On Thu, Jul 11, 2013 at 01:47:09PM +0200, Stefan Jakobs wrote:
> $ openssl s_client -no_ssl2 -reconnect -starttls smtp -state -cipher \
> "ALL:+RC4:@STRENGTH" -connect server.example.com:25
> 250 DSN
> drop connection and then reconnect
> SSL3 alert write:warning:close notify
> CONNECTED(00000003)
> SSL_connect:before/connect initialization
> SSL_connect:SSLv3 write client hello A
> SSL3 alert write:fatal:protocol version
> SSL_connect:error in SSLv3 read server hello A
> 13820:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
> number:s3_pkt.c:281:
Unfortunately, the "reconnect" code in s_client (at least with
0.9.8j) forgets to do SMTP "STARTTLS", so this fails because
"220 hostname" is not an SSL server HELO.
A better diagnostic utility is available with the latest Postfix
2.11 snapshot. You don't need to install it (no need to upgrade
to Postfix 2.11), just compile postfix-2.11-20130710 with TLS
support and run:
./bin/posttls-finger -p "" -lmay -Lsummary,cache,debug -r 1 \
"[status.rus.uni-stuttgart.de]"
This will report more useful results.
> > What O/S is the server running? Does it have OpenSSL-0.9.9-dev?
>
> Ubuntu 12.04 LTS
> libssl1.0.0 1.0.1-4ubunu5.10
> openssl 1.0.1-4ubuntu5.10
I don't see anything wrong with the server's response in the packet
capture, it does however send a session ticket, perhaps this gives
0.9.8j indigestion. It is however possible that something subtle
Since your Postfix client does not disable SSLv2 (it really should),
initial handshakes can't use TLS extensions, and so the server
sends no session tickets. With resumed sessions, the client
indicates session ticket support, and the server sends a session
ticket, so this may explain why your client can't complete the
handshake intermittently.
Upgrading to a more recent OpenSSL release on the client is highly
recommended, probably 0.9.8y to maintain binary compatibility with
0.9.8j. You could also compile and link Postfix with OpenSSL
1.0.1e, installed in some suitable location where its header files
won't get in the way of other applications that should be linked
with 0.9.8* (can't say 0.9.8x for a generic patch, that's an actual
release).
The simplest work-around for the problem is to disable TLSv1 on
your 0.9.8j machine, since it seems to not handle the session
ticket extension correctly. This is not a long-term fix, you
really should upgrade to 0.9.8y or later, which likely does not
have this problem.
main.cf:
# Disable SSLv2 and TLSv1, the latter until session ticket
# support works in the local SSL library.
#
smtp_tls_protocols = !SSLv2, !TLSv1
smtp_tls_mandatory_protocols = !SSLv2, !TLSv1
--
Viktor.
