Как браузер генерирует симметричный ключ во время рукопожатия SSL - PullRequest
15 голосов
/ 14 октября 2010

У меня небольшая путаница при рукопожатии SSL между браузером и сервером в типичном веб-сценарии https:

До сих пор я понял, что в процессе рукопожатия SSL клиент (в данном случае браузер) шифрует случайно выбранный симметричный ключ с помощью открытого ключа (сертификат, полученный от сервера). Это отправляется обратно на сервер, сервер расшифровывает его (симметричный ключ) с помощью закрытого ключа. Этот симметричный ключ теперь используется во время оставшейся части сеанса для шифрования / дешифрования сообщений на обоих концах. Одна из основных причин для этого - более быстрое шифрование с использованием симметричных ключей.

Вопросы * * 1006 1) Как браузер выбирает и генерирует этот «случайно» выбранный симметричный ключ?

2) Имеют ли разработчики (и / или пользователи браузера) контроль над этим механизмом генерации симметричных ключей?

1 Ответ

12 голосов
/ 14 октября 2010

Здесь - очень хорошее описание того, как работает установление HTTPS-соединения. Я предоставлю краткую информацию о том, как сеансовый ключ получается обеими сторонами (клиентом и сервером), этот процесс известен как «протокол соглашения о ключе», вот как он работает:

  1. Клиент генерирует случайное значение 48-байтового «секрета перед мастером».
  2. Клиент дополняет эти байты случайными данными, чтобы ввод был равен 128 байтам.
  3. Клиент шифрует его с помощью открытого ключа сервера и отправляет его на сервер.
  4. Затем обе стороны производят мастер-ключ следующим образом:

    master_secret = PRF(
       pre_master_secret, 
       "master secret", 
       ClientHello.random + ServerHello.random
    )
    

PRF - это «псевдослучайная функция», которая также определена в Спец и довольно умный. Он сочетает в себе секрет, метку ASCII и начальные данные, которые мы даем с помощью ключевого хеш-сообщения Версии кода аутентификации (HMAC) хеша MD5 и SHA-1 функции. Половина входных данных отправляется каждой хэш-функции. Это умный, потому что он довольно устойчив к атакам даже перед лицом слабые места в MD5 и SHA-1. Этот процесс может оставить отзыв о себе и итерации навсегда, чтобы генерировать столько байтов, сколько нам нужно.

Следуя этой процедуре, мы получаем 48-байтовый «главный секрет».

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...