W wydanym wczoraj tzw. Patch Tuesday, czyli paczce aktualizacji bezpieczeństwa przeznaczonej dla produktów firmy Microsoft publikowanej w drugi wtorek każdego miesiąca, znalazła się m.in. zmiana będąca pokłosiem głośnej podatności POODLE – wyłączenie SSL 3.0 fallback. Na końcu tego wpisu znajduje się także opis błędu, na który natknąłem się w trakcie jego tworzenia.
Microsoft dotrzymuje słowa
Zgodnie z grudniowymi zapowiedziami, o których wspomniałem w jednym z wpisów, wśród opublikowanych wczoraj przez Microsoft poprawek bezpieczeństwa znalazła się ta, obiecana ponad dwa miesiące temu, związana obsługą protokołu SSL. Użytkownicy, którzy zaktualizowali już przeglądarkę Internet Explorer chronieni są przed tzw. SSL 3.0 fallback. O tym czym jest SSL fallback pisałem we wskazanym wyżej i ponownie teraz, poście. Zmiana została włączona domyślnie, więc użytkownik nie musi wykonywać żadnych dodatkowych czynności konfiguracyjnych.
Drugą ważną informacją, która wpisuje się w tematykę Kryptosfery, jest ogłoszenie planu całkowitego wyłączenia wsparcia dla protokołu SSL w wersji 3.0 w przeglądarce IE. Ma to nastąpić już (lub dopiero) w kwietniu.
POODLE i… błąd OCSP
W związku z wprowadzonymi poprawkami Microsoft zaktualizował opis podatności POODLE o czym informuje Microsoft Security Response Center Team. W zasadzie ta krótka informacja miała zakończyć ten wpis, gdyby nie błąd na który natknąłem się chcąc zapoznać się ze szczegółami zmian w opisie podatności Padding Oracle On Downgraded Legacy Encryption. Otóż, próba przejścia pod adres: https://technet.microsoft.com/en-us/library/security/3009008.aspx (trzeci z wypunktowanych linków) w przeglądarce Firefox zakończyła się poniższym błędem OCSP:
Błąd OCSP: sec_error_ocsp_old_response
Postanowiłem znaleźć jego przyczynę.
Nieaktualna odpowiedź serwera OCSP
Do sprawdzenia struktury odpowiedzi OCSP, która nie została poprawnie przetworzona przez Firefoxa wykorzystałem Wiresharka. Zarejestrowana odpowiedź wyraźnie wskazuje przyczynę:
OCSP Response – Wireshark
Ci z Was, którzy czytali drugą cześć wpisu dotyczącą OCSP mogą już domyślać się przyczyny zwrócenia takiego błędu (Ci, którzy uważnie przeczytali śródtytuł też :-)).
Zwróćcie uwagę na pole nextUpdate, wskazuje ono na datę 9 lutego 2015 i godzinę 11:00:50 (czas UTC) – dzisiaj mamy już 11 lutego. Zgodnie z tym co pisałem we wspomnianym artykule o OCSP, a przede wszystkie zgodnie ze standardem tego protokołu opisywanym w RFC 2560:
W przypadku, gdy wartość z pola nextUpdate wskazuje na wcześniejszą godzinę niż aktualny czas, odpowiedź nie powinna być uznawana za właściwą.
Odpowiedź, którą otrzymałem dzisiaj z serwera OCSP została podpisana przez responder 5 lutego (6 dni temu). Wystawiając tę odpowiedź responder zobowiązał się, że zaktualizuje informacje o statusie certyfikatu przed datą wskazaną w polu nextUpdate. Z jakiegoś powodu jednak tego nie zrobił.
Właśnie dlatego Firefox nie pozwolił mi zapoznać się z treścią wskazanej strony. Niestety, spośród grona: Chrome, IE, Opera i Firefox, tylko przeglądarka Mozilli zablokowała dostęp. Ma to o tyle istotny wpływ na bezpieczeństwo użytkowników, że od 5 lutego certyfikat mógł zostać unieważniony, a przez nieaktualną odpowiedź OCSP użytkownik mógł nie być tego świadomy.
Być może wskazany błąd OCSP występuje tylko u mnie np. z powodu jakiegoś upartego cache’a, którego – mimo usilnych prób – nie udało mi się usunąć (mało realny scenariusz). Jestem ciekawy czy błąd będzie powtarzalny także w Waszym lisku (nie w pandzie małej :-) Jeżeli będziecie mieli ochotę zweryfikować to na swoich stacjach to przed wykonaniem testu (czyt. kliknięciem we wskazany link), upewnijcie się, że w opcjach Firefoxa (zakładka Zaawansowane) posiadacie zaznaczony punkt „Odpytywanie serwerów OCSP w celu potwierdzenia wiarygodności certyfikatów”. Wynikami podzielcie się w komentarzach ;-)