TLS termination на CDN или origin: где расшифровывать трафик

TLS termination — это завершение защищённого соединения в точке, где зашифрованный трафик расшифровывается и превращается в обычные HTTP-запросы. Когда сайт подключён к CDN, такой точкой может быть пограничный узел провайдера или непосредственно сервер origin на VDS.

Место расшифрования влияет на задержки, кэширование, работу WAF, доступность журналов, управление сертификатами и модель доверия. При этом формулировки «сайт работает по HTTPS» недостаточно: защищённое соединение браузера с CDN ничего не говорит о том, как CDN передаёт запрос дальше.

На практике используются три основные архитектуры:

• TLS завершается на CDN, а до origin запрос передаётся по HTTP;
• CDN завершает клиентский TLS и устанавливает отдельное HTTPS-соединение с origin;
• зашифрованный поток проходит через промежуточную инфраструктуру без расшифрования и завершается только на origin.

У этих моделей разные свойства. Универсально лучшего варианта нет: границу расшифрования выбирают с учётом функций CDN, характера данных, устройства сети и того, насколько владелец сайта готов доверять посреднику.

Что именно происходит при TLS termination

В обычной схеме без CDN браузер устанавливает TLS-соединение непосредственно с веб-сервером. Сервер предъявляет сертификат, стороны согласуют параметры защищённого канала, после чего внутри него передаются HTTP-запросы и ответы.

При завершении TLS на CDN клиент подключается уже не к origin, а к edge-узлу. Сертификат домена предъявляет CDN, и именно на его инфраструктуре становятся доступны метод запроса, URL, заголовки, cookie и тело сообщения. После этого CDN может проверить запрос средствами WAF, найти объект в кэше, изменить заголовки или обратиться к origin.

Следующий участок выбирается отдельно. Между CDN и VDS может работать обычный HTTP либо новое TLS-соединение. Во втором случае возникает не один непрерывный защищённый канал, а два независимых:

1. клиент — CDN;
2. CDN — origin.

Протоколы, наборы шифров, сертификаты и срок жизни соединений на этих участках могут различаться. HTTPS на обоих участках защищает данные при передаче, но не скрывает их от CDN: между двумя TLS-сессиями запрос существует в расшифрованном виде и может обрабатываться посредником.

Термин «сквозное HTTPS» иногда используют для схемы с двумя TLS-соединениями. Криптографически это не сквозное шифрование между посетителем и origin, потому что CDN имеет доступ к открытому содержимому.

Модель 1: TLS на CDN и HTTP до origin

В этой архитектуре клиентская сессия завершается на edge-узле, после чего CDN отправляет запрос на VDS без TLS. Снаружи сайт выглядит защищённым: браузер видит HTTPS и сертификат домена. Однако последний сетевой участок остаётся незашифрованным.

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

• Минимальная сложность origin. На VDS не требуется сертификат для соединения с CDN, если сервер вообще недоступен по HTTPS.
• Небольшие вычислительные затраты. Origin не выполняет TLS-рукопожатия и шифрование ответов. Для современного сервера эта экономия обычно не является решающей, но может быть заметна при очень большом числе коротких соединений без их повторного использования.
• Простая внутренняя диагностика. Веб-сервер получает обычный HTTP, поэтому меньше риск ошибок, связанных с цепочкой сертификатов, именем узла или политиками TLS.

Недостатки и риски

Главный недостаток — возможность чтения и изменения трафика между CDN и origin. Риск зависит от маршрута. Если узлы связаны через публичный интернет, незашифрованными могут передаваться пароли, cookie сессий, персональные данные, административные запросы и ответы API.

Даже если провайдер описывает участок как внутреннюю сеть, необходимо понимать её границы: является ли она изолированной, кто имеет к ней доступ и проходит ли трафик через сторонние сегменты. Само слово «внутренняя» не обеспечивает ни аутентификацию узла, ни криптографическую защиту.

Возникают и прикладные нюансы. Origin видит входящее HTTP-соединение и без дополнительных настроек может считать исходную схему небезопасной. Это способно вызвать циклические перенаправления, неверное формирование абсолютных URL или отсутствие флага Secure у cookie. CDN обычно передаёт информацию об исходной схеме в служебном заголовке, но доверять такому заголовку следует только в запросах от доверенного прокси. Настройка реального IP и доверенных заголовков подробно рассмотрена в материале о TLS termination за прокси и защите от редирект-лупов.

Когда модель допустима

HTTP до origin можно рассматривать для закрытого, контролируемого транспортного сегмента, где риск перехвата принят осознанно и не передаются чувствительные данные. Для интернет-магазина, панели управления, личного кабинета, API с токенами или сайта, обрабатывающего персональные данные, предпочтительнее шифровать и внутренний участок.

Использовать эту схему только ради экономии ресурсов VDS обычно не стоит. Нагрузка от TLS зависит от трафика, алгоритмов, повторного использования соединений и возможностей процессора, а CDN часто поддерживает постоянные соединения с origin. Решение следует принимать после измерений, а не исходя из представления, что любое шифрование создаёт критическую нагрузку.

Модель 2: два TLS-соединения и HTTPS до origin

Это наиболее распространённый компромисс для CDN уровня HTTP. Посетитель устанавливает TLS-сессию с edge-узлом, CDN расшифровывает запрос, выполняет кэширование и проверки, а затем при необходимости открывает отдельное защищённое соединение с VDS.

Такая архитектура сохраняет функции CDN и защищает данные на обоих сетевых участках. Но она требует доверия к провайдеру: CDN всё равно видит открытые запросы и ответы.

Производительность

Клиентское TLS-рукопожатие выполняется рядом с посетителем, поэтому его задержка обычно определяется расстоянием до ближайшего edge-узла, а не до VDS. Это особенно полезно для географически распределённой аудитории. Дополнительное соединение CDN с origin создаёт собственные сетевые и вычислительные затраты, однако их влияние зависит от реализации.

CDN может поддерживать уже открытые соединения с origin, объединять последовательные запросы и повторно использовать TLS-сессии. В таком случае новое рукопожатие не требуется для каждого обращения посетителя. Кроме того, запросы, обслуженные из кэша, вообще не доходят до VDS.

Наибольшее влияние внутренний TLS оказывает при частых обращениях к origin, коротком времени жизни соединений и большой сетевой задержке между площадками. Поэтому важно оценивать не только цену одного рукопожатия, но и долю попаданий в кэш, частоту создания соединений и расположение origin относительно инфраструктуры CDN.

Сертификат на edge и сертификат origin

У двух участков разные задачи, поэтому для них могут использоваться разные сертификаты.

• Edge-сертификат предъявляется браузерам и должен быть действителен для публичного имени сайта. Его цепочка должна распознаваться клиентскими устройствами.
• Origin-сертификат предъявляется CDN. Требования к нему определяются механизмом проверки на стороне провайдера: это может быть публично доверенный сертификат либо сертификат, выпущенный поддерживаемым частным центром.

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

При выборе режима следует выяснить:

• проверяется ли цепочка доверия сертификата origin;
• проверяются ли срок действия и имя сервера;
• какое имя CDN передаёт в SNI и ожидает в сертификате;
• поддерживается ли частный центр сертификации;
• что происходит при ошибке проверки: запрос блокируется или отправляется в ослабленном режиме.

Автоматическое продление сертификата на VDS остаётся обязательным, если используется короткоживущий публичный сертификат. Важно также контролировать перезагрузку конфигурации веб-сервера после обновления и заранее получать уведомления о приближении срока окончания. Общие принципы выбора и эксплуатации сертификатов собраны в статье «HTTPS без боли: выбор и установка SSL, автообновление, HSTS и редиректы».

Аутентификация CDN перед origin

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

Для защиты применяют несколько уровней:

• ограничение входящих соединений актуальными диапазонами адресов CDN;
• взаимный TLS, при котором CDN предъявляет клиентский сертификат;
• криптографически проверяемые подписи запросов, если они поддерживаются архитектурой;
• секретный заголовок как дополнительный, но не единственный барьер;
• закрытая сеть или выделенный канал между инфраструктурой CDN и VDS.

Фильтрация по IP эффективна только при регулярном обновлении списков и учёте IPv4 и IPv6. Ошибка в правилах способна либо открыть origin, либо заблокировать легитимный трафик. Взаимный TLS даёт более сильную аутентификацию, но требует управления клиентскими сертификатами и проверки возможностей конкретного CDN.

Секретный заголовок проще внедрить, однако он находится внутри запроса и становится известен инфраструктуре CDN. Его нужно защищать от попадания в журналы и периодически менять. Такой механизм не заменяет сетевые ограничения и TLS-аутентификацию там, где требуется строгая защита.

Модель 3: TLS passthrough до origin

При настоящей сквозной модели TLS-соединение устанавливается между клиентом и сервером на VDS. Промежуточная платформа пересылает зашифрованный поток, не получая ключей для расшифрования. Сертификат сайта предъявляет origin, и там же находится закрытый ключ.

В таком режиме посредник может работать как сетевой балансировщик или служба защиты транспортного уровня, но не как полноценный HTTP-прокси. Не имея доступа к HTTP, он не может обычным способом анализировать URL, заголовки, cookie и тело запроса.

Что теряется без расшифрования

• кэширование HTTP-ответов на edge;
• WAF с анализом методов, путей, параметров и тела запроса;
• перенаправления и изменение HTTP-заголовков на стороне CDN;
• оптимизация HTML, изображений и другого содержимого;
• маршрутизация по URL и cookie;
• подробные журналы HTTP-запросов на стороне посредника;
• часть механизмов защиты от ботов и прикладных атак.

Возможности зависят от класса сервиса. Даже не расшифровывая трафик, платформа может ограничивать соединения, фильтровать известные сетевые атаки и распределять TCP-потоки. Однако эти функции нельзя приравнивать к проверке HTTP-запросов.

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

Главное преимущество — сокращение круга сторон, которым доступно содержимое трафика. Закрытый ключ остаётся на VDS, а посредник не видит пароли, содержимое форм, cookie и ответы приложения. Это может быть важно для систем с жёсткой моделью доверия, внутренних сервисов, специализированных API и инфраструктуры, где функции CDN уровня HTTP не требуются.

Origin также получает исходную TLS-сессию и самостоятельно управляет допустимыми версиями протокола, шифрами и клиентскими сертификатами. Если приложение использует mTLS для аутентификации конечных клиентов, прямое завершение соединения на origin часто проще для понимания и аудита.

Ограничения и цена

Посетитель устанавливает защищённое соединение с удалённым VDS, поэтому edge-узел не сокращает сетевое расстояние TLS-рукопожатия так, как при завершении на CDN. Все HTTP-запросы достигают origin, а значит, сервер принимает полную прикладную нагрузку и не получает преимуществ edge-кэша.

Масштабирование также меняется. Чтобы распределять зашифрованные соединения между несколькими серверами, балансировщик должен использовать признаки транспортного уровня или доступные метаданные TLS. Маршрутизация по пути запроса до расшифрования невозможна.

Наконец, не каждый продукт, называемый CDN, поддерживает passthrough. Часто эта возможность относится к отдельной услуге TCP-проксирования или глобальной балансировки. При оценке необходимо проверять не название тарифа, а точную точку завершения TLS и доступные функции.

Сравнение трёх архитектур

Как точка расшифрования влияет на видимость трафика

Завершив TLS, CDN получает техническую возможность читать и изменять HTTP-содержимое. Это необходимо для кэша, WAF и оптимизации, но одновременно расширяет доверенную зону. В неё входят не только edge-серверы, но и системы журналирования, аналитики, поддержки и внутренней передачи данных провайдера.

Владельцу сайта стоит выяснить, какие сведения записываются в журналы. URL может содержать поисковые запросы, идентификаторы и другие чувствительные параметры. Заголовки несут cookie и токены авторизации, а тело запроса — данные форм. Безопасная архитектура не должна рассчитывать только на то, что канал зашифрован: приложение обязано минимизировать чувствительные данные в URL, корректно управлять сессиями и исключать секреты из журналов.

HTTPS между CDN и origin защищает трафик в сети, но не уменьшает видимость со стороны CDN. Если требование состоит именно в том, чтобы посредник не мог прочитать данные, потребуется TLS passthrough либо дополнительное шифрование отдельных полей на уровне приложения. Последний вариант усложняет обработку и не превращает обычный CDN в полностью недоверенный узел: он по-прежнему видит незашифрованные части HTTP-запроса.

Влияние на сертификаты и управление ключами

При edge termination закрытый ключ, используемый для соединений с посетителями, доступен инфраструктуре, которая завершает TLS. Провайдер может хранить его в управляемой системе или выпускать сертификат автоматически. Это упрощает продление и развёртывание сайта на множестве узлов, но переносит часть контроля к третьей стороне.

Загрузка собственного сертификата не отменяет этот факт: чтобы обслуживать TLS-сессии, edge-инфраструктура должна иметь возможность использовать соответствующий ключ. Если политика организации запрещает передачу или использование ключа внешним оператором, обычное завершение TLS на CDN не подходит.

В схеме с повторным HTTPS у origin должен быть отдельный сертификат. Необязательно использовать тот же ключ, что и на edge. Разделение ключей уменьшает последствия компрометации одного участка и упрощает ротацию. Сертификат origin может быть привязан к отдельному имени, которое не публикуется как основной адрес сайта, если CDN умеет корректно передавать это имя и проверять его.

При passthrough сертификатом управляет владелец VDS. Он отвечает за выпуск, хранение ключа, продление, настройку полной цепочки и безопасное применение обновлений. Ошибка на origin сразу затрагивает посетителей, тогда как при edge termination проблема внутреннего сертификата обычно проявляется только в запросах, которые CDN не может получить из кэша.

Производительность: что действительно нужно измерять

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

• расстояние от посетителя до точки завершения TLS;
• доля ответов, выдаваемых из edge-кэша;
• задержка между CDN и VDS;
• повторное использование соединений с origin;
• размер и динамичность ответа;
• скорость приложения и базы данных;
• число перенаправлений и дополнительных запросов страницы.

Для статического сайта с высоким процентом попаданий в кэш завершение TLS на edge обычно даёт заметное преимущество: большинство запросов не доходит до VDS. Для полностью динамического API эффект кэширования может отсутствовать, но остаются близкая к клиенту точка приёма соединения, защита от части атак и возможность поддерживать устойчивый пул соединений до origin.

Сквозная модель может быть оправдана требованиями доверия, однако её не следует выбирать как автоматический способ ускорения сайта. Чтобы оценить результат, сравнивают время TLS-рукопожатия, время до первого байта, долю кэш-попаданий, число новых соединений к origin и загрузку процессора VDS. Измерения следует проводить из регионов, где находится реальная аудитория.

Как выбрать границу расшифрования

Выбирайте TLS на CDN и HTTPS до origin для большинства публичных сайтов

Эта модель подходит интернет-магазинам, медиа, корпоративным сайтам, личным кабинетам и публичным API, если владельцу необходимы кэш, WAF, фильтрация ботов и глобальная доставка. Она обеспечивает шифрование на обоих сетевых участках и сохраняет прикладные функции CDN.

При этом origin должен проверяться по действительному сертификату, прямой доступ к нему следует ограничить, а доверенные прокси — явно перечислить в конфигурации приложения или веб-сервера. Нельзя считать безопасным режим, в котором HTTPS включён, но ошибки сертификата игнорируются.

Оставляйте HTTP до origin только в контролируемой среде

Такой вариант допустим, если транспортный сегмент действительно изолирован, данные не требуют дополнительной защиты, а риск зафиксирован и принят. Для обычного VDS с публичным адресом передача трафика от CDN по HTTP создаёт лишнюю уязвимость без значительного практического выигрыша.

Если текущая система уже использует HTTP, переход на HTTPS до origin лучше выполнять отдельно от смены DNS или CDN-провайдера. Сначала нужно настроить и проверить TLS на VDS, затем включить строгую проверку сертификата со стороны CDN и только после этого ограничивать прямой доступ.

Используйте passthrough, когда конфиденциальность важнее функций CDN

Сквозное соединение подходит, если посредник не должен видеть HTTP-содержимое, закрытый ключ запрещено размещать вне собственной инфраструктуры либо конечный TLS используется для аутентификации клиентов. Взамен придётся отказаться от большинства функций CDN уровня приложения и принять полную нагрузку на origin.

Перед выбором нужно убедиться, что услуга действительно не завершает TLS ни на одном промежуточном узле. Формулировка «защищённая доставка» может означать два отдельных HTTPS-соединения, а не passthrough.

Практический чек-лист для владельца VDS

До изменения архитектуры полезно ответить на следующие вопросы:

1. Нужен ли CDN доступ к HTTP? Без расшифрования не будут полноценно работать кэш, WAF и маршрутизация по URL.
2. Какие данные проходят через сайт? Учтите пароли, cookie, токены, персональные сведения, платёжные и административные запросы.
3. Можно ли доверять провайдеру открытый трафик? Оцените не только договорные условия, но и географию обработки, журналы и доступ сотрудников.
4. Зашифрован ли участок до origin? Наличие HTTPS в адресной строке не отвечает на этот вопрос.
5. Проверяет ли CDN сертификат VDS? Нужны проверка имени, срока действия и цепочки доверия.
6. Как origin отличает CDN от прямого клиента? Рассмотрите сетевые ограничения, mTLS и другие механизмы аутентификации.
7. Что произойдёт при отказе CDN? Заранее определите, допустим ли прямой доступ, резервный маршрут или временное переключение DNS.
8. Кто продлевает каждый сертификат? Ответственность за edge-сертификат и сертификат origin может лежать на разных сторонах.
9. Какие метрики доступны? Нужны данные о кэше, ошибках соединения с origin, задержке и статусах ответов.
10. Проверена ли работа реального IP и исходной схемы? Приложение должно доверять служебным заголовкам только от известных прокси.

Типичные ошибки архитектуры

• Считать два HTTPS-участка одной TLS-сессией. CDN расшифровывает трафик и остаётся доверенной стороной.
• Включить HTTPS до origin без проверки сертификата. Шифрование без надёжной аутентификации не защищает от подмены сервера.
• Оставить VDS открытым для всего интернета. Это позволяет обходить WAF, лимиты и правила CDN.
• Доверять заголовкам реального IP от любого клиента. Напрямую обратившийся пользователь может подставить ложное значение, если веб-сервер не ограничивает список доверенных прокси.
• Разместить секреты в URL. Они могут попасть в журналы CDN, веб-сервера, аналитики и историю браузера.
• Забыть про IPv6. Origin может быть закрыт по IPv4, но оставаться доступным через публичный IPv6-адрес.
• Не контролировать продление внутреннего сертификата. Просроченный сертификат способен привести к ошибкам получения динамических страниц и промахов кэша.
• Ожидать от passthrough обычных возможностей CDN. Без открытого HTTP посредник не может полноценно кэшировать и фильтровать прикладные запросы.

Итог

Для большинства сайтов на VDS практичным выбором становится завершение TLS на CDN с отдельным строго проверяемым HTTPS-соединением до origin. Такая схема сочетает кэширование и защиту на edge с шифрованием последнего сетевого участка. Её безопасность зависит от проверки сертификата, ограничения прямого доступа к VDS и корректного управления доверенными заголовками.

HTTP между CDN и origin оправдан только в осознанно контролируемой сети. Его не следует считать безопасным продолжением клиентского HTTPS. Настоящий TLS passthrough сохраняет конфиденциальность содержимого от посредника, но лишает CDN большей части возможностей уровня HTTP и переносит обработку всех запросов на origin.

Для размещения origin выбирайте VPS-сервер с достаточными ресурсами и возможностью настроить сетевые правила, сертификаты и веб-сервер в соответствии с выбранной моделью.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Поэтому границу расшифрования следует выбирать не по одному показателю скорости. Решение должно одновременно отвечать четырём требованиям: обеспечивать нужные функции edge-платформы, защищать оба сетевых участка, соответствовать допустимой модели доверия и оставаться управляемым с точки зрения сертификатов и эксплуатации VDS.