Диффи-Хеллмана вместо SSL?

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

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

Просто для очевидного примера, использование DH (самого по себе) Man в средней атаке довольно просто. Если я смогу заставить вас подключиться к моему серверу вместо того, который вы намеревались сделать, я могу использовать DH для установления «безопасного» сеанса с вами. Затем я подключаюсь к серверу, который вы изначально намеревались использовать. Каждый пакет, который я получаю от вас, я расшифровываю, повторно шифрую с помощью ключа, который я использовал для подключения к этому серверу, и отправляю на этот сервер. Я делаю то же самое со всеми его ответными пакетами. Для вас все выглядит так, как будто оно было получено непосредственно с исходного сервера, и сделанная вами покупка (например) работает как обычно. Единственное, что изменится, - это то, что я также сохраню номер вашей кредитной карты, и когда вы попытаетесь заправить свою машину топливом на следующий день, плата будет отклонена, потому что тем временем я потратил весь ваш кредит.

Аутентификация в SSL, по крайней мере, предназначена для предотвращения этого. Если ваш браузер попытался подключиться (например) к www.amazon.com, он должен выдать вам предупреждение, если в моем сертификате SSL не указано, что он был выпущен на www.amazon.com - и ЦС не должен выдавать такой сертификат кому угодно, кроме Amazon.

DH сам по себе даже не гарантирует большей части того, что я сказал выше. Сам по себе DH - это просто способ обмена ключами (или, возможно, это можно было бы сформулировать как «обмен информацией, необходимой обеим сторонам для создания идентичных ключей, никогда не обмениваясь самим ключом в открытом виде»). После того, как обе стороны получат ключ, они могут (и предположительно будут) использовать его для шифрования / дешифрования данных, но это шифрование фактически отделено от самого DH.

Фактически Diffie-Hellman является частью SSL. Но одна часть не заменяет другие.

Из здесь SSL Diffie-Helman используется для:

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

Вы можете использовать анонимное соглашение о ключах Диффи-Хеллмана с SSL. Это обеспечивает конфиденциальность на канале, но без аутентификации.

Конечно, без аутентификации у вас действительно не может быть конфиденциальности, потому что ваш частный канал может быть подключен к «человеку посередине». Вот почему не рекомендуется использовать анонимные наборы шифров DH.

Если отсутствие сертификата мешает вам использовать SSL там, где он действительно необходим, получите бесплатный на startcom.org. < / а>

Обмен ключами Диффи-Хеллмана только для обмена ключами. Он не дает вам аутентификации (с кем вы разговариваете), для этого вам нужны сертификаты и PKI.

Итак, да, вы можете использовать шифрование, но вы не знаете, с кем разговариваете.

Обмен ключами DH сам по себе не может выполнять шифрование. Он используется для установки сеансового ключа, но не для шифрования. Итак, на этом уровне вопрос сформулирован неверно или обнаруживает либо отсутствие точности, либо непонимание (я подозреваю, что на этот раз проблема заключается в точности).

Вопрос в том:

• Вы хотите вообще кем-нибудь зашифровать данные?
• Вы хотите быть уверены, с кем разговариваете?

Как уже указывалось, SSL использует обмен ключами DH для установления сеансового ключа. Однако это также гарантирует, что программа на другом конце - это тот, кому вы доверяете (прямо или косвенно). Если вам не нужно беспокоиться о том, заслуживает ли другой человек доверия, вы можете просто использовать простой обмен ключами DH, а затем отправлять зашифрованные данные без сертификатов. Но вы не будете уверены, с кем говорите, если не подтвердите это - и сертификаты, используемые SSL и т. Д., Помогают с этой проверкой.