Blacklisting RSA decryption ciphers is plausible (though note our data suggests that, sadly, it still sees nontrivial usage), but wanting to disable those four without also wanting to disable TLS_RSA_WITH_3DES_EDE_CBC_SHA is surprising. Did you mean to include that one too? It's even worse than the other four.

Options to blacklist ciphers already exist at the SSL layer, so the question is whether the Enterprise team wishes to support this. However, it may make more sense to expose higher-level knobs, such as:

SSLWeakRSACiphersEnabled (controls TLS_RSA_WITH_*)
SSLWeakCBCCiphersEnabled (controls *_CBC_*)

These would be very straightforward to add and would make it easier for administrators to express actual security policies and avoid accidentally disabling the strong ciphers or missing one.

We would also want to block "TLS_RSA_WITH_3DES_EDE_CBC_SHA" as we currently do that today in addition with those 4 in IE/Windows world.

We want to be able to enforce this on our enterprise client machines to ensure clients can't connect to non-compliant standards set forth by our organization and not need to rely on "third parties".

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks! That suggests something like SSLWeakRSACiphersEnabled would indeed work for you.

I'll leave it to enterprise folks to decide what to do here. I would recommend high-level knobs over low-level knobs and, from a security standpoint, am happy with that option. (Indeed we'd set it by default were it not for the public web still being a bit behind on this one. :-( )

We've had this request come up, and it's been WontFix'd a few times.

An important reason that care has been taken is we've avoided Enterprise settings that increase the risk of a persistent "bricking" of a device or Chrome install (through a bad policy push that prevents future updates) and to ensure that the combinations we need to support and test, both client and server, remain reasonably bounded. For example, we would not want customers to push a configuration that disables all ciphersuites and preventing future configuration updates. Equally, we've seen approaches that would have hindered the ability to deploy and iterate on new protocols, conceptually for the same underlying reasons.

As David notes, a ciphersuite blacklist option exists, via the command-line, which was done intentionally to prevent a bad policy push from being able to brick a device, as modifying the command-line implies an out-of-band configuration mechanism.

@reporter: Does modifying the command-line suffice?

I'd encourage the Enterprise team to concretely document use cases or requests; this has been rare enough that it hasn't yet justified the support cost. From conversations with requestors, it generally has been a misunderstanding/misapplication of server-side rules, rather than client-side rules.

I have been told conflicting about using commandline or "flags".  Additionally, it is difficult to repackage the shortcuts in Google Chrome to have these modified settings.  It would be so much easier to manage via Group Policy.

Not sure why this would affect us.  We currently blocked 5 Cipher Sets already across our IE/Windows stack and would love to do the same to Google Chrome so our end users have the same expected "End User" experience.

"we would not want customers to push a configuration that disables all ciphersuites and preventing future configuration updates. Equally, we've seen approaches that would have hindered the ability to deploy and iterate on new protocols, conceptually for the same underlying reasons"

Looping in the right folks to discuss this further.

-Phil as owner. Networking team to triage this

We've done so. To reiterate from above:

Exposing the cipher blacklist directly is a bad idea. (As Ryan noted, it brings a risk of bricking the device, and as demonstrated above by the bug reporter's initial cipher list being wrong, it is an error-prone policy.)

A high-level option like SSLWeakRSACiphersEnabled is reasonable, but this is a feature request for an Enterprise policy. We can certainly help implement it, but we don't make the calls about whether we ship particular policies.

That said, one note to the requester:

brink668: Is this primarily due to concerns about padding oracles or forward secrecy? You are *not* fully protected from padding oracles by disabling RSA decryption ciphers on the client. Those problems can also be used to forge ECDHE_RSA signatures (though the attack must be online in that case). The only fix is to either disable RSA decryption ciphers on the *server* OR to fix your server's RSA decryption ciphers to correctly implement the mitigations.

Thanks. I'm going to close this then, but I've opened https://bugs.chromium.org/p/chromium/issues/detail?id=913640 to capture the request for higher-level control

 Issue 913640  has been merged into this issue.