Ubuntu and undefined symbol for SSLv2_method

Question

Is Canonical renaming symbols in their package version of openssl, and if so for what purpose? When I compile openssl-1.0.0e.tar.gz (downloaded from openssl.org directly) from scratch I see the necessary symbol, but Python (and I) can't seem to find it in the packaged version.

Read on for more information about how I diagnosed this problem...

I am trying to compile Python 2.6.1 on Ubuntu 11.10, and get the error message above. The reason I am using this older Python is that I am trying to make my Ubuntu installation 100% compatible with a production system for development purposes.

When performing

strace -feopen make -j4 |& grep "libssl"

I see that I am using a promising file:

[pid 22614] open("/usr/lib/x86_64-linux-gnu//libssl.so", O_RDONLY) = 7

Running nm, this file has no symbols. However the .a file does have a similar one:

0000000000000030 T SSLv23_method

The package libssl1.0.0-dbg is installed via synaptic, however when I list the installed files for this package all I see is "The list of installed files is only available for installed packages" which is clearly an Ubuntu bug. So I am not sure how I am supposed to check which symbols are present in the .so.

However, I am suspicious that they have renamed SSLv2_method to SSLv23_method in any case.

How to proceed to figure out the status of Ubuntu's openssl-1.0.0?

Answer 1

My fix was install openssl without ssl2 support

./config --prefix=/usr enable-shared -no-ssl2

Then install anything linked to the libraries in /usr/ssl. It works..

Answer 2

I was able to build Python 2.6 with SSL support on Ubuntu 12.04 with the help of the patch in this blog post.

Answer 3

The Ubuntu people build OpenSSL without SSLv2 support because the protocol has known security issues. So that's why you can't find SSLv2_method in their library even though you can find it when you compile the library yourself.

Ubuntu build logs are publicly available. You can see in the oneiric-i386.openssl_1.0.0e log that the library gets configured with the -no-ssl2 option, which disables support for SSLv2.

./Configure --prefix=/usr --openssldir=/usr/lib/ssl --libdir=lib/i386-linux-gnu no-idea no-mdc2 no-rc5 zlib  enable-tlsext no-ssl2 debian-i386
Configuring for debian-i386
    no-gmp          [default]  OPENSSL_NO_GMP (skip dir)
    no-idea         [option]   OPENSSL_NO_IDEA (skip dir)
    no-jpake        [experimental] OPENSSL_NO_JPAKE (skip dir)
    no-krb5         [krb5-flavor not specified] OPENSSL_NO_KRB5
    no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
    no-mdc2         [option]   OPENSSL_NO_MDC2 (skip dir)
    no-rc5          [option]   OPENSSL_NO_RC5 (skip dir)
    no-rfc3779      [default]  OPENSSL_NO_RFC3779 (skip dir)
    no-shared       [default] 
    no-ssl2         [option]   OPENSSL_NO_SSL2 (skip dir)
    no-store        [experimental] OPENSSL_NO_STORE (skip dir)
    no-zlib-dynamic [default] 

Note that the availability of SSLv23_method does not mean that a client will be able to connect to a server with SSLv2. The OpenSSL documentation briefly discusses this situation:

The list of protocols available can later be limited using the SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1 options of the SSL_CTX_set_options() or SSL_set_options() functions. Using these options it is possible to choose e.g. SSLv23_server_method() and be able to negotiate with all possible clients, but to only allow newer protocols like SSLv3 or TLSv1.