Passer le site en HTTPS par défaut

Compte anonymisé · Le 11/03/2017, à 12:14

Hello,

Vu que Firefox et Chrome commencent à avertir l'utilisateur quand un formulaire de login n'est pas sécurisé (https), je pense qu'il serait temps de diriger tous les visiteurs vers la version HTTPS du site. En plus de ne pas ennuyer les visiteurs, ça permettra d'augmenter la sécurité de ceux qui sont sur des Wifi publics ou des réseaux surveillés, et qui ne savaient peut-être pas qu'on pouvait voler leurs identifiants.

J'ai d'ailleurs jamais compris pourquoi la version http n'avait pas disparu. Le coût de https est négligeable et le laisser en option ne sert à rien : la plupart se moquent de la barre d'adresse et ne remarquent pas qu'ils sont sur un site pas sécurisé.

J5012 · Le 12/03/2017, à 13:43

le https n'a pas pour but d'empecher le vol d'identifiants ...
http ne peut pas disparaitre, c'est le protocole de base des serveurs http ...

Cyberbleuet · Le 12/03/2017, à 15:37

J'ai d'ailleurs jamais compris pourquoi la version http n'avait pas disparu

Plus de http = plus de web

Compte anonymisé · Le 12/03/2017, à 16:26

J5012 a écrit :

le https n'a pas pour but d'empecher le vol d'identifiants ...

À quoi sert le chiffrement pour toi ? Protéger les identifiants, c'est une des raisons d'être de TLS ; la preuve, Chrome et Firefox commencent à le demander sur les pages de login.

J5012 a écrit :

http ne peut pas disparaitre, c'est le protocole de base des serveurs http ...

Sylvain Malenfant a écrit :

Plus de http = plus de web

Je parlais bien sûr de la version HTTP(pas S) de Ubuntu-fr. Quand le support de HTTPS est arrivé il y a un moment, la version HTTP est restée ouverte et utilisée par défaut, du coup le support de HTTPS ne sert presque à rien.

Dernière modification par Compte anonymisé (Le 12/03/2017, à 16:26)

J5012 · Le 13/03/2017, à 00:33

shillage a écrit :

J5012 a écrit :
le https n'a pas pour but d'empecher le vol d'identifiants ...
À quoi sert le chiffrement pour toi ? Protéger les identifiants, c'est une des raisons d'être de TLS ; la preuve, Chrome et Firefox commencent à le demander sur les pages de login.
J5012 a écrit :
http ne peut pas disparaitre, c'est le protocole de base des serveurs http ...
Sylvain Malenfant a écrit :
Plus de http = plus de web
Je parlais bien sûr de la version HTTP(pas S) de Ubuntu-fr. Quand le support de HTTPS est arrivé il y a un moment, la version HTTP est restée ouverte et utilisée par défaut, du coup le support de HTTPS ne sert presque à rien.

ce n'est pas parce que la demande de login se passe sur une page https que ca protege du vol d'identifiants ... parce que ce n'est pas l'objectif du protocole https ... https sert à certifier les transactions entre operateur (le commerce online par ex) et le destinataire (la banque par ex) ... dans une page de login https, la transaction est la verification du login, pas sa protection ! : https assure que login et pass viennent bien du meme serveur que la page de login https , et pas d'un opportun "man-in-the-middle" ...

http ne disparait pas meme avec le protocole https ... https fonctionne avec http + tls !

Compte anonymisé · Le 13/03/2017, à 08:05

J5012 a écrit :

ce n'est pas parce que la demande de login se passe sur une page https que ca protege du vol d'identifiants ... parce que ce n'est pas l'objectif du protocole https ... https sert à certifier les transactions entre operateur (le commerce online par ex) et le destinataire (la banque par ex) ... dans une page de login https, la transaction est la verification du login, pas sa protection ! : https assure que login et pass viennent bien du meme serveur que la page de login https , et pas d'un opportun "man-in-the-middle" ...

Je ne sais pas qui t'a dit ça, mais tu te trompes. TLS a pour but d'authentifier une connexion ET de garder les données échangées secrètes. Après l'authentification (DSA ou RSA), il y a un échange de clés (Diffie-Hellman), puis toutes les données sont chiffrées avec un algorithme symétrique (souvent AES). Tu peux voir tous ces noms dans certains navigateurs en cliquant sur le cadenas dans la barre d'adresse.

Wikipedia a écrit :

When secured by TLS, connections between a client (e.g., a web browser) and a server (e.g., wikipedia.org) have one or more of the following properties:
The connection is private (or secure) because symmetric cryptography is used to encrypt the data transmitted.
[...]
The identity of the communicating parties can be authenticated using public-key cryptography.
[...]
The connection ensures integrity because each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission.

TLS sert à authentifier le serveur, à garder les échanges secrets, et à garantir que les données ne sont pas modifiées pendant le transfert. Ici c'est la deuxième propriété qui est intéressante.

J5012 a écrit :

http ne disparait pas meme avec le protocole https ... https fonctionne avec http + tls !

Je sais bien, comme j'ai dit au-dessus, ce n'est pas le protocole HTTP que j'aimerais voir disparaître mais la version non-sécurisée de Ubuntu-fr, parce que si elle est utilisée par défaut la version sécurisée ne sert à rien.

Edit : au cas où tu ne me croirais toujours pas sur le but de TLS, voici la RFC 5246 qui définit TLS 1.2, par l'IETF, le groupe responsable de TLS :

IETF a écrit :

The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications.

Dernière modification par Compte anonymisé (Le 13/03/2017, à 08:16)

Compte anonymisé · Le 13/03/2017, à 08:22

shillage a écrit :

Je ne sais pas qui t'a dit ça, mais tu te trompes. TLS a pour but d'authentifier une connexion ET de garder les données échangées secrètes.

Dans ce cas, en jouant le rôle du man in the middle, explique-moi comment suis-je arrivé à chiper des informations de cookies d'authentification sur deux sites différents en HTTPS.

Compte anonymisé · Le 13/03/2017, à 08:26

jojo81 a écrit :

shillage a écrit :
Je ne sais pas qui t'a dit ça, mais tu te trompes. TLS a pour but d'authentifier une connexion ET de garder les données échangées secrètes.
Dans ce cas, en jouant le rôle du man in the middle, explique-moi comment suis-je arrivé à chiper des informations de cookies d'authentification sur deux sites différents en HTTPS.

Ça manque de détails. C'était des machines à toi ? Tu contrôlais la connexion et tu as intercepté des identifiants ? Alors TLS était mal implémenté, ou tu avais ajouté un certificat que tu contrôlais sur le client, ou le chiffrement était partiel (ça arrive sur certains sites, les navigateurs afichent un avertissement en général).

Si TLS est bien utilisé, il n'y a aucune fuite de données.

Compte anonymisé · Le 13/03/2017, à 08:33

shillage a écrit :

jojo81 a écrit :
shillage a écrit :
Je ne sais pas qui t'a dit ça, mais tu te trompes. TLS a pour but d'authentifier une connexion ET de garder les données échangées secrètes.
Dans ce cas, en jouant le rôle du man in the middle, explique-moi comment suis-je arrivé à chiper des informations de cookies d'authentification sur deux sites différents en HTTPS.
Ça manque de détails. C'était des machines à toi ? Tu contrôlais la connexion et tu as intercepté des identifiants ? Alors TLS était mal implémenté, ou tu avais ajouté un certificat que tu contrôlais sur le client, ou le chiffrement était partiel (ça arrive sur certains sites, les navigateurs afichent un avertissement en général).
Si TLS est bien utilisé, il n'y a aucune fuite de données.

Aucun avertissement de la part des navigateurs.
Aucun certificat contrôlé.

Une machine en sous-réseau, connectée à un routeur dont je contrôlais ses paramètres avec une autre machine. Il me suffisait d'écouter une des interfaces de ce routeur et de trouver les bons paquets pour trouver les informations de cookies. Avec ces informations de cookies, j'ai reconstitué ce cookie sur une troisième machine dans ce même sous réseau, résultat, une authentification piratée.

Compte anonymisé · Le 13/03/2017, à 16:55

La connexion se faisait entre deux machines de ton réseau ? Donc ces deux machines étaient à toi ? Ou tu te connectais à des sites extérieurs ? Je comprends pas très bien ce que tu as fait.

De toute façon ça ne change pas grand chose : si tu te connectes à https://www.ubuntu-fr.org et que tu te connectes à ton compte, tu verras que tu ne peux pas intercepter tes identifiants depuis ton routeur sans modifier quelque chose sur ton client.

Dernière modification par Compte anonymisé (Le 13/03/2017, à 16:56)

Compte anonymisé · Le 13/03/2017, à 19:15

shillage a écrit :

La connexion se faisait entre deux machines de ton réseau ? Donc ces deux machines étaient à toi ? Ou tu te connectais à des sites extérieurs ? Je comprends pas très bien ce que tu as fait.
De toute façon ça ne change pas grand chose : si tu te connectes à https://www.ubuntu-fr.org et que tu te connectes à ton compte, tu verras que tu ne peux pas intercepter tes identifiants depuis ton routeur sans modifier quelque chose sur ton client.

M1---------<10.0.2.16>|
|<192.168.1.187>----(~)----<192.168.1.1>|<@mon_ip_publique>-----------(~)---------<@IP>|
M2---------<10.0.2.15>|

J'ai capturé le trafic sur 10.0.2.16 (M1) qui dialoguait vers @IP avec mon PC sur 192.168.1.187 . Trouvant ensuite les paquets IP correspondant aux données des cookies d'identification, je les aies réutilisées pour reconstituer un cookie sur 10.0.2.15 (M2)

M2 pouvait donc s'identifier chez @IP sans devoir renseigner login et mot de passe sur le navigateur web.

Compte anonymisé · Le 13/03/2017, à 19:22

jojo81 a écrit :

M1---------<10.0.2.16>|
|<192.168.1.187>----(~)----<192.168.1.1>|<@mon_ip_publique>-----------(~)---------<@IP>|
M2---------<10.0.2.15>|
J'ai capturé le trafic sur 10.0.2.16 (M1) qui dialoguait vers @IP avec mon PC sur 192.168.1.187 . Trouvant ensuite les paquets IP correspondant aux données des cookies d'identification, je les aies réutilisées pour reconstituer un cookie sur 10.0.2.15 (M2)
M2 pouvait donc s'identifier chez @IP sans devoir renseigner login et mot de passe sur le navigateur web.

Tu es sûr que la connexion utilisait TLS ? Si tu as pu récupérer un cookie de connexion simplement en surveillant le trafic, ce cookie n'était pas chiffré ; peut-être une mauvaise configuration du site.

Tu peux réessayer avec https://www.ubuntu-fr.org, je suis sûr que tu ne récupéreras pas ce cookie.

J5012 · Le 13/03/2017, à 19:41

shillage a écrit :

J5012 a écrit :
ce n'est pas parce que la demande de login se passe sur une page https que ca protege du vol d'identifiants ... parce que ce n'est pas l'objectif du protocole https ... https sert à certifier les transactions entre operateur (le commerce online par ex) et le destinataire (la banque par ex) ... dans une page de login https, la transaction est la verification du login, pas sa protection ! : https assure que login et pass viennent bien du meme serveur que la page de login https , et pas d'un opportun "man-in-the-middle" ...
Je ne sais pas qui t'a dit ça, mais tu te trompes. TLS a pour but d'authentifier une connexion ET de garder les données échangées secrètes. Après l'authentification (DSA ou RSA), il y a un échange de clés (Diffie-Hellman), puis toutes les données sont chiffrées avec un algorithme symétrique (souvent AES). Tu peux voir tous ces noms dans certains navigateurs en cliquant sur le cadenas dans la barre d'adresse.
Wikipedia a écrit :
When secured by TLS, connections between a client (e.g., a web browser) and a server (e.g., wikipedia.org) have one or more of the following properties:
The connection is private (or secure) because symmetric cryptography is used to encrypt the data transmitted.
[...]
The identity of the communicating parties can be authenticated using public-key cryptography.
[...]
The connection ensures integrity because each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission.
TLS sert à authentifier le serveur, à garder les échanges secrets, et à garantir que les données ne sont pas modifiées pendant le transfert. Ici c'est la deuxième propriété qui est intéressante.
J5012 a écrit :
http ne disparait pas meme avec le protocole https ... https fonctionne avec http + tls !
Je sais bien, comme j'ai dit au-dessus, ce n'est pas le protocole HTTP que j'aimerais voir disparaître mais la version non-sécurisée de Ubuntu-fr, parce que si elle est utilisée par défaut la version sécurisée ne sert à rien.
Edit : au cas où tu ne me croirais toujours pas sur le but de TLS, voici la RFC 5246 qui définit TLS 1.2, par l'IETF, le groupe responsable de TLS :
IETF a écrit :
The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications.

je ne remets pas en cause ton explication ... et je disais exactement la meme chose !
la page web protegee par https ne protege que la transaction, pas le vol d'identifiants ... on peut voler les identifiants autrement ! avec une faiblesse dans la base de donnees par ex ... ce qui est arrivé à sony par ex ...

je disais seulement que ton argument "empecher le vol d'identifiants" n'est pas un bon argument puisque https protege juste les transactions entre operateur et serveur destinataire (meme si des identifiants sont utilisés pour partie dans le chiffrement par tls, https ne protege pas leur vol : https n'a aucune prise sur comment les identifiants sont stockés par ex)

la doc n'est pas protégée parce qu'il n'ya rien à proteger dessus : c'est un gaspillage de ressources que de deployer https pour garantir la transaction de sources documentaires non secretes , et de plus destinées à etre diffusées au plus grand nombre ...

Compte anonymisé · Le 13/03/2017, à 19:53

J5012 a écrit :

je ne remets pas en cause ton explication ... et je disais exactement la meme chose !
la page web protegee par https ne protege que la transaction, pas le vol d'identifiants ... on peut voler les identifiants autrement ! avec une faiblesse dans la base de donnees par ex ... ce qui est arrivé à sony par ex ...

D'accord, j'avais mal compris. Je parlais seulement du vol d'identifiants par un Wifi ou réseau local malveillant, ce qui est assez courant et facile à déjouer pour qu'on s'y attaque. Suffit de rediriger les utilisateurs vers une url en https, et tout est réglé, vu que c'est déjà supporté par le serveur.

J5012 a écrit :

je disais seulement que ton argument "empecher le vol d'identifiants" n'est pas un bon argument puisque https protege juste les transactions entre operateur et serveur destinataire (meme si des identifiants sont utilisés pour partie dans le chiffrement par tls, https ne protege pas leur vol : https n'a aucune prise sur comment les identifiants sont stockés par ex)

Oui c'est aussi un problème. On protégerait déjà bien mieux les utilisateurs du forum avec TLS. Les Wifi publics sont très utilisés et jamais de confiance (puisque publics) !

J5012 a écrit :

la doc n'est pas protégée parce qu'il n'ya rien à proteger dessus : c'est un gaspillage de ressources que de deployer https pour garantir la transaction de sources documentaires non secretes , et de plus destinées à etre diffusées au plus grand nombre ...

Je n'ai jamais modifié la doc, mais je vois qu'on s'y connecte aussi ; un MITM peut voler un compte sur n'importe quelle page du site du moment que l'utilisateur se connecte dessus. C'est pour ça que j'aimerais bien qu'il soit choisi par défaut.

D'ailleurs, pour les performances, le chargement des pages est instantané en HTTPS chez moi (presque aussi rapide qu'ouvrir un dossier dans Nautilus), et je n'imagine pas le protocole charger énormément le serveur vu que ce forum n'est pas Facebook. De plus, HTTP/2 permet des gains en performance et les gros navigateurs ont décidé de ne le supporter qu'avec TLS ; je ne sais pas où ça en est sur ce site.

Dernière modification par Compte anonymisé (Le 13/03/2017, à 19:57)

J5012 · Le 13/03/2017, à 20:09

@shillage : pas besoin de voler un compte : il y a bien assez de vandales en anonymous ...

Compte anonymisé · Le 13/03/2017, à 20:11

shillage a écrit :

Tu es sûr que la connexion utilisait TLS ?

Oui, sur les deux que j'ai testé.

shillage a écrit :

Tu peux réessayer avec https://www.ubuntu-fr.org, je suis sûr que tu ne récupéreras pas ce cookie.

Le but n'est pas de récupérer le cookie en lui même, mais le contenu de celui-ci.
Si https://www.ubuntu-fr.org est configuré pareil que ceux que j'ai visité, je ne serai pas si sûr.

Compte anonymisé · Le 13/03/2017, à 22:04

J5012 a écrit :

@shillage : pas besoin de voler un compte : il y a bien assez de vandales en anonymous ...

On peut poster en anonyme ici ?
Edit : tu parlais de la doc peut-être ? J'avais mal compris.

jojo81 a écrit :

Le but n'est pas de récupérer le cookie en lui même, mais le contenu de celui-ci.
Si https://www.ubuntu-fr.org est configuré pareil que ceux que j'ai visité, je ne serai pas si sûr.

Réessaye avec ce site alors ! Ça pourrait être intéressant si tu y arrivais.

Dernière modification par Compte anonymisé (Le 13/03/2017, à 22:05)

Compte anonymisé · Le 14/03/2017, à 07:18

shillage a écrit :

Réessaye avec ce site alors ! Ça pourrait être intéressant si tu y arrivais.

"Tout le monde" peut le faire.
Par contre, je ne suis pas sûr que les administrateurs de ce site conseillent de dire que j'y suis arrivé devant tout le monde.

Compte anonymisé · Le 14/03/2017, à 18:15

jojo81 a écrit :

"Tout le monde" peut le faire.

Je n'ai pas pu le faire en surveillant mon interface pendant la connexion : tout est chiffré.

jojo81 a écrit :

Par contre, je ne suis pas sûr que les administrateurs de ce site conseillent de dire que j'y suis arrivé devant tout le monde.

Tu réalises que ce que tu dis nécessite soit que les deux sites que tu as mentionné soient très mal configurés, soit une faille catastrophique et évidente dans le protocole dont la sécurité de tous les sites Web dépend ?

En TLS, toutes les données transférées sont chiffrées, point. Si tu as pu récupérer quoi que ce soit sans être le client ou le serveur, ce n'était pas protégé par TLS.

Est-ce que tu pourrais au moins m'envoyer l'adresse desdits sites par MP pour que j'aille voir ? D'ailleurs, s'ils sont en HTTPS mais que leurs cookies de connexion sont transmis en clair, ça serait une bonne idée d'aller leur signaler directement pour qu'ils corrigent ça.

Pour revenir au sujet, c'est dommage qu'un admin du site ne lise pas ce sujet... Je devrais peut-être poster dans le topic de propositions.

Dernière modification par Compte anonymisé (Le 14/03/2017, à 18:16)

Compte anonymisé · Le 14/03/2017, à 20:51

shillage a écrit :

tout est chiffré.

À quel genre de données tu t'attends ?

shillage a écrit :

D'ailleurs, s'ils sont en HTTPS mais que leurs cookies de connexion sont transmis en clair, ça serait une bonne idée d'aller leur signaler directement pour qu'ils corrigent ça.

Déjà fait.

Dernière modification par Compte anonymisé (Le 14/03/2017, à 20:54)

Compte anonymisé · Le 15/03/2017, à 07:59

jojo81 a écrit :

À quel genre de données tu t'attends ?

Des données qui ont l'air aléatoire, vu que c'est ce que produisent les algos de chiffrement modernes. Et c'est ce que j'ai capturé avec tcpdump.

jojo81 a écrit :

shillage a écrit :
D'ailleurs, s'ils sont en HTTPS mais que leurs cookies de connexion sont transmis en clair, ça serait une bonne idée d'aller leur signaler directement pour qu'ils corrigent ça.
Déjà fait.

Tu es leur héros

koshieIsYourDaddy · Le 29/03/2017, à 15:58

Ce n'est pas parce qu'il existe des moyens de contourner une protection qu'il ne faut pas la mettre en place... Il en existe plusieurs, du bête certificats à l'échange de clé Diffie-Hellman.

Le coût du TLS est négligeable aujourd'hui si le serveur web est correctement configuré pour optimisé la transaction.

Même s'il existe des failles, il est quand même important, à partir du moment où il y a une transaction de données privées (identifiant carte bleu, mot de passe etc), d'avoir une garantie (presque parfaite) entre le client et le serveur, et que ces données si elles sont récupérés, ne soit pas exploitable sans difficulté (même mineures).

Le coût monétaire est aujourd'hui nul avec des outils comme Let's Encrypt.

C'est une habitude recommandés par tout les grands du web... Par Google, Firefox, la W3C, l'EFF... Voici quelques liens utiles à ce sujet:

http://stackoverflow.com/questions/2177 … by-default
https://www.sslshopper.com/why-ssl-the- … cates.html

C'est une des priorités des acteurs du web, même petit, de participer à leur échelle à créer un web plus sûr. Je ne comprend pas pourquoi ça n'est pas le cas des gérants du forum. Peut-être ont-il un avis et des raisons à ce sujet et j'aimerai bien les connaître car je suis dubitatif.

Enfin, il est même aujourd'hui recommandé de passer l'intégralité de ses données vers le TLS, et donc àplu le port 80. Pourquoi? Après tout s'il n'y a pas de données sensibles, on s'en fiche, non?

Et bien non, ça permet toujours d'augmenter les preuves de l'authenticité du site sur lequel on se trouve. Ça permet aussi de brouiller les pistes pour un attaquant: par quelle page va t'il commencer si l'ensemble du site est protégé? Les petits malins ne perdront pas trop de temps à résoudre ce problème, mais ça limiterai les exploits via des outils de script-kiddies qui attaque à vue tout ce qui n'est pas protégé.

Bref, y'a beaucoup plus d'avantages que d'inconvénient.

Savoir qu'à l'heure actuelle un de mes voisins peut récupérer sans trop de difficulté mon mot de passe ici si j'utilise le wi-fi, je trouve ça gros pour un forum Linux, une communauté censé être intéressé de nature par la sécurité et la protection des données.

Dernière modification par koshieIsYourDaddy (Le 29/03/2017, à 16:00)

lynn · Le 29/03/2017, à 19:39

C'est vrai que la page d'accueil d'ubuntu-fr n'est pas en https... On peut se demander pourquoi alors que le reste est en https..?!

koshieIsYourDaddy · Le 29/03/2017, à 20:03

Chose bizarre que j'ai remarqué, tout à l'heure sur ce PC, Firefox m'indiquait clairement que j'étais pas en https. Mais maintenant, sur deux Firefox différents (ce pc et un autre) oui... Comprend plus.

J5012 · Le 29/03/2017, à 21:54

la doc et le forum sont en https mais https n'est pas encore obligatoire sur le forum ... je crois savoir que la machine de la doc n'est pas la meme que celle du forum (et qu'il y a un bleme de certificat derriere)...

si tu tapes dans la barre url doc.ubuntu-fr sans marquer le protocole https de facon explicite, le serveur te redirige automatiquement sur la version https ... ce n'est pas le cas avec le forum où tu peux encore te loguer en http , c'est mon cas : je recois des erreurs de certification https, ce que je n'obtiens pas avec le https de la doc ...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 11/03/2017, à 12:14

Passer le site en HTTPS par défaut

#2 Le 12/03/2017, à 13:43

Re : Passer le site en HTTPS par défaut

#3 Le 12/03/2017, à 15:37

Re : Passer le site en HTTPS par défaut

#4 Le 12/03/2017, à 16:26

Re : Passer le site en HTTPS par défaut

#5 Le 13/03/2017, à 00:33

Re : Passer le site en HTTPS par défaut

#6 Le 13/03/2017, à 08:05

Re : Passer le site en HTTPS par défaut

#7 Le 13/03/2017, à 08:22

Re : Passer le site en HTTPS par défaut

#8 Le 13/03/2017, à 08:26

Re : Passer le site en HTTPS par défaut

#9 Le 13/03/2017, à 08:33

Re : Passer le site en HTTPS par défaut

#10 Le 13/03/2017, à 16:55

Re : Passer le site en HTTPS par défaut

#11 Le 13/03/2017, à 19:15

Re : Passer le site en HTTPS par défaut

#12 Le 13/03/2017, à 19:22

Re : Passer le site en HTTPS par défaut

#13 Le 13/03/2017, à 19:41

Re : Passer le site en HTTPS par défaut

#14 Le 13/03/2017, à 19:53

Re : Passer le site en HTTPS par défaut

#15 Le 13/03/2017, à 20:09

Re : Passer le site en HTTPS par défaut

#16 Le 13/03/2017, à 20:11

Re : Passer le site en HTTPS par défaut

#17 Le 13/03/2017, à 22:04

Re : Passer le site en HTTPS par défaut

#18 Le 14/03/2017, à 07:18

Re : Passer le site en HTTPS par défaut

#19 Le 14/03/2017, à 18:15

Re : Passer le site en HTTPS par défaut

#20 Le 14/03/2017, à 20:51

Re : Passer le site en HTTPS par défaut

#21 Le 15/03/2017, à 07:59

Re : Passer le site en HTTPS par défaut

#22 Le 29/03/2017, à 15:58

Re : Passer le site en HTTPS par défaut

#23 Le 29/03/2017, à 19:39

Re : Passer le site en HTTPS par défaut

#24 Le 29/03/2017, à 20:03

Re : Passer le site en HTTPS par défaut

#25 Le 29/03/2017, à 21:54

Re : Passer le site en HTTPS par défaut

Pied de page des forums