Hi Walter, On Sunday, 21 January 2024 04:23:34 GMT Walter Dnes wrote: > On Thu, Jan 18, 2024 at 06:42:48PM +0000, Michael wrote > > > openssl s_client -connect smtp.ebox.ca\:587 -starttls smtp -showcerts > > openssl s_client -connect smtp.ebox.ca\:587 -starttls smtp -showcerts > > x.txt > > For output to x.txt, see file x.txt in attachment logs.tgz > > Output to the terminal (stderr ???) is... > ======================================================================== > depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = > Go Daddy Root Certificate Authority - G2 verify return:1 > depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = > http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate > Authority - G2 verify return:1 > depth=0 CN = *.ebox.ca > verify return:1 > 40F73DC2087F0000:error:0A00014D:SSL routines:tls_process_key_exchange:legacy > sigalg disallowed or > unsupported:../openssl-3.0.12/ssl/statem/statem_clnt.c:2254: > ======================================================================== > > That last line about "legacy sigalg disallowed or unsupported:" looks > rather ominous.
I think you have found the cause of the problem. The signature algorithm SHA1 has been deprecated[1], because SHA1 has known weaknesses to some collision and pre-image attacks. Theoretically some evil actor could concoct a rogue certificate which will produce the same SHA1 digest as the Root CA your smtp server is using. Practically, this is of little concern for a Root CA, IF your OS trusts directly the Root CA certificate by having it stored in /etc/ ssl/certs/, or in your user's local store for mutt trusted certificates. Both openssl and gnutls report a successful verification of the certificate chain. > > or with gnutls-cli: > > > > gnutls-cli --starttls-proto smtp smtp.ebox.ca -p 587 > > > > then try to negotiate a connection: > > > > ehlo there > > ... > > Ctrl+D > > > > Gnutls should run starttls and when you enter "Ctrl+D" it will print out > > what > See file y.txt in logs.tgz Same warning shown in y.txt: "... RSA key 2048 bits, signed using RSA-SHA1 (broken!)" > My fibre upgrade is delayed, so I'm testing an unneceassary handoff to > port 587 on cable when an "insecure" handoff to port 25 will do. Sending user authentication credentials in the clear is not advisable for the security conscious. > I just > asked the ISP's direct support to confirm that I'm using the correct > credentials. And one last try at "mutt -d 4". Here's a snippet... > > ======================================================================== > [2024-01-20 23:08:56] mwoh: buf[Subject: Test message 1] is short enough > [2024-01-20 23:08:56] Looking up smtp.ebox.ca... > [2024-01-20 23:08:56] Connecting to smtp.ebox.ca... > [2024-01-20 23:08:56] Connected to smtp.ebox.ca:587 on fd=4 > [2024-01-20 23:08:56] 4< 220 smtp.ebox.ca ESMTP Postfix (Debian/GNU) > [2024-01-20 23:08:56] 4> EHLO waltdnes.org > [2024-01-20 23:08:56] 4< 250-smtp.ebox.ca > [2024-01-20 23:08:56] 4< 250-PIPELINING > [2024-01-20 23:08:56] 4< 250-SIZE 20000000 > [2024-01-20 23:08:56] 4< 250-VRFY > [2024-01-20 23:08:56] 4< 250-ETRN > [2024-01-20 23:08:56] 4< 250-STARTTLS > [2024-01-20 23:08:56] 4< 250-ENHANCEDSTATUSCODES > [2024-01-20 23:08:56] 4< 250-8BITMIME > [2024-01-20 23:08:56] 4< 250 DSN > [2024-01-20 23:08:56] 4> STARTTLS > [2024-01-20 23:08:56] 4< 220 2.0.0 Ready to start TLS > [2024-01-20 23:08:56] gnutls_handshake: A packet with illegal or unsupported > version was received. [2024-01-20 23:08:58] Could not negotiate TLS > connection > ======================================================================== > > "illegal or unsupported version" ominous again. TLS 1.0 was deprecated in 2021 and there have been up to date Root certificates issued by this CA using SHA256[2]. Perhaps the server sysadmins have not yet updated their smtp server's Root CA? Anyway, to take you forward you can: 1. Keyword the latest gnutls package in case the gnutls verification criteria have been loosened. 2. Copy the Root CA into the users ~/ and point muttrc to it: set certificate_file = "~/.mutt/certificates" 3. If everything else fails, having verified yourself the server's Root CA and child certificates are all legit you can set: unset ssl_verify_host Obviously this would not be satisfactory from a security perspective. [1] https://datatracker.ietf.org/doc/html/rfc8996 [2] https://certs.godaddy.com/repository
signature.asc
Description: This is a digitally signed message part.
