Bugs item #3395520, was opened at 2011-08-20 17:09
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3395520&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: https
Group: wrong behaviour
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jan-E (jan-e)
Assigned to: Daniel Stenberg (bagder)
Summary: SSL23_GET_SERVER_HELLO when connecting to OpenSSL 1.0.0

Initial Comment:
Same behaviour as in the closed bug 3165773.

Additional info: fails when connectiing to https://www.domain.tld, but connects correctly to https://domain.tld

E:\utils>curl --version
curl 7.19.4 (i386-pc-win32) libcurl/7.19.4 OpenSSL/0.9.8j zlib/1.2.3 libidn/1.11 libssh2/1.0
Protocols: tftp ftp telnet dict ldap http file https ftps scp sftp
Features: IDN Largefile NTLM SSL SSPI libz

E:\utils>curl -k -I https://sessionportal.net/
HTTP/1.1 200 OK
Date: Sat, 20 Aug 2011 23:59:23 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]

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

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2012-01-18 14:34

Message:
We got a duplicate bug report for this error and that report includes some
further details:

http://curl.haxx.se/bug/view.cgi?id=3469471

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-11-29 12:35

Message:
So far we've not seen anyone provide any actual fix, so discussing which
fix is the best seems a bit premature...

----------------------------------------------------------------------

Comment By: Trocker (trocker)
Date: 2011-11-29 11:08

Message:
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.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-11-12 00:33

Message:
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.

----------------------------------------------------------------------

Comment By: Aleksander Adamowski (the_olo)
Date: 2011-11-09 07:17

Message:
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)

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-10-21 13:15

Message:
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.

----------------------------------------------------------------------

Comment By: Daniel Kinzler (numbthumb)
Date: 2011-10-21 08:52

Message:
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_at_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

----------------------------------------------------------------------

Comment By: Jan-E (jan-e)
Date: 2011-09-03 19:49

Message:
Thanks, Paul. Keep us posted.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-09-02 00:03

Message:
Thanks a lot Paul for pulling ahead on this issue!

----------------------------------------------------------------------

Comment By: Paul Donohue (paulsd)
Date: 2011-09-01 16:09

Message:
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.

----------------------------------------------------------------------

Comment By: Paul Donohue (paulsd)
Date: 2011-09-01 16:04

Message:
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

----------------------------------------------------------------------

Comment By: Paul Donohue (paulsd)
Date: 2011-09-01 15:20

Message:
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).

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-08-22 06:32

Message:
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.

----------------------------------------------------------------------

Comment By: Jan-E (jan-e)
Date: 2011-08-22 06:28

Message:
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>

----------------------------------------------------------------------

Comment By: Jan-E (jan-e)
Date: 2011-08-21 14:43

Message:
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...

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-08-21 14:14

Message:
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.

----------------------------------------------------------------------

Comment By: Jan-E (jan-e)
Date: 2011-08-21 14:05

Message:
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)?

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-08-21 13:43

Message:
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...

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-08-21 13:26

Message:
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...

----------------------------------------------------------------------

Comment By: Jan-E (jan-e)
Date: 2011-08-21 06:48

Message:
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

----------------------------------------------------------------------

Comment By: Jan-E (jan-e)
Date: 2011-08-21 06:37

Message:
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

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-08-21 05:13

Message:
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...

----------------------------------------------------------------------

Comment By: Jan-E (jan-e)
Date: 2011-08-21 04:46

Message:
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)

----------------------------------------------------------------------

Comment By: Jan-E (jan-e)
Date: 2011-08-21 04:38

Message:
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)

----------------------------------------------------------------------

Comment By: Jan-E (jan-e)
Date: 2011-08-21 04:13

Message:
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.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-08-21 03:02

Message:
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)

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3395520&group_id=976
Received on 2012-01-18