Les URL HTTPS sont-elles cryptées?
Toutes les URL sont-elles cryptées lors de l'utilisation du cryptage TLS/SSL (HTTPS)? J'aimerais savoir parce que je veux 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 à des URL.
Oui, la connexion SSL est établie entre la couche TCP et la couche HTTP. Le client et le serveur établissent d’abord une connexion sécurisée cryptée TCP (via le protocole SSL/TLS), puis le client envoie la requête HTTP (GET, POST, DELETE ...) sur cette instance cryptée TCP connexion.
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
Voir 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 indiquer à un serveur le nom du serveur avec lequel il contacte. Il peut être souhaitable que les clients fournissent Ces informations facilitent les connexions sécurisées aux serveurs hébergeant 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 l'hello du client (étendu).
En bref:
FQDN (la partie domaine de l’URL) PEUT être transmis en clair à l'intérieur du paquet
ClientHellosi l'extension SNI est utiliséeLe reste de l'URL (
/path/?some=parameters&go=here) n'a pas d'activité à l'intérieur deClientHellopuisque l'URL de la demande est un objet HTTP (couche OSI 7), elle ne sera donc jamais affichée dans un dialogue TLS (couche 4 ou 5) Cela viendra plus tard dans une demandeGET /path/?some=parameters&go=here HTTP/1.1HTTP, APRÈS le sécurisé Le canal TLS est établi.
RÉSUMÉ
Le nom de domaine PEUT être transmis en clair (si l'extension SNI est utilisée dans le dialogue TLS), mais l'URL (chemin d'accès et paramètres) est toujours chiffrée.
MISE À JOUR DE MARS 2019
Merci carlin.scott pour avoir soulevé celui-ci.
La charge utile dans l'extension SNI peut maintenant être chiffrée via ce projet de proposition RFC . Cette fonctionnalité n'existe que dans TLS 1.3 (en option et il appartient aux deux extrémités de l'implémenter) et il n'y a pas de compatibilité ascendante avec TLS 1.2 et inférieur.
CloudFlare est en train de le faire et vous pouvez en savoir plus sur les internes ici - Si le poulet doit venir avant l'oeuf, où mettez-vous le poulet?
En pratique, cela signifie qu'au lieu de transmettre le nom de domaine complet en texte brut (comme dans les émissions de capture de Wireshark), il est maintenant chiffré.
REMARQUE: Cette question concerne davantage la confidentialité que la sécurité, car une recherche DNS inversée PEUT révéler le nom de l'hôte de destination.
Toute la demande et la réponse sont cryptées, 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).
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 elle établit la connexion. La deuxième partie (/ herearemygetparameters/1/2/3/4) est protégée par TLS.
Cependant, vous ne devez pas définir de paramètres dans la demande GET pour un certain nombre de raisons.
Premièrement, comme déjà mentionné par d'autres: - fuites via la barre d'adresse du navigateur - fuites dans 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 adressée au site B contiendra l'URL complète du site A dans le paramètre référant de la demande. Et l’administrateur du site B peut le récupérer à partir des fichiers journaux du serveur B.)
Un ajout à 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 voulez pas que le serveur conserve les informations plus longtemps terme, ne le mettez pas dans l'URL.
Oui et non.
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 cryptés.
Remarque pour les demandes GET, l'utilisateur pourra toujours couper et coller l'URL en dehors de la barre d'emplacement et vous ne voudrez probablement pas y insérer d'informations confidentielles pouvant être vues par toute personne regardant l'écran.
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 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, d’autres réponses sont correctes, bien que ce document montre pratiquement que les pages visitées (c’est-à-dire les URL) peuvent être déterminées très efficacement.
Vous ne pouvez pas toujours compter sur la confidentialité de l’URL complète non plus. Par exemple, comme c'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 certificat racine "de confiance" supplémentaire afin que votre navigateur puisse faire confiance à une inspection proxy (intermédiaire) du trafic https. . 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, ce qui constitue une autre raison d'utiliser mots de passe à usage unique ou de changer fréquemment de mot de passe.
Enfin, le contenu de la demande et de la réponse est également exposé s'il n'est pas crypté.
Un exemple de configuration d’inspection est décrit par Point de contrôle ici . Un "café Internet" à l'ancienne utilisant les ordinateurs fournis peut également être configuré de cette manière.
Lien vers ma réponse sur un question dupliquée . Non seulement l'URL disponible dans l'historique des navigateurs, 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 contrôle.
Nous sommes maintenant 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 cela ressemble dans les paquets TCP de cloudflare.com. Ainsi, j'ai attrapé un paquet de négociation "bonjour client" d'une réponse du serveur cloudflare en utilisant Google Chrome comme navigateur comme renifleur de paquets. Je peux toujours lire le nom du serveur en texte brut dans le paquet Bonjour client.
Donc, 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.
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 éventuelles par 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 pendant le transport. Seules votre application et le serveur connaissent les paramètres envoyés via https.
Le seul "peut-être" serait ici si le client ou le serveur est infecté par un logiciel malveillant qui peut voir les données avant qu'elles ne soient encapsulé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é.
De plus, si vous construisez une API ReSTful, les problèmes de fuite de navigateur et de référent http sont principalement 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.