puisque personne n'a fourni de capture, en voici une.

nom de serveur (la partie domaine de L'URL) est présenté dans le paquet ClientHello , dans texte simple .

ce qui suit montre une demande de navigateur à:

https://i.stack.imgur.com/path/?some=parameters&go=here

voir cette réponse pour en savoir plus sur TLS champs de version (il y en a 3 - pas des versions, des champs qui contiennent 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 pour un client afin de lui indiquer un serveur le nom du serveur sur lequel il est en contact avec les. il peut être souhaitable les clients à fournir ce informations pour faciliter sécurisé des connexions à des serveurs qui hébergent plusieurs "virtuel" de serveurs adresse réseau unique sous-jacente.

afin de fournir le nom du serveur, les clients peuvent inclure un extension du type "server_name" dans le client hello (étendu).

en bref:

• Nom de domaine complet (la partie domaine de l'adresse URL) PEUT transmis en clair à l'intérieur de la ClientHello paquet si SNI d'utiliser l'extension

• le reste de L'URL ( /path/?some=parameters&go=here ) n'a pas à être à l'intérieur de ClientHello puisque L'URL de la requête est une chose HTTP (couche OSI 7), donc il ne se présentera jamais dans une poignée de main TLS (couche 4 ou 5). Cela viendra plus tard dans une GET /path/?some=parameters&go=here HTTP/1.1 demande HTTP, APRÈS le sécurisé canal TLS est établi.

RÉSUMÉ

Le nom de domaine

peut être transmis en clair (si L'extension SNI est utilisée dans la poignée de main TLS) mais L'URL (chemin et paramètres) est toujours crypté.

comme le autre réponses ont déjà souligné, https" URLs " sont en effet cryptés. Cependant, votre demande/réponse DNS lors de la résolution du nom de domaine n'est probablement pas, et bien sûr, si vous utilisiez un navigateur, vos URL pourraient être enregistrées aussi.

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

notez que lorsque vous utilisez un mandataire HTTP, il connaît l'adresse (le domaine) du serveur cible, mais ne connaît pas le chemin demandé sur ce serveur (c.-à-d. la requête et la réponse sont toujours crypté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 encore visible lors de la construction de la connexion. La deuxième partie (/herearemygetparameters)/1/2/3/4) est protégée par TLS.

cependant, il y a un certain nombre de raisons pour lesquelles vous ne devriez pas mettre de paramètres dans la requête GET.

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

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 de référencement 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 sur le serveur (par exemple, dans /etc/httpd/logs/ssl_access_log), donc si vous ne voulez pas que le serveur de maintenir l'information à long terme, ne le mettez pas dans L'URL.

Oui et non.

la partie adresse du serveur n'est pas cryptée puisqu'elle est utilisée pour configurer la connexion.

cela pourrait changer à l'avenir avec le SNI et le 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ées.

Note pour les requêtes GET l'utilisateur pourra toujours couper et coller L'URL hors de la barre d'emplacement, et vous pourrez probablement ne pas mettre des informations confidentielles là-dedans qui peuvent être vus par quiconque regarde 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 y avait seulement 2 pages sur un site, une beaucoup plus grande que l'autre, alors la comparaison de la taille du transfert de données indiquerait quelle page vous avez visitée. Il y a des façons de le cacher à la tierce partie, mais ce n'est pas un comportement normal du serveur ou du navigateur. Voir, par exemple, ce papier de SciRate, https://scirate.com/arxiv/1403.0297 .

en général, les autres réponses sont correctes, pratiquement bien que ce papier montre que les pages visitées (C'est-à-dire L'URL) peuvent être déterminées assez efficacement.

"151900920 de" Liant " à ma réponse sur un double question . Non seulement L'URL est disponible dans l'historique des navigateurs, mais elle est aussi envoyée sous forme D'en-tête HTTP Referer qui, si vous utilisez du contenu tiers, expose l'URL à des sources hors de votre contrôle.

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 comme votre PC d'entreprise sont configurés avec un certificat racine supplémentaire "de confiance" de sorte que votre navigateur peut tranquillement faire confiance à un proxy (man-in-the-middle) inspection du trafic https. Cela signifie que L'URL complète est exposée pour inspection. C'est généralement enregistrés dans un journal.

en outre, vos mots de passe sont également exposés et probablement connecté et c'est une autre raison d'utiliser les mots de passe ou de changer vos mots de passe fréquemment.

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

un exemple du système d'inspection est décrit par Check Point here . Un "cybercafé" de style ancien utilisant des PC fournis peut également être mis en place de cette manière.

bien qu'il y ait déjà de bonnes réponses ici, la plupart d'entre elles se concentrent sur la navigation par navigateur. J'écris ceci en 2018 et quelqu'un veut probablement 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 sécurisé . iOS ou Android vérifiera le certificat et d'atténuer les éventuelles attaques MiM (qui serait être le seul point faible dans tout cela). Vous pouvez envoyer des données sensibles par le biais de connexions HTTPS qu'il sera crypté pendant le transport . Juste votre application et le serveur connaîtront tous les paramètres envoyés par https.

le seul" peut-être " ici serait si le client ou le serveur sont infectés 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 genre de logiciel, il aura accès aux données, non peu importe ce que vous utilisez pour le transporter.

de plus, si vous construisez une API ReSTful, les fuites de navigateur et les problèmes de http referer sont généralement atténués car le client peut ne pas être un navigateur et vous pouvez ne pas avoir de personnes cliquant sur les liens.

si c'est le cas, je recommande l'ouverture de session oAuth2 pour obtenir un jeton porteur. Les seules données sensibles serait l'initiale d'identification...qui devrait probablement être dans une demande de poste de toute façon