безопасно ли отправлять SSL-pubkey пользователям через сеть без шифрования?

Question

Просто рассмотрим следующий вопрос:

1) Во-первых, клиент пользователя подключается к удаленному серверу WebSocket на основе "WS: //" Протокол instread из "WSS: //" протокол.

2) После установления соединения с веб-сервером удаленный сервер WebSocket отправляет SSL-pubkey этому пользователю, используя этот (ws: // ..) websocket канал.

3) Затем клиент отправит SSL-pubkey через событие «ws.onmessage».

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

Я думаю, что шаги 3 и 4, конечно, безопасны, но нет уверенности в том, безопасен ли шаг 2 или нет.

Так ли это (шаг 2) можно взломать кем-то?

Answer 1

Безопасно ли отправлять SSL-pubkey пользователям через сеть без зашифрованных данных?

Ответ зависит от «возможно, это зависит» от «нет, его нет». Нам нужно будет больше узнать о протоколе, модели риска и модели угрозы.

«Нет, его нет» является простым. Представьте себе случай, когда политический диссидент подключается к службе, чтобы помочь его делу. Даже открытый ключ на проводе создает угрозу. Модель риска будет включать тюремное заключение, пытки и смерть.

«Возможно, это зависит», сложнее ответить. Как указывали другие, его принято считать. Но, как указывает Штеффен, протокол, который вы описываете, фактически является анонимным обменом ключами, потому что нет никаких шагов для установления происхождения ключа. То есть, злоумышленник мог бы поменять свой ключ на настоящий ключ. Модель риска в этом случае обычно представляет собой финансовые потери, а это означает: (1) потребитель страдает или (2) страдает владелец акций.

Вторая сложная проблема. Его называют "key distribution" problem. Его a wicked hard problem without a solution.

---

Так это (этап 2) можно быть взломан кем-то?

Как описано в протоколе, да, это очень легко.

Answer 2

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

Почему бы не просто использовать wss? (на веб-странице https по той же очевидной причине)

wss (as https) предоставляет конфиденциальность, но также и проверку подлинности.

Answer 3

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

Безопасно ли отправлять SSL-pubkey пользователям через сеть без зашифрованных данных?

Открытый ключ является публичной информацией, то есть никакой информацией, которая должна быть специально защищена. И он отправляется ясно как часть сертификата внутри рукопожатия TLS (https: //, wss: //).

Но то, что вы пытаетесь сделать с открытым ключом, - очень плохая идея.

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

Я рекомендую отказаться от вашей идеи и использовать надлежащий wss: // с сертификатом, которому может доверять клиент (т. Е. Подписанным доверенным ЦС). Это не наносит лишних накладных расходов, чем ваша идея, но является более безопасным и не может быть разбит простым человеком в средней атаке.

Answer 4

Возможно, что шаг (2) взломан любой.Контрастность TLS, где сервер отправляет сертификат , а не только открытый ключ и который (а) подписан, чтобы аутентифицировать идентификатор, выраженный сертификатом, поэтому вы знаете, кем он должен быть, и (b) сопровождается цифровой подписью, которая удостоверяет, что сервер владеет этим открытым ключом.

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

Не делайте этого. Используйте TLS. Он уже существует, уже работает и уже безопасен.