Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

[Marsh Ray <[e-mail]>]

Martin Rex wrote:
> 
> There is absolutely _NO_ known security problem and no vulnerability for
> a server to accept an initial handshake with the existing SSLv3, TLSv1.0,
> TLSv1.1 or TLSv1.2 protocol, even when the ClientHello handshake
> message does neither contain SCSV nor an empty extension RI.

Baloney!

> The possibility for an "attack" where an old client's renegotiation
> handshake is proxied into the initial handshake of a server is of
> no concern to the server.

TLS is a network data security protocol. Both parties have an interest
in the security of the connection.

If a client has the attacker's data in his input buffer, then a
legitimate server's handshake provides a certificate which the client
interprets as authenticating the previous data, the attacker has stolen
the servers credentials!

(Interpreting TLS credentials over a connection this way was previously
thought to be a valid and secure thing to do, and is made so by the RI
extension.)

> That's purely a client issue and has the
> prerequisite that the client completely botches the server authentication
> on the initial handshake

TLS specifies no requirement for the client to authenticate the server
on the initial handshake. It is completely within the spec for a client
to negotiate an anon-anon connection which is then upgraded to anon-cert
or cert-cert.

Regardless, this necessary requirement for security (that a client must
fully validate and verify the server's certificate during and not after
every handshake) is non-obvious and basically undocumented for
application developers.

Heck, most of us didn't even know renegotiation existed or that our SSL
stacks would do it automatically. There are surely applications coded by
competent and conscientious developers which do not behave this way only
because no one was aware of the need to do so. And that need only exists
because TLS renegotiation was vulnerable to a MitM attack before this fix!

> and is equivalent in effectiveness to XSRF, XSS
> and server impersonation -- something that protected TLS renegotiation
> can not protect from.

You can't have it both ways. You can't say there's "absolutely _NO_
known security problem" and that "protected TLS renegotiation can not
protect from" it.

But in fact, there is an attack. The good news is that having both
endpoints patched to support RI, or just one endpoint patched and
configured in strict-secure mode, does protect your connection from this
attack.

- Marsh