W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Trusted proxy UI strawman

From: Martin Nilsson <nilsson@opera.com>
Date: Sun, 15 Jun 2014 23:48:24 +0200
To: ietf-http-wg@w3.org, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
Message-ID: <op.xhimuyaoiw9drz@beryllium.bredbandsbolaget.se>
On Sun, 15 Jun 2014 23:09:40 +0200, Stephen Farrell  
<stephen.farrell@cs.tcd.ie> wrote:

>> There are a lot
>> of root certificates installed on the client side to facilitate
>> MITM-TLS-proxies. This is not good.
> I would characterise the problem differently. There is no
> HTTP proxy solution that has been adopted for the few (or
> maybe even only one) real use-cases for policy checking of
> TLS secured sessions.
>> The TLS aims to make communication with the highest degree of
>> confidenitality and integrity possible. That is good. Unfortunately it
>> is entirely binary,
> That is not correct. There are many independent parameters
> affecting TLS and literally hundreds (unfortunately) of
> ciphersuites with different properties, and in fact some of
> which do offer NULL confidentiality.

Having worked on a TLS implementation for the past year, I'm well aware of  
the richness of TLS parameters. They are however not available to the  
intermediary to modify, which is good. Even if they could modify them, it  
would essentially only be enable or disable encryption, which is too  
coarse control. Most policy enforcement doesn't need to see actual  
content, for example, or even URL. Well defined normalized URL hash is  

>> so if an intermediary wants to do anything with the
>> traffic, block specific URLs or add additional headers, it has to drop
>> the security to zero.
> See above. And "drop security to zero" is a meaningless
> phrase.

Underspecified at least. Block TLS traffic (or degrade it so users avoid  
TLS), doing MITM with private root certificate or explicitly MITM  
regardless of client certificates where the options I had in mind.

> Frankly, I think analysis such as yours above is very
> obviously not a sound basis on which to propose significant
> changes.

Calling it analysis is a bit of a stretch, so I think we agree. I aim to  
provide analysis in this direction though.

/Martin Nilsson

Using Opera's mail client: http://www.opera.com/mail/
Received on Sunday, 15 June 2014 21:48:56 UTC

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