This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Security

OpenSSL gets hard-fought revalidation

By Lisa Hoover on February 09, 2007 (8:00:00 AM)

Share    Print    Comments   

After a long and arduous journey that included a suspended validation last year, the Open Source Software Institute (OSSI) has announced that OpenSSL has regained its FIPS 140-2 validation and is now available for download. The validation process, which normally lasts a few months, took an astounding five years to complete, and those involved with the projects say they are already devising ways to avoid such long delays in future validations.

OpenSSL is an open source toolkit that allows programs to securely exchange data in the same fashion as proprietary versions of Secure Sockets Layer encryption. It is licensed under an "Apache-style" license that allows users to download the toolkit at no cost, freely distribute it, and use it for both commercial and non-commercial purposes. The tarball, complete source code, security policy, and all documentation is now available on the OpenSSL Web site. Developers are currently working on a user's guide and plan to make it available in the upcoming weeks.

In order for governmental agencies like the Department of Defense to use open source software to manage sensitive data, federal regulations state its security must be validated by the Computer Module Validation Program (CMVP). The CMVP is a joint venture between the US National Institute of Standards and Technology (NIST) and the Canadian agency Communications Security Establishment (CSE). OpenSSL's validation process was managed by the OSSI, whose goal is to encourage the use and development of open source software within educational and governmental agencies.

One reason OpenSSL's validation took so long is because of the new testing approach the CMVP devised to ensure the security of the software. The validation process usually involves testing binary modules for software applications, but that was not a practical approach for testing this particular toolkit. OpenSSL users may, in some cases, opt to compile their own versions, while others will choose a precompiled version. As a result, the software may behave differently according to how it is compiled, necessitating that the CMVP test the source code itself instead of just binary modules. "It's a unique validation," says OSSI technical project manager Steve Marquess. "We did several things for the first time that required a long learning curve for both us and CMVP."

Validating source code wasn't the only thing gumming up the works for OpenSSL. According to John Weathersby, executive director for OSSI, several proprietary software companies with similar products mounted a campaign to delay, if not totally derail, the validation of an open source SSL toolkit. Weathersby suggests that perhaps some vendors of proprietary software felt threatened by the idea that free SSL software that had been validated for government use would undercut their ability to sell similar products to government agencies and decided to interfere with the validation process.

CMVP policy allows anyone, from individuals to companies, to submit comments, questions, and concerns during the validation process. Weathersby said the CMVP received several complaints about OpenSSL, and since either the CMVP or the lab itself must address each concern, the entire validation process was delayed. In fact, OpenSSL had already been validated once only to have it suspended in July 2006 because "anonymous vendors filed extensive complaints," according to Weathersby.

"We called it the FUD campaign," he says. "There were all kinds of complaints sent to the CMVP including one about 'Commie code.' Apparently, OpenSSL was accused of having 'Communist code' in it simply because a developer in Russia had worked on it. Silly or no, each complaint that's filed really slows down the process."

While OSSI was not able to review each complaint the CMVP received, the ones they did see often contained redacted, or blacked-out, data about who had filed the complaint. Some documents, however, did reveal the complainant information, and Weathersby says that is how the OSSI became aware that, in some cases, proprietary software vendors were lodging the complaints.

Marquess says that ultimately the scrutiny led the team to produce an even better toolkit than they had expected. "The FUD campaign slowed us down a bit," he says. "We're vulnerable to that sort of thing because it's all open. With other software [tested by CMVP], all the proprietary information is treated as trade secrets and we can't comment on it. On the one hand, that gives someone an advantage to disparage our work. On the other hand, we've been scrutinized and tested in the open, so we have a much more solid validation than the others."

The software vendors contacted for this article declined to comment.

Avoiding future delays

The biggest frustration OSSI encountered by the seemingly endless delays is that now the software that was validated by the CMVP is more than three years old. "[This toolkit] is branched from version 0.9.7, but 0.9.8 is already available and 0.9.9 is in development," says Marquess. "We're glad it's available, but now it's dated. We understand a lot better what the CMVP's requirements are, though, so validation will go more smoothly next time around. We also know the criticism we'll encounter, and we'll nail them with the next release."

Additionally, OSSI plans to attempt a "rolling validation" designed to produce a validated version approximately every six months. Since all of OpenSSL's source code has passed the testing process, now developers can focus on compiling binary libraries and submitting those for validation, a process that CMVP already uses to test other software and which therefore is expected to proceed much more quickly.

Though the road to certification -- and recertification -- was long, both Weathersby and Marquess say they were buoyed by the constant support they received from the open source community, team members, and volunteers. Even the testing lab, DOMUS, stepped up to the plate and continued to test OpenSSL's source code despite the fact that the project ran out of money to finance the testing after the first year. Weathersby estimates the volunteer man-hours surrounding this project to be "in the seven figures."

Both men acknowledge that the CMVP played a huge role in seeing OpenSSL's validation through to completion. "We really appreciate all the members of CMVP for addressing this in a heads-up manner," says Weathersby. Referring to their willingness to test source code instead of the usual binary code, Weathersby says, "They had to change things, but we all knew we were turning a battleship here."

Marquess agrees. "What they did was really quite gutsy," he says. "We were messing with some other vendors' rice bowl and they were probably pressured by others to see that this wasn't validated. Excuses were expected, but we never got any."

"This demonstrates how durable, flexible, and dynamic the open source model is," Weathersby says. "It also goes to show you can't keep a good idea down."

Share    Print    Comments   

Comments

on OpenSSL gets hard-fought revalidation

Note: Comments are owned by the poster. We are not responsible for their content.

How can they validate non-open source?

Posted by: Anonymous Coward on February 09, 2007 08:20 PM

This whole article baffles me. How can anyone certify software for which they do not see the source? Exhaustive testing of a package this size is not possible. You can't be sure you know everything it is designed to do unless you see source code.

#

Re:How can they validate non-open source?

Posted by: Anonymous Coward on February 09, 2007 08:30 PM
They do is the source code. It is part of the validation process of stuff like this. But there is no requirement to release it to anyone other than the validating team. And the validating team is not allowed to release it either.

#

Great ... but the apps needs to hooks

Posted by: Anonymous Coward on February 09, 2007 10:31 PM
That is a huge deal for the OpenSSL team and all involved, but I think for anything else to utilize the FIPS certification, the application(SSH) must have a call in it's source say something enable_fips_mode(), etc..

Now the communtity needs mod_ssl and openssh to inherit the FIPS methods.

Can this be done another way?

 

#

Re:Great ... but the apps needs to hooks

Posted by: Anonymous Coward on February 09, 2007 11:43 PM
it's in the works.
jmw

#

Great

Posted by: Anonymous Coward on February 09, 2007 11:52 PM
Great that OpenSSL got validated.<nobr> <wbr></nobr>:)

<a href="http://en.wikipedia.org/wiki/FIPS_140" title="wikipedia.org">http://en.wikipedia.org/wiki/FIPS_140</a wikipedia.org>

FIPS 140-3 is a new version of the standard which is currently under development.

#

Messy to non-existent docs

Posted by: Anonymous Coward on February 10, 2007 01:31 AM
Miraculous that the certification got done.

OpenSSL has the worst docs I've ever seen... not currently usable *unless you consult with others*... probably will inmprove when the new docs are finished.

This code almost made me give up on using open source (I was writing Apache modules).

No, I am not particularly dumb, I just like being able to leverage someone else's accomplishments without bothering half the universe to find sample code and usable docs.

BWilde

#

Cost

Posted by: Anonymous Coward on February 10, 2007 02:07 AM
What's the cost of this certification? Who paid? Just curious.

#

They see the source code

Posted by: Anonymous Coward on February 10, 2007 04:09 AM
Proprietary or Open, they see the source code and FIPS requires the submission of test suites, results and documentation.

#

Cryptographic Module Validation Program

Posted by: Anonymous Coward on February 10, 2007 05:36 AM
It is Cryptographic, not Computer.

Perhaps the entire open source community should begin sending complaints to the CMVP about commercial products being made by anti-capitalist facists or any such political crap that they want if the CMVP is going to allow such tripe to interfere with free and open competition. I wonder who can get more people willing to submit bogus complaints - a few commercial vendors losing money or the open source community not happy with a certification process that allows competitors to block certification. Talk about a lack of free market!

#

Re:Cryptographic Module Validation Program

Posted by: Anonymous Coward on February 10, 2007 03:43 PM
Good point - except that they don't need to be BOGUS complaints. There's plenty enough legitimate ones, and they've made it clear the process requires them all to be processed.

So what's the address to send complaints to the CMVP? And how do we find out which products to complain about?

#

Re:time to name names?

Posted by: Anonymous Coward on February 11, 2007 06:58 PM
While their tactics are almost certainly legal, they are absolutely unethical.

Please name the companies so that we'll know who we DON'T want to do business with.

#

time to name names?

Posted by: Administrator on February 10, 2007 02:17 AM
"The software vendors contacted for this article declined to comment."

Then show us who they are. Their comments are part of the public record. Let's hold them to account for their illegal tactics.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya