Mailing List CGatePro@mail.stalker.com Message #105820
From: James Roman <james.roman@ssaihq.com>
Subject: Re: Error: none of client TLS cipher methods is supported
Date: Thu, 17 Sep 2015 10:37:00 -0400
To: CommuniGate Pro Discussions <CGatePro@mail.stalker.com>
X-Mailer: Apple Mail (2.2104)
I can’t speak definitively about what how it works inside the CommuniGate server. We ran into this problem back in April and I don’t have easy access to log files from that far back, so I’m going from my memory of what one of my peers found. What we learned came just from using the following commands against our server from a CentOS 5 and a CentOS6/7 client:

openssl s_client -connect mailserver.domain.com:25 -starttls smtp
and
openssl s_client -connect mailserver.domain.com:25 -starttls smtp -cipher AES256-SHA

In our case we new the allowed cipher list that the remote user had configured in the sendmail.cf file on their servers, and the OS versions. Given that they were using CentOS 5 and limited to TLS 1.0, the only shared Cipher for TLS 1.0 session would be AES256-SHA. For most Internet senders we would be in the dark about this information, as I expect may be in the situation you face. When we ran the command from a CentOS 6/7 client, our CommuniGate server accepted the handshake and negotiated a TLS v1.2 connection successfully. Without any cipher specified, the handshake would end in an AES256_SHA256 TLS v1.2 session. On CentOS5, without the “-cipher AES256-SHA” argument the handshake would only negotiate with RC4-SHA (an insecure stream cipher, not block cipher). If we forced AES256-SHA, the connection failed, unless we enabled the  “CBC Ciphers for Old TLS”.  

Despite the description in the manual, it only makes sense if "CBC Ciphers for Old TLS” means that normally CBC Ciphers are reserved for use in TLS v1.1 and TLS v1.2. For TLS 1.0, CommuniGate only offers (the less secure) stream ciphers in that case. The only way they are offered in TLS v1.0 is if you force them by enabling that the “CBC Ciphers for Old TLS”. Note that DTLS 1.0 is based on TLS 1.1, and DTLS 1.2 is based on TLS 1.2. Given that Block Ciphers are the only secure option available for TLSv1.0, the "CBC Ciphers for Old TLS” seems like the most secure default, if you plan on supporting TLSv1.0. Since RedHat/CentOS 5 will continue to be supported until March 2017, I don’t think that we have much choice but to set our Oldest Accepted TLS version to TLS 1.0 until then.

References:

Correction: I retract the statements about CommuniGate not separating CBCs from protocols. In fact they obviously are in the case of TLS v1.0. 


On Sep 17, 2015, at 7:00 AM, CommuniGate Pro Discussions <CGatePro@mail.stalker.com> wrote:

From: Tom Rymes <trymes@rymes.com>
Subject: Re: Error: none of client TLS cipher methods is supported
Date: September 16, 2015 at 11:47:35 AM EDT


On 09/16/2015 11:01 AM, James Roman wrote:
Just to correct a statement from an earlier message, to my
understanding, Chaining Block Ciphers (CBC) are a method or mode for
encrypting data. They are coupled with an algorithm, one of which is
AES, for encrypting data in transit.

I believe that CommuniGate doesn’t separate the CBCs (or any other Block
Ciphers) from the protocols in their implementation. None of the Block
Cipher methods published (and approved) in the original RFC can be
considered safe. In that case, from the CommuniGate server’s
perspective, the only safe choice is to only negotiate TLS 1.1 and TLS
1.2. Since the remote server you are speaking with appears to only
support TLS 1.0, you need to allow weak ciphers to make CommuniGate
accept TLS 1.0 traffic. This is kind of like agreeing that we will
communicate using English, but one side is limited to only using a Greek
character set.

Am I correct in understanding that the "CBC Ciphers for old TLS" setting will basically allow AES-256 and other non RFC-compliant ciphers to be used in TLS 1.0 connections?

Similarly, provided that I do not enable the "Weak Ciphers" option, I will not be compromising any security by using a cipher that is considered "not safe"?

My last question is why this connection did not fall back to an unencrypted connection when no suitable cipher could be agreed upon? I thought that the nature of STARTTLS was to allow encryption but also allow a fallback to unencrypted if enryption failed for some reason. Perhaps a setting on one end or the other is preventing the fallback?

Tom

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster