Czy SSL szyfruje URL-e?

08 czerwca 2018, 09:40 | Teksty | komentarzy 19
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.

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

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Posypka

    Krótko, zwięźle i na temat – to mi się podoba! :)

    Odpowiedz
  2. tmk

    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.

    Odpowiedz
    • Jan

      Czyli jeżeli mamy zablokowany youtube.com a wejdziemy na nieblokowany youtu.be to youtube.com będzie działał?

      Odpowiedz
      • tmk

        Nie będzie. Zauważ że youtu.be przekierowuje na youtube.com.

        Odpowiedz
  3. Marcin

    Fajny art. ;)

    Odpowiedz
  4. aaa

    W TLS 1.3 SNI jest encrypted czy nie?

    Odpowiedz
  5. Fabian

    Zatem można powiedzieć że TLS/SSL zapewnia poufność ale nie prywatność?

    Odpowiedz
    • Jacek

      Tylko nazwa serwera (domena, nie cały url) jest zdradzana przy nawiązywaniu połączeń, reszta danych jest zabezpieczona przed podsłuchaniem i podmianą.

      Odpowiedz
  6. Michal

    Konkretnie i na temat. Super

    Odpowiedz
  7. 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ć.

    Odpowiedz
  8. ktoś

    czyli jak wchodzę na redtuba to mój provider nie zobaczy jakie kategorie przeglądam i jakie filmiki?

    Odpowiedz
  9. jaaaaaa

    czyli jak wchodzę na redtuba to mój provider nie zobaczy jakie kategorie przeglądam i jakie filmiki?

    Odpowiedz
  10. Jarek

    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ć.

    Odpowiedz
  11. adrb

    Nazwa domeny w SNI to nie jest URL. Co ważniejsze, nie musi nawet być zgodna z nagłówkiem Host w zapytaniu.

    Odpowiedz
    • czy ktoś twierdzi w tekście że SNI to URL? :)

      Odpowiedz
      • adrb

        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ć.

        Odpowiedz
        • Milaczek

          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.

          Odpowiedz
  12. 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.

    Odpowiedz

Odpowiedz