SSL / TLS (https) masque-t-il les URL auxquelles on accède
Supposons que je tape ceci dans mon navigateur
https://www.mysite.com/getsecret?username=alice&password=mysecret
et un attaquant surveille tout le trafic entre moi et mon FAI.
Quelles informations sont protégées par HTTPS? L'URL est-elle révélée? Les paramètres de la demande get sont-ils révélés?
De plus, HTTPS assure-t-il l'intégrité de l'url?
J'ai essayé de regarder divers articles HTTPS et la spécification TLS, mais je n'ai pas pu comprendre cela.
[EDIT:] Ce n'est pas grave si seul le nom de domaine du serveur est révélé. Cependant, aucune partie de ?username=alice&password=mysecret devrait être révélé.
Le protocole HTTPS équivaut à utiliser HTTP sur une connexion SSL ou TLS (sur TCP).
Ainsi, d'abord un connexion TCP (sur le port 443) est ouvert au serveur. Cela suffit généralement à révéler le nom d'hôte du serveur (c'est-à-dire www.mysite.com dans votre cas) à l'attaquant. L'adresse IP est directement observée et:
- vous faisiez généralement une requête DNS non chiffrée auparavant,
- de nombreux serveurs HTTPS ne desservent qu'un seul domaine par adresse IP,
- Le certificat du serveur est envoyé en clair et contient le nom du serveur (entre plusieurs, peut-être),
- dans les versions TLS plus récentes, il y a l'indication du nom du serveur, par laquelle le client indique au serveur quel nom d'hôte est souhaité, afin que le serveur puisse présenter le bon certificat, s'il en a plusieurs. (Ceci est fait pour pouvoir s'éloigner de 2.)
Ensuite, une prise de contact TLS a lieu. Cela comprend la négociation d'une suite de chiffrement, puis un échange de clés. En supposant qu'au moins un de votre navigateur et que le serveur n'ait pas inclus le chiffre NONE dans les suites acceptées, tout ce qui suit l'échange de clé est crypté.
Et en supposant qu'il n'y ait pas d'attaque réussie d'homme au milieu (c'est-à-dire un attaquant qui intercepte la connexion et présente un faux certificat de serveur que votre navigateur accepte), l'échange de clés est sécurisé et aucun espion ne peut décrypter quoi que ce soit qui est alors envoyé entre vous et le serveur, et aucun attaquant ne peut modifier aucune partie du contenu sans que cela ne soit remarqué. Cela inclut l'URL et toute autre partie de la demande HTTP, ainsi que la réponse du serveur.
Bien sûr, comme D.W. mentionne, la longueur de la demande (qui ne contient pas beaucoup plus de données variables que l'URL, peut-être certains cookies) et la réponse peut être vue à partir du flux de données cryptées. Cela pourrait saper le secret, surtout s'il n'y a qu'un petit nombre de ressources différentes sur le serveur. Aussi toutes les demandes de ressources de suivi.
Cependant, votre mot de passe dans l'URL (ou toute autre partie de la demande) doit toujours être sécurisé - tout au plus sa longueur peut-elle être connue.
Comme @ Paŭlo Ebermann et @Jeff Ferland vous l'ont dit, la demande GET est cryptée sous SSL et est donc sûre. Cependant, n'oubliez pas que de nombreux serveurs Web enregistrent les demandes et les paramètres GET, et toutes les informations d'identification ou autres informations sensibles que vous envoyez via GET peuvent être écrites quelque part dans un journal. Pour cette raison, vous devez utiliser POST (qui sera également crypté sous SSL) lors de la soumission de données sensibles.
Cela tombe dans la catégorie "le chiffrement n'est pas une sécurité magique qui résout tous vos problèmes".
Vous devez supposer que l'URL n'est pas protégée, c'est-à-dire qu'un espion passif peut être en mesure de savoir quelle URL vous visitez.
Je me rends compte que cela contredit ce que certains prétendent, alors je ferais mieux de l'expliquer.
Il est vrai que tout ce qui se trouve après le nom de domaine est envoyé crypté. Par exemple, si l'URL est https://www.example.com/foo/bar.html, puis www.example.com est visible pour l'attaquant, tandis que la requête HTTP (GET /foo/bar.html HTTP/1.0) est crypté. Cela empêche un espion de voir directement la partie chemin de l'URL. Cependant, la longueur de la partie chemin de l'URL peut être visible pour l'écoute. En outre, d'autres informations - telles que la longueur de la page que vous avez visitée - peuvent également être visibles pour l'écouteur. C'est un pied dans la porte pour l'attaquant. Il y a eu certaines recherches qui utilisent ce pied dans la porte pour savoir quelles URL vous visitez , si l'attaquant peut espionner votre trafic https.
Bien qu'il n'y ait aucune garantie que ces attaques réussiront, je suggère qu'il serait prudent de supposer le pire: supposer qu'un espion peut être en mesure d'apprendre quelles URL vous visitez. Par conséquent, vous devez pas supposer que SSL/TLS cache à un espion quelles pages vous visitez.
Oui, https assure l'intégrité de l'URL que vous avez visitée.
P.S. Une autre mise en garde: dans la pratique, sslstrip et d'autres attaques man-in-the-middle peuvent réussir contre de nombreux ou la plupart des utilisateurs, si le site Web n'utilise pas HSTS . Ces attaques peuvent violer à la fois la confidentialité et l'intégrité de l'URL. Par conséquent, si les utilisateurs visitent des sites Web qui n'utilisent pas HSTS sur un réseau non sécurisé (par exemple, Wifi ouvert), vous devez vous méfier qu'un attaquant pourrait être en mesure d'apprendre quelles pages les utilisateurs visitent. Une atténuation partielle contre la menace sslstrip est que les utilisateurs tilisent HTTPS Everywhere et que les sites adoptent HSTS.
Les choses suivantes fuiront avant le début de votre session:
- Adresse IP du serveur
- Certificat du serveur
- Cela comprendra le nom de domaine publié sur le certificat, mais cela ne garantit pas qu'il correspondra à ce que vous avez utilisé.
- Vos requêtes DNS
Aucune donnée ou demande non liée à la création de la connexion SSL (GET ...) sont envoyés au serveur avant le début de la session SSL. L'URL est envoyée dans le cadre de la demande de page et protégée de la même manière que tout trafic faisant partie de la session.
Oui et non.
L'URL est cryptée correctement, les paramètres de requête ne doivent donc jamais être révélés directement.
Cependant, l'analyse du trafic peut obtenir la longueur de l'URL souvent - et connaître le serveur et la longueur de l'URL est souvent suffisant pour espionner les pages auxquelles on accède, surtout si l'on suppose que les liens sur une page sont cliqués. Google pour "navigation ssl d'analyse du trafic" ou quelque chose de similaire si le sujet vous intéresse.
Dans votre cas d'utilisation, cela n'a qu'une importance marginale. Une utilisation intelligente de l'analyse du trafic peut révéler la longueur du nom d'utilisateur et/ou la longueur du mot de passe, selon que les autres URL récupérées contiennent également le nom d'utilisateur. Si vous complétez le nom d'utilisateur/mot de passe à une longueur constante, vous pouvez éviter ces attaques, mais cela ne vaut peut-être pas la peine.
Les piles TLS commencent à envoyer l'indication du nom du serveur (SNI, http://en.wikipedia.org/wiki/Server_Name_Indication ; http://www.ietf.org/rfc/rfc3546 .txt ). Cela est envoyé en clair, ce qui signifie que les écoutes peuvent voir le nom du serveur que vous tapez dans la barre d'adresse.