Re: Semantics of HTTPS


------ Original Message ------
From: "Yoav Nir" <ynir@checkpoint.com>
>
>
>I don't think this is actually getting rid of them. It really depends on how you define "MitM". If a user connects to facebook, they naturally expect their traffic to go straight to facebook, and if notice the little padlock icon, they expect this connection to be confidential. They don't expect third parties to be reading this, so any third party that does is a MitM.
>
>
We don't really expect that it will get rid of MitMs, since if someone 
has a working MitM, they will likely keep it, at least for as long as 
it is still useful (which will be the case until GET https:// is 
ubiquitous)

The proposal does change a couple of things though.

1. It makes it easier to implement.  It's much easier to implement 
support for GET https:// than it is to implement interception of TCP 
connections to a SSL endpoint that has to spoof certificates.
-> fewer nasty side-effects, probably better user experience, lower 
customer (operator) support burden.

2. It provides a viable alternative to development of another MitM 
solution, presuming client support is adopted quickly enough.

With the current MitM situation, as you say the error condition is one 
of failure to validate a certificate.  

There's no way for the browser to recognise that the certificate issue 
is relating to a MitM.  Therefore it can only display a generic error, 
of the kind that is more likely to be lumped in with others, and trains 
users to ignore it.

With our proposal however, the client can know what's going on.  

I think there could be some refinements to provide even better 
information, such as 

* the proxy passing back cert of server as Base64 encoded Server-Cert 
header or something, so that the client has an opportunity to do its 
own cert validation. This of course presupposes trusting the proxy.

* Some way to fail a CONNECT request in a way that tells the client it 
must use proxied https for that site.


We could even ameliorate MitM with a few things.  Like a BCP for it, 
doing things like

* mandate spoofed certificates to include an attribute marking 
themselves explicitly as spoofed for the purpose of content inspection.

But we can't keep our heads in the sand.  The more sites move to SSL, 
the more pressure comes on intermediary vendors to provide solutions.


Adrien

>
>Whether you configure a sniffing CA, or a "trusted proxy" makes no difference. Making it part of the protocol makes no difference, because the user's privacy is not affected by whether the proxy behavior is "standardized" or a "hack". The implications are the same.
>
>The proposal that Stephen mentioned was rejected by TLS was not intended to make privacy better or worse than the current situation, not does it change the implications of having a MitM. This proposal also does not change things.
>
>Yoav
>
>
>
>

Received on Tuesday, 7 August 2012 07:34:22 UTC