Ponieważ nikt nie dostarczył podsłuchu, oto jeden.
Nazwa serwera (domenowa część adresu URL) jest przedstawiona w pakiecie ClientHello, w zwykłym tekście.

Poniżej przedstawiono żądanie przeglądarki do:
https://i.stack.imgur.com/path/?some=parameters&go=here

zobacz tę odpowiedź aby dowiedzieć się więcej o polach wersji TLS (są ich 3 - nie wersje, pola, z których każde zawiera numer wersji!)

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

3.1. Oznaczenie Nazwy Serwera

[TLS] nie zapewnia mechanizmu dla klienta, aby powiedzieć serwerowi nazwa serwera, z którym się kontaktuje.[[9]} może być pożądane dla klientów, aby dostarczyć te informacje w celu ułatwienia bezpiecznego połączenia z serwerami, które obsługują wiele "wirtualnych" serwerów w pojedynczy bazowy adres sieciowy.

Aby podać nazwę serwera, klienci mogą zawierać rozszerzenie typu "server_name" w (extended) Witaj kliencie.

W skrócie:

• FQDN (domain part of the URL) MAY be transmitted in clear inside the ClientHello packet if SNI extension is used

• Reszta adresu URL (/path/?some=parameters&go=here) nie ma prawa znajdować się wewnątrz ClientHello, ponieważ adres URL żądania jest elementem HTTP (warstwa 7 OSI), dlatego nigdy nie pojawi się w uścisku dłoni TLS (warstwa 4 lub 5). To nastąpi później w GET /path/?some=parameters&go=here HTTP/1.1 żądanie HTTP, po zabezpieczony kanał TLS został ustanowiony.

STRESZCZENIE

Nazwa domeny może być przesyłana w sposób jasny (jeśli rozszerzenie SNI jest używane w uścisku dłoni TLS), ale adres URL (Ścieżka i Parametry) jest zawsze szyfrowany.

Jako inne odpowiedzi już zwróciły uwagę, "adresy URL" https są rzeczywiście szyfrowane. Jednak twoje żądanie/odpowiedź DNS podczas rozwiązywania nazwy domeny prawdopodobnie nie jest, i oczywiście, jeśli używasz przeglądarki, Twoje adresy URL mogą być również rejestrowane.

Całe żądanie i odpowiedź są szyfrowane, łącznie z adresem URL.

Zauważ, że gdy używasz serwera proxy HTTP, to ten serwer zna adres (domenę) serwera docelowego, ale nie zna żądanej ścieżki na tym serwerze (tzn. żądanie i odpowiedź są zawsze szyfrowane).

Zgadzam się z poprzednimi odpowiedziami:

Być jednoznaczne:

Z TLS, pierwsza część URL ( https://www.example.com/) jest nadal widoczny podczas budowania połączenia. Druga część (/herearemygetparameters/1/2/3/4) jest chroniony przez TLS.

Istnieje jednak wiele powodów, dla których nie należy umieszczać parametrów w żądaniu GET.

Po pierwsze, jak już wspominali inni: - wyciek przez pasek adresu przeglądarki - wyciek przez Historia

Oprócz tego masz wyciek adresu URL przez referer http: użytkownik widzi witrynę A na TLS, a następnie klika link do witryny B. Jeśli obie witryny są na TLS, żądanie do witryny B będzie zawierać pełny adres URL z witryny a w parametrze referer żądania. A admin ze strony B może pobrać go z plików dziennika serwera B.)

Dodatek do pomocnej odpowiedzi od marca Nowakowskiego-adres URL jest przechowywany w logach na serwerze (np. w /etc/httpd/logs / ssl_access_log), więc jeśli nie chcesz, aby serwer przechowywał informacje przez dłuższy czas, nie umieszczaj go w adresie URL.

Tak i nie.

Część adresu serwera nie jest szyfrowana, ponieważ jest używana do skonfigurowania połączenia.

Może się to zmienić w przyszłości w przypadku szyfrowanego SNI i DNS, ale od 2018 r. obie technologie nie są powszechnie używane.

Ścieżka, ciąg zapytania itp. są zaszyfrowane.

Uwaga dla żądań GET użytkownik nadal będzie mógł wyciąć i wkleić adres URL z paska lokalizacji i prawdopodobnie nie będziesz chciał umieszczać tam poufnych informacji, które mogą być widoczne przez każdy, kto patrzy na ekran.

Osoba trzecia, która monitoruje ruch, może również określić odwiedzaną stronę, badając Twój ruch i porównując go z ruchem, jaki ma inny użytkownik podczas odwiedzania witryny. Na przykład, jeśli w witrynie były tylko 2 strony, jedna znacznie większa niż druga, porównanie rozmiaru transferu danych wskazywałoby, którą stronę odwiedziłeś. Istnieją sposoby, że można to ukryć przed osobami trzecimi, ale nie są to normalne zachowanie serwera lub przeglądarki. Zobacz na przykład Ten artykuł od SciRate, https://scirate.com/arxiv/1403.0297 .

Ogólnie inne odpowiedzi są poprawne, praktycznie chociaż ten artykuł pokazuje, że odwiedzane strony (czyli URL) można określić dość skutecznie.

Linkowanie do mojej odpowiedzi na duplikat pytania . Nie tylko adres URL jest dostępny w historii przeglądarek, dzienniki po stronie serwera, ale jest również wysyłany jako nagłówek Referer HTTP, który jeśli używasz treści innych firm, naraża adres URL do źródeł poza Twoją kontrolą.

Nie zawsze możesz liczyć na prywatność pełnego adresu URL. Na przykład, jak czasami ma to miejsce w sieciach korporacyjnych, dostarczone urządzenia, takie jak komputer firmowy, są skonfigurowane z dodatkowym "zaufanym" certyfikatem głównym, dzięki czemu przeglądarka może spokojnie zaufać proxy (man-in-the-middle) kontroli ruchu https. Oznacza to, że pełny adres URL jest wystawiony do wglądu. Jest to zwykle zapisywane w dzienniku.

Ponadto Twoje hasła są również ujawnione i prawdopodobnie zalogowane, a to jest kolejny powód, aby używać haseł jednorazowych lub często zmieniać hasła.

Wreszcie, zawartość żądania i odpowiedzi jest również ujawniona, jeśli nie jest zaszyfrowana w inny sposób.

Jeden przykład konfiguracji kontroli jest opisany przez tutaj. W ten sposób można również skonfigurować starą "kawiarenkę internetową" wykorzystującą dostarczone Komputery PC.

Chociaż istnieją już dobre odpowiedzi, większość z nich skupia się na nawigacji w przeglądarce. Piszę to w 2018 roku i prawdopodobnie ktoś chce wiedzieć o bezpieczeństwie aplikacji mobilnych.

W przypadku aplikacji mobilnych, jeśli kontrolujesz oba końce aplikacji (serwer i aplikację), tak długo, jak używasz HTTPS , jesteś bezpieczny. iOS lub Android zweryfikuje certyfikat i złagodzi ewentualne ataki MiM (to byłby jedyny słaby punkt w tym wszystkim). Możesz wysłać dane wrażliwe poprzez połączenia HTTPS, które zostaną zaszyfrowane podczas transportu. Tylko Twoja aplikacja i serwer będą znać wszelkie parametry wysyłane przez https.

Jedynym "może" tutaj byłoby, jeśli klient lub serwer są zainfekowane złośliwym oprogramowaniem, które może zobaczyć dane, zanim zostaną zawinięte w https. Ale jeśli ktoś jest zainfekowany tego rodzaju oprogramowaniem, będzie miał dostęp do danych, bez względu na to, czego użyjesz do ich transportu.

DODATKOWO, jeśli budujesz interfejs API ReSTful, wyciek przeglądarki i problemy z refererami http są w większości łagodzone, ponieważ klient może nie być przeglądarką i możesz nie mieć osób klikających linki.

W takim przypadku polecam logowanie oAuth2, aby uzyskać token na okaziciela. W takim przypadku jedynymi wrażliwymi danymi będą początkowe poświadczenia...które i tak powinno być w zapytaniu post