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


Réponses:


148

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 .


2
Je suis un peu mécontent de l'affirmation selon laquelle l'URL est cryptée. Le nom d'hôte n'est-il pas considéré comme faisant partie de l'URL? Si tel est le cas, la déclaration est fausse. Il n'existe aucun moyen de masquer le nom d'hôte / l'adresse IP du FAI / serveur proxy de la même manière que vous ne pouvez pas masquer l'adresse de destination lors de l'envoi de courrier physique.
Abhishek Anand

1
@Abhishek: Le nom d'hôte n'est pas présent dans l'en-tête TCP / IP. Je couvre les adresses IP dans ma réponse.
Marcelo Cantos

Le domaine n'est pas chiffré. Cela permet de prendre en charge les hôtes virtuels basés sur les noms (par rapport aux IP). @MarceloCantos a tout à fait raison de dire que le reste de l'URL (c'est-à-dire la GETcommande) est chiffré. Ceci est couvert dans la RFC 4366
hafichuk du

@hafichuk: Merci pour cela. Je ne savais pas que TLS pouvait annoncer le fqdn. La dernière fois que j'ai essayé de configurer un multiserveur https (il y a plusieurs années, je l'admets), cela semblait impossible sur une seule ip.
Marcelo Cantos

Ajout vraiment important au TLS contenant le nom de domaine: n'oubliez pas la requête DNS en clair incluant également le nom de domaine. Il est fort probable que quelqu'un qui peut voir votre trafic HTTPS crypté puisse également regarder vos requêtes DNS.
Tim G

65

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.


2
+1 merci. Ceci est sur mon propre serveur physique, donc je ne suis pas trop préoccupé par les journaux, mais c'est une bonne considération pour quiconque envisage cela dans un environnement d'hébergement partagé. Il est également important de prendre en compte car je vais transférer les numéros de carte de crédit de cette façon et je ne veux certainement pas les enregistrer :)
orokusaki

3
Peu importe que ce soit votre propre boîte. Vous ne voulez pas non plus que quiconque le possède (c'est-à-dire les pirates informatiques pervers) voie ces mots de passe en texte brut. Ou ces numéros CC (en supposant que vous ne les stockez pas également ailleurs).
Thomas

1
Vous devez les mettre dans le corps du POST, pas dans la chaîne de requête URL.
Thomas

1
Craignez-vous que le wbeserver ait moins de restrictions sur l'accès à ses journaux que sur l'accès aux données du site Web (base de données, fichier, etc.)? IMHO tant que les données accèdent en toute sécurité au serveur Web, tout va bien. les seules personnes qui ont accès au serveur Web doivent être considérées comme fiables, car si elles ne le sont pas, vous ne les empêcherez pas de lire les données d'une manière ou d'une autre.
Serge Profafilecebook

1
Lorsque les mots de passe sont envoyés via GET et qu'ils sont enregistrés dans le journal d'accès, ils ne sont PAS hachés. Je pense que c'est le plus gros problème. Le fait d'avoir des mots de passe hachés dans la base de données n'a pas d'importance si vous pouvez simplement les rechercher dans le journal d'accès du serveur Web. Ils devraient être hachés dans la base de données, s'ils ne le sont pas, veuillez le corriger.
Steen Schütt

22

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



7

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).


1
quels serveurs? accessible à qui?
Jader Dias

2
@Jader aux administrateurs de ces serveurs au moins et aux pirates. Avec la requête POST, les informations ne restent pas dans les journaux, donc à moins qu'elles ne soient enregistrées explicitement, il n'y a pas de problème avec les journaux. Les requêtes GET restent dans les journaux et si quoi qu'il arrive avec le journal (ou l'administrateur décide d'utiliser ces journaux pour de mauvaises activités), vous avez des problèmes.
Rappel d'Eugene Mayevski le

5

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


5

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!


4

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.


3

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.


1
Le HTTP/1.1vient à la fin de la première ligne.
Marcelo Cantos

@Marcelos Cantos: Merci, cela faisait un moment que je n'avais plus à écrire des requêtes HTTP à la main.
Morfildur

0

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.


JFYI: Il existe une extension TLS qui permet au client de spécifier le nom d'hôte et ainsi le serveur peut choisir le certificat correspondant.
Rappel de Eugene Mayevski le

@Eugene: Merci - je connais l'extension TLS, mais seulement dans le sens le plus vague de la conscience - je ne sais rien des détails ni de l'ampleur de son utilisation réelle (ou non).
Michael Burr
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.