Announcing SSL Labs Grading Changes for 2017
blog.qualys.com
blog.qualys.com
I'd also like to see the Handshake Simulation improved by splitting ancient clients out into their own section. Call it Obsolete or Legacy. Populate it with all the clients that don't support ECDHE or TLS 1.2. With that change, people won't feel pressured to support IE6 on Windows XP or other such combos. In the real world, a big majority of TLS 1.0 traffic is either 1) unknown web crawlers that don't matter, or 2) zombies running on ancient hacked machines looking to replicate. It's mostly unwanted traffic.
You might say it does no harm to enable connections to IE6 on Windows XP, but I can think of two reasons why it does: First, enabling more ciphersuites in OpenSSL (or other) increases your attack surface, and as for me, I'm way more interested in reducing my attack surface than in talking to a computer that was last updated in 2001. Second, these XP machines will hang around the Internet so long as they're useful. We cancel the driving priveleges of drunk and senile people, and we should do the same at the protocol level for XP machines.
And anyway, it's incoherent to mark an IE6/XP connection failure in red (which means bad), while simultaneosly saying that SSL3 is bad. Some cruft has built up over the years, and it needs to be periodically removed.
> HSTS preloading required for A+
So, if this vanity metric is important for you, you may want to start thinking about getting yourself added, https://hstspreload.appspot.com
- Must be on the root domain.
- Must redirect HTTP to HTTPS.
We refuse to serve content over HTTP, and thus don't redirect broken clients. Doesn't make sense to penalize people for not being on the list.
I was under the impression there is no theoretical nor practical justification for it.
> What the attacker hopes to find inside the AES attack is a key collision. This means that a key guessed by the attack matches a key chosen by a user. Any particular guessed key has chance only 1/2^128 of matching any particular user key, but the attack ends up merging costs across a batch of 2^40 user keys, amplifying the effectiveness of each guess by a factor 2^40
If the attacker has collected 2^40 instances of some known plaintext, such as "GET / HTTP/1.1\r\n", encrypted under 2^40 unknown AES-128 keys (and it doesn't matter how those keys were generated), then the attacker can generate a key randomly, encrypt the known plaintext under that key, and see if it matches any of the target ciphertexts. The chance of guessing one of the 2^40 keys successfully this way is 1/2^(128-40) = 1/2^88. This means that attacking one of the keys requires far less than the 2^128 operations that one might expect would be required to attack AES-128. DJB argues that this makes AES-128 ill-matched with elliptic curves that provide a 128-bit security level, thus motivating a cipher with 256 bit keys instead, such as AES-256 or ChaCha20.
In practice, the first 32 bits of the GCM nonce used by TLS are derived during the handshake, so the attacker has to do 2^32 more computations (since there are 2^32 different ways a known plaintext could be encrypted with a given key). So perhaps AES-128 is actually fine with TLS. But the point still stands that there is a justification for preferring AES-256 over AES-128.
"Bottom line: 128-bit AES keys are not comparable in security to 255-bit elliptic-curve keys. Is 2²⁵⁵−19 big enough? Yes. Is 128-bit AES safe? Unclear."
The point there is that batching helps the attacker finding the first AES key by a factor of m, m being the number of keys being attacked, but it doesn't really help finding the first ECC key---although it does help with the cost of finding the second, third, etc a bit. So for example, the effective multi-key security of AES-128, given 2^32 different keys (read: sessions), is 2^96.
See for example [1] for a formalization of multi-key security in the symmetric encryption setting.
With random keys (generated via /dev/urandom), you don't need to worry about that.
I know how sometimes weaknesses are found that seem impossible at first but can somehow be improved, but unless something fundamental has changed in the years since that attack did not appear to have any actual significance beyond academics (which is why no one in the industry worried about it). Beyond any efficiency requirements is the basic least-common denominator actor issue: if an attacker can get a key owner (person or machine) to perform that level of arbitrary action, there are much much easier ways to subvert the entire system.
As a symmetric block cipher I suppose being in the habit of AES-256 usage is at least some gesture towards any future attacks by scalable general purpose quantum computers should they appear, since Grover's means it'd still be decent while 128 would drop to 64, though given the generally usage of asymmetric ciphers for initial exchange I don't know if it actually matters at all in the specific instance of the web. But whatever its benefits or downsides I don't think the related key attack makes it worse then AES-128.
That being said, I don't know if I'd agree with anyone suggesting that A256 provides a meaningful increase in practical security over A128. As you said, the main difference is post-quantum and you can't just drop A256 in and say you are ready for post-quantum as you need a more holistic post-quantum solution anyway.
Quantum does affect this, but obviously the implications of quantum are way bigger than your block cipher choice.
DJB pointed out, correctly, that generic attacks against ciphers with 128-bit keys are distressingly close to being practical. Generic attacks against 256-bit ECDHE are wildly impractical. If you want to make it take comparable effort to break the key exchange as it takes to break the cipher, the cipher key needs to be bigger.
Not he didn't.
And 256-bit ECDHE has 128 bits of security.
> And 256-bit ECDHE has 128 bits of security.
Can you give that a meaningful definition? I suspect you mean that it takes ~2^128 operations to break a single target ECDHE exchange. If so, that is both true and completely irrelevant to anything I said.
The key point here is that it does not take anywhere near 2^128 operations before you can decrypt a single AES-128 block out of a large corpus of captured ciphertexts. For that type of attack, 128 bit ciphers offer vastly less security than ECDHE on a 256-bit field.
Imagine that the NSA has collected 2^40 sessions using AES-128 on the internet. Let's imagine that they only want to steal session IDs being sent (if they want to eavesdrop on more data, it will be worse). From burp, I get that a simple GET request to Gmail is 2319 bytes, that's around 144 blocks of AES. Let's say a 100.
So in total, the NSA would have to store 2^40 * 128 * 100 bits, let's say around 2 petabytes.
Also I forgot, let's imagine that the first block of any of these sessions' first message is always the same thing. A GET request to the same address. We got extra lucky!
Now they have to perform 2^88 AES operations for each key guess, and hopefully they will start finding keys at this point. (It's more than all of the computing power of bitcoin btw.). And for each of these AES operations they also have to check in their 2 petabytes corpus for a match (I hope you way to do that).
Let's imagine that the NSA wants to do less computations of AES. They could have stored 2^50 sessions instead! And now they only have to perform 2^78 AES operations.
For this they would have to store around 2 exabytes. In 2010 the whole traffic of internet was estimated to be around 21 exabytes per month. So if the NSA would be to record sessions for a month, they would need to store 10% of the internet hopping that they would also be GET requests to Gmail.
Now we can theorize about the evolution of storage space, and computing power, and ... quantum computer. In which case ECDHE will fall before AES-128 does.
2 petabytes is no big deal for the NSA. Also, why would they store anywhere near this much per session? They can estimate which part of the stream matters and store that part if they want to.
> And for each of these AES operations they also have to check in their 2 petabytes corpus for a match (I hope you way to do that).
Bloom filter plus a large hash table?
The point is that crypto ought to be configured to be secure, with a large margin of error, against an adversary who controls the entire world's computational capacity and is willing to use highly theoretical attacks because achieving this level of security is not particularly difficult. AES-256 satisfies this criterion, as does ECDHE until a quantum computer shows up. AES-128 does not satisfy this criterion even though the existing attacks are barely practical even for a nation-state adversary.
256-bit keys may not even be quite good enough against a batch attack done with a quantum computer because a full Grover's algorithm run against the entire batch runs in ~sqrt(2^bits / batch size). If you assume a batch size of 2^96 (to give a nice margin of error) and you want a work factor of 2^128 for the adversary, that gives 352 bits.
ECDHE is, of course, completely dead once someone builds a quantum computer.
Google Chrome requires SCTs for all EV certificates and for all certificates issued by Symantec-owned CAs and will require it for all certificates issued after October 2017.
Currently the Qualys tester checks for Certificate Transparency, but the grade does not depend on it.
By their nature though CA evaluation and choices are a lot mushier and involve more politics and human factors (witness the recent debates surrounding certificate transparency and how it interacts with internal service usage, vis-a-vis redaction etc). And fundamentally, there are also a lot of powerful, interested actors deeply involved already. Authentication is just a separate domain from the crypto itself, and involves a different set of hairy issues.
An A+ grade should be hard to get, and really mean something.
Yes, you need the other things too, but until you've got full current cryptographic security, you're simply not done in that area.
You seem to think of grades as in 'honorifics' or something. "The best of the crop are assigned an A+ to distinguish them from the rest".
But that's not what we have here. SSL Labs grades aren't "rare". They're a supposed to be a direct result of your TLS deployment practices. Given that everyone should follow best practices, everyone should aim for (and get) an A+ in an ideal world.