Re: TLSv1 rejection

Lewis Rosenthal <[email protected]>
Newsgroups gmane.mail.cgatepro.general
Message-ID <[email protected]>
Hi, James. Fancy meeting you, here...


On 01/25/2016 05:22 PM, James Moe wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> linux 4.1.13-5-default x86_64 (opensuse 42.1)
> cgate pro 5.4.11
>
> We recently purchased a Sonicwall SOHO security appliacne (firewall).
> The previous device would send log files to an account on the CGate
> server.
>    The new appliance does not; it fails with an SMTP error.
> Investigation by Sonicwall indicates that the TLSv1 negotiation is the
> cause of the failure.
>    I recall a discussion recently (a few months ago?) about an issue
> with TLSv1 negotiation failing.
>    What was the cause and resolution of that issue?
>
>    (I have looked into the server's documentation. There is no search
> capability, and could see no obvious discussion of SSL.)
>
>
Look up PKI (https://www.communigate.com/communigatepro/PKI.html). In 
addition, in September, Tom Rymes started this thread:

    Error: none of client TLS cipher methods is supported

(Run a web search on the list archives here for a link). The issue there 
was that enabling both:

    CBC Ciphers for old TLS
         Select this setting if you want to support CBC-based cipher
    methods for SSL 3.0 and TLS 1.0 protocols. The CBC-based cipher
    methods are always supported for datagram (DTLS) protocols.


and

    Weak Ciphers
         Select this setting if you want to support weak (less than
    128-bit) security (cipher methods). The CBC Ciphers setting should
    be selected, too."

seemed to resolve the issue of a sender using AES256_SHA not being able 
to get through. Apparently, under normal conditions, CGP only supports 
CBC for TLS 1.1+, and only stream ciphers for TLS 1.0. Enabling the 
first setting allows the use of CBC on TLS 1.0. The interplay between 
the two settings which requires that CBC be enabled for TLS 1.0 in order 
for weak ciphers to be supported is still somewhat foggy for me.

Later, we saw a report that enabling CBC for TLS 1.0 was causing 
difficulty delivering to MS domains (think Office 365), and the post 
from CGP support stated:

    TLS in outgoing SMTP sessions is constrained to version 1.0 because
    of potential problems negotiating 1.1 and up with older SSL/TLS
    implementations. If you sure that negotiating 1.1. or 1.2 won't
    cause problems with remote servers, you can add
    --SMTPOutgoingTLSVersion 2 or --SMTPOutgoingTLSVersion 3 to startup
    options list to allow negotiation of TLS 1.1 and 1.2, respectively.

See the continuation of the previous thread, entitled: HEADS UP: If 
you're queueing to Office365 domains (was Re: Error: none of client TLS 
cipher methods is supported).

FWIW, my own startup settings on 5.4.10 on OS/2 utilize the 
-TLSServerHelloExtensions option.

See:

https://support.communigate.com/tickets/kb_article.php?ref=3800-SGHN-9936
https://support.communigate.com/tickets/kb_article.php?ref=2558-RPGZ-2772

(which may or may not be relevant to your CGP version)

(I also have weak ciphers disabled, accept SSLv2 'hello' enabled, and 
Process Target Domain extensions enabled.)

HTH

-- 
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA
Rosenthal & Rosenthal, LLC                www.2rosenthals.com
visit my IT blog                www.2rosenthals.net/wordpress
IRS Circular 230 Disclosure applies   see www.2rosenthals.com
-------------------------------------------------------------


#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[email protected]>.
To unsubscribe, E-mail to: <[email protected]>
To switch to the DIGEST mode, E-mail to <[email protected]>
To switch to the INDEX mode, E-mail to <[email protected]>
Send administrative queries to  <[email protected]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.