To repeat, "Why can't someone break email or https encryption by somehow getting access to the encryption key?" In other words, why can't someone intercept the key, or the algorithm to create the encryption key, using packet sniffing? After this, why can't they use packet sniffing to also get other data that is sent via https, and then decrypt it using the key? Is this possible, unlikely, or simply impossible? This is related to this question: Why is it possible to sniff an HTTPS / SSL request? But my question is, is it reasonable for someone to obtain a session key through sniffing? Also, what are the other ways someone could obtain a session key?

3 Answers 3


Maybe you can see that it is indeed possible to send a secret over an untrusted path by the following (somehow simplifying but illustrative :-) example

  • You don't trust the post office and want to send me a gift

You can achieve it in the following way

  • You put the gift in a box and lock it with YOUR lock
  • You send the box to me and I additionally lock it with MY lock
  • I send it back to you
  • You remove your lock and send it back to me
  • I remove my lock open the box and take the gift

The mathematical approach behind key exchange protocols is somehow similar. The most fundamental of them is the Diffie-Hellman key exchange.

I hope that makes things a bit more intuitive.

  • This makes a lot of sense, but for each new https connection is their really something sent to the site, then back, the to, then back to establish a session key? It seems like a lot of steps. Once this key is established, information only has to go one way from then on, right? Thanks. Commented Feb 14, 2014 at 16:56
  • The Diffie-Helman article confuses me, though, at this part: en.wikipedia.org/wiki/… It says that for a 3 party key an eavesdropper may know this information "An eavesdropper has been able to see g^{a}, g^{b}, g^{c}, g^{{ab}}, g^{{ac}}, and g^{{bc}}, but cannot use any combination of these to reproduce g^{{abc}}." Why can't the sniffer take g^{a}*g^{{ab}} to get the key? Thanks. Commented Feb 14, 2014 at 17:42
  • g^{a}*g^{b}=g^{a+b} You cannot get the product into the exponent.
    – fr00tyl00p
    Commented Feb 14, 2014 at 18:09
  • 1
    Thank you, that has to be one of the best explanations I've read yet. (the gift sending analogy)
    – k1DBLITZ
    Commented Feb 14, 2014 at 18:16
  • In this instance - g^{a}*g^{b}=g^{a+b}, couldn't the attacker somehow know g and use it to find a and b, and so in my above comment the attacker could find g^{{abc}} by intercepting g^{a}, g^{b}, g^{c}? Under what circumstances could an attacker get g? I believe I saw in a previous post that g was a predetermined value. If it's predetermined can't the attacker intercept it at some point when it's being determined? I know all of this would be very unlikely. Thanks. Commented Feb 14, 2014 at 22:25

In short, the key is never directly sent over the wire. It is negotiated in a way that both parties can derive the same key, even though there is not enough data put on the wire to reconstruct it.

For instance, in ECDH protocols, each side creates a unique public/private keypair. They then exchange public keys. By computing a mathematical operation on their own private key and the other party's public key, they both arrive at the same symmetric session key which is used to encrypt the remainder of the session. An attacker eavesdropping on the communication would only see two public keys, which isn't enough information to compute the shared session key.


SSL/TLS makes use of public key cryptography. This is the idea that we can have two cryptographic keys, one publicly known (pub), and one only known to the individual and never disclosed (priv).

Lets say a user connects to a website with HTTPS (SSL/TLS). They send a request to the server, which responds with among other things, its x509 certificate which details information about the site. This certificate includes the sites public key, as well as being signed by a trusted third party.

You can securely encrypt data using this public key, and be assured the ONLY person who can decrypt the encrypted data (ciphertext) is the person with the private key.

So now you have a way of sending a secret to the server, which only you and the server know. There are several ways to establish a session key in the presence of an attacker, but it basicly boils down to a secret shared between you and the server.

This session key is a symmetric key (not public/private).

EDIT: Sniffing can not show you the data which has been encrypted by SSL. Sniffing can not reveal the key. Certain appliances such as interception proxies or rogue CAs can compromise SSL security, but they are rare.

  • Thank you. Doesn't this answer security.stackexchange.com/questions/19616/… inply you can sniff SSL data, but you'll only be getting encrypted data? Commented Feb 14, 2014 at 16:57
  • Yes, you COULD sniff ssl data, but since it is encrypted you can't sniff any usefull data.
    – Daisetsu
    Commented Feb 14, 2014 at 17:42

You must log in to answer this question.

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