[Feature request] HSTS Preload about ssllabs-scan HOT 16 CLOSED

I like the idea too!

I think that's the old home of that list though. If I'm not mistaken, currently the master list is found here:
https://chromium.googlesource.com/chromium/src/+/master/net/http/transport_security_state_static.json

from ssllabs-scan.

I don't think it really needs a flag for the Firefox/Chrome list, but i'm in favour of a better separation of HSTS (like if includes subdomains, or if is configured for preloading).

Also, would like to see if Firefox/Chrome list will be the better way to do this when more and more domains are in HTTPS and preloading with HSTS header.

from ssllabs-scan.

AFAIK the "preload" keyword is not standardized, it's just to verify, that you are authorized to publish the domain to the HSTS list:
"Note that the preload flag in the HSTS header is required to confirm and authenticate your submission to the preload list." - https://hstspreload.appspot.com/

And also if a client sent the first (unsecured) request to the sever, he won't know that the server uses HSTS, because he never seen header before. The server has to tell the client, that he should use HSTS and that's the risk.
So a client side list of HSTS supported servers fix this. Of course this could affect performance, but IMHO security is more important.

from ssllabs-scan.

Yes you're right! After investigating a little, a good explaination why preload is a security issue:
«However, when connecting to an HSTS host for the first time, the browser won’t know whether or not to use a secure connection, because it has never received an HSTS header from that host. Consequently, an active network attacker could prevent the browser from ever connecting securely (and even worse, the user may never realize something is amiss). To mitigate this attack, we have added to Firefox a list of hosts that want HSTS enforced by default. When a user connects to one of these hosts for the first time, the browser will know that it must use a secure connection. If a network attacker prevents secure connections to the server, the browser will not attempt to connect over an insecure protocol, thus maintaining the user’s security.»
Source: https://blog.mozilla.org/security/2012/11/01/preloading-hsts/

So now i agree with you! Since is a security issue should be in the test.

But really don't know if a manual list is the better way to do this. Maybe browsers should first try to connect through HTTPS, but i'm sure that way their performance would decrease, so is a field for better exploration in the future. Just guessing, another way i think this could be done would be with a HSTS DNS TXT record instead of a HTTP header, but just guessing don't really know the consequences of that.

from ssllabs-scan.

HSTS preload list from Mozilla: https://dxr.mozilla.org/mozilla-central/source/security/manager/boot/src/nsSTSPreloadList.inc

from ssllabs-scan.

I'm looking into automating Chrome preload list checking using the API. The main conditions are:

• The conditions specified at hstspreload.appspot.com

In addition, we look at the SSL Labs report manually for every page and sanity check for major errors, or for issues that could affect Chrome users:

• The www. subdomain must work, since some people may visit it automatically (prefixDelegation: True in the SSL Labs API)
• The chain is not incomplete, because that will break in old versions of Android (chain.issues has bit 2 set)
• The site works with something other than ECDSA, because that doesn't work on Windows XP.

However, we don't currently use the preload list to enforce HTTPS best practices.

To see the processing that Mozilla does on top of our list, see security/manager/tools/getHSTSPreloadList.js.

from ssllabs-scan.

---> The www. subdomain must work, since some people may visit it automatically (prefixDelegation: True in the SSL Labs API)

Huh? I always delete WWW prefix from DNS, and I hate when a CA adds WWW prefix to SANs without my permission. When a site redirects to WWW, I always feel sad, even though it is valid for Google, Facebook, SSL Labs… The dumbest thing I can imagine is WWW subdomain.

Why WWW is stupid: http://erikras.com/2012/01/19/why-www-is-stupid/

When requesting a certificate from StartCom, i have to add a subdomain, and I add "secure". I don't need it, but at least my certificate is not valid for WWW.

---> The chain is not incomplete, because that will break in old versions of Android (chain.issues has bit 2 set)

Mozilla Firefox also, because it is smart enough not to download an intermediate from an AIA-server. Sites have incomplete chains because Internet Explorer and Google Chrome allow this crap.

---> The site works with something other than ECDSA, because that doesn't work on Windows XP.

If your site uses SNI, it is essential for a default HTTPS-host to have an ECDSA certificate. If a default host uses RSA, this is a security problem, because non-SNI clients clients are allowed, thus getting a certificate mismatch. After a user ignores a warning, a connection is encrypted and authenticated using a default RSA key pair, not yours. If a default host uses ECDSA, non-SNI clients receive handshake failure because of no cipher overlap.

Default uses RSA:

Default uses ECDSA:

It is also essential for an SNI-server NOT to be compatible with SSL 2 handshakes. More info here: https://community.qualys.com/thread/14525

from ssllabs-scan.

Feature request +1 👍

from ssllabs-scan.

+1 for this feature.
If I check for instance mail.google.com, it shows no HSTS support, but almost all google sites are in the HSTS preload list, see:
https://www.ssllabs.com/ssltest/analyze.html?d=mail.google.com
https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json

from ssllabs-scan.

Sites from Google, Facebook, Twitter, Microsoft, Yahoo! etc. have special privileges.
From my side, we don't have to mark them as preloaded. We could place a note instead to clarify.

from ssllabs-scan.

Implemented in 1.20.12, now running on dev.ssllabs.com.

from ssllabs-scan.

I've just checked mail.google.com on dev - HSTS preload is properly detected, but the green bar is not shown in the Summary box. This is probably bug, not by design?
https://dev.ssllabs.com/ssltest/analyze.html?d=mail.google.com&s=216.58.216.101&hideResults=on&latest

from ssllabs-scan.

I don't think so. You get a green bar is you set the HSTS header, which mail.google.com is not doing.
Maybe you could (at some point) get a green bar if you're preloaded in all major browsers, but we're still lacking a check for Safari and IE.

from ssllabs-scan.

I checked a few domains that are not in the Chromium HSTS preload list and SSL Labs reports that they are added.

E.g., bankofamerica.com

I'm looking at https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json for the Chromium HSTS list.

from ssllabs-scan.

Sorry, the UI needs some work. If it's grey, the hostname is not preloaded; if it's green, it is.

from ssllabs-scan.

Got it, thanks.

from ssllabs-scan.