Re: STARTTLS for HTTP (both versions)

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