Wprowadzenie
Gdy użytkownik odwiedza witrynę HTTPS, musi odpowiedzieć działającym klucz publicznyoraz ważny certyfikat SSL, który wiąże klucz z twoją tożsamością, jako osoba, firma lub organizacja. Certyfikaty są zawsze wydawane z uprzednio zdefiniowaną datą ważności, która jest zawarta w samym podpisanym certyfikacie, a przeglądarki zawsze sprawdzają datę ważności i odrzucają wszelkie wygasłe certyfikaty.
Jednak w niektórych przypadkach certyfikat musi być oznaczony jako nieważny (i zaufanie do tych certyfikatów musi być odwołany) zanim wygasa. Typowe przykłady obejmują właściciela serwera mającego dowody (lub po prostu podejrzewające), że ich klucz prywatny został naruszony (tj. Został zgubiony, skradziony lub zniszczony), ponieważ strona trzecia posiadająca ten klucz prywatny może zasadniczo ominąć wszystkie kontrole bezpieczeństwa sieci przeglądarki.
W związku z tym wymagane są dostawcy przeglądarki publicznie zaufany urzędy certyfikacji (Urzędy certyfikacji) w celu wdrożenia co najmniej jednej metody zarówno unieważniania problematycznych certyfikatów, jak i powiadamiania przeglądarek o odrzuceniu tych unieważnionych certyfikatów.
Krótka historia (problemów) sprawdzania odwołania
Na początku protokołu SSL stosowaną metodą urzędów certyfikacji było publikowanie statusu odwołania certyfikatu w publicznie dostępnych dokumentach o nazwie listy odwołania certyfikatów (C.R.L.). Lista CRL to po prostu lista wszystkich certyfikatów, które urząd certyfikacji kiedykolwiek odwołał przed wygaśnięciem. Urzędy certyfikacji okresowo publikowały najnowszą wersję swoich list CRL, z którymi przeglądarki musiały się zapoznać zanim każde połączenie HTTPS.
Oczywiście jako HTTPS (i SSL /TLS) wzrosła z biegiem lat, podobnie jak rozmiar opublikowanych list CRL. Wymóg pobierania i analizowania dużej listy CRL przed każdym połączeniem narzucał stale rosnące obciążenie sieci. Szybko okazało się, że metoda CRL nie jest dobrze skalowana.
Aby złagodzić te problemy ze skalowaniem, przeglądarki i urzędy certyfikacji zaprojektowały i wdrożyły Protokół statusu certyfikatu online (OCSP). Publicznie zaufane urzędy certyfikacji, takie jak SSL.com, teraz utrzymuj proste serwery HTTP o nazwie Respondenci OCSP. Przeglądarki mogą teraz skontaktować się z responderem, aby poprosić o status odwołania pojedynczego certyfikatu wydanego przez urząd certyfikacji, zamiast konieczności pobierania i przetwarzania całej listy CRL.
Respondenci OCSP podpisują swoje odpowiedzi prywatnym kluczem podpisu urzędu certyfikacji, a przeglądarki mogą zweryfikować, czy otrzymany status odwołania został rzeczywiście wygenerowany przez właściwy urząd certyfikacji.
Niestety, choć początkowo OCSP wydawało się skutecznym rozwiązaniem, nowy protokół wykazał pewne praktyczne problemy z wydajnością, bezpieczeństwem i prywatnością.
Problemy z wydajnością
Kontakt z responderem w sprawie każdego certyfikatu napotkanego przez przeglądarkę oznacza, że przeglądarki muszą wykonać dodatkowe żądanie HTTP dla każdego nowego połączenia HTTPS. Ten narzut sieciowy był odczuwalny dla użytkowników, szczególnie na stronach zawierających treści stron trzecich przechowywane na zdalnych serwerach dystrybucji treści (z których każdy może mieć jeden lub więcej certyfikatów).
Reagowanie jest podstawową zasadą dobrego projektowania interfejsu użytkownika. Długie opóźnienia mogą być główną przyczyną frustracji użytkowników i mogą prowadzić użytkowników do przekonania, że witryna nie działa lub że ich gest wejściowy został zignorowany.
Co więcej, wielu badania naukowe w przeszłości łączyły szybkość i szybkość wczytywania strony z ulepszonym SEO i wyższym współczynnikiem konwersji. W rzeczywistości Amazon obliczył, że opóźnienie wynoszące zaledwie jedną sekundę może ich kosztować $1.6 miliard rocznie.
(Aby uzyskać więcej informacji na temat wpływu szybkości wczytywania strony na twoją stronę internetową i sugerowanych optymalizacji, zapoznaj się z naszą artykuł opisujący, w jaki sposób usunięcie mieszanej zawartości z witryny poprawi jej wydajność).
Kwestie bezpieczeństwa
Istnieją również ważne obawy dotyczące bezpieczeństwa związane z OCSP. Fakt, że większość praktycznych implementacji OCSP nie była wystarczająco niezawodna (albo z powodu opóźnienia sieci, błędów konfiguracji lub aplikacji) zmotywowała przeglądarki i inne oprogramowanie klienckie do wdrożenia sprawdzania OCSP w miękka porażka tryb.
Oznacza to, że jeśli nie można uzyskać dostępu do serwera OCSP lub upłynie limit czasu podczas udzielania odpowiedzi, przeglądarki to zrobią uznać certyfikat za ważny i mimo to kontynuuj połączenie HTTPS.
Powodem tego jest to, że ponieważ serwer OCSP może potencjalnie obsługiwać miliony witryn internetowych i możliwe jest, że serwer OCSP ulegnie awarii w dowolnym momencie, porzucenie połączenia przy każdej awarii OCSP zakłóciłoby przeglądanie milionów użytkowników. Nawet jeśli serwer OCSP działa, ale odpowiedź zajmuje dużo czasu, zwiększa to postrzegane opóźnienie i frustrację użytkownika.
Człowiek w środku (MITM) wiadomo, że osoby atakujące wykorzystują to zachowanie, blokując cała kolekcja połączenia z obiektami odpowiadającymi OCSP, co w praktyce oznacza, że mogą używać skradzionego certyfikatu i pary kluczy dla złośliwej witryny, niezależnie od stanu odwołania certyfikatu.
Prywatne problemy
Wreszcie, ponieważ certyfikat jest powiązany z kluczem i nazwą domeny, a przeglądarki żądają statusu unieważnienia przed każdym nowym połączeniem HTTPS, oznacza to, że przeglądarki przeciekają znaczną część historii online ich użytkowników do respondentów OCSP.
Oczywiście publicznie zaufane urzędy certyfikacji nie są złośliwymi organizacjami, które chcą zagrażać prywatności użytkowników. (Renomowane urzędy certyfikacji zawsze aktywnie próbują chronić bezpieczeństwo i prywatność ich użytkowników). Jednak w przypadku naruszenia bezpieczeństwa podmiotu odpowiadającego OCSP urzędu certyfikacji dane wymieniane z tym niezaufanym serwerem mogą prowadzić do ujawnienia poufnych i prywatnych informacji.
OCSP Zszywanie na ratunek
Aby złagodzić te problemy, przeglądarki i urzędy certyfikacji opracowały nową metodę określania stanu certyfikatu o nazwie Zszywanie OCSP. Zszywanie OCSP pozwala serwerom internetowym (zamiast przeglądarek) uzyskiwać podpisane odpowiedzi OCSP dla swoich certyfikatów, które mogą być buforowane do 7 dni.
Serwery obejmują (lub zszywka) buforowana odpowiedź OCSP w odpowiedziach HTTPS obok samego certyfikatu SSL. W ten sposób przeglądarki mogą zweryfikować podpis urzędów certyfikacji w odpowiedzi OCSP i mieć pewność, że certyfikat nie został odwołany, przed ustanowieniem bezpiecznego połączenia i bez konieczności wykonywania kosztownego dodatkowego żądania do samego serwera OCSP.
Zszywanie OCSP to proste, ale bardzo skuteczne rozwiązanie wyżej wymienionych problemów. Serwery mogą pobierać buforowane odpowiedzi OCSP w swoim własnym czasie, co eliminuje narzut związany z wydajnością narzucony przez listy CRL i OCSP, a także towarzyszące im obawy dotyczące prywatności.
Jednak samo zszywanie OCSP nie rozwiązuje całkowicie problemu z miękkimi awariami protokołu OCSP. Ponieważ zszywanie jest zaimplementowane na serwerze, przeglądarki nie mogą wiedzieć, czy serwer faktycznie obsługuje zszywanie, czy nie.
W konsekwencji osoby atakujące MITM ze skradzionym (ale unieważnionym) certyfikatem mogą przeprowadzić atak na obniżenie wersji, udostępniając certyfikat bez zszywania OCSP. Przeglądarka ofiary nie jest w stanie potwierdzić, czy serwer faktycznie obsługuje zszywanie, i przejść do zapytania odpowiadającego OCSP w normalny sposób.
Atakujący MITM mogą wtedy po prostu zablokować to zapytanie OCSP i skutecznie zmusić przeglądarki do zaakceptowania certyfikatu jako ważnego.
Zszywki OCSP
Ten atak zmotywował urzędy certyfikacji i dostawców przeglądarki do wprowadzenia rozszerzenia certyfikatów SSL, zdefiniowanych w RFC 7633, powszechnie nazywane OCSP Niezbędne zszywanie (chociaż sam dokument RFC nie wymienia tej nazwy, co może powodować pewne zamieszanie). To po prostu nakazuje zszywanie protokołu OCSP dla certyfikatu. Jeśli przeglądarka napotka certyfikat z tym rozszerzeniem, który jest używany bez zszywania OCSP, zostanie odrzucony. OCSP Must-Staple łagodzi wspomniany wcześniej atak na obniżenie wersji, a także redukuje niepotrzebny ruch do respondentów OCSP urzędu certyfikacji, co może również pomóc w poprawie ogólnej wydajności OCSP.
Jeśli chcesz włączyć rozszerzenie OCSP Must-Staple w swoich certyfikatach, skontaktuj się z jednym z naszych agentów pomocy technicznej pod adresem support@ssl.com by uzyskać więcej szczegółów.
Włącz zszywanie OCSP na swoim serwerze
Aby uniknąć problemów związanych z wyszukiwaniem, poniższe sekcje zawierają instrukcje dotyczące włączania zszywania OCSP w twoim urządzeniu Apache i nginx środowiska:
Apache
Aby włączyć zszywanie OCSP w twoim Apache serwerze, proszę dodać następujące wiersze w pliku konfiguracyjnym serwera.
# Zszywanie OCSP, tylko w httpd 2.3.3 i nowszych SSLUseStapling na SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors wyłączone SSLStaplingCache shmcb: / var / run / ocsp (128000)
nginx
Aby włączyć zszywanie OCSP w twoim nginx serwerze, proszę dodać następujący tekst do pliku konfiguracyjnego serwera.
# OCSP Zszywanie --- # pobierz rekordy OCSP z adresu URL w certyfikacie ssl_cache i buforuj je ssl_stapling na; ssl_stapling_verify on;
Wnioski
Sieć to skomplikowana sieć współzależnych komponentów, z których wszystkie (zwykle) działają w harmonii, zapewniając bezproblemowe przeglądanie. Coraz większa złożoność tego systemu tworzy jednak coraz większą powierzchnię ataku i umożliwia opracowywanie i wykonywanie nowych ataków sieciowych.
Sama liczba komponentów w naturalny sposób zwiększa opóźnienia i powoduje opóźnienia, co oznacza, że przedsiębiorstwa muszą znaleźć sposoby na poprawę bezpieczeństwa bez wpływu na komfort użytkownika. Włączenie zszywania OCSP da ci tę rzadką okazję do poprawy bezpieczeństwa i wydajność Twojej witryny w tym samym czasie.
Jak zawsze chętnie odpowiemy na pytania dotyczące zszywania OCSP lub innych problemów - wystarczy wysłać do nas wiadomość e-mail na adres support@ssl.com.
