I am finding some TLS enabled SMTP servers that don't appear to like
the TLSv1 sesion ticket extension.
With session tickets enabled:
$ openssl s_client -starttls smtp -msg -tlsextdebug -connect 192.0.2.1:25
CONNECTED(00000003)
>>> TLS 1.0 Handshake [length 00cb], ClientHello
01 00 00 c7 03 01 4c ef 32 cf 80 30 7d fd 15 94
07 d4 ec 56 39 c2 d9 77 4f 4e ed 5f ca 16 c5 07
7c 61 98 37 5f 8f 00 00 5a c0 14 c0 0a 00 39 00
38 00 88 00 87 c0 0f c0 05 00 35 00 84 c0 12 c0
08 00 16 00 13 c0 0d c0 03 00 0a c0 13 c0 09 00
33 00 32 00 9a 00 99 00 45 00 44 c0 0e c0 04 00
2f 00 96 00 41 c0 11 c0 07 c0 0c c0 02 00 05 00
04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 00
03 00 ff 01 00 00 44 00 0b 00 04 03 00 01 02 00
0a 00 34 00 32 00 01 00 02 00 03 00 04 00 05 00
06 00 07 00 08 00 09 00 0a 00 0b 00 0c 00 0d 00
0e 00 0f 00 10 00 11 00 12 00 13 00 14 00 15 00
16 00 17 00 18 00 19 00 23 00 00
<<< TLS 1.0 Alert [length 0002], fatal internal_error
02 50
182902742496:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
internal error:s23_clnt.c:658:
With session tickets disabled:
$ openssl s_client -starttls smtp -no_ticket -msg -tlsextdebug -bugs
-connect 192.0.2.1:25
CONNECTED(00000003)
>>> TLS 1.0 Handshake [length 00c7], ClientHello
01 00 00 c3 03 01 4c ef 34 65 4a 01 e3 74 81 a4
60 25 69 d3 01 ad 96 f3 e5 ea 21 02 80 06 35 4d
6c 9e a3 d8 50 3e 00 00 5a c0 14 c0 0a 00 39 00
38 00 88 00 87 c0 0f c0 05 00 35 00 84 c0 12 c0
08 00 16 00 13 c0 0d c0 03 00 0a c0 13 c0 09 00
33 00 32 00 9a 00 99 00 45 00 44 c0 0e c0 04 00
2f 00 96 00 41 c0 11 c0 07 c0 0c c0 02 00 05 00
04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 00
03 00 ff 01 00 00 40 00 0b 00 04 03 00 01 02 00
0a 00 34 00 32 00 01 00 02 00 03 00 04 00 05 00
06 00 07 00 08 00 09 00 0a 00 0b 00 0c 00 0d 00
0e 00 0f 00 10 00 11 00 12 00 13 00 14 00 15 00
16 00 17 00 18 00 19
<<< TLS 1.0 Handshake [length 004a], ServerHello
02 00 00 46 03 01 4c ef 35 13 87 8d b3 aa 5b b4
80 36 72 d1 eb f5 f3 23 54 48 42 76 55 52 5b 1e
b7 07 ea ed f2 49 20 4c ef 35 13 33 83 0e 60 ed
44 5f 85 5c 9f 66 6f eb 63 13 3b ef e5 79 ea 36
30 ba 8b 25 db 5a e6 00 16 00
<<< TLS 1.0 Handshake [length 04d2], Certificate
...
<<< TLS 1.0 Handshake [length 01ac], ServerKeyExchange
...
<<< TLS 1.0 Handshake [length 0004], ServerHelloDone
...
>>> TLS 1.0 Handshake [length 0066], ClientKeyExchange
...
>>> TLS 1.0 ChangeCipherSpec [length 0001]
01
>>> TLS 1.0 Handshake [length 0010], Finished
...
<<< TLS 1.0 ChangeCipherSpec [length 0001]
01
<<< TLS 1.0 Handshake [length 0010], Finished
...
---
No client certificate CA names sent
---
SSL handshake has read 1937 bytes and written 397 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
It is a bit difficult to predict which sites will run into trouble with
this or other extensions. How common a problem is this?
So far I am seeing this just with SMTP servers from China, whose EHLO
response starts with:
250-StormMail ESMTP service ready
Don't know much about this gateway, but this seems to be the main
source of the "internal error" alerts in response to TLSv1 SMTP client
connections.
There is as yet no code in Postfix to selectively disable session tickets
while still leaving TLSv1 enabled. Is this likely to be required to
avoid similar interoperability issues?
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
