Subject: Re: [TLS] TLS and middleboxes again

From: Yaron Sheffer <[email-masked]>
Date: Thu, 01 Sep 2011 10:03:10 +0300

DNS is not crossing any protocol layers, but I agree your proposal is 
simpler.

Adding a time-to-live to the alert/announcement (with e.g. max 1 hour) 
would probably solve the problem.

     Yaron

On 09/01/2011 09:07 AM, Yoav Nir wrote:
> 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.
>

---

From: Philip Gladstone <[email-masked]>
Date: Wed, 07 Sep 2011 08:30:07 -0400

On 8/26/2011 4:45 PM, Daniel Kahn Gillmor wrote:
> Since HTTP redirects can only be done in an HTTP header, the middlebox
> would need to buffer all HTTP content before relaying it to the User
> Agent, in case "bad" material was found at the end.
>
> I don't think either of these use cases are valuable, certainly not
> valuable enough to warrant allowing middleboxes to violate the integrity
> guarantees of TLS.
>
>

The problem with not allowing modification of the data stream is that 
the middlebox only has one choice left -- to abort the connection. This 
provides a less than satisfactory experience to the end user -- and some 
file transfer managers will simply retry the connection (as they think 
that the connection was accidentally aborted).

There is another reason to release the authentication keys -- and that 
is to prove to the middlebox that the correct encryption key was 
released. Otherwise, the client can release a bogus encryption key, and 
the middlebox has no way of determining what is being transferred. [Of 
course, the client would release the correct key initially to cover the 
HTTP request, and would then rekey the connection with the server and 
release an incorrect key for the response body. ]

Philip

-- 
Philip Gladstone
Distinguished Engineer
Product Development
[email-masked]
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ