Re: [TLS] TLSrenego - current summary of semantics and possibilities

[Michael D'Errico <mike-list at pobox.com>]

> It is possible that a TLS client may not want to assert the TLS extension
> Renegotiation_Info in an initial ClientHello because of interoperability
> concerns with an installed base of not-quite-spec-compliant servers.

Then it will end up buying a lot of pizza.

Simply finishing the *initial* handshake completes the attack!  (The
server saw it as a renegotiation, not the client.)

To protect against this, the only thing that a client can do is include
the empty renegotiation info extension.  If the server returns it and
the handshake completes, there is no MITM.  In fact if you were to then
renegotiate, you wouldn't need the extension (!) because you are already
certain that the handshake was with the server and not the MITM.

There are a few possible results of sending the extension:

    a) the server responds with the extension
    b) the server responds without including the extension
    c) the server "crashes" because of the extension

(a) is fine as long as the extension is empty.
(c) could be simulated by the MITM, so be careful -- falling back to a
    less-secure mode can play into their hands
(b) continue at your own risk -- a client could hold off on sending a
    certificate (if requested) and not send any Cookies.  The HTTPS
    request will fail, but the client can just reissue it after the
    failure -- possibly after renegotiating to send its certificate
    (this is secure if the client has verified the server's cert).

> Overloading ("abusing") the semantics of other regular elements
> of an SSL/TLS handshake that have a lesser likelihood to upset
> legacy servers.
>
>    - Assign one (or two) specific ciphersuite IDs that the client
>      can include in the ciphersuites list which signal the clients
>      notion of the connection state (initial vs. renegotiation)
>      to the server.
>
>    - Assign one (or two) compression algorithm IDs that the client
>      can include in the supported compression algorithms list which
>      signal the clients notion of the connection state (initial vs.
>      renegotiation) to the server.

I would not like to see this kind of solution.  If code has to change,
Do The Right Thing.

> We could define a new TLS handshake message "RenegotiationRequest"
> to be sent instead of a "HelloRequest".  This would be an option for
> those servers, that will abort the handshake and connection
> if the client does not send the TLS extension Renegotiation_Info.

Again, the attack happens on the client's *initial* handshake, so it
never receives a HelloRequest.

Mike