STARTTLS менее безопасен, чем TLS / SSL?

В Thunderbird (и я полагаю, во многих других клиентах) у меня есть возможность выбора между «SSL / TLS» и «STARTTLS».

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

Или другими словами:

Является ли STARTTLS менее безопасным, чем SSL / TLS, потому что он может перейти на обычный текст без уведомления меня?

Ответ, основанный на RFC STARTTLS для SMTP ( RFC 3207 ):

STARTTLS менее безопасен, чем TLS.

Вместо того, чтобы говорить самому, я позволю RFC говорить за себя, с четырьмя соответствующими битами, выделенными жирным шрифтом :

Атаку «человек посередине» можно запустить, удалив ответ «250 STARTTLS» с сервера. Это приведет к тому, что клиент не будет пытаться запустить сеанс TLS. Другая атака «человек посередине» - позволить серверу объявить о своей возможности STARTTLS, но изменить запрос клиента на запуск TLS и ответ сервера. Чтобы защититься от таких атак, клиенты и серверы ДОЛЖНЫ быть настроены так, чтобы требовать успешного согласования TLS соответствующего набора шифров для выбранных хостов, прежде чем сообщения могут быть успешно переданы. ДОЛЖНА также быть предоставлена дополнительная возможность использования TLS, когда это возможно. Реализация МОЖЕТ предоставить возможность записывать, что TLS использовался при связи с данным узлом и генерировать предупреждение, если он не используется в более позднем сеансе.

Если согласование TLS не удается или клиент получает ответ 454, клиент должен решить, что делать дальше. Есть три основных варианта: продолжить оставшуюся часть SMTP-сессии , [...]

Как видите, сам RFC утверждает (не очень четко, но достаточно четко), что НИЧЕГО не требуется клиентам устанавливать безопасное соединение и информировать пользователей в случае сбоя безопасного соединения. Это явно дает клиентам возможность устанавливать молчащие текстовые соединения.

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

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

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

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

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

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

Вкратце, эта памятка теперь рекомендует, чтобы:

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

(выделение добавлено)

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

Во-первых, ваше резюме не совсем отражает разницу между 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 лет или около того, активные атаки стали более выполнимыми и более распространенными.

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

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

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

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

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

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

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

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

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