W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2015

Re: STARTTLS for HTTP (both versions)

From: Cory Benfield <cory@lukasa.co.uk>
Date: Thu, 27 Aug 2015 10:48:05 +0100
Message-ID: <CAH_hAJH_NCEjAu6vDXiUaMmy4nSC2aULcppB-4iU2+b1KdfHkg@mail.gmail.com>
To: Maxthon Chan <xcvista@me.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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.
Received on Thursday, 27 August 2015 09:48:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:46 UTC