User: Password:
|
|
Subscribe / Log in / New account

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Ars Technica reports on the OpenSSL project's new roadmap that describes a number of problems with the project and its code along with plans to address them. "The project has numerous problems, the roadmap says. These include a backlog of bug reports, incomplete and incorrect documentation, code complexity that causes maintenance problems, inconsistent coding style, a lack of code review, and having no clear release plan, platform strategy, or security strategy. The plan is to fix all these problems. For example, bug reports should receive 'an initial response within four working days.' That goal can be met now, the roadmap says, but others will take longer. Defining a clear coding standard for the project is expected to take about three months. 'Review[ing] and revis[ing] the public API with a view to reducing complexity' will take about a year."
(Log in to post comments)

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 3, 2014 18:35 UTC (Thu) by ledow (guest, #11753) [Link]

Too little, too late?

Just the admission that the code hasn't been audited, contains lots of untested legacy code, and is too complex for even users should be regarded as project death for such a security-conscious application.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 3, 2014 20:25 UTC (Thu) by m45t3r (subscriber, #92849) [Link]

Actually a project that is a library (like OpenSSL is) is only death when no active projects are using it. Since OpenSSL is used in lots of projects, the project isn't death even if it's a mess.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 14, 2014 13:57 UTC (Mon) by jwarnica (guest, #27492) [Link]

Other projects using it, (or continuing to use it when LibreSSL gets something shipping) doesn't make OpenSSL alive, it makes those projects necrophiliacs.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 3, 2014 19:02 UTC (Thu) by flussence (subscriber, #85566) [Link]

My cynical interpretation of this roadmap:

A year from now, and if everything goes perfectly to plan, OpenSSL hopes to catch up to where a fork with a tiny fraction of its resources currently is.

To their credit, at least they've finally admitted to having problems...

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 3, 2014 19:07 UTC (Thu) by roskegg (subscriber, #105) [Link]

If they were smart, they'd hand half their $$ over to LibreSSL and say "you do our work for us while we go out and raise more money." But then the NSA collaborators at the Linux Foundation would probably deny them funding the way they've shunned libressl. Lose lose scenario.

If you follow OpenSSL Valhalla Rampage every day, how can you not conclude that OpenSSL was a deliberate act of sabotage. And now they are getting rewarded with MOAR dollarz!

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 4, 2014 5:00 UTC (Fri) by zenaan (subscriber, #3778) [Link]

Linux Foundation is almost looking suspect, in the light of what has so recently transpired, but I understand their difficulty in supporting non-target-able funding for BSD - no guarantees of funding getting to libreSSL.

Still, I'm sure some solid collaboration would make sense here, including some "goodwill" funding. Alas that has not happened.

I am guessing that the funders of LinuxFoundation got 'demanding' behind the scenes, and so LinuxFoundation had to appear to do something? A shame if LinuxFoundation has succumbed to management stupidity...

This is all currently speculation, but nevertheless based on what has transpired in the public media. LinuxFoundation leaves a little to be desired on this round IMHO.

Zenaan

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 4, 2014 6:04 UTC (Fri) by roskegg (subscriber, #105) [Link]

> I understand their difficulty in supporting non-target-able funding for BSD - no guarantees of funding getting to libreSSL.

What difficulty is that? I've never had difficulty ear-marking my donations to the OpenBSD foundation. I've found the OpenBSD developers and staff to always be approachable and easily available to discuss things.

Linux distributions incorporate important pieces from the OpenBSD project; it shouldn't be afraid to fund it.

A lot of people justify withholding support from OpenBSD by saying "Theo de Raadt is an asshole". Theo de Raadt has always spoken TRUTH and spoken up quickly when people are misbehaving. That makes him honorable and trustworthy, not an asshole. He deserves far more support than he's been getting. The assholes are the people who are trying to screw over the users; the people that Theo has been exposing.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 4, 2014 7:51 UTC (Fri) by khim (subscriber, #9252) [Link]

Theo de Raadt has always spoken TRUTH and spoken up quickly when people are misbehaving. That makes him honorable and trustworthy, not an asshole.

Actually that's exactly what makes him “asshole” and “trustless”. Truth is not something objective, there are many shades of it. People operate under many taboos. E.g. if you'll try to go against LGBT equality in US you'll quickly find out that it's just not allowed. On the other hand in Iran you'll be a pariah if you'll try to promote LGBT right (you could be even sentenced to death!). It's pretty obvious that both approaches could not be right, but both are “truth” as far as citizens of these countries are concerned. And if you move from Iran to US (or back) you MUST accept different “truth”. These are basic “agreements” of the society, there are many such things (just less severe), but people like Theo could not do the appropriate bending and thus could not even agree to the bare minimum of what is needed to be considered trustworthy.

This may be a bad thing (actually it's most likely a bad thing), but it's also human society works.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 11, 2014 15:13 UTC (Fri) by Karellen (subscriber, #67644) [Link]

Truth is not something objective, there are many shades of it.

Uh, no, it is objective. That's what makes it "truth".

People operate under many taboos. E.g. if you'll try to go against LGBT equality in US you'll quickly find out that it's just not allowed. On the other hand in Iran you'll be a pariah if you'll try to promote LGBT right (you could be even sentenced to death!). It's pretty obvious that both approaches could not be right, but both are “truth” as far as citizens of these countries are concerned."

You keep using that word. I do not think it means what you think it means.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 19, 2014 0:02 UTC (Sat) by Wol (guest, #4433) [Link]

> Uh, no, it is objective. That's what makes it "truth".

If you're so certain that you know what "truth" is, would you mind explaining to us mere mortals - uh, I mean philosophers - who have been searching for the answer for centuries - what "truth" really is?

Let's be objective about this. What is an electron? Is it a particle or a wave? Are we humans particles or waves?!

Or let's say we simultaneously observe two events, both a light year away. Which occurred first?

I'm sorry, but if we are clueless as to the "truth" of such fundamental matters as that, then how can we know the "truth" as you see it?

Oh - and my take on the LGBT thing? Well, imnsho the question "what sex are you" is biologically meaningless, so the whole thing just doesn't doesn't make sense!

Cheers,
Wol

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 19, 2014 1:02 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

> Or let's say we simultaneously observe two events, both a light year away. Which occurred first?

I think the standard interpretation here is that it's basically indeterminate and due to relativity, basically irrelevant since you can't even ask the question, so I answer "mu".

If you think about it, there is somewhere such that one event is outside its light cone and the other inside, so from that vantage point, one may as well never have happened.

> if we are clueless as to the "truth" of such fundamental matters as that, then how can we know the "truth" as you see it?

Just be cause we don't know what it is doesn't mean that there can't be just one "truth". Things can be true whether we know them or not. Of course, philosophers can argue as to whether we're wrong in looking for only one or not…

> the question "what sex are you" is biologically meaningless

Do you mean "gender" here?

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 22, 2014 1:04 UTC (Tue) by Wol (guest, #4433) [Link]

> > the question "what sex are you" is biologically meaningless

> Do you mean "gender" here?

Maybe I do, maybe I don't. Where's the line?

Physically, you can be hermaphrodite.

Genetically, the correlation between your genes and your genitalia is not 100% accurate - some people are XXX or XXY, some phenotypical males are XX, and some phenotypical females are XY.

And mentally, your brain can be a different sex to your body. Yes, there are detectable differences in the brain. And I think this is actually the only 100%, sure fire, guaranteed way of finding out what "gender" someone is - a brain scan. As far as I am aware, if you ask someone what gender they really feel they are, it correlates 100% with the gender of the brain as revealed by a scan - a "man trapped in a woman's body" will have a male brain, and vice versa.

Cheers,
Wol

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 22, 2014 1:21 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

The usual difference I've heard (and personally agree with) is that "sex" is what your genetics say (whether it be XY, XX, XXY, XXX, or whatever else nature can come up with) and "gender" is what you self-identify with. So, to me, "gender" is indeed biologically meaningless[1] while "sex" is defined by it.

[1]Insofar as you can tell by just the sex chromosomes; maybe one day certain genes will be correlated with genders.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 22, 2014 8:24 UTC (Tue) by renox (subscriber, #23785) [Link]

> that "sex" is what your genetics say (whether it be XY, XX, XXY, XXX,[cut])

But in the forms you (usually) cannot answer by XY, XX, XXY, XXX.. but only by woman(XX implied), man(XY implied) so the "sex" in the form cannot really match what the genes say .. and isn't a good match with gender either.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 22, 2014 13:02 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Since when do we make our language conform to what options are available on a form?

I certainly agree it is not a replacement for gender though.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 22, 2014 12:10 UTC (Tue) by Jonno (subscriber, #49613) [Link]

> The usual difference I've heard (and personally agree with) is that "sex" is what your genetics say (whether it be XY, XX, XXY, XXX, or whatever else nature can come up with) and "gender" is what you self-identify with.

Unfortunately it is more complicated than that:

What your genetics say (X, XXX, XXY, XXYY, XXXY, XXXXY, XYY, XX, XY, or a mix of more than one of the above) is usually called "chromosomal sex". Without qualifier "sex" usually refers to "genital sex" (testicles, ovaries, mixed gonads, ambiguous gonads, no gonads, or two or more different gonads).

"Intersex" can refer to anyone with a chromosomal sex other than XY or XX, with a genital sex other than "testicles" or "ovaries", or with a genital sex not matching their chromosomal sex.

There are also "hormonal gender" (what your hormone levels are), "biological gender" (what your outward appearance is), as well as "self-identified gender" (what you think of yourself as), each of which has an unlimited number of variations.

"Transgender" can refer to anyone with a hormonal gender, biological gender or self-identified gender other than "male" or "female", or whose hormonal gender, biological gender and self-identified gender are not all the same.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 20, 2014 14:44 UTC (Sun) by Karellen (subscriber, #67644) [Link]

> If you're so certain that you know what "truth" is, would you mind explaining to us mere mortals

Uh, how about, "being congruent with reality." Is that a reasonable start?

> What is an electron? Is it a particle or a wave? Are we humans particles or waves?!

The truth is that "it depends" - on whether you try to measure its particle-like properties, or its wave-like properties.

On the other hand, if what you're asking is, how can a seemingly singular entity appear to be either a wave or a particle depending on what properties you choose to measure, then the best answer I can give you there is, I don't know. Even though I have a Physics degree. I think the best answer, which serves very well when it comes to many things related to the mechanisms underlying quantum phenonema, is probably "we aren't entirely sure, yet".

Is there a true answer to that question out there? Probably. That's why we keep looking deeper, to figure out what the truth of the matter *is*. That's one of the things that makes truth objective - it exists even before anyone knows what it is.

> Or let's say we simultaneously observe two events, both a light year away. Which occurred first?

The truth is that it depends on your reference frame.

> I'm sorry, but if we are clueless as to the "truth" of such fundamental matters as that,

We're not clueless at all. We are a lot closer to the truth now than we were 100 years ago, and we continue to make progress and get closer and closer to the truth.

Of course, there may be things we think we know, things which we think are true, which we are wrong about. I'm not denying that. But the reason we are able to find out that we are wrong, is that there are actual truths out there. If there weren't, then our ancestors would never have been able to overcome the notion that a 10kg rock fell 10 times faster than a 1kg rock.

> Oh - and my take on the LGBT thing?

Yeah, I've no idea where khim was going with that. Personally, I'd be more interested in finding out what their definition of "truth" was, and in what way they were using the word. Yes, it is true that suggesting that LGBT people should be treated the same as cis heterosexuals will likely get you pariahed (or worse) in Iran, and that the opposite is true in many (but definitely not all) parts of the US. How that is supposed to make "truth" itself a relative concept is beyond me though.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 4, 2014 9:20 UTC (Fri) by PaXTeam (guest, #24616) [Link]

> Theo de Raadt has always spoken TRUTH[...]

heh, another obsd zealot spreading religion. FYI, Theo has proved himself a notorious liar over the years (and when caught he often covers it up with ad hominem), 'truth' is not a word in his vocabulary.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 4, 2014 12:51 UTC (Fri) by dgm (subscriber, #49227) [Link]

A few links with examples would add so much weight to your argument. Without them it's... just weightless.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 5, 2014 9:18 UTC (Sat) by PaXTeam (guest, #24616) [Link]

just look up the past flamefests between us and you'll find plenty of examples.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 11, 2014 9:20 UTC (Fri) by ortalo (subscriber, #4654) [Link]

Yes, but now we know these flamewars were legitimate attempts at spoiling NSA analysts brain resources; so you do not need to hide yourself, we all know you are all righteous servants of the True Security God. [1]
What a wonderful new century in the world of computer security...

[1] Or goddess btw. Wouldn't it be nicer if it was a goddess in the end? And we need to save these charming cryptographers out of Fort Meade.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 4, 2014 11:24 UTC (Fri) by roblucid (subscriber, #48964) [Link]

Why?
Theo et al, are already doing a "free" independant code review and there's value in that independance. Seperate funding avoids taint and group think, or being closely coupled which wouldn't be a pleasant situation.

A better strategy would be to diplomatically review LibreSSL assumptions in the changes they make, to try to catch LibreSSL mistakes, give feedback via a liason person who also makes sure the LibreSSL changes are considered on techinical merit for inclusion in OpenSSL.

Where they differ in short/medium term, is on priority for support of non-OpenBSD platforms, but dropping a whole load of unsupported obsolescent OSes and fixing their portability hacks to be only applied on platforms that need them, doesn't seem controversial.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 3, 2014 21:11 UTC (Thu) by donbarry (guest, #10485) [Link]

Of note is that neither the report nor the roadmap mentions the Giant License Problem. Given the commitment to significant code churn, it would seem very reasonable to mark this as a key part of the roadmap, so that the reimplementation and code cleanup would eventually produce code without the GPL-incompatible advertising clauses.

All the more reason to promote alternative projects which have a commitment to this significant issue.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 12, 2014 13:46 UTC (Sat) by tomgj (guest, #50537) [Link]

But just because all the code's churned through doesn't stop it being a derived work.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 19, 2014 0:15 UTC (Sat) by Wol (guest, #4433) [Link]

If none of the original code is left, then LEGALLY it's not a derived work.

And that's all that matters.

Cheers,
Wol

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 29, 2014 14:54 UTC (Tue) by etienne (guest, #25256) [Link]

> If none of the original code is left, then LEGALLY it's not a derived work.

If someone translate a book from one language to another, then none of the original text is left in the new book, but it is still a derived work...

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 29, 2014 15:13 UTC (Tue) by spaetz (subscriber, #32870) [Link]

It is an old dilemma known as Theseus paradox iirc. If you replace all planks of a ship, is it still the same ship?

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Aug 17, 2014 10:22 UTC (Sun) by Duncan (guest, #6647) [Link]

In computer terms, likely more appropriate for the current audience...

If you replace all the hardware components of a computer, as well as all the software components including switching OSs/distros a couple times and upgraded from (8-bit to) 16-bit to 32-bit to 64-bit over the years, one to several components at a time, each several times over, is it the same computer you started with? If not, since they weren't replaced all at once, at what point was it a different computer, and how many different computers have you had?

While there's certainly those here with computer experience going back well before mine, I'm no longer a young man, and my original first PC was a 486sx25 running MS Windows 3.1 with 4 MB RAM and a 130 MB hard drive. In that I've never actually replaced it all at once, by some weird definition I guess I'm running the same computer, even if it's a 6-core AMD fx6100 running slightly overclocked at 3.6 GHz now, with 16 gigs of RAM and a pair of 256 GB SSDs with multiple partitions mostly configured as btrfs raid1 for the main system, Gentoo/~amd64 Linux as the OS, plus additional spinning rust. Everything has changed a half dozen times over at least (except for the case, only four times for it, I think), but not all at once, and it has always been my primary personal system, and it remains exactly that today. I've only ever had the single computer filling that role, and it has always been the same one, upgrading only a few components at a time.

The best answer to the question I've come up with is that when I change the mobo, which generally also means the memory and cpu, plus often the graphics, with a kernel config changed to match since I run a self-configured and compiled monolithic kernel, that can be defined as a different computer now, even if it's in the same case as the old mobo, with the same monitors, amplifier and speakers, keyboard and
mouse, hard drives and ssds, network cable and router, sometimes the same power supply, etc, attached, and I'm running the same distro and software from it, including the same kernel version even if I've reconfigured and rebuilt it for the new mobo and onboard devices.

I'm certain I'm not the only one here with a similar story, and people do asked how many computers I've had from time to time, and I wonder myself from time to time as well, so it's by no means an empty question.

(I do sometimes wonder why automotive doesn't work that way too, tho. Imagine being able to interchange engines or wheels or transmissions between models as they're all modular, with just the equivalent of a 2.5-inch to 3.5-inch drive adapter if necessary! You could still buy higher economy or better performance engine modules, and there'd still be companies famous for their particular model lines, but most of the major parts would be modular and interchangeable between them as they'd be built to a common standard spec! =:^)

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 29, 2014 17:48 UTC (Tue) by dlang (subscriber, #313) [Link]

copyright is on the implementation, not the idea

OpenSSL and LibreSSL

Posted Jul 3, 2014 22:40 UTC (Thu) by david.a.wheeler (subscriber, #72896) [Link]

I'm happy to see some of the things that OpenSSL and LibreSSL are doing... but saddened by others.

I'm glad that the OpenSSL developers are going to work on making OpenSSL better. My article How to Prevent the next Heartbleed lists some specific analysis tools they should use, and it also notes some of their points (e.g., code cleanups and API simplification). OpenSSL has not committed to any particular analysis approach to start with; I hope they will choose ones that will actually work for problems like Heartbleed.

However, I'm disappointed that the OpenSSL roadmap still doesn't identify fixing its licensing mess. OpenSSL's license is a weird nonstandard GPL-incompatible license. The can sometimes be worked around, true. But generally its license has created a mess, and I think it's greatly decreased the amount of review it would otherwise have gotten. At least one project (GnuTLS) was created because of it. Its license doesn't need to be the GPL; the 2-clause BSD license (like OpenBSD), 3-clause BSD, or MIT license would be just fine. OpenSSL will lack the number of reviewers and resources it should have until the licensing is fixed.

The LibreSSL folks are doing some great technical things, and their snarky comments are fun. Simplifying the API, making the code readable, simplifying the code, and generally approaching portability in a sane way are great things.

However, the LibreSSL folks seem to be interested in preventing FIPS 140 validation. That's certainly one of the first things they threw away, and they have made it abundantly clear that they are uninterested in it. To me, that's a problem. You cannot use cryptography inside the US government without FIPS validation in most cases. The Canadian government (strongly) recommends it. In addition, many other organizations also require FIPS validation (because they want someone to look over their crypto). Few vendors want to sell two different products, so in practice, most organizations will only use crypto libraries if there's a FIPS configuration available for it. (E.G., Samsung and Apple sell mobile phones, and they make sure they're FIPS validated so that they can sell to those markets.) OpenSSL has FIPS validation. LibreSSL, as far as anyone can tell, will not.

FIPS 140 has many problems. Also, FIPS 140 focuses on stuff like encryption, and doesn't cover protocols (like SSL), so expecting FIPS 140 to find Heartbleed would be absurd. The LibreSSL folks are welcome to do whatever they want, but they are clearly not interested in meeting the minimum requirements of millions of people. Sure, many people are not required to follow FIPS... but nobody wants to do things twice. The LibreSSL folks should not expect to get funding for stuff a lot of people can't use.

In the end, I want to see at least one good OSS crypto library that has a license everyone can use, is technically very strong, and can be used by everyone because it's gone through the various evaluations necessary for their widespread use. I'm sure it could happen. I'm concerned that it might not happen any time soon.

OpenSSL and LibreSSL

Posted Jul 4, 2014 1:20 UTC (Fri) by roskegg (subscriber, #105) [Link]

FIPS140 may be a government requirement, but it reduces security. If someone approached 3 key LibreSSL developers with even 1/2 of the amount that is being thrown at OpenSSL, I'm sure FIPS would become an option in the "portable" version of LibreSSL. And it would be a clean dropin, easy to maintain. Or they would fork a "fipssl" in the same way they fork the portable libraries from the OpenBSD specific ones.

The OpenBSD team are the ones doing the most for good security; they are also committed to real Liberty. Ever since the DARPA thing a few years ago, money is consistently being withheld from OpenBSD. This is a dirty shame. If not for OpenBSD, the free software movement, and the internet, would be a much worse place.

OpenSSL and LibreSSL

Posted Jul 4, 2014 7:33 UTC (Fri) by khim (subscriber, #9252) [Link]

The whole thing is incredibly backwards. The fact that there are many-many users who need FIPS 140 is not as important here. But the fact that most organizations with money have FIPS 140 as a basic requirement means that noone will bother to even talk with LibreSSL developers.

If someone approached 3 key LibreSSL developers with even 1/2 of the amount that is being thrown at OpenSSL, I'm sure FIPS would become an option in the "portable" version of LibreSSL.

Maybe, but then again, may be not. Why deal with people who start their development with “f*uck you, sponsors” move if you could deal with more reasonable people?

Remember that many (not all, but many) of these companies are not really interested in security (or else they wouldhave protested against crazy FIPS 140 requirements long ago), they are interested in checkboxes. And it's certainly easier and simpler to obtain these checkboxes when you deal with people who understand such a simple facts of life.

Ever since the DARPA thing a few years ago, money is consistently being withheld from OpenBSD. This is a dirty shame.

Indeed. But it's also something which neither side wants to change. OpenBSD developers reinforce the notion that they don't want to play by the rules again and again (removal of FIPS 140 support is just one link in a long line of them) and the other side reinforces the notion that it does not want to deal with someone who does not to play by rules. This may be sad, but it's also perfectly normal reaction.

OpenSSL and LibreSSL

Posted Jul 4, 2014 7:48 UTC (Fri) by roskegg (subscriber, #105) [Link]

Making secure software isn't "playing by the rules"? What rules are these and where can I read them? The rules of being polite and never mentioning that the emperor has no clothes?

Why are you negging on OpenBSD for playing by rules of honor? Disgusting hypocrisy and acquiescence are no kind of rules for those that would provide us with security.

Think of it like the US Marines; who do you want storming the beach? A 90 pound weakling with perfect manners who throws himself in front of the cannons every time his commander tells him to? Or a cigar-chomping jackboot who screams and shouts... then goes and takes the beach?

The security of my data is important to me. I know who I trust more to keep it safe.

You seem to be saying that the members of the Linux Foundation are check-box tickers, who don't care about security. If they do give OpenBSD some money for libressl, that would prove you wrong.

OpenSSL and LibreSSL

Posted Jul 4, 2014 8:30 UTC (Fri) by khim (subscriber, #9252) [Link]

Making secure software isn't "playing by the rules"? What rules are these and where can I read them?

Why do you think they are written somewhere? These are rules which govern IFF systems of the society. As such it'll be strange to see them written: this will make it so much easier to fake them without truly accepting them.

The rules of being polite and never mentioning that the emperor has no clothes?

Not exactly, but yes, something like this.

Think of it like the US Marines; who do you want storming the beach? A 90 pound weakling with perfect manners who throws himself in front of the cannons every time his commander tells him to? Or a cigar-chomping jackboot who screams and shouts... then goes and takes the beach?

You know the answer, or else you would not ask the question, LOL. But let me ask me counter-question: who will most likely have the right to send marine corps to the death-ridden beach: 180 pound weakling with perfect manners or cigar-chomping jackboot?

Theo tries to obtain the position of “180 pound weakling who could push marine corps around” by being “cigar-chomping jackboot”. It just does not work.

You seem to be saying that the members of the Linux Foundation are check-box tickers, who don't care about security.

Most, but not all of them, sure.

If they do give OpenBSD some money for libressl, that would prove you wrong.

Not necessarily. They could put that under “diversity of suppliers” checkbox. But I doubt that'll happen.

OpenSSL and LibreSSL

Posted Jul 4, 2014 17:49 UTC (Fri) by david.a.wheeler (subscriber, #72896) [Link]

"The rules" in the US are US law and regulation. The Federal Information Security Management Act (FISMA) of 2002 mandates the use of FIPS within the government in a large variety of circumstances, and waivers are forbidden. NIST defines FIPS 140, the spec for cryptographic modules; details here: http://csrc.nist.gov/groups/STM/cmvp/index.html

The US government want to independently test a crypto module before the government uses it. That, I hope, seems reasonable. They have also defined a process for independently testing crypto modules before they use them. OpenBSD has a great reputation in the tech field, but the US government don't care about mere reputation; they require that it go through this process. Lots of other people want crypto modules independently tested too; since doing this is expensive, other large organizations use the FIPS 140 validation process as a signal that the module is probably okay to use.

US law does not require Canadian developers of cryptographic modules to implement FIPS 140. However, these modules cannot be used by the US federal government. The US federal government had 4.3 million employees in 2012, and I suspect a vast majority must use a FIPS 140 validated crypto module (employee counts are here: http://www.opm.gov/policy-data-oversight/data-analysis-documentation/federal-employment-reports/historical-tables/total-government-employment-since-1962/ ). When you add all the other organizations that also care about FIPS 140, you're basically throwing away a big market. I'm sure that the companies behind the Linux Foundation want to download just one crypto module and use it everywhere, and I expect that they want to be able to say stuff like "yes, it's FIPS 140 validated" to any potential buyer.

If you want to say that FIPS 140 needs fixing, sure. I completely agree. Heck, NIST itself would agree, since they've been working to update the spec (I'm not sure what the situation of its update is). But the way to fix FIPS 140 is to work with the people writing the specs. Joe Purchaser in the government is required to only use crypto with FIPS 140 validation, and is not permitted to do anything else. The LibreSSL folks are free to ignore the needs of millions of users, but ignoring users is a problem. I see no technical reason that LibreSSL couldn't be validated in the future, but the current comments from their developers do not give me much hope that this is realistic.

OpenSSL and LibreSSL

Posted Jul 4, 2014 1:28 UTC (Fri) by roskegg (subscriber, #105) [Link]

> You cannot use cryptography inside the US government without FIPS validation in most cases.

Really? Are all the web browsers used in US government offices, FIPS certified? Noone ever downloads and "tries out" a new web browser? There are special use exceptions, and they are becoming more common. Time for the backdoored FIPS140 turkey to die.

FIPS 140 validates crypto modules not web browsers

Posted Jul 4, 2014 14:01 UTC (Fri) by david.a.wheeler (subscriber, #72896) [Link]

FIPS 140 validates "cryptographic modules", not web browsers. Usually the web browser calls down to some library provided by the OS (or can be configured to do so), and THAT module is often validated. If it won't call down, then THAT part of the software does indeed have to be validated. I know that Mozilla, Microsoft, Red Hat, and many other organizations are listed as suppliers for FIPS 140 validations, see: http://csrc.nist.gov/groups/STM/cmvp/validation.html

FIPS 140 only covers crypto like AES, and not protocols like SSL/TLS, so FIPS 140 has nothing to do with Heartbleed. OpenSSL updated for Heartbleed without requiring re-validation, because the OpenSSL FIPS module does not include protocol support at all.

I want to see the US government use open source software where it makes sense to do so. It saves my tax dollars, for one thing. Even if you don't work with them, their software selections influence lots of other organizations too. The LibreSSL developers are free to remove FIPS 140 support, but they should expect that makes them way less interesting to many organizations with money. Many organizations will have a simple question: Why should I send money to support a software project I can't use?

OpenSSL and LibreSSL

Posted Jul 4, 2014 1:53 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Isn't the FIPS-ified OpenSSL basically a fork anyways? It's not like its a configure flag as it is (to my knowledge). Plus, with the way FIPS works, the *binary* is certified, not the source, so any vendor would have to go through the hoops unless they use communal binaries (and the certification *really* slows down acceptance of patches). To that end…how many NSA servers are/were vulnerable to Heartbleed until they got their FIPS builds recertified? Or did they scramble and say "oh shit, just patch it for now"?

OpenSSL and LibreSSL

Posted Jul 4, 2014 5:08 UTC (Fri) by zenaan (subscriber, #3778) [Link]

To the OP/ grandparent post:
> FIPS 140 has many problems.

This is statement is true.

A lot of the rest don't smell so good to me.

To the parent post:
> how many NSA servers are/were vulnerable to Heartbleed until they got their FIPS builds recertified?

The NSA is not so stupid as to use FIPS. At least not where security matters. In fact, they probably spearheaded FIPS in order to facilitate their bugging needs.

OpenSSL and LibreSSL

Posted Jul 4, 2014 14:14 UTC (Fri) by david.a.wheeler (subscriber, #72896) [Link]

The current OpenSSL FIPS certification (#1747) is certified at the source level, not binary. That's unusual, but it can happen.

I have no idea what NSA does or doesn't do. I can say that the US government executive branch spent a lot of effort rapidly patching their systems after Heartbleed. Just like most big organizations, it uses OpenSSL a lot. Since the FIPS module doesn't include protocols, and FIPS 140 doesn't evaluate protocols anyway, no one even needed to raise the question "does this invalidate validation?". In any case, if there's a known vulnerability being actively exploited, you typically patch first. The purpose of validation is to reduce risk.

OpenSSL and LibreSSL

Posted Jul 4, 2014 10:16 UTC (Fri) by moltonel (subscriber, #45207) [Link]

> You cannot use cryptography inside the US government without FIPS validation in most cases. The Canadian government (strongly) recommends it.

Certifications are a good thing, we should strive to implement and follow them... As long as their requirements are sane.

If FIPS140 reduces security, then the industry should send a strong message by stoping support for it. Eventually (I know, in some places it could take decades...) the higher-ups will either drop the FIPS140 requirement, or preferably adopt a FIPS N+1 which doesn't suck.

In the meantime, they can use old versions of the certified libraries. Since they didn't mind mandating broken algorythms, they shouldn't mind using broken implementations either.

Droping support for a broken standard is the right thing to do, even if you lose some users in the process. OpenSSL is not a for-profit; they should have the guts to do the technically-right thing, even if from the sponsor's POV it isn't the commercially-right thing.

Let people pay for an inferior product, it's their loss. I don't want it to become my loss because they mandated inferiority in the free product I use.

OpenSSL and LibreSSL

Posted Jul 4, 2014 11:33 UTC (Fri) by roblucid (subscriber, #48964) [Link]

The license mess issue, sounds like something The Linux Foundation ought to press on, or at least provide a rationale why it's tolerable. Least opening up and publishing a road map, allows review and feedback on such points, which may have not been considered.

OpenSSL and LibreSSL

Posted Jul 5, 2014 6:39 UTC (Sat) by xxiao (guest, #9631) [Link]

How to make Linux Foundation listen to arguments like these? Do they visit LWN at all? Do they have a forum to get inputs from OSS community(say, I could copy and paste some debates here to that forum)? I don't sense they care too much about the community other than those big name companies.

I'm all for an OSS-friendly license, and adding FIPS140 support.

OpenSSL and LibreSSL

Posted Jul 8, 2014 20:23 UTC (Tue) by kpfleming (subscriber, #23250) [Link]

I assume that all of the comments here referring to 'Linux Foundation' are in reality referring to the Core Infrastructure Initiative, which is an effort LF is organizing, but is not actually the LF. The CII steering committee is making its decisions based on the input it receives, but as far as I know at the moment there is no public input mechanism. Most of the CII member companies are well known, though, and have channels to accept public input. In addition, some of us involved with CII are in fact LWN readers and pay attention to threads like this :-)

OpenSSL licensing

Posted Jul 10, 2014 16:58 UTC (Thu) by david.a.wheeler (subscriber, #72896) [Link]

Good to know!

I have no problem with OpenSSL having a permissive license: Enjoy! But as I noted above, its use of a non-standard license known to be incompatible with the GPL is a problem. There is a lot of GPL'ed code.

If OpenSSL switched to Apache 2 that'd be a big improvement. Most GPL'ed software is GPLv2+, and GPLv3 is compatible with Apache 2. However, that still leaves a serious incompatibility with the Linux kernel, which is GPLv2 only. I think the OpenSSL folks should use a permissive license (if that is their wish) that is compatible with GPLv2, because combining OpenSSL and the Linux kernel code is often desirable. One solution, used by LibreSSL, is the 2-clause BSD license. There are other solutions.

I'd just like to see a long-term plan to eliminating the license headaches. I think that would also help counter vulnerabilities longer-term.

OpenSSL and LibreSSL

Posted Jul 12, 2014 13:48 UTC (Sat) by tomgj (guest, #50537) [Link]

The LibreSSL folks are doing some great technical things, and their snarky comments are fun. Simplifying the API...
Really? I thought they were staying API compatible.

OpenSSL and LibreSSL

Posted Jul 13, 2014 3:20 UTC (Sun) by raven667 (subscriber, #5198) [Link]

I thought they were trying to stay compatible with common applications, but were removing APIs which are not commonly used.

OpenSSL speeds up development to avoid being “slow-moving and insular” (Ars Technica)

Posted Jul 15, 2014 6:49 UTC (Tue) by thudson (subscriber, #47301) [Link]

FYI - there is more than one OpenSSL team member that is a regular (and long term) LWN reader.

Tim.


Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds