Ephemeral Diffie-Hellman

w33d3r · July 12, 2013, 5:33pm

GIBSON RESEARCH CORPORATION http://www.GRC.com/

SERIES: Security Now!
EPISODE: #412
DATE: July 10, 2013
TITLE: SSL & Perfect Forward Secrecy
SPEAKERS: Steve Gibson & Leo Laporte
SOURCE FILE: http://media.GRC.com/sn/SN-412.mp3
FILE ARCHIVE: GRC | Security Now! Episode Archive

So the problem, though, is that, for a long time we were comfortable, except when we really looked closely at the architecture of SSL because there is a - I don’t want to call it a “fault.” But it is a weakness that has always been present in the SSL that we’ve always been using.

And that is as follows: The private key, as we know when we connect to a remote server securely, the private key is something that only the server has. And the public key is signed by a certificate authority to authenticate that the public key belongs to the entity we want to connect to. Only the entity we want to connect to who has the matching private key that they never disclose is able to decrypt what is encrypted with the public key. So when an SSL connection is established - and anybody who wants more depth can go back to the podcast where we did SSL [SN-195]. We have an SSL podcast which takes this thing apart step by step. I’m going to go, going to take the high points that are relevant here because we have covered it in full detail in the past.

The user, who is the client, wants to connect to the server. They generate a random number and the list of cipher suites that they support. And I’ll explain exactly what that is in a second. They send that to the server. The server has its own list of cipher suites that it supports. And so essentially what the server has received from the user is I know all of these different crypto technologies, and I’ve listed them in the order I think I would like you to choose them, hopefully strongest to least strong. The server looks at that list, compares it with its list. It has its own list of things it knows.

And so the idea is that it chooses, the server chooses the strongest cipher that appears on both lists, is the best way to say that. And it generates a random number, which it sends back to the client. That is, so it sends the cipher it chose, the random number it chose, and its certificate. This is the certificate that it got signed by the authority, asserting to its identity and containing its public key.

So now the client says, okay, I know how to communicate cryptographically in a way that we both understand because from its big list one was chosen by the server and sent back. The client knows its random number and the server’s random number. So, which form part of the handshake. And this is where I’m not going to go into great detail because I did before. It generates another random number, completely separate from that, and it mixes all this together. And it encrypts that with the server’s public key and sends that back to the server.

Now, that’s the key. Because this certificate has been used for authentication. And the certificate containing the public key has also been used for encryption. That is, what the client encrypts under the server’s public key is the final agreed key that they’re going to be using for their conversation. This is the symmetric key, much shorter, 128 bits, maybe 256, typically not much more than that because that’s still plenty, which is encrypted with the server’s public key sent back to the server, under the theory that only the server can decrypt it.

Now, what’s the problem? The problem is, with this particular approach, the same key, that is, essentially the server’s private key, is protecting both the authentication, that is, it’s asserting its identity, and the encryption because the data exchanged is protected by encrypting with a public key which can be decrypted only with the server’s private key. And so that’s the problem.

If the threat model is anyone storing your encrypted traffic, if there’s somebody on the line, as we know there is, I mean, we don’t know that there isn’t somebody inside the organization. I contend, as I did at the beginning of the podcast, and we’ve discussed it before, well, we don’t know. We may never know. But we do absolutely know they’re outside tapping the Internet, tapping the fiber optics all over the place and sucking in encrypted traffic.

So what does the tapping person get? The person who is tapping the line gets all of the communications passing in both directions. And if, as in my theory, they’re right down at the spigot feeding Google, then they’re going to see the client traffic going in, and the server traffic coming back, and be able to extract the conversation, as it’s called, this SSL connection between TCP endpoints at the client and the server, and log that as its own thread. That is, here is a piece of communication which we cannot today decipher. And we believe that it is still extremely difficult for them to decrypt it.

Well, all they have to do is compel the release of the private key. That is, if they are recording all of the traffic, then the NSA can say we have a national security need to access traffic in the past. We need your private key.

LEO: Yeah. They can do that with a National Security Letter, and you’d never even know.

STEVE: Correct. And if they have the private key, then that - because that is protecting both authentication and encryption. They can decrypt, just as the server could, that final packet containing the agreed-upon keying material for this symmetric cipher, just as the server does, and that then gives them access to the entire stream, just as both server and client had.

Now, the creepy thought I had was, imagine this: Imagine that the NSA says, okay. We don’t want to be too onerous. We understand that it represents a problem for you to give us your private key. But, you know, you’re going to be expiring those every two or three years.

LEO: Yeah.

STEVE: So we’d like to have it after you’re done with it.

LEO: Oh. Because they’re storing it all.

STEVE: Yes.

LEO: No problem.

STEVE: So all they have to do is say, uh, don’t delete that. Just we want it when you’re done. After you’ve replaced it with your new keys, we want the old ones.

LEO: There might be some precedent there because they’ve already said, and I think the law agrees, that after six months nobody really owns that data. It’s old data. So what’s wrong with having the key to it?

STEVE: Yeah. And, I mean, what’s the argument? It’s like, well, they’re never saying they want the key we’re using. They’re just saying give us your old keys. We’d like to have those. And, by the way, that’s patriotic. Okay. So it just occurred to me as I was putting this together, it’s like, whoa, you know? They don’t have to demand the current one. I mean, maybe if there’s something, an absolute clear and present danger, oh my god, we’re absolutely sure a terrorist attack is imminent, we have to have this. Well, who’s going to say no? But it seems to me that it’s entirely feasible that they just say, give us your keys when you’re done.

LEO: Just the old ones. The old ones.

STEVE: You’re going to be getting rid of them anyway. Every two or three years you’re…

[Talking simultaneously]

STEVE: Yeah, you keep the new ones. Don’t worry. We’ll be keeping all the new traffic for when you expire those keys.

LEO: Yeah.

STEVE: And so, yeah. Very…

LEO: I’m sure that’s happening. That’s good, that’s…

STEVE: Doesn’t it make sense?

LEO: Sure.

STEVE: It absolutely makes sense. That’s why I said I’m sure I’m not the first person to think about this, so I can mention it. So how do we…

w33d3r · July 12, 2013, 5:38pm

STEVE: How do we prevent that? The prevention has always been present, but even now is barely being used. And that’s this notion of these cipher suites. A cipher suite consists of - in math jargon we call it a “tuple.” It’s like a number of parameters. It’s the how are we going to exchange our keys, what algorithm are we going to use for - well, for example, how are we going to exchange our keys? Well, RSA is what I was just talking about, using the RSA public key in order to protect the contents of the agreed-upon key as it finally goes over the wire.

A different approach is called - is Diffie-Hellman. And we’ve talked about Diffie-Hellman a lot, the Diffie-Hellman key agreement protocol, very famous. And it’s a protocol that allows two parties to exchange keys in plain view such that somebody eavesdropping, not an active attacker but a passive attacker, someone watching them cannot figure out what the final keys are. And it’s very clever. So there are different key exchange methods.

Then there’s the next part of this tuple, is what’s our cipher going to be? Shall we use AES? Shall we use RC4? Shall we use DES, the Data Encryption Standard? And so forth. So what is our cipher? Then the next part of the tuple is, oh, and how long is that symmetric key going to be? 128 bits? Back in the old days, remember, it was 56 bits or 64 or even 40 at one point, back when there were export restrictions that required that.

So the idea was, I mean, this flexibility was built into SSL specifically so that it could meet export restrictions so that you could use a weak cipher on some connections and a strong cipher on others. Essentially it’s like choosing one from Column A, one from Column B, one from Column C, one from Column D. Column D is what are we going to use for our message authentication code, the MAC algorithm? Typically SHA is used in order to verify that the message has not been tampered with. So the idea is that the client will be equipped with software protocols with various combinations of these.

For example, you might have SSL with RSA, with exportable 40-bit using RC4 encryption and MD5 authentication. I just, actually, that’s one that’s in the list. And in fact, Leo, there is a link here in my notes under SSL/TLS cipher suites [www.iana.org/assignments/tls-parameters/tls-parameters.xhtml]. If you click the link and scroll down about half a page, you can see that this has all been standardized. All these cipher suites have been standardized by the IANA for use in SSL and TLS. And so the key is that the - all of, pretty much the majority of the connections today being made are with RSA - the original, oldest, trusted, we know how this works, everybody supports it, key exchange method.

But many browsers today, and many servers today, support what’s called Diffie-Hellman Ephemeral, DHE. Ephemeral specifically means “just for the moment.” So this is DHE, Diffie-Hellman Ephemeral, is a technology that is decoupled - and this is the key, “decoupled” - from the server’s authentication. And as I just said with Diffie-Hellman, a third-party observing the interchange gets no knowledge. That is exactly the protection we want in our SSL connections from long-term archiving. Long-term archiving and subsequent revelation of the server’s private key doesn’t give anybody any help in cracking Diffie-Hellman Ephemeral protection.

Now, one of the reasons this has not been used, and for the same reason super-long public keys have not been used, is speed. Diffie-Hellman is about three times slower in terms of computational burden to establish a key pair between the endpoints. So there’s a much bigger burden, which really ends up being focused on the server because it’s the one where all these SSL endpoints are terminating. The user ends up having two connections in HTTP 1.1 going to the server, and then reusing those connections.

So there is a newer variant called Elliptic Curve, ECDHE, Elliptic Curve Diffie-Hellman Ephemeral key exchange, which is dramatically less burdensome. And Adam Langley over at Google, whom we’ve spoken of before, who’s a cryptographer and security guy, he recently did some work on finding some very efficient elliptic curve algorithms that would further lower the computational overhead. He did this with some other cryptographers. And so those are available and have been standardized.

Here’s the problem, though. And I mentioned this a little bit before. I would love to be offering Diffie-Hellman Ephemeral connections. Not that we need them for GRC. I mean, there’s nothing happening at GRC that - we don’t have, like, user accounts and so forth that the NSA is going to care about. We’ve got people grabbing Perfect Paper Password and Perfect Passwords and stuff. It’s like, okay. Still, of course, I would love to have it. But Microsoft does not offer any Diffie-Hellman Ephemeral in Column A that also has RC4, which is the cipher, in Column B. Unfortunately they’re all CBC, Cipher Block Chaining. And that’s the encryption protocol which is vulnerable to the BEAST attack.

So if GRC, and remember this is all about the order in which the ciphers are chosen, and right now I have had to, in order to get an A score on SSL Labs and give people comfort that they’re not vulnerable to the BEAST attack, which is really not a problem, but yes, it’s a weakness in SSL, I’ve had to put a cipher suite, SSL with RSA, RC4, 128-bit key length, or cipher key length, and SHA. That is No. 5 on the hit parade of IANA in the cipher suites. That’s got to be my first one, and it’s the only choice I have.

I am hoping that Microsoft will get on the ball here and at some point will update the cipher suites on not only their latest and greatest server, which would be 2012, but also 2008, which I’m using. And then, absolutely, I would love to put Diffie-Hellman Ephemeral cipher suites up at the top of the list if they’ve also got RC4. Or actually, if we even had a smarter server, because the later versions of TLS, of Transport Layer Security 1.1 and 1.2, are not vulnerable to the BEAST attack. They have fixed that. But the problem is the server is not currently smart enough to see that the client is willing to do TLS 1.1 or 1.2 and then therefore choose a proper suite. Right now the SSL version doesn’t affect the choice of cipher suites. And, oh, my god, it would be so cool if it did. I don’t know why nobody’s done that yet, but they haven’t.

So that’s the story. Essentially, we’re in another one of these sort of transition periods. I’ve seen some stats that show that, since Firefox and Chrome are both supporters of Ephemeral Diffie-Hellman key exchange, about a third, about 33% of both of those browsers’ overall Internet traffic is using perfect forward secrecy. And of course, again, what that means is that every time you make a connection, the key is negotiated for that connection, and is it used in other connections, and no capturing of traffic and later analysis will easily reveal that. You’d have to do a brute-force ■■■■■ on that one conversation. And then, if you wanted another conversation from the same guy, go through a whole brute-force ■■■■■ on that again. And as far as we know, that just still takes too long to make it feasible.

But we are seeing perfect forward secrecy beginning to happen. In trying to figure out, like, why it’s not more widespread, one of the things I sort of picked up on is people are liking the fact, like web server vendors or corporations are liking the fact that they get credit for spending money on the EA certificate, on having the extended validation, EV, sorry, EV, extended validation certificate. It lights up green on the address bar, and it’s like, oh, okay, that seems like good. And of course it is because it also means that your connection cannot be intercepted without you knowing it, or at least without losing EV, as long as you’re using one of the good browsers.

There is no indication on the so-called Chrome on the UI, the user interface of a browser, any browser, if perfect forward secrecy is in effect. And I don’t have time to write browser extensions now. I’m working on SpinRite, and that’s what I should be working on. But that would be a nice thing for browser vendors to do. It ought to be built into the browser itself and not…

LEO: That’s an interesting idea, make it a - could you make it an extension?

STEVE: It could be an extension, for sure.

LEO: It doesn’t have to be built into the browser. It could be a browser extension.

STEVE: Yeah, it could be a browser extension. But, boy, it would make so much sense to start giving brownie points, bonus points, when connections are perfectly - have perfect forward secrecy.

LEO: And the browser would do it, but the other end would have to do it, as well.

STEVE: It’s go to, yes…

LEO: So it’s mutual.

STEVE: Both ends.

LEO: It’s like SSL.

STEVE: Yeah, exactly. Both ends need to agree on that, on Ephemeral Diffie-Hellman, on any Ephemeral Diffie-Hellman key exchange. But then it would be cool if the browser said, hey, look, the server - see, and the point is, this is much more work for the server. So the server’s only going to be willing to do that if it’s going to get some credit. And so it’s up to the browsers to say, hey, the server is giving you perfect forward secrecy. So nobody - because, remember, it’s the server that has the private key that is otherwise vulnerable.

LEO: Perfect.

STEVE: Yeah.

LEO: Perfect, yeah. An interesting topic. I’m not sure I understood it, but I’m sure many did [laughing]. And for them, that’s why we do this show, Steve Gibson.

STEVE: Well, but the creepiness of the idea that the…

LEO: Means it’s moot, yeah.

STEVE: …NSA could be saying give us your used-up keys, those are useful to us, just makes so much sense to me.

LEO: And even if you’re using perfect forward secrecy, two years from now, if I have the keys, it doesn’t matter.

STEVE: Correct. Does not matter. It will not, does not weaken your privacy.

LEO: Yeah. That’s - oh, so you’re saying perfect forward secrecy will protect me in the future, as well.

STEVE: Yes.

LEO: Ah. Then we must use it.

STEVE: Yes. That’s what the “forward” means, forward into the…

LEO: Forward in time.

STEVE: Perfect, forward into the future, yes.

LEO: Even if you had the keys.

STEVE: Even if the NSA coerces or somehow gets the keys from anyone, that does not help them because the key is in - as long as you’re using an authentication that is separate from your key exchange, then you’re safe because all the NSA is going to get is the authentication key, not the key exchange crypto.

LEO: Well, I think the time has clearly come for software folks, whether it’s Firefox, Chrome, Safari, or somebody new, to recognize that there’s a market demand for secrecy.

STEVE: Yes, yes.

LEO: And to start filling that market demand. And I think it would be perfectly sensible for somebody to create a browser, the Secret Browser. You know, we honor your Do Not Tracks. We honor, you know, we use, we implement perfect forward secrecy when a server supports it. Things like that.

STEVE: Yup, you’re right.

LEO: It’s an opportunity.

STEVE: Yup. And I think, if anything, maybe Mozilla is now suffering from their size. There’s just too much bureaucracy and politics for them to do that. Look at the trouble that they’ve got with infighting among developers, saying, oh, well, we’re going to remove the JavaScript. Well, there’s no way in this browser you were just imagining, Leo, that they’re going to take away the “Disable JavaScript” button.

LEO: Right, right.

STEVE: But it’s gone now in the next version of Firefox.

LEO: It would implement HTTPS Everywhere.

STEVE: Yup. Yup. It would absolutely tell you when you had it. Oh, and many people have been asking for me to do a browser plugin that does my certificate verification. It would do that. You know?

LEO: I hope somebody’s listening with some skills. It would have to be a group of people, obviously. Writing a browser is no longer a one-man show, if it ever was.

Citizen_K · July 12, 2013, 9:07pm

Could you give a short recap of what the message is? This is just a bit much to read…

w33d3r · July 12, 2013, 9:33pm

The topic was meant to be a suggestion for Comodo Dragon ( which is where I posted it to begin with )

… You didn’t understand it … and moved it ? 88) - Oh well, hopefully someone who could potentially be interested in developing CD more might just breeze through this part of the forum one day.

The topic title is the meat of the suggestion.

Understanding it though needs reading unfortunately. Once understood in whole it becomes obvious why it would be a good suggestion for possible inclusion in CD ( or maybe an extension for CD, as Steve suggests that is also possible )

… But then again, I guess I am too focussed on CD, Comodo also has its own version of a FireFox fork, which this would also benefit ( if this were to be a multi-browser extension similar to PrivDog, as opposed to a dedicated modification of the browser itself ).

I have no doubt the developers of CD will understand its relevance.

( If they visit this part of the forum … Otherwise it will now be effectively buried to there eyes )

Citizen_K · July 12, 2013, 11:18pm

Like I thought, after some skimming, this is an article about vulnerability with the SSL system and thus relevant for all browsers and therefor more suited for the General Security Discussions board.

Since this is a publicly available article it is safe to assume the developers are aware of the problem being discussed. It is their job to be on the up and running with the discussions in their field.

In my view when publishing one should be able to make a comprehensive recapitulation about the topic at hand for reasons of getting people interested to read the more in depth article.

A quick Google search reminded me of Red Hat developer who need help from Phillip Hallam Baker Comodo where this Ars Technica article gets linked: SSL fix aims to mend huge cracks in ‘Net’s foundation of trust.

I have come to known Steve Gibson as a pied piper; somebody not without charisma capable of captivating the attention of the concerned non professional computer users.

You can appeal against my decision following How to appeal against Moderators decisions.

w33d3r · July 13, 2013, 1:34am

Nearly there, its also concerning the revelations made by Edward Snowden re; Prism
The idea being if anyone has the ability to hoover up ( and store ) a huge amount of internet communications, which at the time is locked due to encryption, and at a later date ‘acquire’ the old keys to the door to unlock all of that old data, then privacy needs a new method of protecting that data from being unlocked in the future.

Since this is a publicly available article it is safe to assume the developers are aware of the problem being discussed. It is their job to be on the up and running with the discussions in their field.

I would hope so too, but if a none professional can pop in to the forum and point out a suggestion so obvious as this one for the PrivDog plugin ( which has been implemented since ) … One has to wonder if the developers really have got their eyes all over every aspect. They are human after all, and I believe are appreciating a helping hand from the public, Melih certainly did in that case.

In my view when publishing one should be able to make a comprehensive recapitulation about the topic at hand for reasons of getting people interested to read the more in depth article.

My thought was, they would decide what the best course of action would be after reading the whole subject.

A quick Google search reminded me of [url=https://forums.comodo.com/general-security-questions-and-comments/red-hat-developer-who-need-help-from-phillip-hallam-baker-comodo-t96201.0.html]Red Hat developer who need help from Phillip Hallam Baker Comodo[/url] where this Ars Technica article gets linked: [url=http://arstechnica.com/business/2012/02/ssl-fix-aims-to-mend-huge-cracks-in-nets-foundation-of-trust/]SSL fix aims to mend huge cracks in ‘Net’s foundation of trust[/url].

I dont think the Mutually Endorsing CA Infrastructure is relevant, this is about adopting Diffie-Hellman Ephemeral encryption method to protect against anyone coercing old encryption keys out of the authority responsible when they are expired.

I have come to known Steve Gibson as a pied piper; somebody not without charisma capable of captivating the attention of the concerned non professional computer users.

That would be your personal opinion, and in this case thrown into the conversation to lessen the credibility of the source of the information. Was that necessary ?

You can appeal against my decision following [url=https://forums.comodo.com/new-member-information/how-to-appeal-against-moderators-decisions-t62068.0.html]How to appeal against Moderators decisions[/url].

No need for that I dont think, I just wondered at the decision to move the subject before you understood it.

But in hindsight I agree about the decision for the move, as I mentioned in my previous post …

.. But then again, I guess I am too focussed on CD, Comodo also has its own version of a FireFox fork, which this would also benefit ( if this were to be a multi-browser extension similar to PrivDog, as opposed to a dedicated modification of the browser itself ).

JoWa · July 13, 2013, 11:42am

From the quoted article:

There is no indication on the so-called Chrome on the UI, the user interface of a browser, any browser, if perfect forward secrecy is in effect. And I don't have time to write browser extensions now.

So what you are asking for is an extension that tells whether forward secrecy is used or not?

Forward secrecy is supported using two algorithms for key-exchange: DHE (Diffie-Hellman Ephemeral) and ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).

If you click on the padlock next to https in Chromium’s address-bar, and then on Connection, you can see what algorithm is used for key exchange. Google (e.g.https://encrypted.google.com) uses ECDHE_ECDSA (draft-ietf-tls-ecc-00), but still ECDHE_RSA (RFC 4492 - Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)) for some sites, such as https://www.google.se.

Most servers use RSA, which is not forward secret.