Les données GET sont-elles également cryptées dans HTTPS?

Quand vous obtenez

https://encrypted.google.com/search?q=%s

La requête %s est chiffrée? Ou juste la réponse? Si ce n’est pas le cas, pourquoi Google devrait-il également diffuser son contenu public avec le cryptage?

La demande entière est cryptée, y compris l’URL et même la commande ( GET ). La seule chose qu’un intervenant tel qu’un serveur proxy peut glaner est l’adresse et le port de destination.

Notez, cependant, que le paquet Client Hello d’une prise de contact TLS peut annoncer le nom de domaine complet en texte clair via l’ extension SNI (merci @hafichuk), qui est utilisé par tous les navigateurs grand public modernes, mais uniquement sur les nouveaux.

EDIT: (comme cela vient de me donner un badge “bonne réponse”, je suppose que je devrais répondre à toute la question…)

La réponse entière est également cryptée; les mandataires ne peuvent en intercepter aucune partie.

Google fournit des recherches et d’autres contenus sur https, car ils ne sont pas tous publics et vous pouvez également masquer une partie du contenu public d’un MITM . En tout état de cause, il est préférable de laisser Google répondre par lui-même .

L’URL elle-même est cryptée, donc les parameters de la chaîne de requête ne voyagent pas en clair sur l’ensemble du réseau.

Toutefois, gardez à l’esprit que les URL, y compris les données GET, sont souvent consignées par le serveur Web, contrairement aux données POST. Donc, si vous prévoyez de faire quelque chose comme /login/?username=john&password=doe , alors ne le faites pas; utilisez plutôt un POST.

HTTPS Établit une connexion SSL sous-jacente avant le transfert des données HTTP. Cela garantit que toutes les données d’URL (à l’exception du nom d’hôte, qui est utilisé pour établir la connexion) sont transscopes uniquement dans cette connexion chiffrée et sont protégées contre les attaques de type intermédiaire, de la même manière que les données HTTPS.

Ce qui précède fait partie d’une réponse TRÈS complète de Google Answers située ici:

http://answers.google.com/answers/threadview/id/758002.html#answer

La partie de l’URL après l’envoi du nom d’hôte en toute sécurité.

Par exemple, https://somewhere.com/index.php?NAME=FIELD

La partie /index.php?NAME=FIELD est chiffrée. Le somewhere.com n’est pas.

Tout est crypté, mais vous devez vous rappeler que votre requête restra dans les journaux du serveur et sera accessible aux différents parsingurs de journaux, etc. (ce qui n’est généralement pas le cas avec la requête POST).

La connexion est cryptée avant la transmission de la demande. Donc oui, la requête est également chiffrée, y compris la chaîne de requête.

Le SSL a lieu avant l’parsing d’en-tête, ce qui signifie:

 Client creates Request Request gets encrypted Encrypted request gets transmitted to the Server Server decrypts the Request Request gets parsed 

Une requête ressemble à ceci (ne peut pas retenir la syntaxe exacte, mais cela devrait être assez proche):

 GET /search?q=qwerty HTTP/1.1 Host: www.google.de 

C’est aussi la raison pour laquelle avoir des certificates SSL différents pour plusieurs hôtes sur la même adresse IP est problématique, le nom d’hôte demandé n’est pas connu avant le déchiffrement.

Oui, c’est sécurisé. SSL chiffre tout.

Extrait de la demande POST:

 POST /foo HTTP/1.1 ... some other headers 

Extrait de la requête GET:

 GET /foo?a=b HTTP/1.1 ... some other headers 

Dans les deux cas, tout ce qui est envoyé sur le socket est crypté. Le fait que le client voit des parameters dans son navigateur pendant une requête GET ne signifie pas qu’un homme du milieu verrait la même chose.

Je viens de me connecter via HTTPS à un site Web et j’ai passé un tas de parameters GET. J’ai ensuite utilisé wireshark pour renifler le réseau. En utilisant HTTP, l’URL est envoyée non cryptée, ce qui signifie que je peux facilement voir tous les parameters GET dans l’URL. En utilisant HTTPS, tout est crypté et je ne peux même pas voir quel paquet est la commande GET, et encore moins son contenu!

La requête GET est cryptée lors de l’utilisation de HTTPS – en fait, c’est pourquoi les sites Web sécurisés doivent avoir une adresse IP unique – il est impossible d’obtenir le nom d’hôte (ou le répertoire virtuel) souhaité avant le décryptage.