Безопасно ли соединение HTTPS без действительного сертификата SSL?

Ответ 1

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

Ответ 2

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

Алиса и Боб соглашаются на случайное число х. Алиса рассчитывает x ^a где a - большое простое число, известное только Алисе, и отправляет его Бобу. Боб вычисляет x ^b и отправляет его Алисе. Алиса вычисляет (x ^b) ^a а Боб вычисляет (x ^a) ^b. Поскольку (x ^a) ^b= (x ^b) ^a= x ^ab Алиса и Боб теперь знают номер x ^ab и могут использовать его в качестве ключа шифрования. Красота этого заключается в том, что Боб не знает, Алиса не знает b, и любые подслушивающие устройства не знают ни одного номера (поскольку вычисление a из x ^a в случае больших чисел, потребовались бы годы).

Как подчеркивает суперкарт, это само по себе все еще подвержено атаке "человек в середине", и поэтому по крайней мере один конец транзакции должен аутентифицироваться с использованием сертификата. Чтобы быть точным, это не сервер, который проверяет это, это браузер, и большинство браузеров позволят пользователю продолжить, если сертификат недействителен (или, возможно, даже мусор). В этом случае соединение будет значительно более безопасным, чем обычное соединение. Чтобы прослушать, вам нужно будет иметь возможность манипулировать IP-маршрутизацией или поиском DNS, и вам нужно будет настроить его до того, как будет выполнено соединение, что нелегко сделать.

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

Ответ 3

Если проверка сертификатов SSL не проводилась, то кто-то, кто перехватил канал связи, мог захватить запрос на подключение к https://www.acmebank.com, отправить его собственный запрос на www.acmebank.com и переговоры с ключами как с acmebank.com, так и с пользователем. После этого он может получать каждый кусочек данных от пользователя, расшифровывать с помощью ключа пользователя и шифровать ключом acmebank, а также делать данные с сайта acmebank.com. Чистым эффектом было бы то, что ни пользователь, ни acmebank не увидели бы что-то не так, но перехватчик сможет расшифровать все данные между пользователем и acmebank. Пользователь и банк будут использовать разные ключи для обработки своего сообщения, но ни один из них не узнает об этом. Добавление любого стандартного аспекта к протоколу, чтобы узнать, какой ключ используется, не помогло бы, поскольку перехватчик мог обнаружить такие запросы и соответствующим образом изменить ответы.

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

Ответ 4

Больше не беспокойтесь о недействительном сертификате ssl. Теперь вы можете генерировать бесплатный действительный сертификат браузера для своего сервера так же легко, как вы создадите сертификат snakeoil (self-signed, browser invalid). Пойдите https://letsencrypt.org/ бесплатно и открывайте для вкладов.

Ответ 5

Неа. То, что вы делаете при использовании HTTPS, говорит браузеру подключиться через другой порт (443), тогда как обычно вы подключаетесь через (80). Без сертификата сервер откажется от соединения. HTTPS просто невозможно без сертификата. Посмотрите здесь, и вы увидите сертификат , чтобы он работал.

Ответ 6

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