On Tue, Aug 20, 2013 at 9:03 PM, Yoav Nir <y...@checkpoint.com> wrote: > > But you bind the transmitted MAC to the TLS session by getting cookie_key > extracted from the session. So what you transmit is not a bearer token, as it > can't be used in another session. The cookie_binding protects you against > someone stealing the cookie during set-cookie, but that's a one-time thing, > although it could be worth it.
I think you're reversing "cookie_key" and "cookie_binding"? It's true that the cookie_key could have been sent explicitly by the server, instead of "extracting" it from the master secret. But then we'd be transmitting auth secrets, which we're trying to avoid. > If Channel ID becomes part of TLS 1.3, proxies would have to be updated. No > question there. But once it is, then the new handshake records can just be > passed along by the proxy. > > What the proxy can't do, is to make it so that the master secret on both > halves of the connection are the same. The proxy performs a handshake with > the client and with the server, and then decrypts and re-encrypts everything. > So there is no way that the client and server can calculate the same values > for cookie_binding and for cookie_key. The "cookie_key" and "cookie_binding" values for a TLS connection can also be passed from a TLS-terminating proxy to back-end servers. Trevor _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
