Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
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 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 | 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 | |||
* 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 | 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) | |||
* 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. | I'm still up in the air about what the best approach is here. |