Viktor Dukhovni wrote:
> On Thu, Apr 03, 2014 at 01:18:13PM +0200, Frantisek Hanzlik wrote:
>
>> Hello OpenSSL gurus,
>>
>> I found in my sendmail-8.14.7/Fedora-18-i386 queue undelivered mails,
>> log say 'TLS handshake failed', and when I captured traffic between
>> mine and destination mailserver, I got result as in attached text export
>> from wireshark.
>>
>> And when I tried:
>>
>> openssl s_client -starttls smtp -connect DestMTA -msg -debug
>
> I can reproduce this behaviour with the Postfix 2.11 "posttls-finger"
> utility (not surprising really, since it is also linked with
> OpenSSL). The behaviour is the same with OpenSSL 1.0.1 and the
> 1.0.2 version in git.
>
> $ posttls-finger "[89.24.112.34]"
> posttls-finger: Connected to 89.24.112.34[89.24.112.34]:25
> posttls-finger: < 220 elfetex.cz Kerio Connect 8.2.2 ESMTP ready
> posttls-finger: > EHLO central-dogma.lan
> posttls-finger: < 250-elfetex.cz
> posttls-finger: < 250-AUTH CRAM-MD5 PLAIN LOGIN DIGEST-MD5
> posttls-finger: < 250-STARTTLS
> posttls-finger: < 250-ENHANCEDSTATUSCODES
> posttls-finger: < 250-8BITMIME
> posttls-finger: < 250-PIPELINING
> posttls-finger: < 250-ETRN
> posttls-finger: < 250-DSN
> posttls-finger: < 250 HELP
> posttls-finger: > STARTTLS
> posttls-finger: < 220 2.0.0 Ready to start TLS
> posttls-finger: SSL_connect error to 89.24.112.34[89.24.112.34]:25: -1
> posttls-finger: warning: TLS library problem: error:1409210A:SSL
> routines:SSL3_GET_SERVER_HELLO:wrong ssl version:s3_clnt.c:868:
>
> Indeed that server's response is TLS 1.1 {3, 2} at the record layer, and
> TLS 1.2 {3, 3} in the server HELLO. I don't know whether rejecting
> such server responses is the right behaviour, or whether the OpenSSL
> client should tolerate this.
>
> For what it is worth, Postfix will retry in cleartext after an
> opportunistic TLS handshake fails. Does Sendmail not fall back to
> cleartext?
Hello Viktor, thaks for looking at this problem.
As I know, Sendmail from Sendmail.org do not know fall back to cleartext
when this type of TLS error occurs. Sendmail tells them as 'SOFTWARE'
errors and mails where these errors occurs will be queued for later
delivery - and after several days of futile delivery attempts will
be deleted from queue. Only way how avoid this situation for one
particular mailserver is using "Try_TLS:SERVERIP/FQDN NO" in access
map, which disable STARTTLS for this server even if it announce STARTTLS
in its EHLO reply.
If I guess correctly, there isn't clear rule how treat cases, where
server tell lower TLS version in its record layer than TLS version
which choose for connection and tells it in server HELLO ?
PS: Please, excuse me for posting my mail twice - I have not got it
back from list (it was sent, but rejected with my antispam rule
"mails from me to me sent from internet must be sent over cryped and
authenticated connection"), and I could not find it either on the
marc.info openssl archive. I found it to tonight on mail-archive.com.
Thanks, Franta Hanzlik
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
