Czwarty z serii postów dotyczących Online Certificate Status Protocol (OCSP), tak jak obiecałem, dotyczył będzie dwóch mechanizmów bezpośrednio z nim związanych: OCSP Stapling oraz OCSP Must-Staple. Zapraszam do lektury.

Jeżeli nie czytaliście jeszcze poprzednich części – 1, 2 i 3 – to zachęcam do nadrobienia zaległości.

OCSP Stapling

O tym, że OCSP nie jest protokołem idealnym wspominałem w trzeciej części. Dwa, chyba najczęściej kierowane zarzuty pod jego adresem to:

• powodowanie opóźnień w ładowaniu strony – wysłanie żądania do serwera OCSP utrzymywanego przez CA i oczekiwanie na odpowiedź zajmuje czas;
• naruszanie prywatności użytkowników – klient (np. przeglądarka), w celu weryfikacji statusu certyfikatu, wysyła do serwera OCSP numer seryjny certyfikatu zainstalowanego na stronie, którą odwiedza użytkownik.

Oba te problemy rozwiązuje mechanizm potocznie zwany OCSP Stapling, który realizowany jest poprzez rozszerzenie protokołu TLS – Certificate Status Request (nie mylić z Certificate Signing Request).

Zasada działania OCSP Stapling polega na tym, że to serwer HTTP odpytuje serwer OCSP w celu uzyskania informacji o statusie certyfikatu, który jest na nim zainstalowany, a następnie dostarcza uzyskany status klientowi (przeglądarce) podczas procesu ustanawiania bezpiecznego kanału wymiany informacji (TLS handshake). Klient nie musi już wtedy nawiązywać połączenia się z serwerem OCSP, dzięki czemu czas zestawiania szyfrowanego połączenia jest krótszy, a i prywatność użytkowników zostaje zachowana.

Jak większość mechanizmów/protokołów/rozwiązań także i OCSP Stapling nie posiada samych zalet. Do głównych wad zaliczyć można dołożenie pracy do wykonania serwerowi HTTP (odciążamy tym samym serwery CA). Narzut wydajnościowy jest jednak na tyle mały, że kwestia ta nie powinna zaprzątać nam głowy – każdorazowe łączenie się klienta z serwerem OCSP jest z pewnością bardziej czasochłonne, a przecież zależy nam na tym, aby opóźnienia w ładowaniu naszej strony były jak najmniejsze.

TLS handshake z i bez OCSP Stapling

Spróbujmy przyjrzeć się bliżej temu jak działa OCSP Stapling. Poniższy opis opisuje proces zestawiania połączenia TLS handshake. Do analizy struktury pakietów skorzystałem z Wireshark’a.

Pierwszym warunkiem działania OCSP Staplingu jest przesłanie przez klienta w komunikacie ClientHello rozszerzenia status_request. Klient ze wsparciem dla OCSP Stapling przesyła je każdorazowo, ponieważ na tym etapie nie wie czy dany serwer posiada włączony Stapling czy też nie.

W odpowiedzi serwer w komunikacie ServerHello zwraca to samo rozszerzenie potwierdzając obsługiwanie OCSP Staplingu. W przypadku, gdy serwer nie korzysta ze Staplingu rozszerzenie to nie jest zwracane do przeglądarki.

Po lewej rozszerzenie status_request wysłane przez przeglądarkę, a po prawej przez serwer

Następnie wraz z certyfikatem przesyła jego status za pomocą wiadomości CertificateStatus, która zawiera pełną odpowiedź serwera OCSP opisywaną już przeze mnie w części drugiej. Tutaj właśnie znajduje się główna różnica dotycząca procesu zestawiania szyfrowanej komunikacji. W przypadku braku wdrożonego aktywnego OCSP Staplingu serwer przesyła do przeglądarki tylko certyfikat, która to dopiero nawiązuje połączenie z serwerem OCSP celem jego zweryfikowania.

Status certyfikatu zwracany poprzez mechanizm OCSP Stapling

Dalsza część TLS handshake wygląda już identycznie w obu przypadkach.

Wsparcie przeglądarek i serwerów dla OCSP Stapling

Wszystkie najpopularniejsze przeglądarki od dawna posiadają wsparcie dla OCSP Stapling. W razie wątpliwości czy dana wersja przeglądarki obsługuje ten mechanizm można skorzystać z narzędzia SSL Labs (sekcja: Protocol Features → Protocol Details). Nawet jeżeli dana przeglądarka nie wpiera Staplingu, to po prostu skorzysta z tradycyjnego połączenia do serwera OCSP lub pobierze odpowiednią listę CRL. Nie ma tutaj zagrożenia, że coś przestanie działać.

Najpopularniejsze serwery HTTP także wspierają OCSP Stapling. Apache robi to od wersji 2.3.3. (wymagany OpenSSL przynajmniej w wersji 0.9.8h), nginx od 1.3.7, a IIS od wersji Windows Server 2008. Co więcej, Microsoft wdrażając OCSP Stapling zdecydował, że zostanie on włączony domyślnie.

OCSP Must-Staple

Chcąc wyjaśnić ideę OCSP Must-Staple trzeba zacząć od opisania możliwego zachowania przeglądarki w momencie, gdy informacja o statusie danego certyfikatu nie będzie mogła zostać do niej przekazana. Wyróżnia się tutaj dwie koncepcje:

1. Soft-fail – uznanie certyfikatu za ważny i pozwolenie na dostęp do treści.
2. Hard-fail – uznanie certyfikatu za nieważny i blokowanie dostępu do treści.

Oba sposoby mają swoje wady i zalety, a krótko i ogólnie można podsumować to następująco: soft-fail to wygoda użytkownika kosztem bezpieczeństwa, hard-fail to bezpieczeństwo użytkownika kosztem wygody.

Z punktu widzenia bezpieczeństwa idealnie byłoby, gdyby przeglądarki nie pozwalały na dostęp do danej strony bez potwierdzenia poprawnej weryfikacji statusu certyfikatu – opcja hard-fail. Ciężko jednak mówić o tym w przypadku braku wsparcia dla OCSP Stapling. Jest zbyt dużo powodów, które mogą być przyczyną niedostarczenia do przeglądarki statusu certyfikatu z serwera OCSP.

Co innego, gdy korzystamy ze Staplingu. Część z tych powodów jest eliminowanych, dzięki temu, że przeglądarka komunikuje się jedynie z serwerem HTTP. Jednak i tutaj występuje pewna niedoskonałość. Otóż, przeglądarka nie rozróżnia powodów braku możliwości uzyskania statusu certyfikatu, który może spowodowany być po prostu brakiem wsparcia dla OCSP Stapling po stronie serwera lub – opcja gorsza – to atakujący, po przejęciu kontroli nad serwerem, umyślnie blokuje odesłanie odpowiedzi OCSP.

Właśnie tutaj z pomocą przychodzi OCSP Must-Staple, który daje serwerowi możliwość poinformowania klienta (przeglądarki) o tym, że posiada on (serwer) wsparcie dla OCSP Staplingu. Przeglądarka mając tę informacje może, w przypadku nieotrzymania statusu certyfikatu, bez wahania zwrócić hard-fail, ponieważ z wielkim prawdopodobieństwem oznaczało będzie to kompromitację samego serwera.

Podsumowując, OCSP Must-Staple pozwala na zwiększenie skuteczności weryfikacji statusu certyfikatu poprzez danie przeglądarkom możliwości uzasadnionego reagowania na błędy w trybie hard-fail.

Serwer: “Przeglądarko, wspieram OCSP Must-Staple”

Nie wspomniałem jeszcze o tym w jaki sposób serwer może przekazać przeglądarce informację o tym, że posiada on włączony mechanizm OCSP Stapling. Przeglądarka będzie mogła wtedy stosować politykę hard-fail, chroniąc użytkowników danej strony przed odwiedzaniem jej bez potwierdzenia ważności certyfikatu. Propozycje są następujące:

1. Dodanie rozszerzenia w certyfikacie SSL.
2. Dodanie nagłówka w odpowiedzi HTTP.

Zaletą pierwszej z nich jest brak tzw. problemu pierwszej wizyty (TOFU – trust-on-first-use), wadą zaś konieczność wygenerowania nowego certyfikatu. W drugim przypadku jest dokładnie odwrotnie. Certyfikat nie musi być wymieniany, ale występuje ryzyko pierwszej wizyty (ten sam problem dotyczy także innego mechanizmu, który opisywałem jakiś czas temu – HSTS).

Obecnie, nadal trwają prace zarówno nad samym standardem OCSP Must-Staple jak i nad sposobami jego wdrożenia w przeglądarkach i serwerach webowych.

Połączenie OCSP Staplingu z OCSP Must-Staple jest z pewnością rozwiązaniem, które pozwala na eliminacje niedoskonałości obecnego procesu sprawdzania unieważnień certyfikatów. Tam, gdzie to możliwe warto już w tym momencie rozważyć wdrożenie mechanizmu OCSP Stapling śledząc jednocześnie postępy prac nad OCSP Must-Staple.

PS. Wpis ten jest ostatnim z serii o OCSP. Jak pewnie zauważyliście trafiały one do, górnolotnie nazwanej, kategorii Artykuły :) Ta część Kryptosfery zawierała będzie wpisy niekonieczne związane z aktualnymi wydarzeniami, które opisywały będą różnego rodzaju kwestie dotyczące Infrastruktury Klucza Publicznego.