Subject: Pseudo end-to-end connections considered harmful

From: Roland Zink <[email-masked]>
Date: Thu, 24 Jul 2014 15:22:44 +0200

Accessing web sites through TLS gives the feeling of just talking to 
this site. The retrieved HTML content however cause the browser to open 
more connections for subresources of the displayed page, e.g. there are 
multiple endpoints and third parties are involved. It is known that in 
some countries it is possible for intelligence agencies to get access to 
the data after decryption has been done. If encryption is done to 
provide real end to end security then the use of any third party 
subresource must be avoided in order to not violate the users privacies 
concerns. For example an intelligence agency can surveil who is browsing 
where by just using some tracking companies data including the referer 
header data, ever cookies and other tracking data.

When a http2 browser is using TLS then it should use a single end-to-end 
connection and refrain from open any further connections. The server is 
the endpoint and is therefore not allowed to forward the request. Any 
proxy / gateway must mark responses with a via header and http2 clients 
using a TLS connection must close the connection if they discover such a 
via header.

Roland

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Jul 2014 07:11:17 -0700

On 24 July 2014 06:22, Roland Zink <[email-masked]> wrote:
> connection and refrain from open any further connections. The server is the
> endpoint and is therefore not allowed to forward the request. Any proxy /
> gateway must mark responses with a via header and http2 clients using a TLS
> connection must close the connection if they discover such a via header.

I think that there are other solutions that stand a better chance of
achieving the goal:

http://www.w3.org/TR/SRI/

---

From: Roland Zink <[email-masked]>
Date: Thu, 24 Jul 2014 16:16:42 +0200

I think this solves a different goal.

Roland

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 25 Jul 2014 02:47:13 +1200

On 25/07/2014 1:22 a.m., Roland Zink wrote:
> this site.

Such feeling is an illusion. Human estimations about security and safety
are notoriously inaccurate.

It is often the case that http:// traffic going to a local proxy which
encrypts using only the latest most secure TLS 1.2 ciphers is far better
for safety than the browser itself connecting https:// directly with
silent fallback to outdated TLS or even SSL encryption.

> The retrieved HTML content however cause the browser to open

Which requirement to add Via exists in RFC2616 and is already soundly
ignored by the intelligence community middelware causing risk.

The only thing this advice will do is break end-user middleware
providing useful and non-harmful protection. Users AV or adware
protection, corporate TLS tunnel proxies, ISP based AV proxy, content
provider CDN TLS gateway, and such like.

Also, please do not confuse TLS and HTTPS.
 - Any agent using *TLS* should expect the connection to the server it
is connecting to be secure. Hops beyond that server are not relevant and
offer no guarantee of security.
 - Any agent using *HTTPS* should expect end-to-end security even if
that connection goes via several proxy hops.

Amos

---

From: Roland Zink <[email-masked]>
Date: Thu, 24 Jul 2014 13:13:17 -0400

> Am 24.07.2014 um 10:47 schrieb Amos Jeffries <[email-masked]>:
> 
:)

> ignored by the intelligence community middelware causing risk.
Exactly

> that connection goes via several proxy hops.
To be more exact I should have used https.

---

From: "Richard Wheeldon (rwheeldo)" <[email-masked]>
Date: Mon, 28 Jul 2014 08:41:34 +0000

From: Amos Jeffries [mailto:[email-masked]] 
 > Which requirement to add Via exists in RFC2616 and is already soundly ignored by the intelligence community middelware causing risk.

We do add Via and XFF on the requests of an inspected / MITM HTTPS transaction. They tend to get largely ignored - the most irritating being when that IP is used for:
- Authentication
- Country / location lookup
- Checking consistency between HTTP and HTTPS transaction sources.

I won't argue that any of these are good uses for an IP address - but they are all examples where I've seen XFF working on HTTP but being ignored when on HTTPS. I can't comment about Via since the browser's treatment of it rarely makes any difference to us as a proxy. The fact that we can't put this information on an HTTPS request at all without doing MITM is a source of even greater frustration.

 > The only thing this advice will do is break end-user middleware providing useful and non-harmful protection.
 > Users AV or adware protection, corporate TLS tunnel proxies, ISP based AV proxy, content provider CDN TLS gateway, and such like.

Yup. +1 to this.

Richard