25 ms·
Perfect Forward Secrecy can block the NSA, but almost no one uses it
- LoganCale 13y agoNote that despite this headline, the article does correctly state that Google now uses Perfect Forward Secrecy.
- y0ghur7_xxx 13y agoWho cares? The NSA gets it's data directly from google. You need to protect yourself from all hops between you and the one you communicate with, not only from the hops between you and google.
- bobwaycott 13y agoI'm assuming you read the article, in which it offers an explanation of how the NSA gets Google data. Are you disputing that very likely explanation for the theory that a Powerpoint slide somehow communicates more technically accurate and viable information? Obviously, Google could be lying in their most recent denial that disputes such a claim. They are, after all, required to lie if they are directly and materially involved in the program. On the other hand, were I the business owner of a corporation that held millions of people's information and the NSA approached me for access, I don't think it is at all inconceivable and unlikely that I would attempt to negotiate not having the NSA on my network, in my machines, so I could retain the ability to truthfully tell my users that the company did not allow direct access to company servers. In the article, Mr. Horowitz suggests that, given other leaks and information we've had in the prior years regarding NSA tapping the internet, the slurping of company data is happening at the on/off ramps to the networks, where data is coming in/out. This is far more likely than Google shipping off deltas in cron batches. Thus, Google et al. can appear on the PRISM Powerpoint, which just says their data was added to the system. That can mean anything, you know. The Powerpoint presentation is hardly a source of empirical data presenting the technical architecture of the program. This article is attempting to help educate and achieve protection at all hops, not just the hops between you and Google. Perfect Forward Secrecy is just for that purpose--it removes the ability to find your encrypted data crackable via single master key decryption by using temporary keys. So, while Google can only do so much in resisting NSLs, perhaps there is a little bit worth appreciating here. Google can't stop the NSA from slurping up traffic. But they can prevent that data from being massively decrypted via a single key.
- y0ghur7_xxx 13y ago> Google can't stop the NSA from slurping up traffic. But they can prevent that data from being massively decrypted via a single key. I don't want to sound snarky, but, so what? If you want privacy you still have to encrypt data end-to-end, not end-to-[google|microsoft|yahoo|facebook]-to-end. And, anyway, [google|microsoft|yahoo|facebook] should not know about your stuff just like the nsa or anyone else who is not the intended recipient.
- mortehu 13y agoIt's not up to Google to encrypt your e-mail end-to-end, though. That you have to do yourself. This technology exists and is called PGP. Obviously Gmail's HTML interface can't work with these e-mails, until you get some way to sandbox part of the DOM on the client. Search won't work either.
- declan 13y agoNo, they're not required to lie. AT&T and Verizon never did when asked about NSA surveillance: http://news.cnet.com/8301-13578_3-57589012-38/nsa-surveillance-retrospective-at-t-verizon-never-denied-it/ http://news.cnet.com/8301-13578_3-57589012-38/nsa-surveillan...
- deleted 13y ago[deleted]
- Strilanc 13y agoI agree with the article. Perfect forward secrecy (given master private key, still can't figure out derived session keys) is a wonderful property. However, it's a bit over-reaching to say it can "block the NSA". It won't stop them from backdoor-ing your hardware/software (keyloggers, compromised random numbers, etc). It won't stop them from storing the encrypted communication until (for example) quantum computers make it possible to decrypt it (assuming RSA).
- cantankerous 13y ago..Or stop the company you're talking to from shipping off information to a 3rd party after it's been received.
- senorprogrammer 13y agoYes, in the same way that an excellent front-door lock doesn't stop someone from smashing your front window. For the purposes of encrypting traffic to prevent eavesdropping, one of the recipients sending the unencrypted data to a third-party is not an attack vector of consideration. In your scenario the only viable measure is to send no data at all (aka "don't play").
- tptacek 13y agoIn the forward secrecy modes of TLS, RSA isn't used to encrypt anything.
- Groxx 13y agoSince we're assuming quantum computers, isn't Diffie-Hellman vulnerable as well? A bit of wikipediaing suggests DH is equivalent to a "discrete logarithm problem", which it also states has an "efficient" (polynomial time) quantum algorithm.
- chongli 13y ago>backdoor-ing your hardware/software Yeah, gotta build your own computer and operating system from scratch! >(assuming RSA) A great reason to look at elliptic curve crypto.
- gojomo 13y agoTwo notes: (1) While Google uses forward-security on their HTTPS connections, I've not yet seen evidence either way as to whether the SMTP-TLS connections (relaying email to other domains) use forward-security. (The report at checktls.com mentions only the cipher "RC4-SHA", not the key-exchange mechanism.) (2) If one side of the connection chooses to retain its session keys, or chooses session keys in a poor/predictable manner, or leaks information about session keys via a side-channel (either by mistake or intent), then the forward-security could be destroyed, and in a very subtle/undetectable way. (This could be a cheap and sly way to grant visibility to a third-party: adopt forward-security outwardly, but ensure your session keys only look random to people who don't know the bug/secret-seed-shared-with-the-third-party.)
- e12e 13y agoThanks for asking this -- apparently there is no really easy tool for this (I was thinking openssl s_client could do this automagically -- apparently not) -- however, see: http://superuser.com/questions/109213/is-there-a-tool-that-can-test-what-ssl-tls-cipher-suites-a-particular-website-of http://superuser.com/questions/109213/is-there-a-tool-that-c... And now I realized I hadn't tuned the SSL ciphers on one of my servers to not accept (among other thing NULL ciphers... at least if that bash-script works -- I'll have to double check).
- jervisfm 13y agoYou should check out https://ssllabs.com https://ssllabs.com. They accept a URL and do SSL checks to determine if your server is not configured in the most secure manner possible. It is already interesting to run the check against online banking sites to see first hand how seriously they take security in practice. I was surprised to see that some banks score pretty poorly in this regard.
- gojomo 13y agoI don't find an option at ssllabs.com to check SMTP (the topic of this thread). Am I overlooking it?
- rocky1138 13y agoIt would have been a fantastic effect and win for computerworld.com if their site supported what this article talked about.
- paulsutter 13y agoChrome should change the lock icon to something weaker for sessions that don't use ephemeral keys. This may be the most important article on HN related to the NSA leaks. Fact is, most of us haven't paid enough attention to the details of https. EDIT: "something weaker" - didn't mention color. People dont need to understand "forward secrecy", the browser just needs to raise the bar for what's considered secure. The goal is to change server-side behavior, not consumer behavior.
- jiggy2011 13y agoHow do you explain that to people though? It's simple enough to say "if you don't see the green padlock, don't enter your credit card number" but then what if the person sees the weaker symbol? You could say "go ahead" in which case they will go ahead all of the time or you could say "only go ahead under these additional circumstances" , what would they be?
- jlgreco 13y agoThis is a great idea, but I wonder how far you can go with it. Could you also change the lock icon when larger more secure keys are used? Could you perhaps have the lock icon change color between a continuum of red to green (or better, black to white, or something accessible to colorblind people) depending on how the site is set up?
- lazyjones 13y agoThis article seems to start out with wrong assumptions and therefore ends up presenting dangerously wrong conclusions: "Suppose, for example, the NSA was recording all HTTPS encrypted traffic to/from joeswebsite.com in January. Then, in February, they learned the private key for joeswebsite.com. Almost always, that lets them decrypt everything from January, February, March and beyond." We should instead suppose that the NSA has had the private keys all the time (since it started recording encrypted communication), so every piece of communication that has been recorded can be decrypted even with Perfect Forward Secrecy. I.e. let's assume they got Google's private key immediately when it was last changed, then all communication with Google's servers is decryptable (correct me if I'm wrong). The NSA doesn't have to brute-force private keys, they just use legal/strong-arm techniques to obtain them, so it doesn't take a lot of computing power and time.
- Scaevolus 13y agoNo. The point of Perfect Forward Secrecy is that, even if you know one side's private key and have a log of all communications, you cannot determine what _session-key_ was agreed upon, and thus can't decrypt the rest of the session. PFS means that even with private keys, you can't read sessions passively. Of course, it can't help with a MITM or taps on unencrypted data.
- methehack 13y agoI guess this is exactly why this is over my head. Maybe you can help me even though it's a little unfair to pick on you :) If one can decrypt the conversation that negotiates the session key and thereby obtain the session key, couldn't one also read the conversation? This must be the whole trick to the ephemeral part...
- tdg 13y agoThis is not PFS but a simplified example of how you may not be able to decrypt a conversation with one side's private key: Server X and User Y are communicating. Some guy Z has X's private key. Z is also passively listening the communication. - Y sends its public key to X. X sends its public key. - Y generates a random number (A), encrypts with X's public key sends to X. - Both X and Z decrypt the number. Now X, Y and Z all know the number A. - X generates a random number (B), encrypts with Y's public key, sends to Y. - Since Z does not have Y's private key, it can't decrypt it . At this point, X and Y know A and B, Z only knows A. - X and Y use a predetermined algorithm using A and B as inputs to generate a new key. Further communications are encrypted/decrypted with this key. - Z can't decrypt the communication.
- tlb 13y agoFWIW, news.ycombinator.com provides perfect forward secrecy with ECDHE_RSA. Thanks, Nick!
- e12e 13y agoOf course, there is no way for us to know whether or not yc archives a copy of the session keys... (Not that I think yc does that, but we're still talking a shared secret -- you need to trust both parties, if you want to trust forward secrecy...).
- adventured 13y agoSince this is a forum site (versus a site that might get sensitive data), I hadn't bothered to check to see if it was always on HTTPS, until this post. Glad to see that it's always on.
- jgrahamc 13y agoI really hate the name "Perfect Forward Secrecy". There's no guarantee in ECDHE that the connections cannot be decrypted at some future time. All that's being implied is that the key changes per connection. Sure, it's 'better' than RSA with a long lived private key, but there could be advances that would breach ECDH and make none of this 'perfect'. Such as: http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115 http://www.wired.com/politics/security/commentary/securityma... If the NIST supplied curves used by the TLS standard had a backdoor none of this would be perfect.
- tptacek 13y agoWhat you hate is the word "perfect". "Forward secrecy", though, has a technical meaning: a compromise in the long-lived key material for the cryptosystem doesn't enable an adversary to go back and decrypt earlier saved sessions. The link you've provided doesn't implicate Diffie Hellman; it's in an obscure, virtually unused NIST standard that uses elliptic curves to generate random numbers. There are other things not to like about the NIST curves, but the methodology used to generate them is documented (I suppose you could generate your own using the same method) and is based on the literature on ECC from the late '90s.
- jgrahamc 13y agoYes, it's the word 'perfect' that really bothers me. I think it gives the general public the wrong impression.
- flatfilefan 13y agoSuppose the data captured is not a dump of a database but rather a https log. Doesn't it imply that NSA has to essentially rebuild the server functionality to make sense of the data?
- mtgx 13y agoIf Google is offering perfect forward secrecy for e-mails, why don't they have the same for Hangouts (OTR with perfect forward secrecy)?
- Sprint 13y agoHow important is the difference between ECDHE_RSA and DHE_RSA security-wise? edit: I asked because Opera showed a site's free StartCom certificate as "TLS v1.0 256 bit AES (1024 bit DHE_RSA/SHA)". I checked with Chromium and there it is shown as ECDHE_RSA though. This is confusing...
- JshWright 13y agoThey both provide PFS, but ECDHE_RSA is _much_ faster. Do you have TLS 1.1/1.2 enabled in Opera?
- lucian1900 13y agoI don't see how this really helps, though. The NSA can still force a CA to generate certs for any domain they wish to intercept and MITM everyone they care about. They are likely to have the resources for that.
- gojomo 13y agoBut that requires the greater cost/intrusiveness of an MITM, and could potentially be noticed as an unexpected change in the certificate. See for example the SSL Observatory project: https://www.eff.org/observatory https://www.eff.org/observatory
- e12e 13y agoIn the case where providers/servers are under NSA jurisdiction (or control, in the case of them hacking servers) -- they could also keep a copy of session keys. But that would force them to intercept at many more points than simply various edge routers (which is what they may or may not be doing now, having (or not having) equipment at ISPs/TelCos). Essentially, if you use gmail or outlook.com -- you'll just have to trust that no one has forced (or covertly) installed backdoored crypto libraries. I do think it is very likely security agencies (both foreign and domestic) have agents/assets working at large companies like Google and Microsoft -- I don't think it is very likely that they have been able to covertly subvert their infrastructure. But it certainly is possible.
- lucian1900 13y agoThey don't need to do that much. If they control a CA and a few ISPs (especially networks to the outside of the US, since apparently us in the rest of the world are fair game), they can MITM anyone reliably. The only defence is checking fingerprints, but few will bother.
- codereflection 13y agoGmail uses Perfect Forward Secrecy, so what? If the NSA really does have direct access to Google's servers, then PFS will not provide you any extra protection from them. Sure, PFS will make it harder for others to snoop. But the current context for the general population is PRISM and the NSA. I'm not saying that PFS (ugh, what a name, perfect, really?) isn't valuable, I'm just pointing out that no one should think this is going to make it any harder for the NSA to read/access your gmail account.
- AJ007 13y agoThe NSA is getting all of the attention, but this applies to all of the world's intelligence services. Even if you absolutely believe and support what the NSA is doing, you probably have good reason to want any number of governments, foreign competitors, and individuals from knowing what you are doing or (at the least) your financial status.
- y0ghur7_xxx 13y ago> you probably have good reason to want any number of governments, > foreign competitors, and individuals from knowing what you are > doing or (at the least) your financial status. ...and you should therefore ignore PFS in https, and use something that encrypts your data so that only the recipient can read it, and not someone in the middle like google, microsoft or facebook.
- mafribe 13y agoSure, but if Googles stores all session keys, as is likely (key phrase: meta-data), then the session data store is a rich and likely target for all the world's intelligence services, and one that is not invulnerable. After all, Google is a big organisation with a large turnover of staff.
- declan 13y agoI would say that storing session keys is vanishingly unlikely and eliminates the benefit of PFS. Google probably spends millions of dollars a year in PFS additional handshake costs. Google then storing the session keys would be a little like the Dutch building an expensive dike and then knocking a big hole in it. If you want to store data like "user X searched for Porsche 911 GTS 0-60 statistics, so let's show him some 991 Cabriolet ads the next time we can," you don't need to store the session keys.
- IvyMike 13y agoI've had a question about PFS for a while now: How 'expensive' is it to implement? First up, let me state for the record that I don't have personal experience with running SSL on a server. But back in the day, generating a public/private key pair for PGP was a semi-expensive operation. Definitely not the kind of thing I could imagine running on a per session basis. Since PFS requires per-session public/private key pairs, how "costly" is it? (I understand that the goog uses ECDHE, so I guess I'm asking for a general feel for how quickly and efficient this compares to RSA key generation.)
- agilebyte 13y agoThe article mentions 23% reduction in speed for ECDHE-RSA vs RSA. Another example states between 15% and 27% reduction.
- IvyMike 13y agoThanks! I knew I should have read the article more carefully. (The same section of the article also references http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-se... which answers some of my follow on questions.)
- diminoten 13y agoThe line has always been, "You can't stop a determined hacker with any single solution." The NSA may be a group of determined hackers. One technology isn't going to suddenly cure the whole problem. It takes a solid security policy set at and followed by the top levels of a company, and constant vigilance to respond to threats. You're not going to stop anyone from getting in, but you can stop them from getting anything of value, and you can kick them out quickly and quietly.
- Nursie 13y agoDoes it need to be DHE or will DH do just as well? What exactly is the difference here? It still uses a key per connection at the least, and it's still not on the NIST/FIPS 140-2 standards because you can't decode it after the fact so it breaks auditing (all AFAICT, and I have looked at this stuff a lot). That said, we're best using AES_GCM, 2048-bit RSA and ECDHE as a matter of course, because at the very least it requires a valid, active MITM to break and can't just be logged and scanned later.
- casca 13y agoIt's odd that there seems to be no definitive instructions for nginx or apache for enabling PFS. Given that it's clearly not obvious how to set this up, how many here are inadvertently running non-PFS without knowing it?
- baudehlo 13y agoFunny, I think in part it's because few people care. Maybe I didn't have the right keywords, but I just wrote an article about this for nginx/stud, and it got 2 upvotes on HN. Here's the HN link: https://news.ycombinator.com/item?id=5935988 https://news.ycombinator.com/item?id=5935988
- joepub 13y agoWhat about more use of one-time or ephemeral email addresses? The info we have so far seems to suggest NSA likes to track email addresses. Compare tracking an email address that was only used to send or receive one or a few messages with one that has a long history of use.
- lucasjans 13y agoIt appears this very site is using Perfect Forward Security. http://cloud.lucasjans.com/image/081m1V3c3O1z http://cloud.lucasjans.com/image/081m1V3c3O1z
- mattme 13y agoPGP complete lacks perfect forward secrecy. Suppose an eavesdropper is recording your email, even though they can't understand it. If your private key is ever compromised (say by torture or subpoena), then all your previous messages can be immediately decrypted. > You could say that Bob losing control of his private key was the problem. But with today’s easily-compromised personal computers, this is an all-too-likely occurence. We would really prefer to be able to handle such failures gracefully, and not simply give away the farm. http://www.cypherpunks.ca/otr/otr-wpes.pdf http://www.cypherpunks.ca/otr/otr-wpes.pdf