Действительно ли STARTTLS менее безопасен, чем TLS/SSL?

Да, вы правильно поняли основы. И да, STARTTLS определенно менее безопасен. Он не только может вернуться к обычному тексту без уведомления, но и потому, что он подвержен атакам «злоумышленник в середине». Поскольку соединение начинается в открытом виде, MitM может вырезать команду STARTTLS и предотвратить выполнение шифрования. Однако я считаю, что почтовые серверы могут указывать, что передача происходит только после установки зашифрованного туннеля. Так что вы можете обойти это.

Так почему такое вообще существует? По соображениям совместимости. Если какая-либо из сторон не поддерживает шифрование, вы все равно можете захотеть установить соединение правильно.

Нет разницы в безопасности между двумя вариантами.

• SSL / TLS сначала открывает соединение SSL / TLS, а затем начинает транзакцию SMTP. Это должно происходить на порте, на котором еще не запущен SMTP-сервер, отличный от SSL / TLS; невозможно настроить один порт для обработки и простого текста, и зашифрованных соединений из-за природы протоколов.

• STARTTLS запускает транзакцию SMTP и ищет поддержку на другом конце для TLS в ответе на EHLO. Если клиент видит STARTTLS в списке поддерживаемых команд, он отправляет STARTTLS и начинает согласование для шифрования. Все это может (и обычно происходит) происходить на стандартном SMTP-порту 25, частично для обратной совместимости, но также для обеспечения гибкого шифрования между конечными точками, которые поддерживают его, но не обязательно требуют этого.

Обычно SSL / TLS используется только между конечными клиентами и серверами. STARTTLS чаще используется между MTA для защиты межсерверного транспорта.

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

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

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

Согласитесь с @Greg. Эти атаки возможны. Однако MTA могут быть настроены (в зависимости от MTA) для использования «обязательного TLS», а не «уступчивого TLS». Это означает, что для транзакций электронной почты используется TLS и только TLS (включая STARTTLS). Если удаленный MTA не поддерживает STARTTLS, электронное письмо возвращается.

В частности, для электронной почты в январе 2018 года был выпущен RFC 8314 , в котором явно рекомендуется использовать «неявный TLS» вместо механизма STARTTLS для IMAP, POP3, и отправка SMTP.

Вкратце, в этом документе теперь рекомендуется следующее:

• TLS версии 1.2 или выше должен использоваться для всего трафика между MUA и почтовые серверы, а также между MUA и Mail Access Серверы.
• MUA и поставщики почтовых услуг (MSP) (а) не поощряют использование протоколы открытого текста для доступа к почте и отправки почты и (b) не рекомендуют использовать протоколы открытого текста для этих целей, поскольку как можно скорее.
• Подключения к серверам отправки почты и серверам доступа к почте должны быть сделано с использованием «неявного TLS» (как определено ниже), предпочтительнее, чем подключение к порту «открытого текста» и согласование TLS с использованием Команда STARTTLS или аналогичная команда.

(выделено мной)

Нет, это не менее безопасно, если ваше приложение обрабатывает его правильно.

Существует четыре способа обработки TLS, и многие программы позволяют вам выбрать:

• Нет TLS
• TLS на выделенном порте (только пытается TLS)
• Использовать TLS, если он доступен (пытается starttls , в случае сбоя использует незашифрованное соединение)
• Всегда использовать TLS (Используется starttls и не работает, если не работает)

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

Но в целом безопасность зависит от обработки ошибок безопасности. Программа может решить переключиться на порт открытого текста, когда TLS на TLS-Port также не работает. Вам нужно знать, что он будет делать, и выбрать безопасные настройки. И программы должны использовать безопасные значения по умолчанию.

Ответ в некоторой степени зависит от того, что вы имеете в виду под словом «безопасный».

Во-первых, ваше резюме не совсем отражает разницу между SSL / TLS и STARTTLS.

• При использовании SSL / TLS клиент открывает TCP-соединение с «портом SSL», назначенным протоколу приложения, которое он хочет использовать, и немедленно начинает говорить TLS.
• С помощью STARTTLS клиент открывает TCP-соединение с «портом открытого текста», связанным с протоколом приложения, которое он хочет использовать, а затем спрашивает сервер, «какие расширения протокола вы поддерживаете?». Затем сервер отвечает списком расширений. Если одно из этих расширений - «STARTTLS», клиент может затем сказать «хорошо, давайте использовать TLS», и оба начнут говорить по TLS.

Если клиент настроен на требование TLS, два подхода более или менее одинаково безопасно. Но есть некоторые тонкости относительно того, как STARTTLS должен использоваться, чтобы сделать его безопасным, и реализации STARTTLS немного сложнее получить эти детали правильно.

С другой стороны, если клиент настроен на использование TLS только тогда, когда TLS доступен, и использовать открытый текст, когда TLS недоступен, клиент может сначала попытаться подключиться к порту SSL, используемому протоколом, а если это не удается, затем подключиться к порту открытого текста и попытаться использовать STARTTLS, и, наконец, вернуться к открытому тексту, если TLS недоступен в любом случае. Злоумышленнику довольно легко вызвать сбой подключения к порту SSL (все, что требуется, - это несколько своевременных пакетов TCP RST или блокировка порта SSL). Злоумышленнику немного сложнее - но совсем немного - нарушить согласование STARTTLS и заставить трафик оставаться в открытом виде. И тогда злоумышленник не только прочитает вашу электронную почту, но и получит ваше имя пользователя / пароль для использования в будущем.

Итак, простой ответ - если вы подключаетесь к серверу, который, как вы знаете, поддерживает TLS (как и должно быть в случае, когда вы отправляете или читаете электронную почту), вам следует использовать SSL / TLS. Если соединение подвергается атаке, попытка подключения не удастся, но ваш пароль и адрес электронной почты не будут скомпрометированы.

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

Когда был изобретен STARTTLS, «пассивные» атаки только для прослушивания были очень Обычные "активные" атаки, в которых злоумышленник вводил трафик, чтобы попытаться снизить уровень безопасности, были менее распространены. Примерно за 20 лет с тех пор активные атаки стали более возможными и более распространенными.

Например,Если вы пытаетесь использовать ноутбук в аэропорту или другом общественном месте и пытаетесь прочитать свою почту через предоставленный там Wi-Fi, вы понятия не имеете, что эта сеть Wi-Fi делает с вашим трафиком. Сети Wi-Fi очень часто направляют определенные виды трафика на «прокси», которые встают между вашими клиентскими приложениями и серверами, с которыми они пытаются общаться. Для этих прокси-серверов тривиально отключить и STARTTLS, и «попробовать один порт, затем другой», чтобы заставить вашего клиента вернуться к открытому тексту. Да, это происходит, и это всего лишь один из примеров того, как сеть может отслеживать ваш трафик. И такие атаки не ограничиваются трехбуквенными агентствами, поддерживаемыми государством, они могут быть осуществлены подростком с компьютером за 35 долларов, который спрятан где-то в общественном месте.