Re: [gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?

[Michael <confabulate@kintzios.com>]

[-- Attachment #1: Type: text/plain, Size: 4528 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]