[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] TLS and middleboxes again
From:       Yaron Sheffer <yaronf.ietf () gmail ! com>
Date:       2011-08-31 19:39:05
Message-ID: 4E5E8DD9.40604 () gmail ! com
[Download RAW message or body]

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, tls-request@ietf.org wrote:
> Date: Wed, 31 Aug 2011 14:57:51 +0300
> From: Yoav Nir<ynir@checkpoint.com>
> To: Chris Richardson<chris@randomnonce.org>
> Cc: "tls@ietf.org List"<tls@ietf.org>
> Subject: Re: [TLS] TLS and middleboxes again
> Message-ID:<0AD45ACF-20DA-474B-BEB8-ECAF7AC2EBF3@checkpoint.com>
> 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<ynir@checkpoint.com>  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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> End of TLS Digest, Vol 85, Issue 22
> ***********************************


[prev in list] [next in list] [prev in thread] [next in thread]