Как работает 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 и другие поддерживают свой список центров сертификации. Ваш браузер/ОС поставляется с этим списком доверенных центров сертификации.

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

Продолжаем: