Czy przeglądarki internetowe buforują certyfikaty SSL?


26

Czy jakieś przeglądarki internetowe buforują certyfikaty serwera SSL? Na przykład, jeśli zmienię certyfikat SSL na serwerze sieciowym, czy wszystkie przeglądarki internetowe pobiorą nowy certyfikat, gdy będą się łączyć za pośrednictwem protokołu SSL, czy jest możliwe, że mogą mieć nieaktualny certyfikat?

Myślę o scenariuszu wygaśnięcia certyfikatu SSL i zastąpienia go nowym na serwerze WWW.


Zakładam, że przeglądarka sprawdza datę na certyfikacie, aby sprawdzić, czy musi uzyskać nowszą, tak jak robi to wszystko, ale nie jestem pewien.
soandos

Rzucić okiem tutaj imperialviolet.org/2011/05/04/pinning.html o „świadectwie przypinanie” oraz z inicjatywy TGV whis jest związana z byłym dev.chromium.org/sts
Shadok

1
Od 2019 r. Mój Chrome 75 buforuje certyfikaty SSL
Fabian Thommen

Odpowiedzi:


10

Cóż, odpowiedź RedGrittyBrick jest poprawna, ale tak naprawdę nie odpowiada na pytanie. Pytanie brzmiało: czy przeglądarki to robią, a nie czy powinny lub muszą to robić.

Z tego, co słyszałem, zarówno MSIE, jak i Chrome faktycznie wykonują certyfikaty pamięci podręcznej i nie zastępują ich, gdy otrzymają nową wersję, o ile stara jest ważna. Nie robię tego, dlaczego to robią, ponieważ obniża to bezpieczeństwo.


Akceptowana obecnie odpowiedź jest dość jasna. Wskazuje to konkretnie, że nie , przeglądarki nie buforują certyfikatów. Jak zauważyłeś, zmienił się krajobraz, powody, dla których Chrome jest dobrze udokumentowany, warto połączyć się z tymi przyczynami. Ponieważ certyfikat jest nadal ważny, nie „obniża” bezpieczeństwa, co nie miałoby sensu.
Ramhound

3
Obniża go, ponieważ nie można zastąpić starego klucza SHA-1 nowym, ponieważ stary nadal jest ważny, a Chrome ignoruje nowy, jeśli wszystko dobrze rozumiem. Nie ma więc sposobu na wymuszenie przejścia na wyższy standard bezpieczeństwa - więc „obniża się” w sensie względnym, nie pozwalając na podniesienie go. Podobnie jak inflacja nie obniża wyznaczonej wartości pieniądza, ale jego rzeczywistą wartość rynkową.
tuexss,

5
+1 Po mieszanym fiasku łańcucha SHA1 / SHA2 StartSSL jest jasne, że Chrome w systemie Windows rzeczywiście buforuje certyfikaty pośrednie, być może w nieskończoność. Chrome zignoruje każdy nowy certyfikat pośredni wysłany przez serwer. Nie jest jednak jasne, czy buforowanie jest uzależnione od tożsamości serwera cert czy tożsamości pośredniego certyfikatu i co dokładnie stanowi tę tożsamość.
Robert Važan,

3
uderzył problem dzisiaj, zarówno chrome, jak i firefox pokazują różne certyfikaty w normalnym oknie (stary certyfikat) i trybie incognito (poprawny). Narzędzia wiersza poleceń, takie jak curl lub openssl, zgłaszają prawidłowy certyfikat. Naprawiono przez wyczyszczenie pamięci podręcznej przeglądarki (ctrl + shift + del) - „pliki cookie i inne dane strony” dla Chrome oraz „dane strony offline” dla Firefoxa.
anilech

1
Przynajmniej bieżąca wersja przeglądarki Firefox (66.0) na OSX wydaje się dość mocno trzymać swoją pamięć podręczną. Wczoraj zaktualizowałem certyfikat TLS dla mojej witryny i zarówno CLI, jak openssli Chromium pokazują mi nowy certyfikat. Firefox pokazuje mi stary pomimo przeładowania z wyłączoną pamięcią podręczną, wyczyszczenia wszystkich pamięci podręcznej i danych offline oraz ponownego uruchomienia przeglądarki.
Tad Lispy

20

Nie. Zobacz przegląd IBM SSL

  1. Klient SSL wysyła komunikat „witaj klienta”, który zawiera informacje kryptograficzne, takie jak wersja SSL oraz, w kolejności preferencji klienta, obsługiwane przez klienta CipherSuites. Wiadomość zawiera także losowy ciąg bajtów, który jest wykorzystywany w kolejnych obliczeniach. Protokół SSL pozwala „powitaniu klienta” uwzględnić metody kompresji danych obsługiwane przez klienta, ale obecne implementacje SSL zwykle nie zawierają tego przepisu.

  2. Serwer SSL odpowiada komunikatem „witaj serwer”, który zawiera CipherSuite wybrany przez serwer z listy dostarczonej przez klienta SSL, identyfikator sesji i inny ciąg bajtów losowych. Serwer SSL wysyła również swój certyfikat cyfrowy . Jeśli serwer wymaga certyfikatu cyfrowego do uwierzytelnienia klienta, serwer wysyła „żądanie certyfikatu klienta”, które zawiera listę obsługiwanych typów certyfikatów oraz nazwy wyróżniające dopuszczalnych urzędów certyfikacji.

  3. Klient SSL weryfikuje podpis cyfrowy na cyfrowym certyfikacie serwera SSL i sprawdza, czy wybrany przez serwer CipherSuite jest akceptowalny.

Podsumowanie Microsoft jest podobne. Uścisk dłoni TLS jest również pod tym względem podobny.

W kroku 2 wydaje się, że klient nie może powiedzieć „nie zawracaj sobie głowy wysłaniem certyfikatu serwera, użyję mojej pamięci podręcznej”.

Pamiętaj, że istnieje kilka rodzajów certyfikatów: klient, serwer i urząd certyfikacji. Niektóre z nich są buforowane.


Zmienione oryginalne pytanie wyjaśniające, że jest to certyfikat serwera.
Lorin Hochstein

Nie jest to prawdą, a zakładanie, że nie ma pamięci podręcznej, ponieważ przegląd działania protokołu SSL wyklucza buforowanie, jest dość złym uzasadnieniem. youtube.com/watch?v=wMFPe-DwULM
Evan Carroll

Jedyną pamięcią podręczną, której można użyć, jest sprawdzenie poprawności, ale jest to kompromis w zakresie bezpieczeństwa.
Daniel B

0

Nie jestem pewien, czy mój wkład w jakikolwiek sposób pomoże, ale oto, czego właśnie doświadczyłem: mam witrynę internetową w lazurowej z niestandardową domeną. Próbowałem uzyskać do niego dostęp za pomocą https w chromach, zanim skonfigurowałem powiązanie SSL dla mojej nazwy domeny. Chrome powiedział mi, że witryna nie jest zabezpieczona, co ma sens (ERR_CERT_COMMON_NAME_INVALID). Ale po przesłaniu certyfikatu i skonfigurowaniu powiązania SSL w kolorze lazuru wciąż pojawia się ten sam błąd. Na tym etapie, podczas otwierania nowego prywatnego okna przeglądarki (lub przy użyciu innej przeglądarki) https działało poprawnie.

Ale nigdy nie udało mi się sprawić, by działał w mojej otwartej sesji Chrome. Próbowałem wyczyścić stan SSL, ten sam wynik. Działa po całkowitym ponownym uruchomieniu Chrome.

Prawdopodobnie coś mnie oszukało, ale wyglądało to prawie tak, jakby certyfikat był buforowany ...


Ten błąd oznaczałby, że uzyskałeś dostęp do witryny z identyfikatorem URI innym niż ten, który znajdował się w CN. Czy faktycznie zmieniłeś identyfikator URI, aby uzyskać dostęp do witryny w chrome po skonfigurowaniu powiązania?
Seth

nie, jedyną rzeczą, którą zmieniłem w tym czasie, było wiązanie. Kiedy po raz pierwszy zapytałem https, był on obsługiwany przy użyciu domyślnego certyfikatu Lazur SSL, ale nadal mi go dostarczano po zmianie powiązania z prawidłowym certyfikatem na platformie Azure.
Etienne,

Jak powiedziałeś, skonfigurowałeś powiązanie SSL domeny, czy to oznacza, że ​​masz dostęp do serwera za pomocą swojej domeny od samego początku, czy nie? Błąd wskazywałby, że istnieje różnica między użytym adresem URL a adresem URL, dla którego certyfikat był. O to mi chodziło. Ponadto rzeczywista konfiguracja serwera może mieć duże znaczenie, jeśli pomyślisz o HSTS i tym podobnych.
Seth

1
Krok 1: opublikowano witrynę internetową w lazurach. Na tym etapie ma zarówno domyślny lazurowy adres URL, jak i domyślny certyfikat. Krok 2: skonfiguruj domenę niestandardową dla aplikacji internetowej, teraz mysite.com poprawnie wskazuje witrynę. Certyfikat SSL dla mysite.com nie jest skonfigurowany na tym etapie. Krok 3: W tym momencie, gdy próbuję https strony, pojawia się błąd bezpieczeństwa informujący, że certyfikat nie pasuje (i ma to sens) Krok 4: Instaluję certyfikat SSL dla Mysite.com w lazurowym i STILL ostrzeżenie o bezpieczeństwie wyskakuje z Chrome. NIE pojawia się w żadnej innej przeglądarce lub jeśli otworzę prywatną nawigację.
Etienne,

1
Krok 5: Ponownie uruchamiam Chrome i teraz (i tylko teraz) moja witryna jest obsługiwana przy użyciu prawidłowego certyfikatu SSL. W związku z tym doszedłem do wniosku, że rzeczywiście istniała kwestia buforowania certyfikatu
Etienne,

-1

Niektórzy twórcy przeglądarek planują wprowadzić taki system chaching do wykrywania ataków, takich jak atak na Diginotar w 2011 roku.

Ale w chwili obecnej AFAIK taki system nie jest aktywny w obecnych przeglądarkach. Dlatego nie musisz myśleć o tej sytuacji podczas aktualizacji certyfikatu serwera.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.