Subject: Fwd: The ability to automatically upgrade a reference to HTTPS from HTTP

From: Tim Bray <[email-masked]>
Date: Fri, 22 Aug 2014 12:16:22 -0700

>From TimBL on the public TAG list. Of possible relevance to several WGs
here.
---------- Forwarded message ----------
From: "Tim Berners-Lee" <[email-masked]>
Date: Aug 22, 2014 11:50 AM
Subject: The ability to automatically upgrade a reference to HTTPS from HTTP
To: "Public TAG List" <[email-masked]>
Cc: "SW-forum Web" <[email-masked]>

There is a massive and reasonable push to get everything from HTTP space
into HTTPS.
While this is laudable, the effect on the web as a hypertext system could be
very severe, in that links into http: space will basically break all over
the place.
Basically every link in the HTTP web we are used to breaks.

Here is a proposal, that we need this convention:

         If two URIs differ only in the 's' of 'https:', then they may
never be used for different things.

That's sounds like a double negative way of putting it, but avoids saying
things we don't want to mean.
I don't mean you must always serve up https or always serve up http.
Basically we are saying the 's' isn't a part of the identity of the
resource, it is just a tip.

So if I have successfully retrieved https:x  (for some value of x) and I
have a link to http:x then I can satisfy following the link, by presenting
what I got from https:x.
I know that whatever I get if I do do the GET on the http:x, it can't be
different from what I have.

The opposite however is NOT true, as a page which links to https:x requires
the transaction to be made securely.  Even if I have already looked up
http:x < i can't assume that I can use it for htts:x.  But for reasons of
security alone -- it would still be against the principle if the server did
deliberately serve something different.

This means that if you have built two completely separate web sites in
HTTPS and HTTP space, and you may have used the same path (module the 's')
for different things, then you are in trouble. But who would do that?   I
assume the large search engines know who.

I suppose an exception for human readable pages may be that the http:
version has a warning on it that the user should accessing the https: one.

With linked data pages, where a huge amount of the Linked Open Data cloud
is in http: space last time I looked, systems using URIs for identifiers
need to be able to canonicalize them so tht anything said about http:x
applies equally to https:x.

What this means is that a client given an http:  URL in a reference is
always free to try out the HTTPS, just adding an S, and use result if the
 is successful.
Sometimes, if bowser security prevents a https-origin web page from loading
any http resources as Firefox proudly does, [1], is you are writing a
general purpose web app which has to read arbitrary web resources with XHR,
ironically, you have to serve it over HTTP!     In the mean time, many
client libraries will I assume need to just try HTTPS as that is all they
are allowed.

Or do we have to only build serious internet applications as browser
extensions or native apps?

For this any many related reasons, we need to first get a very high level
principle that if a client switches from http to http of its own accord,
then it can't be given misleading data as a result.

I suspect has been discussed in many fora -- apologies if the issue is
already noted and resolved, and do point to where it has

TimBL

[1]
https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/

In order for this switch to be made, transitions

---

From: Nico Williams <[email-masked]>
Date: Fri, 22 Aug 2014 16:37:13 -0500

On Fri, Aug 22, 2014 at 12:16:22PM -0700, Tim Bray wrote:
> [...]
> [...]

It too late for that though: all too often the two resources are not the
same.

Though a server could advertise that they are the same, but the client
would first have to try HTTPS to find out, increasing latency when the
server doesn't (which would be the common case at first).

IIUC the HTTP/2.0 folks are working on one transport to access both
kinds of resources.  And if we apply the opportunistic security pattern
to this we should be able to get encrypted security (even if often
unauthenticated) when using http URIs.

> extensions or native apps?

I agree with the idea though, that we should apply opportunistic
security when we would otherwise just use plaintext!

> already noted and resolved, and do point to where it has

Please look at the opportunistic security (OS) effort currently under
IETF LC, draft-dukhovni-opportunistic-security.

Nico
--

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 22 Aug 2014 17:49:37 -0400

> security when we would otherwise just use plaintext!

Yes, this was agreed upon during the STRINT workshop in Berlin, without any
argument as I recall.  OS would look like the plaintext version of a
protocol, http in this case, to an end user.

-- 

Best regards,
Kathleen

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 22 Aug 2014 21:55:04 +0000

> server doesn't (which would be the common case at first).

A deeper problem occurs when the HTTP URI includes a port:

    http://example.com:8080/some/path

In that case, what would the https URI be?  The approproach would
work at best for just for 80/443, and not anything else.

I am all too familiar (and annoyed) with https servers that deliver
content that is different from the "corresponding" http resource.
Often these are even software download links from major vendors,
that I would like to retrieve over an encrypted authenticated
channel, but can't.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Fri, 22 Aug 2014 17:02:07 -0500

> work at best for just for 80/443, and not anything else.

Indeed.  Ideally START-TLS would just work (but it doesn't) and not cost
an extra round trip (but it does).

It might be the case that only TCPinc can save us here.

Alternatively we should take the extra latency and pin whether the
server supported START-TLS or not (if not, pin for a few hours, if yes
pin forever).  Not that pinning is free, mind you.

Nico
--

---

From: Eliot Lear <[email-masked]>
Date: Sat, 23 Aug 2014 09:03:55 +0200

> It too late for that though: all too often the two resources are not the

Indeed.  Regrettably I suspect the worst offender would be the index
itself for the site (e.g., http://www.example.com v.
https://www.example.com).

Eliot

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 23 Aug 2014 08:04:30 -0700

> https://www.example.com).

Um? Those look identical to me.

--Paul Hoffman

---

From: Chaitanya D <[email-masked]>
Date: Sat, 23 Aug 2014 21:03:26 +0530

Paul this would not be identical if a shared server hosts multiple sites but serves ssl as a different site. 

Seen this often where the web host's ssl secure billing panel is the only ssl on the box. 

In that case any connection on port 443 by default gets the one ssl site and can result in https vs http being different. And its still a perfectly valid config. 

Chaitanya Dhareshwar
+91 9820760253

-----Original Message-----
From: "Paul Hoffman" <[email-masked]>
Sent: ‎23-‎08-‎2014 20:35
To: "Eliot Lear" <[email-masked]>
Cc: "IETF Discussion" <[email-masked]>
Subject: Re: The ability to automatically upgrade a reference to HTTPS fromHTTP

--Paul Hoffman