I ran into an issue at $DAYJOB where we had a hard-coded TLS version and ciphersuite set connecting to Google (specifically aspmx.l.google.com). The problem turned out to be a library upgrade had disabled SHA1, so the TLS hello handshake failed.
Here's an example to reproduce it with gnutls-cli: $ gnutls-cli --priority=NORMAL:-VERS-ALL:+VERS-TLS1.2:-MAC-ALL:+SHA384:+SHA256 --starttls-proto=smtp aspmx.l.google.com:25 Processed 148 CA certificate(s). Resolving 'aspmx.l.google.com:25'... Connecting to '2607:f8b0:4002:c08::1a:25'... *** Fatal error: A TLS fatal alert has been received. *** Received alert [40]: Handshake failed If you add ":+SHA1" at the end of the priority string, it connects successfully (and uses SHA1). Oddly, if I nmap scan what ciphers appear to work with TLSv1.2, there are SHA256 and SHA384 ciphers available (and were in our hard-coded list). From an nmap: | TLSv1.2: | ciphers: | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A So is there a bug on Google's side forcing SHA1, or am I missing something (which is quite possible, getting into obscure bits of TLS does trip me up)? -- Chris Adams <c...@cmadams.net> _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop