Tls рукопожатие что это

Что такое рукопожатие SSL/TLS? Объясним за 3 минуты

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

Процесс называется рукопожатием или handshake, потому что клиент и сервер встречают друг друга впервые. Рукопожатие начинается с идентификации и заканчивается генерированием секретного ключа.

SSL/TLS-рукопожатие — что это?

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

Давайте представим выполнение TLS-рукопожатия как диалог клиента и сервера.

Клиент: «Привет! Я хочу установить безопасное общение между нами. Вот мой набор шифров и совместимая версия SSL/TLS».

Сервер: «Привет, клиент. Я проверил твой шифр и версию SSL/TLS. Думаю, мы можем продолжить общение. Вот мой файл сертификата и открытый ключ. Проверь их».

Клиент: «Сертификат в порядке. Но мне нужно проверить твой закрытый ключ. Я сейчас сгенерирую и зашифрую общий секретный ключ с помощью твоего открытого ключа. Расшифруй его с помощью своего закрытого ключа. Если все получится, ты создашь главный секрет, который мы будем использовать для шифрования и расшифрования информации».

Сервер: «Готово».

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

Клиент: «Я отправлю тебе тестовое сообщение, чтобы проверить, что наш главный секрет работает. Отправь мне расшифрованную версию этого сообщения. Если он работает, наши данные в безопасности».

Сервер: «Да, все работает».

Теперь, каждый файл, который будет передаваться от клиента к серверу и обратно, будет зашифрован. Это и есть SSL/TLS-рукопожатие.

Читайте также:

• SSL-сертификат – что это такое
• Как установить SSL-сертификат
• Как работает SSL-сертификат

Как устроено TLS-рукопожатие?

Протокол TLS активно работает со множеством процессов сетевого взаимодействия, начиная с передачи файлов и VPN-подключения, заканчивая IP-телефонией и службами обмена мгновенными сообщениями. Ключевой аспект протокола TLS — «рукопожатие». О нём и поговорим.

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

«Рукопожатием SSL/TLS» называют процесс, а точнее, этап установки HTTPS-соединения. И основная часть работы, связанная с SSL/TLS-протоколом, производится как раз на этом этапе.

В HTTPS-соединении участвуют 2 стороны: клиент (это инициатор соединения, как правило, web-браузер) и, разумеется, сервер. Цель SSL/TLS-рукопожатия заключается в выполнении всей криптографической работы для установки безопасного соединения, включая проверку подлинности задействованного SSL-сертификата и генерацию ключа шифрования.

Согласование шифронабора

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

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

Когда клиент получает сертификат, он проверяет его на подлинность. Дабы обеспечить безопасность соединения, надо не только зашифровать информацию, но и убедиться, что она отправляется на правильный web-сайт. Эту аутентификацию обеспечивают сертификаты SSL/TLS, а то, каким образом они это делают, уже зависит от применяемого шифронабора.

Все доверенные SSL-сертификаты выпускает центр сертификации (ЦС). ЦС — это что-то типа нотариуса, и его подпись означает, что данные в сертификате реальны.

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

В наиболее распространённой криптографической системе с открытым ключом — RSA, клиент посредством открытого ключа шифрует случайные данные, и эти данные потом используются для генерации сеансового ключа. При этом сервер может расшифровать и начать применять эти данные только в том случае, если имеет закрытый ключ, наличие которого и обеспечивает подлинность стороны.

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

Обмен ключами

Это финишная часть TLS-рукопожатия. Она предполагает создание «сеансового ключа», который станет использоваться для защищённой связи. Такие ключи являются «симметричными», когда один и тот же ключ применяется и для шифрования, и для дешифрования.

Говоря о симметричном шифровании, можно сказать, что оно производительнее, если сравнивать с асимметричным. А значит, оно лучше подходит для отправки данных по HTTPS. Что касается точного метода генерации ключа, то он зависит от выбранного шифронабора. Наиболее распространённые — RSA и Диффи-Хеллман.

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

Вообще, само SSL-рукопожатие происходит всего за несколько сотен миллисекунд. И это первое, что произойдёт при HTTPS-соединении, а произойдёт оно ещё даже до загрузки web-страницы. Далее, после рукопожатия начинается аутентифицированное и зашифрованное HTTPS-соединение, соответственно, все данные, которые отправляются и получаются клиентом и сервером, являются защищёнными.

Напоследок, отметим, что до выхода TLS 1.3 рукопожатие происходило заново каждый раз при посещении сайта. Но уже TLS 1.3 начал поддерживать 0-RTT (нулевое время возобновления приёма-передачи), а это существенно повысило скорость для посетителя, который повторно возвращается на сайт.

Что такое TLS-рукопожатие и как оно устроено

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

TLS — это один из наиболее часто встречающихся инструментов безопасности, используемых в интернете. Протокол активно работает со многими процессами сетевого взаимодействия: передачей файлов, VPN-подключением (в некоторых реализациях для обмена ключами), службами обмена мгновенными сообщениями или IP-телефонией.

Один из ключевых аспектов протокола — это рукопожатие. Именно о нём мы поговорим в этой статье.

«Рукопожатие SSL/TLS» — это название этапа установки HTTPS-соединения. Большая часть работы, связанной с протоколом SSL/TLS, выполняется именно на этом этапе. В прошлом году IETF доработал TLS 1.3, полностью обновив процесс рукопожатия.
В статье будут освещены два вида рукопожатия — для протоколов TLS 1.2 и TLS 1.3, которые мы рассмотрим, начиная с абстрактного уровня и постепенно углубляясь в особенности:

• согласование криптографических протоколов;
• аутентификация с помощью SSL-сертификата;
• генерация сеансового ключа.

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

В HTTPS-соединении участвуют две стороны: клиент (инициатор соединения, обычно веб-браузер) и сервер. Цель рукопожатия SSL/TLS — выполнить всю криптографическую работу для установки безопасного соединения, в том числе проверить подлинность используемого SSL-сертификата и сгенерировать ключ шифрования.

Согласование шифронабора

Каждое программное обеспечение уникально. Поэтому даже самые популярные веб-браузеры имеют различную функциональность. Аналогично и на стороне сервера — Windows Server, Apache и NGINX также отличаются друг от друга. Всё становится ещё сложнее, когда вы добавляете пользовательские конфигурации.

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

Как только клиент и сервер согласовывают используемый шифронабор, сервер отправляет клиенту свой SSL-сертификат.

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

Получив сертификат, клиент проверяет его на подлинность. Это чрезвычайно важный шаг. Чтобы соединение было безопасным, нужно не только зашифровать данные, нужно ещё убедиться, что они отправляются на правильный веб-сайт. Сертификаты SSL/TLS обеспечивают эту аутентификацию, а то, как они это делают, зависит от используемого шифронабора.

Все доверенные SSL-сертификаты выпускаются центром сертификации (ЦС). ЦС должен следовать строгим правилам выдачи и проверки сертификатов, чтобы ему доверяли. Вы можете считать ЦС кем-то вроде нотариуса — его подпись значит, что данные в сертификате реальны.

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

На этом этапе клиент косвенно проверяет, принадлежит ли серверу закрытый ключ, связанный с сертификатом.

В RSA, самой распространённой криптосистеме с открытым ключом, клиент с помощью открытого ключа шифрует случайные данные, которые будут использоваться для генерации сеансового ключа. Сервер сможет расшифровать и использовать эти данные, только если у него есть закрытый ключ, наличие которого обеспечивает подлинность стороны.

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

Обмен ключами

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

Сеансовые ключи являются «симметричными», то есть один и тот же ключ используется для шифрования и дешифрования.

Симметричное шифрование производительнее, чем асимметричное, что делает его более подходящим для отправки данных по HTTPS-соединению. Точный метод генерации ключа зависит от выбранного шифронабора, два самых распространённых из них — RSA и Диффи-Хеллман.

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

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

Вплоть до TLS 1.3 каждый раз, когда вы посещали сайт, рукопожатие происходило заново. Рукопожатие TLS 1.3 поддерживает 0-RTT или нулевое время возобновления приёма-передачи, что значительно увеличивает скорость для вернувшегося посетителя.

Пошаговый процесс рукопожатия в TLS 1.2

Рассмотрим TLS-рукопожатие с использованием RSA подробнее. Использование алгоритма Диффи-Хеллмана будет описано ниже.

1. Первое сообщение называется «Client Hello». В этом сообщении перечислены возможности клиента, чтобы сервер мог выбрать шифронабор, который будет использовать для связи. Также сообщение включает в себя большое случайно выбранное простое число, называемое «случайным числом клиента».
2. Сервер вежливо отвечает сообщением «Server Hello». Там он сообщает клиенту, какие параметры соединения были выбраны, и возвращает своё случайно выбранное простое число, называемое «случайным числом сервера». Если клиент и сервер не имеют общих шифронаборов, то соединение завершается неудачно.
3. В сообщении «Certificate» сервер отправляет клиенту свою цепочку SSL-сертификатов, включающую в себя листовой и промежуточные сертификаты. Получив их, клиент выполняет несколько проверок для верификации сертификата. Клиент также должен убедиться, что сервер обладает закрытым ключом сертификата, что происходит в процессе обмена/генерации ключей.
4. Это необязательное сообщение, необходимое только для определённых методов обмена ключами (например для алгоритма Диффи-Хеллмана), которые требуют от сервера дополнительные данные.
5. Сообщение «Server Hello Done» уведомляет клиента, что сервер закончил передачу данных.
6. Затем клиент участвует в создании сеансового ключа. Особенности этого шага зависят от метода обмена ключами, который был выбран в исходных сообщениях «Hello». Так как мы рассматриваем RSA, клиент сгенерирует случайную строку байтов, называемую секретом (pre-master secret), зашифрует её с помощью открытого ключа сервера и передаст обратно.
7. Сообщение «Change Cipher Spec» позволяет другой стороне узнать, что сеансовый ключ сгенерирован и можно переключиться на зашифрованное соединение.
8. Затем отправляется сообщение «Finished», означающее, что на стороне клиента рукопожатие завершено. С этого момента соединение защищено сессионным ключом. Сообщение содержит данные (MAC), с помощью которых можно убедиться, что рукопожатие не было подделано.
9. Теперь сервер расшифровывает pre-master secret и вычисляет сеансовый ключ. Затем отправляет сообщение «Change Cipher Spec», чтобы уведомить, что он переключается на зашифрованное соединение.
10. Сервер также отправляет сообщение «Finished», используя только что сгенерированный симметричный сеансовый ключ, и проверяет контрольную сумму для проверки целостности всего рукопожатия.

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

На этом этапе могут быть отправлены первые байты веб-приложения (данные, относящиеся к фактическому сервису, — HTML, Javascript и т. д.).

Пошаговый процесс рукопожатия в TLS 1.3

Рукопожатие TLS 1.3 значительно короче, чем его предшественник.

1. Как и в случае TLS 1.2, сообщение «Client Hello» запускает рукопожатие, но на этот раз оно содержит гораздо больше информации. TLS 1.3 сократил число поддерживаемых шифров с 37 до 5. Это значит, что клиент может угадать, какое соглашение о ключах или протокол обмена будет использоваться, поэтому в дополнение к сообщению отправляет свою часть общего ключа из предполагаемого протокола.
2. Сервер ответит сообщением «Server Hello». Как и в рукопожатии 1.2, на этом этапе отправляется сертификат. Если клиент правильно угадал протокол шифрования с присоединёнными данными и сервер на него согласился, последний отправляет свою часть общего ключа, вычисляет сеансовый ключ и завершает передачу сообщением «Server Finished».
3. Теперь, когда у клиента есть вся необходимая информация, он верифицирует SSL-сертификат и использует два общих ключа для вычисления своей копии сеансового ключа. Когда это сделано, он отправляет сообщение «Client Finished».

Издержки TLS-рукопожатия

Исторически одна из претензий к SSL/TLS заключалась в том, что он перегружал серверы дополнительными издержками. Это повлияло на ныне несуществующее представление, что HTTPS медленнее, чем HTTP.

Рукопожатия до TLS 1.2 требовали много ресурсов и в больших масштабах могли серьёзно нагрузить сервер. Даже рукопожатия TLS 1.2 могут замедлить работу, если их происходит много в один момент времени. Аутентификация, шифрование и дешифрование — дорогие процессы.

На небольших веб-сайтах это скорее всего не приведёт к заметному замедлению работы, но для корпоративных систем, куда ежедневно приходят сотни тысяч посетителей, это может стать большой проблемой. Каждая новая версия рукопожатия существенно облегчает процесс: TLS 1.2 совершает две фазы, а TLS 1.3 укладывается всего в одну и поддерживает 0-RTT.

Улучшения рукопожатия TLS 1.3 по сравнению с TLS 1.2

В приведённом выше объяснении рукопожатие разделено на десять отдельных этапов. В действительности же многие из этих вещей происходят одновременно, поэтому их часто объединяют в группы и называют фазами.

У рукопожатия TLS 1.2 можно выделить две фазы. Иногда могут потребоваться дополнительные, но когда речь идёт о количестве, по умолчанию подразумевается оптимальный сценарий.

В отличие от 1.2, рукопожатие TLS 1.3 укладывается в одну фазу, хотя вернее будет сказать в полторы, но это всё равно значительно быстрее, чем TLS 1.2.

Сокращение шифронаборов

Никто никогда не собирался использовать 37 наборов для шифрования данных, так эволюционировал протокол. Каждый раз, когда добавлялся новый алгоритм, добавлялись новые комбинации, и вскоре IANA администрировала 37 различных шифронаборов.

Это плохо по двум причинам:

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

IETF исключил в TLS 1.3 поддержку всех алгоритмов, кроме самых безопасных, убирая путаницу за счёт ограничения выбора. В частности, был убран выбор метода обмена ключами. Эфемерная схема Диффи-Хеллмана стала единственным способом, позволяющим клиенту отправить информацию о своём ключе вместе с «Client Hello» в первой части рукопожатия. Шифрование RSA было полностью удалено вместе со всеми другими схемами обмена статическими ключами.

При этом есть одна потенциальная ахиллесова пята в TLS 1.3.

Нулевое время возобновления приёма-передачи — 0-RTT

0-RTT — это то, к чему стремился весь технологический мир, и вот оно здесь с TLS 1.3. Как уже было упомянуто, рукопожатие TLS исторически было не быстрым, так что было важно ускорить его. 0-RTT делает это путём сохранения некоторой секретной информации о клиенте, обычно идентификатора сеанса или сеансовых тикетов, чтобы использовать их при следующем соединении.

Несмотря на все преимущества 0-RTT, он содержит пару потенциальных подводных камней. Режим делает клиентов восприимчивыми к атакам воспроизведения, когда злоумышленник, которому каким-то образом удаётся получить доступ к зашифрованному сеансу, может получить данные 0-RTT, включая первый запрос клиента, и снова отправить их на сервер.

Тем не менее, использовать эксплойт непросто. Вероятно, такой риск — небольшая цена за чрезвычайно полезную функцию.

Безопасность

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

В рукопожатии TLS 1.2 этапы согласования не были защищены, вместо этого использовалась простая MAC-функция, чтобы никто не вмешался в передачу. В этап согласования входят сообщения «Client Hello» и «Server Hello».

MAC-функция действует как индикатор, но не даёт никаких гарантий безопасности. Возможно, вы слышали об атаке, которая вынуждает стороны использовать менее безопасные протоколы и функции (downgrade attack). Если и сервер, и клиент поддерживают устаревшие шифронаборы — информацию об этом легко получить, прослушивая соединение, — злоумышленник может изменить шифрование, выбранное сервером, на более слабое. Такие атаки не опасны сами по себе, но открывают дверь для использования других известных эксплойтов тех шифронаборов, на которые был изменён выбранный изначально.

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

Теперь посмотрим, как эти обновления для рукопожатия TLS 1.3 будут реализованы во всех трёх основных функциях самого рукопожатия SSL/TLS.

Шифронаборы TLS-рукопожатия

Шифронабор — это набор алгоритмов, определяющих параметры безопасного соединения.

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

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

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

В приведённом выше примере используется эфемерная система Диффи-Хеллмана (DH) с эллиптической кривой для обмена ключами и алгоритм цифровой подписи эллиптической кривой для аутентификации. DH также может быть соединен с RSA (функционирующим как алгоритм цифровой подписи) для выполнения аутентификации.

Вот список наиболее широко поддерживаемых шифронаборов TLS 1.2:

Шифронаборы

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA;
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA;
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA;
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA;
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA;
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA;
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256.

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

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

Мы уже знаем, что будем использовать какую-то версию обмена эфемерными ключами Диффи-Хеллмана, но не знаем параметров, так что первые два алгоритма в шифронаборе TLS 1.2 больше не нужны. Эти функции всё ещё выполняются, их просто больше не нужно согласовывать во время рукопожатия.

Из приведённого выше примера видно, что используется AES (Advanced Encryption Standard) для шифрования большого объёма данных. Он работает в режиме счётчика Галуа с использованием 256-битных ключей.

Вот пять шифронаборов, которые поддерживаются в TLS 1.3:

• TLS_AES_256_GCM_SHA384;
• TLS_CHACHA20_POLY1305_SHA256;
• TLS_AES_128_GCM_SHA256;
• TLS_AES_128_CCM_8_SHA256;
• TLS_AES_128_CCM_SHA256.

Что изменилось в TLS 1.3 по сравнению с TLS 1.2?

Важно помнить, что при создании версии 1.3 главным было повышение безопасности и производительности. Для этого в TLS 1.3 был переработан алгоритм генерация ключей и исправлены известные уязвимости.

В рукопожатии TLS 1.3 также стали лучше некоторые процессы, например аутентификация сообщений и цифровые подписи.

Наконец, в дополнение к постепенному отказу от старых алгоритмов генерации ключей или обмена ими, TLS 1.3 устраняет старые симметричные шифры. В TLS 1.3 полностью исключили блочные шифры. Единственный разрешённый в TLS 1.3 тип симметричных шифров называется шифрованием с проверкой подлинности с использованием дополнительных данных (AEAD). Он объединяет шифрование и проверку подлинности сообщений (MAC) в одну функцию.

Аутентификация в TLS-рукопожатии

Исторически двумя основными вариантами обмена ключами являются RSA и Диффи-Хеллман (DH), в наши дни DH часто ассоциируется с эллиптическими кривыми (ECDH). Несмотря на некоторые основные сходства, между этими двумя подходами к обмену ключами есть фундаментальные различия.

Иными словами, TLS-рукопожатие RSA отличается от TLS-рукопожатия ECDH.

Краткая история RSA и DH/ECC

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

Диффи-Хеллмана иногда называют экспоненциальным обменом ключами, что указывает на возведение в степень (в дополнение к модульной арифметике), но на самом деле сам DH вообще ничего не шифрует и не дешифрует. Поэтому называть его «методом шифрования» вместо «математического обоснования» может быть немного неверно.

Небольшой экскурс в историю может пояснить этот момент.

Ещё в 1976 году Уитфилд Диффи и Мартин Хеллман создали протокол обмена ключами, основанный на работе Ральфа Меркля, чьё имя, по мнению обоих, должно также присутствовать в названии протокола.

Они пытались решить проблему безопасного обмена ключами по незащищённому каналу, даже если злоумышленник прослушивает его. У них получилось, но был один серьёзный недостаток: обмен ключами DH не включал в себя проверку подлинности, поэтому не было возможности проверить сторону на другом конце соединения.

Это можно считать рождением криптографии с открытым ключом и ИОК. Вскоре после того, как Диффи и Хеллман представили свой протокол обмена ключами, были завершены самые ранние версии криптосистемы RSA. Диффи и Хеллман создали концепцию шифрования с открытым ключом, но ещё не придумали саму функцию одностороннего шифрования.

Именно Рон Ривест (R в RSA) создал концепцию, которая в итоге стала криптосистемой RSA.

Во многих отношениях RSA является духовным преемником DH. Он осуществляет:

• генерацию ключей;
• обмен ключами;
• шифрование;
• дешифрование.

Таким образом, RSA является более функциональным алгоритмом, который может обрабатывать как обмен ключами, так и цифровые подписи, то есть производить аутентификацию в дополнение к безопасному обмену ключами. Поэтому у RSA ключи больше: должна быть обеспечена достаточная безопасность для цифровой подписи.

В то время как RSA осуществляет аутентификацию и обмен ключами, Диффи-Хеллман только облегчает обмен ключами. Существует четыре распространённых варианта семейства DH:

• Диффи-Хеллман (DH);
• эфемерный (краткосрочный) Диффи-Хеллман (DHE);
• эллиптическая кривая Диффи-Хеллмана (ECDH);
• эллиптическая кривая эфемерного Диффи-Хеллмана (ECDHE).

Опять же, Диффи-Хеллман сам по себе ничего не аутентифицирует. Его нужно использовать в паре с алгоритмом цифровой подписи. Так, например, если вы использовали ECDH или ECDHE, большинство шифронаборов будут сопряжены с алгоритмом цифровой подписи эллиптической кривой (ECDSA) или RSA.

Аутентификация в рукопожатии TLS 1.2

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

С другой стороны, если Диффи-Хеллман не выполняет аутентификацию, то что он делает? Как было сказано выше, DH часто используют совместно с криптографией на основе эллиптических кривых, чтобы обеспечить аутентификацию и обмен ключами.

Эллиптическая криптография (ECC) имеет гораздо меньшие размеры ключей, которые соответствуют эллиптической кривой, на которой они основаны. Для этого контекста есть пять подходящих кривых:

• 192 бит;
• 224 бита;
• 256 бит;
• 384 бит;
• 521 бит.

Но это не единственное различие между открытыми/закрытыми ключами ECC и ключами RSA. Они используются для двух совершенно разных целей во время рукопожатия TLS.

В RSA пара открытый/закрытый ключ используется как для проверки подлинности сервера, так и для обмена симметричным ключом сеанса. Фактически, именно успешное использование секретного ключа для расшифровки секрета (pre-master secret) аутентифицирует сервер.

С Диффи-Хеллманом пара открытый/закрытый ключ НЕ используется для обмена симметричным сеансовым ключом. Когда задействован Диффи-Хеллман, закрытый ключ фактически связан с прилагаемым алгоритмом подписи (ECDSA или RSA).

RSA-аутентификация

Процесс RSA-аутентификации связан с процессом обмена ключами. Точнее обмен ключами является частью процесса аутентификации.

Когда клиенту предоставляется SSL-сертификат сервера, он проверяет несколько показателей:

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

Если все эти проверки прошли, то проводится последний тест — клиент шифрует pre-master secret с помощью открытого ключа сервера и отправляет его. Любой сервер может попытаться выдать любой SSL/TLS-сертификат за свой. В конце концов, это общедоступные сертификаты. А так клиент может провести аутентификацию сервера, увидев закрытый ключ «в действии».

Таким образом, если сервер может расшифровать pre-master secret и использовать его для вычисления сессионного ключа, он получает доступ. Это подтверждает, что сервер является владельцем используемой пары из открытого и закрытого ключа.

DH-аутентификация

Когда используются Диффи-Хеллман и ECDSA/RSA, аутентификация и обмен ключами разворачиваются бок о бок. И это возвращает нас к ключам и вариантам их использования. Открытый/закрытый ключ RSA используется как для обмена ключами, так и для аутентификации. В DH + ECDSA/RSA асимметричная пара ключей используется только для этапа цифровой подписи или аутентификации.

Когда клиент получает сертификат, он всё ещё проводит стандартные проверки:

• проверяет подпись на сертификате,
• цепочку сертификатов,
• срок действия,
• статус отзыва.

Но владение закрытым ключом подтверждается по-другому. Во время обмена ключами TLS-рукопожатия (шаг 4) сервер использует свой закрытый ключ для шифрования случайного числа клиента и сервера, а также свой DH-параметр. Он действует как цифровая подпись сервера, и клиент может использовать связанный открытый ключ для проверки, что сервер является законным владельцем пары ключей.

Аутентификация в рукопожатии TLS 1.3

В TLS 1.3 аутентификация и цифровые подписи всё ещё играют важную роль, но они были исключены из шифронаборов для упрощения согласования. Они реализованы на стороне сервера и используют несколько алгоритмов, поддерживаемых сервером, из-за их безопасности и повсеместного распространения. В TLS 1.3 разрешены три основных алгоритма подписи:

• RSA (только подпись),
• алгоритм цифровой подписи эллиптической кривой (ECDSA),
• алгоритм цифровой подписи Эдвардса (EdDSA).

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

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

Клиент получает всю информацию, передающуюся с «Server Hello», и выполняет стандартную серию проверок подлинности сертификата SSL/TLS. Она включает в себя проверку подписи на сертификате, а затем проверку на соответствие подписи, которая была добавлена в хеш расшифровки.

Совпадение подтверждает, что сервер владеет секретным ключом.

Обмен ключами в TLS-рукопожатии

Если выделить главную мысль этого раздела, она будет звучать так:

RSA облегчает обмен ключами, позволяя клиенту шифровать общий секрет и отправлять его на сервер, где он используется для вычисления соответствующего сеансового ключа. Обмен ключами DH на самом деле вообще не требует обмена открытым ключом, скорее обе стороны создают ключ вместе.

Если сейчас это звучит немного абстрактно, к концу этого раздела всё должно проясниться.

Обмен ключами RSA

Называть это обменом ключами RSA на самом деле неправильно. На самом деле это RSA-шифрование. RSA использует асимметричное шифрование для создания ключа сеанса. В отличие от DH, пара открытого/закрытого ключей играет большую роль.

Вот как это происходит:

1. Клиент и сервер обмениваются двумя простыми числами (x и y), которые называют случайными числами.
2. Клиент генерирует pre-master secret (a), а затем использует открытый ключ сервера для его шифрования и отправки на сервер.
3. Сервер расшифровывает pre-master secret с помощью соответствующего закрытого ключа. Теперь обе стороны имеют все три входных переменных и смешивают их с некоторыми псевдослучайными функциями (PRF) для создания мастер-ключа.
4. Обе стороны смешивают мастер-ключ с ещё большим количеством PRF и получают совпадающие сеансовые ключи.

Обмен ключами DH

Вот как работает ECDH:

1. Клиент и сервер обмениваются двумя простыми числами (x и y), которые называют случайными числами.
2. Одна сторона выбирает секретный номер, называемый pre-master secret (a), и вычисляет: xa mod y. Затем отправляет результат (A) другому участнику.
3. Другая сторона делает то же самое, выбирая свой собственный pre-master secret (b) и вычисляет xb mod y, а затем отправляет обратно своё значение (B).
4. Обе стороны заканчивают эту часть, принимая заданные значения и повторяя операцию. Один вычисляет ba mod y, другой вычисляет ab mod y.

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

Рукопожатие TLS 1.2 для DH

Теперь, когда мы узнали, чем DH отличается от RSA, посмотрим, как выглядит рукопожатие TLS 1.2 на основе DH.

Опять же, между этими двумя подходами существует множество сходств. Мы будем использовать ECDHE для обмена ключами и ECDSA для аутентификации.

1. Как и в случае с RSA, клиент начинает с сообщения «Client Hello», которое включает в себя список шифронаборов, а также случайное число клиента.
2. Сервер отвечает своим сообщением «Server Hello», которое включает в себя выбранный шифронабор и случайное число сервера.
3. Сервер отправляет свой SSL-сертификат. Как и при TLS-рукопожатии RSA клиент выполнит серию проверок подлинности сертификата, но, поскольку сам DH не может аутентифицировать сервер, необходим дополнительный механизм.
4. Чтобы провести аутентификацию, сервер берёт случайные числа клиента и сервера, а также параметр DH, который будет использоваться для вычисления сеансового ключа, и шифрует их с помощью своего закрытого ключа. Результат будет выполнять роль цифровой подписи: клиент использует открытый ключ для проверки подписи и того, что сервер является законным владельцем пары ключей, и ответит своим собственным параметром DH.
5. Сервер завершает эту фазу сообщением «Server Hello Done».
6. В отличие от RSA, клиенту не нужно отправлять pre-master secret на сервер с использованием асимметричного шифрования, вместо этого клиент и сервер используют параметры DH, которыми они обменялись ранее, чтобы получить pre-master secret. Затем каждый использует pre-master secret, который он только что рассчитал, для получения одинакового сеансового ключа.
7. Клиент отправляет сообщение «Change Cipher Spec», чтобы сообщить другой стороне о своём переходе на шифрование.
8. Клиент отправляет финальное сообщение «Finished», чтобы сообщить, что он завершил свою часть рукопожатия.
9. Аналогично, сервер отправляет сообщение «Change Cipher Spec».
10. Рукопожатие завершается сообщением «Finished» от сервера.

Преимущества DHE перед RSA

Существует две основные причины, по которым сообщество криптографов предпочитает использовать DHE, а не RSA: совершенная прямая секретность и известные уязвимости.

Совершенная прямая секретность

Ранее вы, возможно, задавались вопросом, что означает слово «эфемерный» в конце DHE и ECDHE. Эфемерный буквально означает «недолговечный». И это может помочь понять совершенную прямую секретность (Perfect Forward Secrecy, PFS), которая является особенностью некоторых протоколов обмена ключами. PFS гарантирует, что сессионные ключи, которыми обмениваются стороны, не могут быть скомпрометированы, даже если скомпрометирован закрытый ключ сертификата. Другими словами, он защищает предыдущие сессии от извлечения и дешифрования. PFS получила высший приоритет после обнаружения ошибки Heartbleed. Это основной компонент TLS 1.3.

Уязвимость обмена ключами RSA

Существуют уязвимости, которые могут использовать заполнение (padding), используемое во время обмена ключами в старых версиях RSA (PKCS #1 1.5). Это один из аспектов шифрования. С RSA pre-master secret должен быть зашифрован открытым ключом и расшифрован закрытым ключом. Но когда этот меньший по длине pre-master secret помещается в больший открытый ключ, он должен быть дополнен. В большинстве случаев попытавшись угадать заполнение и отправив поддельный запрос на сервер, вы ошибётесь, и он распознает несоответствие и отфильтрует его. Но есть немалая вероятность, что вы сможете отправить на сервер достаточное количество запросов, чтобы угадать правильное заполнение. Тогда сервер отправит ошибочное законченное сообщение, что, в свою очередь, сузит возможное значение pre-master secret. Это позволит злоумышленнику рассчитать и скомпрометировать ключ.

Вот почему RSA был удалён в пользу DHE в TLS 1.3.

Обмен ключами в рукопожатии TLS 1.3

В рукопожатии TLS 1.3 из-за ограниченного выбора схем обмена ключами клиент может успешно угадать схему и отправить свою часть общего ключа во время начального этапа (Client Hello) рукопожатия.

RSA была не единственной схемой обмена ключами, которая была удалена в TLS 1.3. Неэфемерные схемы Диффи-Хеллмана тоже были ликвидированы, как и перечень недостаточно безопасных параметров Диффи-Хеллмана.

Что имеется в виду под недостаточно безопасными параметрами? Не углубляясь в математику, сложность Диффи-Хеллмана и большинства криптосистем с открытым ключом — это сложность решения задач дискретного логарифма. Криптосистема должна быть достаточно сложной для вычисления, если неизвестны входные параметры (случайные числа клиента и сервера), иначе вся схема окажется бесполезной. Схемы Диффи-Хеллмана, которые не могли обеспечить достаточно большие параметры, были исключены в TLS 1.3.

1. В начале рукопожатия TLS 1.3, зная, что будет использоваться DHE-схема соглашения о ключах, клиент включает свою часть общего ключа на основе предполагаемой схемы обмена ключами в своё сообщение «Client Hello».
2. Сервер получает эту информацию и, если клиент угадал, возвращает свою часть общего ключа в «Server Hello».
3. Клиент и сервер вычисляют сеансовый ключ.

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

Вместо заключения

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

По крайней мере, пока что-то не пойдёт не так, как нужно.

История TLS протокола и SSL сертификатов

Сертификаты TLS все еще известны как сертификаты SSL, но реальность такова, что всякий раз, когда кто-то покупает сертификат SSL, он фактически покупает последние сертификаты TLS с такими опциями, как шифрование RSA или DSA. Причина в том, что SSL является наиболее часто используемым термином, который стал более знакомым среди интернет-пользователей.

• Самая первая версия SSL так и не была выпущена из-за определенных проблем безопасности, возникающих во время конфиденциальных транзакций, таких как транзакции по кредитным картам, через Интернет. Позже в 1994 году Netscape внесла некоторые улучшения и выпустила вторую версию SSL, SSLv2 (устарела в 2011 году), которая преодолела предыдущие проблемы и обеспечила безопасность конфиденциальной информации. Таким образом, SSL стал стандартным протоколом для защиты веб-трафика на основе HTTP.
• 1995 — Netscape пошла еще дальше, чтобы сделать больше улучшений для усиления криптографических алгоритмов для решения проблем SSLv2. Поскольку SSLv2 использовал слабую структуру MAC, была выпущена обновленная версия под названием SSLv3. Это устранило проблему, связанную с SSLv2, а также предложило расширенные функции, такие как поддержка нескольких алгоритмов безопасности, которые ранее не поддерживались.
• 1999 — В форме обновления SSL 3.0 TLS 1.0 (безопасность транспортного уровня), написанная Кристофером Алленом и Тимом Дирксом, была определена в RFC 2246. Согласно RFC, «различия между этим протоколом и SSL 3.0 не являются существенными, но они достаточно важны, чтобы исключить возможность взаимодействия между TLS 1.0 и SSL 3.0 ».
• 2006 — TLS 1.1 был введен в RFC 4346
• 2008 — TLS 1.2 был введен в RFC 5246
• 2018 — Небезопасные технологии в предыдущих версиях были удалены и TLS 1.3, текущая версия была выпущена. TLS 1.3 предлагает лучшую конфиденциальность, чем его предшественники.

Шаги протокола рукопожатия SSL Handshake Protocol

1. ClientHello
   Это самый первый шаг. Клиент инициирует рукопожатие, отправляя сообщение «ClientHello», в котором рекомендуются параметры SSL, которые будут использоваться в течение всего сеанса SSL.
2. ServerHelloSSL Handshake Protocol
   Сервер отвечает клиенту сообщением «ServerHello», содержащим выбранные параметры SSL из предоставленного списка, которые будут использоваться во время сеанса SSL. Если клиент и сервер не смогут использовать общие параметры, соединение на этом этапе будет разорвано.
3. Certificate
   Сервер отправит Клиенту цепочку сертификатов SSL (свой и промежуточный сертификат). Затем Клиент начнет проверять, является ли сертификат легитимным, проверяя цифровую подпись сертификата и цепочку сертификатов и проверяя, есть ли потенциальные проблемы с данными сертификата, истек ли срок действия сертификата, неправильное имя домена, отозван ли сертификат и т. д.). Клиент также должен убедиться, что сервер обладает закрытым ключом сертификата, и весь этот процесс выполняется во время обмена / генерации ключей.
4. ServerKeyExchange
   Это необязательное сообщение, которое необходимо, когда определенные методы обмена ключами запрашивают у сервера дополнительные данные.
5. ServerHelloDone
   Это сообщение «ServerHelloDone» сообщает клиенту, что все сообщения были отправлены.
6. ClientKeyExchange
   Клиент отправляет информацию о ключе сеанса, который был зашифрован с использованием открытого ключа сервера.
7. ChangeCipherSpec
   Клиент предоставляет серверу инструкции, что он активирует все согласованные параметры SSL для всех будущих сообщений, которые он отправляет.
8. Finished
   Клиент поручает серверу проверить, были ли согласования SSL успешными или нет.
9. ChangeCipherSpec
   Сервер дает клиенту инструкции активировать все согласованные параметры SSL для будущих сообщений, которые он отправляет.
10. Finished
    Сервер инструктирует клиента проверить, успешно ли согласованы SSL.

Рукопожатие SSL завершено. Теперь обе стороны имеют сеансовый ключ и начнут взаимодействовать с зашифрованным и аутентифицированным соединением.

SSL Record Protocol

Протокол записи SSL отвечает за обработку шифрования всех сообщений. Этот протокол предлагает общий формат, используемый для кадрирования всех сообщений Handshake, Alerts, ChangeCiperSpec и Application Protocols. Другими словами, он обеспечивает базовую безопасность для других протоколов более высокого уровня, а именно протокола рукопожатия, протокола изменения шифра и протокола оповещения. Этот протокол состоит из обобщенных данных, типа сообщения, версии, длины и цифровой подписи, что делает его длиной 8 байтов.

SSL Alert Protocol

1. Предупреждение
2. Критическое положение
3. Фатальный прекращение процесса

Протокол спецификации шифра The ChangeCipher Spec Protocol

Протокол спецификации шифра изменений используется для сигнализации о переходах в стратегиях шифрования. Он содержит одно сообщение, которое содержит один байт значения 1. Цель этого протокола состоит в том, чтобы сжать и зашифровать это сообщение в состоянии соединения. Кроме того, сообщение этого протокола отправляется обеими сторонами серверу и клиенту для уведомления получателя о том, что последующие записи останутся защищенными в соответствии с недавно обмененными CipherSpec и ключами.

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

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

TLS 1.3 является самой последней и самой безопасной версией семейства протоколов SSL / TLS . TLS 1.3 приветствуется почти всеми экспертами по безопасности, поскольку это самый продвинутый протокол TLS на сегодняшний день. Это приносит некоторые существенные улучшения с точки зрения производительности и безопасности. Долгое время единственным * глупым * аргументом, который был сделан против SSL / TLS, является время, необходимое для установления соединения между клиентом и сервером. Теперь с TLS 1.3 этот бездумный аргумент перестанет существовать. Это из-за введения рукопожатий TLS 0-RTT (нулевого приема) и 1-RTT. TLS 1.3 сокращает поездку за одно рукопожатие, тем самым сокращая время рукопожатия вдвое. Это приводит к уменьшению TTFB — время до первого байта и увеличению задержки. Для доменов, где скорость соединения имеет первостепенное значение, это рукопожатие будет очень удобным. С TLS 1.3 потенциально уязвимые алгоритмы, шифры и протоколы больше не поддерживаются. Это дает огромный импульс безопасности, и это огромное разочарование для хакеров и мошенников.

 DV OV EV WC SAN PRO CodeSign Email PDF Wi-Fi IoT ALL Купить сертификат

Copyright © 1997-2024 adgrafics