Hi, On Fri, 30 Jun 2017 15:24:10 +0100 Ivan Ristic <[email protected]> wrote:
> Here's my new blog post about where the grading is heading: > > > https://blog.qualys.com/misc/2017/06/30/ssl-labs-grading-redesign-preview-1 > > Happy to discuss here, but you can also leave comments on the document > itself. I skimmed through it. I'm happy that you'll finally make HSTS an "A" requirement. I think you announced this quite a while ago and I feel HSTS should get some push. Minor thing about A: I would suggest that AEADs should also become an "A" requirement. You're already requiring TLS 1.2 for an "A" and there isn't much else than AEADs that makes 1.2 safer than 1.1. Looking at the requirements for "A+" I feel you're increasing the requirements quite a bit, and I'm wondering if you aren't increasing them to insane levels and also including quite controversial requirements. To sum up for an A+ one would need among other things: * TLS 1.3 * CAA * OCSP stapling and muststaple * CT and Expect-CT * DANE * CSP Each of these is nontrivial. With CAA I see the least problems, TLS 1.3 is a good requirement once it's final and available in mainstream software (aka "when most software works with openssl 1.1"), which will hopefully happen within months. OCSP stapling and muststaple: This one is much more problematic. As many people have pointed out the stapling implementations of the major web servers nginx and apache are more or less broken. They tend to not reliably cache and refetch OCSP responses and if one is using one of those you seriously have to consider the possibility that stapling will fail from time to time, particularly when upstream OCSP servers are unavailable. Combine that with muststaple and it becomes a recipe for troube. I recently had some discussions with the apache devs and I'm mildly optimistic that at least for the apache side we'll see some improvement. But until that has happened (and also happens for nginx) this is problematic. If you require muststaple you may end up pushing people to use it who really shouldn't use it, because their server software isn't up for the task. CT/Expect-CT: Right now deploying CT often means doing arcane server configuration things to bundle SCTs in the TLS handshake. Over the medium term this requirement will cease, because hopefully all CAs will bundle SCTs in Certs, but we're not there yet. Particularly Let's Encrypt doesn't bundle SCTs in Certs. Not sure there is really a point in trying to push people to deploy an intermediate solution that will go away anyway. Similar are my concerns about Expect-CT. I feel that's a bit a result of "secure header inflation". On the long term CT will be required anyway, so I'm not sure we need an extra header for it. DANE: I'm not sure I should even start here... It's well known that DNSSEC is highly controversial and many people don't think it has a role in the future of TLS security. No major browser and no major Internet player is behind DANE at the moment. CSP: Here I'm not entirely sure I understand the requirement. It says "Mixed content mitigated via CSP" Now you can use CSP to mitigate mixed content, but you don't have to. HSTS already does it. Wouldn't HSTS already kinda fulfil this requirement? I think CSP is a nice and underapprechiated feature, but I'm not sure it belongs into the TLS space. -- Hanno Böck https://hboeck.de/ mail/jabber: [email protected] GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ ssllabs-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ssllabs-discuss
