I've been saying this for a while now (well, a couple weeks anyway). The defeat of the cryptography behind SSL communication is an inevitability given sufficient time, so it would absolutely behoove intelligence agencies to store everything, including encrypted data. As Snowden said, one of the dangers of these programs is the possibility of going back in time to paint a normal life in the context of a wrongdoer. In a few decades, when powerful computers and algorithms have all but obliterated current encryption technologies, all of your current "safe" data might as well have been sent plaintext.
Or the NSA could just demand private keys via FISA letter.
Why do people keep repeating this trope that it's only a matter of time before encryption will be broken?
Use a Diffie-Hellman style protocol to create and exchange a secret key for each session, use AES-256 if you're ultra-paranoid, then forget the session key. It even works today, and there are no known attacks against AES that can reduce the work enough to beat the heat death of the universe.
Because we can't really predict the future and some far-fetched science-fiction sounding things such as quantum computers and future advancements we can't currently conceive of may completely and utterly change that, perhaps even overnight.
From a paranoid security point of view, it's definitely a bad idea to assume your cryptography is perfect and always will be.
And from a paranoid physical security point of view it's definitely a bad idea to assume I would survive my car trip to the grocery store every week.... I do it anyways, as it's still much better than the alternatives.
I believe this a logical fallacy. I didn't argue that due to said paranoia one should not engage in cryptography, any more than I would argue that one should not drive their car to the grocery store every week.
I'm talking about complacency, and how it's a better idea for us to assume that sooner or later (if not currently) our best-known cryptography will be broken. If I recall correctly, in 2008, Simple Nomad[1] told us to consider PGP broken by the government. He wasn't saying it is... just we should consider it as such and find something better, before it's too late.
And if I just told you to assume AES is broken by the government and find something better, would that be all the incitement you need? Or would you want actual evidence that at least hints it's probably instead of just assumptions?
You're missing the point. I already am thinking of it as broken, even without evidence, because I want to look ahead. This doesn't mean I don't use cryptography "because it's broken", it means I don't trust it as if it wasn't broken.
Also, to be a bit unfair, I have no idea who you are, but I know who Simple Nomad[1] is. If Simple Nomad told me the government had definitely owned PGP, AES, or anything else of that nature I'd be very concerned, no evidence necessary. The implication is that he already has the evidence, but maybe can't share it with me. Or he's really drunk and messing with me.... either way, good times ahead!
That's also the problem with switching to a new and untested solution. You only get to be wrong once. Is there any symmetric cypher with more cryptanalytic effort put into than AES? Is there even one?
You switch to something else out of paranoia and you could easily switch to something with a theoretical backdoor that NSA has already identified and exploited (after all, they're "10-20 years ahead of us", right?).
What about quantum computation? My (only slightly informed) understanding is that quantum computing's greatest strength lines up perfectly with the problem of brute-forcing encryption.
A sufficiently patient attacker can still eavesdrop on TLS sessions established via RSA or ECDHE today, wait for quantum computers to arrive (10+ years?), then break their public keys, and derive the symmetric keys used to encrypt the session from there.
What does a "code-based cryptosystem" mean? You can approximate asymmetric cryptography using something like Kerberos, but these schemes requires a trusted third party.
You seem to be under the misapprehension that quantum computing threatens all asymmetric cryptosystems. It doesn't. McElice is an example of an asymmetric scheme that uses binary error correcting codes as its trapdoor function, rather than discrete logs.
Grover's algorithm halves the keysize. It's not a theoretical problem (just double the keysize) but plenty of sites today use 128-bit keys for their block ciphers. Even though quantum computers don't rival classical computers for speed yet and therefore saying that these keys are "effectively 64-bit" would be slightly disingenuous, there's no reason to expect that QCs won't make that a reality within our lifetimes.
This is basically what OTR messaging does. But you're still vulnerable to man-in-the-middle attacks when using DH, unless you're already on a secure channel. And the most common solution to authentication is SSL/TLS, which the defeats the purpose of the whole thing.
So we need to utilize other channels, like key-signing parties.
Or, I suppose you can communicate using something like SRP to avoid this issue, though it sounds like a complicated layering of crypto that is destined to be screwed up at some point. However, this is what ZRTP does, and it seems to be pretty widely adopted.
>It even works today, and there are no known attacks against AES that can reduce the work enough to beat the heat death of the universe.
Well, that's the problem isn't it? The known attacks aren't the ones you have to worry about. Nearly every form of cryptography to date was expected to last longer than it actually did. I would not be at all surprised to find AES-256 broken before I'm on the wrong side of the grass.
The Cybercrime Act 2001 No. 161, Items 12 and 28 grant police with a magistrate's order the wide-ranging power to require "a specified person to provide any information or assistance that is reasonable and necessary to allow the officer to" access computer data that is "evidential material"; this is understood to include mandatory decryption. Failing to comply carries a penalty of 6 months imprisonment. Electronic Frontiers Australia calls the provision "alarming" and "contrary to the common law privilege against self-incrimination."
I wonder how that would work if you own the server, but only the individual users held their private keys?
Hmmm. As someone under the jurisdiction of the Australian Cybercrime Act... I wonder if it's time to have policies in place for private keys - much like many corporate email retention policies. "We keep private keys for twelve months only. We create and deploy new keys every six months and securely delete all keys older than 12 months along with their passphrases - including physically destroying all drives that ever contained the key and/or backups of it. Any data not transitioned to new encryption keys before private key destruction is considered irretrievable."
"Yes Agent Smith, that's a mighty fine $5 wrench you have there - here's _both_ my current private keys. Last year's? No sorry, here's the video of those disk drives being hammered to bits then melted down to sludge. (Ouch! Why are you hitting me? This plan was _flawless!_)"
I think you could probably make the case you had no reason to believe sessions were "evidential material" because you aren't storing them and you have no reason to believe anyone else is either.
Of course, once you get a notice there's probably nothing you can do.
Also, why is it that everytime the authorities get away with making analogies with stuff in real life, like encryption compared to a locked box, or something, but when it's the other way around, say e-mail vs snail mail, suddenly they are not the same anymore, and they need to be treated differently (authorities can't look into your mail, but but get all your e-mail after 180 days).
I have found that the Crypto Law Survey is remarkably more detailed than wikipedia for crypto policy questions. Sadly the site is not as well known as wikipedia:
So the only solution is to increase the effort to decrypt. And for that we have to either/both increase complexity of the crypto (hard) and the amount of noise traffic.
Changing the crypto would require lots of time to roll out new platforms and updated clients.
Hence, the only feasible way to save the internet is to convert all porn sites to https. If you work on a ISP, block all porn connections over http, nature will find a way and the https sites will popup overnight.
With SNI[1], the hostname is sent unencrypted (so that you can host more than one domain in a single IP address), so the watchers can simply filter out porn domains.
As of November 2012, the only major user bases whose browsers do not support SNI appear to be users of Android 2.x (default browser), Internet Explorer (any version) on Windows XP and versions of Java before 1.7 on any operating system.
From a security point of view I don't think this changes anything - in the absence of SNI, you can get the hostname anyway just by starting a TLS connection to the server, as your browser would.
(Unless porn sites start whitelisting incoming IP addresses, which seems pretty unlikely)
And while I know cPanel/WHM doesn't really belong in the same discussion as "encryption possibly resilient against state level attackers"… I note with interest that the latest cPanel update (11.38) includes SNI support. That's "switched on" an _huge_ userbase of webhosting that can now grab a cheap/free SSL cert without needing dedicated ip addresses, and who can then tell users "you'll need to upgrade your browser to use our secure site - have you tried downloading Chrome?" ;-)
Popular libraries such as OpenSSL and GnuTLS support TLSv1.2 (NSA Suite B Crypto[1]). Typically this means preferring or forcing TLS_ECDHE_ECDSA_AES_256_GCM_SHA384 with elliptic curve CURVE-SECP521R1 for maximum security. Refer to [2] for more information on the elliptic curve key sizes recommended to be used with various symmetric key sizes.
The notable problem for many users (particularly client-side) is libraries such as NSS not yet supporting TLSv1.2[3] and therefore not supporting NSA Suite B Crypto.
I think your first link may be incorrect? I also tried looking through the tracker but I wasn't able to find a relevant bug associated with this. Would you mind posting the link to the bug?
The second link doesn't work as far as I can tell.
I think the person that says we need Apache 2.4 to get ECDHE is correct. Adding ECDHE ciphers to the Apache 2.2 config doesn't seem to do anything. Following the advice in the second link actually turns off PFS for chrome compared to the default setup.
I have a bad habit of linking to HN posts and assuming that people understand I mean "look at the comments." The Cloudflare instructions break chrome? That is my bad, I have not verified them myself recently. I usually use the cloudflare settings or jacob's duraconf[1]. Thanks to joeyh's mr I usually have duraconf checked out on any machine that I use.
Yeah, I actually just noticed that cloudflare was using nginx so the qualys scan was not indicative of the cloudflare apache setup. I apologize I got distracted watching those genetic cars.
I am sorry, my link was correct but the context was incorrect. The link is to submit a new bug for apache in ubuntu's bug tracker. I changed the text so that it is clear that I am suggesting that a bug be filed.
In my opinion pubic issue trackers are one of the greatest features of open source software and under utilized. Since there are no open or closed bugs I imagine the most likely answer for why it is not on by default is "nobody asked or not enough people asked." If enough people say "this applies to me" on a bug in launchpad the maintainers will recognize that it is an important feature for users. If there is a reason why it is not on by default the WONTFIX bug report will provide an answer for other people who are curious.
Unfortunately individual applications need to add support for ECDHE for it to be usable, and Apache 2.2 does not have such support. Apache 2.4 does though.
The big question is how are they going to prove the majority of the SSL traffic was from x person? The majority of identity would have to be via IP address. The IP stuff -> personal identity stuff requires it to be near present time does it not?
... unless the SSL content contains identifying information. But what percentage would that be in the future?
Governments can just run a "Real CA" trusted by most common web browsers, then that government run CA could occasionally emit new certificates of sites that the government wants to me man in the middle for. Then government does not have to decrypt the information as they are already man in the middle. Some users get the sites original certificate, others get the MITM certificate and interception.
Thus trusting central CA is somehow broken from a security point of view. How many end users really check the certificates is coming from the right CA and has correct fingerprint?
Then you do not need to decrypt the SSL traffic. Much easier.
This sounds like a brilliant solution to a difficult problem, but I fear it only solves a portion of the problem. It deals with the issue of stolen keys, but how does it protect against cryptanalysis? If an organization were able to reveal the a key with a replicable process, couldn't it be simply repeated for each session key?
The hope is that the "replicable key revealing process" is difficult and time consuming - which is worthwhile for an attacker with sufficient resources if going to the effort to reveal a key results in breaking every encrypted session from that source. PFS means they'd go to all that effort to reveal an ephemeral key for only one session.
It'd be _well_ worth the NSAs time/money to burn 10 million cpu hours brute forcing Google's TLS key if it gave them every encrypted session's cleartext past and future. It's not practical to burn 10 million cpu hours for every SSL session connecting to Google's servers.
Although even with PFS, cracking Google's private key would still give them access to every future encrypted session, until the key changed. So PFS is no panacea here.
With PFS, the webserver and the browser (yeah, oversimplifying here) each generate a random number and "create" a temporary session key without revealing enough about their individual random numbers to an eavesdropper.
So as well as Google's private key, the attacker also needs the "agreed upon ephemeral key" for each session if they want to passively snoop. (And if they're deeply enough into Google's infrastructure to see and archive those, then don't need to decrypt SSL connections - they can just syphon the cleartext out from inside the SSL termination).
(Note: I'm still trying to educate myself here. I fear I may be not fully understanding the subtleties and differences between DH & DHE, and when that "E" means "ephemeral" and whether it also sometimes means "elliptic"…)
Absolutely. This is why PFS protects past sessions, because you can try to decrypt the past, but you can't MITM the past.
But do you think the slightly harder task of running MITM attacks (as opposed to simply siphoning off a copy of the data as it passes) would thwart an entity like the NSA? I really doubt it. PFS or not, a leaked private key means game over for all data transferred after the leak and until that key is replaced.
And that's my point, the reason I made the statement you're replying to: it would still be well worth the NSA's time to crack Google's private key, and PFS doesn't somehow make that scenario not bad. Your statement is correct, but, I argue, not terribly relevant.
> But do you think the slightly harder task of running MITM attacks (as opposed to simply siphoning off a copy of the data as it passes) would thwart an entity like the NSA?
MITM attacks have the disadvantage that they can be noticed by communicating the session key through a second, more secure, channel, for example one using a client certificate.
I think your concerns are mitigated by the attack vectors.
If cracking encryption with N bit length keys someday becomes trivial, it doesn't matter what keys we used in the past: You're right. My meager understanding is that we don't expect this to be the case anytime soon, and worries about moore's law or asics for cracking keys can be mitigated by increasing key size until it's infeasible to brute force.
If your main SSL key is compromised/subpoenaed, at least you still have the PFS keys for individual conversations. Those would need to be subpoenaed (or otherwise made not-secret) as well, and so in theory your data is still safe even if they go after john Q terrorist's data.
I think that is an intractable problem. It is impossible to design a system that is not vulnerable to flaws in its design. The idea is to design a system that doesn't have flaws.
Doesn't SSL/TLS use a per-session symmetric key that is exchanged using the asymmetric server keys? Is the point of this article that even that per-session private key would be logged or re-generated and therefore prone to attack if the server private key were exposed?
If an eavesdropper records all traffic between client and server, he/she will also record the encrypted session key. If the server's private key is compromised, the eavesdropper can decrypt the session key and use it to read the rest of the communication for that session.
Is there a browser plugin that indicates more information than the padlock icon such as which cipher suite is being used for the current SSL connection and whether that suite uses PFS?
Or the NSA could just demand private keys via FISA letter.