OpenSSL and IPv6

OpenSSL is one of the most popular implementations of Transport Layer Security (TLS), as well as one of the leading free software libraries for general-purpose cryptography, but as an online debate recently highlighted, it still lags behind on support for IPv6 tools. Admittedly, "lagging behind on IPv6" is a charge that could be leveled at most of the Internet, but with OpenSSL the feature requests — and the patches — have been idling in limbo for several years, which appears to be garnering frustration from some developers.

Michael Stapelberg raised the issue in a March 6 post on Google Plus:

The command line tools Stapelberg refers to are s_client and s_server, both of which are standard commands for the openssl tool, and are designed to help users test their code and SSL/TLS applications. S_client implements a simple SSL/TLS client application that attempts to open a connection to a remote host. S_server implements a simple SSL/TLS server, which listens for connections and (if desired) can emulate a web server.

In practice, you might use s_client to try to connect to a new server with a command of the form:

    openssl s_client -connect somehost:someportnumber

That command could be followed by flags to test out the particular settings of interest (e.g., certificate options, support for specific ciphers, or simply printing out session information for debugging). But with an unpatched OpenSSL, the command does not work if the host requested is only reachable via IPv6. Similarly, s_server can listen on any port, but if the connection requests originate from an IPv6 address, it fails.

Patches and other options

Stapelberg linked to the OpenSSL request tracker (which requires logging in with a username and password; guest/guest is acceptable), showing seven open requests that match "ipv6." Of those, three are requests to support IPv6 addresses in s_client or s_server, and all three include patches. The most recent is RT 2051, which was originally opened by Michael Tuexen in 2009, and which has received regular patch updates as new OpenSSL releases have come out. The latest update is from December 28, 2011.

Questions have also come up on the OpenSSL mailing lists about IPv6 support. What seems to frustrate the question-askers is that the library supports IPv6 addresses in most core routines and internal data structures. In addition to the s_client and s_server testing tools, however, there are places where the API is unaware of IPv6 addressing. Namely, an application cannot use the OpenSSL library to create a new socket to an IPv6-addressed host — but the application can create an IPv6-addressed socket separately (or using a different library), then hand that socket over to OpenSSL.

In the comments on Stapelberg's Google Plus post, Florian Foster asked why anyone would use OpenSSL, which is hardly the only game in town, particularly when GnuTLS fully supports IPv6 addresses both in its API and in its command-line tool gnutls-cli. Watson Ladd concurred, and also noted that OpenSSL still has big holes in its documentation. Gregory P. Smith commented that the bulk of the SSL/TLS traffic on open source systems probably comes from the Netscape Security Services (NSS) library used by Mozilla applications and Google Chrome (as well as by many mail user agents and server products from Red Hat and Sun).

There is an argument to be made for each of those positions. GnuTLS support does IPv6 pervasively, OpenSSL's official documentation does list four out of its six man pages as "STILL INCOMPLETE," and NSS probably does handle the lion's share of SSL/TLS bits in open source software — at least on the client side. But even when taken collectively, the three arguments do not justify throwing up one's hands in disgust and uninstalling OpenSSL.

First, GnuTLS was started in order to provide a GPL-compatible alternative to OpenSSL, which is dual-licensed under the Apache 1.0 license and the "old-style-BSD-like" SSLeay license. As a result, GnuTLS is used heavily by official GNU projects, as well as by large projects like GNOME and CUPS. But OpenSSL remains more popular on the server side, in web frameworks, virtual private network (VPN) tools, and mail servers, plus system utilities like cryptmount and wpasupplicant. The need to maintain license compatibility can restrict a project's options regarding which library to use — such as commercial vendors wishing to avoid GPL-licensed code. Second, even though the two projects are roughly on par, they do differ in the details when it comes to protocol and cipher support, which could make the difference for other users.

So who cares about IP addresses anyway?

It is a little unclear why it has taken so long for the IPv6 patches to get merged. In 2009, Arkadiusz Miskiewicz objected to the style in Tuexen's patch, but Tuexen responded, and subsequently the patch was met with approval. OpenSSL core developer Stephen Henson chalked it up to a simple matter of time. "There has been a fair bit of activity lately related to the FIPS 140-2 validation work and the upcoming release of 1.0.1", he said, after which the team "can look at getting several patches including IPv6 support in place".

The only real ongoing objection to explicitly supporting IPv6 has been that IP addresses are not a fundamental SSL/TLS concern to begin with. The argument goes that TLS runs on top of TCP (and DTLS on top of UDP), so an application requiring TLS or DTLS must deal with the TCP or UDP connection, regardless of the state of the Internet layer beneath it. That is true to an extent; SSL/TLS is agnostic about what lies beneath the transport layer — but it clearly does not apply to the command-line testing tools that ship with OpenSSL. They are supposed to emulate an SSL/TLS client and server, after all, all the way up to the application layer, and not patching them means application developers must turn elsewhere.

Tuexen and others have updated the patch for both the current development version of OpenSSL and for the older releases. As Stapelberg mentioned in his Google Plus post, Debian adds the patch downstream (which is then picked up by Ubuntu and derivatives); so too does Red Hat (including Fedora).

Regardless of whether IPv6 support is conceptually important to the package, then, the interest in IPv6 tools among developers and sysadmins seems clear. The risk to the project is that by letting the patch languish for years, potential new developers may head towards GnuTLS or another competitor rather than wait. At 13 years of age, OpenSSL is a mature project, and it certainly deals with subjects that demand a lot of domain expertise, such as cryptography. Consequently it may find it difficult to recruit new contributors.

But two years is still a long time for an actively-updated patch to remain in limbo. As is the case with the still-incomplete man pages, OpenSSL probably gets more leeway than other projects thanks to its solid reputation for robustness. But it is also a gamble — in the comments on Stapelberg's post, there is frustration with the project on several fronts, and one never knows when goodwill is going to run out.

Index entries for this article
Security	OpenSSL
GuestArticles	Willis, Nathan

---

to post comments