Re: TLS response code

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.


#############################################################
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]>