6 ms·

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

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:).

nandhp 10y ago
Indeed. Perhaps a better title for this would be "'https://' https://' considered harmful".
- dang 10y ago
  We changed the title to that of the HTML doc, which is clearer.
geofft 10y ago
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:// http:// URLs to https:// https://, accomplishing the goal requested in this article without the security risks of optional/opportunistic encryption.
- dietrichepp 10y ago
  Only after you visit a domain.
  - niftich 10y ago
    Or if you preload with a browser vendor, which in all fairness doesn't scale in its current incarnation.
    - strcat 10y ago
      It's scaling well enough so far. A domain can be submitted at https://hstspreload.appspot.com/ https://hstspreload.appspot.com/ and doesn't take long to show up in Chromium and then other browsers.
      - niftich 10y ago
        [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/http/transport_security_state_static.json https://chromium.googlesource.com/chromium/src/+/master/net/... [2] https://dxr.mozilla.org/comm-central/source/mozilla/security/manager/ssl/nsSTSPreloadList.inc https://dxr.mozilla.org/comm-central/source/mozilla/security...
        icebraining 10y ago
        The page linked above has instructions for removal.
        niftich 10y ago
        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_ 10y ago
        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 10y ago
        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 10y ago

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

dang 10y ago
We changed the title to that of the HTML doc, which is clearer.

geofft 10y ago

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:// http:// URLs to https:// https://, accomplishing the goal requested in this article without the security risks of optional/opportunistic encryption.

dietrichepp 10y ago
Only after you visit a domain.
- niftich 10y ago
  Or if you preload with a browser vendor, which in all fairness doesn't scale in its current incarnation.
  - strcat 10y ago
    It's scaling well enough so far. A domain can be submitted at https://hstspreload.appspot.com/ https://hstspreload.appspot.com/ and doesn't take long to show up in Chromium and then other browsers.
    - niftich 10y ago
      [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/http/transport_security_state_static.json https://chromium.googlesource.com/chromium/src/+/master/net/... [2] https://dxr.mozilla.org/comm-central/source/mozilla/security/manager/ssl/nsSTSPreloadList.inc https://dxr.mozilla.org/comm-central/source/mozilla/security...
      - icebraining 10y ago
        The page linked above has instructions for removal.
        niftich 10y ago
        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_ 10y ago
      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 10y ago
        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.