[lifthrasiir]

Just in case, note that it is not against "TLS Everywhere", just against the separation of http: and https: schemes in the URI. TBL essentially argues that http: should upgrade to TLS without any change in the URI (I think that this also implies that, when TLS deployment is finally universal, http: should equal to today's https:).

[geofft]

If you set HTTP Strict Transport Security (which any site that believes it will continue to competently run SSL can and should do), it will implicitly upgrade all http:// URLs to https://, accomplishing the goal requested in this article without the security risks of optional/opportunistic encryption.

[dietrichepp]

Only after you visit a domain.

[niftich]

Or if you preload with a browser vendor, which in all fairness doesn't scale in its current incarnation.

[strcat]

It's scaling well enough so far. A domain can be submitted at https://hstspreload.appspot.com/ and doesn't take long to show up in Chromium and then other browsers.

[niftich]

[a] If the ownership for the site's domain changes, how does the new owner undo the previous owner's preload?

[b] Is the only way to obtain the full preload list to extract it out of Chromium or Firefox source code? [1][2]

[1] https://chromium.googlesource.com/chromium/src/+/master/net/...

[2] https://dxr.mozilla.org/comm-central/source/mozilla/security...

[icebraining]

The page linked above has instructions for removal.

[Matt3o12_]

No it doesn't. You cannot preload every of the Internet, i event doubt you could load 5% of al domain names.

With this approach we can have it for big sites, or important sites but we want it everywhere.

[geofft]

As of April, Let's Encrypt had issued 2 million certificates. Assuming that each domain is about 10 bytes long, that there's no compression (not even includeSubdomains=true, which is a conservative assumption because LE doesn't do wildcards), and that each domain is active, on the public internet, and wants HSTS, that's 20 megabytes of data. That's a lot of data, yes, but it's smaller than the Chrome or Firefox installer. Even if you account for other CAs, that's still the same order of magnitude as the browser itself. So it's not unreasonable for this data to be delivered as part of the initial browser download, and for updates to be delivered as part of browser automatic updates.

There's no sense in which you "cannot" preload every site with an SSL certificate. You absolutely can, and it would work totally fine. We can talk about whether there are better designs, but preloading everything is definitely a realistic option.

It's also an option that works today. If we figure out a better solution in the future (DNSSEC? Bloom filters and OCSP responders?), we can seamlessly transition the current preload list to it, but we're also getting the security advantage of the preload list immediately.

[nandhp]

Indeed. Perhaps a better title for this would be "'https://' considered harmful".

[dang]

We changed the title to that of the HTML doc, which is clearer.