net: allow fallback down to TLS 1.0 in the event of a bad-record-MAC alert.

net: allow fallback down to TLS 1.0 in the event of a bad-record-MAC alert.

TLS 1.1 support has uncovered several examples of a new kind of broken server:
they negotiate TLS 1.0 correctly in the face of a 1.1 or 1.2 ClientHello, but
then fail with a bad-record-MAC alert when processing the client's Finished
message.

This bug is exhibited by at least two different types of SSL "accelerator"
device, which will probably take forever to be fixed. So, with a heavy heart,
this change adds yet another workaround.

BUG=260358
R=rsleevi@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=212122

[agl, 2013-07-17 16:52:25]

jar: sending this to you because wtc and sleevi are away. It probably needs a
stable merge so I don't want to wait for them to return.

[Ryan Sleevi, 2013-07-17 17:35:11]

On 2013/07/17 16:52:25, agl wrote:
> jar: sending this to you because wtc and sleevi are away. It probably needs a
> stable merge so I don't want to wait for them to return.

I'm back.

[Ryan Sleevi, 2013-07-17 17:42:05]

Can you provide more details on the bug, so that we can track this
appropriately?

Name and shame.

I'm also curious if the accelerators are computing the finished messages as-if
the ClientHello contained 1.0 rather than 1.1

Should we also consider *not* showing the green lock for these cases, but the
yellow exclamation (if we don't already...). I'm concerned that without greater
visibility/scare, we're always going to have TLS downgrade attacks possible.

Why does ssl_client_socket_openssl not need a similar change? We've enabled TLS
1.1/1.2 on mobile, IIRC (
https://code.google.com/p/chromium/codesearch#chromium/src/net/ssl/ssl_config...
)

[Ryan Sleevi, 2013-07-17 17:42:15]

Oh, and LGTM for the NSS side.

[agl, 2013-07-17 19:15:17]

On Wed, Jul 17, 2013 at 1:42 PM,  <rsleevi@chromium.org> wrote:
> Can you provide more details on the bug, so that we can track this
> appropriately?
>
> Name and shame.

Will do. I've had a few reports and they seem to be:

HP e-Commerce Server Accelerator sa7120
Solaris KSSL kernel SSL acceleration

(It's possible that the first is actually a box running Solaris.)

> I'm also curious if the accelerators are computing the finished messages
> as-if
> the ClientHello contained 1.0 rather than 1.1

Could well be.

> Should we also consider *not* showing the green lock for these cases, but
> the
> yellow exclamation (if we don't already...). I'm concerned that without
> greater
> visibility/scare, we're always going to have TLS downgrade attacks possible.

I don't think that the yellow downgrade is actually helpful. Downgrade
bugs are so endemic that we're not going to be able to clear them out.

My plan is to get Salsa20/12+Poly1305 working in NSS & OpenSSL (I've a
patch for NSS, OpenSSL is going to take a little more work and benl is
slammed this week), then to enable AES-GCM and Salsa20/12+Poly1305 in
all versions down to SSLv3. In SSLv3, that ciphersuite will also
implicitly mean P-256 with uncompressed points.

> Why does ssl_client_socket_openssl not need a similar change? We've enabled
> TLS
> 1.1/1.2 on mobile, IIRC (
>
https://code.google.com/p/chromium/codesearch#chromium/src/net/ssl/ssl_config...
> )

I think we can get away with not having this sort of thing on mobile
more readily. If they want it to work on mobile they can fix the site
:)


Cheers

AGL

[agl, 2013-07-17 19:19:13]

On Wed, Jul 17, 2013 at 3:14 PM, Adam Langley <agl@chromium.org> wrote:
> I think we can get away with not having this sort of thing on mobile
> more readily. If they want it to work on mobile they can fix the site
> :)

p.s. I'll get this patch moving unless you believe that we should keep
mobile in sync with these hacks.


Cheers

AGL

[agl, 2013-07-17 20:15:30]

Committed patchset #1 manually as r212122 (presubmit successful).