The Linux Foundation's fund for critical projects
The first project under consideration to receive funds from the Initiative will be OpenSSL, which could receive fellowship funding for key developers as well as other resources to assist the project in improving its security, enabling outside reviews, and improving responsiveness to patch requests."
Posted Apr 24, 2014 13:40 UTC (Thu)
by lkundrak (subscriber, #43452)
[Link]
Posted Apr 24, 2014 13:51 UTC (Thu)
by patrick_g (subscriber, #44470)
[Link] (20 responses)
Read the posts from Ted Unangst and Theo de Raadt. It's really horrifying. "OpenSSL is not developed by a responsible team" and the Linux Foundation should not fund them.
Posted Apr 24, 2014 13:57 UTC (Thu)
by lkundrak (subscriber, #43452)
[Link] (14 responses)
Posted Apr 24, 2014 14:05 UTC (Thu)
by patrick_g (subscriber, #44470)
[Link] (5 responses)
Posted Apr 24, 2014 14:48 UTC (Thu)
by proski (subscriber, #104)
[Link] (4 responses)
Posted Apr 24, 2014 17:03 UTC (Thu)
by khim (subscriber, #9252)
[Link] (3 responses)
It's even worse than that. Not only can not it find bugs, it makes it impossible to fix these bugs because FIPS-certified code cannot be changed without invalidating the certification. Not only FIPS certification is useless, it's actively harmful WRT real security.
Posted Apr 24, 2014 22:48 UTC (Thu)
by jeff_marshall (subscriber, #49255)
[Link] (2 responses)
Posted Apr 25, 2014 6:27 UTC (Fri)
by msmeissn (subscriber, #13641)
[Link] (1 responses)
That said, I think the TLS protocol itself was not certified before (not by SUSE), only some of the cryptographic algorithms and the randomness handling.
Also, recertification after code changes is also defined in the standard process, just costs money and has buerocracy again.
Posted Apr 25, 2014 17:43 UTC (Fri)
by jeff_marshall (subscriber, #49255)
[Link]
That was the point I was trying to make above - the SSL heartbeat code can likely be fixed without impacting the FIPS cert because it's probably outside of the "module boundary", and is really just application code using the FIPS module as far as NIST is concerned.
Posted Apr 24, 2014 14:45 UTC (Thu)
by nix (subscriber, #2304)
[Link] (6 responses)
Posted Apr 24, 2014 15:10 UTC (Thu)
by mitr (subscriber, #31599)
[Link]
Posted Apr 24, 2014 16:22 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (4 responses)
Posted Apr 24, 2014 16:56 UTC (Thu)
by zblaxell (subscriber, #26385)
[Link] (3 responses)
It does take FIPS a while to catch up to the state of the art in crypto. Ciphers linger on even though they are weak, and are only removed after people figure out how to break them *in public* (which can be a year or four after people work out how to do such things in private or at great cost). Legacy systems are (were?) excepted, so a broken cipher can still linger around for years.
The one useful thing FIPS does is attract people who want to spend a lot of money on rigorous certification. Sometimes we get lucky and someone fixes a bug while they're doing that. Certification also makes people choose between "spend $40,000 and three months on a bug fix and recert" and "use a certified stack today with known remote wireless exploits." That creates a huge conflict of interest which is good for exactly no one.
FIPS used to be useful in that it prevented people from running crypto that was worse than government standards for commercial use; however, that was the 80's. Now FIPS is as much trailing edge as leading.
Posted Apr 24, 2014 17:54 UTC (Thu)
by drag (guest, #31333)
[Link]
> Now FIPS is as much trailing edge as leading.
The point of FIPS is to not represent the state of the art, but to simply be able to prove that your software is not using any non-government approved algorithms and that those algorithms appear to be correct.
Since the stock OpenSSL library allows the use of crypto types not certified by the government then it's automatically not FIPS compliant.
At the level at which OpenSSL and NSS are certified is mostly a bureaucratic level of correctness more concerned about following the letter of the law rather then any sort of verifiable code correctness or quality of implementation beyond some minimal amount.
When the government decides it's useful to update it's approved crypto list then FIPS will follow suite.
Posted Apr 24, 2014 22:16 UTC (Thu)
by louie (guest, #3285)
[Link] (1 responses)
I don't think you'll find any serious cryptographer who disagrees. And most of them have felt that way for years. But if Theo has magic connections that can make that change happen, then by all means! In the meantime, the companies who provide piles of important software will continue to ship FIPS-compliant software because that is what certain IQ-poor-but-cash-rish customers demand. Which is too bad for all of us, including Theo, assuming he wants people to actually use his software.
Posted Apr 25, 2014 6:41 UTC (Fri)
by palmer_eldritch (guest, #95160)
[Link]
Posted Apr 24, 2014 17:47 UTC (Thu)
by drag (guest, #31333)
[Link]
The FIPS version of OpenSSL was already a separately distributed tarball that was patched to make it compliant. There was is hoops you have to jump through to make sure it's compiled in the correct manner with the correct compiler on the correct OS and make sure your environment is setup correctly so that the application in question is using the FIPS OpenSSL and not the system one. Any divergence from the environment or compile time options rendered the entire exercise mute.
I don't see how that would be any different if somebody wanted to care enough to get a LibreSSL tarball certified.
Posted Apr 24, 2014 18:00 UTC (Thu)
by iabervon (subscriber, #722)
[Link] (1 responses)
Whether or not we should be depending on OpenSSL, it's clear that we presently are, and that they presently need help, so it makes sense for the Linux Foundation to provide funding for now.
Posted Apr 27, 2014 4:42 UTC (Sun)
by eean (subscriber, #50420)
[Link]
Posted Apr 25, 2014 1:51 UTC (Fri)
by rsidd (subscriber, #2582)
[Link] (2 responses)
Posted Apr 26, 2014 11:54 UTC (Sat)
by Lennie (subscriber, #49641)
[Link] (1 responses)
The OpenBSD foundation obviously does accepts funding, but not for specific projects.
You are basically funding OpenBSD-development in general which includes LibreSSL and OpenSSH.
At least that was how it was in the past and OpenBSD isn't know for changing their ways easily.
Posted Apr 26, 2014 14:15 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
Posted Apr 24, 2014 15:08 UTC (Thu)
by TRS-80 (guest, #1804)
[Link] (2 responses)
Posted Apr 24, 2014 17:58 UTC (Thu)
by drag (guest, #31333)
[Link] (1 responses)
As this point the cost of fixing OpenSSL (or a fork like LibreSSL) is going to be dramatically less then porting everything that currently depends on OpenSSL to something else.
Posted Apr 25, 2014 4:22 UTC (Fri)
by TRS-80 (guest, #1804)
[Link]
Posted Apr 24, 2014 17:26 UTC (Thu)
by josh (subscriber, #17465)
[Link] (7 responses)
Posted Apr 24, 2014 18:11 UTC (Thu)
by mtaht (subscriber, #11087)
[Link] (2 responses)
Posted Apr 24, 2014 18:18 UTC (Thu)
by mtaht (subscriber, #11087)
[Link] (1 responses)
from: http://www.lawfareblog.com/2014/04/heartbleed-as-metaphor/
"Heartbleed is getting its fifteen minutes of fame, but what may matter most is that so much of what is being deployed now is in the embedded systems space — network-capable microcontrollers inside everything that has a power cord or a fuel tank. No one watches these and they are treated as if immortal. They have no remote management capability. There is not even a guarantee that their maker knows with precision what went into any one of them after the model year is over. The option suggested by the honeymoon effect is thus impossible, so the longer lived the devices really are, the surer it will be that they will be hijacked within their lifetime. Their manufacturers may die before they do, a kind of unwanted legacy much akin to space junk and Superfund sites."
Posted Apr 24, 2014 18:34 UTC (Thu)
by mtaht (subscriber, #11087)
[Link]
Posted Apr 24, 2014 18:32 UTC (Thu)
by atai (subscriber, #10977)
[Link] (3 responses)
(this is a joke)
Posted Apr 24, 2014 18:46 UTC (Thu)
by drag (guest, #31333)
[Link] (2 responses)
A unfortunately perverse incentive system.
Posted Apr 24, 2014 18:54 UTC (Thu)
by pboddie (guest, #50784)
[Link] (1 responses)
But at least we now know what step 2 is.
Posted Apr 24, 2014 20:05 UTC (Thu)
by drag (guest, #31333)
[Link]
1. Collect Underpants
Makes sense to me.
Posted Apr 25, 2014 7:17 UTC (Fri)
by littlesandra88 (guest, #64017)
[Link]
The Linux Foundation's fund for critical projects
Microsoft
I found this interesting.
“Security is an industry-wide concern requiring industry-wide collaboration. The Core Infrastructure Initiative aligns with our participation in open source and the advancement of secure development across all platforms, devices and services.” – Steve Lipner, partner director of software security, Microsoft.
The Linux Foundation's fund for critical projects
Mr. de Raadt seems to be living in his very own land of rainbows and unicorns. "They don't care for FIPS"
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
I don't disagree, but the validation process has actually resulted in security improvements, even for projects undergoing the validation for a fourth time.
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
And I don't think Theo would want it any other way...
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
It's not zero sum
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
Given the cultural and license problems with OpenSSL, how about they fund a proper 2-clause BSD/MIT/AL2 SSL library instead?
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
Sure, API compatibility with OpenSSL is a requirement. I was also going to say that LibreSSL would be even worse for GPL compatibility than OpenSSL due to poorly worded exceptions, but the actual ones I can find say 'the OpenSSL project's "OpenSSL" library (or with modified versions of OpenSSL that use the same license as OpenSSL)' so that's less of a problem.
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
The Linux Foundation's fund for critical projects
2. Get paid to write shitty code that everybody uses
3. Profit
Why fund OpenSSL when NSA is already doing it?