Зачем в TLS два вида шифрования, если асимметричное и так работает

Асимметричное шифрование решает главную проблему — как договориться о секрете по открытому каналу, не имея общего ключа заранее. Но RSA или обмен по эллиптическим кривым (ECDHE) в разы медленнее симметричного AES. Гонять им весь трафик сессии — не вариант под нагрузкой.

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

Упрощённо для TLS 1.3: клиент отправляет свои параметры ключевого обмена (ключевой share на эллиптической кривой), сервер отвечает своим share, сертификатом и подписью. Обе стороны независимо вычисляют один и тот же общий секрет через ECDHE, из него выводят ключи сессии — и дальше шифруют AES-GCM.

// На уровне приложения это скрыто, // но именно отсюда растёт разница // в задержке между http и https SSLContext ctx = SSLContext.getInstance("TLSv1.3");

Спросят: сколько round-trip'ов занимает хендшейк в TLS 1.2 против TLS 1.3. В 1.2 — два RTT до первого прикладного байта, в 1.3 — один RTT, а при session resumption (0-RTT) можно отправить данные вместе с первым сообщением клиента, но с риском replay-атаки на эти данные.

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

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки