SSL23_GET_SERVER_HELLO when connecting to OpenSSL 1.0.0

Your summary says you connect TO openssl 1.0.0, how can you tell? Did you mean connecting WITH openssl 1.0.0?

I think there's more to it than "just" that version though:

$ curl -V
curl 7.21.7 (i486-pc-linux-gnu) libcurl/7.21.7 OpenSSL/1.0.0d zlib/1.2.3.4 libidn/1.22 libssh2/1.2.8 librtmp/2.3

$ curl -k -I https://www.sessionportal.net/
HTTP/1.1 200 OK
Date: Sun, 21 Aug 2011 10:00:38 GMT

(and it also works fine with my 7.22.0-dev version using the same OpenSSL version)

I copied the subject from this closed bug:
https://sourceforge.net/tracker/index.php?func=detail&aid=3165773&group_id=976&atid=100976

The Apache server is running OpenSSL/1.0.0d, the client uses OpenSSL/0.9.8j. I do not know if this causes the odd behaviour.

Downloaded another win32 build from
http://www.gknw.de/mirror/curl/win32/old_releases/curl-7.21.1-ssh2-ssl-sspi-zlib-idn-static-bin-w32.7z

Same effect:
D:\zip\curl721>curl --version
curl 7.21.1 (i386-pc-win32) libcurl/7.21.1 OpenSSL/0.9.8o zlib/1.2.5 libidn/1.18 libssh2/1.2.7
Protocols: dict file ftp ftps http https imap imaps ldap pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN Largefile NTLM SSL SSPI libz

D:\zip\curl721>curl -k -I https://sessionportal.net/
HTTP/1.1 200 OK
Date: Sun, 21 Aug 2011 11:34:32 GMT
Server: Apache/2.2.19 (Win32) DAV/2 mod_fcgid/2.3.6 mod_ssl/2.2.19 OpenSSL/1.0.0d PHP/5.3.6
[snip]

D:\zip\curl721>curl -k -I https://www.sessionportal.net/
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)

Same effect with the 7.21.7 build
http://www.gknw.de/mirror/curl/win32/curl-7.21.7-ssh2-ssl-sspi-zlib-idn-static-bin-w32.7z
dated 28-Jun-2011 02:00

D:\zip\curl7217>curl --version
curl 7.21.7 (i386-pc-win32) libcurl/7.21.7 OpenSSL/0.9.8r zlib/1.2.5 libidn/1.18 libssh2/1.2.8
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN Largefile NTLM SSL SSPI libz

D:\zip\curl7217>curl -k -I https://www.sessionportal.net/
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)

Still, I can't reproduce this. (I don't have or use windows.) This needs to be debugged and researched further by someone who can reproduce it.

To me it looks much more like an OpenSSL on Windows problem rather than a curl problem...

I could not reproduce it either on Linux / FreeBSD / Centos. But I did not have a client with OpenSSL/0.9.8h or greater on one of those systems. It looks like 0.9.8 from the 'h' release on might be the problem. I downloaded the 7.18.0 and 7.18.2 devel Ming32 releases of Curl. The 0.9.8h had the problem, the 0.9.8g not.

In the closed bug 0.9.8k was the client OpenSSL (also on Linux)
https://sourceforge.net/tracker/index.php?func=detail&aid=3165773&group_id=976&atid=100976

D:\zip\curl7182>curl -V
curl 7.18.2 (i386-pc-win32) libcurl/7.18.2 OpenSSL/0.9.8h zlib/1.2.3 libssh2/0.18
Protocols: tftp ftp telnet dict ldap http file https ftps scp sftp
Features: Largefile NTLM SSL SSPI libz

D:\zip\curl7182>curl -k -I https://www.sessionportal.net/
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)

D:\zip\curl7182>cd ..\curl718

D:\zip\curl718>curl -V
curl 7.18.0 (i386-pc-win32) libcurl/7.18.0 OpenSSL/0.9.8g zlib/1.2.3 libssh2/0.1
7
Protocols: tftp ftp telnet dict ldap http file https ftps scp sftp
Features: Largefile NTLM SSL SSPI libz

D:\zip\curl718>curl -k -I https://www.sessionportal.net/
HTTP/1.1 200 OK
Date: Sun, 21 Aug 2011 13:24:14 GMT
Server: Apache/2.2.19 (Win32) DAV/2 mod_fcgid/2.3.6 mod_ssl/2.2.19 OpenSSL/1.0.0
d PHP/5.3.6

The 7.18.1 devel Mingw32 release works. The only difference with the faulting 7.18.2 seems to be the OpenSSL client version: 0.9.8g versus 0.9.8h.

D:\zip\curl7181>curl -V
curl 7.18.1 (i386-pc-win32) libcurl/7.18.1 OpenSSL/0.9.8g zlib/1.2.3 libssh2/0.18
Protocols: tftp ftp telnet dict ldap http file https ftps scp sftp
Features: Largefile NTLM SSL SSPI libz

D:\zip\curl7181>curl -k -I https://www.sessionportal.net/
HTTP/1.1 200 OK
Date: Sun, 21 Aug 2011 13:43:44 GMT
Server: Apache/2.2.19 (Win32) DAV/2 mod_fcgid/2.3.6 mod_ssl/2.2.19 OpenSSL/1.0.0d PHP/5.3.6

I found a Linux system of mine that repeats this problem:

$ curl -V
curl 7.21.3 (i486-pc-linux-gnu) libcurl/7.21.3 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18 libssh2/1.2.6

$ curl -k -I https://www.sessionportal.net/
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)

Very strange...

Rebuilding with the latest curl source and still using the same OpenSSL/0.9.8o library, the problem persists. I think this looks like an OpenSSL problem:

$ ./src/curl -V
curl 7.22.0-DEV (x86_64-unknown-linux-gnu) libcurl/7.22.0-DEV OpenSSL/0.9.8o zlib/1.2.3.4 libssh2/1.2.6 librtmp/2.3

It is the SSL_connect() function that returns error (-1) and when we check which error by using SSL_get_error() which says SSL_ERROR_SSL. The full error string is then extracted using further OpenSSL calls...

Hi Daniel,

Glad you could reproduce it. I am using the following protocols of Curl win32: ftp https ftps scp (and using WinSCP for sftp). As far as I know there are no win32 builds with OpenSSL/1.0.0. Or did I look with my nose?

Any ideas on further steps I could take (besides sticking with 0.9.8g)?

I don't know about downloads. If there really isn't any already available then I guess your options are to either stick with the older version that works or to build your own libcurl using OpenSSL 1.0.0d (I've spotted at least http://www.shininglightpro.com/products/Win32OpenSSL.html\) provides such OpenSSL buildsl for windows.

Since the EXACT same curl code works with the right OpenSSL version and fails with the wrong versions I will treat this as an OpenSSL bug until we find out more.

I have already been at the Shining Light before, but it isn't easy to use their files to build a curl on my own. For the moment I will stick to the old one and postpone the building.

Before you close this report, just one quote from the closed bug:

"The openssl command line tool works fine though (openssl s_client --connect <server>:443). So it seems like curl is doing something different than the openssl command line tool."

It might be worthwhile to investigate a little further...

I downloaded OpenSSL/0.9.8r from
http://www.shininglightpro.com/products/Win32OpenSSL.html

And tried if the Windows OpenSLL tool had problems connecting to www.sessionportal.net. It did not. So it might not be an entirely OpenSSL problem.

D:\OpenSSL>openssl s_client -quiet -connect www.sessionportal.net:443
Loading 'screen' into random state - done
depth=1 /C=US/O=GeoTrust, Inc./CN=RapidSSL CA
verify error:num=20:unable to get local issuer certificate
verify return:0
GET /
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/x
html1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr">

<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Welcome at the Session Portal! | Session Portal</title>

I'm quite sure the s_client tool doesn't for example use non-blocking sockets, which curl does, so it isn't a completely reliable comparison.

This problem has to do with the TLS SNI extension.

If curl sends an SNI hostname that the server does not recognize, the server will send back a TLS Alert record with Level 1 (Warning) and Code 112 (Unrecognized name) to notify the client that the server may not do what the client is expecting (that's what reason(1112) is referring to).

In the case of Apache, if your VirtualHost does not contain a ServerName or ServerAlias statement which explicitly matches the specified domain name, Apache will send back this TLS Alert. It then continues to process the request normally (it defaults to using the first defined VirtualHost), so if curl were to ignore the Alert, everything would work as expected. (You can see the code for this on line 2170 of http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?revision=1162103&view=markup\)

All browsers seem to ignore this alert, so it seems that curl probably should too (or at least just print a warning instead of quitting when it gets this alert).

So it looks like openssl 0.9.8 will fail if it receives any TLS Alert records while waiting for the Server Hello record. openssl 1.0.0 has been updated to ignore TLS Alerts that are Warnings:
http://cvs.openssl.org/chngview?cn=14772

I suspect the simplest solution will be to add an option to Apache to disable sending the TLS alert when no hostname matches. I'll write a patch, submit it to Apache, and update this ticket with details.

Thanks a lot Paul for pulling ahead on this issue!

Thanks, Paul. Keep us posted.

I'm having the same problem using 0.9.8 to connect to https://www.wikimedia.de. it works with firefox and wget, it does not work with curl. openssl s_client works. This seems a massive bug. It basically means that all of our pages are not accessible using the version of libcurl currently distributed with ubuntu, debian, etc.

My hoster basically told me that our pages there will not be available from clients using 0.9.8, because the protocol version is not detected correctly. It works when providing the protocol version explicitly:

daniel@brightpad ~> curl -k -I 'https://www.wikimedia.de/'
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
daniel@brightpad ~> curl -1 -k -I 'https://www.wikimedia.de/'
HTTP/1.1 301 Moved Permanently
Date: Fri, 21 Oct 2011 15:49:52 GMT
Server: Apache/2.2.20
X-Powered-By: PHP/5.2.13
Vary: Accept-Encoding,Cookie
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, must-revalidate, max-age=0
Last-Modified: Fri, 21 Oct 2011 15:49:52 GMT
Location: https://www.wikimedia.de/wiki/Hauptseite
Connection: close
Content-Type: text/html; charset=utf-8

daniel@brightpad ~> curl -3 -k -I 'https://www.wikimedia.de/'
HTTP/1.1 301 Moved Permanently
Date: Fri, 21 Oct 2011 15:49:56 GMT
Server: Apache/2.2.20
X-Powered-By: PHP/5.2.13
Vary: Accept-Encoding,Cookie
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, must-revalidate, max-age=0
Last-Modified: Fri, 21 Oct 2011 15:49:56 GMT
Location: https://www.wikimedia.de/wiki/Hauptseite
Connection: close
Content-Type: text/html; charset=utf-8

daniel@brightpad ~> curl --version
curl 7.21.3 (x86_64-pc-linux-gnu) libcurl/7.21.3 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

numbthumb: this is not about the libcurl version, this is about the OpenSSL version. Update that one and you'll see that it works. Without modifying a single line in libcurl.

Firefox uses NSS. You can make use libcurl use NSS as well and it will work too. Or you make it use GnuTLS or another working lib. Or just a recent OpenSSL. I suspect the fact that both wget and openssl s_client are working with these versions is because both of them use OpenSSL in a blocking mode and libcurl does not.

I have the same problem when connecting using Cygwin version of curl to an Apache server on Ubuntu 11.10.

The client:

$ curl -V
curl 7.22.0 (i686-pc-cygwin) libcurl/7.22.0 OpenSSL/0.9.8r zlib/1.2.5 libidn/1.18 libssh2/1.2.7
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: IDN IPv6 Largefile NTLM NTLM_WB SSL libz

The server:

$ /usr/sbin/apache2 -V

Server version: Apache/2.2.20 (Ubuntu)
Server built: Sep 6 2011 18:40:05
Server's Module Magic Number: 20051115:28
Server loaded: APR 1.4.5, APR-Util 1.3.12
Compiled using: APR 1.4.5, APR-Util 1.3.12
Architecture: 64-bit
Server MPM: Worker
threaded: yes (fixed thread count)
forked: yes (variable process count)
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/worker"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT="/etc/apache2"
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="mime.types"
-D SERVER_CONFIG_FILE="apache2.conf"

Problem on Cygwin:

$ curl -k -l https://server.address

curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)

I am still firmly convinced that the source of this problem lies within OpenSSL. I suggest anyone who wants to resolve this problem dig more in that area.

I'm having the same issue: upgrading the server from openssl 0.9.8 (fedora 15) to 1.0 (fedora 16) triggers the issue. The client is cygwin (0.9.8r).

Paulsd's description seems to fit my problem. If I use the fully-qualified hostname to connect to the server then things work fine (the ServerName is the fully-qualified name). Using a "short" name gives the SSL23_GET_SERVER_HELLO:reason(1112) error.

I know badger suggested it was an openssl issue (and in some sense it is: there is a new error being returned by openssl), the "fix" seems to most logically belong in curl: to act like other clients and provide a path to ignore the error: either always, or tied to the -k (insecure) flag.

As SNI gets rolled out in servers this will start happening more and more often.