ASUS/Merlin emails can only do TLS1.0

[bllfr0g]

I've got an RT-AC86U running 384.5.

I have my own email server, and recently decided to disable TLS1.0 for traffic to port 587, which is what I use for the RT-AC86U to send me email alerts. I noticed that I wasn't getting alerts any more, and have since confirmed that the router can send emails using STARTTLS with TLS1.0, but it doesn't seem to be able to handle TLS1.1 or TLS1.2.

Is this a known issue? Is it something that could be addressed in merlin's firmware or is it Asus closed-source?

I'm using the "email" executable to reproduce these results.

 

[RMerlin]

It's possible that the email client doesn't support it. It's a third party component, it's not developped either by Asus or myself, and its author hasn't updated it in over a year now. In that case, try using curl instead.

 

[sfx2000]

It's possible that the email client doesn't support it. It's a third party component, it's not developped either by Asus or myself, and its author hasn't updated it in over a year now. In that case, try using curl instead.

Yes - and many embedded SMTP agents might not support TLS 1.1 or later...

TLS 1.0 is still safe for sending out...

 

[bllfr0g]

Yes - and many embedded SMTP agents might not support TLS 1.1 or later...

TLS 1.0 is still safe for sending out...

I think it's debatable whether or not TLS 1.0 is okay for authenticated SMTP. I agree that it's still a good idea to leave TLS 1.0 enabled on port 25 (and I do), but I don't want it on port 587 if I can get away with it.

That said, I looked through the source for the "email" executable on github and found where it hardcodes the selection of TLS 1.0. It wouldn't be hard to change that code to try 1.2, 1.1, 1.0 in order. BUT... I found a better workaround. email can be told to use the sendmail executable (which is implemented by busybox) for sending mails, and sendmail gives the option to specify a "connection handler." Using s_client from openssl and the connection handler I can get it to do what I want. Example /etc/email.com:

SENDMAIL_BIN = "/usr/sbin/sendmail -t -f bleh@bleh.com -H 'exec openssl s_client -quiet -starttls smtp -connect bleh.com:587 -no_ssl3 -no_tls1' -au'username' -ap'password'"
MY_NAME = 'me'
MY_EMAIL = 'bleh@blhe.com'



Now my emails from the router get sent using modern TLS.

 

[Fitz Mutch]

... Now my emails from the router get sent using modern TLS.

Why does it happen to me?

1077527472:error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol:s23_clnt.c:767:
sendmail: helper exited (1)

 

[bllfr0g]

Can you post your email.conf file?

 

[Fitz Mutch]

Can you post your email.conf file?

I don't use the email.conf, instead I did exactly your example. Is it the SMTP server that is the problem? It belongs to my ISP. The SMTP server and E-mail names down below are faked because it's only an example.

export FROM="Me <horse@whitehouse.gov>"
export TO="Everyone <biglist0009432@gmail.com>"
export FROM_RAW="$(echo $FROM | sed -r 's/.*<(.*)>.*/\1/')"
export HOSTNAME="RT-AC68U-XXXX"
(
   echo "From: $FROM"
   echo "To: $TO"
   echo "Subject: $HOSTNAME UPS 1 Power Failure !!!"
   echo " "
   echo "The system is going down in 10 seconds. Please log off now."
   echo " "
) | sendmail -t -f $FROM_RAW -H 'exec openssl s_client -quiet -starttls smtp -connect smtp.whitehouse.gov:587 -no_ssl3 -no_tls1' -au'horse' -ap'bigsecret'

However, when I pump the same message into this command it works 100%.

sendmail -t -S smtp.whitehouse.gov:25 -f $FROM_RAW

 

[bllfr0g]

Do you know for sure that your ISP supports TLS on port 587? Running a script like testssl.sh is an easy way to find out.

 

[Fitz Mutch]

Do you know for sure that your ISP supports TLS on port 587? Running a script like testssl.sh is an easy way to find out.

My ISP is an old, family-owned business in a small town. Here is the results of the testssl.sh test.

# ./testssl.sh -t=smtp smtp.whitehouse.gov:587

 Service set:            STARTTLS via SMTP

 Testing protocols via sockets 

 SSLv2      not offered (OK)
 SSLv3      offered (NOT ok)
 TLS 1      offered
 TLS 1.1    not offered
 TLS 1.2    not offered
 SPDY/NPN   (SPDY is an HTTP protocol and thus not tested here)
 HTTP2/ALPN (HTTP/2 is a HTTP protocol and thus not tested here)


 Testing ~standard cipher categories 

 NULL ciphers (no encryption)                  not offered (OK)
 Anonymous NULL Ciphers (no authentication)    offered (NOT ok)
 Export ciphers (w/o ADH+NULL)                 not offered (OK)
 LOW: 64 Bit + DES encryption (w/o export)     not offered (OK)
 Weak 128 Bit ciphers (SEED, IDEA, RC[2,4])    offered (NOT ok)
 Triple DES Ciphers (Medium)                   offered
 High encryption (AES+Camellia, no AEAD)       offered (OK)
 Strong encryption (AEAD ciphers)              not offered

 ...

 ...

 Testing server preferences 

 Has server cipher order?     nope (NOT ok)
 Negotiated protocol          TLSv1
 Negotiated cipher            DHE-RSA-AES256-SHA (your /usr/bin/openssl cannot show DH bits) (limited sense as client will pick)
 Negotiated cipher per proto  (limited sense as client will pick)
     DHE-RSA-AES256-SHA:            SSLv3, TLSv1
 No further cipher order check has been done as order is determined by the client

 ...

 Testing vulnerabilities 

 Heartbleed (CVE-2014-0160)                not vulnerable (OK), no heartbeat extension
 CCS (CVE-2014-0224)                       not vulnerable (OK)
 Ticketbleed (CVE-2016-9244), experiment.  --   (applicable only for HTTPS)
 Secure Renegotiation (CVE-2009-3555)      not vulnerable (OK)
 Secure Client-Initiated Renegotiation     VULNERABLE (NOT ok), potential DoS threat
 CRIME, TLS (CVE-2012-4929)                not vulnerable (OK) (not using HTTP anyway)
 POODLE, SSL (CVE-2014-3566)               VULNERABLE (NOT ok), uses SSLv3+CBC (check TLS_FALLBACK_SCSV mitigation below)
 TLS_FALLBACK_SCSV (RFC 7507)              Downgrade attack prevention NOT supported and vulnerable to POODLE SSL
 SWEET32 (CVE-2016-2183, CVE-2016-6329)    VULNERABLE, uses 64 bit block ciphers
 FREAK (CVE-2015-0204)                     VULNERABLE (NOT ok), uses EXPORT RSA ciphers
 DROWN (CVE-2016-0800, CVE-2016-0703)      not vulnerable on this host and port (OK)
                                           make sure you don't use this certificate elsewhere with SSLv2 enabled services
                                           https://censys.io/ipv4?q=351C0E3EEC52BE01E3C144901E3A9810066A7496CE89A09C177A01E7A357C6F9 could help you to find out
 LOGJAM (CVE-2015-4000), experimental      VULNERABLE (NOT ok): uses DH EXPORT ciphers
                                           VULNERABLE (NOT ok): common prime postfix builtin detected (1024 bits)
 BEAST (CVE-2011-3389)                     SSL3: DHE-RSA-AES256-SHA ADH-AES256-SHA AES256-SHA DHE-RSA-AES128-SHA ADH-AES128-SHA AES128-SHA
                                                 EDH-RSA-DES-CBC3-SHA ADH-DES-CBC3-SHA DES-CBC3-SHA  EDH-RSA-DES-CBC-SHA ADH-DES-CBC-SHA
                                                 DES-CBC-SHA EXP-EDH-RSA-DES-CBC-SHA EXP-ADH-DES-CBC-SHA EXP-DES-CBC-SHA EXP-RC2-CBC-MD5
                                           TLS1: DHE-RSA-AES256-SHA ADH-AES256-SHA AES256-SHA DHE-RSA-AES128-SHA ADH-AES128-SHA AES128-SHA
                                                 EDH-RSA-DES-CBC3-SHA ADH-DES-CBC3-SHA DES-CBC3-SHA  EDH-RSA-DES-CBC-SHA ADH-DES-CBC-SHA
                                                 DES-CBC-SHA EXP-EDH-RSA-DES-CBC-SHA EXP-ADH-DES-CBC-SHA EXP-DES-CBC-SHA EXP-RC2-CBC-MD5
                                           VULNERABLE -- and no higher protocols as mitigation supported
 LUCKY13 (CVE-2013-0169), experimental     potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS
 RC4 (CVE-2013-2566, CVE-2015-2808)        VULNERABLE (NOT ok): ADH-RC4-MD5 RC4-SHA RC4-MD5 EXP-ADH-RC4-MD5 EXP-RC4-MD5 

 ...

 

[bllfr0g]

Well, that explains it. My suggested command line includes:

-no_ssl3 -no_tls1

and your ISP's email server ONLY supports TLS1 and SSLv3. That's pretty embarrassing on their part, actually. SSLv3 is not safe to use. TLSv1,while better, is still about 20 years old and has been much improved upon in TLS1.1 and, especially, TLS1.2. They also support null ciphers, which is really really really bad.


I'd complain to your ISP and tell them they should support modern protocols.

In the meantime, you can make this work if you replace "-no_ssl3 -no_tls1" with "-tls1". That'll at least give you TLSv1.0, which is the best you can do with that server right now.

 

[Fitz Mutch]

... That'll at least give you TLSv1.0, which is the best you can do with that server right now.

After trying it again with "-tls1", it gets farther along:

depth=3 C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority
verify error:num=19:self signed certificate in certificate chain
250 DSN
sendmail:  failed

Also, added the vuln test results in their SMTP server to my previous post. I only use their SMTP server to send power failure alerts for my UPS.

 

[sfx2000]

I think it's debatable whether or not TLS 1.0 is okay for authenticated SMTP. I agree that it's still a good idea to leave TLS 1.0 enabled on port 25 (and I do), but I don't want it on port 587 if I can get away with it.

Authenticated SMTP is going to be on something other that TCP/25 - there's no promises on port 25, and these days, little trust...

TLS1.0 is still sound for authenticating for sendmail and other MTA's - remember with MTA's, you also have SPF/DKIM/DMARC/etc...

 

[Fitz Mutch]

Well, that explains it. My suggested command line includes:

-no_ssl3 -no_tls1

Hooray, it works now. As you stated, my ISP only support TLS1. So, I must use this option instead:

-tls1 -CAfile /rom/etc/ssl/certs/ca-certificates.crt


How to pump a message into sendmail with TLS1.

export FROM="Me <horse@whitehouse.gov>"
export TO="Everyone <biglist0000432@gmail.com>"
export FROM_RAW="$(echo $FROM | sed -r 's/.*<(.*)>.*/\1/')"
export HOSTNAME="RT-AC68U-XXXX"
(
   echo "From: $FROM"
   echo "To: $TO"
   echo "Subject: $HOSTNAME UPS 1 Power Failure !!!"
   echo " "
   echo "The system is going down in 10 seconds. Please log off now."
   echo " "
) | sendmail -t -f $FROM_RAW -H 'exec openssl s_client -quiet -starttls smtp -connect smtp.whitehouse.gov:587 -tls1 -CAfile /rom/etc/ssl/certs/ca-certificates.crt' -au$FROM_RAW -ap'bigsecret'