
SSL: Intercepted today, decrypted tomorrow - jstanley
http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html
======
pvnick
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.

~~~
mpyne
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.

~~~
merlincorey
I'll bite.

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.

~~~
rsync
Unless it's a one time pad with good RNG. In that case it is indeed a good
idea to assume your cryptography is perfect and always will be.

~~~
merlincorey
Just don't lose the key... As I'm sure I don't have to tell you.

What book would you use? That's how "they" used to do it.

------
gcb0
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.

~~~
icebraining
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.

[1]
[https://en.wikipedia.org/wiki/Server_Name_Indication](https://en.wikipedia.org/wiki/Server_Name_Indication)

~~~
X-Istence
It is sad, but by the time SNI is a viable extension to use, IPv6 should be in
full swing and SNI will no longer be required :-(.

~~~
graue
SNI is already plenty viable if you have few/no IE users. That's certainly not
everyone, but it's good enough for some of us.

~~~
bigiain
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?" ;-)

------
dhx
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.

[1]
[https://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography](https://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography)

[2]
[http://www.nsa.gov/business/programs/elliptic_curve.shtml](http://www.nsa.gov/business/programs/elliptic_curve.shtml)

[3] Refer to
[https://en.wikipedia.org/wiki/Comparison_of_TLS_implementati...](https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations)
for a comparison of libraries providing TLS crypto.

------
jcampbell1
Can someone explain why we don't get ECDHE on ubuntu 12.04 by default?

On ubuntu 12.04 my apache has:

    
    
        SSLCipherSuite HIGH:MEDIUM:!ADH:!MD5
    

` openssl ciphers 'HIGH:MEDIUM:!ADH:!MD5'` shows a ton of ECDHE stuff in the
list. I am not sure what it takes to get apache to use the ECDHE ciphers.

~~~
dfc
Why not by default? Ask ubuntu and report a bug:
[https://bugs.launchpad.net/ubuntu/+source/apache2/+filebug](https://bugs.launchpad.net/ubuntu/+source/apache2/+filebug)

How to do it for yourself:
[https://news.ycombinator.com/item?id=5171250](https://news.ycombinator.com/item?id=5171250)

~~~
prg318
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?

~~~
jcampbell1
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.

~~~
dfc
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.

[1] [https://github.com/ioerror/duraconf](https://github.com/ioerror/duraconf)

~~~
jcampbell1
Yes, the cloudflare advice does break chrome PFS. With the defaults, chrome
shows:

    
    
        CAMELLIA_256_CBC, with SHA1 for message 
        authentication and DHE_RSA as the 
        key exchange mechanism.
    

By changing to the suggestion in the comments, the encryption downgrades to:

    
    
        The connection is encrypted using RC4_128,
        with SHA1 for message authentication and 
        RSA as the key exchange mechanism.

~~~
dfc
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.

------
dmix
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?

~~~
elithrar
> The IP stuff -> personal identity stuff requires it to be near present time
> does it not?

Collect logs from ISP that show IP <-> account. Many ISPs keep these logs
around for a long while as it is.

~~~
icebraining
An account is not a person, and thankfully some courts are recognizing that:
[https://www.techdirt.com/articles/20130218/21462222020/yet-a...](https://www.techdirt.com/articles/20130218/21462222020/yet-
another-court-says-ip-addresses-are-not-enough-to-positively-identify-
infringers.shtml)

------
acd
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.

------
Arnor
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?

~~~
bigiain
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.

~~~
graue
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.

~~~
spicyj
If I understand properly, having Google's private key only allows you to do
MITM attacks, not to passively decrypt traffic using PFS algorithms.

~~~
graue
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.

(Sorry if this post sounds confused; it's late.)

~~~
mortehu
> 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.

------
noveltyaccount
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?

~~~
calmingbreeze
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.

~~~
noveltyaccount
Thanks for clarifying, that makes sense.

------
znowi
I'm a bit surprised to see duckduckgo.com not using PFS :/ Hopefully they
implement it soon.

~~~
Mithrandir
From [https://duck.co/topic/duckduckgo-ssl-not-secure-
enough#28469...](https://duck.co/topic/duckduckgo-ssl-not-secure-
enough#28469000001486713) :

> We're aware and are planning accordingly. Thanks for the heads up, though.

------
nemoniac
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?

~~~
rorrr2
Chrome does it by default, just click on the padlock. Example:

[http://i.imgur.com/k1bhh77.png](http://i.imgur.com/k1bhh77.png)

------
ww520
Speaking of SSL attack, are BEAST and CRIME attacks on SSL still a problem in
the wild? Have most browsers been patched against these kind of attacks?

