web-dev-qa-db-fra.com

L'URL HTTPS est-elle en texte brut à la première connexion?

Disons que je ne me suis jamais connecté au site example.com.

Si ce site est https et que j'écris https://example.com/supersecretpage l'URL sera-t-elle envoyée en texte clair puisque c'est la première fois que je me connecte au site et donc que les clés cryptographiques n'ont pas encore été échangées? Sinon, quand cela a-t-il lieu? Quelqu'un pourrait-il expliquer les étapes lorsque je tape cette URL?

tlshttpurl
34
user104545

Réponse courte: Non, l'URL est cryptée, mais le (sous) domaine est envoyé en texte brut. Dans votre cas, un attaquant (passif) sait auquel vous vous connectez example.com, mais il ne sait pas à quelle page spécifique vous accédez.

En bref, il y a trois fois où un attaquant peut obtenir des informations sur le site auquel vous accédez (chronologique ordonné):

  1. (Sous) domaine dans la requête DNS
  2. (Sous) domaine dans le Client Hello (SNI)
  3. (Sous) domaine dans le certificat du serveur

Cependant, le...

  1. L'URL est envoyée cryptée via TLS

Pour plus de détails, lisez l'explication ci-dessous.

Explication

Remarque: Lorsque j'écris "(sous) domaine", je veux dire à la fois le domaine (example.com) et le sous-domaine (mydomain.example.com). Lorsque j'écris uniquement "domaine", je ne veux vraiment dire que le domaine (example.com) sans le sous-domaine.

Fondamentalement, ce qui se passe est:

  1. Vous tapez https://example.com/supersecretpage .
  2. Le navigateur soumet le (sous) domaine dans une extension TLS spéciale (appelée SNI =)
  3. À un moment donné, le navigateur obtient le certificat SSL du serveur.
    Selon le certificat *, cela inclut également le sous-domaine auquel vous vous connectez, mais il peut également inclure plus d'un sous-domaine et même plus d'un domaine. Donc, en fait, le cert de example.com peut également inclure www.example.com, devserver.example.com et how-to-develop-tls.example. Ces entrées sont appelées Subject Alternative Names et le certificat est valable pour toutes.
  4. Une fois que le client a vérifié le certificat et que le client et le serveur ont choisi un chiffre, le trafic est chiffré .

  5. Après tout cela, une requête HTTP "habituelle" est envoyée (via le canal TLS sécurisé). Cela signifie que c'est la première fois dans toute la requête que l'URL complète apparaît. La demande par exemple ressemble à ça:

    GET/supersecretpage HTTP/1.1
    Hôte: example.com
    [...]

* Si le certificat est un certificat générique, il n'inclut pas les sous-domaines, mais seulement *.example.com.

Une autre chose mérite d'être mentionnée: Avant que la connexion puisse être établie, le client doit résoudre le nom DNS. Pour ce faire, il envoie des requêtes DNS non cryptées à un serveur DNS et celles-ci contiennent également le (sous =) domaine , qui peut donc être utilisé par un attaquant pour voir les domaines visités.

Cependant cela ne doit pas toujours se produire de cette façon, car vous supposez que l'utilisateur saisit manuellement https://example.com/supersecretpage dans la barre d'URL. Mais cela est très rare car la plupart des utilisateurs, par exemple préfère taper example.com/supersecretpage. Un autre problème serait que les visiteurs cliquent sur n lien non sécurisé , qui utilise HTTP - contrairement à n lien HTTPS sécurisé ). Ces liens pourraient par exemple être d'anciens liens créés lorsque le site ne prend pas en charge HTTPS ou ne redirige pas vers HTTPS par défaut. Vous demandez pourquoi cela compte?

Dans un tel cas (habituel), il n'y a pas de https:// dans l'URL. Lorsqu'aucun protocole n'est entré dans la barre d'URL, tous les navigateurs "convertissent" en interne cette URL en http://example.com/supersecretpage (notez le http: // là-bas) car ils ne peuvent pas s'attendre à ce que le serveur prenne en charge HTTPS. Cela signifie que le navigateur essaie d'abord de se connecter au site Web en utilisant HTTP non sécurisé et seulement après que le site Web envoie une redirection (301) vers l'URL HTTPS, il utilise le mode sécurisé.
Dans ce cas, l'attaquant peut voir l'URL complète dans la requête HTTP non chiffrée.

Vous pouvez facilement le tester par vous-même en consultant le "panneau réseau" de votre navigateur. Là, vous devriez voir cette "mise à niveau HTTPS":
HTTPS connection upgrade in Firefox

Notez cependant qu'il existe des techniques pour empêcher cette première requête HTTP non sécurisée. Plus particulièrement HSTS et - pour protéger même la première connexion que vous établissez avec le site - préchargement HSTS , mais aussi HTTPS Everywhereaide contre de telles attaques. FYI: Selon Netcraft 95% de tous les serveurs HTTPS vulnérables étaient vulnérables à de telles attaques (SSL Stripping) en mars 2016.

76
rugk

Non, l'URL ne sera pas envoyée en texte clair.

Immédiatement après la fin de la négociation à trois voies TCP, votre client lance la négociation TLS avec le serveur. Ce n'est qu'une fois cette négociation terminée et le chiffrement en place que la demande HTTP est envoyée.

15
gowenfawr

Puisque vous n'avez jamais visité le site www.example.com, votre navigateur doit résoudre le nom de domaine en adresse IP. Par conséquent, il envoie une requête de résolution DNS qui contient le nom de domaine du site auquel vous essayez de vous connecter. Ainsi, un MITM peut savoir à quel domaine vous essayez de vous connecter, sauf si vous utilisez un DNS sécurisé.

2
user90696