<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Any thoughts here?<br>
<br>
On 8/31/2018 6:14 PM, Jordan Brown wrote:<br>
</div>
<blockquote type="cite"
cite="mid:93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<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"
moz-do-not-send="true">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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Jordan Brown, Oracle Solaris</pre>
</body>
</html>