Re: [TLS] Renegotation redux

[Nick Mathewson <[e-mail]>]

On Mon, Apr 14, 2014 at 10:48 AM, Watson Ladd <[e-mail]> wrote:
> Dear all,
>
> Are there any users of renegotiation beyond authentication with client
> side certificates? In particular has anyone come up with a use for
> changing the claimed identity of the server?
>
> I think we can do client authentication upgrades via a channel
> extraction+signing solution while preserving the privacy currently
> given by renegotiation. I haven't yet run Proverif on this solution,
> so it might not work, but my intuition is that this will work better
> than trying to expose the semantics of renegotiation correctly.

So, I've got an example, but I hesitate to bring it up.

Long ago, Tor added a link authentication mode in which we do an
innocuous TLS handshake designed to look like a browser talking to a
webserver, and then renegotiate with the actual parameters and
certificates we wanted.  The goal here was to resist attempts to block
users from connecting to the network.

Using renegotiation here was a mistake and a very bad design.  The
versions of Tor which prefer this link protocol are all deprecated
now.  Renegotiation was not a good solution for this problem, for a
few reasons:

    * It only helped somewhat against blocking.  It turns out that
renegotiating in the way we were renegotiating was weird enough that
it didn't actually make us less conspicuous.
    * It seriously complicated our code.
    * Because we depending on renegotiation, many of the workarounds
for TLS renegotiation bugs broke our clients and servers.

I'm only mentioning it here so nobody brings up Tor as an example of
projects that need renegotiation. We would have been better off if we
had never used renegotiation.  Please do not cite Tor as a good use
case for renegotiation.

> Renegotation has been responsible for two major security issues, and
> significantly complicates the TLS handshake state machine and
> semantics.

To add to the parade of ugliness: the presence of negotiation keeps
programmers from implementing post-handshake TLS as a filter: you need
a notion of "[TLS] read blocked on [TCP] write" and "[TLS] write
blocked on [TCPl] read."  This adds a great deal of complexity and
bugginess to non-blocking programs that want to use TLS libraries.

cheers,
-- 
Nick Mathewson