Quand vous obtenez
https://encrypted.google.com/search?q=%s
La %s
requête est-elle chiffrée? Ou juste la réponse? Si ce n'est pas le cas, pourquoi Google devrait-il également diffuser son contenu public avec cryptage?
Quand vous obtenez
https://encrypted.google.com/search?q=%s
La %s
requête est-elle chiffrée? Ou juste la réponse? Si ce n'est pas le cas, pourquoi Google devrait-il également diffuser son contenu public avec cryptage?
Réponses:
L'ensemble de la requête est chiffrée, y compris l'URL et même la commande ( GET
). La seule chose qu'une partie intervenante telle 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ée par tous les navigateurs grand public modernes, bien que certains uniquement sur les systèmes d'exploitation plus récents.
EDIT: (Puisque 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 diffuse des recherches et d'autres contenus sur https car tout n'est pas public et vous pouvez également masquer une partie du contenu public d'un MITM . Dans tous les cas, il est préférable de laisser Google répondre par lui-même .
GET
commande) est chiffré. Ceci est couvert dans la RFC 4366
L'URL elle-même est chiffrée, de sorte que les paramètres de la chaîne de requête ne voyagent pas en clair sur le fil.
Cependant, gardez à l'esprit que les URL comprenant les données GET sont souvent enregistrées par le serveur Web, alors que les données POST le sont rarement. 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 de toute donnée HTTP. Cela garantit que toutes les données URL (à l'exception du nom d'hôte, qui est utilisé pour établir la connexion) sont transportées uniquement dans cette connexion cryptée et sont protégées contre les attaques de l'homme du milieu de la même manière que toutes 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 le nom d'hôte est envoyée en toute sécurité.
Par exemple, https://somewhere.com/index.php?NAME=FIELD
La /index.php?NAME=FIELD
pièce est cryptée. Le somewhere.com
n'est pas.
Tout est crypté, mais vous devez vous rappeler que votre requête restera dans les journaux du serveur et sera accessible à divers analyseurs de journaux, etc. (ce qui n'est généralement pas le cas avec la requête POST).
Je viens de me connecter via HTTPS à un site Web et j'ai passé un tas de paramètres GET. J'ai ensuite utilisé wirehark pour renifler le réseau. En utilisant HTTP, l'URL est envoyée non chiffrée, ce qui signifie que je peux facilement voir tous les paramètres GET dans l'URL. En utilisant HTTPS, tout est crypté et je ne peux même pas voir quel paquet est la commande GET, sans parler de son contenu!
Oui, c'est sécurisé. SSL crypte tout.
Extrait de la requête POST:
POST /foo HTTP/1.1
... some other headers
Extrait de la demande GET:
GET /foo?a=b HTTP/1.1
... some other headers
Dans les deux cas, tout ce qui est envoyé sur le socket est chiffré. Le fait que le client voit des paramètres dans son navigateur lors d'une requête GET ne signifie pas qu'un homme au milieu verrait la même chose.
Le SSL a lieu avant l'analyse de l'en-tête, cela 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 à quelque chose comme ça (je ne me souviens pas de la syntaxe exacte, mais cela devrait être assez proche):
GET /search?q=qwerty HTTP/1.1
Host: www.google.de
C'est aussi pourquoi avoir des certificats SSL différents pour plusieurs hôtes sur la même IP est problématique, le nom d'hôte demandé n'est pas connu avant le décryptage.
HTTP/1.1
vient à la fin de la première ligne.
La demande GET est chiffré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 n'y a aucun moyen d'obtenir le nom d'hôte (ou le répertoire virtuel) prévu de la demande jusqu'à ce qu'elle ait été déchiffrée.