Re: Semantics of HTTPS

On 07.08.2012 10:12, Stephen Farrell wrote:
> Hi Willy,
>
> On 08/06/2012 10:41 PM, Willy Tarreau wrote:
>> Hi Stephen,
>>
>> On Mon, Aug 06, 2012 at 10:33:26PM +0100, Stephen Farrell wrote:
>>>> At the moment the state of affairs has created MITM proxies and 
>>>> we'd better
>>>> get rid of them by offering a solution to the problem they try to 
>>>> solve.
>>>
>>> The tls WG was offered that option again last week and rejected it
>>> again. If the httpbis WG want to standardise some kind of mitm 
>>> without
>>> changing TLS then that seems to re-define https to me at least.
>>>
>>> Even though mitm hacks exist and people pay for them, the IETF has
>>> actively and repeatedly refused to standardise that behaviour.
>>
>> I'm not advocating MITM, quite the opposite : I'm advocating valid
>> use of proxies via opt-in to put an end to MITM.
>
> I think that depends on how you define MITM. From the point of
> view of a site, or a user forced into using this, your approach
> still seems like a MITM, just a different one, but still a
> re-definition of https I think.

Its more visible. The user gains the ability to see it happening, and 
to complain.

Today those rights are just words on a piece of paper describing some 
fantasy land that does not exist. Recalls marks assumption that he 
*knew* CONNECT provided end-to-end security. Mark you live in .au still? 
then your CONNECT is being decrypted. .cn, .sa, .in. .us, rq? same.


>
>> The end user chooses in his browser :
>>
>>     Proxy Connection for HTTPS :
>>         [ ] proxy may inspect contents fetched over HTTPS  (GET 
>> https://)
>>             except for those sites : _______________
>
> Does that whitelisting approach break TLS client auth and channel
> binding? I guess we'd need to see a draft to know but regardless of
> the fact that those are not very widely used, re-defining https
> like this in a way that breaks those features seems like a bad
> plan.

Client auth where? to the end-server? or to the trusted proxy? or to 
some MITM?
  MITM today forge the certs relayed.

I see no reason why these properties could not be legitimately relayed 
by a trusted proxy using standardised mandatory secure mechanisms. Yes 
it will require coordination with TLS people to ensure its done right. 
Which is a bit more than any MITM implementation can say today.

>
>>         [ ] proxy may not inspect contents fetched over HTTPS  
>> (CONNECT)
>
> With what default? I'd bet there are many wrinkles here. What about
> use of SNI in TLS to select between hosts?

SNI is a big security hole in TLS which enables MITM to operate more 
silently (traffic sniff the SNI detail and forge the certs to there).

The tabled proposal for https:// to explicit proxy erases the need for 
that mess. the absolute-URL and/or Host header contains the details SNI 
would have contained.
  * Allowing the browser to connect over TLS secured without the SNI 
loophole to a trusted proxy.
  * Allowing cert verification to be concentrated at the proxy
  * Allowing end-user devices to drop away most of the CA trust and 
restrict themselves to just the centralized proxy CA.

Note that the trusted proxy need not be a commercial one. It could be a 
desktop device or CPE gateway at a home with dozens of smartphones, TVs, 
games boxes, PCs, laptops, tablets, fridges, etc behind it. All of which 
would otherwise need to have constant CA certificate database, 
revocation list updates and related security updates.
  On the whole the overall picture is *more* secure using a trusted 
point of centralized security management with simpler end-user in mind.

>
> Really, I think your proposal doesn't work out in the end. I also
> understand why you propose it, but suspect that like many such
> proposals there are many more problems than are apparent at first.

And more benefits than commercial ones.

Amos

Received on Tuesday, 7 August 2012 00:43:31 UTC