|
|
@@ -0,0 +1,27 @@
|
|
|
+Как происходит установка соединения по HTTPS между клиентом (браузером) и сервером.
|
|
|
+
|
|
|
+Браузер шлёт запрос на сервер `course.to.digital` — о, говорит, дружок, давай-ка мы с тобой установим безопасное соединение, а то кругом враги, надо бы предостеречься. И вот тебе на всякий случай рандомная строка, например, 123.
|
|
|
+
|
|
|
+Сервер отвечает — ну конечно, давай, вот на тебе лови мой сертификат, в нём есть публичный ключ и подпись Let’s Encrypt, и заодно на тоже тебе рандомную строку, например, 567.
|
|
|
+
|
|
|
+В процессе настройки HTTPS на сервере сохраняется публичный и приватный ключ, приватный не передаётся никуда и хранится только на сервере, публичный (исходя из названия) передаётся собеседникам (браузерам). Публичным ключом можно зашифровать сообщение, а расшифровать такое сообщение можно только имея соответствующий этому публичному ключу приватный ключ.
|
|
|
+
|
|
|
+И вот, значит, сервер передаёт сертификат с публичным ключом браузеру.
|
|
|
+
|
|
|
+Браузер через удостоверяющий центр (через Letsencrypt в твоём примере) проверяет, что переданный публичный ключ действительно относится к домену `course.to.digital`. Если это не проверить, то хакер сможет перехватить коммуникацию на этом этапе и передать вместо реального публичного ключа `course.to.digital` свой хакерский ключ и затем спалить (прочесть) всю дальнейшую коммуникацию. А так удостоверяющий центр (которому все доверяют) подтверждает, что да, всё чики-пуки, публичный ключ правильный, принадлежащий домену `course.to.digital`.
|
|
|
+
|
|
|
+Браузер генерирует ещё одну рандомную строку, например, 890 и шифрует её публичным ключом сервера, и передаёт серверу.
|
|
|
+
|
|
|
+Сервер расшифровывает своим приватным ключом рандомную строку от браузера (получает 890). На этом этапе:
|
|
|
+
|
|
|
+а) сервер знает изначальную рандомную строку 123 от браузера
|
|
|
+
|
|
|
+б) сервер знает свою рандомную строку 567
|
|
|
+
|
|
|
+в) знает только что пришедшую зашифрованную рандомную строку 890.
|
|
|
+
|
|
|
+И браузер тоже знает все эти 3 строки. Сервер и браузер использует эти 3 строки, чтобы сгенерировать **одинаковый** сеансовый ключ.
|
|
|
+
|
|
|
+Дальше все сообщения между клиентом и сервером шифруются одинаковым сеансовым ключом. При этом сам это ключ никогда по сети не передавался (он был рассчитан и сервером, и браузером). Хакер не может вычислить этот ключ, потому что он не может получить строку 890. не зная приватный ключ сервера (при том, что он мог перехватить строки 123 и 567).
|
|
|
+
|
|
|
+В новой версии TLS (1.3) схема обмена несколько иная, но принцип тот же — ассиметричное шифрование используется для безопасного получения симметричного ключа и использование симметричного ключа дальше для шифрования трафика.
|
