Re: [TLS] Deprecating SSLv3

[Hubert Kario <[e-mail]>]

On Monday 24 November 2014 19:29:53 Martin Rex wrote:
> Hubert Kario wrote:
> > On Monday 24 November 2014 18:06:22 Martin Rex wrote:
> >> Hubert Kario wrote:
> >> > Anyway, you should file a complaint to the manufacturer that it haven't
> >> > addressed the POODLE vulnerability in their product (or that it doesn't
> >> > implement advertised protocols properly).
> >> 
> >> Poodle is a *PURE* Web-Browser and client problem.
> >> Servers are not vulnerable to Poodle, and this site *REQUIRES*
> >> TLS client certs for authentication.
> >> 
> >> Disabling SSLv3 on servers is only a practical mitigation against
> >> the stupid "downgrade dance" that so many browsers perform.
> >> It's difficult for me to understand how someone could implement
> >> the downgrade dance and *NOT* provide a switch to turn it off after
> >> addressing the rfc5746 tls renegotiation issue.
> > 
> > To exploit POODLE you need fallback dance *or* support just SSLv3. It's
> > not
> > limited to web browsers (and there are some clients that do fallback and
> > are not browsers, e.g. curl).
> > 
> > Also, are you saying that an *automated* system won't retry on connection
> > failure?
> 
> _very_ few, if any.  Exactly none of ours.

we're not writing the RFC for your systems only
 
> > We're talking about average of 128 failed requests per byte decrypted,
> > even if we fail just every first connection on a system that queries
> > remote server every 5 minutes 24/7 that will require just a month to
> > decrypt 16 byte password/authentication string. There have been far
> > more dedicated and longer attacks in the wild.
> 
> You may have not understood the Problem.
> 
> It's a plaintext recovery of 1 byte per 256 requests on average

no, you need 256 for 100% chance of recovery, statistically speaking you need 
128 requests for a 50% chance of recovery - 50% *is* average, especially if 
we're talking about recovering multiple bytes.

> A poodle attack will be pretty "noisy" on the server, so for many
> usage scenarios, this will be sufficient deterrent, just like many
> apartments have no bullet-proof windows and many doors have not
> pick-proof locks.

attacks are unlikely (in general), administrator will consider hardware 
failure or a software bug before an active attack

that is *if* he will look in the logs at all...
 
> And you could add random URL-parameters or other insert additional
> header fields before the credentials if you absolutely want to
> keep doing disclosing authentication rather than simply switching
> to using TLS client certs for the requests.

that means implementing mitigations. You might as well stop using 18 years old 
protocol while you're making changes to your application code

> > SSLv3 has known security problems,
> > more issues may be discovered in the future.
> 
> TLS has long known weaknesses and well-documented limitations.
> 
> When you remain within the safe usage areas, even SSLv3 is still secure.
> 
> Really, what we should worry about is the current usage scenarios
> where even TLSv1.2 can not provide protection, and one of these
> is Cross-Site-Request-Forgery as currently offered by Web-Browsers.

just because other systems have issues doesn't make this particular problem 
smaller
 
> > So while use of certificates may mitigate this problem, we may not
> > ever know if it mitigates all problems SSLv3 has.
> 
> I'm not expecting any. Honestly.

a protocol that requires 2 pages to describe all the pitfalls and workarounds 
needed to use securely is a bad protocol

that basically makes it impossible to implement and use securely

> > For example, issues like 3-shake won't be fixed in SSLv3.
> 
> I never offered TLS renegotiation to applications in our implementation,
> and I hardwired it to a fatal alert on the server in 2010.
> 
> Conservative designs don't have to care about 3-shake.
> 
> There are several more implementation pitfalls hidden in the
> TLS renegotiation design.

you did that, how many did not? have you peer reviewed your changes? can you 
trust those reviews? (see also: CloudFlare Challange)

and let me repeat myself: we're not making RFC for your implementation only
  
> > Do we really need the repeat of the MD5 signatures story or can we learn
> > on
> > our own (as in industry) mistakes?
> 
> It would already be an improvement if the TLS WG stopped (mostly) ignoring
> problems (such as Vaudenay's), or didn't add new problems (such as
> making (rsa,md5) a mandatory-to-implement TLSv1.2 signature algorithm).

Sorry, but that is simply not true.

The specified behaviour is to select SHA1 in case the client doesn't provide 
the extension. At no point the RFC says that RSA+MD5 is a MUST or even SHOULD.

-- 
Regards,
Hubert Kario