Disable SRP, SHA384, and ECDH (but not ECDHE) cipher suites, to prevent

net/socket/ssl_client_socket_openssl.cc

Index: net/socket/ssl_client_socket_openssl.cc
===================================================================
--- net/socket/ssl_client_socket_openssl.cc	(revision 207033)
+++ net/socket/ssl_client_socket_openssl.cc	(working copy)
@@ -194,7 +194,9 @@
     case SSL_ERROR_WANT_WRITE:
       return ERR_IO_PENDING;
     case SSL_ERROR_SYSCALL:
-      DVLOG(1) << "OpenSSL SYSCALL error, errno " << errno;
+      LOG(ERROR) << "OpenSSL SYSCALL error, earliest error code in "
+                    "error queue: " << ERR_peek_error() << ", errno: "
+                 << errno;

[wtc, 2013/06/19 16:53:53]

Note: I am printing the errno as the original code does. Since we have our
own BIO, I think we probably should query our BIO for the actual socket I/O
error instead.

Also, the SSL_get_error man page says we should consider |rv| (the return
value of SSL_do_handshake(), SSL_read(), SSL_write(), etc.) when
ERR_peek_error()
returns 0. So MapOpenSSLError() probably should also take |rv| as input.

       return ERR_SSL_PROTOCOL_ERROR;
     case SSL_ERROR_SSL:
       return MapOpenSSLErrorSSL();
@@ -530,8 +532,9 @@
   STACK_OF(SSL_CIPHER)* ciphers = SSL_get_ciphers(ssl_);
   DCHECK(ciphers);
   // See SSLConfig::disabled_cipher_suites for description of the suites
-  // disabled by default.
-  std::string command("DEFAULT:!NULL:!aNULL:!IDEA:!FZA");
+  // disabled by default. Note that !SHA384 only removes HMAC-SHA384 cipher
+  // suites, not GCM cipher suites with SHA384 as the handshake hash.
+  std::string command("DEFAULT:!NULL:!aNULL:!IDEA:!FZA:!SRP:!SHA384:!aECDH");

[Ryan Sleevi, 2013/06/18 23:00:34]

Does this also disable SHA-384 from the Signature & Hash Algorithms structure?

I was recently updating the EV policy, and note that Comodo has 3 roots using
SHA-384 (2 using RSA/4096+SHA-384 and 1 using ECC/secp384p1 + SHA-384).

Would this change prevent such certs from being used?

[wtc, 2013/06/19 01:25:16]

No. The supported_signature_algorithms list in OpenSSL is a hardcoded
array:

openssl-1.0.1e/ssl/t1_lib.c:

static unsigned char tls12_sigalgs[] = {
#ifndef OPENSSL_NO_SHA512
        tlsext_sigalg(TLSEXT_hash_sha512)
        tlsext_sigalg(TLSEXT_hash_sha384)
#endif
#ifndef OPENSSL_NO_SHA256
        tlsext_sigalg(TLSEXT_hash_sha256)
        tlsext_sigalg(TLSEXT_hash_sha224)
#endif
#ifndef OPENSSL_NO_SHA
        tlsext_sigalg(TLSEXT_hash_sha1)
#endif
#ifndef OPENSSL_NO_MD5
        tlsext_sigalg_rsa(TLSEXT_hash_md5)
#endif
};

(That array can be declared as const.)

This is confirmed with an experiment. The signature_algorithms
extension in ClientHello still matches that array, with this change
applied:

              extension type signature_algorithms, length [34] = {
   0: 00 20 06 01  06 02 06 03  05 01 05 02  05 03 04 01  | . ..............
  10: 04 02 04 03  03 01 03 02  03 03 02 01  02 02 02 03  | ................
  20: 01 01                                               | ..
              }

The 05 bytes are sha384.

Another evidence is that the OpenSSL cipher list format does not mention
SHA512: http://www.openssl.org/docs/apps/ciphers.html

But sha512 is a valid value for the Signature & Hash Algorithms structure.

   // Walk through all the installed ciphers, seeing if any need to be
   // appended to the cipher removal |command|.
   for (int i = 0; i < sk_SSL_CIPHER_num(ciphers); ++i) {