On Thu, 4 Aug 2022 at 17:12, Chris Adams via mailop <mailop@mailop.org> 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.
No, you didn't just disable SHA1. You disabled all MACs except SHA256 and SHA384, including the crucial AEAD MAC for modern GCM ciphers. If in doubt, try the default without your *specific* configuration, that way you can verify your claim: gnutls-cli --priority=NORMAL:-VERS-ALL:+VERS-TLS1.2 --starttls-proto=smtp aspmx.l.google.com:25 > 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 Because with modern SHA256 and SHA384 ciphers (GCM), the MAC is actually AEAD, not SHA256 or SHA384 [1]. So you can add :+AEAD (instead of adding the obsolete :+SHA1), this will fix this particular issue. So actually you disabled GCM ciphers completely, bringing your TLS configuration to the pre-2012 era. And yes, Google still supports SHA1 for misconfigured and obsolete software stacks. However I guess there is no point in supporting CBC ciphers with SHA256/SA384 MACs, because those software stacks supporting SHA256 CBC would probably also support GCM ciphers. OpenSSL 1.0.1 with GCM support was released 10 years ago. Rolling your own very specific and low-level TLS configuration is probably not such a good idea. You could for example use GnuTLS default, specific generic profiles (like NORMAL or PFS), or OS defaults. cheers, lukas [1] https://gnutls.org/manual/html_node/Priority-Strings.html _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
