On 04/08/2022 16:12, Chris Adams via mailop wrote:
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)?
SHA1 is used for AEAD algorithms (such as ChaCha-Poly/AES-GCM) merely as
a key derivation algorithm (HKDF), for CBC modes SHA1 is also used for
integrity checks (HMAC) [1].
The usage of sha1 is perfectly secure in the both cases (but not for
certificates signatures, of course!). The choice between
SHA/SHA256/SHA384 is based on the requirements to the transport
constructs, e.g. keys lengths adjustments.
[1]: https://en.wikipedia.org/wiki/Transport_Layer_Security#Data_integrity
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
