STARTTLS

STARTTLS — это протокол (расширение протоколов передачи данных), предназначенный для преобразования незащищённого текстового соединения в шифрованное с использованием протокола TLS (Transport Layer Security) или его предшественника SSL. STARTTLS применяется в протоколах электронной почты (SMTP, IMAP, POP3) и в некоторых других прикладных протоколах (например, FTP, XMPP, LDAP) для обеспечения конфиденциальности и целостности передаваемых данных без необходимости использования отдельного порта для защищённого соединения.

История и предпосылки создания

До появления STARTTLS шифрование в протоколах электронной почты обычно реализовывалось через выделенные порты: для SMTP с SSL/TLS использовался порт 465, для IMAP — 993, для POP3 — 995. Такой подход (известный как «явное шифрование», implicit TLS) требовал, чтобы клиент и сервер заранее знали, что соединение будет защищённым, и устанавливали его сразу на альтернативном порту.

Стандарт STARTTLS был предложен как альтернатива, позволяющая использовать один и тот же порт (например, порт 25 для SMTP, порт 143 для IMAP, порт 110 для POP3) как для незащищённого, так и для защищённого обмена. Идея заключалась в том, чтобы клиент и сервер начинали общение в открытом виде, а затем, по команде STARTTLS, «повышали» соединение до шифрованного. Это упрощало конфигурацию сетевых экранов и позволяло постепенно внедрять шифрование без изменения номеров портов.

Первая версия расширения STARTTLS для SMTP была описана в RFC 2487 (1999 год), которая позже была заменена на RFC 3207 (2002 год). Для IMAP и POP3 аналогичные расширения были стандартизированы в RFC 2595 (1999 год) и RFC 4616 (2006 год) соответственно.

Принцип работы

Процесс установления защищённого соединения через STARTTLS состоит из нескольких этапов:

1. Установление TCP-соединения. Клиент подключается к серверу на стандартный порт (например, 25 для SMTP).
2. Приветствие сервера. Сервер отправляет клиенту сообщение, содержащее информацию о поддерживаемых расширениях. В этом сообщении сервер может указать, что он поддерживает STARTTLS.
3. Команда STARTTLS. Клиент отправляет команду STARTTLS (или её аналог для других протоколов). Сервер отвечает подтверждением (обычно кодом 220 для SMTP).
4. Установка TLS-туннеля. После подтверждения обе стороны начинают процедуру рукопожатия TLS: обмениваются сертификатами, согласовывают алгоритмы шифрования и вырабатывают сессионные ключи. Весь последующий обмен данными происходит внутри шифрованного туннеля.
5. Продолжение работы. После успешного установления TLS клиент и сервер продолжают взаимодействие уже в защищённом режиме. Для SMTP это означает, что аутентификация и передача писем происходят по шифрованному каналу.

Важно отметить, что STARTTLS не требует обязательного шифрования: сервер может поддерживать STARTTLS, но не настаивать на его использовании. Клиент, в свою очередь, может либо принять шифрование, либо отказаться и продолжить работу в открытом виде. Однако многие современные почтовые серверы и клиенты настроены на обязательное использование STARTTLS (с опцией «require STARTTLS»).

Применение в различных протоколах

SMTP (Simple Mail Transfer Protocol)

В протоколе SMTP STARTTLS описан в RFC 3207. Сервер сообщает о поддержке STARTTLS в ответе на команду EHLO (или HELO). Клиент отправляет команду STARTTLS, сервер отвечает кодом 220. После установки TLS клиент должен повторно отправить EHLO, так как некоторые возможности сервера могут измениться после перехода на шифрование.

STARTTLS для SMTP используется как при передаче почты между почтовыми серверами (MTA-to-MTA), так и при отправке писем от почтового клиента (MUA) на сервер (MSA). В последнем случае часто используется порт 587 с обязательным STARTTLS.

IMAP (Internet Message Access Protocol) и POP3 (Post Office Protocol 3)

Для IMAP и POP3 STARTTLS описан в RFC 2595. Клиент отправляет команду STARTTLS (для IMAP) или STLS (для POP3). Сервер подтверждает, после чего устанавливается TLS-соединение. После этого клиент должен пройти аутентификацию (логин/пароль) уже в защищённом режиме.

Другие протоколы

• FTP — расширение AUTH TLS (RFC 4217) позволяет защитить управляющее и/или data-соединение.
• XMPP (Jabber) — STARTTLS используется для защиты обмена мгновенными сообщениями (RFC 6120).
• LDAP — расширение StartTLS (RFC 2830) для защиты запросов к каталогу.
• NNTP — STARTTLS может применяться для защиты новостных групп (RFC 4642).

Безопасность и уязвимости

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

1. STRIPTLS-атаки. Злоумышленник, находящийся между клиентом и сервером (атака «человек посередине»), может перехватить начальное незащищённое приветствие и удалить или изменить информацию о поддержке STARTTLS. В результате клиент может не узнать о возможности шифрования и продолжить работу в открытом виде. Для защиты от таких атак рекомендуется использовать DANE (DNS-based Authentication of Named Entities) или MTA-STS (SMTP MTA Strict Transport Security), которые позволяют клиенту узнать, что сервер обязан использовать TLS.

1. Сертификаты. STARTTLS полагается на инфраструктуру открытых ключей (PKI). Если сертификат сервера самоподписанный или не доверенный, клиент может либо отклонить соединение, либо продолжить с предупреждением. В некоторых конфигурациях клиенты могут игнорировать ошибки сертификатов, что снижает защищённость.

1. Атаки на согласование TLS. Как и любой протокол, использующий TLS, STARTTLS подвержен атакам на старые версии TLS (например, POODLE, BEAST), если сервер поддерживает устаревшие алгоритмы шифрования.

1. Logjam и другие атаки на Diffie-Hellman. Если сервер использует слабые параметры обмена ключами, злоумышленник может расшифровать сессию.

Практические рекомендации

Для обеспечения максимальной безопасности при использовании STARTTSL рекомендуется:

• Включать обязательное использование STARTTLS на сервере (настройка require TLS).
• Использовать только современные версии TLS (1.2 и 1.3), отключать SSLv2, SSLv3 и TLS 1.0/1.1.
• Применять механизмы DANE (RFC 7671) и MTA-STS (RFC 8461) для предотвращения STRIPTLS-атак.
• Настраивать проверку сертификатов на стороне клиента и сервера.
• Регулярно обновлять сертификаты и следить за их валидностью.

Альтернативы

Основной альтернативой STARTTLS является использование выделенных портов с явным TLS (implicit TLS). В этом случае шифрование устанавливается сразу при подключении, без начального незащищённого обмена. Такой подход считается более безопасным, так как исключает возможность STRIPTLS-атаки на этапе приветствия. Однако он требует использования отдельных портов (например, 465 для SMTP, 993 для IMAP, 995 для POP3), что может быть неудобно с точки зрения администрирования сетевых экранов.

В последние годы IETF (Internet Engineering Task Force) рекомендует использовать explicit TLS (STARTTLS) для SMTP на порту 587 и implicit TLS для IMAP и POP3 на портах 993 и 995 соответственно. Однако на практике многие почтовые серверы поддерживают оба подхода.

Интересные факты

• Команда STARTTLS в SMTP не является обязательной: сервер может не поддерживать шифрование, и клиент будет вынужден работать в открытом виде.
• В некоторых реализациях STARTTLS используется для защиты не только данных, но и аутентификации (например, при отправке логина и пароля через IMAP).
• Протокол STARTTLS не требует, чтобы сертификат сервера был подписан доверенным центром: клиент может принять самоподписанный сертификат, но это снижает уровень доверия.
• Расширение STARTTLS для протокола FTP (AUTH TLS) редко используется на практике; чаще применяется FTPS (FTP over SSL) на порту 990.

Источники

• RFC 3207 — SMTP Service Extension for Secure SMTP over Transport Layer Security
• RFC 2595 — Using TLS with IMAP, POP3 and ACAP
• RFC 4616 — The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
• RFC 4217 — Securing FTP with TLS
• RFC 6120 — Extensible Messaging and Presence Protocol (XMPP): Core
• RFC 2830 — Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
• RFC 4642 — Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)
• RFC 7671 — The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
• RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS)