Где происходит шифрование данных, и где находится ключ tls/ssl?

#безопасность #ssl #https #криптография #tls

Интересует вопрос безопасности https соединения.


Не могу понять, где именно происходит шифрование данных, когда запрашивается какой-нибудь
сайт по https? - В браузере, в операционной системе клиента или вообще на сервере? 
Каким образом передается ключ браузеру, чтобы расшифровать сообщение?  Просто в ответном
сообщении или как-то еще, его же могут перехватить? 
Знает ли браузер алгоритм шифрования? - это открытая информация? Если так, то почему
не используются закрытые алгоритмы (о которых никто не знает), или постоянно меняющиеся,
чтобы злоумышленнику было сложнее разгадать? 

    

Ответы

Ответ 1

Шифрование происходит с обеих сторон. Ведь если шифровать будет
только одна сторона (например только сервер), значит трафик от
другой стороны (от клиента) будет не зашифрован. Его можно будет
подслушать или даже изменить.
Формально никто не передает никому ключ. В протоколе TLS клиент и сервер должны сгенерировать
общий секрет (shared secret), набор из 48 байт. Потом клиент и сервер на основании
общего секрета вычисляют ключи: ключ шифрования клиента и ключ шифрования сервера.
Процедура вычисления ключей из общего секрета стандартная, и задана в описании протокола
TLS. Сервер и клиент знают 2 ключа шифрования, одним шифруют, вторым дешифруют. А теперь
самое интересное - как клиент и сервер вычисляют общий секрет. Это зависит от выбранного
набора шифров:


TLS_RSA_WITH_: В данном случае клиент сам создает общий секрет генерируя 48 случайных
байт. Затем он шифрует их при помощи публичного RSA ключа, который находится в сертификате
сервера. Сервер получает зашифрованные данные, и расшифровывает их при помощи приватного
RSA ключа. Данная схема используется редко.
TLS_DHE_RSA_/TLS_ECDHE_RSA_/TLS_ECDHE_ECDSA_: Здесь используется криптографическая
схема Диффи-Хеллмана (DHE) или ее версия на эллиптических кривих (ECDHE). Суть схемы
такая: сервер и клиент генерируют случайные большие числа (приватные ключи), вычисляют
на их основе другие числа (публичные ключи), и пересылают друг другу. Имея свой приватный
ключ и публичный ключ другой стороны, они вычисляют общий секрет. Третья сторона, которая
прослушивает канал, видит только 2 публичных ключа, и она не может вычислить общий
секрет. После этого все данные, которыми обменивались клиент и сервер для получение
этого ключа подписываются сертификатом сервера (RSA или ECDSA подписи). Если клиент
доверяет сертификату сервера, он проверяет эту подпись, и если она правильная, начинается
уже обмен данными. Это наиболее часто используемая схема.
Есть еще несколько схем, но они используются очень редко или не используются вообще.


Про перехват. Как я выше описал, перехватывать сообщения здесь бесполезно, так как
в первом случае его может расшифровать только сервер, а во втором используется хитрая
криптографическая схема.
Алгоритмы шифрования знает и сервер, и клиент. Ведь если клиент не знает, какой алгоритм
шифрования, как он будет шифровать данные для отправки? В современной криптографии
никто не использует закрытые алгоритмы. Открытые алгоритмы постоянно изучаются лучшими
криптографами мира, ищутся уязвимости, и предлагаются решения для их обхода.

В TLS мы условно можем сказать, что алгоритмы меняются, так как каждый раз генерируются
другие ключи шифрования. А потом, если вы хотите использовать закрытый алгоритм, например
для просмотра веб-страницы, каким образом этот алгоритм может быть закрытый, если ваш
компьютер/устройство производит шифрование/дешифрование?


Я упустил/упростил некоторые детали, что бы описать только основные идеи.


Ответ 2

Работает это так:


У сервера и у клиента имеются т.н. сертификаты. Грубо говоря - сертификаты это набор:
публичный ключ (PubKey)+секретный ключ (PrivKey)
В момент установления соединения происходит т.н. handshake-рукопожатие, опять же
грубо говоря в этот момент клиент и сервер обмениваются информацией какие у них сертификаты
и какие алгоритмы шифрования они поддерживают и могут ли они доверять сертификатам
противной стороны. Handshake проходит успешно, если клиент и сервер имеют корневые
сертификаты, которые доверяют сертификатам респондентов.
Если handshake проходит успешно они обмениваются публичными ключами и на их основе
вычисляют сессионный ключ, который вычисляется как sessionKey=sharedKey(PubKeyClient,
PrivKeyServer)==sharedKey(PubKeyServer, PrivKeyClient) - здесь фигурирует функция sharedKey()
- это некий мат.алгоритм, который вычисляет сессионный ключ на основе публичного ключа
респондента и секретного ключа получателя, причем он тождественно равен сессионному
ключу полученному в результате вычисления на основе публичного ключа получателя и приватного
ключа респондента - собственно на этом вся эта математика и строится - иначе ничего
не взлетит
После этапа 3. обе партии имеют одинаковый ключ, который используется для симметричного
шифрования выбранным алгоритмом, который устанавливается во время handshake
Далее каждая сторона шифрует свои запросы сессионным ключом, принимающая сторона
дешифрует его и вуаля.


В реале все намного сложнее - можете почитать хотя бы Википедии

Update


  его же могут перехватить


Посколько сервер и клиент обмениваются только публичными ключами, то атакующий может
перехватить только публичные ключи, знание публичного ключа без знания секретного ключа
бесполезно.


  Знает ли браузер алгоритм шифрования? - это открытая информация?


Да, это открытая информация. В криптографии защита на основе незнания алгоритма шифрования
не считается надежной защитой. Скорее даже наоборот, знание алгоритма - это наоборот
способ защиты - как некая гарантия надежности алгоритма. Существует определенная процедура
как бы сертификации алгоритмов, которая и подтверждает его надежность - то есть устойчивость
к разнообразным атакам. В случае SSL/TLS для обмена ключами используются RSA и DH,
а для обмена в пределах сессии используются симметричные алгоритмы IDEA и AES.