TLS

TLS, или Transport Layer Security, — криптографический протокол, предназначенный для защиты данных при передаче между клиентом и сервером по сети.

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

Протокол используется не только браузерами. TLS применяется в API, электронной почте, базах данных, прокси-серверах, балансировщиках нагрузки, микросервисах, VPN и других сетевых системах.

TLS защищает данные во время передачи между узлами, но сам по себе не делает приложение безопасным и не защищает данные до отправки или после их получения.

Что такое TLS простыми словами

Без защищенного соединения данные между клиентом и сервером могут передаваться так, что участник сети потенциально способен их прочитать или изменить.

Client
↓ unprotected traffic
Network
↓
Server

TLS создает зашифрованный канал:

Client
↓ encrypted TLS connection
Network
↓
Server

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

Расшифровка TLS

TLS расшифровывается как Transport Layer Security — безопасность транспортного уровня.

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

Для чего нужен TLS

TLS решает три основные задачи:

• Confidentiality — скрывает содержимое передаваемых данных;
• Integrity — позволяет обнаружить изменение данных при передаче;
• Authentication — помогает проверить подлинность сервера, а в некоторых сценариях и клиента.

Конфиденциальность

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

Например, Password, API Request или документ передаются не как открытый текст.

Целостность

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

Если защищенный пакет был модифицирован, проверка целостности должна завершиться ошибкой.

Аутентификация

Обычно клиент проверяет цифровой сертификат сервера и убеждается, что соединяется с ожидаемым Domain.

Это помогает противодействовать подмене сервера.

TLS и HTTPS

HTTPS — это HTTP, работающий через защищенное TLS-соединение.

HTTP
+
TLS
=
HTTPS

HTTP определяет структуру Requests и Responses, а TLS защищает их при передаче.

TLS и SSL

SSL — предшественник TLS.

В разговорной речи выражения вроде SSL Certificate до сих пор используются, но современные защищенные соединения строятся на TLS.

Термин SSL часто сохраняется по историческим и маркетинговым причинам.

TLS Handshake

Перед началом защищенного обмена Client и Server выполняют Handshake.

В ходе него стороны согласуют криптографические параметры, проверяют Certificate и создают ключи для дальнейшего шифрования Traffic.

Client
↓ handshake
Server
↓ certificate and key agreement
Client
↓
encrypted application data

Что происходит во время Handshake

Конкретные сообщения зависят от используемой версии TLS и конфигурации, но логически процесс включает:

1. согласование поддерживаемых параметров;
2. получение сертификата сервера;
3. проверку его подлинности;
4. криптографический обмен данными для формирования ключей;
5. переход к зашифрованному трафику.

Цифровой сертификат

Certificate связывает Cryptographic Public Key с определенной Identity, например Domain Name.

В нем могут содержаться:

• Domain;
• Public Key;
• Issuer;
• срок действия;
• Serial Number;
• Digital Signature.

Зачем нужен сертификат

Без Authentication злоумышленник мог бы попытаться представить собственный сервер как настоящий.

Certificate позволяет Client проверить, что Public Key действительно связан с ожидаемым сервером согласно модели доверия.

Certificate Authority

Certificate Authority, или CA, — удостоверяющий центр, который подписывает сертификаты.

Операционная система или Browser имеет набор доверенных Root CA и использует его при построении Chain of Trust.

Цепочка сертификатов

Certificate сервера может быть подписан не Root CA напрямую, а Intermediate CA.

Root CA
↓
Intermediate CA
↓
Server Certificate

Client строит цепочку и проверяет цифровые подписи.

Root Certificate

Root Certificate является верхней точкой доверия в соответствующей PKI-цепочке.

Он обычно уже присутствует в доверенном хранилище Client System.

Intermediate Certificate

Intermediate CA используется между Root и конечными сертификатами.

Server должен предоставлять необходимую цепочку так, чтобы Client смог корректно выполнить Validation.

Проверка имени домена

Недостаточно убедиться, что Certificate подписан доверенным CA.

Client также должен проверить, что Certificate действителен именно для Domain, к которому выполняется подключение.

SAN

Subject Alternative Name содержит имена, для которых действителен Certificate.

Например:

example.com
api.example.com

Wildcard Certificate

Wildcard Certificate может покрывать набор поддоменов определенного уровня.

Например, сертификат для шаблона вида *.example.com может использоваться для нескольких соответствующих Hosts, если это предусмотрено правилами сертификата.

Срок действия сертификата

Certificate действует ограниченное время.

После Expiration клиент должен считать его недействительным.

Поэтому автоматизация Renewal является важной частью эксплуатации TLS.

Что происходит при истечении сертификата

Browser или API Client может показать ошибку и отказаться от установления соединения.

Таким образом, даже полностью работоспособный Web Server может стать недоступным из-за просроченного Certificate.

Private Key

Закрытый ключ, связанный с Server Certificate, является критичным Secret.

Он должен храниться только на доверенных системах и иметь ограниченный Access.

Что произойдет при утечке Private Key

Компрометация ключа может позволить злоумышленнику выдавать себя за соответствующую систему в ряде сценариев.

Такой ключ необходимо заменить, выпустить новый Certificate и выполнить предусмотренные процедуры отзыва и реагирования.

Public Key

Public Key содержится в Certificate и может распространяться открыто.

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

Симметричное шифрование в TLS

После Handshake основной поток данных обычно защищается эффективными симметричными криптографическими механизмами.

Они быстрее асимметричных операций и хорошо подходят для передачи больших объемов данных.

Зачем нужны разные типы криптографии

Асимметрические механизмы удобны для Authentication и согласования ключей, а симметрические — для быстрого шифрования основного Traffic.

TLS объединяет эти подходы в одном протоколе.

Session Keys

Для конкретного защищенного соединения создаются временные криптографические ключи.

Они не должны совпадать с Private Key самого Certificate.

Forward Secrecy

Forward Secrecy означает, что компрометация долгосрочного Private Key в будущем не должна автоматически позволять расшифровать ранее записанные Sessions, если они были установлены с соответствующим механизмом обмена ключами.

Это важное свойство современных TLS-конфигураций.

Cipher Suite

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

В зависимости от версии TLS состав и роль Cipher Suite различаются.

Сервер следует настраивать на применение современных поддерживаемых наборов, соответствующих требованиям системы.

Почему нельзя включать все Cipher Suites

Поддержка устаревшей криптографии ради старых Clients может снижать уровень безопасности.

При настройке нужен баланс между Compatibility и Security.

Версии TLS

TLS развивался в нескольких версиях.

В современных системах следует использовать актуальные версии протокола, поддерживаемые Client и Server, а устаревшие варианты отключать согласно требованиям безопасности и совместимости.

Почему старые протоколы отключают

Со временем в криптографических протоколах и алгоритмах обнаруживаются ограничения и уязвимости.

Если Server продолжает поддерживать слабый вариант, злоумышленник может попытаться использовать его вместо более современного.

Protocol Downgrade

Downgrade Attack пытается заставить участников использовать менее защищенную версию протокола или параметры.

Современные механизмы TLS включают защиту от определенных видов такого понижения, но правильная Server Configuration по-прежнему важна.

TLS Termination

TLS не обязательно завершается непосредственно на Application Server.

Он может завершаться на:

• Reverse Proxy;
• Load Balancer;
• CDN;
• Ingress Controller;
• API Gateway.

Client
↓ HTTPS
Load Balancer
↓ HTTP or HTTPS
Backend

TLS Termination на Load Balancer

Load Balancer принимает зашифрованное соединение, выполняет TLS Handshake и затем передает Request Backend.

Это позволяет централизовать Certificates и разгрузить Application Servers.

Что происходит после TLS Termination

Между Proxy и Backend трафик может передаваться как незашифрованным, так и через новое TLS-соединение.

Выбор зависит от Threat Model и архитектуры сети.

TLS Re-encryption

При Re-encryption Front Proxy завершает внешнее TLS-соединение, а затем создает новое защищенное соединение до Backend.

Client
↓ TLS
Proxy
↓ TLS
Backend

Это позволяет сохранять шифрование на внутреннем участке.

End-to-End Encryption и TLS

TLS обеспечивает защищенный канал между конкретными точками соединения.

Если Traffic расшифровывается на Reverse Proxy, этот Proxy видит содержимое.

Поэтому TLS Termination не следует автоматически называть сквозным шифрованием между конечными пользователями.

TLS и Reverse Proxy

Reverse Proxy часто централизует:

• Certificates;
• TLS Policies;
• Redirect HTTP to HTTPS;
• Load Balancing;
• WAF;
• Logging.

TLS и CDN

CDN может устанавливать TLS-соединение с пользователем, а затем отдельное соединение с Origin Server.

Для полной защиты необходимо правильно настроить обе стороны.

Origin TLS

Даже если пользователь подключается к CDN через HTTPS, соединение CDN с Origin также желательно защищать TLS при соответствующей Threat Model.

Кроме того, CDN должен проверять Certificate Origin, а не просто шифровать соединение без Authentication.

TLS и WAF

Для анализа HTTPS Requests WAF должен видеть расшифрованный HTTP Traffic.

Поэтому WAF обычно располагается в точке TLS Termination или получает доступ к данным после расшифрования.

TLS и API

REST, GraphQL и другие API обычно работают через HTTPS.

TLS защищает:

• Authorization Header;
• Bearer Tokens;
• JSON Body;
• Cookies;
• API Responses.

Почему API Token не заменяет TLS

Даже очень надежный Access Token является Credential.

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

TLS и JWT

Цифровая подпись JWT защищает его от незаметного изменения, но не скрывает и не предотвращает кражу Bearer Token.

Поэтому JWT необходимо передавать через TLS.

TLS и OAuth

OAuth взаимодействия содержат Authorization Codes, Access Tokens, Refresh Tokens и другие чувствительные данные.

Защищенный транспорт является необходимой частью безопасной OAuth Architecture.

TLS и SSO

SSO Redirects, Cookies, Assertions и Tokens должны передаваться через защищенные соединения.

Компрометация Identity Provider Connection может иметь последствия сразу для множества приложений.

TLS и MFA

MFA защищает Authentication от компрометации одного фактора, а TLS защищает передачу Authentication Data по сети.

Эти меры решают разные задачи и дополняют друг друга.

mTLS

mTLS, или Mutual TLS, — взаимная TLS-аутентификация.

При обычном HTTPS чаще всего Client проверяет Certificate Server.

При mTLS Server также требует Certificate от Client.

Client certificate ↔ Server certificate

Для чего используют mTLS

mTLS применяется для:

• Service-to-Service Authentication;
• корпоративных API;
• Microservices;
• партнерских интеграций;
• доступа устройств;
• Zero Trust Architecture.

mTLS и Password

mTLS может подтверждать Machine Identity без обычного Password.

Но управление Certificates и Private Keys требует собственной PKI и жизненного цикла.

mTLS и Service Mesh

Service Mesh может автоматически выдавать Workload Identity и устанавливать mTLS между Microservices.

Service A
↓ mTLS
Service B

Это уменьшает необходимость вручную настраивать TLS в каждом приложении.

TLS в Kubernetes

В Kubernetes TLS используется для API, Ingress и внутренних компонентов.

Certificates могут управляться отдельно для внешнего Traffic и внутренних Service Connections.

TLS в Docker

Контейнеризация сама по себе не шифрует Network Traffic.

Если Containers взаимодействуют через недоверенную сеть, TLS необходимо настраивать на Application, Proxy или Service Mesh Layer.

TLS и базы данных

Database Client и Server могут использовать TLS для защиты:

• SQL Queries;
• Credentials;
• результатов запросов;
• Replication Traffic.

Почему TLS для Database важен

Database Password и бизнес-данные могут передаваться между Application Server и удаленной Database.

Даже внутри корпоративной сети не всегда разумно считать Traffic автоматически доверенным.

TLS и SMTP

SMTP может использовать TLS для защиты соединения при отправке электронной почты.

В зависимости от архитектуры применяется TLS с самого начала соединения или переход на защищенный режим через STARTTLS.

TLS и IMAP

IMAP через TLS защищает Login и содержимое почтового ящика при передаче между Mail Client и Server.

TLS и POP3

POP3 также может работать через защищенное соединение, чтобы Password и письма не передавались в открытом виде.

STARTTLS

STARTTLS — механизм, позволяющий начать соединение как обычное для соответствующего Application Protocol, а затем переключиться на TLS.

Это встречается, например, в некоторых почтовых протоколах.

Implicit TLS

При Implicit TLS защищенный Handshake начинается сразу после установления транспортного соединения.

Application Data передается только после создания TLS Channel.

TLS и DNS

Обычные DNS-запросы сами по себе традиционно не защищены TLS.

Для повышения конфиденциальности существуют отдельные механизмы передачи DNS через защищенные протоколы.

TLS и VPN

Некоторые VPN Technologies используют TLS как часть защищенного туннеля.

Однако TLS и VPN не являются синонимами: VPN обычно создает более широкий Network Tunnel, а TLS защищает конкретные транспортные или прикладные соединения.

TLS и SSH

SSH и TLS — разные криптографические протоколы.

SSH чаще используется для удаленного Shell, SFTP и Port Forwarding, а TLS — как универсальная защита Application Protocols.

TLS и Firewall

Firewall может разрешать или запрещать соединение по IP и Port, но при обычном TLS не видит содержимое зашифрованного Application Traffic.

Для более глубокого анализа могут применяться TLS Inspection или Application-aware Security Systems.

TLS Inspection

При TLS Inspection корпоративный Proxy завершает TLS-соединение клиента, анализирует Traffic и создает новое TLS-соединение до внешнего сервера.

Client
↓ TLS
Inspection Proxy
↓ TLS
Internet Server

Для этого корпоративные устройства должны доверять соответствующему CA.

Риски TLS Inspection

Inspection Proxy получает доступ к расшифрованному содержимому, поэтому становится критичной Security и Privacy точкой.

Его необходимо защищать, обновлять и строго контролировать.

TLS и Proxy

HTTP Proxy может туннелировать HTTPS Traffic без расшифрования или выполнять Inspection, если это предусмотрено корпоративной архитектурой.

Эти сценарии принципиально различаются с точки зрения Confidentiality.

TLS и NAT

NAT изменяет сетевые адреса, но не обязан расшифровывать TLS.

TLS работает поверх соединения независимо от обычной трансляции адресов.

TLS и Load Balancer

Load Balancer может работать на Network Layer и не завершать TLS либо выступать как Application Proxy и выполнять TLS Termination.

Выбор зависит от архитектуры.

SNI

SNI позволяет Client сообщить имя Server, к которому он хочет подключиться, на этапе установления TLS-соединения.

Это дает возможность обслуживать несколько HTTPS Sites на одном IP с разными Certificates.

Почему SNI важно для виртуального хостинга

До выбора Certificate Server должен понимать, для какого Domain устанавливается соединение.

SNI решает эту задачу для современных TLS-сценариев.

ALPN

ALPN позволяет Client и Server согласовать прикладной протокол внутри TLS.

Например, так может определяться использование HTTP/2 или другого поддерживаемого протокола.

TLS и HTTP/2

На практике HTTP/2 в Web часто используется через TLS.

При Handshake стороны могут согласовать подходящий Application Protocol.

TLS и HTTP/3

HTTP/3 работает поверх QUIC, где криптографическая защита тесно интегрирована с транспортом.

Поэтому архитектура установления защищенного соединения отличается от классического TCP плюс TLS.

Ошибки TLS-сертификата

Client может отклонить соединение по разным причинам:

• Certificate expired;
• Domain mismatch;
• Unknown CA;
• неполная Certificate Chain;
• Certificate not yet valid;
• ошибка Signature Validation.

Self-signed Certificate

Self-signed Certificate подписан собственным ключом и не связан автоматически с публичной цепочкой доверия.

Он может использоваться во внутренней инфраструктуре, если Client явно доверяет соответствующему Certificate или CA.

Почему не стоит отключать проверку сертификата

Разработчик иногда сталкивается с TLS Error и временно отключает Certificate Verification.

Это опасно, потому что Encryption без проверки Identity может оставить возможность Man-in-the-Middle Attack.

Man-in-the-Middle

MITM-атака предполагает, что злоумышленник располагается между Client и Server и пытается перехватывать или изменять обмен.

Certificate Validation является одним из ключевых механизмов противодействия такой подмене.

Encryption без Authentication

Сам факт наличия зашифрованного соединения недостаточен, если Client не знает, с кем именно установил его.

Поэтому Certificate Verification является такой же важной частью TLS, как Encryption.

HSTS

HSTS используется Web Site для указания Browser, что к Domain следует обращаться только через HTTPS.

Это помогает предотвращать случайный переход на незашифрованный HTTP в поддерживаемых сценариях.

HTTP Redirect на HTTPS

Web Server часто перенаправляет HTTP Requests на HTTPS.

Однако сам первый HTTP Request еще не защищен TLS, поэтому HSTS может дополнять Redirect Policy.

Mixed Content

Даже если Web Page открыта через HTTPS, она может попытаться загрузить некоторые ресурсы по HTTP.

Такой Mixed Content снижает безопасность страницы и обычно блокируется современными Browsers в чувствительных сценариях.

TLS и Cookies

Authentication Cookies следует передавать только по защищенному соединению.

Атрибут Secure указывает Browser не отправлять такую Cookie по обычному HTTP.

TLS и Password

Пароль пользователя должен передаваться через TLS, но это не решает вопрос его хранения на Server.

Для хранения Password применяют специализированное хеширование.

TLS и хеширование

Хеширование и TLS выполняют разные функции.

Хеширование создает Digest, а TLS защищает канал передачи.

Криптографические Hash Functions при этом используются внутри некоторых механизмов TLS.

TLS не защищает данные на диске

После получения HTTPS Request Server расшифровывает данные.

Если затем они сохраняются в Database в открытом виде, TLS уже не защищает их.

Для Data at Rest применяются другие механизмы.

TLS не защищает от SQL Injection

Злоумышленник может отправить вредоносный HTTP Request через полностью корректное HTTPS-соединение.

TLS защищает Traffic от перехвата, но не определяет, безопасно ли содержимое Request.

TLS не заменяет WAF

WAF анализирует HTTP Requests и пытается обнаруживать атаки уровня приложения.

TLS лишь обеспечивает защищенный транспорт.

TLS не заменяет Authentication

HTTPS подтверждает Server Identity, но не означает, что пользователь автоматически авторизован в приложении.

Для этого нужны Login, SSO, OAuth, Certificates или другие механизмы.

TLS и Zero Trust

В Zero Trust Architecture шифрование Traffic между Services является одним из базовых элементов.

Однако Access Decision также требует Identity, Authorization и Context.

Управление сертификатами

В крупной инфраструктуре могут существовать тысячи Certificates.

Необходимо контролировать:

• Owner;
• Domain;
• Expiration;
• Private Key;
• Renewal;
• Revocation;
• Deployment.

Автоматизация Renewal

Ручное продление сертификатов плохо масштабируется и повышает риск простоя.

Автоматизированная PKI или Certificate Management System может заранее обновлять Certificates и устанавливать их на нужные Services.

Certificate Monitoring

Monitoring должен предупреждать об истечении сертификата заранее.

Ждать момента, когда пользователи сами увидят TLS Error, слишком поздно.

Certificate Inventory

Компания должна знать, где используются ее Certificates.

Забытый старый Server может продолжать использовать уязвимую конфигурацию или просроченный Certificate.

Private Key Storage

Закрытые ключи можно хранить в защищенных Key Stores, HSM или Secret Management Infrastructure в зависимости от требований.

Доступ должен быть минимально необходимым.

HSM

Hardware Security Module предназначен для защищенного хранения и выполнения операций с Cryptographic Keys.

Это особенно актуально для критичных CA и высокочувствительных ключей.

Certificate Revocation

Если Certificate или Private Key скомпрометирован, одной проверки Expiration недостаточно.

PKI предусматривает механизмы публикации информации о досрочно недействительных Certificates.

TLS и Monitoring

Полезно контролировать:

TLS и SIEM

Security Logs могут содержать информацию о TLS Errors, Certificates, Client Authentication и подозрительных соединениях.

SIEM использует эти Events как часть общего Security Context.

TLS и SOC

SOC может расследовать аномальные Certificates, ошибки mTLS, неожиданные подключения и другие связанные события.

Но за ежедневное управление Certificate Lifecycle чаще отвечает Infrastructure или Security Engineering Team.

TLS и Observability

Observability помогает отличить TLS Problem от Application Failure.

Например, пользователь видит ошибку доступа, а Metrics показывают всплеск Handshake Failures после замены Certificate.

Влияние TLS на производительность

Handshake требует дополнительных вычислений и Network Round Trips.

Однако современные системы используют оптимизации, Session Resumption и эффективные криптографические алгоритмы.

Session Resumption

Повторное соединение с тем же Server может использовать механизмы возобновления Session, чтобы уменьшить стоимость полного Handshake.

Конкретный способ зависит от версии TLS и реализации.

Keep-Alive

Повторное использование существующего соединения также уменьшает количество Handshakes.

Это особенно важно для API с большим числом Requests.

TLS и Latency

В распределенных системах множество коротких соединений может создавать дополнительную задержку.

Connection Pooling и Keep-Alive помогают снизить этот Overhead.

Типичные ошибки TLS

1. Использовать просроченный Certificate.
2. Отключать Certificate Validation в Client.
3. Поддерживать ненужные устаревшие версии протокола.
4. Хранить Private Key в открытом виде.
5. Не контролировать Expiration.
6. Шифровать внешний Traffic, но оставлять чувствительный внутренний канал без защиты.
7. Считать TLS заменой Application Security.
8. Не проверять Domain Certificate.
9. Использовать один Private Key в слишком большом количестве систем без необходимости.
10. Не иметь процесса Key Rotation и Incident Response.

Как правильно настроить TLS

Шаг 1. Получить подходящий Certificate

Он должен соответствовать используемому Domain и модели доверия.

Шаг 2. Защитить Private Key

Ограничьте Access и не помещайте Key в публичный Repository.

Шаг 3. Включить актуальные версии TLS

Отключите ненужные Legacy Protocols в соответствии с требованиями Compatibility.

Шаг 4. Настроить Certificate Chain

Client должен корректно построить доверенную цепочку.

Шаг 5. Включить HTTPS Redirect и HSTS, где уместно

Это уменьшает вероятность незашифрованного Web Traffic.

Шаг 6. Автоматизировать Renewal

Сертификат не должен истекать неожиданно.

Шаг 7. Настроить Monitoring

Контролируйте Handshake Errors и Expiration.

Шаг 8. Проверить внутренние соединения

Определите, нужен ли TLS между Proxy, Applications, Databases и Microservices.

Практический пример

Компания публикует Web Application для клиентов.

Пользователь открывает:

https://portal.example.com

Browser устанавливает соединение с Load Balancer и получает Certificate для portal.example.com.

Он проверяет Domain, срок действия Certificate и Chain of Trust.

После успешного Handshake создаются Session Keys, и HTTP Requests начинают передаваться в зашифрованном виде.

На Load Balancer выполняется TLS Termination. Затем он устанавливает отдельное TLS-соединение до Application Server.

Пользователь вводит Login и Password. Они защищены при передаче внешним TLS Channel.

Application Server проверяет Credentials и создает Session.

Если злоумышленник прослушивает сеть между пользователем и сервисом, содержимое Login Request не должно быть доступно ему в открытом виде.

При этом TLS не мешает самому приложению допустить SQL Injection или ошибку Authorization, поэтому дополнительно используются безопасный код, WAF, IAM и другие Security Controls.

TLS для бизнеса

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

Для бизнеса важна не только установка Certificate на сайт. Необходимо управлять всем жизненным циклом: выпуском, Private Keys, Renewal, Monitoring, внутренним TLS и политикой допустимых протоколов.

В распределенной инфраструктуре TLS также становится способом защиты Machine-to-Machine Traffic и подтверждения Workload Identity через mTLS.

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

• шифрует данные при передаче;
• защищает целостность Traffic;
• позволяет проверять Server Identity;
• поддерживает Client Authentication через mTLS;
• используется в HTTPS и API;
• подходит для Microservices и Cloud;
• поддерживается большим количеством Application Protocols.

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

• не защищает Data at Rest;
• не исправляет уязвимости приложения;
• не предотвращает кражу данных на уже скомпрометированном Endpoint;
• требует управления Certificates и Keys;
• неверная Validation делает MITM возможнее;
• TLS Termination раскрывает Traffic соответствующему Proxy;
• не заменяет Authentication и Authorization пользователей.

Когда нужен TLS

TLS нужен практически во всех сценариях передачи чувствительной информации через недоверенную или потенциально наблюдаемую сеть.

Это касается Web, API, почты, Remote Services, Database Connections, Cloud и взаимодействия между Microservices.

Связанные термины

Краткий итог

TLS — Transport Layer Security, криптографический протокол защиты сетевых соединений. Он обеспечивает Confidentiality, Integrity и Authentication и лежит в основе HTTPS и множества других защищенных протоколов.

Для установки TLS-соединения Client и Server выполняют Handshake, проверяют Certificate и формируют временные ключи для шифрования Application Traffic. При этом сертификат и особенно связанный с ним Private Key требуют строгого управления.

TLS защищает данные только в процессе передачи и не заменяет WAF, IAM, MFA, безопасный код, EDR или Encryption at Rest. Наиболее надежная архитектура сочетает правильную TLS Configuration, автоматическое управление Certificates, Monitoring и другие уровни информационной безопасности.