Subject: Re: [TLS] TLS Proxy Server Extension

From: Ken Peirce <[email-masked]>
Date: Wed, 3 Aug 2011 05:18:23 -0700 (PDT)

Yoav,

> The use-case that interests me is deep firewall inspection.
> HTTP connections are routinely inspected by firewalls for
> downloaded malware, cross-site scripting, and various other
> attacks. Without a TLS proxy, HTTPS connections can either
> slip under the radar or get blocked entirely. That would
> have been fine a few years ago, when SSL was only used for
> shopping and banking sites (you could defer your shopping
> and banking for when you were home). These days the use of
> HTTPS is becoming more prevalent, so blocking HTTPS is no
> longer a good option. A TLS proxy allows an organization to
> use HTTPS while still applying company policy and defenses.

Why would you want to make banking and shopping less secure to support these other usage scenarios? The law enforcement community and service providers spend a lot of money to manage the security of their interception tools. There are many recorded cases where control of these tools was mishandled and abused by another party. TLS takes the human being out of the equation and protects the end user with known mathematical barriers. The TLS proxy exists today. It's two sessions in relay mode. The end user accepts the peer of the first session to be a trusted entity. If this trust is misplaced, that has nothing to do with the protocol. This is an application layer problem. 

Please ask the IETF leadership to form a new working group for a new protocol with this proxy as a fundamental tenet. You can experiment with this new protocol all you want. I do not want to see TLS broken because of tinkering in the name of some unestablished need. 

Ken

---

From: Philip Gladstone <[email-masked]>
Date: Wed, 03 Aug 2011 09:38:12 -0400

On 8/3/2011 8:18 AM, Ken Peirce wrote:
> The TLS proxy exists today. It's two sessions in relay mode. The end user accepts the peer of the first session to be a trusted entity. If this trust is misplaced, that has nothing to do with the protocol.

This is exactly true. The problem that we are trying to solve is to find 
out the actual identity of the server that the proxy has connected to. 
Further, we want the client to be able to validate the certificate of 
the server according to its own rules (which may include a different 
list of trusted root certificates). As people have pointed out, being 
able to understand the EV status of the remote server could be important.

I think, based on the discussion, that there is a place for a new type 
of object in the TLS model -- the read-only proxy. This would require 
significant changes to the TLS protocol to support, and it might be 
significantly more difficult to implement than the current two TLS 
session approach. However, I suspect that until all proxies supported 
this new protocol, they would have to support the two TLS session model 
as well -- a viable strategy might be to try and negotiate the read-only 
proxy protocol and then fall back to the two TLS session model.

Philip

-- 
Philip Gladstone
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Ham radio: N1DQ