Bugs item #3395520, was opened at 2011-08-20 20:09
Message generated for change (Comment added) made by paulsd
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: Paul Donohue (paulsd)
Date: 2011-09-01 18: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 09: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 09: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 17: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 17: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 17: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 16: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 16: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 09: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 09: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 08: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 07: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 07: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 07: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 06: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 2011-09-02
Mailing List 
Page updated November 12, 2010.