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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

Возникает вопрос:

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

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