Ответ 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.)