
Announcing SSL Labs Grading Changes for 2017 - QUFB
https://blog.qualys.com/ssllabs/2016/11/16/announcing-ssl-labs-grading-changes-for-2017
======
Panino
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.

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

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

~~~
yuhong
[https://dev.ssllabs.com/](https://dev.ssllabs.com/)

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

~~~
ivanr
If your servers are all public, you can use the (also free) SSL Labs API:
[https://www.ssllabs.com/projects/ssllabs-
apis/](https://www.ssllabs.com/projects/ssllabs-apis/)

~~~
mattbillenstein
Sweet -- next best thing -- thanks! !

------
josho
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](https://hstspreload.appspot.com)

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

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

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

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

~~~
meta_AU
I didn't mean to suggest that A256 was worse than A128 (though I see how it
would read that way). I was just trying to point out that things are more
complicated than comparing two numbers.

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.

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

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

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

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

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

~~~
mkj
What's an example of something they could add that would make A+ harder to
get, and also add meaningful security?

