Два TLS на одном сайте: обычный и ГОСТ одновременно

MAATRIX

Сайт живёт обычной жизнью — Let's Encrypt или сертификат от привычного УЦ, браузеры молча зеленеют. А потом появляется требование: часть клиентов должна подключаться через ГОСТ-криптографию, потому что это условие интеграции с госсистемой, банком или отраслевой платформой. И тут выясняется, что «просто поставить второй сертификат» не работает — ГОСТ TLS живёт по своим правилам, и совместить его с обычным HTTPS на одном порту в лоб нельзя. Разберём, какие архитектурные схемы реально применяют, и на что вы наткнётесь при реализации.

Почему это не тривиальная задача

Обычный TLS (1.2/1.3) и ГОСТ TLS — это, по сути, два разных криптографических стека. У них разные наборы алгоритмов (cipher suites), разные механизмы согласования (handshake), и — что важнее всего для архитектуры — клиент с ГОСТ-криптографией физически не умеет договориться с сервером, который предлагает только классические наборы, и наоборот. Обычный браузер не понимает ГОСТ-наборы, а специализированный ГОСТ-клиент (часто это не браузер, а СКЗИ-модуль или прокси, встроенный в клиентское ПО госсистемы) может не поддерживать современные наборы TLS 1.3 в привычном виде.

Стандартный веб-сервер (nginx, Apache, любой обычный обратный прокси) в базовой сборке работает с OpenSSL и умеет обычный TLS «из коробки». Поддержка ГОСТ-алгоритмов требует отдельного криптографического модуля — сертифицированного средства криптографической защиты информации (СКЗИ), которое подключается к серверу как криптопровайдер. Это не строчка в конфиге, а отдельный программный компонент со своими требованиями к сборке, лицензированию и (часто) к сертифицированному окружению.

Отсюда и главный архитектурный вопрос статьи: как на одном домене или одном сервере обслужить и тех, кому нужен обычный TLS, и тех, кому обязателен ГОСТ, не сломав ни тех, ни других.

Важная оговорка: конкретные продукты СКЗИ, их версии, точные названия модулей и директивы конфигурации сильно зависят от производителя, вашей инфраструктуры и требований регулятора — в этой статье я сознательно не привожу их, чтобы не давать устаревшую или неточную информацию. Уровень статьи — архитектурные принципы. Для конкретной реализации нужна консультация со специалистом по криптографической защите информации, который работает с актуальной версией нужного СКЗИ и знает требования вашего конкретного регулятора/интегратора.

Три базовых архитектурных подхода

На практике сосуществование двух TLS-стеков на одном сайте решают одним из трёх способов (или их комбинацией).

1. Отдельный поддомен под ГОСТ-контур. Самый простой и предсказуемый вариант: example.ru обслуживает обычных пользователей обычным TLS, а gost.example.ru (или secure.example.ru, gov.example.ru — как удобно) поднят на отдельном сервере или отдельном виртуальном хосте с ГОСТ-стеком. DNS указывает поддомен на IP, где стоит сервер с криптопровайдером ГОСТ. Клиент, которому нужен ГОСТ, изначально настроен ходить именно на этот адрес — интеграция описывает конкретный URL.

Плюсы: минимум связности между стеками, проще эксплуатировать, проще изолировать зону ответственности (в том числе для аудита и сертификации окружения — ГОСТ-контур часто подпадает под отдельные требования к защите информации). Минусы: два домена/поддомена нужно поддерживать в DNS, могут понадобиться отдельные сертификаты и для обычного поддомена тоже, если это публичный веб-ресурс.

2. Раздельные точки входа на уровне IP/порта на одном сервере. Один физический (или виртуальный) сервер, но два разных слушателя: обычный TLS на 443-м порту одного IP, ГОСТ TLS — на отдельном порту или отдельном дополнительном IP того же сервера. Это ближе к разделению «на уровне инфраструктуры, а не домена» — удобно, когда домен один и делить его на поддомены нежелательно (например, по требованиям заказчика интеграции).

Плюсы: не нужен отдельный сервер. Минусы: нестандартный порт для ГОСТ-клиента не всегда приемлем (некоторые интеграции жёстко ожидают 443), и обе конфигурации всё равно физически разделены на уровне процессов/слушателей — псевдо-единства на самом деле нет, просто он спрятан за одним доменным именем.

3. Определение клиента по возможностям на одной точке входа. Самый сложный вариант: один порт 443, один IP, а решение «какой стек предложить» принимается динамически на основе того, что умеет клиент. В теории это похоже на выбор версии протокола TLS 1.2 vs 1.3 — сервер объявляет поддерживаемые наборы шифров, клиент выбирает из пересечения. На практике для ГОСТ-контура это работает не так гладко, как хотелось бы: обычный TLS-стек и ГОСТ-стек — это часто не «один сервер с расширенным списком алгоритмов», а два разных программных компонента (обычный OpenSSL-стек и отдельный ГОСТ-криптопровайдер), и заставить их работать как единый слушатель на одном порту — задача уровня отдельного архитектурного проекта, а не конфига.

Здесь чаще применяют SNI-роутинг (Server Name Indication) — клиент ещё до шифрования отправляет имя хоста, к которому подключается, и на основе этого имени (или, реже, на основе самого поведения handshake) фронтирующий компонент решает, на какой бэкенд отдать соединение — с обычным TLS или с ГОСТ-терминацией. По сути это комбинация первого подхода (раздельные бэкенды) с общей точкой входа спереди.

Роль обратного прокси и балансировщика

Практически во всех рабочих схемах на самом краю сети стоит балансировщик или обратный прокси, который принимает соединения на 443-й порт и решает, куда их направить.

Если прокси умеет работать в режиме TCP-passthrough (просто перекидывает TCP-поток, не расшифровывая его), он может маршрутизировать по SNI без необходимости самому понимать ГОСТ-криптографию — это его и не касается, TLS-хендшейк (в том числе ГОСТовый) происходит уже на бэкенде, к которому прокси только подвёл сырой TCP-поток. Это ключевое архитектурное преимущество: балансировщику не нужно знать ГОСТ-алгоритмы, если он не терминирует TLS сам, а только маршрутизирует зашифрованные байты дальше.

Если же обратный прокси терминирует TLS сам (расшифровывает трафик, чтобы, например, применить WAF-правила или кэшировать), то ему придётся либо самому уметь ГОСТ-криптографию (то есть быть собран с нужным криптопровайдером), либо — что чаще — не терминировать ГОСТ-соединения вообще, а прозрачно прокидывать их дальше на специализированный сервер, который это умеет.

Практическая схема, которую видно чаще всего у тех, кто уже прошёл этот путь:

                     ┌─────────────────────┐
  Обычный клиент ──▶ │  Балансировщик/прокси │──▶ Backend A (обычный TLS,
                     │  (SNI-роутинг,        │     OpenSSL, Let's Encrypt/УЦ)
  ГОСТ-клиент ─────▶ │   TCP-passthrough)     │──▶ Backend B (ГОСТ TLS,
                     └─────────────────────┘     СКЗИ-криптопровайдер)

Обычный обратный прокси в роли терминатора TLS для классического трафика — задача полностью стандартная, её подробно разбирали в статье про Nginx как реверс-прокси на VPS. А вот терминация ГОСТ-TLS требует отдельного сервера или отдельного процесса с криптопровайдером — заводить её «заодно» на общем обратном прокси обычно не получается без специальной сборки.

Как определяют, какой клиент перед вами

На практике используют несколько сигналов, часто в комбинации:

• SNI (Server Name Indication). Если ГОСТ-клиенты явно настроены ходить на отдельное имя хоста (поддомен), роутинг по SNI — самый надёжный и стандартный способ развести трафик ещё до расшифровки.
• Порт подключения. Если интеграция допускает нестандартный порт, можно развести стеки просто по номеру порта на одном IP.
• IP или сетевой сегмент. Иногда ГОСТ-контур физически изолирован в отдельном сегменте сети (актуально, если есть требования к сертифицированному окружению) — тогда клиент попадает на нужный стек просто по маршруту, которым он идёт (например, через выделенный канал или VPN до защищённого контура).
• User-Agent или заголовки приложения — самый слабый и ненадёжный сигнал, потому что относится к прикладному уровню, а не к транспортному: решение о том, каким TLS-стеком отвечать, нужно принять до того, как заголовки HTTP вообще станут видны (они идут уже внутри зашифрованного соединения). Годится разве что как дополнительная проверка внутри уже установленного соединения, а не как основной механизм роутинга.

На практике комбинация «отдельный поддомен + SNI-роутинг на балансировщике + отдельный бэкенд с криптопровайдером» закрывает подавляющее большинство реальных задач и остаётся самой предсказуемой в эксплуатации.

Практические сложности, с которыми сталкиваются

Балансировка нагрузки. Если ГОСТ-контур должен быть отказоустойчивым (не единственный сервер), балансировщик перед ним должен либо сам поддерживать нужный криптопровайдер (что редкость и обычно требует специальной сборки), либо работать в чистом TCP/L4-режиме, передавая шифрование целиком на откуп бэкендам. Второй вариант проще в эксплуатации, но теряет часть возможностей L7-балансировки — например, невозможно балансировать по содержимому HTTP-запроса, если вы не расшифровываете трафик. Общие принципы выбора инструмента для балансировки (HAProxy как специализированный L4/L7-балансировщик против связки на базе Nginx) разобраны в статье HAProxy или Nginx для балансировки — для ГОСТ-контура на практике чаще годится именно L4-режим TCP passthrough.

Поддержка на стороне обратного прокси. Большинство популярных обратных прокси и балансировщиков (стандартные сборки Nginx, HAProxy, облачные балансировщики) не умеют ГОСТ-криптографию «из коробки» — она не входит в стандартный OpenSSL и требует отдельной пересборки с нужным криптомодулем или отдельного специализированного продукта. Это значит, что часть привычной функциональности обратного прокси (централизованная терминация TLS, единые логи TLS-сессий, единые метрики) для ГОСТ-контура придётся организовывать отдельно — на уровне бэкенда, который эту криптографию действительно поддерживает.

Сертификаты и их выпуск. Обычный TLS-сертификат можно получить автоматически (Let's Encrypt и подобные), а ГОСТ-сертификат выпускается только удостоверяющим центром, аккредитованным для этой криптографии, — это отдельный, не автоматизируемый процесс, с собственными сроками и требованиями к заявителю. Автопродление в привычном понимании (cron с certbot) для ГОСТ-контура обычно не работает так же гладко — сроки и процедуру продления нужно закладывать отдельно. Если на обычном контуре у вас уже стоит сертификат российского УЦ, процесс его установки на nginx (не ГОСТ, а обычный TLS-сертификат от российского УЦ) описан в статье про установку сертификата российского УЦ на nginx — это соседняя, но заметно более простая задача.

Мониторинг и логирование двух стеков. Если у вас два независимых бэкенда (обычный и ГОСТ), у вас и два независимых источника логов TLS-хендшейков, два набора метрик по сертификатам, два места, где может истечь срок действия. На практике стоит с самого начала завести единый дашборд или хотя бы единый чек-лист сроков действия сертификатов по обоим контурам — иначе продление ГОСТ-сертификата, который выпускается не автоматически, легко пропустить.

Требования к окружению. Для части задач ГОСТ-криптография должна работать в сертифицированном программно-аппаратном окружении — то есть не любой VPS годится в принципе, регулятор или интегратор может требовать конкретный класс защиты среды выполнения. Это нужно выяснять на старте проекта, а не после того, как инфраструктура уже развёрнута — переезд на другой класс окружения задним числом обычно дороже, чем заложить требование сразу.

Когда действительно нужен ГОСТ, а когда достаточно обычного TLS

Прежде чем городить второй TLS-стек, стоит трезво оценить, откуда взялось требование. Если интеграция с конкретной госсистемой или банком явно указывает ГОСТ TLS как обязательное условие протокола — деваться некуда, придётся разворачивать отдельный контур. Но иногда требование звучит расплывчато («у нас безопасность, нужна российская криптография») и оказывается, что на практике достаточно сертификата от российского УЦ поверх обычного TLS 1.2/1.3 — это совершенно другая, значительно более простая задача, никакого отдельного криптопровайдера не требующая. Разница принципиальная: сертификат от российского УЦ — это про то, кто подтверждает подлинность сайта; ГОСТ TLS — это про то, каким алгоритмом шифруется сам канал. Уточнить это на старте — экономит недели работы.

Более подробный разбор того, что конкретно нужно на стороне сервера и на стороне клиента для ГОСТ TLS (какие роли у сертификата, крипто-провайдера и клиентского ПО), есть в статье ГОСТ TLS на практике — рекомендую прочитать её вместе с этой, если вы только начинаете разбираться в теме.

Частые вопросы