NSS:upgradeToHTTPS

From MozillaWiki
Jump to: navigation, search

The problem statement I'm interested in solving is how to help sites gradually transition from insecure communications modes to secure communications modes. The two endpoints here are obviously "HTTP" (i.e., HTTP over an insecure transport) and "HTTPS" (i.e., HTTP over TLS with full certificate and domain name checking).

Consider the case of a site which is currently running HTTP and wants to change to HTTPS. They could just redirect everyone to an HTTPS version of their site, but if they do, a lot of things can break. In particular:

  • They may have a certificate which is not acceptable to some clients.
  • They may have mixed content which will cause the site to break.
  • They may have explicit "http://" links on their page that would break if they turned off http. [This is especially an issue if they want to use HSTS.]

It would be nice to have a mechanism that would allow smoother upgrade. SPDY's Alternate-Protocol mechanism is one such mechanism in that it allows upgrade to unauthenticated TLS, but it would be nice to have something that let us get further up the security ladder (eventually to authenticated HTTPS), as well as perhaps something that didn't rely on doing SPDY (since we're trying to lower entry barrier and obviously doing SPDY is more work than not doing SPDY).

At a high-level, here's what I think we want:

  • A path to upgrade eventually to full HTTPS
  • Easy for server admins to deploy
  • Safe for server admins to deploy

I think the last of thease is especially critical. If there's some change that server admins can make but that breaks 1% of clients, that's not something they are going to do.

As indicated above, Alternate Protocol satisfies the last two of these, but doesn't get us all the way to HTTPS and depends on SPDY. So I think it's part of the equation but not the whole thing.

There are a lot of ideas floating around in this space. Here are some of the ones I have heard:

  • Redirect to HTTPS (potentially with HSTS to pin it down permanently)
  • A new header with some semantics stronger than Alternate-Protocol, e.g.,
    • Do authenticated HTTP over TLS but with an http:// origin
    • Do HTTP over TLS but with all the checks (certs, mixed content, etc.) merely in a reporting mode.
    • An "opportunistic" upgrade mode in which the client would try to connect to the server with HTTPS semantics and if so pin it in place but otherwise stick with HTTP ("work" seems tricky here").
    • A header which indicates "please connect to me with HTTP over TLS and enforce the following checks but not others", with the idea that you would gradually ask for more and more checks and end up at HTTPS.
  • More than one of these in concert

I'm still up in the air about what the best approach is here.

What I'm hoping to get out of this discussion is some sense of:

  1. Whether something like this is worth doing?
  2. What are the most promising avenues?
  3. What are the steps to make progress?