Кратко

  • RFC 8314 рекомендует неявный TLS для доступа к почте и её отправки: на портах 465, 993 и 995 рукопожатие начинается сразу после TCP-соединения, до команд прикладного протокола.
  • Такой порядок защищает установление канала. Он сам по себе не доказывает ожидаемую личность сервиса, не аутентифицирует и не авторизует пользователя и не подтверждает приём или окончательную доставку письма.

В отчёте четыре строки были зелёными, а пятая — красной. Клиент подключился к порту 465, установил TLS, проверил сертификат и вошёл с верным паролем. Затем сервер отказал в использовании адреса MAIL FROM. Первые результаты не обещали успех пятого: транспорт, сервис, учётная запись и право представлять конкретного отправителя были разными решениями.

Почтовый клиент скрывает эту последовательность за значком замка. На деле настроенное имя сервиса превращается в сетевой адрес, адрес и порт — в TCP-соединение, TLS — в согласованные параметры и сертификат. Клиент проверяет имя сервиса, затем приложение предъявляет полномочия. Сервер сопоставляет их с учётной записью и решает, какие ящики, отправители и команды ей разрешены. Успех этапа позволяет перейти дальше, но не отвечает за следующий этап.

Кит Мур и Крис Ньюман опубликовали RFC 8314 в 2018 году. Документ предлагает вывести открытый текст из нормальной практики связи Mail User Agent с серверами доступа и отправки. Для POP, IMAP и SMTP Submission он предпочитает неявный TLS модели, где сначала открывается незашифрованный сеанс приложения, а затем выполняется повышение защиты командой STARTTLS или её аналогом.

Слово «неявный» описывает момент запуска. На стандартном порту 465 сервиса submissions рукопожатие TLS начинается сразу после TCP. Для IMAP аналогичен порт 993, для POP — 995. Почтовый протокол продолжается только внутри установленного канала. При STARTTLS клиент сначала обменивается открытыми командами, получает список возможностей, запрашивает повышение и после этого начинает TLS.

Устранение прикладной фазы перед рукопожатием сокращает поверхность понижения защиты. Но число 465 не становится криптографическим доказательством. Настройка не сообщает, какой адрес реально разрешился, какой процесс ответил, какой сертификат был представлен и проверил ли клиент ожидаемое имя. Нужен журнал фактической сессии, а не только снимок параметров.

RFC 8314 учитывает распространённость STARTTLS на порту 587 и рекомендует в переходный период поддерживать и 587/STARTTLS, и 465/неявный TLS. Поэтому документ не даёт основания объявлять любой STARTTLS небезопасным. Критична политика клиента: когда возможность повышения исчезает или команда завершается ошибкой, прерывает ли он работу, если защита обязательна?

RFC 2595 определила STARTTLS для IMAP, POP3 и ACAP и описала посредника, который удаляет возможность из объявления или вызывает ошибку команды. Отсутствие возможности само по себе ещё не доказывает атаку — причиной может быть конфигурация или версия. Для вывода нужны исходный ответ, правило обязательности TLS и действие клиента после отказа.

Рукопожатию требуется и ожидаемое имя. RFC 8314 требует от клиентов реализации проверки сертификата. Более поздняя RFC 9525 других авторов задаёт современную общую модель личности сервиса. Клиент строит эталонные идентификаторы из доверенного ввода или настройки, проверяет весь путь сертификата и сопоставляет их с предъявленными идентификаторами. Промежуточное имя из DNS-разрешения не становится автоматически личностью, которую собирались проверить.

Успешное совпадение аутентифицирует прикладной сервис в границах этой процедуры. Оно не аутентифицирует человека у клиента, не гарантирует безошибочность или добросовестность сервера и не расширяет его полномочия на другие имена. И оно не даёт пользователю доступ к почтовому ящику. Сервис и пользователь — разные субъекты.

Клиентский сертификат не отменяет границу. RFC 8314 допускает его применение и одновременно позволяет серверу потребовать прикладную аутентификацию даже после получения сертификата. Запись взаимного TLS доказывает авторизованную операцию лишь вместе с правилом сопоставления сертификата учётной записи и назначенными ей правами.

SASL называет две роли прямо. RFC 4422 отличает authentication identity, связанную с полномочиями, от authorization identity, от имени которой клиент просит действовать. Сервер проверяет первую и решает, может ли она представлять вторую. Обмен завершается неудачей при провале любой проверки. Если отдельная authorization identity не указана, обычно запрашивается действие от собственного аутентифицированного имени, но политика сервера всё равно применяется.

У отправки есть отдельные права. RFC 6409 отделяет submission от ретрансляции и резервирует порт 587. Message Submission Agent может принимать только авторизованных пользователей и отклонять MAIL FROM, если у адреса недостаточно прав или он не соответствует аутентификации. Защищённое достижение MSA не одобряет заранее отправителя, получателей, размер или содержимое.

Даже ответ MSA об успешном приёме не равен доставке. Он фиксирует принятую ответственность в данной точке. Далее идут передача, ответ системы получателя, фильтры, помещение в ящик и чтение человеком. «TLS успешен», «сервис совпал», «пользователь вошёл», «команда разрешена», «письмо принято» и «письмо доставлено» — разные квитанции.

Воспроизводимая цепочка хранит имя ожидаемого сервиса и вход обнаружения, полученный адрес и фактический порт, режим запуска TLS, рукопожатие, версию и сертификат. Затем — путь доверия, эталонные идентификаторы и совпадение, механизм SASL, authentication identity, запрошенную authorization identity, решение политики, команду и точный ответ. Для исходящей почты следом сохраняются события передачи и доставки.

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

Источники