Czy wszystkie adresy URL są szyfrowane podczas korzystania z szyfrowania TLS / SSL (HTTPS)? Chciałbym wiedzieć, ponieważ chcę, aby wszystkie dane URL były ukryte podczas korzystania z TLS / SSL (HTTPS).

Jeśli TLS / SSL zapewnia całkowite szyfrowanie adresów URL, nie muszę się martwić ukrywaniem poufnych informacji przed adresami URL.

Tak, połączenie SSL odbywa się między warstwą TCP a warstwą HTTP. Klient i serwer najpierw ustanawiają bezpieczne szyfrowane połączenie TCP (za pośrednictwem protokołu SSL / TLS), a następnie klient wyśle ​​żądanie HTTP (GET, POST, DELETE ...) za pośrednictwem tego szyfrowanego połączenia TCP.

Ponieważ nikt nie przewidział przechwytywania drutu, oto jeden.
Nazwa serwera (część domeny adresu URL) jest prezentowana w ClientHellopakiecie zwykłym tekstem .

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

Zobacz tę odpowiedź, aby uzyskać więcej informacji na temat pól wersji TLS (są 3 z nich - nie wersje, pola, które zawierają numery wersji!)

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

3.1 Wskazanie nazwy serwera

[TLS] nie zapewnia klientowi mechanizmu informowania serwera o nazwie serwera, z którym się kontaktuje. Może być pożądane, aby klienci dostarczali te informacje, aby ułatwić bezpieczne połączenia z serwerami, które obsługują wiele „wirtualnych” serwerów pod jednym podstawowym adresem sieciowym.

Aby podać nazwę serwera, klienci MOGĄ zawierać rozszerzenie typu „nazwa_serwera” w (rozszerzonym) halo klienta.

W skrócie:

• FQDN (część domeny URL) MOGĄ być przekazywane w jasny wewnątrz ClientHellopakietu, jeśli jest stosowany rozszerzenie SNI

• Pozostała część adresu URL ( /path/?some=parameters&go=here) nie ma żadnego interesu, ClientHelloponieważ adres URL żądania jest rzeczą HTTP (OSI Layer 7), dlatego nigdy nie pojawi się w uzgadnianiu TLS (warstwa 4 lub 5). To przyjdzie później w GET /path/?some=parameters&go=here HTTP/1.1żądaniu HTTP, PO ustanowieniu bezpiecznego kanału TLS.

STRESZCZENIE

Nazwa domeny MOŻE być przesyłana w postaci jawnej (jeśli rozszerzenie SNI jest używane w uzgadnianiu TLS), ale adres URL (ścieżka i parametry) jest zawsze szyfrowany.

AKTUALIZACJA MARCA 2019

Dziękujemy carlin.scott za podniesienie tego.

Ładunek w rozszerzeniu SNI można teraz zaszyfrować za pomocą tej propozycji projektu RFC . Ta funkcja istnieje tylko w TLS 1.3 (jako opcja i jej implementacja zależy od obu końców) i nie ma wstecznej kompatybilności z TLS 1.2 i niższymi.

CloudFlare to robi i możesz przeczytać więcej o wewnętrznych elementach tutaj - jeśli kurczak musi przyjść przed jajkiem, gdzie go umieszczasz?

W praktyce oznacza to, że zamiast przesyłać FQDN w postaci zwykłego tekstu (jak pokazuje program przechwytujący Wireshark), jest on teraz szyfrowany.

UWAGA: Dotyczy to bardziej kwestii prywatności niż bezpieczeństwa, ponieważ odwrotne wyszukiwanie DNS MOŻE ujawnić docelowego hosta docelowego.

Jak już wskazały inne odpowiedzi , „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 korzystasz z przeglądarki, twoje adresy URL mogą być również rejestrowane.

Całe żądanie i odpowiedź są szyfrowane, w tym adres URL.

Pamiętaj, że gdy używasz serwera proxy HTTP, zna on 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:

Mówiąc wprost:

W przypadku TLS pierwsza część adresu URL ( https://www.example.com/ ) jest nadal widoczna podczas budowania połączenia. Druga część (/ herearemygetparameters / 1/2/3/4) jest chroniona przez TLS.

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

Po pierwsze, jak już wspomniano przez innych: - wyciek przez pasek adresu przeglądarki - wyciek przez historię

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

Dodatek do pomocnej odpowiedzi od Marca Novakowskiego - adres URL jest przechowywany w dziennikach na serwerze (np. W / etc / httpd / logs / ssl_access_log), więc jeśli nie chcesz, aby serwer dłużej przechowywał informacje nie umieszczaj go w adresie URL.

Tak i nie.

Część adresu serwera NIE jest szyfrowana, ponieważ służy do konfigurowania połączenia.

Może to ulec zmianie w przyszłości w przypadku zaszyfrowanego SNI i DNS, ale od 2018 r. Obie technologie nie są powszechnie używane.

Ścieżka, ciąg zapytania itp. Są szyfrowane.

Uwaga dla żądań GET użytkownik nadal będzie mógł wyciąć i wkleić adres URL poza pasek lokalizacji i prawdopodobnie nie będziesz chciał umieszczać w nim poufnych informacji, które będą widoczne dla każdego, kto patrzy na ekran.

Strona trzecia monitorująca ruch może również być w stanie określić odwiedzaną stronę, badając ruch i porównując go z ruchem innego użytkownika podczas odwiedzania witryny. Na przykład, jeśli w witrynie były tylko 2 strony, jedna znacznie większa od drugiej, porównanie wielkości transferu danych powiedziałoby, którą stronę odwiedziłeś. Istnieją sposoby, w jakie można to ukryć przed firmami zewnętrznymi, ale nie są to normalne zachowania serwera lub przeglądarki. Zobacz na przykład ten artykuł SciRate, https://scirate.com/arxiv/1403.0297 .

Zasadniczo inne odpowiedzi są poprawne, praktycznie jednak ten dokument pokazuje, że odwiedzone strony (np. URL) można dość skutecznie określić.

Nie zawsze możesz liczyć na prywatność pełnego adresu URL. Na przykład, jak to czasami bywa 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ć inspekcji proxy (man-in-the-middle) ruchu https . Oznacza to, że pełny adres URL jest udostępniany do kontroli. Zazwyczaj jest to zapisywane w dzienniku.

Co więcej, twoje hasła są również ujawnione i prawdopodobnie zarejestrowane, a to kolejny powód, aby używać haseł jednorazowych lub często je zmieniać.

Wreszcie treść żądania i odpowiedzi jest również ujawniana, jeśli nie jest w inny sposób szyfrowana.

Jeden przykład konfiguracji inspekcji opisano tutaj przez Checkpoint . W ten sposób można również skonfigurować „kafejkę internetową” w starym stylu z wykorzystaniem dostarczonych komputerów.

Link do mojej odpowiedzi na zduplikowane pytanie . Adres URL jest nie tylko dostępny w historii przeglądarek, dzienniki po stronie serwera, ale jest również wysyłany jako nagłówek odsyłacza HTTP, który, jeśli korzystasz z treści stron trzecich, udostępnia adres URL źródłom poza Twoją kontrolą.

Jest teraz 2019, a TLS v1.3 został wydany. Według Cloudflare SNI może być szyfrowany dzięki TLS v1.3. Więc powiedziałem sobie świetnie! zobaczmy, jak to wygląda w pakietach TCP cloudflare.com. Tak więc złapałem pakiet uścisku dłoni „klient cześć” z odpowiedzi serwera cloudflare używającego Google Chrome jako przeglądarki i wireshark jako sniffera pakietów. Nadal mogę odczytać nazwę serwera w postaci zwykłego tekstu w pakiecie hello klienta.

Uważaj więc na to, co możesz przeczytać, ponieważ nadal nie jest to anonimowe połączenie. Oprogramowanie pośrednie między klientem a serwerem może rejestrować każdą domenę żądaną przez klienta.

Wygląda więc na to, że szyfrowanie SNI wymaga dodatkowych implementacji do współpracy z TLSv1.3

W poniższym artykule opisano szyfrowanie SNI zapewnianego przez Cloudflare jako część TLSv1.3. Jednak wszystkie adresy URL HTTPs z cloudflare.com są w postaci zwykłego tekstu w pakiecie TCP w TLS 1.3

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

Tak i nie.

Rzeczywisty adres URL jest szyfrowany, co oznacza, że ​​ktoś nie może podać dokładnej strony w odwiedzanej witrynie. Jednak nagłówek TLS zawiera nazwę hosta serwera, do którego uzyskujesz dostęp (np. Www.quora.com) niezaszyfrowanego. DNS prawie nigdy nie jest szyfrowany, a także wyciek nazwy hosta, do którego masz dostęp. To zapytanie DNS prawie zawsze jest domyślnie skierowane przeciwko serwerom twojego dostawcy usług internetowych, dzięki czemu mogą łatwo zobaczyć nazwę hosta każdej witryny, do której masz dostęp, poprzez wąchanie twoich żądań DNS do innych serwerów DNS lub nagrywanie twoich na własne.

Jeśli jednak zastanawiasz się, czy ktoś może dowiedzieć się, do której witryny korzystasz, to nie wystarczy. HTTPS działa w warstwie OSI 4 i szyfruje wszystkie dane na tym poziomie, ale niższe poziomy są pozostawione sieciom, które je przenoszą. Ktoś nadal może po prostu prześledzić ścieżkę i miejsce docelowe ruchu w warstwie OSI 3. Oznacza to, że ktoś wąchający ruch może znaleźć adres IP i rozszerzenie nazwy domeny witryny, do której miałeś dostęp.

Co gorsza, po raz pierwszy (i kilka kolejnych razy, w zależności od tego, jak / kiedy pamięć podręczna DNS zostanie wyczyszczona) prawdopodobnie wyślesz niezaszyfrowane zapytanie DNS na dowolny serwer DNS, który zażąda adresu IP docelowego adresu URL HTTPS (ponownie przez domyślnie zazwyczaj serwery twojego dostawcy usług internetowych). Każdy, kto ma dostęp do twojego ruchu na ścieżce do twojego serwera DNS, może być w stanie wąchać to zapytanie.

Jeśli szukasz wysokiego standardu prywatności, musisz uzupełnić HTTPS o zaufaną szyfrowaną sieć VPN i / lub szyfrowaną usługę proxy. Możesz także zajrzeć do DNSSEC, aby chronić swoje zapytania DNS. Ta usługa musi być godna zaufania, ponieważ może łatwo wykonać powyższe śledzenie źródeł i miejsc docelowych ruchu.

Chociaż istnieją już dobre odpowiedzi, większość z nich koncentruje 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 aplikacja), o ile korzystasz z HTTPS , jesteś bezpieczny . iOS lub Android zweryfikują certyfikat i złagodzą ewentualne ataki MiM (byłby to jedyny słaby punkt tego wszystkiego). Możesz przesyłać poufne dane za pośrednictwem połączeń HTTPS, które zostaną zaszyfrowane podczas transportu . Tylko Twoja aplikacja i serwer będą znać wszelkie parametry wysyłane przez https.

Jedynym „być może” byłoby to, gdyby klient lub serwer został zainfekowany złośliwym oprogramowaniem, które może zobaczyć dane przed ich opakowaniem w https. Ale jeśli ktoś zostanie zainfekowany tego rodzaju oprogramowaniem, będzie miał dostęp do danych, bez względu na to, czego użyjesz do ich transportu.

Ponadto, jeśli budujesz interfejs ReSTful API, problemy z wyciekami z przeglądarki i odsyłaczem HTTP są w większości łagodzone, ponieważ klient może nie być przeglądarką i nie możesz klikać linków.

W takim przypadku zaleciłbym logowanie oAuth2, aby uzyskać token nośnika. W takim przypadku jedynymi wrażliwymi danymi byłyby początkowe dane uwierzytelniające ... które prawdopodobnie powinny znajdować się w żądaniu przesłanym

Chociaż masz już bardzo dobre odpowiedzi, naprawdę podoba mi się wyjaśnienie na tej stronie: https://https.cio.gov/faq/#what-information-does-https-protect

w skrócie: używając ukrytych HTTPS:

• Metoda HTTP
• parametry zapytania
• Treść POST (jeśli jest obecna)
• Żądaj nagłówków (w tym pliki cookie)
• Kod statusu