HTTPS-соединения - как управляются пары ключей

В 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. Чтобы использовать пары статических ключей, важно установить доверие к открытому ключу.

Логически, одна пара ключей будет служить клиенту на всю жизнь. Таким образом, каждая ОС должна иметь набор ключей различной длины, сгенерированных для каждого алгоритма.

Это полная и полная ерунда. У клиента обычно даже не будет пары ключей. Все сертификаты имеют срок действия, в котором они должны использоваться. У клиента обычно даже нет сертификата. Ключи необходимо обновить. Эфемерные пары ключей генерируются на лету.

В частности, мне очень любопытно, как это делается в Android. Я пытаюсь решить, как управлять соединениями https в моем приложении, но я не нашел библиотек, которые позволили бы мне использовать определенную пару ключей для соединения, и это заставило меня задуматься обо всех этих вещах.

Вы не должны думать, потому что все, что вы написали выше, совершенно неправильно (хорошо, за исключением того единственного предложения, которое является просто неполным). Вы должны читать - для TLS RFC для начинающих. Мышление приходит после того, как вы создали достаточную базу знаний.

Если у вас есть интересные мысли сейчас: запишите их, изучите, а затем проверьте, стоит ли их хранить.