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

Disable SRP, HMAC-SHA384, and ECDH (but not ECDHE) cipher suites, to
prevent ClientHello from getting too big.

Print more error info when we get SSL_ERROR_SYSCALL.

R=agl@chromium.org,digit@chromium.org,rsleevi@chromium.org
BUG=245500
TEST=none

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207624

[wtc, 2013-06-18 22:18:01]

Without this change, Chrome with OpenSSL advertises 62
cipher suites in ClientHello when TLS 1.2 is enabled.
With this change, it advertises the following 38 cipher
suites:

            cipher_suites[38] = {
                (0xc030) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
                (0xc02c) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
                (0xc014) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
                (0xc00a) TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
                (0x00a3) TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
                (0x009f) TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
                (0x006b) TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
                (0x006a) TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
                (0x0039) TLS_DHE_RSA_WITH_AES_256_CBC_SHA
                (0x0038) TLS_DHE_DSS_WITH_AES_256_CBC_SHA
                (0x009d) TLS_RSA_WITH_AES_256_GCM_SHA384
                (0x003d) TLS_RSA_WITH_AES_256_CBC_SHA256
                (0x0035) TLS_RSA_WITH_AES_256_CBC_SHA
                (0xc012) TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
                (0xc008) TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
                (0x0016) SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
                (0x0013) SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
                (0x000a) SSL_RSA_WITH_3DES_EDE_CBC_SHA
                (0xc02f) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
                (0xc02b) TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
                (0xc027) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
                (0xc023) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
                (0xc013) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
                (0xc009) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
                (0x00a2) TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
                (0x009e) TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
                (0x0067) TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
                (0x0040) TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
                (0x0033) TLS_DHE_RSA_WITH_AES_128_CBC_SHA
                (0x0032) TLS_DHE_DSS_WITH_AES_128_CBC_SHA
                (0x009c) TLS_RSA_WITH_AES_128_GCM_SHA256
                (0x003c) TLS_RSA_WITH_AES_128_CBC_SHA256
                (0x002f) TLS_RSA_WITH_AES_128_CBC_SHA
                (0xc011) TLS_ECDHE_RSA_WITH_RC4_128_SHA
                (0xc007) TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
                (0x0005) SSL_RSA_WITH_RC4_128_SHA
                (0x0004) SSL_RSA_WITH_RC4_128_MD5
                (0x00ff) TLS_EMPTY_RENEGOTIATION_INFO_SCSV
            }

[wtc, 2013-06-18 22:21:13]

Re: SRP: OpenSSL has a build option OPENSSL_NO_SRP to turn
off SRP support at compile time. I didn't go that far in this
CL because Chrome for Android may need to use SRP outside TLS.

[agl, 2013-06-18 22:22:04]

LGTM.

You might want to note that this is only removing HMAC(SHA384) ciphersuites, not
GCM ciphersuites with SHA384 as the handshake hash.

[wtc, 2013-06-18 22:33:23]

On 2013/06/18 22:22:04, agl wrote:
> 
> You might want to note that this is only removing HMAC(SHA384) ciphersuites,
not
> GCM ciphersuites with SHA384 as the handshake hash.

Good idea. I added a comment in patch set 2.

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

https://codereview.chromium.org/17427003/diff/6001/net/socket/ssl_client_sock...
File net/socket/ssl_client_socket_openssl.cc (right):

https://codereview.chromium.org/17427003/diff/6001/net/socket/ssl_client_sock...
net/socket/ssl_client_socket_openssl.cc:537: std::string
command("DEFAULT:!NULL:!aNULL:!IDEA:!FZA:!SRP:!SHA384:!aECDH");
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]

https://codereview.chromium.org/17427003/diff/6001/net/socket/ssl_client_sock...
File net/socket/ssl_client_socket_openssl.cc (right):

https://codereview.chromium.org/17427003/diff/6001/net/socket/ssl_client_sock...
net/socket/ssl_client_socket_openssl.cc:537: std::string
command("DEFAULT:!NULL:!aNULL:!IDEA:!FZA:!SRP:!SHA384:!aECDH");

On 2013/06/18 23:00:34, Ryan Sleevi wrote:
> Does this also disable SHA-384 from the Signature & Hash Algorithms structure?

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.

[Ryan Sleevi, 2013-06-19 01:27:29]

lgtm

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

https://codereview.chromium.org/17427003/diff/6001/net/socket/ssl_client_sock...
File net/socket/ssl_client_socket_openssl.cc (right):

https://codereview.chromium.org/17427003/diff/6001/net/socket/ssl_client_sock...
net/socket/ssl_client_socket_openssl.cc:199: << errno;

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.

[commit-bot: I haz the power, 2013-06-19 16:54:11]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/wtc@chromium.org/17427003/6001

[commit-bot: I haz the power, 2013-06-19 17:04:02]

Step "update" is always a major failure.
Look at the try server FAQ for more details.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac&number...

[commit-bot: I haz the power, 2013-06-20 01:56:03]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/wtc@chromium.org/17427003/6001

[commit-bot: I haz the power, 2013-06-20 23:01:19]

Change committed as 207624