Ytukyg

In an HTTPS connection, a client and a server exchange public keys and use these keys to encrypt their messages using an algorithm (e.g. RSA) (Asymmetric encryption). Interestingly, for HTTPS connections on web, after both sides assure they have a secure channel, they transmit a key for sending further messages encrypted by another algorithm (Symmetric encryption). Symmetric encryption is used because asymmetric encryption is computationally heavy. After they agree upon a single secret encryption key, the server and client can easily transmit messages (text, images, heavy video, etc).

Now, my questions are : How is the keypair(s) used for https connections managed? Does the OS manage them or is it the browsers? Where are they stored? Can one change them? Is a (new) keypair generated for every https connection that a client makes?

Logically, a single keypair will serve a client for lifetime. So each OS needs to have a bunch of keys of various lengths generated for each algorithm.

Specifically, I'm very curious about how it is done in android. I am trying to decide on how to manage https connections in my app, but I didn't find any libraries that allow me to use a specific keypair for the connection, and that made me thinking about all these stuff.

In an HTTPS connection, a client and a server exchange public keys and use these keys to encrypt their messages using an algorithm (e.g. RSA) (Asymmetric encryption)

This is not true. The key pairs are used to establish a pre-master secret, from which the symmetric keys are derived. This can be done by using key agreement (DH/DHE/ECDH/ECDHE ciphersuites) in TLS up to and including TLS 1.3. In earlier versions of the standard it is also possible to encrypt that secret - generated by the client - using RSA encryption, just using the key pair of the server.

Interestingly, for HTTPS connections on web, after both sides assure they have a secure channel, they transmit a key for sending further messages encrypted by another algorithm (Symmetric encryption).

No, the pre-master secret is used to generate the master secret, which is then used to derive the session keys using a key derivation function, generally called a PRF in TLS standards up to 1.3.

Symmetric encryption is used because asymmetric encryption is computationally heavy.

It also expands the ciphertexts by a much larger amount than asymmetric encryption. It is a misconception that it depends just on being computationally heavy. Otherwise this is correct.

After they agree upon a single secret encryption key, the server and client can easily transmit messages (text, images, heavy video, etc).

No. First of all the previous messages need to be authenticated. Otherwise an attacker could insert information to attack the scheme. Furthermore, two to four keys are used to encrypt the data frames. If a cipher with authentication is needed then one key is used to create messages in either direction. If a cipher without authentication is used then another key is needed for each direction to provide integrity and authenticity by calculating a MAC - commonly HMAC.

Now, my questions are : How is the keypair(s) used for https connections managed?

That depends on the key pair and the implementation.

Does the OS manage them or is it the browsers?

That depends as well. Firefox certainly manages it's own keys and certificates. However IE and Edge generally use SChannel, a TLS implementation within Windows that uses the Windows certificate / key store.

Where are they stored?

Ephemeral (temporary) key pairs are generally kept in memory. Static key pairs are generally kept in permanent storage or they may even be hardware protected.

Can one change them?

No, you can generate new ones, but if you change them then they will not be valid anymore.

Is a (new) keypair generated for every https connection that a client makes?

The E in DHE and ECDHE based ciphersuites means ephemeral. For the - sparsely used - DH and ECDH schemes one key pair is static and the other one is ephemeral. Otherwise key pairs are static and the answer is no. The public keys of static key pairs are generally within X.509 certificates. To use static key pairs it is important to establish trust in the public key.

Logically, a single keypair will serve a client for lifetime. So each OS needs to have a bunch of keys of various lengths generated for each algorithm.

That's complete and utter nonsense. A client will generally not even have a key pair. Certificates all have a validity period in which they need used. A client commonly doesn't even have a certificate. Keys need to be renewed. Ephemeral key pairs are generated on the fly.

Specifically, I'm very curious about how it is done in android. I am trying to decide on how to manage https connections in my app, but I didn't find any libraries that allow me to use a specific keypair for the connection, and that made me thinking about all these stuff.

You should not be thinking, because anything you wrote above is utterly wrong (well except for that single sentence, which is merely incomplete). You should be reading - for the TLS RFC's for starters. Thinking comes after you've established a sufficient base of knowledge.

If you have any interesting thoughts now: write them down, learn, and then check if they are worth keeping.