Поддержка SSL и не SSL на том же порту

Я работаю над добавлением поддержки SSL в наше существующее приложение и начал думать о обратной совместимости.Поддержка SSL и не SSL на том же порту

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

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

Любые предложения по изящному способу справиться с этим?

(я использую Winsock и OpenSSL)

источник

2014-01-14 BigHands79

Поскольку протокол SSL является протоколом поверх TCP, они всегда работают * на одном и том же порту. –

Упс. Я неправильно сформулировал свой вопрос. Исправлена. – BigHands79

Недостаточно данных здесь. Вам нужно подумать о том, как * сервер * будет обновлен, когда/если это произойдет. Как сервер будет обрабатывать клиентов, которые/не были обновлены до SSL? Вы собираетесь использовать StartTLS, например? – EJP

Обычно приложения принимают простые соединения и прямые SSL соединения на разных портах, например, порт 25 smtp и порт 465 smtps, порт http 80 и порт 383 https и т. д. Другие способы использования одного и того же порта, а затем имеют конкретную команду от клиента для перехода на SSL, например. как STARTTLS с smtp или AUTH TLS с ftp.

Если эти общие способы не являются для вас вариантом, и клиент все равно отправляет первый пакет в вашем протоколе (например, с помощью http, но не с smtp или ftp), вы можете сделать recv (.. MSG_PEEK) после первоначального принять, чтобы видеть, какие данные клиент отправляет, не удаляя данные из буфера сокета еще. Если просматриваемые данные выглядят как ваш обычный протокол приложений, вы продолжаете там, если они похожи на приветствие клиента от SSL (см. https://security.stackexchange.com/questions/34780/checking-client-hello-for-https-classification), вы выполняете обновление SSL.

источник

2014-01-15 04:56:47

Это действительно хорошее решение, но * я не могу изменить код сервера, чтобы его реализовать. Я в основном добавляю поддержку SSL только к клиенту и подключаюсь к серверам, которые ничего не знают о SSL. В этом случае клиент будет использовать незашифрованное соединение. – BigHands79

Если я правильно понимаю, вы не знаете, имеет ли сервер SSL или нет, но он будет прослушивать один и тот же порт. И если у него есть SSL, это будет прямой SSL вместо того, чтобы делать обновление SSL с помощью определенной команды, такой как STARTTLS в smtp. Это будет плохой дизайн :) Ваша стратегия зависит от протокола связи. Если сервер начинает с приветствия после подключения, подождите некоторое время, а затем предположите SSL. В противном случае вы можете попытаться говорить откровенно, и если это не удастся, вы можете предположить, что серверу понравился бы SSL. В любом случае помните о выборе серверов для ускорения следующего подключения. –

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

Поддержка SSL и не SSL на том же порту

ответ

Смежные вопросы