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

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

16:56, 02.12.2022

Содержание статьи
arrow

  • Шифрование данных
  • Как происходит SSL/TLS-рукопожатие
  • Алгоритм Диффи-Хеллмана в TLS Handshake 1.2
  • Шифронаборы TLS 1.3
  • Вывод

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

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

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

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

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

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

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

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

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

Как работает 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, так что мы рекомендуем использовать именно его.

views 18s
views 2
Поделиться

Была ли эта статья полезной для вас?

Популярные предложения VPS

Другие статьи на эту тему

cookie

Принять файлы cookie и политику конфиденциальности?

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