Re: STARTTLS for HTTP (both versions)

Under heavy server load and high connection count every saved handshake adds up to the total saved traffic, which in turn amounts to $$$. Also the Upgrade: STARTTLS response itself can be smaller.

The behaviour of Upgrade: STARTTLS on the client side is that the client upgrades to HTTPS and send the same request again. This means that a HTTPS-only server do not need to implement HTTP at all - whenever a connection is not started with a TLS handshake, a static Upgrade: STARTTLS response can be send back immediately, usually before even finish reading the request.

> On Aug 27, 2015, at 17:48, Cory Benfield <cory@lukasa.co.uk> wrote:
> 
> On 27 August 2015 at 10:08, Maxthon Chan <xcvista@me.com> wrote:
>> 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.
> 
> The server is clearly not HTTPS-only, because it can speak enough
> plaintext HTTP to send the 4XX back with the Upgrade header. Given
> that it can do that, it can clearly speak enough plaintext HTTP to
> send the 301 with Location header. As far as I can see the only
> advantage this extra header has is that it saves a TCP handshake.
>