Announcing SSL Labs Grading Changes for 2017

https://blog.qualys.com/ssllabs/2016/11/16/announcing-ssl-labs-grading-changes-for-2017

by QUFB • 10 years ago

122 47 10 years ago

blog.qualys.com

gcp2• 10 years ago

What's the feeling on them preferring 256-bit AES over 128-bit AES?

I was under the impression there is no theoretical nor practical justification for it.

agwa4• 10 years ago

Batch attacks: https://blog.cr.yp.to/20151120-batchattacks.html

tptacek6• 10 years ago

How is this attack meaningful with the random AES keys generated by the TLS KDF?

meta_AU3• 10 years ago

From memory there is a related key attack on AES256 with complexity 2^99. So in that regard AES128 is more secure than AES256.

gcp2• 10 years ago

That's exactly what I mean by the lack of theoretical justification for their grading.

CiPHPerCoder• 10 years ago

The related key attack is only really relevant if you're using the AES internals to construct, say, a hash function.

With random keys (generated via /dev/urandom), you don't need to worry about that.

xoa2• 10 years ago

Someone who knows more correct me if I wrong, but my recollection is that the AES256/192 related key attack presented by Alex Biryukov and Dmitry Khovratovich (assuming that's what you're referring to) was seriously, seriously theoretical. Like, for real. Performing it required somehow getting the owner of the targeted key (K1) to use a specific derivation algorithm to derive 3 other keys from K1, then get the owner to perform encryption/decryption operations of the attacker's choosing using all 4 keys on up to 2^99.5 16-byte blocks, THEN the attacker uses ridiculous amounts of storage to to finish, I can't remember exactly how big but multiple exabytes of storage big.

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.

tptacek6• 10 years ago

I think it's a bit silly to demand 256 bit security from your bulk cipher but only 128 bit security from your key exchange.

Quantum does affect this, but obviously the implications of quantum are way bigger than your block cipher choice.

amluto3• 10 years ago

Talking about "128 bits" security is meaningless.

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.

ivanr3• 10 years ago

I should have fixed that a long time ago and I apologise that I haven't yet. But I will! At the moment, sites with "too strong" security (e.g., 4096-bit RSA, 4096-bit DH, etc) are still rewarded for it, but they shouldn't be.

kseistrup3• 10 years ago

It would be nice with an SSL Labs Beta site that let you test your site(s) according to the upcoming grading rules.

yuhong• 10 years ago

https://dev.ssllabs.com/

kseistrup3• 10 years ago

Thanks for the link! I'm not sure it does thing differently, though. I'll have to check it again later.

mattbillenstein2• 10 years ago

And what would be really really rad would be open-sourcing the toolkit that makes these checks possible -- I'd like to plug something like that into periodic checks in nagios or something.

ivanr3• 10 years ago

Indeed, a couple of people have asked for that already. I will try to make that happen. Edit: The development site is already used for the testing of new versions before they are deployed to production, but with the new grading perhaps we can make the testing period longer and tell people about it. I believe the grading is currently the same on both servers.

kseistrup3• 10 years ago

Sounds really good!! :)

meta_AU3• 10 years ago

I like how informal systems like this drive feature development in reverse proxies. Nginx has great support for automated OSCP now, but I wonder if that would have come to pass without some group saying it is important and giving it a (somewhat arbitrary) rating.

wolf550e• 10 years ago

Why does the grade not depend on presence of Certificate Transparency Signed Certificate Timestamp for the certificate, either embedded in the certificate or provided by TLS extension?

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.

tptacek6• 10 years ago

That would be a grade at how well your site contributes to the ecosystem, but not as much how safe your particular site was.

xoa2• 10 years ago

It may just be that they're waiting on more consensus from browser/OS makers and will take a stronger look at this next year as Chrome's (and perhaps Firefox/Safari/IE by that point) general SCT deadline approaches. That said, honest question: are certificate authentication questions really within the strict scope of their focus on SSL? The items they grade is pretty bread-and-butter technical compliance and best practices stuff, within the direct control of a single party (the server owner) and independent of any others. It's pretty unambiguous despite any difficult subject choices that may arise from old infrastructure/client issues. Further, there's also the fact that in all this SSL Labs has grown to fill an important unfilled niche in evaluation.

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.

Panino• 10 years ago

All good changes.

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.

josho• 10 years ago

Everyone should note that they intend the following change:

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

captn3m0• 10 years ago

The preload pre-conditions are what stops us from considering it:

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

bradknowles2• 10 years ago

With respect, I disagree that anyone should make it easier to get an A+ rating. That really should be reserved for the best of the best, where a site implements all current best practices and avoids all current weaknesses.

An A+ grade should be hard to get, and really mean something.

mkj2• 10 years ago

No, sites would be better off spending that extra effort on non-cryptographic security like protecting their DNS registration, internal spearphishing, etc.

bradknowles2• 10 years ago

IMO, full cryptographic security should be the baseline.

Yes, you need the other things too, but until you've got full current cryptographic security, you're simply not done in that area.

darklajid• 10 years ago

No, it shouldn't be hard to get and it already does mean something.

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.

Announcing SSL Labs Grading Changes for 2017

Related Stories