This post is about the 'openssl' tool that is provided with the OpenSSL library not supporting IPv6 - not OpenSSL itself! As far as I'm aware, IPv6 support has been provided by the library for a while.

The library has nothing to do with IPv6 - SSL is not in that layer

That must be why these functions don't exist:

http://openssl.org/docs/crypto/BIO_s_connect.html

While the library isn't what's at issue here, your assumptions are way off. IPv4-capable code doesn't magically become IPv6-capable code by virtue of running on an IPv6-capable OS. Functions like these require some tweaking to be made to use new IPv6-capable structs as well as getaddrinfo. The switch is not invisible to anyone making socket API calls.

The link's "getting angry" comment reminds me of this bug report bingo card: http://the-b.org/~kenny/bingo.txt

Which I just saw linked from this issue with an open source Android app: http://code.google.com/p/connectbot/issues/detail?id=100

It's an amusing list of all the complaints and threats issue reporters make trying to get someone to do work for them for free. :)

Heh, that’s a good list and what you describe does happen often.

Being a developer myself, I try hard to not make that impression when reporting bugs. I always check first if the issue was reported and don’t post unless I have some value to add. If there is no fix yet, I fix it.

However, in this case, there are (working) fixes and I don’t see any other method to contribute to fixing this issue apart from raising awareness and thereby maybe getting an OpenSSL developer to merge the patch.

Right - the polite thing to do on their part would be to either 1) say why the patch and others like it are not acceptable 2) comment on what needs fixing/improving (docs? test cases?) in order to accept the patches, or 3) declare that they are no longer able to maintain the code, and if someone wants to take it over, go ahead.

Is there any way to read this without signing into a Google account. On my mobile device I am getting a prompt to sign into Google.

Here you go:

Michael Stapelberg - 4:41 AM - Public Nearly every time I use the OpenSSL command line tools I get angry. It’s 2012 and OpenSSL’s s_client still doesn’t work with IPv6. Every time, I go to the Debian bugtracker first. Every time, I see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589520 and apply that patch.

I’ve been doing that so often, that I had enough of it and went to the OpenSSL request tracker: http://rt.openssl.org/index.html?q=ipv6 (user/pass: guest/guest). Turns out they actually have several patches lying around for that. The oldest one is 5 years old!

I cannot understand how the OpenSSL developers fail to merge several working patches for an issue which is obviously important enough for several people to come up with various patches for 5 YEARS! :-(

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589520

Welcome to the end of the www as we know it. Where you request permission to follow an interesting sounding link on HN by logging in to Google.

Only if you're on a mobile device, though. On a desktop browser you can access it without being logged in to Google.

Yeah this seems more like a bug/oversight on the G+ team's part than something planned.

There are OpenSSL alternatives if you're prepared to walk the path less travelled.

One I've taken a shine to lately is PolarSSL[1], which has the nice quality that you can selectively compile only those modules you need. Consequently the API is quite simplified and you can use it as a library rather than put up with the framework-y bookkeeping OpenSSL requires.

I wrote a small wrapper to access the SHA-384/512 component in Lua[2]. Compared to a 500k+ OpenSSL .so, the PolarSSL version weighs in at 22k. It was a great learning experience.

[1] http://polarssl.org/ [2] https://github.com/jchester/lua-polarssl

Sorry, but I prefer my crypto being tried and tested:

"What makes you think you can invent a good cipher if y ou have no expertise in the subject? Maybe you can, but it's not terribly likely. Imagine how you would react if your doctor told you "You have appendicitis, a disease that is life-threatening if not treated. We have a time-tested cure that cures 99% of all patients with no noticeable side-effects, but I'm not going to give you that: I'm going to give you a new experimental treatment my cousin dreamed up last week. No, my cousin has no medical training. No, I have no evidence that the new treatment will work, and it's never been tested or analyzed in depth -- but I'm going to give it to you anyway because my cousin thinks it is good stuff." You'd find another doctor, I hope. Rational people leave medical care to the medical experts. The medical experts have a much better track record than the quacks." -- David Wagner PhD, sci.crypt, 19th Oct 02.

PolarSSL invents no new ciphers. It implements the well-known ones.

More to the point, it is in my unprofessional opinion easier to verify the PolarSSL implementations because they are all completely standalone. By design you can compile a single .c file and it will do what you expect.

OpenSSL has its advantages, to be sure. It's more widely used and thus theoretically yields better for Linus's Law. Its maintainers also take great care to squeeze extra performance out of different architectures.

But for my case having the smallest possible reliable implementation of the SHA-512 algorithm is what I want.

I principally agree, but the analogy from the excerpt you quote represents a chicken-and-egg problem.

Where did the medical experts come from? Every tried-and-tested medication was once a new, experimental treatment. Every doctor was once a quack without medical training (the analogy starts hinging here, but I hope you get what I'm trying to convey).

So yeah, it's most likely a better idea to use a battle-hardened approach in crypto in most cases, but that shouldn't become a fundamental stance opposing anything new because, well, it's new.

Five years is a long time. However, with something as important as OpenSSL, some degree of discretion and evaluation should be done before patches are merged.

Does anyone know the reason for the delay? I can't imagine that it's just them being lazy, for instance. Maybe they don't have the time and resources to properly analyze something as critical as this?

Edit: I guess what I mean to say is, for OpenSSL I'd rather have no feature than a feature with a security vulnerability.

Found on the openSSL dev list:

Newsgroups: mailing.openssl.dev From: ku...@tenebras.com (Michael Sierchio) Date: Wed, 30 Jul 2008 08:02:41 -0700 Local: Wed, Jul 30 2008 3:02 pm Subject: Re: IPv6 support in OpenSSL Ravindra wrote: > I'm looking for information regarding IPv6 support in OpenSSL. > Which is the first and stable version that adds support for IPv6 in OpenSSL ?

SSL operates atop TCP.  Whether this supports IPv6 is left as an exercise for the reader. - M

PS  Does your web browser support IPv6?  Does your monitor?  How about your keyboard? ______________________________________________________________________ OpenSSL Project                                 http://www.openssl.org Development Mailing List                       openssl-...@openssl.org Automated List Manager                           majord...@openssl.org

If you add two ' '(space) characters in front of a line, HN will stop "formatting" your text.

awesome I've been trying to figure out how to do that myself. Is there any place that has a list of all of these things?

https://news.ycombinator.com/formatdoc (it's linked from the FAQ)

I honestly can't see why that isn't linked from the posting page.

What's even more strange is that it isn't linked from the new post page, as you said, but it is linked from the edit post page.

The complaint was specifically about IPv6 support in s_client though. Hardly seems to be something that would add any risk to openssl itself (though I haven't looked at what the patches touch). s_client is a handy tool when you need it, but I'd wager that it's one of the least-used utilities the openssl suite. It may just be a case of limited resources focusing on stuff that has much higher usage.

Thing is, OpenSSL itself fully support IPv6, the hangup is in s_client and s_server (the generic SSL/TLS command-line client and server).

And as noted in the bug tracker, OpenBSD has been running with a patched s_client for quite some time.

OpenSSL's command line tools are so antequated and annoying that I can't help thinking that they're being held back by the Powers That Be so as to discourage casual crypto.

This annoyed me recently as I was attempting to test a daemon that was running on IPv6 only. Ended up using some netcat magic to bounce it from IPv4 to IPv6...