Кратко

  • ALPN поместил выбор прикладного протокола в рукопожатие TLS: клиент предлагает упорядоченный список, а сервер выбирает один общий идентификатор согласно собственной политике.
  • Выбрать значение вне списка нельзя. Если пересечения нет, фатальное оповещение no_application_protocol останавливает соединение до того, как одни и те же байты смогут получить два разных значения.
  • Результат принадлежит соединению, а не возобновляемому сеансу TLS. Старый билет не переносит ALPN, а успешный выбор не заменяет аутентификацию источника, подтверждение полномочий или авторизацию приложения.

Защищённые байты всё ещё могли попасть не в тот язык

TLS решает важную задачу: стороны обнаружат изменение защищённых сообщений, а при надлежащей проверке установят личность другой стороны в пределах выбранной модели доверия. Но целостность не говорит, является ли первая строка HTTP/1.1, кадром HTTP/2 или сообщением другой службы.

Когда несколько приложений используют одну точку подключения и один порт, ошибочная догадка об анализаторе может пережить успешное рукопожатие. Клиент отправит корректные для своей грамматики байты; сервер честно расшифрует их и истолкует по-другому. Именно надёжность доставки сделает смешение воспроизводимым.

RFC 7301 переносит выбор в рукопожатие TLS. Клиент называет набор допустимых идентификаторов протоколов, сервер возвращает один общий. До появления данных приложения возникает факт, который обе стороны связывают с этим соединением.

Это не полная защита от межпротокольных атак. Но она запрещает серверу объявить согласованной грамматику, которую клиент не предлагал, и позволяет закончить соединение до того, как неправильный анализатор создаст состояние.

Один порт перестал быть достаточным именем

Исторически общеизвестный порт часто подсказывал приложение. Совместное использование TLS, особенно через порт 443, позволило разным протоколам проходить через общую инфраструктуру. Цена удобства — неоднозначность верхнего слоя.

Отдельное согласование после TLS добавило бы сетевой обмен. Определение по первым данным отложило бы решение слишком надолго. ALPN использует уже обязательный ClientHello и ответ сервера.

RFC 8170 связывает практический импульс с HTTP/2. Защищённой версии требовалось согласование без дополнительной задержки, поэтому она использовала ALPN; для открытого текста пробовали механизм обновления протокола. ALPN стал основным способом выбирать следующие версии HTTP.

Обновление протокола HTTP начинается с действующей грамматики HTTP/1.1 и меняет её после ответа 101. ALPN выбирает грамматику до сообщения приложения. Поэтому прежняя история о посегментном обновлении не отвечает на вопрос этой статьи: что связывает анализатор с только создаваемым защищённым соединением.

Порядок клиента не был приказом серверу

Клиент отправляет непустые непрозрачные последовательности байтов в порядке своих предпочтений. У сервера есть собственный набор и порядок. Он должен выбрать значение из предложения и обычно берёт наиболее предпочтительное для себя среди общих.

У клиента остаётся право не принимать неизвестную грамматику. У сервера остаётся право выбирать политику обслуживания внутри разрешённого множества. Первый элемент списка клиента не передаёт ему управление сервером, а сервер не может добавить непредложенный вариант.

Ответ содержит один протокол. Он окончателен для соединения: объявив одно значение, сервер не вправе обмениваться данными приложения по другому. Это не отчёт обо всех возможностях сервера, а обязательство относительно последующих байтов.

Средства наблюдения должны сохранять оба контекста. Фраза «клиент поддерживает h2» не объясняет выбор http/1.1; версия исполняемого файла, которая «умеет h2», не доказывает действующую политику конкретного узла. Нужны исходный порядок, выбранное значение, экземпляр службы и версия конфигурации.

Отсутствие пересечения нельзя было лечить молчанием

Если сервер не поддерживает ни одного предложенного значения, RFC 7301 требует фатального оповещения no_application_protocol. Молчаливый откат уменьшил бы число отказов, но уничтожил бы общий ответ на вопрос о грамматике.

Клиент мог бы принять отсутствие ALPN за старый сервер, проигнорированное расширение или значение по умолчанию. Сервер ожидал бы формат, на который клиент не соглашался. Ошибка проявилась бы только после передачи данных и могла бы выглядеть как ошибка приложения.

RFC 9325 требует поддержки ALPN в современных реализациях TLS и рекомендует строго отвергать выбор вне списка клиента. В документе это связано со смешением протоколов: сообщение одного сервиса способно стать нежелательной командой в другом.

Фатальное оповещение не доказывает атаку и не указывает виновника. Оно доказывает более узкое: это соединение не получило общего прикладного протокола. Такая точность полезнее успешного соединения с вымышленной совместимостью.

Старый билет не имел права выбрать новый анализатор

Возобновление сеанса TLS позволяет повторно использовать часть криптографического состояния. Было бы удобно считать прошлый ALPN частью этого состояния. RFC 7301 прямо говорит обратное: расширение устанавливает свойство соединения, а не сеанса; при возобновлении прежнее содержимое не имеет значения.

Клиент мог удалить устаревший протокол. Сервер мог изменить предпочтение. Билет мог попасть к другому узлу. Если старый результат становится обязательным, механизм ускорения превращается в право прошлого блокировать развёртывание.

Разный выбор для нового и возобновлённого соединений сам по себе не означает поломку. Следует сравнить предложение, узел и политику. Цепочка билета нужна, чтобы связать наблюдения, а не чтобы копировать старое значение в новую запись.

Кроме того, билет не подтверждает полномочия источника и не разрешает запрос. Он участвует в TLS по правилам возобновления. Приложение принимает отдельные решения.

TLS 1.3 спрятал ответ сервера, но не всё предложение

В первоначальной схеме ALPN список клиента находился в ClientHello, а выбор сервера — в ServerHello. RFC 7301 допускал видимость метки для сетевых устройств, когда порт больше не определял приложение, и предупреждал о создании профилей по чувствительным идентификаторам.

RFC 8446 переместил ответ сервера в EncryptedExtensions. Это первое сообщение сервера, защищённое ключами трафика рукопожатия. Предложение клиента остаётся в обычном ClientHello.

Поэтому утверждение о видимости должно называть версию TLS, сторону и точку наблюдения. В TLS 1.3 выбор сервера защищён на этом этапе; список клиента не становится автоматически скрытым.

Изменение осложняет пассивное наблюдение, но не меняет область действия. Даже невидимый внешнему датчику результат создаётся заново для соединения и не наследуется от билета.

HTTP/2 отделил выбор от подтверждения

RFC 9113 требует h2 через ALPN для HTTP/2 поверх TLS. h2c относится к открытому тексту и запрещён в TLS ALPN.

После рукопожатия обе стороны всё равно передают префейс соединения. ALPN выбирает грамматику, а префейс подтверждает, что подключённое приложение действительно начинает с неё и задаёт SETTINGS.

Пограничный узел может успешно выбрать h2 и отправить поток во внутреннюю службу HTTP/1.1. Тогда ALPN будет корректен, а префейс — нет. Без связи этих журналов ошибку легко назвать несовместимостью клиента. Выбор и первое свидетельство приложения должны храниться вместе.

Успешный h2 также не означает право отвечать за любой источник. Протокол соединения и полномочия сервиса — разные утверждения.

Ранние данные не переходили через смену грамматики автоматически

TLS 1.3 допускает 0-RTT при некоторых возобновлениях. Клиент отправляет байты до завершения нового рукопожатия, опираясь на ожидания прошлого соединения.

RFC 8446 запрещает автоматическую повторную отправку ранних данных, если новое соединение не выбрало тот же протокол ALPN. Кадры HTTP/2 нельзя механически перенести в HTTP/1.1 лишь потому, что билет принят.

Одинаковый ALPN — необходимое, но не достаточное условие. Он не доказывает идемпотентность, неизменность учётных данных или отсутствие исполнения первой попытки. Решение о повторе принимает приложение.

Так разделяются компетенции: TLS знает грамматику соединения; приложение знает последствия операции.

QUIC сделал отсутствие выбора ошибкой соединения

RFC 9001 требует аутентифицированного согласования прикладного протокола для QUIC, обычно через ALPN. Без результата стороны немедленно закрывают соединение.

Прикладной протокол может ограничивать совместимые версии QUIC. Сервер обязан выбрать протокол, подходящий к выбранной клиентом версии, а клиент отвергает несовместимое сочетание.

Одного совпадающего имени мало. Возможности клиента, политика сервера и версия транспорта образуют реальное пересечение. Ошибка остаётся до появления состояния приложения, где её можно объяснить, а не после неверного разбора.

Реестр не превращал имя в доказательство использования

Реестр IANA расширений TLS и идентификаторов протоколов ALPN хранит расширение типа 16 и непрозрачные идентификаторы по процедуре экспертной проверки. Там есть http/1.1, h2, h3 и зарезервированный h2c, запрещённый в TLS ALPN.

Регистрация фиксирует последовательность байтов и спецификацию. Она не доказывает предложение, выбор, долю развёртывания или безопасность реализации. Для этого нужны записи рукопожатий и свидетельства приложения.

ALPN остаётся сильным, пока его утверждение не расширяют. Он говорит, какая грамматика назначена этому соединению. Он не говорит, кто авторизован, какой источник обслуживается и что произошло с запросом.

Билет сеанса может вернуться к серверу. Прежний протокол остаётся у прежнего соединения. Новое должно выбрать собственный язык или честно не начать разговор.

Источники

Эти источники определяют стандарты, рекомендации и назначения, но не измеряют современное внедрение или долю трафика.