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

Question

Может ли алгоритм обмена ключами Диффи-Хелмана использоваться для шифрования связи клиент-сервер на веб-странице вместо SSL? Если это возможно, каковы недостатки (например, почему стандарт использует SSL, требующий наличия центра сертификации)? Я понимаю, что Diffie-Hellman можно использовать для тайного создания общего ключа, который затем может использоваться для шифрования любых дальнейших сообщений.

Answer 1

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

С here SSL Диффи-Гельмана используется для:

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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