Deprecating TLS 1 and TLS 1.1

#1

I found out that mxroute is now requiring at least TLS 1.2 when I started migrating my emails from the ocean server to my new package on echo. Encountered the problem in two instances:

  1. My printer (Samsung CLX-6260FW, weighing 59lbs and meant for medium-sized business) with the latest firmware was clearly working with ocean, but refused to send emails via echo with the same settings. This printer supports clear traffic, SSL (465) and StartTLS (587). Had to select clear traffic on 587 to make it work, and wish that I could have some encryption even if it is better than nothing.

  2. My Unifi controller (running the latest version for my access points) was also likewise working with ocean but not for echo. It only allows me to select to enable SSL or to not enable SSL. Even when I select to not enable SSL, it will still attempt to do StartTLS and fails to negotiate the TLS session. So I can’t send emails at all. :frowning: Any solution here?

#2

I’m afraid I don’t have solutions for that, but it is odd that it was working on the Ocean server. I will need to investigate that, as latest versions of OpenSSL should have removed support for anything prior to TLS 1.2 at this stage and I’d like to make sure that happens properly (as 1.0 and 1.1 are EOL and no longer considered secure).

At this stage it should be considered that anything not using TLS 1.2 is not making a secure connection, and falling back to plain text should be considered the security equivalent. Printers may have to go with a plain text connection, but the unifi controller shouldn’t. It may be worth reaching out to their support to find out why the system is trying to use older libraries.

#5

Thanks for the respose. Yeah, I wouldn’t ask or want you to to run unmaintained code.

What I had envisioned was that openssl would continue to support TLS 1.1, 1.0 (and indeed, SSL) just that they would be disabled by default. And that your MTA would allow you to specify configuration settings. Thus the code would remain maintained and patched as per your current process.

Did a little digging… Exim does indeed allow openssl_options to be specified, and setting this to something like -no_tlsv1 -no_tlsv1_1 might have made it work. But, it seems to be global and can’t be applied specifically to one port. So short of running a separate instance of exim… :frowning:

It seems like there is an openssl MinProtocol setting that is system-wide. Or at least, will need funky config to tell a separate instance of exim to use a separate openssl… at which point, I agree that this is not worth the trouble.

Another idea could be for me to run a local stunnel

#3

I previously verified this to be the case on ocean with:

$ openssl s_client -connect ocean.mxroute.com:465 -tls1
CONNECTED(00000005)
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN
= COMODO RSA Certification Authority
verify return:1
depth=1 C = US, ST = TX, L = Houston, O = "cPanel, Inc.", CN = "cPanel, Inc. Cer
tification Authority"
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = ocean.mxroute.com
verify return:1
---
Certificate chain
 0 s:OU = Domain Control Validated, OU = PositiveSSL, CN = ocean.mxroute.com
   i:C = US, ST = TX, L = Houston, O = "cPanel, Inc.", CN = "cPanel, Inc. Certif
ication Authority"
 1 s:C = US, ST = TX, L = Houston, O = "cPanel, Inc.", CN = "cPanel, Inc. Certif
ication Authority"
   i:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = C
OMODO RSA Certification Authority
 2 s:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = C
OMODO RSA Certification Authority
   i:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust
External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGLTCCBRWgAwIBAgIQSnGGdXZFtNmILczsw28JJjANBgkqhkiG9w0BAQsFADBy
MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVFgxEDAOBgNVBAcTB0hvdXN0b24xFTAT
BgNVBAoTDGNQYW5lbCwgSW5jLjEtMCsGA1UEAxMkY1BhbmVsLCBJbmMuIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MB4XDTE5MDgwNjAwMDAwMFoXDTIwMDgwNTIzNTk1
OVowVTEhMB8GA1UECxMYRG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMRQwEgYDVQQL
EwtQb3NpdGl2ZVNTTDEaMBgGA1UEAxMRb2NlYW4ubXhyb3V0ZS5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9p42hj2cX2Zh2EvvXv4LnuRL7+OJh
2EaHy5LBWf3CywCjlqQLUNy5UjsU8LicmzKyPeAlBDxHC/njwbLJgGGRtkTku3hd
4w6IrBJ0d1lSBm6tX2/yxWCVqZGHfSdC6P/YlZjNwdkoYVl8eEJuxscffDYhwc7W
9HTC8YQRBCo6PT2RlCQ3nKN/9brxurElvUvun8tG2CnPGUjlt0YHcXl3JudjOfPB
z+2BtPwVHQ+P7KJrxxyO8H7gWjRxdMrHiLpwLKz1z9wnd3UIGZ1czgrY+rFS7PGB
VGzFLQqeeui88dcS1Ko7hUZIsykPmAejKlP+Q4BzX1eSZImNG7qRoG8BAgMBAAGj
ggLaMIIC1jAfBgNVHSMEGDAWgBR+A1plQWunfgrhuJ0I6h2OHWrHZTAdBgNVHQ4E
FgQU2Fk5ptcaT1Ff/Bs3bDyVM7D8T0UwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB
/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCME8GA1UdIARIMEYw
OgYLKwYBBAGyMQECAjQwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29t
b2RvLmNvbS9DUFMwCAYGZ4EMAQIBMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j
cmwuY29tb2RvY2EuY29tL2NQYW5lbEluY0NlcnRpZmljYXRpb25BdXRob3JpdHku
Y3JsMH0GCCsGAQUFBwEBBHEwbzBHBggrBgEFBQcwAoY7aHR0cDovL2NydC5jb21v
ZG9jYS5jb20vY1BhbmVsSW5jQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcnQwJAYI
KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAzBgNVHREELDAqghFv
Y2Vhbi5teHJvdXRlLmNvbYIVd3d3Lm9jZWFuLm14cm91dGUuY29tMIIBAgYKKwYB
BAHWeQIEAgSB8wSB8ADuAHUAsh4FzIuizYogTodm+Su5iiUgZ2va+nDnsklTLe+L
kF4AAAFsaQ1irwAABAMARjBEAiAYhEzVrWfqpV5pee2a1ZEBSpn9e6J03tKM/MDa
IWik3gIgTYHlNNEKskIfbPNYUG+VnA/7pQYSPUh9dyKqI17tJjgAdQBep3P531bA
57U2SH3QSeAyepGaDIShEhKEGHWWgXFFWAAAAWxpDWLWAAAEAwBGMEQCIFib4IW4
CPaXb3wtfRY85vIQ/WFhNQj0moDoXAVhxPc0AiByn3V/vLtehlWDYtJca7x5gj5Z
ScW+Zhx9C16Mu/bgUTANBgkqhkiG9w0BAQsFAAOCAQEADkYiA+q/pKf1ZTIdzocc
FjZ/BrFn2iINFDwy3tx4+i6uT/Vh0MPbS/hpGqQy13d/ek9IUKJq5X0BbPX6CfKE
1fYC1aG0mMfq3p4mpj85x6MYnjedV0OQ9FKY7XMjw4QEH7kOv6svsPXhsb2A4Q+Q
s6GpuVzRDIh5gv2igrPdaURutxjl3KM+pqTGrXwfnvVF/BTTq/fJx44FkVYBRBGP
MRs+MdAPrHoOlqidsly86WMEaOUhVXMhokRYGORq3OmdOKuAqrqcnqmXU31ZSeJP
NeBqQr8sDR94Sj22SeOBBaV++QHJObc+bOXnyuVhyARqFydljJC7mn/+H2RMUeXg
+A==
-----END CERTIFICATE-----
subject=OU = Domain Control Validated, OU = PositiveSSL, CN = ocean.mxroute.com

issuer=C = US, ST = TX, L = Houston, O = "cPanel, Inc.", CN = "cPanel, Inc. Certification Authority"

---
No client certificate CA names sent
Peer signing digest: MD5-SHA1
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5033 bytes and written 264 bytes
Verification: OK
---
New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: 02020765A8FAF56C8E45CEF269A8DFE25BCC0EE5E65DE9D9B106D650257E1796
    Session-ID-ctx:
    Master-Key: 3B443566DCA5D798237384CDB7460A3165306F3005314846CA2BE421A3716EBF106923B351AE54C8DE8C53B29F66B716
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1590552137
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
220-ocean.mxroute.com ESMTP Exim 4.93 #2 Wed, 27 May 2020 04:02:26 +0000
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.
quit
221 ocean.mxroute.com closing connection
closed

But I see that it has now been “fixed” on ocean, and the same command does not connect anymore.

I think it is inevitable that there will be old clients which cannot support TLS 1.2. Would you consider opening a non-standard port (say 25465 or whatever) while allows smtps over deprecated TLS versions?

It is better than cleartext yet worse than a modern protocol. The difference between TLS 1.0 or 1.1 and cleartext is much much greater than the difference between “AUTH LOGIN” and “AUTH PLAIN”.

#6

Another idea is to run this simple smtp proxy script:

#4

I’m afraid that would require compiling EOL software and running a separate instance of it at this time. Such an act would please a few, but cause a few others to nail me on the public stage. The cost of doing so would likely be paying an outside developer to come in and build a new backend, for the purpose of risking the security of all customers by intentionally exposing OpenSSL libraries that would never be updated. It’s very important that we keep our servers up to date and not running insecure software, our customers put a lot of faith in us to do this.