"--tls-protocol tlsv1" fails after upgrade to FreeBSD 14.0 about swaks HOT 7 CLOSED

Okay, I believe that I have figured out a workaround...

My MWE /etc/ssl/openssl.cnf:

openssl_conf = default_conf

# Comment out the next line to ignore configuration errors
config_diagnostics = 1

[default_conf]
ssl_conf = ssl_sect

[ ssl_sect ]
system_default = system_default_sect

[ system_default_sect ]
MinProtocol = TLSv1
# Be less secure when negotiating ciphers, verifying certificates, etc.
CipherString = DEFAULT:@SECLEVEL=0

By setting @SECLEVEL=0 I was able to successfully use SWAKS on FreeBSD 14.0 with the following options:

    --port 587 \
    -tls \
    --tls-protocol tlsv1

Given all the examples suggesting @SECLEVEL=1 should be sufficient to downgrade to allow TLSv1, I saw only one reference to lowering that to @SECLEVEL=0 and it worked!

Ubuntu 22.04 - how to set lower SSL security level?

and from the man page for SSL_CTX_set_security_level:

Level 0

    Everything is permitted. This retains compatibility with previous versions of OpenSSL.

Level 1

    The security level corresponds to a minimum of 80 bits of security. Any parameters offering below 80 bits of security are excluded. As a result RSA, DSA and DH keys shorter than 1024 bits and ECC keys shorter than 160 bits are prohibited. All export cipher suites are prohibited since they all offer less than 80 bits of security. SSL version 2 is prohibited. Any cipher suite using MD5 for the MAC is also prohibited.

And so maybe even Level 1 has tightened up security against TLSv1?

Now to try and solve the <initial-response> optional argument being accepted by OpenSMTPd.

from swaks.

I really appreciate the level of detail you have drilled down into.

I maintain a mail server project on Github, docker-mailserver

This is an excellent idea ---one that I will explore further.

It is a (malignant) requirement of the legacy accounting system running on Windows, long orphaned by the vendor, and compiled against some ancient version of .NET that in order for the outbound emailing of Invoices, Purchase Orders, and the like to function, the receiving SMTP server must:

1. Accept TLSv1 connections
2. Accept the <inital-response> argument in the AUTH LOGIN command

And so I have been forced to spin up an Ubuntu 18.10 instance (which has TLSv1 still as an option), and then compile OpenSMTPd 6.8.0p1 on it (which had the fix to accept the AUTH LOGIN <initial-response> syntax in order to satisfy both of these requirements.

SWAKS (on my daily drive FreeBSD machine) has been invaluable in being able to pinpoint these two requirements by scouring the mail logs with tracing switched on. Unfortunately, I haven't been able to find an option that has SWAKS use the <initial-response> version of the AUTH LOGIN command, and so have resorted to manual conversations with the SMTP server with the aid of the recipes at:

SMTP 101: Manual SMTP Sessions

that outline a split telnet initial session and then a followup openssh session, and which I have nearly automated as an expect script.

What we have to do to keep legacy software working until an upgrade+migration can be budgeted and planned for :)

Thank you, again.

from swaks.

I think I recall with a Debian upgrade (perhaps to Bullseye), the OpenSSL config they shipped adjusted the security level, which prevented connections with some cipher suites or lower TLS levels unless you modified that config to relax the security level. I needed to do that for Dovecot at the time.

It may have also become a default with OpenSSL 3.0, not sure (I think I recall reading that they adjusted their policy for the same setting with that release though).

While the ciphersuite may say TLSv1 there, that's where it was introduced but is still compatible with newer TLS versions, but I think it can still affect negotiating connections that don't support TLS 1.2?

Here you go, give this a read and try apply the same to your system? docker-mailserver/docker-mailserver#2193

from swaks.

Thank you for this.

I had adapted the guidance from:

Setting and Verifying TLS min version in Ubuntu 22.04

and the script described at:

Reducing TLS client security requirements on OpenSSL and GnuTLS

which are Ubuntu specific resources, on my client FreeBSD machine, but thus far have been unsuccessful. It very well could me that I am misunderstanding the syntax of the openss.cnf file, and so the above changes are not having the desired effect.

[openssl_init]
providers = provider_sect
ssl_conf = ssl_sect

# List of providers to load
[provider_sect]
default = default_sect

...

[default_sect]
# activate = 1

ssl_conf = ssl_sect

[ ssl_sect ]
system_default = system_default_sect

[ system_default_sect ]
MinProtocol = TLSv1
# Be less secure when negotiating ciphers, verifying certificates, etc.
CipherString = DEFAULT:@SECLEVEL=1

To be clear, I am using SWAKS on my FreeBSD machine to connect to a dedicated Ubuntu 18.10, which I can confirm supports TLSv1, because my testing from a FreeBSD 13.2 was and remains successful. It is just that I cannot seem to get the upgraded FreeBSD 14 machine to "downgrade" to talk TLSv1 to the legacy SMTP server.

ASIDE: I did pinpoint the issue with the legacy accounting system failing to talk to the SMTP server: it uses the (optional) initial-response argument on the AUTH LOGIN command RFC-4954, which the version of OpenSMTPd on the server does not support. So I am still trying to thread the needle with a server that supports TLSv1 and an SMTP server that supports the initial-response argument

from swaks.

Given all the examples suggesting @SECLEVEL=1 should be sufficient to downgrade to allow TLSv1, I saw only one reference to lowering that to @SECLEVEL=0 and it worked!

Are you on OpenSSL 3.0? Like I said I think that release made a change related to this feature, and it may have been to adjust the levels to be more strict 🤷‍♂️

On prior releases @SECLEVEL=1 probably was sufficient.

EDIT: Actually given the Level 1 description you shared, perhaps it was more specific to your dated mail server. It's not seriously still using 512-bit RSA key is it? :(

And so maybe even Level 1 has tightened up security against TLSv1?

If not, it probably will. Pretty sure I've seen RFC in recent year or so calling to mandate TLSv1.2+ or something along those lines.

There's only a few cipher suites prior that are still safe to use IIRC, but TLS 1.0 also has some flaws that make it worse I think? Been a while since I assessed that security.

I maintain a mail server project on Github, docker-mailserver, and while I don't think you can use that with FreeBSD, you could probably relay mail through a modern mail server this way to the outside world. Then you have the flexibility of compatible/secure connections over 587, which can then relay to the aging mail server internally. Likewise it could send mail outbound if it needs to without falling back to unencrypted connections if there's nothing compatible.

EDIT: Ah here we go, we changed to minimum TLS 1.2 here at the end of 2022: docker-mailserver/docker-mailserver#2945

• RFC 8996 (March 2021) deprecated TLS 1.0/1.1
• While the only issue with those cipher suites in particularly seems to be:
  • The SHA-1 HMAC used, however the SHA-1 vulnerabilities I don't think are that applicable here because of HMAC.
  • CBC cipher suite vulnerabilities, especially in the context of TLS 1.0.

from swaks.

@usonianhorizon are you the same person who emailed me about the initial-response issue on 2024-02-05? Would you be willing to open a ticket for the issue? I had never known about the initial-response variation of AUTH, but it would be fairly easy to add. Could you include copy/paste of a session where you're authenticating manual so I have something to work against (obfuscated is fine as long as the structure is correct)

from swaks.

Indeed it was me, John. I'll open up a separate ticket for that issue. Thank you for the help.

Warm regards.

from swaks.