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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
