New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 44 users

Issue metadata

Status: Verified
Closed: Dec 2015
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

Sign in to add a comment

Allow individual SSL/TLS ciphersuites to be enabled/disabled

Project Member Reported by, Oct 12 2010 Back to list

Issue description

Currently, Chrome does not offer any interface for enabling or disabling individual SSL/TLS cipher suites, either through the UI or through the administrative policies.

In Chrome 5 and earlier, this could be managed on Windows by configuring the Schannel cipher suites ( ). Since Chrome 6, which saw the switch to NSS as the default SSL library, this is no longer possible, unless either "--use-system-ssl" is specified on the command-line (an unsupported option), or the server requests client certificate authentication (which will cause Chrome to fall back to Schannel).

Currently, there are plans to eliminate the fallback to Schannel ( issue 37560 ), which would also increase the likelihood of "--use-system-ssl" being removed. Once this happens, admins will no longer be able to control or configure cipher suites for regulatory/compliance purposes. 

While cipher suites can be administered on the individual servers being accessed, it is useful in some cases to be able to globally disable this.

Firefox currently offers this feature by means of it's about:config interface, and through administrative preferences files. As previously mentioned, Schannel, which is used by IE, also exposes a series of registry keys.

While I understand that a UI to enable/disable individual cipher suites is unlikely, given that such functionality is typically used in administrative contexts, it seems appropriate to consider it as something to be managed by the Enterprise settings (ADM/ADMX/etc).
It seems to me that the right feature would be the ability to enable/disable individual SSL/TLS cipher suites via group policy.  --use-system-ssl seems too fleeting to add a policy to manage it.  Also related:  bug 53625 
gwilson: I'm sorry if it wasn't clear, that's exactly what I was proposing. --use-system-ssl is going away (maybe, eventually - wtc knows more about the longevity). I'm wholly in favor of a policy and/or UI to enable/disable these.

Also related is  issue 58833 , which deals with relative priorities rather than all-out enabling/disabling.
I should add to the test list:

Safari 5: Does not (as far as I can tell) allow you to enable/disable individual suites.

Opera 10.62: Allows you to enable/disable individual cipher suites

Comment 4 by, Oct 28 2010

The following revision refers to this bug:

r64233 | | Thu Oct 28 04:57:36 PDT 2010

Changed paths:

Add support to to restrict the SSL/TLS bulk encryption algorithms via the command-line argument --ssl-alg.

BUG= 58831 
TEST=Run as an HTTPS server with --ssl-alg=rc4. Connect via openssl s_client -connect -cipher DEFAULT:\!RC4. Observe a connection failure. Connect with openssl s_client -connect, observe that a  ciphersuite that uses RC4 is negotiated.

Review URL:
Labels: -Dev-TestPlan-No Dev-QAReview-No

Comment 6 by, Nov 11 2010

The following revision refers to this bug:

r65773 | | Wed Nov 10 20:12:53 PST 2010

Changed paths:

Add support for restricting the cipher suites that SSLClientSocket(Mac,NSS) use. Restricting SSLClientSocketWin is handled by the existing Windows system policy (which deals in algorithms, not cipher suites).

BUG= 58831 

Review URL:
gwilson: wtc requested that I follow-up some conversation we had in this bug, so I wanted to make sure to do so. If this isn't the best medium, I apologize - I'm a non-Googler committer, so I'm not exactly able to follow-up in person.

The proposed implementation has no UI exposure. Configuring enabled/disabled cipher suites is typically an "advanced" configuration setting, and the primary use case is for regulatory compliance (for example, PCI-DSS or, eventually, FIPS). As such, the preference settings will exist, and will be documented, but won't require any UI work.

The proposed implementation is as follows:

For NSS (Linux, ChromeOS):

Currently uses SSLConfigServiceManagerPref to get the SSL configuration.  ( )
SSLConfigServiceManagerPref in turn gets it's settings from the Profile.

I'm proposing adding a new String List policy for managing the SSL cipher suites, which can be passed as part of the Profile/preferences, called, "ssl.cipher_suites.disabled", to the list of SSL-related policy settings ( ).

The values of the string list will be fully qualified TLS cipher suite names, as they appear at For example, a policy might be:

{ "ssl.cipher_suites.disabled": [ "TLS_RSA_WITH_RC4_128_MD5", "TLS_RSA_WITH_RC4_128_SHA" ] }

Such a policy would leave all other supported cipher suites in their default state, but explicitly disable the two cipher suites above.

For Mac:

Currently uses SSLConfigServiceManagerSystem, which returns an SSLConfigServiceMac.
SSLConfigServiceMac reads application bundle settings ( ). 

I'm proposing adding "org.chromium.ssl.ciphers_suites.disabled", which will be a List of cipher suite strings, with the same behaviour as on NSS.

For Windows:

Currently uses SSLConfigServiceManagerSystem, which returns an SSLConfigServiceWin. SSLConfigServiceWin reads the per-user IE settings in the registry. ( )

I'm proposing adding support for the SCHANNEL registry keys, which control per-machine policies. This corresponds to the Group Policy settings that Microsoft advocated for Windows versions NT - XP, consistent with their FIPS security policy documentation.

Two primary documents exist documenting these - and . These settings control the individual algorithms enabled (which can be masked against cipher suites), as well as the various protocol versions and additional client behaviours not supported in Chrom[e/ium].

The existing supported IE per-user settings are subject to the system-wide SChannel settings - that is, if the IE user enables SSL 3.0, it is not actually enabled unless also enabled via SChannel.

This *WILL NOT* address the Vista+ settings, described at . This is because the Vista/7 settings work as a whitelist, rather than a blacklist. This does not preclude supporting them, however. In addition, even in Vista/7, the legacy SChannel settings are still respected, so the settings are still pushed out by admins as part of their group policies.

This behaviour matches the behaviour of Chrome versions prior to 6. Prior to Chrome 6, the default SSL provider was SChannel, which respected the above registry settings. In 6+, the default SSL provider became NSS, which no longer supported the keys listed, unless performing client authentication, which caused SChannel to be used. In 9+, NSS is used all of the time, unless a command-line flag "--use-system-ssl" is passed. If the flag is passed, SChannel will be used, and the settings are respected. I'm proposing making NSS respect the SChannel settings, so that regardless of which underlying SSL socket is being used, the same list of explicitly disabled cipher suites remain disabled.

For OpenSSL:

Currently controlled by an SSLConfigServiceManagerPref. It will behave the same as NSS.

The above approach seems to match the practice for how policy settings are added, and respects the OS-provided settings when available. Are there any concerns with this approach?

Comment 9 Deleted

Comment 10 by Deleted ...@, Feb 15 2011

I regularly configure web servers and clients for security compliance within the Federal Government of Canada.  The "disable list" approach is opposite to what we would normally require to provide assurance.  We would need to specify a definite list of ciphers that are allowed.  In Canada, this list is maintained by the Communications Security Establishment (CSE) at

Comment 11 by, Feb 15 2011

Blockedon: 67622
Labels: Policy
rsleevi, are you still interested in owning this?  Now that the blocking bugs are resolved, should the enterprise team take this up to add these policies?
Blockedon: -67622
gwilson: Yes, I have several changes needing to be uploaded for review related to this that are implemented - parsing of TLS cipher suite strings ( ), support  whitelisting cipher suites (rather than blacklisting, per comment 10), and better performance for NSS sockets (model FD, per wtc's codereview comments on the net/ portion). Unfortunately, I'm away from my Chromium dev machine for 2 weeks, so I don't expect to be able to get to it until then.

Comment 15 by, Jun 29 2011

As of , the basic infrastructure has landed. This is currently exposed as a command-line preference modifiable via the CommandLinePrefStore, but it should be simple to glue this into one of the PolicyPrefStores / any other pref store.

Like the other SSL variables (SSL, TLS, revocation checking), this is exposed in Local State, not in user/sync'd preferences.

The current format strings are hex literals - ie: [ '0x0004', '0x0005' ].

The preference itself is a List of Strings, chosen to hopefully make it easier to integrate into policy management, particularly Windows' group policies/ADM/ADMX. The command-line version uses a comma-separated list of values which is then translated into a ListValue.

This preference is supported on all platforms when '--use-system-ssl' has not been passed on the command line. If '--use-system-ssl' is passed, this is supported on all platforms but Windows; for Windows with --use-system-ssl, existing group policy management tools are used ( , ).

Remaining issues to be addressed in follow-ups (can split into separate bug if necessary)
 - Allow a more expressive value for cipher strings, using the IANA TLS registry - - eg: TLS_RSA_WITH_AES_256_CBC_SHA instead of 0x0035
 - Allow white-listing cipher suites in addition to/as an alternative to blacklisting cipher suites

Known issues:
 - It's possible to disable every possible cipher-suite, if all of the cipher suites Chrome uses are listed. When this happens, any/all SSL connections will fail. While this is not likely an issue when using command-line options (as it's easy to rectify), I wonder if this may allow a misconfigured policy to brick a device by sending a policy to disable all cipher suites, and then the client can no longer update the policy. Are policies pulled via SSL/TLS? Is this a concern? A variation of this would be to disable all the mutually shared cipher suites with the policy server - so it does not require /all/ cipher suites, just the 'important' ones.
I should also add that it only applies to GCF when it's using the Chrome network stack. If it's using the Host network stack (URLMon, IIRC), then the SChannel settings mentioned are the ones that control this. I believe Official GCF is currently using host network stack for sizing purposes -

This is because, until Windows Vista, it was not possible to disable individual cipher suites on Windows, only bulk encryption algorithms/mac algorithms/signature algorithms, independently (eg: disable all RSA cipher suites)
Status: Assigned
Available + Owner == Default to Assigned
chromium has any plan to port this feature for Android? 
It looks like the focus so far has been on disabling specific ciphers, but there hasn't been any discussion yet on enabling non-default ciphers.

For example, I've been unable to switch to Chrome when using services on wireless networks run by amateur radio operators.  Such networks are not allowed to encrypt communications, so some are using null encryption ciphers to provide authentication-only connections over TLS.

This is already supported by Firefox (about:config / security.ssl3.rsa_null_sha: true) and Opera (Preferences / Advanced / Security / Security Protocols / Details / 0 bit Authentication Only RSA-SHA).  Attached is a screen shot of Opera's warning message when connecting to such sites.

Here's my test site that only offers cipher 0x02 "RSA_WITH_NULL_SHA":

The title of this issue would suggest it's tracking the ability to add as well as remove ciphers.  Should that continue to be the case, or should this be moved to a new issue?
28.8 KB View Download
There are no plans to support unauthenticated ciphersuites, and for now, such issues would be WontFix'd.
The example I used was not about anonymous ciphers, but rather those with authentication-only.  Regardless, it was just an example.

As someone else mentioned earlier, having a way to blacklist specific ciphers would not resolve the issue for those seeking regulatory compliance.  For those situations, they typically require a white list of specifically approved ciphers.  By only providing black-list functionality, you'll effectively void someone's compliance the moment new ciphers are automatically added.

Providing white-list functionality instead would solve the issue for both of those wishing to either add or remove specific ones from consideration.
Project Member

Comment 25 by, Mar 10 2013

Labels: -Area-Internals -Feature-Enterprise -Internals-Network Cr-Internals Cr-Internals-Network Cr-Enterprise

Comment 27 by, Apr 28 2015

This would be great to individually disable ciphers like all old ciphers such as RC4.
a lot of people are using this ("--cipher-suite-blacklist=0x0004,0x0005,0xc007,0xc011") to do exactly that.

Comment 30 by, May 6 2015

Labels: -Cr-Internals
If anyone knows of a way to blacklist ciphers on the Android version of chrome (without rooting the device) I'd love to know it.
#31: i don't think there's any way to do it without root with chrome (requires writing to /data/local/chrome-command-line). if you don't mind using chromium (, you want the chrome-shell.apk from the zip file), you can use adb to put command line options in /data/local/tmp/chrome-shell-command-line, which doesn't require root.
Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner may be inactive (i.e. hasn't fixed an issue in the last 30 days or commented in this particular issue in the last 90 days).  Thanks for helping out!

Labels: -Cr-Internals-Network Cr-Internals-Network-SSL
Given the recent news ( this should probably be reprioritized esp. because there is no simple way to run with --cipher-suite-blacklist in ChromeOS. Thanks!
@35: cipher suites themselves are usually OK. What needs to be done is banning weak key exchange parameters. For example DH is perfectly fine when using dhparam 2048+, so is RSA with 2048+ keys (not PFS, though), and for ECDH we have nice selection of safe curves available here:
RC4 is broken. 3DES is unreasonably slow. those cipher suites are not "OK".
DH only provides forward secrecy if you change the parameters regularly (which no one does). RSA key exchange doesn't provide forward secrecy at all. both are quite far from "perfectly fine".
at this point any cipher suite that doesn't use ECDHE and ChaCha20 or AES is undesireable, and should be disabled if possible.
@37: using weak curve with ECDHE would be as bad as using common 512-1024 bit dhparam in DHE - I see no difference here.

About "cipher suites" - I meant modern cipher suites, like [ECDHE|DHE]-[RSA|ECDSA|EDDSA]-[AES-GCM|CAMELLIA-GCM|CHACHA20-POLY1305] - as long as you use strong parameters they're all fine.

re: ECDHE, that's true, but no chrome doesn't support any weak curves, so that doesn't matter.

and no, DHE is not fine if you just use strong parameters. for it to provide forward secrecy, you have to change the parameters often, and unless you use new 3072-bit or larger parameters for each connection (which is way too slow to be practical), it's still not as good as ECDHE. since the client has no control over the parameters, anyone who wants to require forward secrecy has to disable all non-ECDHE cipher suites.

the point is that there are very good reasons to want to disable certain cipher suites on a schedule that may be a bit ahead of chromium development. enforcing security breaks compatibility, so compromises are made. allowing people to disable individual cipher suites gives them a choice about which of those compromises are acceptable.
Sadly, EdDSA/Ed25519 (mentioned two comments above) is not even implemented yet.
Status: Verified
Marking this as Verified; We're not taking the (optional) next steps described in Comment #16.

Sign in to add a comment