Les URL HTTPS sont-elles cryptées?

1021

Toutes les URL sont-elles cryptées lors de l'utilisation du cryptage TLS / SSL (HTTPS)? Je voudrais le savoir car je souhaite que toutes les données URL soient masquées lors de l'utilisation de TLS / SSL (HTTPS).

Si TLS / SSL vous offre un chiffrement total des URL, je n'ai pas à me soucier de cacher des informations confidentielles aux URL.

ssl  https  httprequest 
— Daniel Kivatinos
source
76
C'est probablement une mauvaise idée de mettre des données confidentielles dans l'URL de toute façon. Il sera également affiché dans l'adresse du navigateur, vous vous en souvenez? Les gens n'aiment pas que leur mot de passe soit visible par quiconque regarde l'écran. Pourquoi pensez-vous que vous devez mettre des données confidentielles dans l'URL?
— jalf
43
Les URL sont également stockées dans l'historique du navigateur et les journaux du serveur - si je voulais que mon nom et mon mot de passe soient stockés quelque part, ce ne serait pas à ces deux endroits.
— Piskvor a quitté le bâtiment le
47
Par exemple, supposons que je visite https://somewhere_i_trust/ways_to_protest_against_the_government/. Ensuite, l'URL contient des données confidentielles, à savoir la suggestion que j'envisage de protester contre mon gouvernement.
— Steve Jessop
42
Je me posais cette question lors d'une demande HTTP à partir d'une application native (non basée sur un navigateur). Je suppose que cela peut intéresser les développeurs d'applications mobiles. Dans ce cas, les commentaires ci-dessus (bien que vrais) ne sont pas pertinents (aucune URL visible, aucun historique de navigation), ce qui rend la réponse, à ma connaissance simple: "Oui, c'est crypté".
— DannyA
23
Pour ceux qui pensent qu'une fois que vous êtes HTTPS, personne ne sait où vous allez, lisez d'abord ceci: Le nom d'hôte du serveur (par exemple example.com) sera toujours divulgué en raison de SNI . Cela n'a absolument rien à voir avec DNS et la fuite se produira même si vous n'utilisez pas DNS ou n'utilisez pas de DNS crypté.
— Pacerier

Réponses:

913

Oui, la connexion SSL se situe entre la couche TCP et la couche HTTP. Le client et le serveur établissent d'abord une connexion TCP cryptée sécurisée (via le protocole SSL / TLS) puis le client enverra la requête HTTP (GET, POST, DELETE ...) sur cette connexion TCP cryptée.

— Marc Novakowski
source
98
Il convient de noter la chose mentionnée par @Jalf dans le commentaire sur la question elle-même. Les données URL seront également enregistrées dans l'historique du navigateur, ce qui peut ne pas être sûr à long terme.
— Michael Ekstrand
20
Pas seulement GET ou POST. Peut également être DELETE, PUT, HEAD ou TRACE.
4
Oui, cela pourrait être un problème de sécurité pour l'historique d'un navigateur. Mais dans mon cas, je n'utilise pas de navigateur (également le message d'origine ne mentionnait pas de navigateur). Utilisation d'un appel https personnalisé dans les coulisses d'une application native. C'est une solution simple pour vous assurer que la connexion du serveur de votre application est sécurisée.
— zingle-dingle
28
Notez cependant que la résolution DNS de l'URL n'est probablement pas chiffrée. Donc, quelqu'un qui flaire votre trafic pourrait toujours voir le domaine auquel vous essayez d'accéder.
— ChewToy
21
SNI rompt la partie «hôte» du cryptage SSL des URL. Vous pouvez le tester vous-même avec Wireshark. Il existe un sélecteur pour SNI, ou vous pouvez simplement consulter vos paquets SSL lorsque vous vous connectez à un hôte distant.
— cmouse
654

Puisque personne n'a fourni une capture de fil, en voici une.
Le nom du serveur (la partie domaine de l'URL) est présenté dans le ClientHellopaquet, en texte brut .

Ce qui suit montre une demande de navigateur pour:
https://i.stack.imgur.com/path/?some=parameters&go=here

ClientHello SNI Voir cette réponse pour en savoir plus sur les champs de version TLS (il y en a 3 - pas des versions, des champs qui contiennent chacun un numéro de version!)

Depuis https://www.ietf.org/rfc/rfc3546.txt :

3.1. Indication du nom du serveur

[TLS] ne fournit pas de mécanisme permettant à un client d'indiquer à un serveur le nom du serveur qu'il contacte. Il peut être souhaitable que les clients fournissent ces informations pour faciliter les connexions sécurisées aux serveurs qui hébergent plusieurs serveurs «virtuels» à une seule adresse réseau sous-jacente.

Afin de fournir le nom du serveur, les clients PEUVENT inclure une extension de type "nom_serveur" dans le bonjour du client (étendu).


En bref:

  • Le FQDN (la partie domaine de l'URL) PEUT être transmis en clair à l'intérieur du ClientHellopaquet si l'extension SNI est utilisée

  • Le reste de l'URL ( /path/?some=parameters&go=here) n'a rien à faire ClientHellopuisque l'URL de demande est une chose HTTP (couche OSI 7), donc elle n'apparaîtra jamais dans une prise de contact TLS (couche 4 ou 5). Cela viendra plus tard dans une GET /path/?some=parameters&go=here HTTP/1.1requête HTTP, APRÈS l' établissement du canal TLS sécurisé .


RÉSUMÉ

Le nom de domaine PEUT être transmis en clair (si l'extension SNI est utilisée dans la négociation TLS) mais l'URL (chemin et paramètres) est toujours cryptée.


MISE À JOUR DE MARS 2019

Merci carlin.scott d' avoir soulevé celui-ci.

La charge utile de l'extension SNI peut désormais être chiffrée via ce projet de proposition RFC . Cette capacité n'existe que dans TLS 1.3 (en option et c'est aux deux extrémités de l'implémenter) et il n'y a pas de compatibilité descendante avec TLS 1.2 et ci-dessous.

CloudFlare le fait et vous pouvez en savoir plus sur les éléments internes ici - Si le poulet doit venir avant l'œuf, où mettez-vous le poulet?

En pratique, cela signifie qu'au lieu de transmettre le nom de domaine complet en texte brut (comme le montre la capture de Wireshark), il est désormais crypté.

REMARQUE: cela aborde l'aspect de la confidentialité plus que celui de la sécurité, car une recherche DNS inversée PEUT révéler l'hôte de destination souhaité de toute façon.

— evilSnobu
source
37
Réponse parfaite, avec une explication complète de A à Z. J'adore le résumé. Made my day @evilSnobu
— oscaroscar
4
Réponse parfaite, vote positif! Considérez toujours la partie client car l'historique du navigateur peut être une fuite. Cependant, en ce qui concerne la couche de transport, les paramètres URL sont cryptés.
— Jens Kreidler
2
Vous voudrez peut-être mettre à jour cette réponse avec le fait que TLS 1.3 crypte l'extension SNI, et le plus grand CDN fait exactement cela: blog.cloudflare.com/encrypted-sni Bien sûr, un renifleur de paquets pourrait simplement faire une recherche DNS inverse pour les adresses IP auxquelles vous vous connectez.
— carlin.scott
@evilSnobu, mais le nom d'utilisateur: mot de passe fait partie du nom d' utilisateur: password@domain.com est crypté, non? Il est donc sûr de transmettre des données sensibles dans l'URL à l'aide de https.
— Maksim Shamihulau
1
Ils sont cryptés sur le câble (en cours de transport) mais si l'une ou l'autre extrémité (utilisateur ou serveur) enregistre l'URL dans un fichier texte brut et ne nettoie pas les informations d'identification ... c'est une conversation différente.
— evilSnobu
159

Comme les autres réponses l' ont déjà souligné, les https "URL" sont en effet cryptées. Cependant, votre demande / réponse DNS lors de la résolution du nom de domaine ne l'est probablement pas, et bien sûr, si vous utilisez un navigateur, vos URL peuvent également être enregistrées.

— Zach Scrivena
source
21
Et l'enregistrement d'URL est important car il existe des hacks Javascript qui permettent à un site complètement indépendant de tester si une URL donnée est dans votre historique ou non. Vous pouvez rendre une URL impossible à deviner en y incluant une chaîne aléatoire assez longue, mais s'il s'agit d'une URL publique, l'attaquant peut dire qu'elle a été visitée, et si elle contient un court secret, alors un attaquant pourrait forcer à une vitesse raisonnable.
— Steve Jessop
8
@SteveJessop, veuillez fournir un lien vers "Les hacks Javascript qui permettent à un site complètement indépendant de tester si une URL donnée est dans votre historique ou non"
— Pacerier
6
@Pacerier: pirater la date bien sûr, mais ce dont je parlais à l'époque, c'était des choses comme stackoverflow.com/questions/2394890/… . C'était une grosse affaire en 2010 que ces questions fassent l'objet d'une enquête et que les attaques soient affinées, mais je ne suis pas vraiment en train de le suivre pour le moment.
— Steve Jessop
2
@Pacerier: plus d'exemples: webdevwonders.com/… , webdevwonders.com/…
— Steve Jessop
1
Vous pouvez utiliser OpenDNS avec son service DNS chiffré. Je l'utilise sur mon Mac, mais j'ai trouvé que la version Windows ne fonctionnait pas correctement. C'était il y a quelque temps, donc ça pourrait bien marcher maintenant. Pour Linux rien encore. opendns.com/about/innovations/dnscrypt
— SPRBRN
101

L'ensemble de la demande et de la réponse est crypté, y compris l'URL.

Notez que lorsque vous utilisez un proxy HTTP, il connaît l'adresse (domaine) du serveur cible, mais ne connaît pas le chemin demandé sur ce serveur (c'est-à-dire que la demande et la réponse sont toujours cryptées).

— Peter Štibraný
source
1
L'intégralité de la demande. Le nom d'hôte est envoyé en clair. Tout le reste est crypté.
— Sam Sirry
98

Je suis d'accord avec les réponses précédentes:

Pour être explicite:

Avec TLS, la première partie de l'URL ( https://www.example.com/ ) est toujours visible lors de l'établissement de la connexion. La deuxième partie (/ herearemygetparameters / 1/2/3/4) est protégée par TLS.

Cependant, il existe un certain nombre de raisons pour lesquelles vous ne devez pas mettre de paramètres dans la demande GET.

Tout d'abord, comme déjà mentionné par d'autres: - fuite via la barre d'adresse du navigateur - fuite via l'historique

En plus de cela, vous avez une fuite d'URL via le référent http: l'utilisateur voit le site A sur TLS, puis clique sur un lien vers le site B. Si les deux sites sont sur TLS, la demande vers le site B contiendra l'URL complète du site A dans le paramètre référent de la demande. Et l'administrateur du site B peut le récupérer à partir des fichiers journaux du serveur B.)

— Tobias
source
3
@EJP Vous n'avez pas compris ce que Tobias dit. Il dit que si vous cliquez sur un lien sur le site A qui vous mènera au site B, le site B obtiendra l'URL de référence. Par exemple, si vous êtes sur siteA.com?u=username&pw=123123 , alors siteB.com (qui est lié à sur la page de siteA.com) recevra " siteA.com?u=username&pw=123123 " comme référence URL, envoyée à siteB.com à l'intérieur du HTTPS par le navigateur. Si c'est vrai, c'est très mauvais. Est-ce vrai Tobias?
— trusktr
9
@EJP, le domaine est visible grâce à SNI que tous les navigateurs Web modernes utilisent. Voir également ce diagramme de l'EFF montrant que n'importe qui peut voir le domaine du site que vous visitez. Il ne s'agit pas de visibilité du navigateur. Il s'agit de ce qui est visible pour les écoutes.
— Buge
10
@trusktr: les navigateurs ne doivent pas envoyer d'en-tête Referer à partir des pages HTTPS. Cela fait partie de la spécification HTTP .
— Martin Geisler
8
@MartinGeisler, le mot clé est "devrait". Les navigateurs ne se soucient pas beaucoup de "devrait" (par opposition à "doit"). À partir de votre propre lien: "fortement recommandé que l'utilisateur soit en mesure de sélectionner l'envoi ou non du champ Référent. Par exemple, un client de navigateur pourrait avoir un interrupteur à bascule pour naviguer ouvertement / anonymement, ce qui activerait / désactiverait respectivement l'envoi de Referer et From information " . Ops, c'est exactement ce que Chrome a fait. Sauf que Chrome laisse fuir le référent même si vous êtes en mode navigation privée .
— Pacerier
48

Un ajout à la réponse utile de Marc Novakowski - l'URL est stockée dans les journaux sur le serveur (par exemple, dans / etc / httpd / logs / ssl_access_log), donc si vous ne voulez pas que le serveur conserve les informations sur la durée terme, ne le mettez pas dans l'URL.

— Rhodri Cusack
source
34

Oui et non.

La partie d'adresse du serveur n'est PAS cryptée car elle est utilisée pour établir la connexion.

Cela pourrait changer à l'avenir avec SNI et DNS cryptés mais à partir de 2018, les deux technologies ne sont pas couramment utilisées.

Le chemin, la chaîne de requête, etc. sont cryptés.

Remarque pour les demandes GET, l'utilisateur sera toujours en mesure de couper et coller l'URL hors de la barre d'emplacement, et vous ne voudrez probablement pas y mettre des informations confidentielles qui peuvent être vues par quiconque regarde l'écran.

— Caisse à savon
source
8
Je voudrais attribuer +1 à cela, mais je trouve le "oui et non" trompeur - vous devriez changer cela pour simplement signaler que le nom du serveur sera résolu en utilisant DNS sans chiffrement.
— Lawrence Dol
7
À ma connaissance, le PO utilise le mot URL dans le bon sens. Je pense que cette réponse est plus trompeuse, car elle ne fait pas clairement la différence entre le nom d'hôte dans l'URL et le nom d'hôte dans la résolution DNS.
— Guillaume
4
L'URL est cryptée. Chaque aspect de la transaction HTTP est crypté. Pas seulement «tout le reste». Période. -1.
— Marquis de Lorne
4
@EJP mais la recherche DNS ne utiliser ce qui est à une partie de point de l'URL, de sorte à la personne non-technique, l'URL complète ne sont pas cryptées. La personne non technique qui utilise simplement Google.com pour rechercher des éléments non techniques ne sait pas où résident les données ni comment elles sont traitées. Le domaine, qui fait partie de l'URL que l'utilisateur visite, n'est pas crypté à 100% car, en tant qu'attaquant, je peux détecter le site qu'il visite. Seul le / chemin d'une URL est intrinsèquement crypté pour le profane (peu importe comment).
— trusktr
6
@EJP, @ trusktr, @ Lawrence, @ Guillaume. Vous vous trompez tous. Cela n'a rien à voir avec le DNS. SNI " envoie le nom du domaine virtuel dans le cadre de la négociation TLS ", donc même si vous n'utilisez pas DNS ou si votre DNS est crypté, un sniffer peut toujours voir le nom d' hôte de vos requêtes.
— Pacerier
9

Un tiers qui surveille le trafic peut également être en mesure de déterminer la page visitée en examinant votre trafic et en le comparant avec le trafic d'un autre utilisateur lors de la visite du site. Par exemple, s'il n'y avait que 2 pages sur un site, une beaucoup plus grande que l'autre, la comparaison de la taille du transfert de données indiquerait la page que vous avez visitée. Il existe des moyens de masquer cela à un tiers, mais ce n'est pas un comportement normal du serveur ou du navigateur. Voir par exemple ce document de SciRate, https://scirate.com/arxiv/1403.0297 .

En général, les autres réponses sont correctes, bien que cet article montre que les pages visitées (c.-à-d. URL) peuvent être déterminées assez efficacement.

— pbhj
source
Cela ne serait vraiment réalisable que sur de très petits sites, et dans ces cas, le thème / ton / nature du site serait probablement toujours le même sur chaque page.
— Cameron
5
D'après la citation que j'ai donnée: "Nous présentons une attaque d'analyse de trafic contre plus de 6000 pages Web couvrant les déploiements HTTPS de 10 sites Web de pointe largement utilisés dans des domaines tels que les soins de santé, la finance, les services juridiques et la vidéo en continu. Notre attaque identifie des pages individuelles dans le même site Web avec une précision de 89% [...] ". Il semble que votre conclusion quant à la faisabilité soit fausse.
— pbhj
2
Pour tous ceux qui souhaitent en savoir plus sur ce type de vulnérabilité, ces types d'attaques sont généralement appelés attaques latérales .
— Dan Bechard
7

Vous ne pouvez pas non plus toujours compter sur la confidentialité de l'URL complète. Par exemple, comme c'est parfois le cas sur les réseaux d'entreprise, les appareils fournis comme le PC de votre entreprise sont configurés avec un certificat racine supplémentaire "de confiance" afin que votre navigateur puisse discrètement faire confiance à une inspection par proxy (homme au milieu) du trafic https . Cela signifie que l'URL complète est exposée pour inspection. Ceci est généralement enregistré dans un journal.

De plus, vos mots de passe sont également exposés et probablement enregistrés et c'est une autre raison d'utiliser des mots de passe à usage unique ou de changer fréquemment vos mots de passe.

Enfin, le contenu des demandes et des réponses est également exposé s'il n'est pas chiffré autrement.

Checkpoint présente un exemple de configuration d'inspection . Un "cybercafé" à l'ancienne utilisant les PC fournis peut également être configuré de cette façon.

— Don Gillis
source
6

Lien vers ma réponse sur une question en double . Non seulement l'URL est disponible dans l'historique des navigateurs, les journaux côté serveur, mais elle est également envoyée comme en-tête HTTP Referer qui, si vous utilisez du contenu tiers, expose l'URL à des sources indépendantes de votre volonté.

— JoshBerke
source
Fournir vos appels tiers est également HTTPS bien que ce ne soit pas un problème, non?
— Liam
3
Il serait crypté avec le certificat tiers afin qu'ils puissent voir l'URL
— JoshBerke
5

Nous sommes maintenant en 2019 et le TLS v1.3 est sorti. Selon Cloudflare, le SNI peut être crypté grâce à TLS v1.3. Alors je me suis dit super! Voyons à quoi cela ressemble dans les paquets TCP de cloudflare.com Donc, j'ai attrapé un paquet de prise de contact "bonjour client" à partir d'une réponse du serveur cloudflare utilisant Google Chrome comme navigateur et Wireshark comme renifleur de paquets. Je peux toujours lire le nom du serveur en texte brut dans le paquet bonjour du client.

entrez la description de l'image ici

Alors, méfiez-vous de ce que vous pouvez lire car il ne s'agit toujours pas d'une connexion anonyme. Un middleware entre le client et le serveur pourrait consigner tous les domaines demandés par un client.

Il semble donc que le chiffrement de la SNI nécessite des implémentations supplémentaires pour fonctionner avec TLSv1.3

L'article suivant décrit le cryptage du SNI fourni par Cloudflare dans le cadre de TLSv1.3. Cependant, toutes les URL HTTP de cloudflare.com sont en texte brut dans le paquet TCP sous TLS v1.3

[ https://blog.cloudflare.com/encrypted-sni/ diplomatique-03]

— Nicolas Guérinet
source
"le SNI peut être crypté" - c'est le point clé. La vérification de cloudflare.com/ssl/encrypted-sni avec Google Chrome actuel indique "Votre navigateur n'a pas chiffré le SNI lors de la visite de cette page." Il en faut deux pour le tango ...
— Piskvor a quitté le bâtiment le
Apparemment, Firefox actuel peut faire ESNI, mais il est désactivé par défaut: vous devez activer network.security.esni.enabled, défini network.trr.modesur 2 (qui définit actuellement votre résolveur DoH sur CloudFlare), et redémarrez le navigateur (sic!); il utilisera ensuite ESNI - là où il est pris en charge par l'infrastructure du domaine. Voir blog.mozilla.org/security/2018/10/18/… pour plus de détails.
— Piskvor a quitté le bâtiment le
2

Bien qu'il existe déjà de bonnes réponses, la plupart se concentrent sur la navigation par navigateur. J'écris ceci en 2018 et probablement quelqu'un veut savoir sur la sécurité des applications mobiles.

Pour les applications mobiles , si vous contrôlez les deux extrémités de l'application (serveur et application), tant que vous utilisez HTTPS, vous êtes en sécurité . iOS ou Android vérifiera le certificat et atténuera les éventuelles attaques MiM (ce serait le seul point faible de tout cela). Vous pouvez envoyer des données sensibles via des connexions HTTPS afin qu'elles soient chiffrées pendant le transport . Seule votre application et le serveur connaîtront tous les paramètres envoyés via https.

Le seul "peut-être" ici serait si le client ou le serveur est infecté par un logiciel malveillant qui peut voir les données avant qu'elles ne soient enveloppées dans https. Mais si quelqu'un est infecté par ce type de logiciel, il aura accès aux données, peu importe ce que vous utiliserez pour le transporter.

— Ricardo BRGWeb
source
1

De plus, si vous créez une API ReSTful, les problèmes de fuite de navigateur et de référent http sont généralement atténués car le client n'est peut-être pas un navigateur et il se peut que personne ne clique sur les liens.

Si tel est le cas, je recommanderais la connexion oAuth2 pour obtenir un jeton au porteur. Dans ce cas, les seules données sensibles seraient les informations d'identification initiales ... qui devraient probablement être dans une demande de publication de toute façon

— Chris Rutledge
source
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.