Re: [TLS] Addressing cookie theft (think BEAST) with channel bound

["Steve Dispensa" <[e-mail]>]

> Martin Rex wrote:
>
> Tom Ritter wrote:
> >
> > I don't think this would work in the (common) case of ssl
> > accelerators/forwarders and reverse proxies.  The app just sees
HTTP,
> > there's no ssl from the point of view of the framework/code a
developer
> > wrote.
> 
> +1
> 
> I also do *NOT* want to see any server-side apps to mess/interfere
with
> TLS session cache management (size and lifetime) on my server or on
> whichever backend border component (accelerator/forwarder/rev.proxy)
> the SSL session is "first opened".
> 
> There is also no guarantee that all client components, that are part
> of an application client infrastructure and consciously sharing
> HTTP cookies, are accessing the same TLS client implementation and
> sharing the TLS session cache.
> 
> -Martin

Apart from this objection, how would this proposal work with expiring
(long-duration) cookies? There are plenty of apps with "remember me"
checkboxes.

But regarding the hardware accelerators, to whatever extent this idea is
valid going directly to a server, they would be able to apply the same
binding themselves without the cooperation of either server or client.
Other problems have been noted, but accelerators don't represent a
critical problem.

I like the thinking in this idea, though. I wonder if there is a
meaningful subset of cases for which this would work, or if Martin's
concerns vis-a-vis the client side are fatal.