Re: [TLS] SCSVs and SSLv3 fallback

[Joseph Birr-Pixton <[e-mail]>]

On Thu, 4 Apr 2013 23:34:02 +0200, Hanno B?ck <[e-mail]> wrote:
> Date: Thu, 4 Apr 2013 23:34:02 +0200
> From: Hanno B?ck <[e-mail]>
> Subject: Re: [TLS] SCSVs and SSLv3 fallback
> Message-ID: <20130404233402.6c91a9bf@melee>
> Content-Type: text/plain; charset="iso-8859-1"

> And it's a serious problem if you're using Server Name
> Indication (SNI) for more than one SSL cert on one IP. The "solution" I
> found for our case was that I found it tolerable today to disable SSLv3
> on the server side. However, I'm not really happy with that browser
> fallback behaviour, it's a serious pitfall for the use of SNI.

Worse than that; it's a serious pitfall for users who think they are
benefiting from any of the security improvements made since SSL3.

For example: I surveyed the alexa top 500 web sites; 321 provide a
working SSL or TLS service. 27% chose different security parameters
under downgrade conditions. Of those, 81% lost forward secrecy under
attacker control.

Notably, google.com went from a server authentication key providing
~128 bits of security and ciphersuite providing forward secrecy, to a
server authentication key providing ~73 bits of security and no
forward secrecy. That is really very, very broken.

More relevantly, any sites deploying non-broken AEAD ciphersuites in
the near future (while still providing SSL3 service) will still be
subject to attacker-controlled downgrade to CBC-mode or RC4
ciphersuites.

Cheers,
Joe