Dlaczego wszystkie certyfikaty główne CA są podpisane przez wszystkie SHA-1 (skoro SHA-1 jest przestarzałe)?

67

Rozumiem, że certyfikatów SSL nie można już podpisywać przy użyciu SHA-1. Jednak wszystkie certyfikaty główne CA są podpisane SHA-1 (głównie). Czy to oznacza, że ten sam algorytm, który nie jest już zaufany w przypadku „sklepu babci SSL”, jest odpowiedni dla najwyższego, najlepiej zabezpieczonego certyfikatu świata?

Czy coś brakuje? (użycie klucza? rozmiar klucza?)

ssl ssl-certificate certificate-authority

— 131
źródło

9

Nie jest prawdą, że „wszystkie” certyfikaty główne CA to SHA1.

— Greg Askew

5

Certyfikaty główne są jak początkowe założenia w światopoglądzie. Zaufanie wymaga wiary.

— Roy Tinker,

@ RoyTinker oprócz cogito ergo sum (patrz radykalne wątpliwości i odpowiedź: kartezjański sceptycyzm )?

— Nick T

1

Cross-stack: security.stackexchange.com/questions/120301/... i superuser.com/questions/1122069/…

— dave_thompson_085

6

@NickT: Play it safe - cogito ergo cogito ;-)

— tonysdg

106

Podpis certyfikatów głównego urzędu certyfikacji w ogóle nie ma znaczenia, ponieważ nie trzeba ich weryfikować. Wszystkie są podpisane przez siebie.

Jeśli ufasz certyfikatowi głównego urzędu certyfikacji, nie trzeba weryfikować jego podpisu. Jeśli nie ufasz, jego podpis jest dla ciebie bezwartościowy.

Edycja: poniżej znajduje się kilka bardzo istotnych komentarzy. Nie czuję się komfortowo, kopiując lub przeredagowując je i uznając je za autorów. Ale witam ludzi, aby dodali wyjaśnienia do tej odpowiedzi.

— użytkownik2233709
źródło

3

Pytanie, dlaczego w ogóle są podpisane

— Richard Tingle

42

Ponieważ system nie obsługuje certyfikatów, które nie są podpisane.

— OrangeDog

Wydaje mi się, że problemem związanym z pękającym certyfikatem root nie jest „nie wiesz, skąd masz certyfikat root”, ale raczej „nie wiesz, kto jeszcze był w stanie złamać ten certyfikat i go użyć podpisywać, co chcą ”. I z twojej odpowiedzi wydaje się, że te dwa (cert i podpisywanie certyfikatów) są osobnymi obawami i że sam certyfikat jest odpowiednio bezpieczny i niemożliwy do zidentyfikowania?

— Dewi Morgan

20

Chciałbym pójść nawet dalej niż „nie ma potrzeby ich weryfikować”. Celem podpisu w łańcuchu certyfikatów jest to, że wyższy organ certyfikuje niższy organ. W przypadku głównego urzędu certyfikacji z definicji nie ma wyższych uprawnień (to znaczy „root”), więc nie ma nikogo, kto mógłby podpisać certyfikat . Ponieważ, jak wspomniano, certyfikaty muszą być podpisane, główne urzędy certyfikacji są podpisywane „obojętnym” podpisem, a najprostszym sposobem na to jest samopodpisanie. Tak więc nie tylko nie ma potrzeby weryfikacji, sam pomysł weryfikacji podpisu głównego urzędu certyfikacji nie ma sensu.

— Jörg W Mittag

13

@DewiMorgan Nie można „złamać” certyfikatu głównego z kolizją skrótu, ponieważ klient ufa samemu certyfikatowi , a nie jego (własnemu) podpisowi. Będziesz musiał odzyskać klucz prywatny, który jest atakiem na RSA, a nie na algorytm skrótu.

— zwolnienie

46

Pod koniec dnia certyfikat główny jest samopodpisany. Nigdy nie jest podpisany przez inny byt oprócz siebie samego. Certyfikat główny zyskuje zaufanie poprzez procesy pozapasmowe, takie jak przesłanie go do listy zaufanych wydawców w przeglądarkach lub uzyskanie akceptacji przez Microsoft w celu umieszczenia na domyślnej liście zaufanych wydawców systemu Windows.

Certyfikaty te (i firmy, które je podpisały) są (rzekomo, mam nadzieję) dokładnie sprawdzone za pomocą innych środków niż tylko ich podpisy.

— Mark Henderson
źródło

2

Nie wspominając o tym, że aktualizacja certyfikatu głównego wymaga powtórzenia tego procesu poza pasmem.

— Kaithar,

4

+1 za „rzekomo, miejmy nadzieję”

— Nathan Osman,

6

Jedyny przypadek, w którym ma to znaczenie, to jeśli root jest podpisany przez SHA-1, może zostać odwołany przez SHA-1. Oznacza to, że ktoś, kto może zaatakować SHA-1, może skonstruować odwołanie dla roota. I jestem absolutnie pewien, że przeglądarka nie wie, jak to utrzymać, więc wandal osiągnął nie więcej niż zerwanie połączeń SSL. Jak kiepsko.

— Joshudson
źródło

1

To ciekawa myśl, ale wątpię, żeby to działało właśnie w ten sposób. Domyślam się, że każdy agent miałby swoje własne unikalne zachowanie, ale wątpię, czy którykolwiek deweloper miał pomysł, aby lista odwołań była używana do zarządzania odwoływaniem certyfikatów root. Przynajmniej, jeśli zadziałałoby to w niektórych przypadkach, byłoby to spowodowane abstrakcją odwołania oprogramowania, a nie celowo przez programistów.

— Peter Oehlert,

1

Uwaga: w tym przypadku NIEKTÓRE urzędy certyfikacji już i tak aktualizują swoje certyfikaty root i pośrednie do SHA256.

Wiem, że w zeszłym roku GlobalSign aktualizował swoje certyfikaty, ponieważ aktualizowaliśmy nasze certyfikaty do podpisywania kodu, więc musiałem również dodać do nich nowy łańcuch.

Możesz sprawdzić, które konkretne certyfikaty zostały zaktualizowane, a które zaktualizowały, ale pozostawił również starszy certyfikat SHA1 tutaj => 1

Mam nadzieję, że to pomaga.

— B.Kaatz
źródło

0

W przypadku głównego urzędu certyfikacji dajesz zaufanie kluczowi publicznemu urzędu certyfikacji - umieszczonemu w CRT - niezależnie od jego własnego podpisu.

Opisywanie urzędu certyfikacji przy użyciu formatu pliku .CRT zamiast surowego klucza publicznego. PEM pozwala na zawarcie w nim większej ilości szczegółów - np. Nazwy urzędu certyfikacji - (po raz kolejny podpis jest bezwartościowy)

— 131
źródło

-1

Istnieją już bardzo stare, głównie zaufane, przypięte certyfikaty główne SHA1 z epoki 2006 lub wcześniejszej, które są akceptowane przez przeglądarki, ale nie ma żadnych nowszych certyfikatów. Pamiętasz, kiedy Firefox i Chrome były wersjonowane przy użyciu pojedynczych cyfr?

Certyfikaty kończą się niepowodzeniem, jeśli główny urząd certyfikacji korzysta z certyfikatów SHA1 z ustawieniem Nie wcześniej na coś po 2014 r. Rzeczywiste ograniczenia dat zależą od przeglądarki lub innej aplikacji. Cabforum WebCA wyjaśniło to kilka lat temu. Sprawdź to sam:

Utwórz prywatną infrastrukturę głównego ośrodka certyfikacji podpisaną za pomocą SHA1, nazwij ją rootSHA1
Niech rootSHA1 utworzy „wydający” urząd certyfikacji lub „pośredni” urząd certyfikacji, który wystawia certyfikaty z certyfikatem powiązanym z katalogiem głównym. Nazwij to pośrednim SHA256.
Poproś, aby pośredniczący urząd certyfikacji wydający SHA256 wygenerował certyfikaty podpisane hashem sha256 lub większym. Nazwij to webServerSHA256.
Zainstaluj webServerSHA256 w webServerSHA56.mydomain.com.
Zainstaluj certyfikaty rootSHA1, pośredniSHA256 i webServerSHA256 w odpowiednich lokalizacjach w Google Chrome. Zainstaluj katalog główny w Zaufanych głównych urzędach certyfikacji i innych z łańcuchem certyfikatów.
Przejdź do Google Chrome na https://webServerSHA256.mydomain.com/ i sprawdź, czy nie ma zielonej kłódki dla webServerSHA256. Test kończy się niepowodzeniem.

— rjt
źródło

To całkiem źle. Pośrednie certyfikaty (i certyfikaty EE./leaf) wymagają SHA2, ale root nie. Własne certyfikaty Google łączą się przez ich prywatny urząd certyfikacji (Google Internet Authority G3) do GlobalSign Root CA R2 - czyli SHA1 - i (bez zaskoczenia) są akceptowane przez Chrome.

— dave_thompson_085

Tak, te przypięte certyfikaty SHA1 są akceptowane, ale nie nowe certyfikaty główne SHA1, nawet jeśli dodasz je do własnego magazynu certyfikatów Trusted Root. Dodano przypadek testowy do mojej odpowiedzi.

— rjt