HSTS czyli HTTP Strict Transport Security

30 sierpnia 2013, 09:57 | Teksty | komentarzy 7
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.
W kolejnym odcinku opisującym nagłówki HTTP związane z bezpieczeństwem webowym skupimy się na HSTS czyli HTTP Strict Transport Security. Wcześniej pisaliśmy o fladze cookie – HttpOnly

Protokół HTTP nigdy nie był projektowany z myślą o bezpieczeństwie. W czasie, kiedy powstawały jego pierwsze wersje, z sieci komputerowych korzystały naukowe ośrodki obliczeniowe i paru naukowców. W aktualnej wersji 1.1 także nic w tym obszarze nie zmieniono. Wynikiem tego jest sytuacja, że do transmisji danych używany jest czysty tekst. W skrócie oznacza to, że atakujący jest w stanie przeprowadzić atak Man-in-the-Middle (MitM), tzn. podglądać oraz modyfikować w locie całą transmisję. W tym celu może się posłużyć narzędziem Ettercap. Przykładowo zatrucie tablic ARP na hoście i routerze mogłoby wyglądać tak:

W tym momencie cały ruch przechodzi przez atakującego, który ma w niego pełen wgląd.

Z powyższych powodów tak istotne jest używanie wersji HTTPS, czyli tunelowania protokołu HTTP w SSL/TLS. Nota bene zalecane jest używanie wersji TLS 1.1 lub 1.2, ponieważ starsze wersje posiadają liczne błędy. Szyfrowanie znacząco ogranicza możliwości atakującego w zakresie podglądania informacji o sesji lub jej modyfikacji.

 

W czym więc może pomóc nagłówek Strict-Transport-Security, skoro jesteśmy już chronieni przez szyfrowanie TLS?

Aby odpowiedzieć na to pytanie, musimy zobaczyć, co się dzieje, gdy użytkownik wchodzi na stronę np. banku przez HTTP. W tym momencie serwer wysyła przekierowanie (przy pomocy odpowiedzi 301) na wersje zabezpieczoną HTTPS.

Wygląda to tak jak na poniższym schemacie.

sekurak - redirect - Kopia

W sytuacji, kiedy ktoś przeprowadza atak typu MiTM, atakujący stara się ulokować pomiędzy klientem a serwerem.

Może to wyglądać tak:

sekurak - mitm - Kopia

Inną sytuacją jest atak, w którym klient posługuje się SSL-em, ale atakujący, np. przy pomocy narzędzi SSLStrip, jest w stanie zmusić przeglądarkę użytkownika do komunikacji czystym tekstem. W tym samym czasie komunikacja atakująca docelowy serwer odbywa się kanałem szyfrowanym.

Rozwiązaniem tych problemów ma być propozycja nagłówka Strict-Transport-Security, który pojawił się w RFC 6797. Działa on tak, że jeżeli przeglądarka zobaczy, że witryna wysyła ten nagłówek, to przez czas określony w nagłówku cała komunikacja będzie się odbywać po HTTPS. Jest to działanie na poziomie przeglądarki, więc jeżeli użytkownik z niewiedzy lub przez roztargnienie będzie próbował połączyć się z wersją HTTP, to przeglądarka automatycznie podmieni jego zapytanie na HTTPS oraz zmieni wszystkie występujące na stronie linki na HTTPS.

Podobnie jak w we wspomnianym już artykule o Fladze HttpOnly, posłużę się przechwyconą odpowiedzią od Googla:

Widać, że zwracany jest nagłówke Strict-Transport-Security z czasem trwania 2.592.000 sekund. Dodatkowo przeglądarka informowana jest, że ma używać tego ustawienia dla wszystkich poddomen domeny google.com.  Pojawia się jednak problem: użytkownik przy pierwszym połączeniu do serwera nie jest chroniony. Jego przeglądarka dopiero po zobaczeniu nagłówka wie, jak ma się dalej zachowywać. Pozostawia to lukę w bezpieczeństwie…

Dostawcy przeglądarek starają się rozwiązać ten problem przez zastosowanie tego samego podejścia jak przy certyfikatach CA. Istnieje wbudowana w program lista stron, dla których nagłówek HSTS jest już ustawiony. Oczywiście niemałą trudność sprawia skalowalność, choć rozwiązaniem mogłaby tu być jakaś forma integracji z usługą DNSsec.

Kolejnym problem rozwiązywanym przez HSTS jest „Click-Through Insecurity”, który oznacza sytuację, w której użytkownik, widząc ostrzeżenie o nieważności certyfikatu, klika „ignoruj” lub „dalej”. Dzieje się tak dlatego, że użytkownicy albo nie zdają sobie sprawy z istniejącego zagrożenia lub są przyzwyczajeni do certyfikatów typu self-signed. W przypadku kiedy używany jest nagłówek HSTS, użytkownik nie dostanie monitu o możliwości zignorowania tego typu sytuacji, przeglądarka po prostu poinformuje o błędzie.

sekurak - hsts - Kopia

Włączenie tego zabezpieczenia jest bardzo proste, ponieważ ogranicza się do ustawienia w konfiguracji webserwera wysyłania odpowiedniego nagłówka. W serwerze Apache można to zrobić, wydając poniższą dyrektywę:

 

W mojej opinii warto stosować tego typu zabezpieczenie, ponieważ dość niskim nakładem prac jesteśmy w stanie podnieść bezpieczeństwo naszej strony. Ponadto rozwiązania webowe zmierzają w kierunku szyfrowania całej transmisji, co najlepiej widać na przykładzie protokołu SPDY, który m.in. zakłada tylko komunikację przy użyciu SSL-a. SPDY stał się bazą dla draftu specyfikacji http 2.0.

 

Piotr Bratkowski  (Piotrek.Bratkowski<at>gmail.com)

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



Komentarze

  1. Na obrazku „sekurak-mitm-Kopia”, na trasie serwer -> MitM powinno chyba być jak wyżej HTTP 301

    A do czasu jak nie zostanie to jakoś rozbudowane, to nadal MitM skutecznie może po drodze nagłówki wycinać.

    Odpowiedz
  2. Piotr Bratkowski

    Może, ale tylko pod warunkiem, że atakującemu uda się wyczyścić ten nagłówek ZANIM użytkownik po raz pierwszy wejdzie na stronę. Potem biorąc przykład z tekstu jest chroniony przez 2.592.000 sekund, ponieważ to jest to wymuszane po stronie przeglądarki.

    Odpowiedz
  3. Wszystko byłoby w tym tekście fajnze za wyjątkiem jednej kwestii. Warto rozpowszechaniać infromacje że połączenia via https nie są bezpieczne ani anonimowe. Współczesne rozwiązania IT jak choćby urządzenia firmy Sourcefire (Snort) potrafią w locie dekodować ruch po ssl pod kątem np. przesyłania plików z danymi jako załączników do poczty (większość normalnych ;-) serwerów poczty korzysta właśnie z protokołu https), czy też treści e-mail. Można to też robić na własnym PC, ale jak to niech się dowiedzą zaintereoswani korzystajcy z np MiTM, arp poisoning, ethereal itd … ;-) i Https obecnie nie stanowi już samej gwarancji bezpieczeństwa oraz zachowania prywatności anonimowosci. Pora na coś nowego

    Odpowiedz
    • Tu bym nie przesadzał, choć pewnie że SSL ma swoje wady. Po ssh też można tunelować inne protokoły i też można zrobić MiTMa, ale czy znaczy to że jest niebezpieczny? ;)

      Odpowiedz
  4. Nie bynajmniej SSL nie jest niebezpieczny (chyba że w wersji 1 ;-)) wykorzystanie SSL z HTTP w ramach HTTPS dla aplikacji webowych typu panel użytkownika poczty, albo portal webowy jak np. facebook, jest ok. Chodzi mi o to że bardzo rzadko można natrafić na artykuły które oprócz zalet protokołu SSL, jego implementacji wraz z innymi protokołami (https,ftps,pop3s itd.) pokazywania na screenshota że sniffer widzi krzaczki, mówił by też że ten protokół nie daje gwarancji na bezpieczne i w pełni prywatne korzystanie z aplikacji webowych wykorzystujących połączenia realizowane via SSL

    Odpowiedz
  5. Ja nie jestem aż tak kumaty jak mam dodać bądź włączyć tak abym mógł wejść na moja stronę w banku ??

    Odpowiedz
  6. Damian

    A jak wygląda komunikacja w przypadku przekierowania takiej strony z HSTS na poziomie routera/webproxy? Czy jeśli wklepiemy w przeglądarkę np https://facebook.pl, a przeglądarka dostanie przekierowanie na https://innastrona.pl to czy powinien pojawić się jakiś błąd lub komunikat dla użytkownika?

    Odpowiedz

Odpowiedz