Re: [TLS] simplistic renego protection
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TLS] simplistic renego protection



Nelson B Bolyard wrote:
> 
> > If lenient servers are allowed, then I think it will take *much* longer
> > until the vulnerability is eliminated from most connections.
> 
> I must have missed the message wherein "lenient server" was defined.
> Is it a server that accepts client hellos without any signal that the
> client has been upgraded, but merely refuses to renegotiate with such a
> client?
> 
> IOW, is it the kind of server that numerous vendors are shipping now,
> that recent patches to open source have just created, one that refuses to
> renegotiate at all but still accepts old style client hellos?

The type of (old) servers that are going to be with us for
quite some time are those that either never did renegotiate
where it was recently disabled.

Problem is, that they leave the clients in the dark if they don't update.
There is no assurance/confirmation at the protocol level that they
can't be abused.


> 
> Is someone proposing to abolish them already?

I must have missed the widespread availability of patches for
secure renegotiation -- or are they taking down the entire internet
until further notice?   ;-)

> 
> > Remember, rejecting a renegotiating ClientHello does not necessarily lead
> > to an interoperability failure; it only does so if the client will not
> > reconnect.
> 
> By definition, the alert that rejects a renegotiating client auth
> (no_renegotiation) is a warning alert.  It leaves the previous TLS
> connection and session state intact and able to continue.  So IINM, it does
> not lead to an interoperability failure unless the client chooses to treat
> that alert as fatal, despite being a warning, AND refuses to reconnect.
> Right?

In theory "no_renegotiation" alert is a warning alert.

In theory a server that wants to obtain a client certificate
and send a HelloRequest should treat a resulting 'no_renegotiation' alert
similar to a no_certificate alert (SSLv3) or empty Certificate message.

but it is probably not that simple.


If the server chokes when the client denies the HelloRequest
with a no_renegotiation alert and the app on top re-connects,
repeating the request, then this could result in a deadly
embrace.  I hope the app uses a retry-counter.

-Martin

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.