Re: Comments on Explicit/Trusted Proxy

Agreed. 

Today:
MITM proxy must get its CA installed in the certificate db on the end user device.
MITM forges certs -- effectively impersonating content servers.
MITM performs trust validation for end user -- transitive trust opens up the possibility that users will not be made aware that they are visiting https sites that they do not trust.
Content servers are unaware of SSL proxy.

Tomorrow:
We could instead have a new section of the certificate database for trusted proxy certs. These certs would need to be issued by trusted CAs. An SSL proxy would need to install this into the end user device so level of security is the same as today.
No forged certs -- the original content server certificate is sent to the browser as described by the mcgrew draft.
Client can decide if it trusts the content server certificate or not -- no transitive trust.
Content servers can be made aware of SSL proxy so that when cnn.com adopts SPDY it can allow optimization by SSL proxies and it will not become 4x slower over satellite.

Peter


On May 2, 2013, at 11:17 AM, Albert Lunde <atlunde@panix.com> wrote:

> On 5/2/2013 9:57 AM, Stephen Farrell wrote:
>> 
>> 
>> On 05/02/2013 03:53 PM, Peter Lepeska wrote:
>>> It's no different than today. If you have a root CA installed on the end users machine, you can MITM the bank. Under this scheme, there will be some proxies that will elect to not MITM traffic from content providers that explicitly opt-out.
>> 
>> Right. All web servers have to trust all the proxies in the universe.
>> Seems like a show-stopper to me.
> >
>>> In general, adding support for an SSL proxy should not decrease the
>>> level of security from MITM attacks that we have today. It just allows
>>> well-behaving ones to A) not have to forge certificates, B) remove the
>>> problem of transitive trust, and C) make content servers aware and give
>> them the ability to opt-out.
>> 
>> Standardising that would IMO seriously decrease the level of
>> security we have.
> 
> I'd say it's better to trust a known proxy than to be in the typical captive portal situation where the portal in effect forges certificates to make you think everything is wonderful.
> 
> This is being done widely enough to suggest there is a use case.
> 
> What one would like is something that restricts what the proxy can do and identifies the proxy in a reliable way.
> 
> The other approach that sometimes works is some kind of VPN, but that may be out of scope...
> 
> -- 
>    Albert Lunde  albert-lunde@northwestern.edu
>                  atlunde@panix.com  (address for personal mail)
>