2

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?

Community
  • 1
Eric Martin
  • 23
  • 3

3 Answers3

7

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.

fr00tyl00p
  • 2,329
  • 1
  • 15
  • 17
  • 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: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange#Operation_with_more_than_two_parties 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
  • I guess the conclusion for me is, if asymmetrical encryption is used to exchange an encrypted symmetrical key over the internet, then those communications may not be secure in the future. My reasoning is this: if someone is sniffing and saving all of these communications, they could one day decrypt the asymmetrical encryption, get the symmetrical encryption key, and decrypt any past communication. The first step of decrypting the asymmetrical encryption which enables all of the others may be feasible in the future through quantum computers or some other means. Does this sound correct? Thanks. – Eric Martin Feb 15 '14 at 00:07
  • g is public. The problem is to reverse the function and get log_g(g^{a}). The problem is difficult to solve if you operate on certain groups. It is known as the computational diffie hellman problem. – fr00tyl00p Feb 15 '14 at 00:49
  • @EricMartin Yes, this sounds correct. If you can break the asymmetric cryptography then practically all HTTPS/SSL/TLS Traffic can decrypted as they all rely on those principles in one or another way. – fr00tyl00p Feb 15 '14 at 13:24
  • @fr00tyl00p Thank you for affirming my thoughts. I suppose the NSA can have access to those Asymmetric keys if they want to, and so they do. And they read everything that we write, or at least store it all to decrypt later. I'm guessing that this is true at least for many of the official "signing certificate" groups. If they're government authorized they're probably also government controlled, and so they've given up their asymmetric keys. It's a shame, but there's not much we can do about it. – Eric Martin Feb 17 '14 at 16:51
  • @EricMartin Using a VPN would do the work. One that would be hosted in another country than US (pref) – Bob Ebert Feb 27 '16 at 17:54
4

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.

Stephen Touset
  • 5,736
  • 1
  • 23
  • 38
3

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.

Daisetsu
  • 5,110
  • 1
  • 14
  • 24
  • Thank you. Doesn't this answer http://security.stackexchange.com/questions/19616/why-is-it-possible-to-sniff-an-https-ssl-request inply you can sniff SSL data, but you'll only be getting encrypted data? – Eric Martin Feb 14 '14 at 16:57
  • Yes, you COULD sniff ssl data, but since it is encrypted you can't sniff any usefull data. – Daisetsu Feb 14 '14 at 17:42