Subject: Re: [TLS] TLS and middleboxes again

From: Yaron Sheffer <[email-masked]>
Date: Wed, 31 Aug 2011 22:39:05 +0300

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.

Thanks,
     Yaron

On 31.8.2011 22:00, [email-masked] wrote:
> Date: Wed, 31 Aug 2011 14:57:51 +0300
> From: Yoav Nir<[email-masked]>
> To: Chris Richardson<[email-masked]>
> Cc: "[email-masked] List"<[email-masked]>
> Subject: Re: [TLS] TLS and middleboxes again
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> The middlebox would still have to at least delay application records until the keys are delivered. Also, making sure that the keys are actually delivered to the middlebox reliably is extremely hard unless we use the existing connection.
>
> I just don't see an out-of-band delivery as being workable.
>
> If we could eliminate the records that the middlebox inserts, and have only the client and server send records, I agree that it would be better, but without the middlebox announcing its presence, I don't see how the protocol could work without too much key sharing. I'll be glad to get some suggestions.
>
> Yoav
>
> On Aug 30, 2011, at 5:58 PM, Chris Richardson wrote:
>
>> If the middlebox is inserting KeyShareInfo records into the stream,
>> then it must modify the TCP sequence number on all future packets in
>> the handshake.  One cannot use a "dumb" middlebox that modifies the
>> handshakes and nothing more.
>>
>> Perhaps an out-of-band keysharing mechanism would be better.
>>
>> On Thu, Aug 25, 2011 at 3:39 AM, Yoav Nir<[email-masked]>  wrote:
>>> Hi all
>>>
>>> Several weeks ago, Dave McGrew submitted a draft for improving the workings of TLS proxies. As expected, this generated a lot of controversy, with some people saying that they'd rather hand over the session keys to the middlebox than to standardize a MitM attack.
>>>
>>> I was on the other side of that debate, but one problem with comparing the two alternatives is that for proxies there are several commercial products and Dave's draft, while there's nothing for key sharing. To remedy that, and help the discussion along, I've submitted the below draft. Comments and additional controversy are very welcome.
>>>
>>> Yoav
>>>
>
>
> ------------------------------
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>
> End of TLS Digest, Vol 85, Issue 22
> ***********************************

---

From: Yoav Nir <[email-masked]>
Date: Thu, 1 Sep 2011 09:07:16 +0300

> 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.