<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>We're trying to nail down error reporting for TLS version
mismatches, and we're seeing a couple of puzzling behaviors.</p>
<p>First, and most puzzling... assume these two command lines:</p>
<blockquote>
<p>$ openssl s_server -cert 2018.08.31.a.pem -key 2018.08.31.a.key
-no_tls1</p>
<p>$ openssl s_client -connect zel.us.oracle.com:4433 -tls1</p>
</blockquote>
<p>That is, I have a server that won't accept TLSv1.0, and a client
that will only accept TLSv1.0.</p>
<p>On the server side I see</p>
<blockquote>
<p> 1:error:14076102:SSL
routines:SSL23_GET_CLIENT_HELLO:unsupported
protocol:s23_srvr.c:605:</p>
</blockquote>
<p>which makes perfect sense. On the client side I see</p>
<blockquote>
<p> 4294956672:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl
handshake failure:s3_pkt.c:659:</p>
</blockquote>
<p>which isn't as good, but is still sort of sensible. But when I
look at the packets exchanged, I see that the client sends a
Client Hello, and the server responds with an ACK and then a
FIN-ACK, with no data. It just hangs up the phone. This seems to
violate RFC 5246 section E.1: "If server supports (or is willing
to use) only versions greater than client_version, it MUST send a
"protocol_version" alert message and close the connection.".
Where's my protocol version alert?</p>
<p>Of course my real case does not involve the sample client and
server - it involves my own clients and servers - but I seem to
see the same behavior with several servers (notably including the
Apache httpd).</p>
<p>This looks like it's the same as
<a class="moz-txt-link-freetext" href="https://rt.openssl.org/Ticket/Display.html?id=2777">https://rt.openssl.org/Ticket/Display.html?id=2777</a> . I'm using
1.0.2o. (But I don't see anything relevant-looking in the 1.0.2p
changes.) I've seen similar behavior from 1.0.2o-fips.</p>
<p>Am I missing something here, or is this a server-side bug?</p>
<p><br>
</p>
<p>And then, on the client side...</p>
<p>SSL_connect returns zero. Exactly how that failure differs from
a less-than-zero error is not clear, but OK. The docs say to call
SSL_get_error(). SSL_get_error() returns 5, SSL_ERROR_SYSCALL.
(That seems a little strange, since I don't think there's any
system call errors here.) The docs say to consult the error queue
and errno. ERR_peek_last_error( ) returns zero. Errno is zero.
It failed, but nobody will tell me why.</p>
<p>Am I missing something here, or is this a client library bug?</p>
<p><br>
</p>
<p>(I have not tracked down exactly how the s_client tool ends up
with a message. It seems to use a more intricate mechanism than
SSL_connect.)</p>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Jordan Brown, Oracle Solaris</pre>
</body>
</html>