Avec HTTPS, sont les URL et les en-têtes de requête protégées en tant que le corps de la requête est?

Citant le HTTPS RFC:

Lorsque la poignée de main TLS a fini. Le client peut alors initier la
première requête HTTP. Toutes les données HTTP DOIVENT être envoyés comme TLS "de l'application
de données".

Essentiellement, le canal sécurisé SSL/TLS est d'abord établie. Seulement alors, le protocole HTTP est utilisé. Cela permettra de protéger tout le trafic HTTP avec SSL, y compris les en-têtes HTTP (qui contiennent de l'URL et des cookies).

Ce qui peut être visible dans la poignée de main est le nom de l'hôte lui-même, puisqu'elle est contenue dans le certificat de serveur qui sera visible en clair dans la poignée de main (et il est souvent facile de deviner le nom d'hôte en regardant l'adresse IP de destination de toute façon).

Lors de l'utilisation d'Indication du Nom du Serveur, la demande de nom d'hôte doit également être visible dans le server_name extension dans le ClientHello message.
Sinon, il y a peut-être un peu d'ambiguïté (pour la personne) à deviner le nom d'hôte du certificat si le certificat est valide pour de multiples noms d'hôte (par exemple, plusieurs sous réserve de l'Alt. Des noms ou des caractères génériques). Dans ce cas, les écoutes de la requête DNS à partir du client peut donner à l'attaquant un indice.

Lire les réponses des autres et les commentaires, certains mentionnent des questions à propos de Referer (perte d'un r dans la spec) et les journaux.

• Les référents ne devrait pas être envoyé lors du passage de HTTPS en HTTP (mais ils sont souvent envoyés lorsque vous passez d'un site en HTTPS vers un autre site en HTTPS).
• Sur l'histoire: vous aurez juste à faire confiance à celui qui peut potentiellement obtenir cette clé légitime (c'est à dire à vos utilisateurs de ne pas le diffuser autour. Si nécessaire, une stratégie pour le changer de temps en temps.
• Sur les journaux: je suis en supposant que vous avez été au bout de la protection sur le réseau. L'URL (y compris la requête) sera dans les journaux, en effet, mais si quelqu'un est capable d'attaquer votre machine de manière à obtenir les journaux, vous avez plus à vous soucier que votre application clés.

De l'un des éventuels points faibles est comment vous donner le lien pour l'utilisateur. Si il est intégré dans une page web servi sur HTTP normal, n'importe qui peut lire que la page serait capable de le voir. Vous devez servir une page HTTPS trop. Si vous envoyez ce lien par e-mail au lieu de cela, je dirais que tous les paris sont éteints, depuis les serveurs de messagerie rarement chiffrer les connexions entre eux et les utilisateurs aussi souvent pour accéder à son compte de messagerie électronique, sans cryptage.

EDIT:

En outre, si vous utilisez le client de l'authentification par certificat, le certificat du client sera visible si elle est négociée au cours de la première poignée de main. Cela peut fuite le nom de l'utilisateur qui accède au site web (souvent l'Objet DNs contiennent le nom de l'utilisateur). Le certificat du client ne sera pas visible si elle est envoyée lors de la renégociation d'poignée de main.

Les données de la demande sera envoyée après établissement d'une connexion Sécurisée, donc pas de soucis avec l'URL ci-dessus, mais n'oubliez pas vos données ne sont pas cryptées, seul le canal entre le serveur et le client sont cryptées, si l'on peut se fissurer ce canal, alors vous pouvez clairement voir vos données.

SSL est wrapper canal crypté sur le dessus de vos données. Si des données est simple, n'importe qui qui peut casser le SSL peut voir vos données clairement.

Qui Dépend..

Si vous utilisez un renifleur de paquets vous ne pouvez pas voir les données envoyées sur le réseau. Le principal problème avec cette approche est que l'url de la requête est souvent enregistrée dans le journal du serveur en texte brut, l'historique du navigateur conserve les url, les adresses Url sont passés dans Référent en-têtes et peut-être persisté par les services de tiers (google analytics).