SSL: Intercepted today, decrypted tomorrow(news.netcraft.com)
news.netcraft.com
SSL: Intercepted today, decrypted tomorrow
http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html
11 comments
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.
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.
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.
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.
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.
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.
What book would you use? That's how "they" used to do it.
Perfect? Two people know the key.
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.
[1] http://www.youtube.com/watch?v=N9AKpHtgpoM
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.
[1] http://www.youtube.com/watch?v=N9AKpHtgpoM
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!
[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.
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.
The problem with cryptography is that you only have to be wrong once.
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?).
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?).
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.
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.
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.
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.
Quantum computing is a threat to RSA, DH, DSA, EDH, and ECDSA, but not to AES.
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.
The question then becomes how you're going to establish an AES key across a public channel without using quantum-vulnerable algorithms.
Presumably, you swap RSA for a code-based cryptosystem; the TLS structure itself could probably remain intact.
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.
McBits is a public key encryption algorithm which should be resistant to attacks by quantum computers: http://binary.cr.yp.to/mcbits.html
AES is not unbreakable, just very hard to break. Schneier in 2009: http://www.schneier.com/blog/archives/2009/07/another_new_ae...
I didn't say AES was "unbreakable"; that's a meaningless term. I said it wasn't threatened by quantum computing.
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.
[deleted]
>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.
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.
I think this can get you into some trouble in the UK, if not the US.
http://en.wikipedia.org/wiki/Key_disclosure_law
http://en.wikipedia.org/wiki/Key_disclosure_law
Oh wow (from the wikipedia article):
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?
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?
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!_)"
"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.
Of course, once you get a notice there's probably nothing you can do.
Probably the same as if you were renting an apartment to a criminal, and you gave him the keys and all the copies.
How would you know he's a criminal?
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).
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:
http://www.cryptolaw.org/
http://www.cryptolaw.org/
That hostname isn't resolving for me at the moment.
$ 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: 51Well, I'm not to worried about trouble in the UK.
> 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?
Doesn't that require getting a CA to re-sign your keys every day?
Yes. The certificate contains a signature of your public key (and other data), which is derived from your private key.
Might be why Google is upgrading all SSL certs to 2048 bit
http://googleonlinesecurity.blogspot.com.au/2013/05/changes-...
http://googleonlinesecurity.blogspot.com.au/2013/05/changes-...
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.
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.
[1] https://en.wikipedia.org/wiki/Server_Name_Indication
[1] https://en.wikipedia.org/wiki/Server_Name_Indication
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/
Apparently we can thank the French: http://www.edelweb.fr/EdelKey/
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)
(Unless porn sites start whitelisting incoming IP addresses, which seems pretty unlikely)
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 :-(.
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.
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?" ;-)
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...
Which is just an argument for starting sooner rather than later, and staying ahead of the curve, rather than giving up the point...
couldn't agree more. was just setting the joke up. :)
"nature will find a way"
brilliant statement. thank you.
brilliant statement. thank you.
Or protocols need to develop that use out of band communication to seed certificates. Just mail me some entropy :)
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.
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.
Can someone explain why we don't get ECDHE on ubuntu 12.04 by default?
On ubuntu 12.04 my apache has:
On ubuntu 12.04 my apache has:
SSLCipherSuite HIGH:MEDIUM:!ADH:!MD5
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
How to do it for yourself: https://news.ycombinator.com/item?id=5171250
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 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.
[1] https://github.com/ioerror/duraconf
[1] https://github.com/ioerror/duraconf
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.
The connection is encrypted using RC4_128,
with SHA1 for message authentication and
RSA as the key exchange mechanism.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.
See my comment in the second link for what I use for nginx. I prefer explicitly stating ciphers to make sure only the ones I want presented are used
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.
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.
(Corroboration: http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-se...)
(Corroboration: http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-se...)
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).
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).
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?
... unless the SSL content contains identifying information. But what percentage would that be in the future?
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.
> 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.
Collect logs from ISP that show IP <-> account. Many ISPs keep these logs around for a long while as it is.
An account is not a person, and thankfully some courts are recognizing that: https://www.techdirt.com/articles/20130218/21462222020/yet-a...
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.
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.
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.
Isn't it a little more complicated than that?
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"…)
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"…)
If I understand properly, having Google's private key only allows you to do MITM attacks, not to passively decrypt traffic using PFS algorithms.
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.)
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.)
> 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.
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.
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.
Thanks for clarifying, that makes sense.
I'm a bit surprised to see duckduckgo.com not using PFS :/ Hopefully they implement it soon.
From https://duck.co/topic/duckduckgo-ssl-not-secure-enough#28469... :
> We're aware and are planning accordingly. Thanks for the heads up, though.
> We're aware and are planning accordingly. Thanks for the heads up, though.
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?
Chrome does it by default, just click on the padlock. Example:
http://i.imgur.com/k1bhh77.png
http://i.imgur.com/k1bhh77.png
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?
Or the NSA could just demand private keys via FISA letter.