Expose TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 on the deprecated cipher fallback.

Expose TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 on the deprecated cipher fallback.

It's believed that the majority (over 80%) of TLS version downgrades remaining
come from out-of-date IIS servers with the AES-GCM bug (crbug/433406). From
probing servers some time back, it appears that, of those, the IIS 8.0 ones
prefer TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 over the broken GCMs. Adding that
cipher may drive the number down enough to be worthwhile.

Experimentally add this cipher to the list to see what it does to the metrics.
It may yet be worth trying to drop the fallback without this workaround, since
the server-side fix is so easy, but run with this a bit to get numbers on what
the options are.

As we otherwise would not have exposed a new legacy CBC mode cipher, this
cipher is placed on the deprecated cipher fallback. This way we can continue to
monitor things which need it and hopefully eventually phase it out once the
install-base has taken their updates.

BUG=536200
Committed: https://crrev.com/91585690d1355c92f7cac0cee08c3ccecb57a6b2
Cr-Commit-Position: refs/heads/master@{#351205}

[davidben, 2015-09-25 22:25:49]

davidben@chromium.org changed reviewers:
+ rsleevi@chromium.org

[davidben, 2015-09-25 22:25:50]

See https://boringssl-review.googlesource.com/#/c/5962/5/include/openssl/ssl.h
for documentation on the cipher suite language.

[davidben, 2015-09-25 22:39:33]

On 2015/09/25 22:25:50, David Benjamin wrote:
> See https://boringssl-review.googlesource.com/#/c/5962/5/include/openssl/ssl.h
> for documentation on the cipher suite language.

(Actually, this one's better:
https://boringssl-review.googlesource.com/#/c/5962/6/include/openssl/ssl.h )

[Ryan Sleevi, 2015-09-28 20:30:45]

LGTM, assuming (a) is the correct interpretation from the comment I left on the
other CL.

[davidben, 2015-09-28 21:27:10]

On 2015/09/28 20:30:45, Ryan Sleevi wrote:
> LGTM, assuming (a) is the correct interpretation from the comment I left on
the
> other CL.

It's (b). The dummy cipher ends up at the end of the list. Producing the right
list with it not at the end is somewhat a nuisance (the exclusions need to get
much more complicated), and I didn't think it was that worthwhile because we
don't actually want you to use this cipher anyway (hence my adding it to the
fallback leg). Ideally the only servers that ever read as using it are the IIS
servers that we workaround (which enforce a server preference) and nothing else.

[Ryan Sleevi, 2015-09-28 22:05:37]

Ah, the fact that IIS enforces server preference makes this clearer/easier to
reason about :)

Thanks, still LGTM

[davidben, 2015-09-28 22:12:08]

On 2015/09/28 22:05:37, Ryan Sleevi wrote:
> Ah, the fact that IIS enforces server preference makes this clearer/easier to
> reason about :)
> 
> Thanks, still LGTM

Ah. Yeah, if IIS didn't enforce server preference, then this change would be
mildly sad as it'd mean we'd have to put this cipher after a GCM, which is one
of those unclear ordering things. :-)

[davidben, 2015-09-28 22:12:14]

The CQ bit was checked by davidben@chromium.org

[commit-bot: I haz the power, 2015-09-28 22:13:16]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1366253005/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1366253005/1

[commit-bot: I haz the power, 2015-09-28 23:46:16]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-09-28 23:47:07]

Patchset 1 (id:??) landed as
https://crrev.com/91585690d1355c92f7cac0cee08c3ccecb57a6b2
Cr-Commit-Position: refs/heads/master@{#351205}