Re: [TLS] TLS and middleboxes again

[Yoav Nir <[e-mail]>]

On Aug 31, 2011, at 10:39 PM, Yaron Sheffer wrote:

> Here's a suggestion to avoid the records that announce the proxy. It's 
> not ideal, but it may be easier to implement/deploy than an intrusive proxy.
> 
> We could use some sort of discovery mechanism to detect the presence of 
> the proxy. Then the client queries the proxy for its certificate hash 
> (with a well known URL), and you can assume the proxy will in fact be 
> there. The discovery process itself is *not* security-sensitive, and we 
> can use caching.
> 
> Two options are PAC (http://en.wikipedia.org/wiki/Proxy_auto-config and 
> http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol) and DNS 
> SRV records. The former is commonly deployed in enterprises, the latter 
> is much simpler to standardize and implement, and architecturally cleaner.
> 

All these involve a potentially lengthy discovery process, and more inter-layer communications than I'd like. 

The common use case for a middlebox is for when I'm "inside" the company perimeter. In the place where I work, there's WLAN reception on all floors, but none in the stairwell. Going upstairs with a smartphone involves roaming from the WLAN to the 3G network and back to the WLAN. As far as the middlebox is concerned, you're going from "inside" to "outside" and back "inside".

There is an obvious way for discovery: the client sends hashes of the middlebox certificates in the extension. If the middlebox hash is missing, the middlebox will interfere by sending an alert with its hash and a URL for getting its certificate. The harder question is how to discover that the proxy is gone (or rather, off-path). It's not quite as important, because sending encrypted keys to a non-existant middlebox should not cause a lot of damage, but we don't want to keep accumulating middleboxes.