Комментарии 42
Хром давно уже, вроде, предупреждает об этом и грозится в будущих версиях вообще выбросить поддержку подписи SHA1.
И Chrome/Chromium, и Firefox.
Вы вот это почитайте. Там спецы из Symantec, Entrust, Microsoft, Trend Micro предлагают отодвинуть дэдлайн до которого еще будут выпускаться сертификаты с SHA-1.
НЛО прилетело и опубликовало эту надпись здесь
Коллизия для SHA-1 за 10 дней
Поэтому, если быть корректным, то полученный результат — не коллизия в SHA-1.
Вот как с такими людьми быть, а?
Если использовать ботнет с хорошими видеокарточками, то почему бы и нет? Но майнинг биткоинов, скорее всего, пока еще более выгоден.
Это печалька. Навскидку, sha-1 используется в git, websocket, майкрософтовских сертификатах формата x.509 :( Или уже нет?
НЛО прилетело и опубликовало эту надпись здесь
Git использует SHA-1 не для безопасности, а для проверки целостности.
Более подробно здесь
wiki
en.wikipedia.org/wiki/SHA-1#Data_integrity
Revision control systems such as Git and Mercurial use SHA-1 not for security but for ensuring that the data has not changed due to accidental corruption. Linus Torvalds has said about Git:
«If you have disk corruption, if you have DRAM corruption, if you have any kind of problems at all, Git will notice them. It's not a question of if, it's a guarantee. You can have people who try to be malicious. They won't succeed.
[...]
Nobody has been able to break SHA-1, but the point is the SHA-1, as far as Git is concerned, isn't even a security feature. It's purely a consistency check. The security parts are elsewhere, so a lot of people assume that since Git uses SHA-1 and SHA-1 is used for cryptographically secure stuff, they think that, OK, it's a huge security feature. It has nothing at all to do with security, it's just the best hash you can get.
[...]
I guarantee you, if you put your data in Git, you can trust the fact that five years later, after it was converted from your hard disk to DVD to whatever new technology and you copied it along, five years later you can verify that the data you get back out is the exact same data you put in.
[...]
One of the reasons I care is for the kernel, we had a break in on one of the BitKeeper sites where people tried to corrupt the kernel source code repositories.»
Nonetheless, without the second preimage resistance of SHA-1, signed commits and tags would no longer secure the state of the repository as they only sign the root of a Merkle tree.
en.wikipedia.org/wiki/SHA-1#Data_integrity
Более подробно здесь
(Если SHA-1 используется для проверки целостности данных) = (скоро будет возможна, или уже возможна, подмена данных с получением того же хэша)
Да, но при этом очень маловероятно, что эти данные будут являться корректным текстом. Почему-то все об этом забывают. А компилятор на мусор в исходниках будет вопить сразу :)
Смысл в том, что можно сделать корректный текст и добавить воды до достижения коллизии. Например в комментариях.
Можно, но я оооочень сомневаюсь, что там будут строго текстовые символы :)
Думаю, как только появится пруф — то быстро сменят на sha256, например :)
Думаю, как только появится пруф — то быстро сменят на sha256, например :)
нет, никто не говорил о том, что данные, приводящие к колизии хеша, должны быть хоть как-то похожи на оригинальный текст. Там любой набор данных произвольного размера.
но зачем? Вы вики читали?
ensuring that the data has not changed due to accidental corruption
Как бы ограничение записи в репозиторий кем попало задача не самого git, а тех кто им пользуется. Нужно только убедиться, что новый объект не затрёт уже существующий при совпадении хэшей.
НЛО прилетело и опубликовало эту надпись здесь
А ведь все в курсе, что SHA-1 используется в качестве единственного алгоритма хэширования для Windows 7? Windows 8+ Понимает уже Sha-256. Таким образом, проверять целостность драйверов, основываясь на целостности подписи будет нельзя.
Учитывая, что валидная цифровая подпись разаработчика драйвера на черном рынке стоит порядка 20к$ волноваться пока рано, но…
Учитывая, что валидная цифровая подпись разаработчика драйвера на черном рынке стоит порядка 20к$ волноваться пока рано, но…
Открытка Яндекс.Деньгам, которые до сих пор на SHA-1.
Так, а что делать счастливым пользователям StartSSL у которых корневой сертификат — SHA-1, а промежуточные — SHA-2?
тут волноваться не надо. Потому что корневые сертификаты прописаны в ОС/браузеры, и не проверяются по отпечатку.
Они-то не проверяются, но нет ли риска, что кто-то создаст промежуточный сертификат и сертификат сайта якобы от StartSSL и, взломав сайт, подставит их вместо настоящих? Ну а там почти идеальный MiTM, если владельцы сайта заранее «гвоздями не прибили».
Промежуточный сертификат будет подписан SHA-2.
Если ваш браузер «увидит» в цепочке корневой сертификат, отличный от того, что хранится в доверенных корневых (или не подписанный другим доверенным корневым), то выдаст предупреждение.
Еще раз: браузер не будет проверять подпись корневого УЦ, а просто проверит, есть ли он в списке доверенных.
Если ваш браузер «увидит» в цепочке корневой сертификат, отличный от того, что хранится в доверенных корневых (или не подписанный другим доверенным корневым), то выдаст предупреждение.
Еще раз: браузер не будет проверять подпись корневого УЦ, а просто проверит, есть ли он в списке доверенных.
Видимо я чего-то упорно недопонимаю, но кто мешает злоумышленнику создать промежуточный сертификат SHA-2 который якобы подписан тем самым корневым SHA-1? Браузер и система увидят отпечаток доверенного корневого и пропустят подделку. Как я это вижу.
Возможно, я не понимаю вас. Поправьте, если не прав:
— Вы создаете свой корневой УЦ, который имеет такую же подпись, как и один из доверенных (SHA-1).
— Вы подписываете этим корневым УЦ сертификат (SHA-2).
Если я правильно понял предлагаемую последовательность, то отвечаю: для корневого сертификата браузер и система доверяют открытому ключу, а не проверяют подпись. Подобрать закрытый ключ, зная открытый — задача отличная от нахождения коллизии в алгоритме хэширования.
— Вы создаете свой корневой УЦ, который имеет такую же подпись, как и один из доверенных (SHA-1).
— Вы подписываете этим корневым УЦ сертификат (SHA-2).
Если я правильно понял предлагаемую последовательность, то отвечаю: для корневого сертификата браузер и система доверяют открытому ключу, а не проверяют подпись. Подобрать закрытый ключ, зная открытый — задача отличная от нахождения коллизии в алгоритме хэширования.
У них есть корневой сертификат с SHA-2: www.startssl.com/certs
Есть ли он в основных ОС, mozilla ca-certificates, jre? Если нет — то он пока нафиг никому не сдался. А intermediate ca с sha-2 уже есть у большинства нормальных ca.
Mozilla добавила его в 2012 году: bugzilla.mozilla.org/show_bug.cgi?id=602750
У Qualys SSL Test к нему нет замечаний.
У Qualys SSL Test к нему нет замечаний.
А в JRE они вообще есть?
Любопытно. Ждут нормального распространения этого сертификата по системам или просто забыли создать свежие промежуточные сертификаты?
У них вроде все есть и работает. Чего они ждут мне неизвестно.
Результат с Qualys SSL Test: habrastorage.org/files/78e/f3b/09e/78ef3b09e1774d0daf030569326894c7.png
Результат с Qualys SSL Test: habrastorage.org/files/78e/f3b/09e/78ef3b09e1774d0daf030569326894c7.png
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Коллизия для SHA-1 за 100$ тыс