Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Czy SSL szyfruje URL-e?
Proste pytanie: „czy SSL szyfruje URL-e?” i prosta odpowiedź: tak. Nieco bardziej rozbudowane rozważania w tym temacie – poniżej.
Zacznijmy od samego początku, czyli tego jak nawiązywane jest połączenie SSL/TLS. Proces ten nosi nazwę TLS handshake i odpowiada za nawiązanie bezpiecznego połączenia po wymianie kluczy publicznych między klientem a serwerem. Poglądowo wszystko zachodzi w taki sposób jak na Rysunku nr 1.
Rysunek nr 1 ( źródło: http://blog.gauravkansal.in/2015/09/tls-handshake.html)
Po wykonaniu TCP handshake ustanawiane jest bezpieczne połączenie pomiędzy klientem a serwerem.
Załóżmy, że chcemy się połączyć z https://www.google.com, zobaczmy jak ta komunikacja wygląda w Wiresharku (pominiemy tutaj początkową fazę czyli TCP handshake, dla zainteresowanych zostało to opisane w początkowej części tego artykułu).
Najpierw komputer wysyła na wybrany adres IP wiadomość Client Hello, która zawiera wszystkie początkowe parametry oraz daje znać serwerowi, że chce nawiązać połączenie TLS/SSL (Rysunek nr 2).
Rysunek nr 2
Następnie serwer odpowiada na zapytanie klienta wiadomością Server Hello widoczną przy pakiecie numer 10 na Rysunku nr 2. Serwer wysyła certyfikat z kluczem publiczny oraz potrzebne sygnatury jak na Rysunku nr 3.
Rysunek nr 3
Ostatnim krokiem jest wiadomość od klienta w której wysyła on wygenerowany klucz symetryczny, zaszyfrowany kluczem publicznym serwera, a na samym końcu przesyłana jest pierwsza zaszyfrowana wiadomość (na rysunku powyżej ‘Encrypted Handshake Message’).
Po wykonaniu tych kroków cały ruch przesyłany między klientem a serwerem jest szyfrowany.
Gdzie i dlaczego pojawią się wątpliwości na temat szyfrowania URL?
Gdy przejrzymy wszystkie informacje zawarte w Client Hello, natkniemy się na dość podejrzany fragment, który widzimy na Rysunku nr 4.
Rysunek nr 4
W tym wypadku nazwa serwera nie jest szyfrowana, dlaczego?
Otóż większość nowoczesnych przeglądarek używa Server Name Indication, czyli w trakcie nawiązywania połączenia wysyła nieszyfrowaną nazwę serwera, tzw. FQDN. Jak to wygląda w praktyce?
Wyobraźmy sobie, że chcemy nawiązać bezpieczne połączenie na adres sekurak.pl/tajne/hasła jak na Rysunku nr 5.
Rysunek nr 5
W takim wypadku sekurak.pl (część zaznaczona na czerwono) zostanie wysłana w Client Hello jako SNI, natomiast cała reszta URLa (zielona część) zostanie wysłana dopiero po nawiązaniu bezpiecznego połączenia.
Oto cała filozofia z szyfrowaniem URLi przez SSL, mamy nadzieję że teraz będzie to jasne i zrozumiałe dla wszystkich naszych czytelników.
–Michał Wnękowicz
Krótko, zwięźle i na temat – to mi się podoba! :)
Wypada dodać po co to SNI wogóle jest potrzebne.
Gdy przeglądarka zestawia połączenie z serwerem, to on jeszcze nie wie o jaką stronę zostanie poproszony, a już w tym momencie musi przedstawić poprawny certfikat dla domeny. Na serwerze może znajdować się wiele stron internetowych, dlatego przeglądarka wysyła mu wcześniej nazwę domeny o którą będzie żądać w HTTP.
Krótko mówiąc, cały protokół HTTP jest zaszyfrowany (URL, wszystkie nagłówki, ciastka, treść strony), ale nazwa domeny jest widoczna dla analizujących pakiety. Widoczna jest w SNI i widoczna jest w certyfikacie którym przedstawia się serwer.
Dlatego możliwe jest blokowanie dostępu do witryn internetowych po HTTPS na podstawie domen a nie adresów IP.
Czyli jeżeli mamy zablokowany youtube.com a wejdziemy na nieblokowany youtu.be to youtube.com będzie działał?
Nie będzie. Zauważ że youtu.be przekierowuje na youtube.com.
A jak sprawdzić, że ciasteczka są faktycznie szyfrowane?
Fajny art. ;)
W TLS 1.3 SNI jest encrypted czy nie?
ma być
https://tools.ietf.org/html/draft-rescorla-tls-esni-00
Zatem można powiedzieć że TLS/SSL zapewnia poufność ale nie prywatność?
Tylko nazwa serwera (domena, nie cały url) jest zdradzana przy nawiązywaniu połączeń, reszta danych jest zabezpieczona przed podsłuchaniem i podmianą.
Konkretnie i na temat. Super
Zupełnie niezwiązane z SSL, ale patrząc całościowo warto jeszcze pamiętać, że domena (tu: sekurak.pl) i tak będzie przesłana w nieszyfrowanym (99% przypadków) zapytaniu DNS, które atakujący prawdopodobnie także jest w stanie podsłuchać.
czyli jak wchodzę na redtuba to mój provider nie zobaczy jakie kategorie przeglądam i jakie filmiki?
czyli jak wchodzę na redtuba to mój provider nie zobaczy jakie kategorie przeglądam i jakie filmiki?
Hah, dobre pytanie, bo podchwytliwe ;-)
Tak, HTTPS szyfruje URL w opisany sposób. Nie, nie znaczy to, że możemy zacząć przesyłać w URL numery kart kredytowych, ponieważ URL istnieje także poza połączeniem HTTPS. URL będzie zapisywany w logach serwera docelowego i serwerów proxy, w historii przeglądarki oraz jest dostępny dla JavaScript, a więc i dla XSS.
Czyli: URL https:// na pewnym etapie swojego życia będzie przesyłany połączeniem szyfrowanym. Ale to nie znaczy, że wszelkie dane zawarte w URL są poufne. Ale odpowiadając na wcześniejsze pytanie, ISP nie może ich odczytać.
Nazwa domeny w SNI to nie jest URL. Co ważniejsze, nie musi nawet być zgodna z nagłówkiem Host w zapytaniu.
czy ktoś twierdzi w tekście że SNI to URL? :)
Pewnie co druga osoba czytająca ten artykuł takie właśnie odniosła wrażenie. To zdanie przy końcu jest bardzo nie precyzyjne – jak w sumie większość artykułu, zaczynając od samego tytułu:
„W takim wypadku sekurak.pl (część zaznaczona na czerwono) zostanie wysłana w Client Hello jako SNI, natomiast cała reszta URLa (zielona część) zostanie wysłana dopiero po nawiązaniu bezpiecznego połączenia.”
Niby nie istotne, a jednak w artykule wymieszany został SSL z HTTP i zapewne namiesza to w głowach ludzi którzy chcieliby się czegoś dowiedzieć.
Pierwsza naczelna zasada Internetu, nalezy weryfikowac kazda a kazda informacje. Czytam na sekuraku a nastepnie zglebiam i weryfikuje w innym miejscu. Jezeli ktos swoja wiedze opiera tylko na jedym zrodle to w mojej ocenie nie chce poszerzyc swojej wiedzy. A tylko liznac temat zeby miec blade pojecie.
Warto jeszcze pamiętać, że opisane zachowanie dotyczy przypadku, gdy klient inicjuje połączenie HTTPS. Jeśli klient spróbuje połączyć się po HTTP i na HTTPS przekieruje go serwer, to URL da się podsłuchać, mimo że finalnie łączymy się po SSL. Detal, ale w praktyce sytuacja dość często spotykana.
A jak proces przebiega przy wykorzystaniu VPN?
Korzystnie :D
A google jak może to połączy się przez QUIC
Czy SSL szyfruje także adres IP serwera przy połączeniu po protokole https ?
Przy założeniu że serwer ma wykupioną nazwę domenowa i certyfikat ssl.
nie, adres IP jest widoczny jawnie na poziomie… protokołu IP :)
Szkoda, że nie napisaliście o ESNI
„Ostatnim krokiem jest wiadomość od klienta w której wysyła on wygenerowany klucz symetryczny, zaszyfrowany kluczem publicznym serwera”
Jesli Mamy Diffie-Hellmana (jak w tym przypadku) to nie powinno mowic sie o wyslaniu zaszyfrowanego klucza, a protokole uzgodniania klucza. Klucz symetryczny obliczany jest po stronie klienta i servera niezaleznie. Zapewnia to utajnianie z wyprzedzeniem w przypadku kompromitacji klucza prywatnego (nie mozna odszyfrowac komunikacji wstecz)
w trakcie korzystania z przeglądarki Tor wygląda to tak samo?