SSL: Intercepted today, decrypted tomorrow

http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html

by jstanley • 13 years ago

231 87 13 years ago

news.netcraft.com

pvnick• 13 years ago

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.

tsotha4• 13 years ago

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.

jstanley3• 13 years ago

I think this can get you into some trouble in the UK, if not the US.

http://en.wikipedia.org/wiki/Key_disclosure_law

jcampbell14• 13 years ago

If they start doing that I'll generate a new set of keys every day.

Doesn't that require getting a CA to re-sign your keys every day?

mpyne4• 13 years ago

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.

merlincorey4• 13 years ago

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.

jjoonathan2• 13 years ago

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.

clarkm• 13 years ago

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.

tsotha4• 13 years ago

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.

CPAhem• 13 years ago

Might be why Google is upgrading all SSL certs to 2048 bit

http://googleonlinesecurity.blogspot.com.au/2013/05/changes-...

gcb02• 13 years ago

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.

icebraining2• 13 years ago

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

contingencies• 13 years ago

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.

Apparently we can thank the French: http://www.edelweb.fr/EdelKey/

X-Istence• 13 years ago

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 :-(.

mappu• 13 years ago

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)

sliverstorm• 13 years ago

Changing the crypto would require lots of time to roll out new platforms and updated clients.

Which is just an argument for starting sooner rather than later, and staying ahead of the curve, rather than giving up the point...

gcb02• 13 years ago

couldn't agree more. was just setting the joke up. :)

fixxer• 13 years ago

"nature will find a way"

brilliant statement. thank you.

7952• 13 years ago

Or protocols need to develop that use out of band communication to seed certificates. Just mail me some entropy :)

Arnor• 13 years ago

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?

jstanley3• 13 years ago

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.

gknoy• 13 years ago

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.

bigiain5• 13 years ago

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.

graue3• 13 years ago

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.

jcampbell14• 13 years ago

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.

dfc6• 13 years ago

Why not by default? Ask ubuntu and report a bug: https://bugs.launchpad.net/ubuntu/+source/apache2/+filebug

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

prg318• 13 years ago

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?

agwa• 13 years ago

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.

(Corroboration: http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-se...)

bigiain5• 13 years ago

I'm still investigating/experimenting myself, but if I understand properly what I've read so far, you can change that to:

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

bincat• 13 years ago

I would like to also include ECDHE ciphers but I'm having a hard time coming up with a line that does not include ECDH. Any ideas?

dmix• 13 years ago

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• 13 years ago

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.

icebraining2• 13 years ago

An account is not a person, and thankfully some courts are recognizing that: https://www.techdirt.com/articles/20130218/21462222020/yet-a...

jonknee• 13 years ago

Why would they have to prove anything? This is a secret program and nothing it turns up will show up in a non-classified arena.

znowi• 13 years ago

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

Mithrandir• 13 years ago

From https://duck.co/topic/duckduckgo-ssl-not-secure-enough#28469... :

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

dhx• 13 years ago

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

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

noveltyaccount2• 13 years ago

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• 13 years ago

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.

noveltyaccount2• 13 years ago

Thanks for clarifying, that makes sense.

ww520• 13 years ago

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?

acd• 13 years ago

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.

nemoniac• 13 years ago

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• 13 years ago

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

http://i.imgur.com/k1bhh77.png

SSL: Intercepted today, decrypted tomorrow

Related Stories