Les URL HTTPS sont-elles cryptées?

Question

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

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

Answer 1

Oui, la connexion SSL est établie 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 envoie la requête HTTP (GET, POST, DELETE ...) via cette connexion TCP cryptée.

Answer 2

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

Ce qui suit montre une requête du navigateur à:
https://i.stack.imgur.com/path/?some=parameters&go=here

Consultez cette réponse pour en savoir plus sur les champs de version TLS (il y en a 3 - pas les versions, les champs contenant chacun un numéro de version !)

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

  

3.1. Indication du nom du serveur

     

[TLS] ne fournit pas de mécanisme à un client pour informer un serveur   le nom du serveur avec lequel il contacte. Il peut être souhaitable de   clients à fournir ces informations pour faciliter la sécurité   connexions aux serveurs hébergeant plusieurs serveurs "virtuels" sur   adresse réseau sous-jacente unique.

     

Pour fournir le nom du serveur, les clients PEUVENT inclure un   extension de type " nom_serveur " dans le hello du client (étendu).

En bref:

• FQDN (la partie domaine de l'URL) PEUT être transmis en clair à l'intérieur du /path/?some=parameters&go=here paquet si l'extension SNI est utilisée

• Le reste de l'URL (GET /path/?some=parameters&go=here HTTP/1.1) n'a pas d'activité à l'intérieur <=> car l'URL de la demande est un objet HTTP (couche OSI 7). Par conséquent, elle n'apparaîtra jamais dans une négociation TLS (couche 4 ou 5). Cela viendra plus tard dans une <=> requête HTTP, APRÈS le canal sécurisé TLS est établi.

SOMMAIRE

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

MISE À JOUR DE MARS 2019

Merci, carlin.scott , pour avoir mis celui-ci en évidence.

Le contenu de l'extension SNI peut maintenant être chiffré via ce projet de proposition RFC . Cette fonctionnalité n'existe que dans TLS 1.3 (en option et son implémentation incombe aux deux extrémités) et il n’existe pas de compatibilité ascendante avec TLS 1.2 ou ultérieur.

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

En pratique, cela signifie qu'au lieu de transmettre le nom de domaine complet sous forme de texte brut (comme dans le cas des captures capturées par Wireshark), il est désormais crypté.

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

Answer 3

En tant que autre réponses ont déjà été signalées, https &"; URL & "; sont effectivement cryptés. 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 utilisiez un navigateur, vos URL pourraient également être enregistrées.

Answer 4

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

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

Answer 5

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 car il établit la connexion. La deuxième partie (/ herearemygetparameters / 1/2/3/4) est protégée par TLS.

Toutefois, vous ne devez pas définir de paramètres dans la demande GET pour un certain nombre de raisons.

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

De plus, 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 adressée au site B contiendra l’URL complète de site A dans le paramètre référant de la requête. Et l’administrateur du site B peut le récupérer à partir des fichiers journaux du serveur B.)

Answer 6

Complément à la réponse utile de Marc Novakowski - l'URL est stockée dans les journaux du serveur (par exemple, dans / etc / httpd / logs / ssl_access_log), donc si vous ne souhaitez pas que le serveur conserve les informations à plus long terme, ne le mettez pas dans l'URL.

Answer 7

Oui et non.

La partie de l'adresse du serveur n'est PAS cryptée car elle est utilisée pour configurer la connexion.

Cela pourrait changer à l'avenir avec les 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 chiffrés.

Remarque pour les demandes GET, l'utilisateur pourra toujours couper et coller l'URL en dehors de la barre d'adresse et vous ne voudrez probablement pas y insérer d'informations confidentielles pouvant être vues par toute personne regardant l'écran.

Answer 8

Un tiers qui surveille le trafic peut également 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 deux pages sur un site, l'une beaucoup plus grande que l'autre, la comparaison de la taille du transfert de données indiquerait la page visitée. Il existe des moyens de masquer cette information à une tierce partie, mais ce n'est pas le comportement normal du serveur ou du navigateur. Voir, par exemple, cet article de SciRate, https://scirate.com/arxiv/1403.0297 .

En général, les autres réponses sont correctes, bien que ce document indique pratiquement que les pages visitées (c.-à-d. une URL) peuvent être déterminées très efficacement.

Answer 9

Lien vers ma réponse sur une question en double . L’URL est non seulement disponible dans l’historique des navigateurs, mais aussi dans les journaux côté serveur, mais il est également envoyé en tant qu’en-tête de référent HTTP qui, si vous utilisez un contenu tiers, expose l’URL à des sources indépendantes de votre volonté.

Answer 10

Vous ne pouvez pas non plus toujours compter sur la confidentialité de l'URL complète. Par exemple, comme cela est parfois le cas sur les réseaux d'entreprise, les périphériques fournis tels que votre ordinateur de société sont configurés avec un & "Confiance &" Supplémentaire; certificat racine afin que votre navigateur puisse faire confiance en toute confiance à une inspection du trafic https par un mandataire (intermédiaire). Cela signifie que l'URL complète est exposée pour inspection. Ceci est généralement enregistré dans un journal.

En outre, vos mots de passe sont également exposés et probablement connectés. C’est une autre raison pour utiliser mots de passe uniques ou modifier fréquemment vos mots de passe.

Enfin, le contenu de la requête et de la réponse est également exposé s'il n'est pas crypté.

Un exemple de configuration de l'inspection est disponible. . Un ancien style & "; Internet café & # 233; &"; L’utilisation des ordinateurs fournis peut également être configurée de cette façon.

Answer 11

Nous sommes en 2019 et la version 1.3 de TLS a été publiée. Selon Cloudflare, le SNI peut être chiffré grâce à TLS v1.3. Alors, je me suis dit génial! Voyons à quoi il ressemble dans les paquets TCP de cloudflare.com Alors, j'ai attrapé un & Quot; client hello & Quot; paquet de prise de contact d'une réponse du serveur cloudflare en utilisant Google Chrome comme navigateur & amp; Wirehark comme renifleur de paquets. Je peux toujours lire le nom du serveur en texte brut dans le paquet Bonjour client.

Alors, méfiez-vous de ce que vous pouvez lire car ce n'est toujours pas une connexion anonyme car un intermédiaire peut voir le nom du serveur cible.

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

L'article suivant décrit le cryptage de la SNI fournie 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/] [3]

Answer 12

Bien qu’il existe déjà de bonnes réponses, la plupart d’entre elles se concentrent sur la navigation dans les navigateurs. J'écris ceci en 2018 et probablement quelqu'un veut en savoir plus 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 limitera les attaques potentielles de MiM (ce serait le seul point faible de tout cela). Vous pouvez envoyer des données sensibles via des connexions HTTPS qui seront cryptées lors du transport . Seul votre application et le serveur connaissent les paramètres envoyés via https.

Le seul " peut-être " 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 une personne est infectée par ce type de logiciel, elle aura accès aux données, quel que soit le moyen de transport utilisé.

Answer 13

En outre, si vous créez une API ReSTful, les problèmes de fuite de navigateur et de référencement HTTP sont généralement atténués, car le client peut ne pas être un navigateur et les personnes qui cliquent sur des liens peuvent ne pas être cliquables.

Si tel est le cas, je vous recommande de vous connecter à oAuth2 pour obtenir un jeton de support. Dans ce cas, les seules données sensibles seraient les informations d'identification initiales ... qui devraient probablement figurer dans une demande de publication de toute façon