Я ошибаюсь, понимая, что это было одно из обнаружений коллизий, они могли выдать себя за корневой CA Verisign и использовать его для создания промежуточного и затем серверного сертификата, которому доверял бы браузер или ОС.
Вы в основном ошибаетесь из-за возможности олицетворения корневого ЦС с помощью всего лишь коллизии хешей, поскольку для успешной атаки на сертификат корневого ЦС потребуется больше шагов, как подробно объясняется ниже.
Однако, как объясняется ниже, вы можете успешно олицетворять промежуточный CA, используя только коллизию хешей.
Короче говоря, клиент проверяет, соответствует ли зашифрованная подпись RSA на сертификате зашифрованной подписи RSA, которая будет сгенерирована с использованием открытого ключа ЦС для подписи хеша байтов сертификата TBS в указанном сертификате. Хотя открытый ключ CA можно использовать для проверки зашифрованной подписи RSA хэша сертификата TBS, необходимо знать закрытый ключ CA, чтобы сгенерировать подпись, позволяющую выдавать себя за CA.
Предположим, вы смогли сгенерировать такое хеш-коллизирование части TBS корневого сертификата CA, изменив его так, чтобы он содержал открытый ключ, для которого вы знаете закрытый ключ, проблема в том, что ваш модифицированный сертификат CA будет содержать другой открытый ключ, чем Действительный сертификат CA и все клиенты, проверяющие сертификат, подписанный CA, будут иметь локально установленную копию реального сертификата CA. При проверке подписанного сертификата клиент извлекает отпечаток или подпись подписывающего лица из подписанного сертификата и извлекает открытый ключ своей локальной копии этого сертификата при попытке проверить подпись сертификата, подписанного этим СА.
Поэтому, чтобы выдать себя за корневой CA и сгенерировать зашифрованную подпись RSA, клиент будет доверять, прежде всего вам нужно найти коллизию части TBS сертификата корневого CA из сгенерированного вами сертификата TBS, который содержит общедоступный, для которого вы знаете частный ключ. Вам также необходимо найти такое столкновение, которое проходит проверку подписи RSA с использованием открытого ключа CA. На этом этапе у вас будет поддельный сертификат с коллизией хэша SHA1 и коллизией подписи RSA. Если каким-то образом вы выполнили все это, вам, наконец, нужно обмануть клиента, чтобы он извлекал ваш поддельный сертификат при поиске сертификата корневого ЦС, а не извлекал их локальную копию сертификата корневого ЦС.
Почти во всех мыслимых сценариях, в которых вы могли бы выполнить все эти вещи, были бы гораздо более эффективные возможности атаки, которые не требовали необходимости сначала находить хеш-коллизию SHA1 сертификата, который содержит известный вам закрытый ключ, который также генерирует RSA коллизия зашифрованных подписей, которые затем должны обмануть клиента, чтобы использовать его для проверки подписи, вместо того, чтобы использовать сертификат подлинного корневого ЦС, который, учитывая тот факт, что клиент ему доверяет, будет храниться локально на клиенте.
Вместо этого более вероятной атакой будет обнаружение хэш-конфликта сертификата промежуточного ЦС, с помощью которого вы можете использовать олицетворение промежуточного ЦС для подписи сертификатов. Эта атака более вероятна по двум причинам: во-первых, вы можете легко заставить клиента загрузить сертификат промежуточного ЦС, а во-вторых, коллизия хеш-кода будет проверяться по зашифрованной подписи доверенного ЦС RSA, поэтому существует необходимость попытаться обмануть клиента. доверять CA, который подписал сертификат.
Если клиенту предоставляется сертификат с веб-сайта, подписанного посредником ЦС, для которого у него нет локальной копии, он попытается загрузить ЦС посредника с веб-сайта, который представил указанный билет, с веб-сайта, который представил сертификат в первое место. Напоминая, что клиент возьмет хэш части TBS сертификата этого посредника и затем проверит, что зашифрованная подпись RSA на этом сертификате действительно была подписана с использованием открытого ключа локально доверенного CA или цепочки CA, которая ведет к локально доверенному CA успешная атака теперь упрощена до генерации коллизии хэшей части сертификата ЦС действительного посредника.
Однажды можно заменить открытый ключ сертификата проверяемого промежуточного ЦС открытым ключом, для которого известен закрытый ключ, а затем изменить другие байты по мере необходимости, чтобы сгенерировать коллизию хеша с проверяемым сертификатом. Этот этот измененный сертификат может затем использоваться для подписи других сертификатов. Такие подписанные сертификаты могут, например, быть установлены на веб-сервере вместе с этим модифицированным промежуточным сертификатом. Когда клиент получает сертификат, он считывает отпечаток CA, который его подписал. Если у клиента не установлен локальный сертификат этого посредника, он загрузит сертификат с веб-сайта и получит сертификат, который он проверяет. Затем клиент сгенерирует хэш сертификата веб-сайта TBS и проверит, что он был подписан цифровой подписью с использованием открытого ключа в сертификате промежуточного ЦС, который он загрузил. Этот процесс является рекурсивным в том смысле, что он затем создает хэш части TBS загруженного промежуточного сертификата и считывает отпечаток CA, подписавшего промежуточный сертификат. Затем он выполнит поиск сертификата этого CA и проверит, что зашифрованная подпись RSA на промежуточном сертификате была сгенерирована с использованием открытого ключа выдающего CA, чтобы подписать хэш сертификата TBS в промежуточном сертификате. Поскольку промежуточный хэш сертификата TBS в промежуточном сертификате совпадает с хешем исходного сертификата посредника, а подпись также совпадает с подписью оригинальной подписи посредника, сертификат нашего модифицированного посредника CA будет проверяться. Клиент завершит процесс рекурсивно, пока не найдет сертификат, выданный ЦС, которому он доверяет, и проверка точки успешно завершена, и мы успешно выделили себя за промежуточного ЦС.
NIST и АНБ предупредили, что
«SHA-1 нельзя доверять после января 2016 года из-за растущей практичности того, что хорошо финансируемый злоумышленник или правительство могут обнаружить коллизию хеш-кода SHA-1, позволяющую им олицетворять любой веб-сайт SSL», и Microsoft и Google начали предупреждать год позже соединений, которые используют SHA-1.
http://windowsitpro.com/security/your-organization-using-sha-1-ssl-certificates
Важно, чтобы цепочка сертификатов была зашифрована сертификатами SHA-2. (Цепочка сертификатов состоит из всех сертификатов, необходимых для сертификации конечного сертификата.) Это означает, что любые промежуточные сертификаты должны также использовать SHA-2 после 1 января 2017 года.
Как правило, ваш CA предоставляет промежуточный и корневой сертификаты CA, когда они предоставляют сертификат SHA-2. Иногда они предоставляют ссылку для загрузки цепочки сертификатов. Важно, чтобы вы обновили эту цепочку сертификатами SHA-2.
В противном случае Windows может не доверять вашему новому сертификату SHA-2.
Корневые сертификаты - это отдельная история. На самом деле это могут быть сертификаты SHA-1, поскольку Windows неявно доверяет этим сертификатам, поскольку ОС напрямую доверяет открытому ключу корневого сертификата. Корневой сертификат является самозаверяющим и не подписывается другим лицом, которому предоставлены полномочия.
По той же причине любой самозаверяющий сертификат может использовать алгоритм SHA-1. Например, Microsoft Exchange Server генерирует самозаверяющие сертификаты SHA-1 во время установки. Эти сертификаты освобождены от новой политики SHA-2, поскольку они не связаны с ЦС. Я ожидаю, однако, что будущие выпуски Exchange будут использовать SHA-2 в самозаверяющих сертификатах.
