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

Я переписываю свой вопрос так, надеюсь, я смогу получить лучший ответ. Я задал аналогичный вопрос в serverfault здесь и считаю, что правильный и действительный TLS-сервер - это тот, который ожидает команду "STARTTLS".

Правда ли, что STARTTLS может быть выдан на правильно настроенный сервер LDAP или HTTP TLS без необходимости использования дополнительного порта? Я знаю, что это верно с точки зрения SMTP, но не знаю, как широко я могу применить этот опыт к другим протоколам.

Я потратил время на чтение (но не полностью схватил)

Q: Что происходит на проводе прямо перед настройкой TLS через сеанс LDAP или HTTP? Поскольку это основано на TCP, могу ли я просто подключиться к этому порту telnet и выдать некоторую команду для проверки работоспособности (до этой точки)?

Ответ 1

Между 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, включают команду, чтобы сообщить прикладному протоколу, что будет обновление. По сути, первая часть связи 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, спасибо.)

( РЕДАКТИРОВАТЬ: я также добавил больше на SSL против TLS в этот ответ на ServerFault.)

Ответ 2

"Команда 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.)

Ответ 3

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