Re: STARTTLS for HTTP (both versions)

That's where HTTP Upgrade to TLS (RFC 2817) comes in. Although not widely implemented for the web due to apparent issues with proxies, it has been used for IPP (which uses HTTP/HTTPS) for 15+ years.

Sent from my iPad

> On Aug 27, 2015, at 5:08 AM, Maxthon Chan <xcvista@me.com> wrote:
> 
> 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
>

Received on Thursday, 27 August 2015 10:17:06 UTC