Mailing List CGatePro@mail.stalker.com Message #106020
From: Bill Cole <cgp-2015@billmail.scconsult.com>
Subject: Re: TLS response code
Date: Sat, 12 Mar 2016 14:30:45 -0500
To: CommuniGate Pro Discussions <CGatePro@mail.stalker.com>
X-Mailer: MailMate (1.9.4r5232)
On 4 Mar 2016, at 16:27, James Moe wrote:

opensuse 421.
cgate-pro 5.4.11

  We are getting this response during an attempt to send mail.
  What is TLS code 10? Is there some place where these codes are defined?

RFC5246 describes when various codes should be used and it helps to understand the whole TLS connection setup process. Looking at the relevantcode of LibreSSL or OpenSSL or GNU-TLS might be illuminating as well. Also, it isn't entirely clear that in this case the "code 10" is a formal TLS error code instead of just some number Vlad chose for a particular sort of failure in CGP. Finally: you can BE SURE that over time CGP 5.4.11 will increasingly fail to negotiate ANY encryption with rationally-configured sites that support TLS, because the SSL/TLS library in 5.4 is a horrible antique mess, missing support for any protocol+ciphersuite combo that should be deemed secure in the modern world.

Yes, I know that's less than entirely helpful.

However...


----[ log excerpt ]----
09:06:41.190 4 SMTP-000114(xyz.com) cmd: EHLO sma-inc.us
09:06:41.202 4 SMTP-000114(xyz.com) rsp: 250-sebalance2.web-hosting.com 09:06:41.202 4 SMTP-000114(xyz.com) rsp: 250 STARTTLS

Odd... I don't see sebalance2.web-hosting.com as a MX for xyz.com and when I connect to port 25 on 209.188.21.34 and say EHLO with a correct name, it doesn't offer STARTTLS to me. Which means that something has changed on that end in the past week; They no longer support STARTTLS, or at least they don't for connections from any of a handful of unrelated addresses that don't nomally get shunned by anyone...

Or you've mangled the logs into a useless fiction, which seems unlikely :)


09:06:41.202 4 SMTP-000114(xyz.com) Connected. TLS
09:06:41.202 4 SMTP-000114(xyz.com) starting TLS(optional)
09:06:41.202 4 SMTP-000114(xyz.com) cmd: STARTTLS
09:06:41.217 4 SMTP-000114(xyz.com) rsp: 220 2.0.0 Start TLS

09:06:41.229 4 SMTP-000114(xyz.com) TLS aborting with code 10

09:06:41.430 3 SMTP-000114(xyz.com) failed to establish a secure
connection with [209.188.21.34]:25. Error Code=connection reset by peer

That *kinda* would make sense if the far end were configured to drop connections that attempt to negotiate a protocol version and/or ciphersuite that it deems unsafe. Or if it were using one of the hacked-up versions of OpenSSL that have been passed around during the past few years with "workarounds" for vulnerabilities that got publicized and exploited before any proper fixes existed, e.g. "solved" by just aborting a TCP connection when TLS negotiation would result in a vulnerable session.

Hypothetically, if one had deployed such a botch 2 years ago and not freaked out about any intervening OpenSSL issues until this week's "DROWN" problem, one might do it wrong and end up just disabling STARTTLS altogether. Or if one were using some shoddy black-box SMTP loadbalancer (as implied by the hostname) with an old non-upgradeable SSL/TLS implementation that was occasionally a little broken last week, one might just turn off STARTTLS in the face of DROWN, which is enabled by using the same private key for obsolete and modern protocols. It sorta makes sense (finally) to actually disable STARTTLS entirely on SMTP systems that can't be updated or configured to never fall back to legacy SSL, since now it is a risk to systems with solid TLS to share a private key (like in a wildcard cert) with one anywhere else that is doing better-than-nothing encryption as a last resort.

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