Hacker News Reader

Comment by gnu8 | Hacker News Reader

Their web page says OpenSSL group is their first candidate for funding. It's puzzling that they would choose to fund such a corrupt and incompetent organization over LibreSSL, which is actually fixing the code and ultimately is what will actually be used.

Or maybe it's not so mysterious, the principle companies involved have a long record of benefiting from OpenSSH and never contributing to that either.

View on HN

LibreSSL is a fork for OpenBSD and doesn't have all the functionality of openSSL (e.g., no Windows support), so it's not a given that LibreSSL will actually become the standard. Also, despite the issues with openSSL, there is significant name recognition for it. That means that funding and improving openSSL can potentially lead to a better outcome than funding libreSSL. I mean this in the sense that funding something else (e.g., LibreSSL) could result in a situation where people still use openSSL because they know the name but that the improvements are going elsewhere. Sure, you can say that people should switch, but name recognition can be tough to overcome.

This is untrue. It removed Windows build support, not Windows support.

That's not exactly accurate. In its current form, you couldn't compile OpenBSD's libssl on Windows even if you had a build system for it.

However, I don't think this is a bad thing. To do a massive clean up, you must be able to focus on code that you can actually compile and test. Dead code, code behind ifdefs is likely to rot. If it wasn't very rotten already.

It is better to do a fresh port of a cleaned up code base for modern systems.

Like removing long long multiplication just for Tandem.

To make the code auditing easier a number of code paths irrelevant to OpenBSD were removed.

Once the code is audited and bugs corrected portability is next. This will only happen if the right team is in place, the community wants it, and sufficient funding is secured.

I think as long as LibreSSL plans on ripping out the FIPS stuff, it's not going to replace OpenSSL in a huge number of places. Don't get me wrong, I think it's the right decision for the OpenBSD guys, and for the security of the library, but it's definitely going to limit adoption.

FIPS support is such a rare requirement (and such an awful one) that I'm willing to bet LibreSSL, once it's 'finished' and buildable on the typical Linux system, will be gladly adopted by pretty much everyone who can. Distros will probably prefer LibreSSL whenever possible, with the exception of Debian, unless the licensing issue can be resolved (which I hope it is because GnuTLS is awful).

The vast majority of people who use OpenSSL don't need FIPS compliance, and LibreSSL will provide them with a more solid, better reviewed, more secure, lightweight, reliable drop-in replacement. It's hard to argue with that.

FIPS support will be required by RedHat, SuSE and any other vendor that wants to do business with the US (and many other) federal governments.

If none of the major vendors will ship a non-FIPS certified crypto lib, then where exactly will it get used?

The OpenBSD guys are applying their knowledge in system designs to sanitize the code and making it more standard. It doesn't qualify them to work on the algorithm parts.

How many years have you been benefiting from the work that was put behind OpenSSL ? What about being a bit grateful for the amazing work they did with basically no funding ?

> It doesn't qualify them to work on the algorithm parts.

Since they also develop OpenSSH, wouldn't that qualify them to also work on the algorithm parts?

I've actually been wondering lately, if a for of openssh would be a good idea, with the goal of ripping out version 1 support, some other cruft, and eg: arcfour and other algorithms that seem a bit redundant and potentially dangerous (to me) these days.

So far, I'm thinking that the odds that I'd introduce some horrible bug (either along the lines of the Debian ssl keygen bug) or perhaps more likely increase vulnerability to timing attacks outweighs the potential benefits (a tighter, more transparent code base, with fewer features and hopefully fewer bugs).

For some of the core crypto stuff, yes.

But, TLS is a huge spec, and I think the OpenSSL guys are going to have more experience in things like "Older (and widely deployed) F5 networking devices attempt to parse a TLS Handshake as SSLv2 first, which means that due to the overlapping structure, an SSLv3/TLS client-hello of length 256 - 511 bytes, it can't tell if a certain byte is a "message type" of 1 (SSLv3/TLS) or it is the "length high bits" to be 1 (SSLv2). Therefore, despite no mention in the spec, it's useful to pad out the CLIENT_HELLO to remove the ambiguity." (Just to use a recent example)

TLS is a horrible mess of a spec, and the real-world implementations are even grittier. While I'm not knocking the OpenBSD guys at all (and I think what they're doing is great), let's not forget that OpenSSL got it's place because despite the code quality, it's one of the most fully-featured TLS stacks out there due to the knowledge and experience of it's developers. I hope to see lots of code flowing in both directions between the two projects.

It is amazing to me that I buy a computer with an OS and aparently zero of that money goes to the people writing some of the important code used in that OS.

Windows used to use BSD stuff for the network stack. OSX uses a lot of BSD stuff. These are not poor companies. Including a per-licence donation of a few US cents would have been a significant contribution.

I think Microsoft was maintaining their own fork of the BSD stuff. The money for support was going to the internal team maintaining it.

I don't know about corrupt and incompetent... maybe under-resourced and apathetic babysitters of a legacy-ridden codebase.

I don't mind it if people fund and contribute to OpenSSL. Improved software is improved software whether you prefer another fork or not.

However, I will personally refrain from funneling money into any project if it is not clear that money will make a difference. It's like donating to charities who cannot ensure the money actually ends up in the right place and actually helps the lives of the people who they (cl)aim to help. I'm more likely to donate to projects that have proven their worth, like OpenBSD. The proof, hard work, should come first. Donations might follow.

> The proof, hard work, should come first. Donations might follow.

Part of the problem with funding open source is that an agent acting only in their own short term interests is going to say: "ok, someone already did the hard work, the results are free!", and won't donate anything.

That's not a problem with funding open source. That might be a problem with getting money if you start doing open source and expect money in return.

What other people do (or don't do) doesn't really matter. If I refuse to donate to a project, and Apple makes a non-free derivative of that project, that project is still free and you can still fund it.

It's very much a problem with funding open source because no one pays for the developers, leading to stuff like openssl in its current state, that everyone depends on, but no one pays for!

I agree with your assessment of who to donate to, by the way, I'm just saying that the whole thing is a bit difficult.

> That's not a problem with funding open source. That might be a problem with getting money if you start doing open source and expect money in return.

This is a distinction without difference. If you're not getting money for doing open source development, your open source development has no funding.

How exactly are they corrupt?

It's worth noting that a number of the businesses that are contributing will have a need to provide FIPS compliant services, something LibreSSL has completely thrown out the window.

I think it's spectacularly naive to assume LibreSSL will be widely adopted beyond FreeBSD just because it's a cleaner codebase.

Just because.

What if it also had fewer bugs, is more receptive to contributed bug fixes, runs clean in Valgrind, etc.?

The point of LibreSSL is to be a potential competitor and an apparent existential threat to scare OpenSSL into getting its house in order.

I don't think that's the point. I think OpenBSD devs just want secure code, and they get it by doing the work. So that's what they do. No hidden agendas.

If this fork makes OpenSSL developers be more responsive to patch fixes and have them improve their documentation it's a win for OpenSSL and their users at large.

OpenBSD is already reaping the benefits from a better TSL implementation in -current so it's a win for our project as well.

This is a win win scenario.

Exactly. When a popular security project has no clear competition, a code "monopoly" may exist and it's much easier to get complacent. By introducing "competition," it tends to keep both projects adversarial and vigilant... which is exactly what a security project needs.

The primary goal of LibreSSL is to fix the OpenSSL codebase for OpenBSD. If other communities like the changes there could be a portable versions as alluded by the LibreSSL web site.

Think OpenSSH -> OpenSSH-portable.

Reply on news.ycombinator.com