Чому кореневі сертифікати CA всі підписані SHA-1 (оскільки SHA-1 застаріло)?

67

Я розумію, що сертифікати SSL більше не можна підписувати за допомогою SHA-1. Однак усі кореневі сертифікати CA (здебільшого) підписані SHA-1. Чи означає це той самий алгоритм, якому більше не довіряють "ти, бабуся, SSL магазин", це чудово для найвищого найкращого захищеного сертифіката світу?

Я щось пропускаю? (використання ключа? розмір ключа?)

ssl ssl-certificate certificate-authority

— 131
джерело

9

Неправда, що "всі" кореневі сертифікати CA - це SHA1.

— Грег Аскеу

5

Кореневі сертифікати - це як вихідні припущення у світогляді. Потрібна віра, щоб довіряти їм.

— Рой Тінкер

@RoyTinker, за винятком сукупної ерго суми (див. Радикальний сумнів, і це відповідь: декартовий скептицизм )?

— Нік Т

1

Перехресний стек: security.stackexchange.com/questions/120301/… та superuser.com/questions/1122069/…

— dave_thompson_085

6

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

— tonysdg

106

Підпис кореневих сертифікатів CA взагалі не має значення, оскільки не потрібно їх перевіряти. Всі вони підписуються самостійно.

Якщо ви довіряєте кореневому сертифікату CA, не потрібно підтверджувати його підпис. Якщо ви не довіряєте цьому, його підпис для вас нічого не вартий.

Редагувати: нижче наведено кілька дуже релевантних коментарів. Мені не комфортно копіювати або перефразовувати їх та брати до них кредит замість їхніх авторів. Але я вітаю людей, щоб додати пояснення до цієї відповіді.

— користувач2233709
джерело

3

Поставляє питання, чому вони взагалі підписані

— Річард Тінгл

42

Тому що система не підтримує сертифікати, які не підписані.

— OrangeDog

Мені здається, що стурбованість, що стосується корінтової кортової церти, - це не "ви не знаєте, звідки у вас коренева церта", а, скоріше, "ви не знаєте, хто ще зміг зламати цю скриньку і використовувати її підписувати все, що вони хочуть ". І з вашої відповіді випливає, що ці два (церт і підпис cert) є окремими проблемами, і що сам cert є належним чином захищеним і незламним?

— Деві Морган

20

Я б пішов ще далі, ніж "немає необхідності їх перевіряти". Метою підпису в ланцюжку сертифікатів є те, що вищий орган посвідчує нижчий орган. Для кореневого CA немає вищої повноваження за визначенням (саме це означає "root"), тому немає нікого, хто міг би підписати сертифікат . Оскільки, як було сказано, сертифікати повинні бути підписані, кореневі ЦС підписуються "фіктивним" підписом, а найпростіший спосіб зробити це - самопідписатись. Отже, не тільки немає необхідності перевіряти, сама ідея перевірки підпису кореневого CA несе сенсу.

— Йорг W Міттаг

13

@DewiMorgan Ви не можете "зламати" кореневу cert при хеш-зіткненні, оскільки клієнт довіряє самій cert , а не її (само-) підпису. Вам доведеться відновити приватний ключ, який є атакою на RSA, а не на хеш-алгоритм.

— zwol

46

Наприкінці дня кореневий сертифікат підписується самостійно. Він ніколи не підписується іншим суб’єктом, крім себе. Кореневий сертифікат отримує свою довіру через позадіапазонні процеси, такі як подання його до списку браузерів довірених видавців або отримання його прийняттям Microsoft для внесення до списку довірених видавців Windows за замовчуванням.

Ці сертифікати (і компанії, які їх самостійно підписали) (нібито, сподіваємось) ретельно перевіряються іншими засобами, ніж лише їхніми підписами.

— Марк Хендерсон
джерело

2

Не кажучи вже про те, що для оновлення кореневого сертифіката потрібно повторно пройти цей позадіапазонний процес.

— Кайтар

4

+1 для "нібито, сподіваюся"

— Натан Осман

6

Єдиний випадок, коли це має значення, - якщо корінь підписаний SHA-1, він може бути відкликаний SHA-1. Тобто, хтось, хто може напасти на SHA-1, може побудувати анулювання для кореня. І я абсолютно впевнений, що браузер не знає, як зберегти це, тому вандал здійснив не більше ніж переривання SSL-з'єднань. Як кульгавий.

— джошудсон
джерело

1

Це цікава думка, але я сумніваюся, що це діятиме саме так. Я здогадуюсь, що кожен агент матиме свою унікальну поведінку, але я сумніваюся, що у будь-яких розробників була ідея, що список відкликання буде використовуватися для управління скасуванням кореневих сертів. Принаймні, якби це працювало в деяких випадках, це було б пов’язано з абстракцією відкликання програмного забезпечення, а не навмисно розробниками.

— Пітер Ехлерт

1

Як зауваження до цього, ДЕЯКІ ЦО вже оновили свої кореневі та проміжні сертифікати до SHA256.

Я знаю, що минулого року GlobalSign оновлював їхні сертифікати, коли ми оновлювали наші сертифікати для підписання коду, тому мені довелося також додати їх до нового ланцюжка.

Ви можете перевірити, які конкретні сертифікати оновлено та які оновлено, але також залишили спадковий сертифікат SHA1 тут => 1

Сподіваюся, що це допомагає.

— B.Kaatz
джерело

0

Що стосується кореневого CA, ви надаєте довіру відкритому ключу CA-пакету, що входить до CRT, незалежно від його самопідпису.

Опис CA з використанням формату файлу .CRT замість неочищеного відкритого ключа .PEM дозволяє згрупувати в ньому більше деталей - наприклад, ім'я CA - (але знову ж таки, підпис не вартий)

— 131
джерело

-1

Існують дуже старі, здебільшого 2006 або попередньої епохи, які вже довіряють закріпленим кореневим сертифікатам SHA1, які браузери приймають, але не нові сертифікати. Пам’ятаєте, коли Firefox та Chrome використовували однозначні цифри?

Сертифікати виходять з ладу, якщо кореневий CA використовує сертифікати SHA1 із значенням Not Before, встановленим на щось після 2014 року. Фактичні обмеження дати залежать від веб-переглядача чи іншої програми. Кабіфорум WebCA зробив це ясно кілька років тому. Перевірте це самостійно:

Створіть приватну кореневу інфраструктуру Центру сертифікатів, підписану SHA1, назвіть її rootSHA1
Запропонуйте rootSHA1 створити CA, що видає, або "проміжний", який видає сертифікати з сертифікатом, прив'язаним до кореня. Назвіть це проміжнимSHA256.
Запропонуйте проміжнийSHA256, що видає CA, генерувати сертифікати, підписані хешем sha256 або більше. Назвіть це webServerSHA256.
Встановіть webServerSHA256 в webServerSHA56.mydomain.com.
Встановіть сертифікати rootSHA1, проміжніSHA256 та webServerSHA256 у відповідні місця в Google Chrome. Встановіть корінь довірених авторів сертифікації Root та інших за допомогою ланцюжка сертифікатів.
Перейдіть у Google Chrome на https://webServerSHA256.mydomain.com/ і переконайтеся, що не існує зеленого замка для webServerSHA256. Тест не вдається.

— rjt
джерело

Це зовсім неправильно. Проміжні серти (та EE./leaf certs) дійсно потребують SHA2, але корені - ні. Chrome приймає власну ланцюжок сертифікатів Google через їх приватний CA (Google Internet Authority G3) до GlobalSign Root CA R2 - що є SHA1 - і (не дивно).

— dave_thompson_085

Так, ці закріплені сертифікати SHA1 приймаються, але не будь-які нові кореневі сертифікати SHA1, навіть якщо ви додасте їх до власного магазину сертифікатів Trusted Root. До моєї відповіді додано тестовий випадок.

— rjt