My understanding is that, when you connect to an HTTPS website, the communication is encrypted via asymmetric encryption, therefore private and public keys play a role there. My assumption there is that I, the user, own the private key.

My understanding is also that each computer (let's just assume Windows) has at least one private key stored in its hard disk.

If my private key gets stolen, what can the ill-intentioned person do? They can communicate with websites as if they were me - but they cannot access my data or my accounts, as they would also need my credentials for that.

So the "only" risk I see, is if I open a session, log in, and then the attacker gets in between and "continues" my session without the other party knowing.

What am I missing? I have the feeling that getting your private key stolen is much worse than this.

  • 1
    @Tripola Thanks for clarifying your question. It seems that you are under the impression that with HTTPS, both the client and the server have a long-term private key. Generally, this is not the case. In most cases, the server has a long-term private key that corresponds with the public key in the server's certificate.
    – mti2935
    Aug 27, 2023 at 13:30
  • But, the same is not true for the client - the client generally does not have a long-term private key, or public key, or certificate. The exception to this are sites that support client authentication using client certificates (by way of mTLS), but this is relatively uncommon. See security.stackexchange.com/questions/110621/… for more info on this.
    – mti2935
    Aug 27, 2023 at 13:32
  • To be clear, the client does have a short-term (ephemeral) private key that it uses for asymmetric encryption to create the TLS tunnel with the server. But, this is a short-lived private key, which only lives for the duration of the TLS session. See moserware.com/2009/06/first-few-milliseconds-of-https.html for how this works in TLS1.0 (newer versions of TLS are slightly more complicated, but the same concept apples wrt the client ephemeral private key).
    – mti2935
    Aug 27, 2023 at 13:55
  • @mti2935 ahh ok thanks for correcting my understanding! So the actual risk would actually be that someone has the private key of a server, and then you communicate with someone else and not with the real server. But then why did I read that every computer has a private key stored in a file? What is this private key for?
    – Tripola
    Aug 27, 2023 at 16:45
  • @Tripola Glad that helped. Yes, if a server's private key is stolen, that's very bad news, as this would enable an attacker to impersonate and/or MITM the server. See security.stackexchange.com/questions/105376/… and security.stackexchange.com/questions/105485/… for some interesting reading on this subject. WRT 'I read that every computer has a private key stored in a file' - can you please reference where you are seeing this?
    – mti2935
    Aug 27, 2023 at 16:59

1 Answer 1


You have a few misunderstandings.

when you connect to an HTTPS website, the communication is encrypted via asymmetric encryption

This is false. The communication is encrypted using symmetric encryption (typically AES or a Salsa20 derivative), which is orders of magnitude faster than asymmetric encryption and supports bidirectional secure communication without needing both sides to have a private key. The symmetric encryption key is derived from randomly-generated data for each new connection, and is ephemeral (forgotten after the connection ends).

Exchanging the symmetric encryption key - the process of ensuring that both the client and the server have the same symmetric key but an eavesdropper does not - can be done using asymmetric encryption. This is how RSA-based key exchange works, and only requires that one party (in practice, the server) have a public/private key pair. However, most modern TLS connections don't use asymmetric encryption (per se) at all, opting instead for an ephemeral key exchange algorithm, usually elliptic curve Diffie-Hellman (abbreviated ECDHE). DH-based key exchanges do involve public and private parameters, but nothing is encrypted or decrypted with them, and to make the key exchange secure the server's public parameter is signed (not encrypted; the mathematical operation is the same in RSA but not in some other signature algorithms and the purpose, concept, and security are totally different) using its private key.

Once the TLS "handshake" (which includes the key exchange) is completed and actual message traffic (encrypted using a symmetric cipher) starts flowing, generally private and public keys are not used again for the rest of the connection.

My understanding is also that each computer (let's just assume Windows) has at least one private key stored in its hard disk.

In practice this is probably true, but not in a way that is relevant to HTTPS (or any other use of TLS). Private keys are used for a lot of things, and Windows does in fact generate them in many cases (typically at least one per user and probably others), but for TLS in particular usually only the server has a private key, which should always be generated specifically for that purpose, and the corresponding public key is distributed as part of a certificate. TLS clients can have their own private keys and certificates - such "client certificates" are used for mutually-authenticated TLS, sometimes abbreviated MTLS - and your browser supports this, but most people will never use that functionality.

If my private key gets stolen, what can the ill-intentioned person do?

If an attacker steals a server's TLS private key (which is the only private key involved in most TLS communication), then at a minimum the attacker can impersonate the server. Doing so requires the victim's device to route traffic to or past the attacker, but there are multiple ways to do this: DNS spoofing, ARP spoofing, owning (or taking over) a router or gateway or proxy or VPN server that the victim is routing through, etc. Demonstrating possession of the server's private key is the means by which the client authenticates the server - that is, by which your browser confirms that, when you navigate to https://security.stackexchange.com/, you're actually connecting to the real security.stackexchange.com server - and confirms that it is performing the key exchange with that server (and not some network attacker, typically called a "man/monkey in the middle" or MitM in situations like this). The attacker (having spoofed the legitimate server and/or having MitM position) could then read everything your browser sent to it, and fake its own responses, or even forward traffic to and from the legitimate server while invisibly decrypting and spying on the contents, with the option to modify them at any time in either direction.

Additionally, if your server was using RSA key exchange or any other key exchange that is not forward secret, and the attacker had recorded previous HTTPS sessions connecting to your server (including the handshake), then the attacker would be able to use the stolen private key to re-derive the exchanged symmetric key and thus decrypt the recorded message traffic in both directions. Similarly, if the attacker had an MitM position on an ongoing connection to your server (and had recorded the handshake of that connection), the attacker would be able to begin decrypting and optionally modifying the network traffic in both directions. However, the reason that ephemeral key exchanges are so commonly used these days is that they provide forward secrecy, such that stealing the private key after the key exchange concludes does nothing to the security of that connection. The attacker needs to actively tamper with the key exchange itself when forward secrecy is used; there's no way to re-derive the symmetric encryption key after the fact.

For the sake of completion, if you are using MTLS and an attacker steals the private key for your client certificate, then that attacker will (most likely, assuming they also got the certificate - which is usually public - and there's no other authentication) be able to impersonate you to servers that expect that certificate. Think of it as being like stealing your password, except instead of you entering a password, your browser uses the private key to sign some data at the end of the TLS handshake and thereby proves your identity to the server.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .