https et cookies de connexion + wifi public

bonjour, je me posais une question théorique sur https et les wifi public.

Voici l’expérience: Je me connecte à un site en https depuis mon wifi domicile et le site me renvoie un cookie de connexion valable 1 an.

Puis je me déplace et je continue à surfer toujours en https sur le site depuis un wifi public.

Un pirate pourrait’il pirater la connexion https sachant qu’elle a commencé sur un wifi de confiance? Il me semble avoir lu qu’au debut du https on s’échange les clef asymétriques et après, on continue en symétrique (donc 100% sécurisé et impossible donc le man in de middle).

Donc à mon niveau de compréhension je ne cours aucun risque sur le wifi public sauf celui que le pirate sait enregistrer mon historique de navigation (à ce titre il ne sait pas voir le contenu des pages visitées)

Salut,

Même dans le cas où tu te inities la connexion sur le wifi public, tu es bien protégé par la crypto asymétrique comme tu l’as compris.

La seule chose qu’un attaquant peut voir sont tes requêtes DNS (quel site, mais pas quelle page puisque la requête http est, elle, chiffrée).

@FantasMaths https*

Je peux me tromper mais il me semble que en asymétrique, une faille man in de middle suffit pour dérober la connexion…. mais je pense que l’adresse des pages n’est pas cryptées non plus, seul son contenu l’est, à ce que je pense. à confirmer…

L’HOST zestedesavoir.com et le PATH /forums/sujet/1234/titre font partie du HEADER qui est encrypté au même titre que le corps de la réponse.

À cause de l’extension SNI du protocole TLS utilisé par HTTPS, le host et le path peuvent apparaître en clair.

Dans le cas de TLS, où il y a de la crypto + l’identité de la personne détenant le certificat (le certificat est lié au nom de domaine), pour que quelqu’un puisse t’écouter il faut qu’il puisse émettre un certificat pour le nom de domaine qui l’intéresse qui soit reconnu par ton navigateur, ce qui n’est pas possible sans intervention sur ta machine (ajout de CA pirate par exemple).

Pour le chemin auquel tu accèdes sur le serveur, a priori ce n’est pas visible en clair mais comme le fait remarquer @psycopy les sites peuvent choisir de ne pas le chiffrer (je ne sais dans quel cas c’est utile par contre). non en effet le path est toujours chiffré

Edit : @A-312 c’est bien une requête http

Il ne faut pas confondre l’hostname et le path présent dans l’header http. Le wiki du SNI parle seulement de l’hostname et non du path

La protection TLS de HTTPS, se fait à une couche assez basse (Transport je crois). Du coup, aucune raison de mettre l’URL, l’URL entière (donc path + query + fragment) est bien chiffrée (et non encrypté) . L’IP du serveur à contacter par contre est nécessaire, c’est évident. Le champs SNI est une extension non obligatoire qui dans la pratique est utilisée quasiment tout le temps. Elle permet de voir le hostname (sachant que souvent depuis l’IP, un reverse DNS permet de retrouver le hostname, mais pas toujours dans le cas où il y a plusieurs « serveurs/services » derrière une IP.

Une version plus respectueuse de la vie privée du champs SNI est en phase de test, c’est le champ ESNI. De manière à protéger le nom du serveur d’une analyse de paquet.