RFC 3207

RFC 3207 — это спецификация протокола, опубликованная в 2002 году в серии документов Request for Comments (RFC) Инженерного совета Интернета (IETF), которая определяет механизм расширения протокола SMTP (Simple Mail Transfer Protocol) для обеспечения безопасной передачи электронной почты с использованием шифрования TLS (Transport Layer Security). Официальное название документа — «SMTP Service Extension for Secure SMTP over Transport Layer Security». RFC 3207 устанавливает стандартный способ, с помощью которого почтовый сервер и клиент могут переключиться с незащищённого текстового соединения на зашифрованное, используя команду STARTTLS. Данный механизм является основой для защиты конфиденциальности и целостности сообщений при их передаче между почтовыми серверами (MTA) и от клиента к серверу (MSA/MUA).

История

До появления RFC 3207 передача электронной почты по протоколу SMTP (RFC 821, 1982 год) осуществлялась исключительно в открытом виде, без какого-либо шифрования. Это означало, что любой участник сети, имеющий доступ к каналу связи, мог перехватить и прочитать содержимое письма, а также изменить его. С ростом коммерческого использования Интернета и увеличением числа угроз безопасности (например, атаки «человек посередине») возникла необходимость в стандартизации защищённого обмена почтой.

Первые попытки обеспечить безопасность SMTP заключались в использовании отдельных портов для зашифрованной передачи (например, порт 465 для SMTPS, который использовал TLS с самого начала соединения). Однако такой подход требовал выделения дополнительных портов и не был гибким. В 1999 году IETF выпустила RFC 2487, который впервые предложил механизм STARTTLS для SMTP. Этот документ стал основой для будущего стандарта. RFC 3207, опубликованный в феврале 2002 года, заменил RFC 2487, уточнив и расширив спецификацию, а также устранив некоторые несоответствия. Авторами документа являются П. Хоффман (P. Hoffman) и К. Аллен (C. Allen).

Основные положения

RFC 3207 определяет расширение протокола SMTP, которое позволяет клиенту и серверу установить защищённое TLS-соединение поверх уже существующего незащищённого TCP-соединения. Ключевым элементом является команда STARTTLS.

Команда STARTTLS

Клиент (отправитель) инициирует процесс шифрования, отправляя серверу команду STARTTLS. Сервер, поддерживающий данное расширение, отвечает кодом 220 (готов к началу TLS-рукопожатия) или кодом 454 (TLS недоступен по временным причинам). После получения кода 220 клиент и сервер выполняют стандартное TLS-рукопожатие, в ходе которого:

• согласовываются параметры шифрования (алгоритмы, версии протокола);
• обмениваются сертификатами (обычно сервер предоставляет свой сертификат, клиент может предоставить свой для аутентификации);
• устанавливается зашифрованный канал.

После успешного завершения TLS-рукопожатия всё последующее взаимодействие (включая передачу команд EHLO, MAIL FROM, RCPT TO, DATA и самого сообщения) происходит в зашифрованном виде. Клиент должен повторно выполнить команду EHLO (или HELO) после установки TLS, так как возможности сервера могут измениться (например, может стать доступной аутентификация).

Коды ответов сервера

Сервер может отвечать на команду STARTTLS следующими кодами:

• 220 — готов к началу TLS-рукопожатия.
• 454 — TLS недоступен по временным причинам (например, из-за нехватки ресурсов).
• 501 — синтаксическая ошибка в параметрах команды (обычно не используется).
• 502 — команда не реализована (если сервер не поддерживает STARTTLS).

После получения кода 220 клиент обязан немедленно начать TLS-рукопожатие. Если сервер отвечает кодом 454, клиент может продолжить работу в незащищённом режиме или завершить соединение.

Требования к сертификатам

RFC 3207 не предъявляет строгих требований к проверке сертификатов. Сервер может использовать самоподписанный сертификат, и клиент может принять его, если это настроено. Однако для обеспечения безопасности рекомендуется использовать сертификаты, подписанные доверенным центром сертификации (CA). В документе также указано, что сервер может запросить сертификат клиента, но это не является обязательным.

Применение

RFC 3207 широко используется в современных почтовых системах. Он применяется в двух основных сценариях:

Передача между почтовыми серверами (MTA-to-MTA)

Когда один почтовый сервер (например, mail.example.com) отправляет письмо другому (например, mail.anotherexample.com), они могут использовать STARTTLS для шифрования канала. Это защищает сообщение от перехвата на маршруте между серверами. Многие крупные почтовые провайдеры (Gmail, Яндекс.Почта, Outlook.com) поддерживают STARTTLS и по умолчанию пытаются установить зашифрованное соединение.

Передача от клиента к серверу (MUA-to-MSA)

Почтовые клиенты (например, Microsoft Outlook, Mozilla Thunderbird, Apple Mail) при отправке писем через SMTP-сервер также могут использовать STARTTLS. В настройках клиента обычно указывается порт 587 (по умолчанию для SMTP с STARTTLS) или порт 25 (традиционный SMTP, который также может поддерживать STARTTLS). При этом клиент отправляет команду STARTTLS, и если сервер поддерживает, устанавливается зашифрованное соединение.

Безопасность и ограничения

Несмотря на широкое распространение, механизм STARTTLS имеет ряд уязвимостей и ограничений:

• Атаки понижения версии (Downgrade Attacks): Злоумышленник, находящийся между клиентом и сервером, может перехватить команду STARTTLS и заменить ответ сервера (например, с 220 на 454) или подавить саму команду. В результате клиент и сервер продолжат работу в незащищённом режиме, не подозревая об этом. Для защиты от таких атак используются механизмы DANE (DNS-based Authentication of Named Entities) и MTA-STS (SMTP MTA Strict Transport Security).
• Отсутствие обязательности: RFC 3207 не требует обязательного использования TLS. Сервер может отказаться от STARTTLS, и клиент должен быть готов продолжить без шифрования. Это делает протокол уязвимым для атак, когда злоумышленник заставляет обе стороны работать в незащищённом режиме.
• Проблемы с сертификатами: Многие почтовые серверы используют самоподписанные сертификаты, что делает возможным атаки «человек посередине» (MITM) при отсутствии дополнительной проверки подлинности (например, через DANE).
• Проблемы с конфиденциальностью: Даже при использовании STARTTLS метаданные письма (отправитель, получатель, тема) остаются видимыми до момента установки TLS-соединения. Команды MAIL FROM и RCPT TO передаются до STARTTLS, поэтому злоумышленник может узнать адреса отправителя и получателя.

Связь с другими стандартами

RFC 3207 является частью семейства стандартов, обеспечивающих безопасность электронной почты:

• RFC 2487 — предшественник RFC 3207, заменённый в 2002 году.
• RFC 7813 — уточнение требований к использованию STARTTLS в SMTP.
• RFC 7672 — определяет использование DANE для SMTP с STARTTLS.
• RFC 8461 — определяет SMTP MTA Strict Transport Security (MTA-STS), который позволяет доменам указывать, что они требуют использования STARTTLS.
• RFC 8314 — рекомендации по использованию TLS для доступа к почтовым серверам (IMAP, POP3, SMTP).

Статус и актуальность

RFC 3207 остаётся действующим стандартом Интернета (Internet Standard) и является одним из наиболее распространённых механизмов защиты электронной почты. Однако из-за уязвимостей, связанных с атаками понижения версии, IETF рекомендует дополнять его более современными протоколами, такими как DANE (RFC 7672) и MTA-STS (RFC 8461). В настоящее время большинство почтовых серверов поддерживают STARTTLS, и многие провайдеры требуют его использования для передачи почты.

Источники

• RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security (2002)
• RFC 2487: SMTP Service Extension for Secure SMTP over TLS (1999)
• RFC 7813: SMTP Service Extension for Secure SMTP over Transport Layer Security (Updated)
• RFC 7672: SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) (2015)
• RFC 8461: SMTP MTA Strict Transport Security (MTA-STS) (2018)
• RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access (2018)