NSS:upgradeToHTTPS: Difference between revisions

no edit summary
mNo edit summary
No edit summary
 
Line 10: Line 10:
In particular:
In particular:


- They may have a certificate which is not acceptable to some clients.
* 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 mixed content which will cause the site to break.
- They may have explicit "http://" links on their page that would
* 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.]
  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
It would be nice to have a mechanism that would allow smoother
Line 27: Line 25:
At a high-level, here's what I think we want:
At a high-level, here's what I think we want:


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


I think the last of thease is especially critical. If there's some
I think the last of thease is especially critical. If there's some
Line 43: Line 41:
some of the ones I have heard:
some of the ones I have heard:


- Redirect to HTTPS (potentially with HSTS to pin it down permanently)
* Redirect to HTTPS (potentially with HSTS to pin it down permanently)
- A new header with some semantics stronger than Alternate-Protocol, e.g.,
* A new header with some semantics stronger than Alternate-Protocol, e.g.,
  - Do authenticated HTTP over TLS but with an http:// origin
** Do authenticated HTTP over TLS but with an http:// origin
  - Do HTTP over TLS but with all the checks (certs, mixed content,
** Do HTTP over TLS but with all the checks (certs, mixed content, etc.) merely in a reporting mode.
    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").
  - An "opportunistic" upgrade mode in which the client would
** 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.
    try to connect to the server with HTTPS semantics and if so
* More than one of these in concert
    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.
I'm still up in the air about what the best approach is here.
Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925

edits