No cipher overlap between server and client about chasquid HOT 3 OPEN

Thanks for reporting this!

I've just received an email with no cipher overlap, so the email was rejected. The logged message was:

 STARTTLS failed: 554  5.5.0 Error in TLS handshake: tls: no cipher suite supported by both client and server

Afterwards, I ran chasquid-util domaininfo-remove <domain> which let the next email come through (I assume, as PLAIN)

This is very strange, because the security level check happens after STARTTLS (it is done when processing the MAIL FROM command). So it does not really affect STARTTLS at all, and running domaininfo-remove shouldn't have made a difference.

Are you sure it wasn't a normal client-side retry without STARTTLS that made it work?

I will try to do a test to reproduce this, just in case.

Would it be possible to:

1. Log the ciphers supported by the remote side

If this doesn't introduce a lot of complexity, sure! I need to look into the tls code to check how difficult it is to get this information.

I'll keep this issue open to look into this and will reply once I have given this a try :)

2. Expose a way to enable certain ciphers

While that would be an improvement in some scenarios, it also introduces complexity and risk of accidental misuse. Go's TLS defaults are generally very well managed, and I am worried about making things too easy to misconfigure in insecure ways.

Considering chasquid's goals and general approach to configuration, I think having such an option is not a good idea in this particular case.

Thank you!

from chasquid.

The entire log I got for the transaction was:

May 15 15:07:54 _ conn.go:251        SMTP.Conn xxx.xxx.xxx.129:58698: error: STARTTLS failed: 554  5.5.0 Error in TLS handshake: tls: no cipher suite supported by both client and server
May 15 15:07:54 _ conn.go:270        SMTP.Conn xxx.xxx.xxx.129:58698: error: exiting with error: read tcp xxxxxxxxx.60:25->xxx.xxx.xxx.129:58698: read: connection reset by peer
May 15 15:07:55 _ domaininfo.go:99   DomainInfo /var/lib/chasquid/domaininfo: error: xxxxxxx.com incoming denied: PLAIN < TLS_CLIENT
May 15 15:07:55 _ conn.go:475        SMTP.Conn xxx.xxx.xxx.129:60994: error: security level check for xxxxxxx.com failed (PLAIN)
May 15 15:07:55 _ conn.go:251        SMTP.Conn xxx.xxx.xxx.129:60994: error: MAIL failed: 550  5.7.3 Security level check failed
May 15 15:07:55 xxx.xxx.xxx.129:60994 rejected [email protected] - security level check failed

Which I read as:

• Sender tried to use STARTTLS, failed due to no cipher overlap
• Sender downgrades to PLAIN
• Sender had previously sent TLS email, so PLAIN is rejected

My understanding is that running domaininfo-remove fixed the downgrade aspect of the issue

The idea with enabling 'bad' ciphers was that "bad cipher" >> PLAIN

from chasquid.

The entire log I got for the transaction was:

May 15 15:07:54 _ conn.go:251        SMTP.Conn xxx.xxx.xxx.129:58698: error: STARTTLS failed: 554  5.5.0 Error in TLS handshake: tls: no cipher suite supported by both client and server
May 15 15:07:54 _ conn.go:270        SMTP.Conn xxx.xxx.xxx.129:58698: error: exiting with error: read tcp xxxxxxxxx.60:25->xxx.xxx.xxx.129:58698: read: connection reset by peer
May 15 15:07:55 _ domaininfo.go:99   DomainInfo /var/lib/chasquid/domaininfo: error: xxxxxxx.com incoming denied: PLAIN < TLS_CLIENT
May 15 15:07:55 _ conn.go:475        SMTP.Conn xxx.xxx.xxx.129:60994: error: security level check for xxxxxxx.com failed (PLAIN)
May 15 15:07:55 _ conn.go:251        SMTP.Conn xxx.xxx.xxx.129:60994: error: MAIL failed: 550  5.7.3 Security level check failed
May 15 15:07:55 xxx.xxx.xxx.129:60994 rejected [email protected] - security level check failed

Which I read as:

• Sender tried to use STARTTLS, failed due to no cipher overlap
• Sender downgrades to PLAIN
• Sender had previously sent TLS email, so PLAIN is rejected

My understanding is that running domaininfo-remove fixed the downgrade aspect of the issue

Oh! Then yes, you're absolutely correct.

And just to be super clear: that "Sender had previously sent TLS email, so PLAIN is rejected" is not due to the failed STARTTLS attempt, but a successful STARTTLS at some point in the past.

Do you know anything about the sender? What software they're using? What build/release?

Also what chasquid version are you using, and what Go version was used to build it (if you know)?

The idea with enabling 'bad' ciphers was that "bad cipher" >> PLAIN

In this case, allowing a bad cipher could let an attacker do connection downgrading.

One possibility would be to allow all insecure ciphers, and in the connection tracking have a new "TLS_CLIENT_INSECURE" for when they're used. I'll look into this, although in this case it seems like it wouldn't have prevented the rejection (assuming you saw a successful secure connection before, chasquid would still prevent the downgrade).

Thank you!

from chasquid.