Your proposal does not solve my second scenario, which I will describe in detail here. Let’s say a software package, for example VMware vSphere, includes a HTTPS-only server, listening on port 5443. Usually to access the said software package you type this into the browser’s address bar: https://vsphere.example.org:5443/. What if you accidentally dropped the ‘s’ in ‘https’? It would be PITA to add the s between http and the colon if the user does not have a mouse, which is very, very common now. This is why among the two use cases of "Upgrade: STARTTLS” I suggested included not only a jump, but also in-place TLS handshake. The in-place handshake happens in the same TCP connection, immediately following the receiving of a response (with a 4xx status code) that contains this Upgrade: STARTTLS header. With in-place Upgrade: STARTTLS such scenarios can be avoided. Also, a Upgrade: STARTTLS of any type implies a Strict-Transport-Security. > On Aug 27, 2015, at 16:43, Cory Benfield <cory@lukasa.co.uk> wrote: > > On 27 August 2015 at 06:34, Maxthon Chan <xcvista@me.com> wrote: >> Hello List. >> >> This idea may have appeared here, but I think it still worth some consideration. >> >> From time to time a website author may want to tell the browser (and user) that their website prefers (or can only be accessed through) HTTPS for connection. Currently this requires server-side rewrite voodoo which requires quite complex configuration on the server. Also there are scenario that a user accidentally access HTTPS site with HTTP requests. >> >> Here I suggest, by using the Upgrade header, to implement some kind of STARTTLS so: >> >> 1) the web browser can know and cache the fact that the site prefers HTTPS over HTTP, >> 2) The accidental HTTP access on HTTPS port can be redirected properly. > > This already exists in a different form for HTTP. > > The solution to part 1 is the HTTP Strict Transport Security > header[0]. This header instructs a user agent to only access a given > site over HTTPS. > > The solution to part 2 is server configuration. Almost all web servers > provide you with configuration that will allow you to respond to all > HTTP requests with a HSTS header and a redirect to the HTTPS > equivalent of the URL. This configuration is rarely particularly > tricky. For example, nginx allows it to be configured very easily: > > server { > listen 80; > > location / { > return 301 https://$host$request_uri; > } > } > > server { > listen 443; > > add_header Strict-Transport-Security "max-age=31536000; includeSubdomains"; > > location / { > # Whatever config is required > } > } > > > It is not clear to me that the Upgrade header proposed provides any > benefit. It is, however, clear to me that this use of the Upgrade > header is unlike the expected uses of the upgrade header, and so would > be a bad idea even if it did provide any benefit. > > [0]: http://tools.ietf.org/html/rfc6797
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:46 UTC