TLS termination: где держать, чтобы не ловить лишний риск и лишний TTFB

TLS termination: где держать, чтобы не ловить лишний риск и лишний TTFB

Если расшифровку держать на краю, backend видит уже чистый HTTP и не тратит CPU на TLS. Для лендинг-сетки, WordPress с кешем и простого API это обычно нормальный баланс: меньше задержка, проще ротация сертификатов, удобнее WAF и rate limit.

Но есть правило: чем ближе termination к приложению, тем проще логика доверия. Если между CDN и origin ходит только HTTPS с origin cert, а IP origin закрыт фаерволом, вы убираете классическую ошибку с «голым» бэкендом. Если же сервисы ходят друг к другу внутри сети, TLS лучше не снимать раньше, чем нужно для балансировщика или ingress.

Где держать termination:
— CDN/edge: когда важны кеш, бот-фильтр и единый вход
— Load balancer: когда несколько приложений за одним доменом
— App server: когда нужны mTLS, client cert или строгая сегментация
— Внутри mesh: только если у вас есть контроль над сеткой и ключами

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

Итого: termination ставьте максимально наружу для типового сайта, но не дальше, чем позволяет ваша модель доверия.