Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3

[Marsh Ray <[e-mail]>]

Martin Rex wrote:
> Marsh Ray wrote:
>> This weakness is one of the last nails in the coffin for SSLv3, doomed
>> from the start due to its lack of proper extensibility. It seems
>> appropriate since it was 3.0 that quietly introduced this renegotiation bug.
> 
> I think you might be barking up the wrong tree.
> 
> This MITM-susceptibility is _not_ a problem specific to SSLv3.
> It is a problem that affects the entire installed base of
> TLS v1.0, TLS v1.1 and TLS v1.2 in _exactly_ the same fashion.

Yes, but TLS >= 1.0 can be fixed properly with
https://datatracker.ietf.org/drafts/draft-rescorla-tls-renegotiation/

> What I do NOT want to happen is that we kill the entire installed
> base of TLS-servers now (including TLS v1.2 servers), which is what
> will be doing if we disable our clients to talk to servers that
> are not updated -- completely independent whether these servers
> are actually vulnerable.
> 
> 
> As far as upgrading/fixing is concerned: I do _not_ see an issue
> the SSLv3 spec that would prevent the proposed fix to be used
> even for sessions negotiated with protocol version 0x03,0x00.

SSL 3.0 doesn't seem to allow extensions on Server and Client Hello
messages.

> There is, however, the problem with killing interoperability
> to an installed base by having the client unconditionally send
> a TLS extension in each initial ClientHello.

TLS allows extensions and specifies when they should be ignored.

> The issue of interoperability with that installed base seems to
> have been sufficiently severe, that at least one Browser vendor
> decided to implement a re-connect retry logic with a fallback
> to extension-free SSLv3 ClientHello.

Maybe that was one of those "we've always done it that way" decisions
that needs to be revisited.

> Do you really want to say "nice work -- we want you to remove
> or disable the fallback and ignore your customers complaints" --
> and not because that fallback is bad or because their clients
> have a vulnerability -- but because we believe there is going
> to remain a small amount of unfixed servers where the attack will
> remain possible (but affecting only the users/customers
> of that servers).

To the extent TLS is about delivering on its stated and implied security
guarantees.

That may or may not meet the requirements of any specific application.

> What I meant was the transition period to an area of fixed servers.
>
> We need to ship clients capable of secure renegotiation before we
> can disable the old renegotiation on the servers.
>
> And we need to upgrade servers to secure renegotiation before we
> can suggest updated clients to discontinue talking to old servers.

The proposed draft-rescorla-tls-renegotiation "RI extension" provides a
solution which restores the security of connections where both endpoints
implement it.
There is probably no way to restore that security without patching both
endpoints.

The RI extension also maintains backwards compatibility with existing
conformant TLS endpoints. There are reports of some non-conformant
servers that might not like seeing an extension on TLS, we can hardly
ask the world to forever abandon the idea of Hello message extensions as
a result!

The timeframe over which users and admins move to configure their
applications to deny connections with unpatched endpoints ("secure
mode") is up to each individual, in conjunction with their vendors. I
have opinions about it, but it really is a situation which will need
informed judgement on a case-by-case basis.

The timeframe over which the default settings of new installations (and
late-patched existing deployments) migrates to secure mode is largely up
to the TLS implementation and application vendors.

> Servers performing a traditional SSL handshake is _not_ a security
> problem.

There are some attacks in which the client sees the renegotiation and
the server only sees one connection.

> Clients can not currently notice what the server is doing, and the
> problem exists, because a clients initial handshake can be proxied
> into a servers renegotiation.

Which is particularly bad when the client is willing to provide client
cert authentication in that handshake.

> A client that is performing an initial handshake does _not_ know
> whether there is a security problem, therefore I'm very reluctant
> to suggest clients to warn users when performing a traditional
> initial handshake.

The client can determine if he is handshaking with an unpatched TLS
server when he sees the Server Hello message without the RI extension.
It sounds reasonable to me that the client might indicate this
potentially-insecure situation in whatever UI or log facility the client
application provides.

> It is going to be unfair to an ever-growing
> number of servers.

No, the number of unpatched servers in the world will begin shrinking as
soon as the fix becomes available.

> Doing the secure renegotiation through the TLS extension in an
> official renegotiation is not the problem.  Fixing means that the
> code will have to be changed.  If the change is sufficiently small,
> it can be added with a relative small amount of work to servers
> at all protocol levels, including SSLv3.

So SSLv3 would be retroactively given hello extensions? Sounds like a
breaking change. Wouldn't it be easier to just use TLS?

- Marsh