Add support for restricting the cipher suites that SSLClientSocket(Mac,NSS) use

net/base/ssl_config_service.h

Index: net/base/ssl_config_service.h
diff --git a/net/base/ssl_config_service.h b/net/base/ssl_config_service.h
index be50097b9d7b73953c9c9470afea33d19fa62233..0639f4863e4fbc2d9f3657a9be775d88c2e41ded 100644
--- a/net/base/ssl_config_service.h
+++ b/net/base/ssl_config_service.h
@@ -8,6 +8,7 @@
 
 #include <vector>
 
+#include "base/basictypes.h"
 #include "base/observer_list.h"
 #include "base/ref_counted.h"
 #include "net/base/x509_certificate.h"
@@ -31,6 +32,24 @@ struct SSLConfig {
   // True if we'll do async checks for certificate provenance using DNS.
   bool dns_cert_provenance_checking_enabled;
 
+  // Cipher suites which should be explicitly prevented from being used. By
+  // default, all cipher suites supported by the underlying SSL implementation
+  // will be enabled, except for:
+  // - Null encryption cipher suites.
+  // - Weak cipher suites: < 80 bits of security strength.
+  // - FORTEZZA cipher suites (obsolete).
+  // - IDEA cipher suites (RFC 5469 explains why).
+  // - Anonymous cipher suites.
+  //
+  // Though cipher suites are sent in TLS as "uint8 CipherSuite[2]", in
+  // big-endian form, they should be declared in host byte order, with the
+  // first uint8 occupying the most significant byte.
+  // Ex: To disable TLS_RSA_WITH_RC4_128_MD5, specify 0x0004, while to
+  // disable TLS_ECDH_ECDSA_WITH_RC4_128_SHA, specify 0xC002.
+  //
+  // TODO(rsleevi): Not implemented when using OpenSSL or Schannel.
+  std::vector<uint16> disabled_cipher_suites;

[wtc, 2010/11/11 22:04:43]

I wonder if we should specify enabled_cipher_suites instead.
In general, a whitelist is better than a blacklist because
with a blacklist it's less clear exactly what is allowed.
We can interpret an empty enabled_cipher_suites list as
"all secure cipher suites are enabled".

I guess this depends on whether this is used for testing,
or for corporate/government regulation compliance.  For
testing, a whitelist is definitely more convenient.  For
corporate/government crypto regulation compliance, it's
less clear which is better.

[Ryan Sleevi, 2010/11/12 17:05:23]

Right, this is what I was trying to address in that first message.

With opt-in, if any new suite is introduced, it will be hampered by admins who
have it in their enable list. Further, it introduces confusion if/when an
algorithm is decided insecure, but it appears in the enable list - does the
overall Chromium-dictated policy of minimum security win, and it's disabled, or
does it's presence in the enable list really mean that they want to use it
(perhaps a legacy app?)

On the positive side, with opt-in, you can also easily express ordering
preferences (which is where the disconnect for Mac comes from - the API
expresses both enabled + cipher preference order)

With opt-out, it's less clear what will actually be enabled, because it's the
intersection of [NSS supported] - [Chromium disabled] - [policy disabled]. Both
[NSS supported] and [Chromium disabled] may change between releases, so there
isn't a good measure there. It also makes it complicated to express ordering
preferences for those ciphers that remain available.

On the positive side, with opt-out, you can be very surgical with what you're
disabling, rather than having to enumerate the dozens and dozens of cipher
suites that "may" be supported.

I was planning on implementing the policy next, but it sounds like there is
still some lingering concern about the design/implementation. I just want to
confirm you're comfortable enough with this design to continue with the opt-out,
with the possibility of changing it/adding an opt-in later (whitelist +
blacklist approach) if needed.

+
   // True if we allow this connection to be MITM attacked. This sounds a little
   // worse than it is: large networks sometimes MITM attack all SSL connections
   // on egress. We want to know this because we might not have the end-to-end