В предыдущей статье мы узнали, как рукопожатие TLS, наконец, обеспечивает аутентификацию сообщения. В сегодняшней статье мы расширим эту тему, рассмотрев следующую часть рукопожатия TLS.
Инфраструктура открытых ключей — довольно обширная тема, поэтому я представляю эти статьи в виде мини-серии. Начните с первой статьи и продолжайте, если хотите узнать, как работает PKI.
Часть 26 | Инфраструктура открытых ключей (PKI) — часть 5
К настоящему времени вы узнали, что онлайн-коммуникация защищена с помощью MAC и шифрования, как протокол установления ключей, называемый обменом ключами Диффи-Хеллмана, решает дилемму курицы и яйца, как правильные ключи получаются из общих секретов, как сертификаты дают гарантию идентификатор отправителя и то, как эти концепции объединяются рукопожатием TLS для запуска безопасного канала связи.
Вау, это точно было много.
Если предыдущий абзац не имел для вас никакого смысла, продолжайте и начните с части 1 этой серии.
TLS продолжился еще дальше
Продолжая с того места, где мы остановились в оставшееся время, давайте взглянем на наш график и посмотрим, что происходит теперь, когда у нас есть полностью защищенная связь.
13. Верно, мы подошли к шагу 13: Получить ключи приложения. Наше AE-шифрование работает, и мы убедились, что наши сообщения до сих пор не были подделаны. Теперь мы собираемся вычислить совершенно новый набор ключей для использования и отбросить те, которые мы использовали до сих пор.
Что вы имеете в виду, это безумие? Я говорил вам с самого начала, что мы использовали обмен ключами Диффи-Хеллмана на эллиптических кривых. Эти ключи эфемерны. Это означает, что мы выбрасываем их, когда закончим с ними!
Если это кажется излишним, то это потому, что так оно и есть. Ключи рукопожатия обеспечивают всю необходимую безопасность после добавления в смесь аутентификации сообщений, поэтому теоретически их можно использовать для остальной части вашего шифрования.
В любом случае, вместо этого мы решили разделить домены. Разные ключи используются для разных целей. Мы используем набор ключей для рукопожатия и набор ключей для шифрования приложения. В прошлом разделение доменов помогало смягчить незаметные атаки, поэтому, даже когда в настоящее время неизвестно ни одной атаки, мы превентивно разделяем проблемы и используем каждый набор ключей для своей конкретной цели на тот случай, если повторное использование ключей для двух целей может быть уязвимым. .
Также обратите внимание, как мы обеспечиваем так называемую прямую секретность, используя уникальные секреты DH для каждого сеанса TLS.
Идея прямой секретности заключается в том, что теоретически перехватчик может записывать весь сетевой трафик, который мы отправляем туда и обратно.
После приветственных сообщений клиента и сервера рукопожатие шифруется, поэтому перехватчик не может на самом деле определить, что передается. Несмотря на это, они могут каким-то образом украсть общий секрет в будущем, если секрет все еще существует. Это позволит им восстановить наши ключи шифрования и выяснить все записанные ими сообщения!
В прошлом ключи повторно использовались в сеансах. Это означало, что злоумышленники могли не только украсть закрытый ключ, поскольку он застрял, но и поскольку этот ключ повторно использовался во многих сеансах TLS, злоумышленник мог расшифровать множество сообщений между сервером и несколькими клиентами.
Для защиты от такого типа атак в TLS 1.3 мы делаем две вещи.
Во-первых, мы гарантируем, что наш общий секрет Диффи-Хеллмана, а также полученные из него ключи не могут быть легко украдены, потому что мы используем их только временно, а затем выбрасываем, когда с ними покончено.
Во-вторых, на случай, если они все равно раскроют секрет, мы также используем совершенно новый секрет с высокой частотой. Предпочтительно, для каждого сеанса с пользователем сервер генерирует уникальную пару ключей Диффи-Хеллмана, в результате чего получается уникальный секрет. Это делает менее привлекательной попытку сохранить зашифрованный трафик и расшифровать его позже, поскольку вам придется атаковать каждый сеанс TLS по отдельности.
На данный момент достаточно информации. Давайте закончим это рукопожатие.
Чтобы получить новые ключи, мы вычисляем новый хэш на основе всех наших сообщений и вводим его в наш HKDF вместе с секретом, который мы получили, когда использовали HKDF в первый раз. Клиент и сервер выполняют эти шаги, поэтому они получают одинаковые ключи. Эти ключи снова подходят для использования AES-GCM, для которого требуются 256-битные ключи в соответствии с выбранным нами набором шифров.
Обратите внимание, что хотя мы используем AES-GCM, алгоритм шифрования с симметричным ключом, мы по-прежнему используем ключ клиента и ключ сервера. Сервер будет использовать ключ сервера, а клиент будет использовать ключ клиента для шифрования сообщений. Хотя это не мешает общению. И клиент, и сервер имеют доступ к обоим ключам, поэтому они могут использовать ключ друг друга для расшифровки полученных сообщений.
Мы также получаем то, что называется значением инициализации. По сути, это запускает наш алгоритм шифрования.
14: Вы знаете нас. Всегда параноик. Итак, мы еще раз проверяем целостность данных с помощью еще одного раунда MAC-n-cheese.
15. Сервер соглашается, что это отличный MAC-n-cheese, так что мы готовы применить наши ключи.
16. Посмотрите на это! Клиент взял некоторые фактические данные приложения, зашифровал их с помощью ключа клиента и нашего алгоритма AE и связался с сервером. У нас есть полнофункциональное TLS-соединение.
Переходим к следующей части PKI. В следующей статье мы подробно рассмотрим те сертификаты TLS, о которых я вам говорил.
Ежедневный совет:
Делайте это шаг за шагом! Если содержание этой статьи кажется слишком подробным и техническим для ваших нужд, у вас, вероятно, еще нет причин разбираться в этом содержании. Возможно, вернитесь сюда, когда вы освоите функциональные аспекты TLS и захотите узнать больше.
Надеюсь, вам понравилось читать вместе! Есть время читать дальше? В части 6 мы рассмотрим цепочку доверия! чтобы узнать больше об PKI!
