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?


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.

| improve this answer | |
  • 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. – Eric Martin Feb 14 '14 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. – Eric Martin Feb 14 '14 at 17:42
  • g^{a}*g^{b}=g^{a+b} You cannot get the product into the exponent. – fr00tyl00p Feb 14 '14 at 18:09
  • 1
    Thank you, that has to be one of the best explanations I've read yet. (the gift sending analogy) – k1DBLITZ Feb 14 '14 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. – Eric Martin Feb 14 '14 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.

| improve this answer | |

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.