W kolejnej, trzeciej już, części wpisów dotyczących OCSP znajdziecie m.in. porównanie weryfikacji statusu certyfikatu za pomocą OCSP i CRL. Przedstawię także kilka ciekawych kwestii związanych z zasadami funkcjonowania protokołu weryfikacji certyfikatów w trybie online.

Tych, którzy nie czytali jeszcze części pierwszej i drugiej, zapraszam do lektury.

Porównanie OCSP z CRL

Jak mogliście przeczytać w pierwszej części, OCSP jest alternatywną – do list certyfikatów unieważnionych (CRLs) – metodą pozwalającą na weryfikację statusu certyfikatu. W zasadzie dzisiaj można by pokusić się o stwierdzenie, że jest odwrotnie i to CRLs stały się opcją zapasową dla OCSP. Poniżej znajduje się krótkie zestawienie przedstawiające zalety i wady obu rozwiązań, a w dalszej części przykład obrazujący jeden z istotnych powodów tego, dlaczego dziś to OCSP jest znacznie popularniejszy niż CRLs.

Zalety OCSP:

• nieduży, stały rozmiar odpowiedzi, nie powoduje to zwiększania narzutu wydajnościowego.

Wady OCSP:

• niedostępność serwera OCSP oznacza brak możliwości zweryfikowania statusu certyfikatu (cyklicznie publikowane CRLs są w pewnym sensie lepiej przystosowane do działania w trybie offline);
• CA może poznać strony internetowe odwiedzane przez użytkowników, może być to traktowane jako naruszanie prywatności (jeżeli ten punkt zaniepokoił kogoś z Was, to już teraz zachęcam do przeczytania czwartej części z tej serii wpisów, która powinna powstać w najbliższych tygodniach).

Zalety CRLs:

• wszystkie informacje o unieważnionych certyfikatach danego wystawcy znajdują się w jednym miejscu.

Wady CRLs:

• duże, rozrastają się powodując wydłużanie czasu ich pobierania (konieczność przeglądania wielu rekordów listy);
• występują opóźnienia w odświeżaniu list.

Główną zaletą OCSP w porównaniu z CRLs jest to, że klient wysyłający zapytanie o status konkretnego certyfikatu nie musi przeszukiwać całej listy przesłanej w odpowiedzi. W zamian otrzymuje on w czasie rzeczywistym informacje tylko o tym certyfikacie o który pytał.

Jak już wspomniałem, rozmiar pojedynczej odpowiedzi OCSP jest stały i zwykle nie przekracza 2 kilobajtów. Jest to przeciwieństwo ciągle zmieniających swój rozmiar CRLs.  Jako ciekawy przykład można podać historię jednej z list CRL popularnego CA, GlobalSign. Po ujawnieniu na początku kwietnia 2014 roku błędu w oprogramowaniu OpenSSL (Heartbleed), który mógł prowadzić do kompromitacji klucza prywatnego serwera, zaczęto masowo unieważniać certyfikaty SSL. Wśród unieważniających znalazła się firma CloudFlare, która postanowiła wygenerować nowe certyfikaty dla swoich klientów, unieważniając przy tym te, które potencjalnie mogły zostać skompromitowane. W ciągu zaledwie kilku dniu do wspomnianej listy dopisanych zostało prawie 134 000 rekordów zawierających informacje o unieważnionych certyfikatach, a rozmiar listy z 22 kilobajtów urósł do 4,5 megabajtów (obecnie lista ta jest jeszcze większa).

Weryfikacja weryfikacji

Jak już wiemy, OCSP służy do weryfikacji statusu certyfikatów. W tym celu OCSP responder wystawia specjalne odpowiedzi, które podpisuje własnym certyfikatem. Jak jednak zweryfikować status tego certyfikatu? Standard wskazuje trzy sposoby – wśród których może wybierać CA – pozwalające rozwiązać tę kwestię:

1. CA może wskazać, aby klient OCSP po prostu ufał responderowi OCSP w czasie, gdy certyfikat podpisujący jest ważny. Realizowane jest to poprzez umieszczenie w certyfikacie OCSP rozszerzenia id-pkix-ocsp-nocheck (OID: 1.3.6.1.5.5.7.48.1.5), które przyjmuje wartość NULL. W przypadku wyboru takiego rozwiązania certyfikaty podpisujące odpowiedzi OCSP nie powinny posiadać długich okresów ważności i muszą być wymieniane odpowiednio często.
2. CA, podobnie jak w przypadku zwykłych certyfikatów (np. SSL), może określić sposób w jaki może zostać sprawdzony status certyfikatu. Może być to lista CRL lub kolejny serwer OCSP (proces weryfikacji staje się wtedy rekurencyjny).
3. CA może zadecydować, aby nie wskazywać żadnych metod weryfikacji. Odpowiedzialności jest tu niejako zrzucona na klienta OCSP, który sam musi podjąć decyzję odnośnie tego czy sprawdzać status certyfikatu czy też nie.

Obecnie najczęściej wykorzystywana jest metoda opisana w punkcie pierwszym.

Rozszerzenie ocsp-nocheck w certyfikacie OCSP

Wartość 05 00 to nic innego jak kodowana za pomocą Distinguished Encoding Rules wartość NULL.

Wydajność OCSP

Liczba aktywnych certyfikatów różnego przeznaczenia ciągle rośnie. Każdego dnia pod wskazywane w certyfikatach adresy usług OCSP wysyłana jest ogromna ilość żądań. Sam Symantec wskazał jakiś czas temu, że średnio obsługuje około 4,5 miliarda (!) żądań OCSP dziennie. Uwzględniając przy tym wymagania odnośnie akceptowalnego czasu w jakim odpowiedź powinna zostać zwrócona można nabrać wyobrażenia o wymaganiach odnośnie wydajności takiej usługi. Nie rzadko do jej osiągnięcia Urzędy Certyfikacyjne decydują się na wykorzystanie technologii CDN.

Tutaj mała uwaga odnośnie czasów zwracania odpowiedzi OCSP. Obecna wersja BR dla certyfikatów SSL zakłada, że odpowiedź może zostać zwrócona w przeciągu 10 sekund. W praktyce jednak niewielka grupa użytkowników będzie czekała tak długo, dlatego też zwykle odpowiedź OCSP zwracana jest w czasie znacznie krótszym niż 1 sekunda.

Niedostępność OCSP

A co jeżeli w danej chwili nie można nawiązać połączenia z serwerem OCSP i uzyskanie informacji o statusie danego certyfikatu jest niemożliwe?

Standard jako dobrą praktykę proponuje w zastępstwie skorzystać z list CRL. Patrząc jednak na obecne zachowanie najpopularniejszych przeglądarek można powiedzieć, że różnie z tym bywa. Jak wspominałem w pierwszej części, Chrome w ogóle nie korzysta z OCSP, więc wypada z naszych rozważań. Firefox dla certyfikatów EV SSL, w przypadku braku możliwości uzyskania odpowiedzi od serwera OCSP uznaje certyfikat jako nieprawidłowy. Jednak dla certyfikatów SSL innych niż EV, w przypadku problemów z połączeniem z OCSP przechodzi do weryfikacji opartej na listach CRLs. Internet Explorer i Opera z kolei nie określają sposobu weryfikacji w zależności od typu certyfikatu i pozwalają w każdym przypadku na weryfikację zarówno za pomocą OCSP jak i CRLs. Jest to chyba najrozsądniejsze rozwiązanie mając na względzie fakt, że istnieją jeszcze certyfikaty, które nie wskazują serwera OCSP w swojej strukturze.

Nie ma jednak gwarancji na to, że powyższe ścieżki weryfikacyjne nie ulegną zmianie za jakiś czas.

Aktualizacja statusu certyfikatu

Unieważniłem certyfikat, po jakim czasie OCSP zacznie zwracać status revoked?

Zwykle aktualizacja statusu nie trwa dłużej niż kilka minut. Problemem może okazać się tutaj jednak zbyt długi czas cache’owania odpowiedzi. Może wtedy dojść do sytuacji w której mimo unieważnienia certyfikatu, do użytkownika –  jeszcze przez pewien czas – będzie zwracany status good. Z tego powodu czas przechowywania odpowiedzi w pamięci podręcznej nie powinien być zbyt długi. Nieuwzględnienie tego warunku w czasie konfiguracji usługi naraża użytkownika na ryzyko związane z przekazaniem mu błędnej informacji o statusie danego certyfikatu, co z kolei może prowadzić do wielu negatywnych konsekwencji.

SHA-2 a OCSP

Jak wiemy, obecnie trwa proces wycofywania, uznawanej za coraz słabszą, funkcji skrótu SHA-1. Niektóre przeglądarki zdecydowały się nawet na zastosowanie środków mobilizujących – w postaci specjalnych ostrzeżeń – mających na celu przyśpieszenie tego procesu.

Na ten moment zdecydowana większość nowo wystawianych certyfikatów podpisywana jest przy użyciu nowszej i bezpieczniejszej następczyni SHA-1, SHA-2 (od roku 2016 zabronione będzie wydawanie certyfikatów dla użytkowników końcowych lub pośrednich w oparciu o SHA-1). Jak w tym wszystkim ma się sprawa z certyfikatami przeznaczonymi do podpisywania odpowiedzi OCSP? Tutaj znowu odniosę się do wymagań tworzonych przez CABForum. Pozwalają one na wykorzystywanie SHA-1 w procesie podpisywania certyfikatów OCSP do końca 2016, czyli rok dłużej niż w przypadku certyfikatów zwykłego przeznaczenia.

W kolejnej części przedstawię dwa mechanizmy związane z protokołem OCSP:

• OCSP Stapling,
• OCSP Must Staple.