В Thunderbird (и я предполагаю, что и во многих других клиентах) у меня есть возможность выбирать между «SSL / TLS» и «STARTTLS».
Насколько я понимаю, "STARTTLS" простыми словами означает "зашифровать, если оба конца поддерживают TLS, в противном случае не шифровать передачу". А «SSL / TLS» простыми словами означает "всегда шифровать или не подключаться вообще". Это верно?
Или другими словами:
Является ли STARTTLS менее безопасным, чем SSL / TLS, потому что он может вернуться к открытому тексту без уведомления меня?
Ответ, основанный на STARTTLS RFC для SMTP (RFC 3207) является:
Вместо того чтобы говорить самому, я позволю 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, и, следовательно, не более или менее уязвимо для атаки Man-in-the-Middle, за исключением этого типа ошибки конфигурации.
В частности, для электронной почты в январе 2018 г. RFC 8314 был выпущен, который явно рекомендует использовать «неявный TLS» вместо механизма STARTTLS для IMAP, POP3 и SMTP.
Вкратце, в этой памятке рекомендуется следующее:
- TLS версии 1.2 или выше должен использоваться для всего трафика между MUA и серверами отправки почты, а также между MUA и серверами доступа к почте.
- MUA и поставщики почтовых услуг (MSP) (a) не рекомендуют использовать протоколы открытого текста для доступа к почте и отправки почты и (b) как можно скорее осуждают использование протоколов открытого текста для этих целей.
- Соединения с серверами отправки почты и серверами доступа к почте производятся с использованием «неявного TLS» (как определено ниже), в предпочтении к подключение к порту "открытого текста" и согласование TLS с помощью команды STARTTLS или аналогичная команда.
(курсив мой)
Ответ в некоторой степени зависит от того, что вы подразумеваете под словом «безопасный».
Во-первых, ваше резюме не совсем отражает разницу между SSL / TLS и STARTTLS.
Если клиент настроен на использование 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 долларов, который спрятан где-то в общественном месте.
Да, вы правильно поняли основы. И да, STARTTLS определенно менее безопасен. Он не только может вернуться к обычному тексту без уведомления, но и потому, что он подвержен атакам «злоумышленник в середине». Поскольку соединение начинается в открытом виде, MitM может вырезать команду STARTTLS и предотвратить выполнение шифрования. Однако я считаю, что почтовые серверы могут указывать, что передача происходит только после установки зашифрованного туннеля. Так что вы можете обойти это.
Так почему такое вообще существует? По соображениям совместимости. Если какая-либо из сторон не поддерживает шифрование, вы все равно можете захотеть установить соединение правильно.
Согласитесь с @Greg. Эти атаки возможны. Однако MTA могут быть настроены (в зависимости от MTA) для использования «обязательного TLS», а не «уступчивого TLS». Это означает, что для транзакций электронной почты используется TLS и только TLS (включая STARTTLS). Если удаленный MTA не поддерживает STARTTLS, электронное письмо возвращается.
Нет, это является не менее безопасен, если ваше приложение обрабатывает это правильно.
Существует четыре способа обработки TLS, и многие программы позволяют выбирать:
starttls, в случае сбоя использует незашифрованное соединение)starttls и выходит из строя, если не работает)Преимущество TLS на выделенном порте заключается в том, что вы можете быть уверены, что не будет отката при использовании программы, которую вы еще не знаете или которая не предоставляет подробные настройки для обработки ошибок в своем мастере первого запуска.
Но в целом безопасность зависит от обработки ошибок безопасности. Программа может решить переключиться на порт открытого текста, когда TLS на TLS-Port также не работает. Вам нужно знать, что он будет делать, и выбрать безопасные настройки. И программы должны использовать безопасные значения по умолчанию.