TLS / SSLv3 небезопасен?

Question

Идея создания сетевого приложения F2F, о котором я только что читал, посвящена безопасному общению. Я быстро согласился с идеей использования TLS / SSL в качестве основы для любого обмена данными, поскольку он использует шифрование с открытым ключом на уровне протокола и, таким образом, идеально подходит для моих нужд. Однако я был удивлен, прочитав (в википедии), что новейшая версия TLS, SSLv3 использует сочетание MD5 и SHA-1 «потому что, если в одном из этих алгоритмов будет обнаружена какая-либо уязвимость, другой предотвратит ее взлом SSLv3». Однако, насколько я понимаю, в последнее время оба были признаны ошибочными!

Итак, мои вопросы таковы:
Не означает ли это, что SSLv3 в основном ошибочен, или я не читаю достаточно близко?
И если да, то существует ли «безопасная» альтернатива SSLv3?

Answer 1

Недостатки MD5 и SHA-1 не влияют на использование MD5 и SHA-1 в TLS.Однако, если вы обнаружите, что TLS неприемлемо из-за использования MD5 или SHA-1 (например, из-за того, что какой-то регламент предписывает поэтапный отказ от MD5 и SHA-1 или, возможно, вы считаете это плохим связям с общественностью), вы можете расследовать SSH , в котором используются аналогичные понятия.

Answer 2

PRF, используемый в TLSv1 и во всех более ранних версиях SSL, использует xor MD5 и SHA1. Возможны столкновения с обоими алгоритмами хеширования. Коллизии MD5 гораздо проще генерировать. Из википедии 2 ^ 24 MD5 против 2 ^ 63 операций SHA1. В TLSv2 PRF, вместо того, чтобы быть жестко закодированным, теперь может согласовываться во многом таким же образом, как базовые шифры в более ранних версиях SSL. Первоначально необходимо реализовать для TLSv2 несмешанный SHA2.

Однако тот факт, что хеш уязвим для коллизий, не обязательно делает его небезопасным для всех приложений.

Например, довольно опасно использовать только уязвимые хеши для проверки подписи файла, потому что очень возможно изменить данные таким образом, чтобы сохранить исходную подпись. (При обнаружении столкновения)

В случае PRF (псевдослучайной функции), что вы хотите сделать, это обеспечить предсказуемый вывод, основанный на знании секрета, который не может быть реально реверсирован для получения входного секрета. В этом случае успешный поиск столкновений не так полезен, как в предыдущем случае.

Поиск коллизий должен по-прежнему относиться к любому использованию алгоритма хеширования, поскольку история показала, что он может открыть двери для БУДУЩЕГО обнаружения гораздо более значительных уязвимостей.

Лично меня больше всего беспокоит TLS в предыдущем случае, когда MD5 / SHA1 обычно используется для проверки подписи при проверке цепочки доверия между корневыми и промежуточными сертификатами. Создание посредников путем генерации столкновений было успешно продемонстрировано.