Что происходит на проводе при настройке соединения TLS / LDAP или TLS / HTTP?

Между SSL и TLS очень мало различий в том, как они используются. Однако существует принципиальное различие между первоначальным установлением SSL / TLS и использованием такой команды, как STARTTLS . Иногда «TLS» используется в отличие от «SSL», что означает «использование режима STARTTLS», но это неверно.

Передний TLS / SSL

В этом случае клиент инициирует соединение TLS / SSL перед чем-либо еще, поэтому сначала выполняется рукопожатие SSL / TLS. После того как защищенный сокет встанет, приложение, использующее его, может начать отправку различных команд для протокола выше TLS (например, HTTP, LDAP в этом режиме, SMTP).

В этом режиме версии SSL / TLS должны запускаться на другом порту из их простых аналогов, например: HTTPS на порту 443, LDAPS на порту 636, IMAPS на порту 993 вместо 80, 389, 143 соответственно.

Уровни, реализующие эти протоколы приложений, едва ли должны знать, что они работают поверх TLS / SSL. Иногда они просто туннелируются в таких инструментах, как sslwrap .

TLS после STARTTLS (или эквивалент)

Спецификация TLS позволяет выполнить рукопожатие в любое время, в том числе после обмена некоторыми данными в обычном TCP по тому же TCP-соединению.

Некоторые протоколы, включая LDAP, include команду, чтобы сообщить, что протокол приложения будет обновляться. По сути, первая часть связи LDAP происходит в обычном тексте, затем отправляется сообщение STARTTLS (все еще в виде обычного текста), что указывает на то, что текущее TCP-соединение будет повторно использоваться, но что следующие команды будут обернуты в TLS / SSL слой. На этом этапе происходит установление связи TLS / SSL, и связь «обновляется» до TLS / SSL. Только после этого связь обеспечивается через TLS / SSL, и как клиент, так и серверы знают, что им приходится обертывать / разворачивать свои команды с уровня TLS (обычно добавляя библиотеку TLS между уровнем TCP и прикладным уровнем).

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

Даже HTTP имеет вариант с использованием этого механизма, хотя он в основном никогда не поддерживается: RFC 2817 Обновление до TLS в HTTP / 1.1 . Это полностью отличается от того, как работает HTTPS ( RFC 2818 ), который сначала инициирует TLS / SSL.

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

( EDIT : я удалил неправильное предложение, как отметил @GregS, спасибо.)

( EDIT : я также добавил больше о SSL и TLS в этом ответе на ServerFault .)

Команда «STARTTLS» – это то, что определено вне спецификации TLS. Это то, что клиент отправляет на сервер по ранее незашифрованному соединению, чтобы сказать «Хорошо, давайте начинаем переговоры TLS сейчас».

Не все протоколы выполняют такую ​​команду. SMTP делает, но HTTP и LDAP (насколько я знаю) этого не делают.

Когда явная команда для начала TLS отсутствует, обычной альтернативой является назначение определенного порта: например, 443 для HTTP (ов) и 636 для LDAP (ов). В этом случае согласование TLS начинается, как только устанавливается соединение TCP.

Хорошим инструментом для устранения неполадок является инструмент «s_client» в openssl. Например:

 openssl s_client -connect ldap.mycompany.com:636 

будет подключаться и выгружать сертификат сервера. Подумайте об этом как о «Telnet» для подключения TLS. (Конечно, LDAP не является текстовым протоколом, поэтому вы не можете делать ничего полезного с клавиатуры после установления соединения TLS.)

LDAP использует расширенную операцию для инициирования установки уровня TLS. См. Также раздел 4.14 в RFC .