[Solved] June 30 2018 SSL/TLS standard deadline?

Discussions on webmail and the Professional version.
Post Reply
dreniarb
Posts: 316
Joined: Mon Jan 19, 2004 5:00 pm
Location: Marion, IN

[Solved] June 30 2018 SSL/TLS standard deadline?

Post by dreniarb » Fri Apr 27, 2018 8:54 pm

For a while now I've been getting this on my incoming smtp server on perhaps 5% of our incoming mail:

Code: Select all

04/24/18 14:15:09	SMTP-IN	DC5CCA8708F0448EBA63BA089A1FFA1D.MAI	1500	8.31.233.152			220 smtp.mydomain.com - YO YO YO	0	0		
04/24/18 14:15:09	SMTP-IN	DC5CCA8708F0448EBA63BA089A1FFA1D.MAI	1500	8.31.233.152	EHLO	EHLO server109.appriver.com	250-mydomain.com [8.31.233.152], this server offers 5 extensions	148	29		
04/24/18 14:15:09	SMTP-IN	DC5CCA8708F0448EBA63BA089A1FFA1D.MAI	1500	8.31.233.152	STARTTLS	STARTTLS	454 TLS not available due to temporary reason	71	10		
04/24/18 14:15:10	SMTP-IN	DC5CCA8708F0448EBA63BA089A1FFA1D.MAI	1500	8.31.233.152	UNKN		503 Bad sequence of commands	30	13		
I got info from appriver.com that they are upgrading to a new ssl/tls standard. They sent me this link which has a bit more info on it:

https://blog.pcisecuritystandards.org/a ... -early-tls

What is odd is all our outgoing email that happens to go to appriver.com's servers gets through just fine. So I'm curious on a few levels about this:

1. How important/real is this deadline? I can't seem to find any other info about it though I will admit I haven't searched too hard.

2. Is there something I need to do on my end to fix this in our installation of ME?

Any insight and advice is greatly appreciated.
Last edited by dreniarb on Thu May 10, 2018 5:08 am, edited 1 time in total.

f2newmedia
Posts: 6
Joined: Sat Apr 28, 2018 2:55 pm

Re: June 30 2018 SSL/TLS standard deadline?

Post by f2newmedia » Sat Apr 28, 2018 3:38 pm

We are running into this problem, as well, but, in our case, we have a confirmed issue of someone not being able to send to one of our clients. We are currently in communications with AppRiver about this. They've dropped us back to TLS 1.1 for the time being, which works for that one known client, but there may be others we don't know about. Here's what we're seeing:

Their log:
16:14:08.715 4 SMTP sending to weberamerica.com
16:14:08.715 5 DNR-024668(weberamerica.com) MX-request
16:14:08.715 4 DNR-024668(weberamerica.com) MX-request -> udp:[10.238.8.133]:53
16:14:08.715 5 DNR-024668(weberamerica.com) got 55 bytes from [10.238.8.133]:53: 60 5C 81 80 00 01 00 01 00 00 00 00 0C 77 65 62 65 72 61 6D 65 72 69 63 61 03 63 6F 6D 00 00 0F 00 01 C0 0C 00 0F 00 01 00 00 91 7C 00 09 00 0A 04 6D 61 69 6C C0 0C
16:14:08.715 5 DNR-024668(weberamerica.com) MX:OK
16:14:08.715 4 DNR-024668(weberamerica.com) MX[0]: weberamerica.com(pty 10) = mail.weberamerica.com
16:14:08.715 4 SMTP-085751(weberamerica.com) resolving 'mail.weberamerica.com'
16:14:08.715 5 DNR-024669(mail.weberamerica.com) A-request
16:14:08.715 4 DNR-024669(mail.weberamerica.com) A-request -> udp:[10.238.8.135]:53
16:14:08.715 5 DNR-024669(mail.weberamerica.com) got 55 bytes from [10.238.8.135]:53: 60 5D 81 80 00 01 00 01 00 00 00 00 04 6D 61 69 6C 0C 77 65 62 65 72 61 6D 65 72 69 63 61 03 63 6F 6D 00 00 01 00 01 C0 0C 00 01 00 01 00 00 95 01 00 04 CC 0D 65 20
16:14:08.715 5 DNR-024669(mail.weberamerica.com) A:OK
16:14:08.715 4 DNR-024669(mail.weberamerica.com) A[0]: mail.weberamerica.com=[204.13.101.32]
16:14:08.715 4 SMTP-085751(weberamerica.com) connecting [192.168.246.224]:0 -> [204.13.101.32]:25
16:14:08.762 4 SMTP-085751(weberamerica.com) rsp: 220 f2newmedia.net ESMTP MailEnable Service, Version: 8.60--8.60 ready at 04/26/18 15:14:06
16:14:08.762 4 SMTP-085751(weberamerica.com) [192.168.246.224]:50721 -> [204.13.101.32]:25 connected to mail.weberamerica.com(ESMTP)
16:14:08.762 4 SMTP-085751(weberamerica.com) cmd: EHLO server907.appriver.com
16:14:08.793 4 SMTP-085751(weberamerica.com) rsp: 250-f2newmedia.net [204.232.250.39], this server offers 7 extensions
16:14:08.793 4 SMTP-085751(weberamerica.com) rsp: 250-AUTH LOGIN
16:14:08.793 4 SMTP-085751(weberamerica.com) rsp: 250-SIZE 20480000
16:14:08.793 4 SMTP-085751(weberamerica.com) rsp: 250-HELP
16:14:08.793 4 SMTP-085751(weberamerica.com) rsp: 250-AUTH=LOGIN
16:14:08.793 4 SMTP-085751(weberamerica.com) rsp: 250-STARTTLS
16:14:08.793 4 SMTP-085751(weberamerica.com) rsp: 250-XSAVETOSENT
16:14:08.793 4 SMTP-085751(weberamerica.com) rsp: 250 X-SAVETOSENT
16:14:08.793 4 SMTP-085751(weberamerica.com) Connected. SIZE TLS AUTH
16:14:08.793 4 SMTP-085751(weberamerica.com) starting TLS(optional)
16:14:08.793 4 SMTP-085751(weberamerica.com) cmd: STARTTLS
16:14:08.824 4 SMTP-085751(weberamerica.com) rsp: 220 Ready to start TLS
16:14:08.856 3 SMTP-085751(weberamerica.com) failed to establish a secure connection with [204.13.101.32]:25. Error Code=TLS record version is not 3.x
16:14:08.856 4 SMTP-085751(weberamerica.com) cmd: RSET
16:14:08.949 4 SMTP-085751(weberamerica.com) rsp: 503 Bad sequence of commands
16:14:08.949 4 SMTP(weberamerica.com) re-enqueue
16:14:08.949 4 SMTP-085751(weberamerica.com) closing connection
16:14:08.949 4 SMTP-085751(weberamerica.com) releasing stream

Our log:
04/26/18 16:14:09 SMTP-IN 88B65018A4944699A18D4D9AC4DE9062.MAI 2868 204.232.250.38 220 f2newmedia.net ESMTP MailEnable Service, Version: 8.60--8.60 ready at 04/26/18 16:14:09 0 0
04/26/18 16:14:09 SMTP-IN 88B65018A4944699A18D4D9AC4DE9062.MAI 2868 204.232.250.38 EHLO EHLO server907.appriver.com 250-f2newmedia.net [204.232.250.38], this server offers 7 extensions 180 29
04/26/18 16:14:09 SMTP-IN 88B65018A4944699A18D4D9AC4DE9062.MAI 2868 204.232.250.38 STARTTLS STARTTLS 454 TLS not available due to temporary reason 71 10
04/26/18 16:14:09 SMTP-IN 88B65018A4944699A18D4D9AC4DE9062.MAI 2868 204.232.250.38 UNKN 503 Bad sequence of commands 30 13

Schannel gives the following error in Event Viewer:
An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.

Here are the ciphers we have in place:
ciphers.png
ciphers.png (54.91 KiB) Viewed 10329 times
We're currently running ME Enterprise 8.6 on Windows Server 2012R2 and have had TLS/SSL up and running for SMTP, POP3, & IMAP for a while. We require it for ports 995, 993, & 465, but not for port 25, which is where this issue seems to lie. I'm assuming that if we have any clients using port 25, and switch it to "Require SSL", they would be unable to connect until they change their settings, correct? As I understand it, STARTTLS should allow a connection to be either encrypted or unencrypted, and telnet indicates STARTTLS is offered, but it doesn't appear to do anything. OpenSSL returns the following when SSL is not required on port 25 (but works fine on the SSL-required port):

C:\Users\bj>openssl s_client -showcerts -connect f2newmedia.net:25
CONNECTED(00000210)
17676:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 308 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1524929329
Timeout : 300 (sec)
Verify return code: 0 (ok)
---

Any help on figuring this out would be appreciated.

dreniarb
Posts: 316
Joined: Mon Jan 19, 2004 5:00 pm
Location: Marion, IN

Re: June 30 2018 SSL/TLS standard deadline?

Post by dreniarb » Sat Apr 28, 2018 3:47 pm

Here is a bit more info from appriver.com. This is what their mail server is returning in the logs:

Code: Select all

16:15:46.390 4 SMTP-324216(mydomain.com) cmd: EHLO server109.appriver.com
16:15:46.468 4 SMTP-324216(mydomain.com) rsp: 250 STARTTLS
16:15:46.468 4 SMTP-324216(mydomain.com) Connected. SIZE TLS AUTH
16:15:46.468 4 SMTP-324216(mydomain.com) starting TLS(optional)
16:15:46.468 4 SMTP-324216(mydomain.com) cmd: STARTTLS
16:15:46.515 4 SMTP-324216(mydomain.com) rsp: 220 Ready to start TLS
16:15:46.515 4 SMTP-324216 TLSvX h-out (174): client_hello
16:15:46.577 3 SMTP-324216 TLS inp: bad header: 34 35 34 20 54
16:15:46.577 3 SMTP-324216(mydomain.com) failed to establish a secure connection with [123.123.123.123]:25. Error Code=TLS record version

dreniarb
Posts: 316
Joined: Mon Jan 19, 2004 5:00 pm
Location: Marion, IN

Re: June 30 2018 SSL/TLS standard deadline?

Post by dreniarb » Mon Apr 30, 2018 1:32 am

A colleague of mine that also runs Mailenable received this info from tech support:
It is not new TLS/SSL protocols then, just that older ones are being discontinued and will not be compliant. You can configure your server already to do this by disabling TLS 1.0 and SSL 3.0 in Windows. See:

https://support.microsoft.com/en-au/hel ... t-informat

Our SSL/TLS uses Windows schannel, so basically just follows what you have enabled/disabled on the server.
I backed up the registry first and then made the suggested change:
Click Start, click Run, type regedt32 or type regedit, and then click OK.
In Registry Editor, locate the following registry key:

HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols\PCT 1.0\Server
On the Edit menu, click Add Value.
In the Data Type list, click DWORD.
In the Value Name box, type Enabled, and then click OK.


Note If this value is present, double-click the value to edit its current value.
Type 00000000 in Binary Editor to set the value of the new key equal to "0".
Click OK. Restart the computer.
However once i did that my Windows 7 clients (using Outlook 2010, 2016, and Windows Live Mail, and Androids) could no longer send email via SSL/TLS. I restored the registry setting and immediate they could send again.

I have a second ME installation that I administer that acts as a front end to Exchange - so no clients actually send through it. I made the registry change on it and while mail flow seems to work just fine (i don't have anyone that uses appriver.com to do tests with this weekend) when I run TLS tests on https://luxsci.com/extranet/tlschecker.html and ssl-tools.net this particular mail server fails the test - both sites says they can't connect via TLS. However the other mail server that hasn't had the registry change passes these tests just fine.

This is all quite confusing to me and the lack of info online about this is frustrating. I do hope ME tech support can shed some light on all of this. I'd like to have my mail servers tightened up as much as possible but I also need my clients to be able to retrieve their email. :/

f2newmedia
Posts: 6
Joined: Sat Apr 28, 2018 2:55 pm

Re: June 30 2018 SSL/TLS standard deadline?

Post by f2newmedia » Mon Apr 30, 2018 1:56 pm

The June 30th date *is* about disabling SSL and TLS 1.0, but what's happening at AppRiver is an upgrade of all their mail servers to TLS 1.2, without an automatic fallback to TLS 1.1, and the TLS 1.2 servers don't appear to play well with MailEnable.

We've had SSL and TLS 1.0 disabled on our server for a while without any issues with our customers, as long as they're configured correctly (SSL/TLS, rather than STARTTLS). However, a lot of our users use the web interface and some aren't using the secure ports for SMTP/POP/etc., so we may just not have any clients with the configuration you're having trouble with.

One thing I found very helpful in configuring SChannel on the server was this little app:

https://www.nartac.com/Products/IISCrypto/

It makes it much easier to disable protocols, ciphers, etc., and also allows you to save out your current configuration before making changes. It also has a best practices template that you can use to bring your server up to current standards. If you have a web server, you can test your current status and changes using this:

https://www.ssllabs.com/ssltest/

f2newmedia
Posts: 6
Joined: Sat Apr 28, 2018 2:55 pm

Re: June 30 2018 SSL/TLS standard deadline?

Post by f2newmedia » Mon Apr 30, 2018 8:49 pm

I will retract my statement about STARTTLS, as I was using OpenSSL incorrectly, without the necessary "-starttls smtp" flag. It appears to work just fine.

dreniarb
Posts: 316
Joined: Mon Jan 19, 2004 5:00 pm
Location: Marion, IN

Re: June 30 2018 SSL/TLS standard deadline?

Post by dreniarb » Tue May 01, 2018 2:32 pm

Thanks for the info. I will give that tool a try as soon as I get the chance.

dreniarb
Posts: 316
Joined: Mon Jan 19, 2004 5:00 pm
Location: Marion, IN

Re: June 30 2018 SSL/TLS standard deadline?

Post by dreniarb » Fri May 04, 2018 3:01 pm

Unfortunately this did not make a difference. As far as I can see I have everything configured correctly yet appriver.com and a few other mail servers are not able to send us email. I also ran a test from this site:

https://www.wormly.com/test-smtp-server

And get the same error:

454 TLS not available due to temporary reason

I was hoping to get some help from tech support here in the forums so that anyone else running into these problems could benefit from it. I will contact them directly and report back here once the problem is fixed.

f2newmedia
Posts: 6
Joined: Sat Apr 28, 2018 2:55 pm

Re: June 30 2018 SSL/TLS standard deadline?

Post by f2newmedia » Fri May 04, 2018 3:51 pm

From AppRiver:
The issue does seem to be with shared ciphers, and our engineers are testing a new version of TLS for our smarthosts that includes additional ciphers. Once that testing is done, we will roll it out to all of our servers hopefully fixing the issue.
We had a client's client send us a test message both to our server and to GMail. It didn't make it to our server, but it did make it to GMail. According to the headers in that message, the cipher used was "ECDHE-RSA-AES128-GCM-SHA256". It appears that while Windows supports ECDHD and GCM, it doesn't support it with RSA ( https://security.stackexchange.com/ques ... pher-ecdhe ). How a major provider like AppRiver went ahead with a cipher set incompatible with Windows, I have no idea.

So this appears to be an issue of incompatible ciphers between AppRiver and Windows, with ME being an innocent victim. Hopefully the Appriver cipher rollout will fix this. Until then, if you can contact AppRiver (or have the AppRiver clients with issues contact AppRiver) and have them route any messages from @sendersdomain.com to @recieversdomain.com through their TLS 1.1 servers, that should fix specific problems, for now. But, they can't do a general reroute for all traffic to a server, so this doesn't help unless you already know both domains. And, I don't know about any other providers.

dreniarb
Posts: 316
Joined: Mon Jan 19, 2004 5:00 pm
Location: Marion, IN

Re: June 30 2018 SSL/TLS standard deadline?

Post by dreniarb » Fri May 04, 2018 4:35 pm

This is good info. I appreciate all the help you have been.

I agree, it is pretty crazy that they are using something that can't talk to a Windows server. I know we're not the majority but there are plenty of us out there.

The appriver user that is trying to email us has already been told by appriver that they are routing emails to us through a tls 1.1 server, but it appears that's not the case. I've forwarded more info to them about it but that's about all I can do. ---- edited update - i heard from the appriver user and they are able to email the one single person on our end that they were having trouble with. so apparently instead of routing all *@ourdomain.com emails through their tls 1.1 server they are just routing 1specificuser@ourdomain.com through their tls 1.1 servers. lovely. :)

Wormly must be having the same issue as appriver. Explains why I've passed most of the other tests I've run.

Well - it's nice to know that this is out of my hands at the moment. Still frustrating though.

f2newmedia
Posts: 6
Joined: Sat Apr 28, 2018 2:55 pm

Re: June 30 2018 SSL/TLS standard deadline?

Post by f2newmedia » Fri May 04, 2018 6:35 pm

Glad I could be of help. :D I definitely share your frustration. Crossing my fingers that they get the long-term solution to work.

Admin
Site Admin
Posts: 804
Joined: Mon Jun 10, 2002 6:31 pm
Location: Melbourne, Victoria, Australia

Re: June 30 2018 SSL/TLS standard deadline?

Post by Admin » Sat May 05, 2018 1:04 am

Hi,

When TLS 1.2 is used, the client sends extra data in the signature algorithms extension. It looks like the ones AppRiver sends are not compatible with the Comodo wildcard certificates. TLS 1.1 does not have this extension, which is why disabling TLS 1.2 works. We have not yet examined a capture of send yet to see what is sent in this extension. Either way, we are a bit restricted on what we can do, since it would need a certificate change or an AppRiver change to resolve (apart from program changes like preventing TLS 1.2 for their IP addresses, etc.).

dreniarb
Posts: 316
Joined: Mon Jan 19, 2004 5:00 pm
Location: Marion, IN

Re: June 30 2018 SSL/TLS standard deadline?

Post by dreniarb » Wed May 09, 2018 2:39 am

After hearing back from ME tech support they recommended setting this registry key to 1:

HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled

After rebooting we are now able to receive email via TLS from appriver.com.

f2newmedia
Posts: 6
Joined: Sat Apr 28, 2018 2:55 pm

Re: June 30 2018 SSL/TLS standard deadline?

Post by f2newmedia » Wed May 09, 2018 10:50 pm

Looks like on May 4th, AppRiver updated their ciphers, as, with no modifications on our server, one minute server518.appriver.com (a TLS 1.2 server) is giving errors in the logs, the next it is not, and hasn't since.

Although I'm not expert enough to be sure, it looks like what that setting does is essentially what we were trying to do with IISCrypto, only, a) it does it automagically, and b) in addition to disabling old ciphers, it also disables new, as-yet-not-govt-sanctioned, possibly faster ciphers. Although, that may be restricted mainly to .NET programs.

Here's a link, if you're interested:
https://blogs.technet.microsoft.com/sec ... e-anymore/

dreniarb
Posts: 316
Joined: Mon Jan 19, 2004 5:00 pm
Location: Marion, IN

Re: June 30 2018 SSL/TLS standard deadline?

Post by dreniarb » Thu May 10, 2018 5:06 am

So interesting. I'm all for increasing security and getting rid of insecure methods but man is it difficult to keep up with.

Of course I can't imagine how stressful it is for web and mail server developers. I don't envy themm.

Thanks for the link.

Post Reply