Discussion:
openssl-1.0.1e client - fatal alert: Protocol Version (70) at Server Hello
(too old to reply)
Frantisek Hanzlik
2014-04-03 11:18:13 UTC
Permalink
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 will get some as:
...
TLS 1.2 Handshake [length 00f4], ClientHello
01 00 00 f0 03 03 53 3a d1 72 61 e9 9f c9 ce dc
97 e0 5d ed 70 b4 2e b5 b2 6c f0 b6 73 28 bf a3
21 6c d0 a7 cc dc 00 00 84 c0 30 c0 2c c0 28 c0
24 c0 14 c0 0a 00 a3 00 9f 00 6b 00 6a 00 39 00
38 00 88 00 87 c0 32 c0 2e c0 2a c0 26 c0 0f c0
05 00 9d 00 3d 00 35 00 84 c0 12 c0 08 00 16 00
13 c0 0d c0 03 00 0a c0 2f c0 2b c0 27 c0 23 c0
13 c0 09 00 a2 00 9e 00 67 00 40 00 33 00 32 00
9a 00 99 00 45 00 44 c0 31 c0 2d c0 29 c0 25 c0
0e c0 04 00 9c 00 3c 00 2f 00 96 00 41 00 07 c0
11 c0 07 c0 0c c0 02 00 05 00 04 00 ff 01 00 00
43 00 0b 00 04 03 00 01 02 00 0a 00 08 00 06 00
19 00 18 00 17 00 23 00 00 00 0d 00 22 00 20 06
01 06 02 06 03 05 01 05 02 05 03 04 01 04 02 04
03 03 01 03 02 03 03 02 01 02 02 02 03 01 01 00
0f 00 01 01
read from 0x8fd44e0 [0x8fdb340] (7 bytes => 7 (0x7))
0000 - 16 03 02 00 3a 02 ....:.
0007 - <SPACES/NULS>
read from 0x8fd44e0 [0x8fdb34a] (56 bytes => 56 (0x38))
0000 - 00 36 03 03 53 3a d1 72-0c 7c 8d 9e 5b ba 26 71 .6..S:.r.|..[.&q
0010 - 26 87 fd b1 ec c6 fe 4d-ee 4f d3 03 31 ea f9 2e &......M.O..1...
0020 - 5e 54 fd b8 00 00 9d 00-00 0e ff 01 00 01 00 00 ^T..............
0030 - 23 00 00 00 0f 00 01 01- #.......
<<< TLS 1.1 Handshake [length 003a], ServerHello
02 00 00 36 03 03 53 3a d1 72 0c 7c 8d 9e 5b ba
26 71 26 87 fd b1 ec c6 fe 4d ee 4f d3 03 31 ea
f9 2e 5e 54 fd b8 00 00 9d 00 00 0e ff 01 00 01
00 00 23 00 00 00 0f 00 01 01
write to 0x8fd44e0 [0x8fe4d50] (7 bytes => 7 (0x7))
0000 - 15 03 03 00 02 02 46 ......F
TLS 1.2 Alert [length 0002], fatal protocol_version
02 46
3070990124:error:1409210A:SSL routines:SSL3_GET_SERVER_HELLO:wrong ssl
version:s3_clnt.c:869:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 297 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1396363634
Timeout : 300 (sec)
Verify return code: 0 (ok)

which is perhaps same error. On mentioned 's3_clnt.c' line is code:

d=p=(unsigned char *)s->init_msg;

if ((p[0] != (s->version>>8)) || (p[1] != (s->version&0xff)))
{
SSLerr(SSL_F_SSL3_GET_SERVER_HELLO,SSL_R_WRONG_SSL_VERSION);
s->version=(s->version&0xff00)|p[1];
al=SSL_AD_PROTOCOL_VERSION;
goto f_err;
}

As I'm not programmer, I was not able tracking it more closely, only
I suspect that one version values may be the record layer version
number (0x0302 ~ TLS 1.1) and other may be Server Hello version values
(0x0303 ~ TLS 1.2). But according to e.g. this article:

http://security.stackexchange.com/questions/29314/what-is-the-significance-of-the-version-field-in-a-tls-1-1-clienthello-message

, I cite:
...
The response from the server states the protocol version which will be
used, and should come as records bearing that version. E.g. if the server
says "TLS 1.1" in its ServerHello then that ServerHello should come
wrapped into a record also tagged as "TLS 1.1"; and all subsequent records
from both client and server should use that version.
...
these values _SHOULD_ be same, but I nowhere found that _MUST_ be same.
Thus, I not know, when is problem on remote server side, or in my
sendmail with openssl-1.0.1e.
Can, please, anyone advise what the problem is, and if so, whether
it can be solved on my side?

TIA, Franta Hanzlik
Viktor Dukhovni
2014-04-03 17:04:59 UTC
Permalink
Post by Frantisek Hanzlik
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.
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?
--
Viktor
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org
Frantisek Hanzlik
2014-04-03 20:50:16 UTC
Permalink
Post by Viktor Dukhovni
Post by Frantisek Hanzlik
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.
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
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-***@openssl.org
Automated List Manager ***@openssl.org
Loading...