TLS ALPN

TLS ALPN — это расширение протокола TLS (Transport Layer Security), позволяющее клиенту и серверу на этапе установления защищённого соединения согласовать протокол прикладного уровня (например, HTTP/2, HTTP/3, SSH, MQTT), который будет использоваться после завершения рукопожатия. ALPN (Application-Layer Protocol Negotiation) устраняет необходимость в отдельном согласовании протокола поверх TLS, что сокращает задержки и повышает эффективность соединения.

История

До появления ALPN для согласования протокола прикладного уровня использовался механизм NPN (Next Protocol Negotiation), разработанный компанией Google для протокола SPDY. NPN работал по схеме «сервер предлагает — клиент выбирает», что приводило к дополнительному обмену сообщениями и увеличивало время установки соединения.

В 2014 году ALPN был стандартизирован в документе RFC 7301 (Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension). В отличие от NPN, ALPN работает по схеме «клиент предлагает — сервер выбирает», что позволяет согласовать протокол уже в рамках стандартного TLS-рукопожатия, без дополнительных раундов обмена.

ALPN был разработан в рамках рабочей группы IETF TLS и стал обязательным для протокола HTTP/2, определённого в RFC 7540 (2015 год). Впоследствии он был включён в стандарты TLS 1.3 (RFC 8446, 2018 год) как одна из обязательных опций.

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

ALPN встраивается в процесс TLS-рукопожатия на этапе обмена приветственными сообщениями (ClientHello и ServerHello). Клиент отправляет список идентификаторов протоколов, которые он поддерживает, в поле alpn расширения ClientHello. Сервер выбирает один из предложенных протоколов и возвращает его идентификатор в расширении alpn сообщения ServerHello. Если ни один из предложенных протоколов не поддерживается сервером, соединение может быть разорвано или продолжено без согласования протокола.

Этапы согласования

1. Клиент формирует список поддерживаемых протоколов (например, h2 для HTTP/2, http/1.1 для HTTP/1.1, h3 для HTTP/3).
2. Сервер получает список и выбирает протокол, который он поддерживает и который предпочтителен для данного соединения.
3. Сервер возвращает выбранный протокол в ответе.
4. После завершения TLS-рукопожатия клиент и сервер начинают обмен данными по согласованному протоколу.

Идентификаторы протоколов

Каждый протокол прикладного уровня имеет свой уникальный идентификатор, который регистрируется в реестре IANA. Примеры распространённых идентификаторов:

Применение

HTTP/2 и HTTP/3

ALPN является обязательным для установки соединения по протоколу HTTP/2. Без ALPN клиент и сервер не могут согласовать использование HTTP/2 поверх TLS, и соединение автоматически переключается на HTTP/1.1. Для HTTP/3, работающего поверх QUIC, ALPN также используется, но согласование происходит на уровне QUIC, а не TLS.

Веб-серверы и браузеры

Современные веб-серверы (Apache, Nginx, IIS) и браузеры (Google Chrome, Mozilla Firefox, Apple Safari, Microsoft Edge) поддерживают ALPN. При установке HTTPS-соединения браузер отправляет список поддерживаемых протоколов, а сервер выбирает наиболее подходящий. Это позволяет автоматически переключаться между HTTP/1.1, HTTP/2 и HTTP/3 в зависимости от возможностей сервера.

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

ALPN может использоваться для согласования любых протоколов прикладного уровня, работающих поверх TLS. Например, в системах удалённого доступа (SSH), в протоколах Интернета вещей (MQTT, CoAP), в видеоконференциях (WebRTC) и в других областях, где требуется защищённое соединение.

Преимущества и недостатки

Преимущества

• Снижение задержек. ALPN устраняет необходимость в отдельном согласовании протокола, что сокращает время установки соединения.
• Упрощение архитектуры. Разработчикам не нужно реализовывать отдельные механизмы согласования для каждого протокола.
• Безопасность. ALPN встроен в TLS-рукопожатие, что исключает возможность атак на уровне согласования протокола.
• Совместимость. ALPN поддерживается всеми современными реализациями TLS и не требует изменений в протоколах прикладного уровня.

Недостатки

• Зависимость от TLS. ALPN работает только при использовании TLS, что ограничивает его применение в незащищённых соединениях.
• Ограниченная гибкость. Сервер выбирает протокол из предложенного списка, но не может предложить альтернативы, если ни один из протоколов клиента не поддерживается.
• Необходимость обновления. Для поддержки ALPN требуется обновление программного обеспечения (серверов, библиотек, клиентов).

Безопасность

ALPN не вносит дополнительных уязвимостей в TLS, так как работает в рамках стандартного рукопожатия. Однако возможны атаки, связанные с подменой идентификаторов протоколов, если злоумышленник контролирует сетевой трафик. Для защиты от таких атак используются механизмы аутентификации TLS (сертификаты, цифровые подписи).

Реализации

ALPN поддерживается большинством современных реализаций TLS:

• OpenSSL (начиная с версии 1.0.2)
• BoringSSL (форк OpenSSL от Google)
• LibreSSL (форк OpenSSL от OpenBSD)
• GnuTLS (начиная с версии 3.2.0)
• NSS (Network Security Services, используется в Firefox)
• SChannel (встроенная реализация TLS в Windows)
• Secure Transport (встроенная реализация TLS в macOS и iOS)

Сравнение с NPN

Источники

• RFC 7301: Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
• RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2)
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• IANA: Transport Layer Security (TLS) Extensions Registry
• OpenSSL: ALPN Support Documentation