[openssl-users] Version negotiation failure failure?

[Kurt Roeckx]

On Fri, Aug 31, 2018 at 06:14:25PM -0700, Jordan Brown wrote:
> We're trying to nail down error reporting for TLS version mismatches,
> and we're seeing a couple of puzzling behaviors.
> 
> First, and most puzzling... assume these two command lines:
> 
>     $ openssl s_server -cert 2018.08.31.a.pem -key 2018.08.31.a.key -no_tls1
> 
>     $ openssl s_client -connect zel.us.oracle.com:4433 -tls1
> 
> That is, I have a server that won't accept TLSv1.0, and a client that
> will only accept TLSv1.0.
> 
> On the server side I see
> 
>     1:error:14076102:SSL routines:SSL23_GET_CLIENT_HELLO:unsupported
>     protocol:s23_srvr.c:605:
> 
> which makes perfect sense.  On the client side I see
> 
>     4294956672:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl
>     handshake failure:s3_pkt.c:659:
> 
> 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?
> 
> 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).
> 
> This looks like it's the same as
> https://rt.openssl.org/Ticket/Display.html?id=2777 .  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.

I can not reproduce this in 1.0.1, 1.0.2, 1.1.0 or 1.1.1. I
believe this was fixed in all branches. I've tried 1.0.2o too, and
I still get the alert back.

> And then, on the client side...
> 
> 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.

I assume that it returns SSL_ERROR_SYSCALL because something is
not properly setting an error, and SSL_get_error() returns
SSL_ERROR_SYSCALL when it doesn't know what else to return.
If the peer just closes the connection, you should have gotten
SSL_ERROR_SSL. I assume read() returned 0 because of EOF, which is
not an error for read() so it does not set errno, but OpenSSL
should have set an error instead.


Kurt