HSTS czyli HTTP Strict Transport Security

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:

ettercap -Tq -i eth1 -M arp:remote /192.168.1.1// /192.168.1.5//

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.

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

Może to wyglądać tak:

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:

HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Encoding: gzip
Content-Length: 3166
Content-Type: text/html; charset=UTF-8
Date: Thu, 27 Jun 2013 17:19:07 GMT
Expires: Thu, 27 Jun 2013 17:19:07 GMT
Server: GSE
Set-Cookie: GoogleAccountsLocale_session=pl; Secure
Set-Cookie: GAPS=1:4gDZvK5g:o5fM52umoiFpi0So;Path=/;Expires=Sat, 27-Jun-2015 17:19:06 GMT;Secure;HttpOnly
Set-Cookie: HSID=AeH9gHkGSn4x2JsR9;Domain=.google.com;Path=/;Expires=Sat, 27-Jun-2015 17:19:06 GMT;HttpOnly
Set-Cookie: SSID=AXftJqsxaxsASWe77;Domain=.google.com;Path=/;Expires=Sat, 27-Jun-2015 17:19:06 GMT;Secure;HttpOnly
Strict-Transport-Security: max-age=2592000; includeSubDomains
X-Content-Type-Options: nosniff
x-frame-options: Deny
x-xss-protection: 1; mode=block
X-Firefox-Spdy: 3

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.

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ę:

Header always set Strict-Transport-Security "max-age=2592000; includeSubDomains"

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)