SSL: Intercepted today, decrypted tomorrow
news.netcraft.com
news.netcraft.com
Or the NSA could just demand private keys via FISA letter.
I don't think you're legally obligated to retain private keys. If they start doing that I'll generate a new set of keys every day.
Australia
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?
"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!_)"
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).
Of course, once you get a notice there's probably nothing you can do.
$ dig www.cryptolaw.org @8.8.8.8
; <<>> DiG 9.8.3-P1 <<>> +nocomments www.cryptolaw.org @8.8.8.8
;; global options: +cmd
;www.cryptolaw.org. IN A
www.cryptolaw.org. 1801 IN A 77.74.54.129
;; Query time: 45 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Jun 25 19:27:38 2013
;; MSG SIZE rcvd: 51Doesn't that require getting a CA to re-sign your keys every day?
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.
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.
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!
[1] http://www.soldierx.com/hdb/Simple-Nomad
> He has spoken at DefCon, BlackHat, ^Shmoocon^, and ToorCon, and he is known for his somewhat paranoid mindset.
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 book would you use? That's how "they" used to do it.
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.
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.
http://googleonlinesecurity.blogspot.com.au/2013/05/changes-...
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.
Apparently we can thank the French: http://www.edelweb.fr/EdelKey/
(Unless porn sites start whitelisting incoming IP addresses, which seems pretty unlikely)
Which is just an argument for starting sooner rather than later, and staying ahead of the curve, rather than giving up the point...
brilliant statement. thank you.
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.
[1] https://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography
[2] http://www.nsa.gov/business/programs/elliptic_curve.shtml
[3] Refer to https://en.wikipedia.org/wiki/Comparison_of_TLS_implementati... for a comparison of libraries providing TLS crypto.
On ubuntu 12.04 my apache has:
SSLCipherSuite HIGH:MEDIUM:!ADH:!MD5
How to do it for yourself: https://news.ycombinator.com/item?id=5171250
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.
CAMELLIA_256_CBC, with SHA1 for message
authentication and DHE_RSA as the
key exchange mechanism.
The connection is encrypted using RC4_128,
with SHA1 for message authentication and
RSA as the key exchange mechanism.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.
(Corroboration: http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-se...)
SSLCipherSuite HIGH+DH:MEDIUM+DH:!ADH:!MD5
to require PFS. I'm not sure how many browsers that'll break (I have doubts about broad coverage for Safari/Opera/IE).
... unless the SSL content contains identifying information. But what percentage would that be in the future?
Collect logs from ISP that show IP <-> account. Many ISPs keep these logs around for a long while as it is.
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.
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.
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.
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.
(Sorry if this post sounds confused; it's late.)
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.
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"…)
> We're aware and are planning accordingly. Thanks for the heads up, though.