Насколько безопасен SSL?

Ответ 1

Предполагая, что все правильно настроено/защищено, и мы говорим о 128-битных ключах, значительно дольше, чем возраст Вселенной.

Я бы заметил, что предыдущие трещины в SSL полагались на "дыру" в MD5, что вызвало изменение метода валидации..

Я также хотел бы отметить, что это не освобождает вас от атак man-in-the-middle или даже кого-то, угоняющего частный сертификат целевой компании (обратите внимание, что закрытые ключи должны быть защищены с помощью надежного пароля, но для уменьшения такого риска, а затем ключ отменяется, если такое событие происходит). Прочитайте обзор на высоком уровне о том, как работает SSL здесь.

Ответ 2

У SSLv2 были проблемы с атаками MITM, способными вызывать согласование шифров более низкого качества. В те дни это обычно включало в себя список стилей "качества экспорта", которые были намеренно слабыми и могли быть подвергнуты трещинам только грубой силой.

SSLv3/TLSv1 эффективно разрешил проблему переговоров, и вскоре после того, как многие из более слабых шифров качества с тех пор были удалены из доступности, теперь, когда ограничения на экспорт в США были отменены и появились различные сканеры соответствия.

Генерация PRF в SSL использует как MD5, так и SHA1 в попытке предотвратить компрометацию системы, если один из алгоритмов хеширования был скомпрометирован. Один из способов атаки на SSL заключается в том, чтобы в значительной степени скомпрометировать оба алгоритма, используемые в функции PRF. IIRC - это просто какой-то XOR ввода, проходящий через оба.

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

(Вы можете скомпрометировать шифр (RSA, AES..etc), но это не обязательно переводит на сам SSL-протокол)

На мой взгляд, наиболее практичные криптоактивные атаки на SSL - это побочные атаки против конкретных шифров. Известно, что AES уязвим против временных атак. Обычно для них требуются высококачественные сети с низкой задержкой (локальный ethernet). Во многих системах есть "ослепляющие" объекты, которые просто добавляют искусственную задержку в процесс, чтобы уменьшить вероятность успешной синхронизации времени. (В основном, длина времени, необходимого для выполнения определенных последовательностей кода, может быть использована для восстановления достаточной информации для компрометации системы).

И, наконец, моя любимая слабость SSL - это атаки на "надежность" системы. Независимо от используемых алгоритмов/шифров шифрование бесполезно без доверия.

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

Сегодня и сегодня мы сталкиваемся с ситуацией, когда десятки органов сертификации перечислены практически в каждом браузере на планете. Под каждым из них находятся несколько промежуточных органов подписи, которыми управляет каждая из CA/downlines.

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

Это требует только компромисса любого CA, промежуточного, реселлера... и т.д., чтобы эффективно скомпрометировать весь якорь доверия (фактически планета Земля). Это можно и было сделано: иногда случайно, иногда преднамеренно. Если ваш IE использовать для себя:

Инструменты-Свойства обозревателя-Сертификаты-Неверные издатели.. К сожалению,...

Существуют смягчающие факторы: даты истечения срока действия сертификата, списки отзыва..., но, на мой взгляд, проблема доверия остается главной уязвимостью всей системы.

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

Ответ 3

Стив Гибсон объяснил, как работает протокол в недавнем подкасте Security Now. Если вас интересует специфика, это определенно стоит слушать.

Ответ 4

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

Однако атаки на стороне канала и другие формы атак на реализацию очень реальны и требуют серьезного внимания. Это включает в себя такие вещи, как человек в средних атаках, паршивые полномочия SSL-сертификатов, физические атаки на хост и т.д.

Ответ 5

Зависит от длины ключа, алгоритма и фермы серверов, чтобы расшифровать его.

Ответ 6

Ну, у SSL v2 были некоторые недостатки, SSL v3 довольно безопасен. Время будет зависеть от длины ключа сертификата и насколько быстро вы сможете расшифровать SHA-1 с помощью RSA-шифрования.

Достаточно безопасно, я бы сказал:)

Ответ 7

Вы упомянули "отправить пароль" через SSL.

Возможно, вопрос здесь в том, как вы

• Защитите пароли (хранятся как хэш, открытый текст и т.д.)
• Ограничение скорости при попытке входа в систему (например, если вы разрешаете макс 1 в секунду грубую силу из внешних источников, потребуется очень много времени).
• Важная информация о SSL: где и как хранится ваш закрытый ключ (зашифрованный на диске, внутри специального нечитаемого оборудования)?

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

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

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

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

Ответ 8

пока какая-то яркая искра не увидит дыру.

Мы думали, что ssl был защищен до конца времени - извините altCognito = > , а затем некоторые поняли, что md5 может быть небезопасным.

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

Помните, что это всегда думают люди, реализованные людьми, а затем управляются компьютерами.

Вы видите там 2 вопроса?

Также недавно

http://www.schneier.com/blog/archives/2008/12/forging_ssl_cer.html

и для обсуждения SSL3 читайте экспертов - http://www.schneier.com/paper-ssl.html

http://www.darkreading.com/security/attacks/showArticle.jhtml?articleID=212700234

Ответ 9

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

Реалистичная угроза заключается не в том, что кто-то собирается взломать SSL - это гораздо лучше, если будет найден какой-то другой способ получения интересных данных.