OpenSSL gets hard-fought revalidation

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.”