Как работает HTTPS

Прежде всего есть два протокола:

1. HTTP (без S) — это протокол для обмена данными, который чаще всего используется между веб-браузером и веб-сайтом.

2. HTTPS — это защищённая версия этого протокола.

Почему HTTPS защищённый? Благодаря шифрованию.

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

Без этого атаки типа «человек посередине» (MITM) могли бы перехватить ваш трафик и прочитать конфиденциальные данные, такие как пароли, данные кредитных карт и т. д.

Протокол, используемый для шифрования данных в HTTPS, — это TLS (Transport Layer Security):

HTTPS = HTTP + TLS

HTTPS использует асимметричное шифрование для шифрования данных. У вас есть:

* ? один закрытый ключ — секретный ключ SSL-сертификата веб-сайта, который никому не передаётся;

* ? один открытый ключ — открытый ключ сертификата, который передаётся всем, кто хочет взаимодействовать с веб-сайтом.

Асимметричное шифрование просто означает, что информация, зашифрованная открытым ключом, может быть расшифрована только закрытым ключом.

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

На самом деле HTTPS использует оба типа!

Асимметричное шифрование используется для проверки сервера и безопасного создания ключа сеанса. Ключ сеанса будет использоваться для симметричного шифрования.

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

Самое интересное, что этот ключ детерминированно генерируется локально как клиентом, так и сервером независимо — он никогда не передаётся по сети.

Итак, какие шаги выполняются?

1. Клиент (браузер) подключается к серверу (веб-странице).

2. Сервер отправляет свой SSL-сертификат (включающий открытый ключ).

3. Клиент и сервер выполняют TLS-рукопожатие и генерируют ключ сеанса для шифрования/дешифрования будущих HTTP-данных.

4. Всё как обычно.

Подробности находятся в TLS-рукопожатии, и это, честно говоря, самая интересная часть работы HTTPS.

TLS-рукопожатие служит трём целям:

* ? проверка подлинности сервера;

* ? генерация ключей сеанса для шифрования во время этого сеанса;

* ? выбор версии TLS и наборов шифров, которые будут использоваться.

Пошагово (используя алгоритм TLS 1.2 RSA, потому что он проще):

1. Client Hello Request: клиент инициирует рукопожатие с сообщением, включающим версию TLS и поддерживаемые шифры, а также строку случайных байтов (называемую client random).

2. Server Hello Response: сервер выбирает набор шифров и генерирует свою строку случайных байтов (server random). Он отвечает с набором шифров, своим SSL-сертификатом и server random.

3. Client Verification: клиент проверяет сертификат через доверенный центр сертификации, который его выдал. SSL-сертификат имеет цифровую подпись, которая подписана закрытым ключом CA, поэтому клиент использует открытый ключ CA для её расшифровки.

После этого шага клиент проверил, что сертификат является легитимным и подтверждён через CA — не поддельным.

Примечание: он всё ещё не знает наверняка, действительно ли сервер владеет этим сертификатом (т. е. имеет закрытый ключ).

Кто определяет, какому центру сертификации можно доверять?

Компания, создавшая ваш браузер! Apple, Microsoft, Google, Mozilla и другие поддерживают свой список центров сертификации. Ваш браузер/ОС поставляется с этим списком доверенных центров сертификации.

Всё основано на доверии, так что лучше им доверять...

Продолжаем:

4. Client Key Exchange: клиент создаёт случайную строку байтов, называемую «premaster secret». Он шифрует её с помощью открытого ключа сервера, полученного из SSL-сертификата, и отправляет. Поскольку для шифрования используется алгоритм асимметричного шифрования, клиент знает, что сервер может получить секрет только если расшифрует его с помощью закрытого ключа (что подтверждает владение сертификатом).

5. Session Key Generation: сервер расшифровывает premaster secret с помощью закрытого ключа SSL-сертификата. Клиент и сервер независимо генерируют ключи сеанса локально, используя комбинацию client random, server random и premaster secret.

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

Если это не так, последующее шифрование/дешифрование данных при записи не будет соответствовать протоколу HTTP/HTTPS и завершится ошибкой.

Шаг 5 косвенно подтверждает клиенту, что сервер владеет предоставленным им SSL-сертификатом (а не просто делает вид, что он у него есть).

После этого сеансовый ключ может использоваться для симметричного шифрования/дешифрования HTTP-данных.

Источник: vk.com

Комментарии: