libssl upgrade causes failure from old clients

[Alex Bligh]

Upgrade of libssl1.0.0 Precise from version 1.0.1-4ubuntu5.5 to version 1.0.1-4ubuntu5.7 causes failure of negotiation by old clients.

I am running apache2 on servers with self-signed certs (I enclose one such). Before upgrade, I can do a 'curl -k' (insecure) and connect successfully whether or not the CN in the self-signed certificate matches the CN in the URL, and irrespective of the version of libssl running on the client (for this test I am using an IP address and a domain name mapping to that IP address).

Certs are generated with
  openssl genrsa -out foo.key 1024
  openssl req -new -key foo.key foo.csr -subj "/C=XX/ST=Test/L=Test/O=Test/OU=Test/CN=${ENDPOINT}"
  openssl x509 -req -days 36500 -in foo.csr -signkey foo.key -out foo.crt

After the upgrade, all works fine from the host itself (i.e. curl to the IP address in the CN, or curl to a DNS name pointing to it but not in the CN), but connection from older clients report:

Ximines:~ amb$ curl -vvvvvv -k "https://cp.dev2.flexiant.net:4443/?wsdl" ; echo ""
* About to connect() to cp.dev2.flexiant.net port 4443 (#0)
* Trying 10.20.0.2... connected
* Connected to cp.dev2.flexiant.net (10.20.0.2) port 4443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
* Closing connection #0
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)

whereas

$ curl -k "https://10.20.0.2:4443/?wsdl"

works fine

This error is ONLY produced when connecting to a URL not matching the CN. If I connect to a URL that does match the CN it works fine (presumably it bails out earlier).

If I force version 3 negotiation with the -3 option, it works fine.

As the version of curl has not changed, I suspect libssl, though it's possible curl is not checking for all error conditions.

Self-signed cert that errors (private key is worthless so included too):

-----BEGIN CERTIFICATE-----
MIICMzCCAZwCCQCX1VMZB/s5ozANBgkqhkiG9w0BAQUFADBdMQswCQYDVQQGEwJY
WDENMAsGA1UECAwEVGVzdDENMAsGA1UEBwwEVGVzdDENMAsGA1UECgwEVGVzdDEN
MAsGA1UECwwEVGVzdDESMBAGA1UEAwwJMTAuMjAuMC4yMCAXDTEyMTEwMjExNTIz
N1oYDzIxMTIxMDA5MTE1MjM3WjBdMQswCQYDVQQGEwJYWDENMAsGA1UECAwEVGVz
dDENMAsGA1UEBwwEVGVzdDENMAsGA1UECgwEVGVzdDENMAsGA1UECwwEVGVzdDES
MBAGA1UEAwwJMTAuMjAuMC4yMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1
1b1RegfDBSATwP7W5kxY6oB1dgBQDmxU9gOhGo06NEyUt88mZmRCLuw9eI9c3Ho/
2P3DleB1HC+8buFn4b0+1c6Chk+gGifsX+3mHmVgjoeoxxk8+3wOjw848FxJ+RZ1
H/FHFPDSjQPfIg6jFPo5Wab4g7Depb/PoDOjgWQ+nQIDAQABMA0GCSqGSIb3DQEB
BQUAA4GBAArf2LS6G3Mh21qrR0UiAc1ekFw3JQvjRG8MSl+nCX3eHjBk1PDvMYs0
Hfh6HVRCBcleQn7xMHxTXw7wNyaoFeI4hl+GYHwzJONcVVSq+1wfIuzPC0YY6uPi
jUOSgUdnWvbZje0W4VM3/437793wPtP+fUVwEAAOGT70tC65R3CI
-----END CERTIFICATE-----

-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQC11b1RegfDBSATwP7W5kxY6oB1dgBQDmxU9gOhGo06NEyUt88m
ZmRCLuw9eI9c3Ho/2P3DleB1HC+8buFn4b0+1c6Chk+gGifsX+3mHmVgjoeoxxk8
+3wOjw848FxJ+RZ1H/FHFPDSjQPfIg6jFPo5Wab4g7Depb/PoDOjgWQ+nQIDAQAB
AoGAJgWzuL3Tsav4sSjCIR23CUC/68/o8NSTQpDO4Xkz3t/gw5hL8LOoc05sh84V
7E0OIxu0tJk6fkKOmNB2wcoqUAbcFnyItvi76EirQ2nu7x7zBhVNhJuYBGvTegG9
ByN7+arc+jvRq1Y36c999SN0wYEZpMdIKKOLBO2RgYnmQ+ECQQDoKVd6aH3fOlAC
ufTLH9duOILjeshH+N/Zuedq1eSA7tBTl3pdbHBbtGmim78brjelhqMn1GWqF3Y1
qWgyIq3jAkEAyIGAEb8EUGT/qOfMdvH52PvQGfMn3ZHT7FTC2m2ScV8kJb6UgrCi
mw6ZYDgSbMhm6xA7ow3wxORq4+s9ChEJfwJASEtXak7Po4vNDoxJplcsBq6iU6QQ
ahkd2/cAEUy580xqox0whZcXBfeQTYqiYERIH8tlUynY3rafoOY4BCS4cQJAOcSl
43cHhSo0RrPSQwrgk1Wp1XArMjlLt7GMGmarZKKmxYEtRKIjl00Tf5doJ5Nto5gf
tpDTp8avzU7/XSEffQJBALupHWw2N+OZd1k2XVVp2AKaL1qRzna5xl6SfP9rIhme
LdZdCMkt4nSKJ1f0HGdIYnbUXm8zeffSnOlWwaeCLRg=
-----END RSA PRIVATE KEY-----

[Marc Deslauriers (mdeslaur)]

Thanks for reporting this issue.

What do you mean by "old clients"? Do you mean precise clients that have openssl 1.0.1-4ubuntu5.5?

[Alex Bligh (ubuntu-alex-org)]

Sorry, I've tried on Lucid and OS-X both of which are using 0.9.8 (k and r respectively), i.e.

$ dpkg --list | fgrep libssl
ii libssl-dev 0.9.8k-7ubuntu8.13 SSL development libraries, header files and documentati
ii libssl0.9.8 0.9.8k-7ubuntu8.13 SSL shared libraries
$ curl --version
curl 7.21.3 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

and

Ximines:~ amb$ curl --version
curl 7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: GSS-Negotiate IPv6 Largefile NTLM SSL libz

[Stefan Huehner (stefan-huehner)]

Hello,

we've noticed the same problem and i can add some information.

The issue happens when connecting with curl using the lucid version of libssl0.9.8 (version: 0.9.8k-7ubuntu8.14) connecting to i.e. a precise server using libssl1.0.0 (version: 1.0.1-4ubuntu5.8).

Just a few days ago some posted a patch upstream to the libssl-dev mailaing list [1]. However there's not reply there yet.

I just finished tested this patch by applying it on top of the lucid version and doing that i can successfully connect to the precise system using https again.

So functionally that fixes the problem for me.

As the patch has not been reviewed yet we only compiled a patched libssl and are using it only for the failing curl invocation to avoid system-wide side-effects.

In case it is useful for anyone:
apt-get build-dep libssl0.9.8
cd openssl-0.9.8
patch -p1 <
0001-Fix-handling-of-warning-level-alerts-in-SSL23-client.patch
debuild -us -uc -b

can be used to provided a patched libssl0.9.8.

Note: patch applies fine with some fuzz ignoring refects for the CHANGES file.

I would be very happy to see a pathced libssl packages for lucid when possible to be able to remove the locally patched version again.

[1] http://marc.info/?l=openssl-dev&m=136760073921954&w=2

[Adrien Nader (adrien)]

As far as I can understand from the mailing-list thread, the patch unfortunately did not get merged. However, the versions against which this issue has been reported are also very old at this point and I think this means the issue will be WONTFIX.