Что HTTPS добавляет к HTTP

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

Рукопожатие и есть эти переговоры, и происходит оно до первого запроса. Клиент открывает TCP-соединение, затем посылает ClientHello со случайным числом, списком поддерживаемых шифров и своим открытым ключом. Сервер отвечает своим случайным числом, выбранным шифром и своим открытым ключом. Дальше обе стороны выводят одни и те же сессионные ключи из своего секретного значения и чужого открытого, и никто, слушающий разговор, этот расчёт повторить не может. В конце обе стороны посылают сообщение Finished — хеш всего сказанного ранее, поэтому любая правка во время рукопожатия ломает проверку сразу.

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

Chain
  1  leaf        CN=example.org
                 SAN: example.org, www.example.org
                 valid 2026-01-01 .. 2026-04-01
  2  intern     CN=R3 Intermediate CA
  3  root        CN=ISRG Root X1  (already on the device)

Validation
  signature of 1  checked with public key of 2    ok
  signature of 2  checked with public key of 3    ok
  signature of 3  checked with public key on device  ok
  name in SAN matches the host that was requested   ok
  current time inside the validity window           okЦепочка сертификатов и пять проверок, которые делает клиент.

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

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

$ curl -v https://example.org
*  SSL certificate problem: self-signed certificate in certificate chain
*  Closing connection

$ curl -vk https://example.org
*  Server certificate: CN=mitm-proxy.local
*  subjectAltName does not match example.org
<  HTTP/1.1 200 OKОдин и тот же запрос с проверкой сертификата и без неё.

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