Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego

[Michael D'Errico <[e-mail]>]

A client that wants protection from this attack MUST send the extension
in its initial handshake.  Why don't you want to do that?

The attack being discussed happens on the client's *initial* handshake.
The server sees it as a renegotiation, so the client needs to be able to
tell the server that it thinks it is performing an initial handshake.
That is exactly what this extension provides.  If you don't send the
extension on an initial handshake you are risking being attacked.

All servers SHOULD disable renegotiation to protect clients, but it's
been said that this is impractical.  A server may be configured to allow
renegotiation even though it understands the new extension.  Thus by not
sending the extension in your initial handshake, you are just as
vulnerable, even though you could have prevented an attack.

And it is actually secure for a client to renegotiate even if the server
does not support the Renegotiation_Info extension.  If the client has
verified the server's certificate in the initial handshake, there is no
MITM.

Mike


David-Sarah Hopwood wrote:
> David-Sarah Hopwood wrote:
>> Michael D'Errico wrote:
>>>> Suppose that the client sent an SSLv3 ClientHello
>>>> with client_version = 3.1 (or higher). Assuming the server supports TLS,
>>>> then TLS will be negotiated. So when the client sends the renegotiation,
>>>> it knows that it is safe to send extensions. The attack is prevented as
>>>> long as the renegotiating handshake uses the extension; it is not
>>>> necessary for the initial handshake to have used it.
>>> The problem is that your initial handshake *is* the renegotiation!
>>> (from the server's point of view)
>> I may well be confused, but: a handshake is a renegotiation if-and-only-if
>> it is encrypted. Initial handshakes are in the clear. So there is no
>> ambiguity, from either party's point of view, about whether a handshake
>> is a renegotiation.
> 
> Actually this is not quite right, although not in a way that affects my
> main point.
> 
> A handshake is a renegotiation from the server's point of view
> if-and-only-if a ciphersuite other than TLS_NULL_WITH_NULL_NULL is
> in effect. It is possible that an initial handshake by a client that
> was sent in the clear, could be encrypted by an attacker and appear to
> the server as a renegotiation. In that case, the server can reject the
> renegotiation if the ClientHello doesn't contain a correct (and non-empty)
> Renegotiation_Info.
> 
> It is also possible that, if a client that does not support the extension
> requests a renegotiation on a session with the attacker, then the attacker
> can decrypt it and present it to the server as an initial handshake.
> But this only applies to clients that do not support the extension at all.
> If a client does support it and sends it only when renegotiating, then
> this variant of the attack is still prevented.
> 
> So, I was right in my original statement that "the attack is prevented
> as long as the renegotiating handshake uses the extension." Note that
> both clients and servers must avoid renegotiating without using the
> extension; it isn't sufficient for only servers to avoid doing so.
> As long as that is the case, for a client does support the extension,
> failing to send the zero-length Renegotiation_Info in an initial handshake
> does not enable an attack.