Re: Trusted proxy UI strawman

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  
sufficient.

>> 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