Disons que j'essaie d'accéder https://www.secretplace.com/really/really/secret.php En fait, qu'est-ce qui est envoyé en clair avant que la session SSL ne soit établie ?
Le navigateur intervient-il, voit-il que je veux un accès https, lance-t-il une session SSL avec secretplace.com (c'est-à-dire sans transmettre le chemin d'accès en clair) et ne transmet-il le chemin d'accès qu'une fois la session SSL établie ?
Simple curiosité.
Le niveau de protection dépend de l'exactitude de la mise en œuvre du navigateur web et du logiciel du serveur, ainsi que des algorithmes cryptographiques effectivement pris en charge.
En outre, le protocole HTTPS est vulnérable lorsqu'il est appliqué à un contenu statique accessible au public. L'ensemble du site peut être indexé à l'aide d'un robot d'exploration, et l'URI de la ressource cryptée peut être déduit en ne connaissant que la taille de la requête/réponse interceptée. Un attaquant peut ainsi avoir accès au texte en clair (le contenu statique accessible au public) et au texte chiffré (la version chiffrée du contenu statique), ce qui permet une attaque cryptographique.
Étant donné que le protocole SSL fonctionne sous le protocole HTTP et n'a aucune connaissance des protocoles de niveau supérieur, les serveurs SSL ne peuvent présenter strictement qu'un seul certificat pour une combinaison IP/port particulière. Cela signifie que, dans la plupart des cas, il n'est pas possible d'utiliser l'hébergement virtuel par nom avec HTTPS. Il existe une solution appelée Server Name Indication (SNI) qui envoie le nom d'hôte au serveur avant de crypter la connexion, bien que de nombreux anciens navigateurs ne prennent pas en charge cette extension. La prise en charge de SNI est disponible depuis Firefox 2, Opera 8, et Internet Explorer 7 sous Windows Vista.
En général, le nom du serveur auquel vous vous adressez est divulgué ("stackoverflow.com"). Ce nom a probablement été divulgué via le DNS avant que SSL/TLS ne puisse commencer à se connecter.
Le certificat du serveur a été divulgué. Tout certificat client que vous avez envoyé (configuration peu courante) peut ou non avoir été envoyé en clair. Un attaquant actif (man-in-the-middle) pourrait probablement demander le certificat à votre navigateur et le recevoir quand même.
La partie chemin de l'URL ("/questions/2146863/how-much-data-is-leaked-from-ssl-connection") ne doit PAS être divulguée. Elle est transmise chiffrée et sécurisée (en supposant que le client et le serveur sont correctement configurés et que vous n'avez pas cliqué sur une erreur de certificat).
L'autre afficheur a raison de dire qu'il existe des attaques possibles d'analyse de trafic qui peuvent être capables de déduire certaines choses sur le contenu statique. Si le site est très vaste et dynamique (disons stackoverflow.com), je soupçonne qu'il pourrait être assez difficile d'en tirer des informations utiles. Cependant, s'il n'y a que quelques fichiers avec des tailles distinctes, les téléchargements pourraient être évidents.
Les données du formulaire POST ne doivent PAS être divulguées. Les mises en garde habituelles s'appliquent toutefois si vous transmettez des objets de taille connue.
Les attaques sur le temps peuvent révéler certaines informations. Par exemple, un attaquant peut exercer une pression sur différentes parties de l'application (par exemple, une certaine table de base de données) ou précharger des fichiers statiques à partir du disque et observer comment votre connexion ralentit ou accélère en réponse.
Il s'agit d'une "fuite" d'informations, mais ce n'est probablement pas un problème majeur pour la plupart des sites.
La demande est faite par votre navigateur pour https://url:443 et c'est clair. Ensuite, le serveur et le client négocient une suite de chiffrement pour protéger les données. Normalement, elle comprend un algorithme de chiffrement symétrique (par exemple, 3DES, RC4 ou AES) et un code d'authentification des messages (tel que HMAC-SHA1) pour détecter les falsifications. Notez que, techniquement, ces deux éléments sont facultatifs. IS Il est possible d'avoir un SSL sans cryptage mais peu probable aujourd'hui.
Une fois que le client (votre navigateur) et le serveur web ont convenu d'une suite de chiffrement et que les clés sont déterminées, le reste de la conversation est protégé.
Pour être honnête, je brancherais un analyseur de protocole et je regarderais tout cela se dérouler sous vos yeux !
N'oubliez pas que le protocole SSL se situe au niveau de la couche de transport de la pile TCP/IP, sous les données du navigateur, et qu'il est donc entièrement protégé.
J'espère que cela vous aidera.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
