The underlying protocols used for HTTPS are SSL3, TLS1.0, TLS1.1, TLS1.2, etc. Each of these have a different way of exchanging keys, so there is not a one-size fits all answer to this question.

In symmetric encryption, the message is encrypted and decrypted using the same key. In asymmetric encryption, the message is encrypted using the public key, and the private key is used to decrypt the message.

But, in practice, a sender typically does not use the recipient's public key to encrypt a message (using asymmetric encryption) directly, because this takes a lot of computational resources. Instead, the sender generates a symmetric key on the fly, then this symmetric key is used to encrypt the message (using symmetric encryption). Then, the symmetric key is encrypted using the recipient's public key (using asymmetric encryption) and this encrypted symmetric key is sent to the recipient along with the encrypted message. On the receiving end, the recipient decrypts the encrypted key using his private key, then uses this key to decrypt the message.

See http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html for an excellent walkthrough of how all of this works in TLS1.0. Even though this was written in 2009 and TLS1.0 has long been outdated at this point, you'll probably find this blog post to be very instructive if you're trying to get your head around these concepts for the first time. Once you're comfortable with this, have a look at https://tlseminar.github.io/first-few-milliseconds/, which is based on TLS1.2 (which uses a whole different method of key exchange, based on elliptical curves).

The underlying protocols used for HTTPS are SSL3, TLS1.0, TLS1.1, TLS1.2, etc. Each of these have a different way of exchanging keys, so there is not a one-size fits all answer to this question.

However, in symmetric encryption, the message is encrypted and decrypted using the same key. In asymmetric encryption, the message is encrypted using the public key, and the private key is used to decrypt the message.

But, in practice, a sender typically does not use the recipient's public key to encrypt a message (using asymmetric encryption) directly, because this takes a lot of computational resources. Instead, the sender generates a symmetric key on the fly, then this symmetric key is used to encrypt the message (using symmetric encryption). Then, the symmetric key is encrypted using the recipient's public key (using asymmetric encryption) and this encrypted symmetric key is sent to the recipient along with the encrypted message. On the receiving end, the recipient decrypts the encrypted key using his private key, then uses this key to decrypt the message.

See http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html for an excellent walkthrough of how all of this works in TLS1.0. Even though this was written in 2009 and TLS1.0 has long been outdated at this point, you'll probably find this blog post to be very instructive if you're trying to get your head around these concepts for the first time. Once you're comfortable with this, have a look at https://tlseminar.github.io/first-few-milliseconds/, which is based on TLS1.2 (which uses a whole different method of key exchange, based on elliptical curves).

The underlying protocols used for HTTPS are SSL3, TLS1.0, TLS1.1, TLS1.2, etc. Each of these have a different way of exchanging keys, so there is not a one-size fits all answer to this question.

But, generally speaking, a sender typically does not use the recipient's public key to encrypt a message (using asymmetric encryption) directly, because this takes a lot of computational resources. Instead, the sender generates a symmetric key on the fly, then this symmetric key is used to encrypt the message (using symmetric encryption). Then, the symmetric key is encrypted using the recipient's public key (using asymmetric encryption) and this encrypted symmetric key is sent to the recipient along with the encrypted message. On the receiving end, the recipient decrypts the encrypted key using his private key, then uses this key to decrypt the message.

See http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html for an excellent walkthrough of how all of this works in TLS1.0. Even though this was written in 2009 and TLS1.0 has long been outdated at this point, you'll probably find this blog post to be very instructive if you're trying to get your head around these concepts for the first time. Once you're comfortable with this, have a look at https://tlseminar.github.io/first-few-milliseconds/, which is based on TLS1.2 (which uses a whole different method of key exchange, based on elliptical curves).

The underlying protocols used for HTTPS are SSL3, TLS1.0, TLS1.1, TLS1.2, etc. Each of these have a different way of exchanging keys, so there is not a one-size fits all answer to this question.

In symmetric encryption, the message is encrypted and decrypted using the same key. In asymmetric encryption, the message is encrypted using the public key, and the private key is used to decrypt the message.

But, in practice, a sender typically does not use the recipient's public key to encrypt a message (using asymmetric encryption) directly, because this takes a lot of computational resources. Instead, the sender generates a symmetric key on the fly, then this symmetric key is used to encrypt the message (using symmetric encryption). Then, the symmetric key is encrypted using the recipient's public key (using asymmetric encryption) and this encrypted symmetric key is sent to the recipient along with the encrypted message. On the receiving end, the recipient decrypts the encrypted key using his private key, then uses this key to decrypt the message.

See http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html for an excellent walkthrough of how all of this works in TLS1.0. Even though this was written in 2009 and TLS1.0 has long been outdated at this point, you'll probably find this blog post to be very instructive if you're trying to get your head around these concepts for the first time. Once you're comfortable with this, have a look at https://tlseminar.github.io/first-few-milliseconds/, which is based on TLS1.2 (which uses a whole different method of key exchange, based on elliptical curves).