Biorąc pod uwagę ilość danych osobowych, które przepuszczają przez ogromne zasoby internetu, szyfrowanie nie jest czymś, co można, ale też nie należy lekceważyć. Nowoczesne przeglądarki oferują kilka mechanizmów, które zapewniają bezpieczeństwo danych użytkowników podczas ich przesyłania: bezpieczne pliki cookie i rygorystyczne zabezpieczenia transportu to 2 najważniejsze kwestie. Pozwalają płynnie chronić użytkowników, uaktualniać ich połączenia do protokołu HTTPS i gwarantować, że dane użytkownika nigdy nie są wysyłane automatycznie.
Dlaczego warto wziąć to pod uwagę? Weź pod uwagę te kwestie:
Dostarczenie strony internetowej przez niezaszyfrowane połączenie HTTP jest mniej więcej takie samo jak wręczenie niezaklejonej koperty pierwszej osobie na ulicy, która wygląda, jak idzie w kierunku urzędu pocztowego. Przy odrobinie szczęścia może dotrzeć do końca samodzielnie lub przekazać ją komuś, kto idzie w właściwą stronę. Ta osoba może zrobić to samo.
Większość obcych osób w tym spontanicznym łańcuchu jest godna zaufania i nigdy nie sprawdziłaby Twojego otwartego listu ani go nie zmieniła. Im częściej litera zmienia rękę, tym więcej osób ma pełny dostęp do wysyłanego listu. Ostatecznie jest dość prawdopodobne, że adresat Twojego listu dostanie w nim coś, ale czy to, co przekażesz w wiadomości to samo, jest to pytanie otwarte. Może powinnaś zakleić tę kopertę...
Pośrednicy
Na lepsze lub gorsze wyniki w dużych obszarach internetu zależy wiarygodność obcych. Serwery nie są ze sobą bezpośrednio połączone, ale przekazują żądania i odpowiedzi od routera do routera w ogromnej grze telefonicznej.
Możesz zobaczyć te przeskoki w działaniu dzięki funkcji traceroute. Trasa z komputera do HTML5Rocks wygląda mniej więcej tak:
$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
1 router1-lon.linode.com (212.111.33.229) 0.453 ms
2 212.111.33.233 (212.111.33.233) 1.067 ms
3 217.20.44.194 (217.20.44.194) 0.704 ms
4 google1.lonap.net (193.203.5.136) 0.804 ms
5 209.85.255.76 (209.85.255.76) 0.925 ms
6 209.85.253.94 (209.85.253.94) 1.226 ms
7 209.85.240.28 (209.85.240.28) 48.714 ms
8 216.239.47.12 (216.239.47.12) 22.575 ms
9 209.85.241.193 (209.85.241.193) 36.033 ms
10 72.14.233.180 (72.14.233.180) 43.222 ms
11 72.14.233.170 (72.14.233.170) 43.242 ms
12 *
13 lb-in-f102.1e100.net (173.194.71.102) 44.523 ms
13 przeskoków nie jest złe. Jeśli jednak wysyłam żądania przez HTTP, każdy z tych routerów pośrednich ma pełny dostęp do moich żądań i odpowiedzi serwerów. Wszystkie dane są przesyłane jako niezaszyfrowany tekst jawny, a każdy z tych pośredników może działać jako człowiek na środku, czytać moje dane, a nawet manipulować nimi w trakcie ich przesyłania.
Co gorsza, tego rodzaju przechwytywanie jest praktycznie niewykrywalne. Złośliwie zmodyfikowana odpowiedź HTTP wygląda tak samo jak prawidłowa odpowiedź, ponieważ nie ma mechanizmu, który pozwoliłby Ci zadbać o to, aby otrzymane dane __wyświetlały dokładnie to, co wysyłasz. Jeśli ktoś zdecyduje się wywrócić mi internet do góry nogami z powodu śmiechu, to pech on sam.
Czy jest to bezpieczna linia?
Przejście ze zwykłego tekstu HTTP na bezpieczne połączenie HTTPS zapewnia najlepszą ochronę przed pośrednikami. Połączenia HTTPS w pełni szyfrują cały kanał przed wysłaniem jakichkolwiek danych, co uniemożliwia maszynom między Tobą a miejscem docelowym odczytywanie lub modyfikowanie danych w ruchu.
Zabezpieczenia HTTPS to koncepcja publicznych i prywatnych kluczy kryptograficznych. Dogłębne omówienie szczegółów wykracza (na szczęście) daleko poza zakres tego artykułu, ale podstawowe założenie jest dość proste: dane zaszyfrowane za pomocą danego klucza publicznego można odszyfrować tylko przy użyciu odpowiedniego klucza prywatnego. Gdy przeglądarka rozpoczyna uzgadnianie połączenia HTTPS, aby utworzyć bezpieczny kanał, serwer dostarcza certyfikat, który przekazuje przeglądarce wszystkie informacje niezbędne do zweryfikowania jej tożsamości przez sprawdzenie, czy serwer posiada odpowiedni klucz prywatny. Cała komunikacja od tego momentu jest szyfrowana w sposób, który potwierdza, że żądania są dostarczane do uwierzytelnionego serwera i otrzymywane z niego odpowiedzi.
Protokół HTTPS daje pewność, że rozmawiasz z serwerem, z którym według Ciebie rozmawiasz, i że nikt inny nie podsłuchuje ani nie kręci elementów przewodu. Ten rodzaj szyfrowania jest absolutnym wymogiem wstępnym dla bezpieczeństwa w internecie. Jeśli Twoja aplikacja nie jest obecnie dostarczana przez HTTPS, jest narażona na atak. Rozwiąż problem Na stronie Ars Technica znajdziesz świetny przewodnik po uzyskaniu i instalowaniu certyfikatu. Warto zapoznać się z nim i zapoznać się ze szczegółami technicznymi. Konfiguracja różni się w zależności od dostawcy i serwera, ale proces żądania certyfikatu jest wszędzie taki sam.
Bezpieczeństwo w standardzie
Po wysłaniu prośby o certyfikat i zainstalowaniu certyfikatu upewnij się, że użytkownicy skorzystają na Twojej ciężkiej pracy: przenieś obecnych użytkowników do połączeń HTTPS, korzystając z magii przekierowań HTTP, i zadbaj o to, by pliki cookie były dostarczane tylko za pośrednictwem bezpiecznych połączeń.
W ten sposób
Gdy użytkownik wejdzie na stronę http://example.com/, przekieruj go na stronę https://example.com/, wysyłając odpowiedź 301 Moved
Permanently z odpowiednim nagłówkiem Location:
$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/
Tego rodzaju przekierowanie można łatwo skonfigurować na serwerach takich jak Apache czy Nginx.
Na przykład konfiguracja Nginx przekierowująca z http://example.com/ do https://example.com/ wygląda tak:
server {
listen [YOUR IP ADDRESS HERE]:80;
server_name example.com www.example.com;
location "/" {
rewrite ^(.*) https://www.example.com$1 permanent;
}
}
Zablokuj słoik plików cookie
Pliki cookie umożliwiają nam zapewnienie użytkownikom bezproblemowego logowania się przez bezstanowy protokół HTTP. Dane przechowywane w plikach cookie, w tym informacje poufne, takie jak identyfikatory sesji, są wysyłane razem z każdym żądaniem, dzięki czemu serwer może stwierdzić, na którego użytkownika w danej chwili odpowiada. Gdy będziemy już mieć pewność, że użytkownicy trafiają do witryny z wykorzystaniem protokołu HTTPS, musimy też zadbać o to, aby dane wrażliwe przechowywane w plikach cookie były przesyłane wyłącznie za pomocą bezpiecznego połączenia, a nigdy nie były wysyłane w sposób przejrzysty.
Skonfigurowanie pliku cookie zazwyczaj wymaga nagłówka HTTP podobnego do tego:
set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT
Możesz polecić przeglądarce ograniczenie wykorzystywania pliku cookie do zabezpieczania sesji przez zastosowanie pojedynczego słowa kluczowego:
Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure
Pliki cookie ustawiane za pomocą słowa kluczowego secure nie będą nigdy wysyłane przez HTTP.
Zamykam otwarte okno
Przejrzyste przekierowanie do HTTPS oznacza, że przez większość czasu użytkownicy będą korzystać w Twojej witrynie z bezpiecznego połączenia. Jednak pozostawia to niewiele miejsca na atak: początkowe połączenie HTTP jest ogólnie otwarte i jest narażone na usunięcie SSL i powiązane ataki. Jeden z członków ma pełny dostęp do początkowego żądania HTTP, więc może działać jako serwer proxy między Tobą a serwerem, utrzymując Cię w niezabezpieczonym połączeniu HTTP niezależnie od intencji serwera.
Aby ograniczyć ryzyko ataku tej klasy, poproś przeglądarkę o wymuszanie stosowania HTTP Strict Transport Security (HSTS). Wysłanie nagłówka HTTP Strict-Transport-Security instruuje przeglądarkę, że ma wykonać przekierowanie HTTP na HTTPS po stronie klienta bez dotykania sieci (jest to też bardzo korzystne dla wydajności, ponieważ najlepszym żądaniem jest to, które nie jest konieczne):
$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000
Przeglądarki, które obsługują ten nagłówek (obecnie Firefox, Chrome i Opera: Caniuse – szczegóły) zobaczą informację, że dana witryna zażądała dostępu tylko HTTPS. Oznacza to, że niezależnie od sposobu, w jaki użytkownik wchodzi do witryny, będzie się ona otwierała przez HTTPS. Nawet jeśli wpisze w przeglądarce http://example.com/, wyświetli się strona HTTPS, która nigdy nie użyje połączenia HTTP. Co więcej, jeśli przeglądarka wykryje nieprawidłowy certyfikat (co może próbować sfałszować tożsamość serwera), użytkownicy nie będą mogli kontynuować korzystania z aplikacji przez HTTP. Wszystko się dzieje albo nic, a więc jest świetnie.
Przeglądarka utraci status HSTS serwera po max-age sekundach (w tym przykładzie będzie to około miesiąca). Ustaw tę wartość na odpowiednio wysoką wartość.
Aby zabezpieczyć wszystkie subdomeny źródła, dodaj do nagłówka dyrektywę includeSubDomains:
$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000
Idź dalej bezpiecznie
Protokół HTTPS to jedyny sposób, aby zdalnie mieć pewność, że wysyłane dane dotrą do docelowego odbiorcy w niezmienionej formie. Już dziś skonfiguruj
bezpieczne połączenia ze swoimi witrynami i aplikacjami. To dość prosta procedura, która pomaga chronić dane klientów. Gdy utworzysz zaszyfrowany kanał, musisz w przejrzysty sposób przekierowywać użytkowników do tego bezpiecznego połączenia niezależnie od tego, skąd trafiają do Twojej witryny, wysyłając odpowiedź HTTP 301. Następnie upewnij się, że wszystkie poufne informacje o sesjach użytkowników korzystają tylko z tego bezpiecznego połączenia. W tym celu dodaj słowo kluczowe secure do ustawiania plików cookie.
Gdy to zrobisz, zadbaj o to, aby użytkownicy nigdy przypadkowo nie wysłali z autobusu. Zadbaj o to, by przeglądarka działała we właściwy sposób, wysyłając nagłówek Strict-Transport-Security.
Skonfigurowanie protokołu HTTPS nie wymaga wiele wysiłku, a przy tym ma wiele korzyści dla Twojej witryny i jej użytkowników. To się opłaciło.
Zasoby
- StartSSL oferuje bezpłatne certyfikaty weryfikowane za pomocą domeny. Nie ma nic dziwnego. Przejście na wyższy poziom weryfikacji jest oczywiście zarówno możliwe, jak i ceny.
- Test serwera SSL: po skonfigurowaniu protokołu HTTPS dla swoich serwerów sprawdź, czy wszystko działa prawidłowo, przeprowadzając test serwera SSL Laboratorium. Otrzymasz dobrze szczegółowy raport, który pokazuje, czy Twoja firma już działa.
- W najnowszym artykule Ars Technica „Zabezpieczanie serwera WWW protokołem SSL/TLS” warto przeczytać więcej podstawowych informacji o konfigurowaniu serwera.
- Warto przejrzeć specyfikację HTTP Strict Transport Security (RFC 6797) w poszukiwaniu wszystkich potrzebnych informacji technicznych dotyczących nagłówka
Strict-Transport-Security. - Gdy już zorientujesz się w swoich działaniach, możesz ustalić, że Twoja witryna powinna być dostępna tylko przez konkretny zestaw certyfikatów. W ETF trwają prace, które pozwolą to zrobić za pomocą nagłówka
Public-Key-Pins. Są wciąż na wczesnym etapie rozwoju, ale są ciekawe i warto obserwować.