Как работает SSL/TLS Handshake

SSL/TLS Handshake – «рукопожатие» между сервером и клиентом. Проще говоря – идентификация друг друга. Происходит во время HTTPS-соединения внутри зашифрованного туннеля SSL/TLS, который гарантирует безопасность как серверу, так и клиенту. После успешной идентификации генерируется секретный сеансовый ключ, который обеспечивает защищенную связь – он служит одновременно как для шифрования, так и для дешифрования передаваемых данных.

Шифрование данных

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

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

Как происходит SSL/TLS-рукопожатие

Если представить SSL-рукопожатие как диалог между сервером и клиентом, то процесс будет выглядеть следующим образом:

1. Клиент обращается к серверу с просьбой установить безопасное соединение и предлагает набор шифров, которые «понимает», а также совместимую версию SSL/TLS.
2. Сервер проверяет присланный шифронабор, сравнивает со своим, и отсылает ответ клиенту с файлом сертификата и открытым ключом.
3. Клиент проверяет сертификат и, если всё в порядке, предлагает проверить закрытый ключ. Для этого он его генерирует и шифрует общий секретный ключ с помощью присланного ранее открытого ключа сервера.
4. Сервер принимает ключ, проверяет его своим закрытым ключом. Далее он создает главный секрет, который и будет использоваться для шифрования обмениваемой информации.

После этого клиент отправляет серверу тестовое сообщение, зашифрованное по продуманному ранее методу, а тот его расшифровывает и анализирует. На этом SSL/TLS Handshake завершается, и клиент с сервером могут спокойно обмениваться информацией дальше.

Если сеанс будет завершен, и через какое-то время клиент снова обратится к серверу, проходить заново процедуру «рукопожатия» не потребуется – все сгенерированные ранее данные и главный секрет сохранят свою актуальность. Весь этот процесс занимает считанные секунды и проходит абсолютно незаметно для пользователя.



Алгоритм Диффи-Хеллмана в TLS Handshake 1.2

Версия протокола TLS 1.2 появилась в 2008 году как крупное обновление протокола 1.1 с улучшенным механизмом согласования сторонами списков поддерживаемых методов шифрования. Выглядит следующим образом:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Здесь:

• TLS — протокол передачи данных;
• ECDHE — временный (эфемерный) ключ;
• ECDSA — алгоритм аутентификации;
• AES 128 GCM — алгоритм симметричного шифрования;
• SHA256 — алгоритм хэширования данных.

Это и есть алгоритм Диффи-Хеллмана, но на сегодняшний день он уже считается устаревшим и редко где используется.

Шифронаборы TLS 1.3

Эта версия протокола увидела свет в 2018 году и претерпела ряд существенных улучшений:

• разделены процессы согласования ключей, аутентификаций и наборы шифрования;
• добавлено правило, утверждающее обязательность наличия цифровой подписи;
• внедрена функция получения ключа HKDF;
• ускорены процессы соединения;
• запрещено сжатие данных, шифры без аутентификации сообщений и пересогласование, которые обеспечивали определенную уязвимость предыдущей версии протокола;
• добавили поточный шифр ChaCha20 с MAC кодом Poly1305, эффективные алгоритмы цифровой подписи Ed25519 и Ed448, а также соответствующие им протоколы обмена ключами Curve25519 и Curve448.

Выглядит шифронабор рукопожатия TLS 1.3 так:

TLS_AES_256_GCM_SHA384

Соответственно, здесь:

• TLS — протокол;
• AES-256 в режиме GCM — алгоритм шифрования и аутентификации с дополнительными данными (AEAD);
• SHA384 — алгоритм функции формирования хешированного ключа (HKFD).

Протокол TLS 1.3 претерпел огромное количество изменений и улучшений, что положительно сказалось на безопасности и производительности процессов Handshake, а сама аутентификация стала занимать значительно меньше времени. Скорость рукопожатия увеличилась почти в 2 раза, при этом протокол лишился нескольких уязвимостей, которые ранее доставляли немало проблем системным администраторам.

Вывод

Наиболее безопасный вариант – криптографический протокол TLS 1.3, но он обладает специфической обратной совместимостью. При установке соединения клиент и сервер обмениваются версиями протокола и выбирается тот, с которым могут работать обе стороны. Однако на практике оказалось, что некоторое количество серверов на старом протоколе TLS 1.2 мгновенно обрывали соединение в случае, если процесс «рукопожатия» должен был состояться через протокол TLS 1.3. Этот феномен был назван оссификацией, и из-за него в первые годы возникали проблемы с внедрением нового протокола. На сегодняшний день эта проблема не встречается практически нигде, а сами серверы в большинстве своем перешли на TLS 1.3, так что мы рекомендуем использовать именно его.