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

net/base/ssl_config_service.h

 // Copyright (c) 2006-2009 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef NET_BASE_SSL_CONFIG_SERVICE_H_
 #define NET_BASE_SSL_CONFIG_SERVICE_H_
 #pragma once
 
 #include <vector>
 
+#include "base/basictypes.h"
 #include "base/observer_list.h"
 #include "base/ref_counted.h"
 #include "net/base/x509_certificate.h"
 
 namespace net {
 
 // A collection of SSL-related configuration settings.
 struct SSLConfig {
   // Default to revocation checking.
   // Default to SSL 2.0 off, SSL 3.0 on, and TLS 1.0 on.
   SSLConfig();
   ~SSLConfig();
 
   bool rev_checking_enabled;  // True if server certificate revocation
                               // checking is enabled.
   bool ssl2_enabled;  // True if SSL 2.0 is enabled.
   bool ssl3_enabled;  // True if SSL 3.0 is enabled.
   bool tls1_enabled;  // True if TLS 1.0 is enabled.
   bool dnssec_enabled;  // True if we'll accept DNSSEC chains in certificates.
   bool snap_start_enabled;  // True if we'll try Snap Start handshakes.
   // 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
   // connection that we believe that we have based on the hostname. Therefore,
   // certain certificate checks can't be performed and we can't use outside
   // knowledge about whether the server has the renegotiation extension.
   bool mitm_proxies_allowed;
 
   bool false_start_enabled;  // True if we'll use TLS False Start.
 
@@ skipping 124 matching lines @@
   void ProcessConfigUpdate(const SSLConfig& orig_config,
                            const SSLConfig& new_config);
 
  private:
   ObserverList<Observer> observer_list_;
 };
 
 }  // namespace net
 
 #endif  // NET_BASE_SSL_CONFIG_SERVICE_H_