В HTTPS-соединении клиент и сервер обмениваются открытыми ключами и используют эти ключи для шифрования своих сообщений с использованием алгоритма (например, RSA) (асимметричное шифрование)
Это неправда.Пары ключей используются для установления предварительного секрета, из которого получены симметричные ключи.Это может быть сделано с помощью согласования ключей (шифры DH / DHE / ECDH / ECDHE) в TLS до TLS 1.3 включительно.В более ранних версиях стандарта также возможно шифровать этот секрет - сгенерированный клиентом - с использованием шифрования RSA, просто используя пару ключей сервера.
Интересно, что для соединений HTTPS в Интернете,после того, как обе стороны заверяют, что у них есть безопасный канал, они передают ключ для отправки дальнейших сообщений, зашифрованных другим алгоритмом (Симметричное шифрование).
Нет, предварительный главный секрет используется для генерации главного секрета, который затем используется для получения сеансовых ключей с использованием функции вывода ключа, обычно называемой PRF в стандартах TLS, вплоть до 1,3.
Симметричное шифрование используется, поскольку асимметричное шифрование является сложным в вычислительном отношении.
Он также расширяет шифротексты на гораздо большую величину, чем асимметричное шифрование.Это ошибочное мнение, что всего лишь зависит от вычислительной нагрузки.В противном случае это правильно.
После того, как они договорились об одном секретном ключе шифрования, сервер и клиент могут легко передавать сообщения (текст, изображения, тяжелое видео и т. Д.).
Нет.Прежде всего предыдущие сообщения должны быть аутентифицированы.В противном случае злоумышленник может вставить информацию для атаки на схему.Кроме того, два-четыре ключа используются для шифрования кадров данных.Если необходим шифр с аутентификацией, то один ключ используется для создания сообщений в любом направлении.Если используется шифр без аутентификации, то для каждого направления требуется другой ключ, чтобы обеспечить целостность и аутентичность путем вычисления MAC - обычно HMAC.
Теперь мои вопросы: Какова пара ключей?используется для соединений https управляемых?
Это зависит от пары ключей и реализации.
Управляет ли их ОС или это браузеры?
Это зависиттакже.Firefox, безусловно, управляет своими собственными ключами и сертификатами.Однако IE и Edge обычно используют SChannel, реализацию TLS в Windows, которая использует хранилище сертификатов / ключей Windows.
Где они хранятся?
Эфемерный (временный) ключпары обычно хранятся в памяти.Пары статических ключей обычно хранятся в постоянном хранилище или даже могут быть защищены аппаратным обеспечением.
Можно ли их поменять?
Нет, вы можете сгенерировать новые, но еслиесли вы измените их, они больше не будут действительными.
Генерируется ли (новая) пара ключей для каждого https-соединения, которое устанавливает клиент?
E в DHE иШифруиты на основе ECDHE означают эфемерные.Для - редко используемых схем DH и ECDH одна пара ключей является статической, а другая - эфемерной.В противном случае пары ключей являются статическими, и ответ - нет.Открытые ключи пар статических ключей обычно находятся в пределах сертификатов X.509 .Чтобы использовать статические пары ключей, важно установить trust в открытом ключе.
Логически, одна пара ключей будет служить клиенту на всю жизнь.Таким образом, каждая ОС должна иметь набор ключей различной длины, сгенерированных для каждого алгоритма.
Это полная и полная чушь.У клиента обычно даже не будет пары ключей.Все сертификаты имеют срок действия, в котором они должны использоваться.У клиента обычно даже нет сертификата.Ключи необходимо обновить.Эфемерные пары ключей генерируются на лету.
В частности, мне очень любопытно, как это делается в Android.Я пытаюсь решить, как управлять соединениями https в моем приложении, но я не нашел библиотек, которые позволили бы мне использовать определенную пару ключей для соединения, и это заставило меня задуматься обо всех этих вещах.
Вы не должны думать, потому что все, что вы написали выше, совершенно неправильно (хорошо, за исключением того единственного предложения, которое является просто неполным).Вы должны читать - для TLS RFC для начинающих.Мышление приходит после того, как вы создали достаточную базу знаний.
Если у вас есть какие-то интересные мысли сейчас: запишите их, изучите, а затем проверьте, стоит ли их хранить.