ssl_ciphersuite: drop non-FS AES256 options

Unpublished Commit · Learn More

Not On Permanent Ref: This commit is not an ancestor of any permanent ref.
This commit no longer exists in the repository. It may have been part of a branch which was deleted.This commit has been deleted in the repository: it is no longer reachable from any branch, tag, or ref.


ssl_ciphersuite: drop non-FS AES256 options

This is slightly controversial, but I think we should move forward
with it for now, and allow reverting if there's any legitimate

The non-forward-secret set of ciphers are the least-secure ones,
which we need to eliminate first in the long term. The AES128 and
3DES non-FS ciphers are in this list for pragmatic reasons: there
are simply too many clients still connecting with them for us to
remove them at this time. The AES256 options here are not
pragmatic. By eliminating them, we change the nature of the
"compat" non-forward-secret list. It changes from a list of
"anything we can reasonably support" to "things we still *have* to
support because of minority (but still significant) real client

Stepping through the rationale and data on why the AES256 options
aren't pragmatic:

  1. Fundamentally, most agree that AES256 doesn't offer any

pragmatic crypto-strength benefit over AES128 today.

  1. Any software which implements AES256 would also implement

AES128, which we already prefer over it for efficiency.

  1. Therefore any real client chosing AES256 has actually disabled

AES128 for some security policy reason, with the (questionable)
rationale that more bits is stronger. However, these same clients
apparently do not support basic forward secrecy. It seems
ridiculous to consider oneself in a position to set non-default
client cipher policy for supposed security reasons while ignoring
much more important factors like forward secrecy. (Note: We do
continue to support AES256 in our forward-secret cipher lists).

  1. We've been gathering detailed stats on our primary clusters for

all ciphersuite selections for a year now, and none of these see
any significant traffic. Breaking that down by each cipher's

AES256-GCM-SHA384: Basically no data, except for one isolated,
tiny spike of connections back on 2016-02-16.

AES256-SHA256: Had a small non-ignorable population in mid-2015,
but the rate abruptly fell to near-zero on 2015-10-08 and never
recovered. Prior to that date, logging and sampling showed the
bulk was from a single group of US Military proxies, which
presumably finally got their software upgraded. It's now
intermittent (often days with zero), and the long-term average
rate since the dropoff has been roughly 0.005 reqs/sec.

AES256-SHA: Also often goes days without stats. Its average rate
over the past year is roughly 0.015 reqs/sec.

Bug: T118181
Change-Id: I56cadda5211706ff7040b0e968e0ecb80d22245b


BBlackAuthored on Jul 20 2016, 12:23 PM

Commit No Longer Exists

This commit no longer exists in the repository.