H

TTP Strict Transport Security (HSTS) jest opcjonalnym mechanizmem zabezpieczeń, w którym serwer WWW oświadcza klientowi (np. przeglądarce internetowej), że komunikacja powinna odbywać się tylko po bezpiecznym połączeniu. Oświadczenie serwera WWW odbywa się poprzez zastosowanie specjalnego nagłówka odpowiedzi HTTP: “Strict-Transport-Security“. Klient obsługujący mechanizm HSTS otrzymując ten nagłówek będzie zapobiegał wszelkiej łączności poprzez protokół HTTP w określonej domenie i starał się, aby wszystkie połączenia odbywały się przez HTTPS.

Specyfikacja HSTS 17 czerwca 2010 roku została zgłoszona jako Internet-Draft IETF przez swoich autorów ( Jeff’a Hodges’a, Collin’a Jackson’a oraz Adama Barth’a ). 2 października 2012 roku komitet wykonawczy IETF – IESG (ang. Internet Engineering Steering Group) zaakceptował HSTS jako propozycja standardu RFC. Jeśli polityka HSTS zostanie aktywowana po stronie serwera spełniający jej wymagania klient wykona następujące czynności:

• automatycznie zmieni wszystkie łącza na bezpieczny protokół TLS (na przykład adres: http://domena.pl/abc zostanie zamieniony na https://domena.pl/abc przed wysłaniem żądania do serwera),
• jeśli bezpieczeństwo połączenia nie może zostać zapewnione (na przykład przez samopodpisany certyfikat TLS) wyświetlony zostanie komunikat błędu blokujący dostęp do niebezpiecznej strony użytkownikowi.

Motywacją do stworzenia HSTS był jeden z rodzajów ataków man-in-the-middle – SSLStrip przedstawiony przez Moxie Marlinspike’a na konferencji Black Hat w 2009 roku. Atak SSLStrip transparentnie konwertuje bezpieczne połączenia HTTPS do zwykłych połączeń HTTP umożliwiając podsłuchiwanie transmisji. Użytkownik może zobaczyć, że połączenie jest nawiązywane zwykłym połączeniem, ale też nie ma zawsze pewności i świadomości, czy powinno być inaczej. Wiele stron nie używa jeszcze protokołu SSL dlatego użytkownicy nie mają możliwości (bez wcześniejszej wiedzy nt. bezpieczeństwa w Internecie) stwierdzenia, czy zastosowanie zwykłego protokołu HTTP jest efektem ataku, czy efektem tego, że na stronie nie został wdrożony protokół SSL.

HSTS po części rozwiązuje ten problem informując przeglądarki, że połączenia do strony zawsze powinny używać połączeń HTTPS. Problem w tym, że nagłówki HSTS przekazywane w protokole HTTP mogą zostać usunięte przez agresora, co pozwoli mu na przeprowadzenie ataku – jeśli jest to pierwsza wizyta użytkownika na stronie. Ten sam przypadek odnosi się do pierwszego żądania przeglądarki po okresie ważności polityki, jaki ustalamy również w nagłówku. Przeglądarka Chrome próbuje ograniczyć ten problem poprzez wbudowaną listę stron, które obsługują HSTS – niestety to rozwiązanie nie może zostać przeniesione na wszystkie strony w Internecie. HSTS może również pomóc uniknąć kradzieży tożsamości na stronach opartych o sesje zapisywane w ciasteczkach przez takie narzędzia jak Firesheep.

Nagłówki HSTS muszą zostać przekazane w odpowiedzi przez protokół HTTPS. Poprawna implementacja obsługi po stronie klienta nie będzie ich respektowała, jeśli zostaną one dostarczone przez protokół HTTP lub HTTPS używający niewiarygodnych certyfikatów. Dlatego przed dostarczeniem nagłówka HSTS do klienta warto za pomocą przekierowania 301 skierować ruch na protokół HTTPS – dla serwera Apache może to być reguła:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R=301,L]

Jeśli klient komunikuje się już po bezpiecznym protokole możemy przekazać do niego nagłówek HSTS w odpowiedzi:

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

Ważność polityki określona jest w sekundach przez wartość max-age (31536000 = 12 miesięcy, 63072000 = 24 miesiące). Dodatkowa wartość includeSubDomains informuje klienta, że polityka ma obowiązywać nie tylko dla głównej domeny, ale także dla wszystkich subdomen. Przeglądarki, jakie obsługują HSTS to: Google Chrome (od wersji 4.0.211.0), Firefox (od wersji 4.0) oraz Opera (od wersji 12).

Więcej informacji: OWASP