Les en-têtes HTTPS sont-ils chiffrés?

600

Lors de l'envoi de données via HTTPS, je sais que le contenu est crypté, mais j'entends des réponses mitigées sur le fait que les en-têtes sont cryptés ou la quantité d'en-tête cryptée.

Combien d'en-têtes HTTPS sont cryptés?

Y compris les URL de demande GET / POST, les cookies, etc.

— Dan Herbert
source

9

Les en-têtes HTTP sur HTTPS sont chiffrés et non compressés HTTP (même si le corps l'est). Cela les rend moins vulnérables aux attaques liées à la compression comme BEAST

— Neil McGuigan

552

Le tout est crypté ^† - tous les en-têtes. C'est pourquoi SSL sur les vhosts ne fonctionne pas trop bien - vous avez besoin d'une adresse IP dédiée car l'en-tête de l'hôte est crypté.

^† La norme SNI (Server Name Identification) signifie que le nom d'hôte peut ne pas être chiffré si vous utilisez TLS. De plus, que vous utilisiez SNI ou non, les en-têtes TCP et IP ne sont jamais chiffrés. (S'ils l'étaient, vos paquets ne seraient pas routables.)

— Greg
source

3

@Greg, Étant donné que la passerelle vhost est autorisée, la passerelle ne peut-elle pas les décrypter, observer l'en-tête Host, puis déterminer à quel hôte envoyer les paquets?

— Pacerier

2

L'URL Afaik elle-même n'est pas chiffrée.

— Teddy

4

@Teddu que voulez-vous dire par "l'URL elle-même n'est pas cryptée". Il est crypté, car il fait partie de l'en-tête.

— Dmitry Polushkin

1

Si Fiddler est utilisé pour capturer la communication https, il affiche toujours des en-têtes, pourquoi? En particulier, lorsque la connexion Internet est via un proxy qui nécessite une authentification, il affiche l'en-tête Proxy-Authorization lorsque la demande est renvoyée après avoir obtenu 407 lors du premier envoi.

— Bochen Lin

1

@Bochen de la même manière que Pegasus. Si vous êtes à l'une ou l'autre extrémité du tunnel HTTPS, vous pouvez tout voir. De la même manière, je peux voir n'importe quoi dans les devtools du navigateur.

— Nux

97

Les en-têtes sont entièrement cryptés. La seule information circulant sur le réseau «en clair» est liée à la configuration SSL et à l'échange de clés D / H. Cet échange est soigneusement conçu pour ne fournir aucune information utile aux écoutes, et une fois qu'il a eu lieu, toutes les données sont cryptées.

— mdb
source

4

La configuration SSL n'implique pas toutes DH

— Dori

30

Pour être un peu pédant: l'adresse IP du client et du serveur, le nom d'hôte du serveur et les signaux concernant leurs implémentations SSL sont utiles aux écoutes et sont visibles.

— poolie

66

Nouvelle réponse à une vieille question, désolé. Je pensais ajouter mon 0,02 $

Le PO a demandé si les en-têtes étaient cryptés.

Ils sont: en transit.

Ils ne sont PAS: lorsqu'ils ne sont pas en transit.

Ainsi, l'URL de votre navigateur (et le titre, dans certains cas) peut afficher la chaîne de requête (qui contient généralement les détails les plus sensibles) et certains détails dans l'en-tête; le navigateur connaît certaines informations d'en-tête (type de contenu, unicode, etc.); et l'historique du navigateur, la gestion des mots de passe, les favoris / signets et les pages en cache contiendront tous la chaîne de requête. Les journaux du serveur sur l'extrémité distante peuvent également contenir une chaîne de requête ainsi que certains détails de contenu.

De plus, l'URL n'est pas toujours sécurisée: le domaine, le protocole et le port sont visibles - sinon les routeurs ne savent pas où envoyer vos demandes.

De plus, si vous avez un proxy HTTP, le serveur proxy connaît l'adresse, généralement il ne connaît pas la chaîne de requête complète.

Donc, si les données sont en mouvement, elles sont généralement protégées. S'il n'est pas en transit, il n'est pas crypté.

Pas à la légère, mais les données à la fin sont également déchiffrées et peuvent être analysées, lues, enregistrées, transmises ou supprimées à volonté. Et les logiciels malveillants à chaque extrémité peuvent prendre des instantanés de données entrant (ou sortant) du protocole SSL - comme (mauvais) Javascript dans une page à l'intérieur de HTTPS qui peut subrepticement faire des appels http (ou https) aux sites Web de journalisation (depuis l'accès au disque dur local) est souvent restreint et inutile).

De plus, les cookies ne sont pas non plus cryptés sous le protocole HTTPS. Les développeurs souhaitant stocker des données sensibles dans des cookies (ou ailleurs d'ailleurs) doivent utiliser leur propre mécanisme de cryptage.

En ce qui concerne le cache, la plupart des navigateurs modernes ne mettent pas en cache les pages HTTPS, mais ce fait n'est pas défini par le protocole HTTPS, il dépend entièrement du développeur d'un navigateur pour être sûr de ne pas mettre en cache les pages reçues via HTTPS.

Donc, si vous craignez de renifler des paquets, vous êtes probablement d'accord. Mais si vous vous inquiétez des logiciels malveillants ou de quelqu'un qui fouille dans votre historique, vos signets, vos cookies ou votre cache, vous n'êtes pas encore sorti de l'eau.

— Andrew Jennings
source

20

Je sais que les bonnes réponses sont au top, mais cela insère une fois de plus des informations erronées . Le domaine n'est pas visible, sauf si SNI est utilisé. Les protocoles autres que IP et TCP ne sont pas visibles. Vous ne pouvez pas dire si j'utilise HTTP 1.1, SPDY ou HTTP2. Ce qui est visible sur les deux points de terminaison n'est pas pertinent, car le but du chiffrement n'est pas de rendre les choses invisibles mais de les rendre visibles uniquement aux parties de confiance. Ainsi, les points finaux sont impliqués dans la question et environ 2/3 de votre réponse peuvent être supprimés. Les informations du proxy doivent être: si vous utilisez un proxy HTTPS, il a alors accès à tout .

— Melvyn

6

Votre lien indique spécifiquement que les cookies sont cryptés: "La connexion du visiteur est cryptée, obscurcissant les URL, les cookies et autres métadonnées sensibles."

— DylanYoung

1

Oui c'est correct. Les cookies sont cryptés pendant le transit, mais une fois qu'ils atteignent le navigateur, ils ne sont pas cryptés par le protocole SSL. Il est possible pour un développeur de crypter les données des cookies, mais cela est hors de portée pour SSL.

— Andrew Jennings

4

@DylanYoung SSL = couche socket sécurisée ; TLS = sécurité de la couche transport . Le chiffrement est au niveau du socket (connexion) ou pour le dire autrement au niveau du transport, pas lorsqu'il est stocké dans le navigateur par base de données de domaine.

— curiousguy

Les cookies HTTP sensibles à la sécurité @Wigwam sont presque toujours des références opaques (généralement c'est un nombre aléatoire cryptographiquement fort) à un enregistrement dans la base de données du serveur de sessions authentifiées. En tant que tel, le cryptage de cet identifiant insignifiant apporterait principalement une complexité supplémentaire.

— curiousguy

53

HTTP version 1.1 a ajouté une méthode HTTP spéciale, CONNECT - destinée à créer le tunnel SSL, y compris la négociation de protocole et la configuration cryptographique nécessaires.
Les demandes régulières par la suite sont toutes envoyées enveloppées dans le tunnel SSL, les en-têtes et le corps inclus.

— Avide
source

Quand CONNECT est-il utilisé pour créer le tunnel SSL?

— curiousguy

@curiousguy tools.ietf.org/html/rfc7231#section-4.3.6

— avp

47

Avec SSL, le cryptage est au niveau du transport, il a donc lieu avant l'envoi d'une demande.

Donc, tout dans la demande est crypté.

— Blowdart
source

Étant donné que SSL a lieu dans la couche transport et que l'attribution de l'adresse de destination dans les paquets (dans l'en-tête) a lieu dans la couche réseau (qui est en dessous du transport), alors comment les en-têtes sont-ils chiffrés?

— Prateek Joshi

@PrateekJoshi Parce que les en-têtes HTTP vivent sur la couche application et sont donc, par défaut, chiffrés en raison du chiffrement d'une couche inférieure / ancêtre.

— Aquarelle

40

HTTPS (HTTP sur SSL) envoie tout le contenu HTTP sur un tunnel SSL, donc le contenu et les en-têtes HTTP sont également chiffrés.

— CMS
source

21

Oui, les en-têtes sont cryptés. C'est écrit ici .

Tout dans le message HTTPS est chiffré, y compris les en-têtes et la charge de demande / réponse.

— appuyez sur la touche
source

37

Wikipédia n'est pas la spécification, c'est ce que vous devriez citer.

— Aran Mulholland

8

l'URL est également cryptée, vous n'avez vraiment que l'IP, le port et si SNI, le nom d'hôte qui n'est pas crypté.

— xxiao
source

Même si SNI n'est pas pris en charge, un intermédiaire capable d'intercepter les connexions HTTP sera souvent également capable de surveiller les questions DNS (la plupart des interceptions se font près du client, comme sur un routeur utilisateur piraté). Ainsi, ils pourront voir les noms DNS.

— curiousguy