## Основы протокола TLS
**TLS (Transport Layer Security)** — криптографический протокол, обеспечивающий безопасную передачу данных между двумя приложениями по сети. Протокол является наследником SSL (Secure Sockets Layer) и используется для защиты веб-трафика (HTTPS), электронной почты, мгновенных сообщений и других приложений.
> [!summary] Простыми словами
> TLS — это “защитный туннель” для данных. Всё, что передаётся через этот туннель, шифруется и не может быть прочитано посторонними. Сертификаты подтверждают, что вы подключились именно к нужному серверу, а не к поддельному.
## Этапы рукопожатия TLS (TLS Handshake)
Процесс установления защищённого соединения включает следующие этапы:
1. **Client Hello** — клиент отправляет список поддерживаемых шифров, версию TLS и случайное число.
2. **Server Hello** — сервер выбирает шифр из предложенных, отправляет свою версию TLS и случайное число.
3. **Certificate** — сервер отправляет свой сертификат для аутентификации.
4. **Server Key Exchange** (опционально) — сервер отправляет параметры для обмена ключами.
5. **Server Hello Done** — сервер завершает свою часть рукопожатия.
6. **Client Key Exchange** — клиент генерирует сеансовый ключ, шифрует его открытым ключом сервера и отправляет.
7. **Change Cipher Spec** — обе стороны переключаются на использование согласованного шифра.
8. **Encrypted Handshake Message** — обмен зашифрованными подтверждениями.
9. **Application Data** — начало передачи зашифрованных данных приложения.
“`mermaid
sequenceDiagram
participant C as Клиент
participant S as Сервер
C->>S: Client Hello (версия, шифры, random_C)
S->>C: Server Hello (выбранный шифр, random_S)
S->>C: Certificate (сертификат сервера)
S->>C: Server Hello Done
C->>S: Client Key Exchange (PreMasterSecret, зашифрованный)
C->>S: Change Cipher Spec, Encrypted Handshake
S->>C: Change Cipher Spec, Encrypted Handshake
C->>S: Application Data (зашифровано)
S->>C: Application Data (зашифровано)
“`
## Типы аутентификации в TLS
|Тип аутентификации|Описание|Использование|
|—|—|—|
|**Односторонняя (серверная)**|Клиент проверяет сертификат сервера. Сервер не проверяет клиента.|Большинство веб-сайтов (банки, магазины, порталы).|
|**Взаимная (двусторонняя)**|Клиент проверяет сертификат сервера, сервер проверяет сертификат клиента.|Корпоративные порталы, системы с повышенными требованиями к безопасности.|
> [!attention] Важно При взаимной аутентификации клиент должен иметь действительный сертификат, выпущенный доверенным центром сертификации. Если сертификат клиента отсутствует или отозван, соединение будет отклонено.
## Криптографические наборы (Cipher Suites)
**Cipher Suite** — набор алгоритмов, используемых для защиты соединения. Формат названия:
1
Пример: `TLS_RSA_WITH_AES_256_CBC_SHA256`
|Компонент|Назначение|Примеры|
|—|—|—|
|Key Exchange|Обмен ключами|RSA, DHE, ECDHE|
|Bulk Cipher|Шифрование данных|AES_128, AES_256, CHACHA20|
|MAC|Контроль целостности|SHA256, SHA384|
> [!tip] Совет Предпочтительны наборы с **Ephemeral** ключами (DHE, ECDHE), так как они обеспечивают **Forward Secrecy** — даже при компрометации долгосрочного ключа сервера прошлые сессии не могут быть расшифрованы.
## Сертификаты для веб-серверов
Для работы веб-сервера по HTTPS необходим сертификат со следующими характеристиками:
– **Subject Alternative Name (SAN)** — должен содержать доменное имя сервера (например, `DNS:study.su`).
– **Extended Key Usage (EKU)** — должен включать `Server Authentication` (OID `1.3.6.1.5.5.7.3.1`).
– **Key Usage** — должен включать `Digital Signature` и `Key Encipherment`.
> [!note] Примечание В лабораторной работе используется сертификат, выпущенный внутренним центром сертификации домена. В производственной среде для публичных сайтов используются сертификаты от публичных ЦС (Let’s Encrypt, DigiCert и др.), которые доверяются браузерами по умолчанию.