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

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> Martin Rex wrote:
> > 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/

There is nothing in that draft that prevents its use for SSLv3


>
> > 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.

That is wrong.  The SSLv3 spec has the exact same provisions for
TLS extensions as the TLSv1.0 and TLSv1.1 specs.

TLS extensions became a standard part of the protocol in TLSv1.2 only.

Compare the specs and you will see.


> 
> > 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.


Breaking installed base just for the sake of the fun of it
sounds like a pretty bad idea.


> 
> 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.

This is a misrepresentation.
There is _NO_ known security problem with a full TLS handshake if
_no_ renegotiation is performed. 


I'm perfectly OK with fixing TLS to provide a secure basis for the
previously flawed assumptions of several servers, provided that all
servers that want to use renegotiation in the future are updated.


I have a very significant problem with any recommendation, let alone
a requirement to brick perfectly valid and secure installed base
that does not contain this TLS enhancement, but also doesn't contain
renegotiation and there is not vulnerable.

Especially since this is completely unnecessary!


> 
> > 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.

So what?  The vulnerability is only an entirely with the part that
performs the insecure renegotiation.  The reliable fix (without upgrade)
is to disable renegotiation of that component.


> 
> > 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?

Huh?

SSLv3 is perfectly OK with hello extensions.  Btw., quite a lot of
sessions established with protocol version SSLv3 (0x03,0x00) might
actually be between implementations of TLS that just use conservative
defaults because they don't have a reconnect fallback to and
extension-less SSLv3 handshake.


It would be good to stop confusing people.  Adding TLS support to
an existing SSLv3 implementation is >5x the work than adding
the proposed TLS extension RI.  And you're still just as vulnerable.


What we need is that the installed base out there needs to discontinue
using the insecure renegotiation with TLS.  JUST THAT.

This means either adding the TLS extension RI or reliably disable
renegotiation.

Please every stop suggesting upgraded to TLS v1.something.
That will cause more harm than good, because it gives a completely
wrong impression about what needs to be done.


I'm fine with requiring a proper TLS extension in the renegotiation(!)
handshake to transfer the verify_data of the finished messages.
It's clean and still very simple, and fits SSLv3 just as nicely as
it does TLSv1.0.  This may even help to make SSLv3 implementations
to improve their SSLv3 spec compliance and interop with clients
proposing TLS extensions.

There may be lots of good reasons why upgrading or completely
replacing an implementation of SSLv3 is simply not an option,
but adding the TLS extension RI is.


-Martin