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

[niftich]

Yes, the submission site talks about removal, and how it takes until the next major release of the browser for the changes to appear in the codebase, and every user will have to upgrade to pick up the changes.

If it were a HSTS preload registry service and API, that'd be different, but it's not.

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