Mailing List CGatePro@mail.stalker.com Message #105819
From: Tom Rymes <trymes@rymes.com>
Subject: Re: Error: none of client TLS cipher methods is supported
Date: Wed, 16 Sep 2015 11:47:35 -0400
To: CommuniGate Pro Discussions <CGatePro@mail.stalker.com>
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