Add a preference and command-line option to disable SSL/TLS cipher suites

Add a preference and command-line option to disable SSL/TLS cipher suites

R=battre
BUG=58831
TEST=unit_tests --gtest_filter=CommandLinePrefStoreTest.DisableSSLCipherSuites:SSLConfigServiceManagerPrefTest.*

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=93778

[Ryan Sleevi, 2011-07-20 05:33:33]

Dominic, since you're an OWNER in chrome/browser/net and chrome/browser/prefs,
would you take a look?

I combined the pref + command-line option into one CL so that it could actually
be tested. Please let me know if you'd rather see separate CLs for switches &
prefs.

The intent is, AFAIK, not to expose any UI. This will be exposed via policy
(assuming policy can manage Local State) for enterprise administration and via
"supported" command-line for power users. Because the primary value is exposing
via policy, I wanted to expose it as a String List, rather than some of the
other net preferences which are just comma-separated strings.

As far as testing, I said "see bug", but have held off updating it to make sure
the design/implementation are sound/acceptable.

To test, I've been using Certicom's SECG ECC test server - http://tls.secg.org/
, as it provides a nice interface to viewing the cipher suites, and is easier
than wiresharking client hellos.

The exact steps are:
1) Navigate to http://tls.secg.org/
2) Click "Connect Now"
3) Choose secp256p1 (the default)
4) Click Continue (link for 1 - 4:
http://tls.secg.org/?action=go&ciphersuite=0&curve=23 )
5) Click "here" to continue ( link: https://tls.secg.org:40023/connect.php )
6) Observe under cipher suites, a list of cipher suites. Some numeric, some
string form. String forms are listed at
http://www.iana.org/assignments/tls-parameters/tls-parameters.xml . Without any
command line flags, see that TLS_RSA_WITH_RC4_128_MD5 (0x0004) and
TLS_RSA_WITH_RC4_128_SHA (0x0005) appear in the list
7) Relaunch chrome with
chrome --cipher-suite-blacklist="0x0004,0x0005"
8) Repeat steps 1-5.
9) Observe that neither TLS_RSA_WITH_RC4_128_MD5 or TLS_RSA_WITH_RC4_128_SHA are
listed.


This seems like something that can/should be unit tested - all the layers
underneath the preference are already. Unfortunately, when looking through
things, I didn't see notice anything similar that I might adopt style from,
which suggests either these things aren't tested or I missed something. If you
happen to know of anything that might provide an example for testing this,
please let me know - as we have the TestServer and it is capable of disabling
cipher suites.

[battre, 2011-07-20 11:16:30]

+wtc for recommendations about unit testing of the SSL part.

http://codereview.chromium.org/7462008/diff/1/chrome/browser/net/ssl_config_s...
File chrome/browser/net/ssl_config_service_manager_pref.cc (right):

http://codereview.chromium.org/7462008/diff/1/chrome/browser/net/ssl_config_s...
chrome/browser/net/ssl_config_service_manager_pref.cc:19: #include
"chrome/common/chrome_notification_types.h"
nit: order

http://codereview.chromium.org/7462008/diff/1/chrome/browser/net/ssl_config_s...
chrome/browser/net/ssl_config_service_manager_pref.cc:156:
RegisterPrefs(local_state);
This introduces an interesting circular dependency. It surprises me that it
works.

Preferences can only be set if they have been registered. If the local_state_
PrefService is created, it calls browser::RegisterLocalState but as far as I can
see, browser::RegisterLocalState does not call
SSLConfigServiceManagerPref::RegisterPrefs. The CommandLinePrefStore that is
part of local_state_ will try to set preferences in local_state_ even though
they have not been registered, yet.

Did you try starting chrome with a command line flag for the
CipherSuiteBlacklist?

The common pattern is to put the registration in browser::RegisterLocalState. I
think I would prefer that, but it might require to modify some unit tests.

http://codereview.chromium.org/7462008/diff/1/chrome/browser/net/ssl_config_s...
chrome/browser/net/ssl_config_service_manager_pref.cc:228:
disabled_cipher_suites_;
nit: single line

http://codereview.chromium.org/7462008/diff/1/chrome/browser/net/ssl_config_s...
chrome/browser/net/ssl_config_service_manager_pref.cc:236:
ListValueToStringVector(value));
nit: single line?

http://codereview.chromium.org/7462008/diff/1/chrome/browser/prefs/command_li...
File chrome/browser/prefs/command_line_pref_store.cc (right):

http://codereview.chromium.org/7462008/diff/1/chrome/browser/prefs/command_li...
chrome/browser/prefs/command_line_pref_store.cc:125: }
Add a unit test to command_line_pref_store_unittest.cc?

http://codereview.chromium.org/7462008/diff/1/chrome/common/chrome_switches.cc
File chrome/common/chrome_switches.cc (right):

http://codereview.chromium.org/7462008/diff/1/chrome/common/chrome_switches.c...
chrome/common/chrome_switches.cc:115: // List of SSL cipher suites to disable.
Nit: "Comma separated list"?

http://codereview.chromium.org/7462008/diff/1/chrome/common/chrome_switches.c...
chrome/common/chrome_switches.cc:116: const char kCipherSuiteBlacklist[ ]       
 = "cipher-suite-blacklist";
nit: space in [ ]

[Ryan Sleevi, 2011-07-21 07:05:12]

battre: Thanks for the feedback! I've uploaded a new version for your review.

Regarding testing, I've added a test to the command-line preference store to
ensure it can parse the comma-separated list out.

The only thing remaining is to add a test for SSLConfigServiceManager[Pref] to
make sure it's correctly parsing the pref into the underlying cipher suites.
Before writing that test, I wanted to run my understanding by you first to make
sure I was going down the right path for testing.

In looking through more of the code, I think the way to test this would be to
use a TestingPrefStore and SetValue() to various different ListValues. Each test
would create an SSLConfigServiceManager with the TestingPrefStore, and then
ensure the SSLConfig from the SSLConfigServiceManager reflects those settings in
their cipher suite forms. Does that sound like the right approach to this?

Everything else should be covered by the existing tests. Parsing and disabling
cipher suites are in net_unittests, the command-line is now handled in this CL.

With the above approach, do you think it will also be necessary to write an
InProcBrowserTest, to test everything integrated, or do you think the above
tests should suffice? I just wasn't sure how much testing is "too much", given
that every test will add to cycle time, and I don't think an InProc test will
add to any coverage, just integration.

http://codereview.chromium.org/7462008/diff/1/chrome/browser/net/ssl_config_s...
File chrome/browser/net/ssl_config_service_manager_pref.cc (right):

http://codereview.chromium.org/7462008/diff/1/chrome/browser/net/ssl_config_s...
chrome/browser/net/ssl_config_service_manager_pref.cc:156:
RegisterPrefs(local_state);
On 2011/07/20 11:16:30, battre wrote:
> This introduces an interesting circular dependency. It surprises me that it
> works.
> 
> Preferences can only be set if they have been registered. If the local_state_
> PrefService is created, it calls browser::RegisterLocalState but as far as I
can
> see, browser::RegisterLocalState does not call
> SSLConfigServiceManagerPref::RegisterPrefs. The CommandLinePrefStore that is
> part of local_state_ will try to set preferences in local_state_ even though
> they have not been registered, yet.
> 
> Did you try starting chrome with a command line flag for the
> CipherSuiteBlacklist?
> 
> The common pattern is to put the registration in browser::RegisterLocalState.
I
> think I would prefer that, but it might require to modify some unit tests.

I was surprised by this as well, when I was reading code to understand how prefs
work. I believe it's a hold-over from when the SSLConfigServiceManager
alternatively returned a manager that dealt with the system vs one that dealt
with preferences.

I did run all the tests I suggested in the note, so it certainly worked and
without any exceptions/errors/DCHECKs. I suspect this may be due to some complex
interactions with the IO thread which results in an SSLConfigServiceManager
being created very early on, perhaps before preferences are loaded/read (or
perhaps a straight up race).

I've pulled out the registration into an explicit static method and added it, as
you suggested. I haven't run into any problems in doing so, but I'm hoping the
tryjob panel will catch anything if this is not the case.

[battre, 2011-07-21 09:00:46]

On 2011/07/21 07:05:12, Ryan Sleevi wrote:
> battre: Thanks for the feedback! I've uploaded a new version for your review.
> 
> Regarding testing, I've added a test to the command-line preference store to
> ensure it can parse the comma-separated list out.
> 
> The only thing remaining is to add a test for SSLConfigServiceManager[Pref] to
> make sure it's correctly parsing the pref into the underlying cipher suites.
> Before writing that test, I wanted to run my understanding by you first to
make
> sure I was going down the right path for testing.
> 
> In looking through more of the code, I think the way to test this would be to
> use a TestingPrefStore and SetValue() to various different ListValues. Each
test
> would create an SSLConfigServiceManager with the TestingPrefStore, and then
> ensure the SSLConfig from the SSLConfigServiceManager reflects those settings
in
> their cipher suite forms. Does that sound like the right approach to this?

Sounds like a good plan to me.

Note that you need a PrefService, not a PrefStore, though. You can do something
like:

TestingPrefService prefs;
SSLConfigServiceManager::RegisterPrefs(&prefs);
scoped_ptr<SSLConfigServiceManager> ssl_config =
SSLConfigServiceManager::CreateDefaultManager(&prefs);
prefs.Set(path, yourlist);

> Everything else should be covered by the existing tests. Parsing and disabling
> cipher suites are in net_unittests, the command-line is now handled in this
CL.
> 
> With the above approach, do you think it will also be necessary to write an
> InProcBrowserTest, to test everything integrated, or do you think the above
> tests should suffice? I just wasn't sure how much testing is "too much", given
> that every test will add to cycle time, and I don't think an InProc test will
> add to any coverage, just integration.

I don't think that is necessary.

Thanks!

Dominic

[Ryan Sleevi, 2011-07-22 07:09:05]

Dominic: As I mentioned on http://codereview.chromium.org/7489004/ , I've split
out the RegisterPrefs changes. As a result, this CL now depends on that CL - for
RegisterPrefs() and for the BrowserThread changes this unit test uses.

This should be everything - so PTAL.

[battre, 2011-07-22 08:44:04]

LGTM if try bots are happy

Thank you.

http://codereview.chromium.org/7462008/diff/1008/chrome/browser/net/ssl_confi...
File chrome/browser/net/ssl_config_service_manager_pref_unittest.cc (right):

http://codereview.chromium.org/7462008/diff/1008/chrome/browser/net/ssl_confi...
chrome/browser/net/ssl_config_service_manager_pref_unittest.cc:28: new
BrowserThread(BrowserThread::UI, message_loop_.get()));
nit: single line (also below)

[Ryan Sleevi, 2011-07-23 04:55:41]

http://codereview.chromium.org/7462008/diff/1008/chrome/browser/net/ssl_confi...
File chrome/browser/net/ssl_config_service_manager_pref_unittest.cc (right):

http://codereview.chromium.org/7462008/diff/1008/chrome/browser/net/ssl_confi...
chrome/browser/net/ssl_config_service_manager_pref_unittest.cc:28: new
BrowserThread(BrowserThread::UI, message_loop_.get()));
On 2011/07/22 08:44:04, battre wrote:
> nit: single line (also below)

Single line is 81 characters, hence the wrapping.