Le protocole HTTPS équivaut à utiliser HTTP sur une connexion SSL ou TLS (sur TCP).

Ainsi, d'abord un La connexion TCP (sur le port 443) est ouverte au serveur. Cela suffit généralement pour révéler le nom d'hôte du serveur (c'est-à-dire www.monsite.com dans votre cas) à l'attaquant. L'adresse IP est directement observée et:

1. vous avez généralement effectué une requête DNS non chiffrée auparavant,
2. de nombreux serveurs HTTPS ne servent qu'un seul domaine par adresse IP,
3. Le certificat du serveur est envoyé en clair, et contient le nom du serveur (entre plusieurs, peut-être),
4. dans les nouvelles versions TLS, il y a l'indication du nom du serveur, par laquelle le client indique au serveur dont le 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 poignée de main 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 le serveur n'incluent pas le chiffrement NONE dans les suites acceptées, tout ce qui suit l'échange de clé est chiffré.

Et en supposant qu'il n'y a pas de succès attaque man-in-the-middle (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 ensuite envoyé entre vous et le serveur , et aucun attaquant ne peut modifier une partie du contenu sans que cela soit remarqué. Cela inclut l'URL et toute autre partie de la requête HTTP, ainsi que la réponse du serveur.

Bien sûr, comme D.W. mentions, la longueur de la requête (qui ne contient pas beaucoup plus de données variables que l'URL, peut-être certains cookies) et la réponse peuvent être vues à partir du flux de données cryptées. Cela peut perturber le secret, surtout s'il n'y a qu'un petit nombre de ressources différentes sur le serveur. Également toutes les demandes de ressources de suivi.

Votre mot de passe dans l'URL (ou dans toute autre partie de la requête) doit néanmoins être sécurisé - tout au plus sa longueur peut être connue.

Comme vous l'ont dit @ Paŭlo Ebermann et @Jeff Ferland, la requête GET est cryptée sous SSL et est donc sécurisée. Cependant , n'oubliez pas que de nombreux serveurs Web consignent les requêtes et les paramètres GET, et que tous les identifiants ou autres informations sensibles que vous envoyez via GET peuvent être écrits 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 cryptage 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 d'autres personnes prétendent, alors je Je ferais mieux d'expliquer.

Il est vrai que tout ce qui suit le nom de domaine est envoyé crypté. Par exemple, si l'url est https://www.example.com/foo/bar.html , alors www.example.com est visible par l'attaquant, tandis que la requête HTTP ( GET /foo/bar.html HTTP / 1.0 ) est cryptée. 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 par les espions. En outre, d'autres informations, telles que la longueur de la page que vous avez visitée, peuvent également être visibles par l'interlocuteur. C'est un pied dans la porte pour l'attaquant. Il y a eu des 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 de savoir quelles URL vous visitez. Par conséquent, vous ne devez pas supposer que SSL / TLS cache à un espion les pages que vous visitez.

Oui, https assure l'intégrité de l'URL que vous avez visitée.

PS Autre mise en garde: en pratique, sslstrip et d’autres attaques man-in-the-middle peuvent réussir contre la plupart 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, une connexion Wi-Fi ouverte), vous devez vous méfier du fait qu'un attaquant pourrait être en mesure de savoir quelles pages les utilisateurs visitent. Une atténuation partielle contre la menace sslstrip consiste pour les utilisateurs à utiliser HTTPS Partout et pour les sites d'adopter HSTS.

Les éléments suivants vont fuir avant le début de votre session:

• Adresse IP du serveur
• Certificat du serveur
  • Qui inclura le domaine nom 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 les demandes qui ne sont pas liées à la création de la connexion SSL ( GET ... ) sont envoyées 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 correctement chiffrée, les paramètres de requête ne doivent donc jamais être révélés directement.

Cependant, l'analyse du trafic peut souvent obtenir la longueur de l'URL - et connaître le serveur et la longueur de l'URL suffit souvent pour espionner les pages auxquelles on accède, surtout si l'on suppose que les liens sur une page sont cliqués. Google pour "l'analyse du trafic navigation ssl" ou quelque chose de similaire si le sujet vous intéresse.

Dans votre cas d'utilisation, cela est d'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 remplissez 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 une indication de nom de 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 espions peuvent voir le nom du serveur que vous saisissez dans la barre d'adresse.