Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security Encryption

OpenSSL Revalidated Following Suspension 51

lisah writes "Despite what looks like an organized effort to prevent it, OpenSSL has been revalidated by an independent testing agency for its ability to securely manage sensitive data and is ready for use by governmental agencies like the Department of Defense. According to the Open Source Software Institute, who has been overseeing the validation process for the last five years (something that typically only takes a few months), it seems that the idea of an open source SSL toolkit didn't sit right with proprietary vendors of similar products. A FUD campaign was launched against OpenSSL that resulted in a temporary suspension of its validation. Developers and volunteers refused to give up the ghost until the validation was reinstated, and Linux.com has the story of the project's long road to success." Linux.com and Slashdot are both owned by OSTG.
This discussion has been archived. No new comments can be posted.

OpenSSL Revalidated Following Suspension

Comments Filter:
  • by damiangerous ( 218679 ) <1ndt7174ekq80001@sneakemail.com> on Friday February 09, 2007 @12:32PM (#17949478)
    How does that make validation meaningless? That you can write an insecure app no matter the toolkit is irrelevant. What's relevant is that cannot write a secure app with an insecure toolkit.
  • by stratjakt ( 596332 ) on Friday February 09, 2007 @12:35PM (#17949550) Journal
    Sure you could, *if* you knew exactly what the insecurities were and worked around them.
  • by mmell ( 832646 ) on Friday February 09, 2007 @12:35PM (#17949552)
    Non-validated tools are worthless. The likelihood of their being used as tools by any branch of the government (including the banks) is virtually nil today. D'you really think business will follow where the government/banking industry won't go, or end users (with no business or government end-points to connect to)?

    And of course, any moron can "write an insecure application" using any tools. Writing a secure application, OTOH . . .

  • Not necessarily... (Score:5, Insightful)

    by lisah ( 987921 ) on Friday February 09, 2007 @12:36PM (#17949562)
    Well, it's not necessarily "meaningless." It would be great to see more governmental agencies choosing open source options but, from what I understand, when it comes to managing sensitive data, only software that is tested and proven to be reliable and secure can be used -- hence OpenSSL's validation process. Sure, it's important to use the tools wisely but, without the FIPS validation, this open source tool can't be used by the government in the first place.
  • by lymond01 ( 314120 ) on Friday February 09, 2007 @12:40PM (#17949632)
    I believe he means it's technically meaningless while others are arguing that it's beaurocratically important. The specs for validation aren't so difficult to meet, but if you don't go through the process, no one wants to use your software.

    Like us: if you don't have that MCSE on your resumé, we don't want you.

    Oh, wait. Yes we do...
  • by stratjakt ( 596332 ) on Friday February 09, 2007 @12:52PM (#17949810) Journal
    It's all going to depend on the project, and the level of security required, who it's for.

    We sell to municipal, state, and federal levels of government, and have worked with a lot of different agencies, and the requirements are different every time. A city servant who needs a database to keep track of the flow rates of fire hydrants has different security concerns from a federal agent investigating a military colonel for embezzlement, or whatever.

    Technically, the policy says OS's have to be POSIX compliant. The reality is, you still stumble across a windows 3.1 box chugging on some home-spun app sitting in the basement.
  • by Anonymous Coward on Friday February 09, 2007 @12:55PM (#17949878)

    Validation is meaningless.

    Is the government allowed to use OpenSSL if it is not validated?

    If not, then I don't think the word "meaningless" means what you think it means.

  • Re:zzzz..... (Score:4, Insightful)

    by stratjakt ( 596332 ) on Friday February 09, 2007 @12:56PM (#17949896) Journal
    No, but like they say in the article, it delayed their validation, because it's easier to criticize something open source, you can pull open the code and point at something and say "see see". The OpenSSL team cant make the same accusations against a closed source product, because the code isnt available - trade secret.

    Validation is somewhat less meaningful for OSS because of this - anyone (assuming the proper skill level) could look at the code, and see for themselves if the criticisms have any merit. With a closed solution, all you have to go on is the validation - that stamp of approval.

    You are correct though, this isnt that big a deal, it's just about OSS so it's /. news.
  • Huh? (Score:5, Insightful)

    by teridon ( 139550 ) on Friday February 09, 2007 @12:57PM (#17949918) Homepage
    FTA:
    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

    Someone please explain to me why binaries aren't good enough for the first review, then later they are? Who says the new source code is "secure"?

    Why didn't they require source code review for vendor products?

  • by stratjakt ( 596332 ) on Friday February 09, 2007 @01:03PM (#17950004) Journal
    Not every goverment application requires the same level of validation or security. Not everything they do is secret - in fact, most of what they do is not secret.

    How much security do you think your local municipalities roads department needs? I'm sure they keep track of what roads got plowed, and salted, and when. I wouldnt think that would be something they need under fort knox level security.

    You can reply with "what if a hacker said dont plow this road then it got real icy and a car crashed and the TERRORISTS WIN", but the fact is, they would hardly give any thought to that scenario, they would have no problem sending updates to the database in cleartext over a wifi link secured with nothing more than WEP. In fact, the key is probably something like 1A2B3C4D5E. The database would exist as a work log - people still do their jobs in the real world.

    Hell, maybe some guy wrote that little database 10 years ago, and its still running on a windows 3.1 box in a back room. I saw a dos terminal in the post office, I see ancient hardware still performing its duties every day.
  • Re:Huh? (Score:3, Insightful)

    by Iphtashu Fitz ( 263795 ) on Friday February 09, 2007 @01:33PM (#17950536)
    Someone please explain to me why binaries aren't good enough for the first review, then later they are? Who says the new source code is "secure"?

    I don't think it's a matter of one being better than the other. Certification of one thing doesn't mean related items are also certified. Just because the source code is now certified doesn't mean that all the libraries that can potentially be built by that source code are now automatically certified as well. (If B derives from A, and A is certified, it doesn't automatically mean that B is certified as well.)

    The article did a fairly good job of explaining why they certified the source. Since there are so many options for including/exluding various components within OpenSSL it'd be difficult to build, maintain, and certify dozens of potential variations of the same version of the library. Not to mention how you keep users from getting confused by all those potential variations.

    Having the source certified means that people/organizations that want to build from those sources can have a binary that meets those certification requirements as long as all the other components (any other libraries or other requirements needed to build it) are similarly certified. It also means that if an organization has some requirement for a rather uniquely configured version of OpenSSL that they can build it themselves from certified sources and be comfortable with using it. By also getting certification of various binaries they're ensuring that people who don't need/want to rely on building from source can also have a fully tested & certified solution. Chances are they won't build/certify every possible combination of OpenSSL. It's more likely that they'll build one version with all options (at least as far as legal restrictions go), one with the most common options, one with minimal options, etc. and get those few variations certified individually.
  • Re:Huh? (Score:3, Insightful)

    by Panaflex ( 13191 ) * <{moc.oohay} {ta} {ognidlaivivnoc}> on Friday February 09, 2007 @06:27PM (#17955712)
    FIPS 140-2 (and moreso -1) were designed for certifying what is commonly known as "black-box" hardware encryption modules. Some given assumptions on the security model include:
    1. Physical security of the boxes
    2. Prevention of attacks
    3. Disclosure of usage, known-good protocols & keys (A Security policy)
    4. Testing of (P)RNG's.
    5. Known Answer tests of FIPS approved algorithms (AES, DES, etc...)

    The movement towards software-only modules has brought a whole series of issues to head - meaning that some whole sections of the fips validation aren't even valid.

    Also - there are (at most)4 levels for certain security aspects which validate - or at least disclose the robustness of the implementation being tested.

    Now you can see why it was not originaly planned to have any validation on the security of the codebase (at least for overall level 1). OpenSSL pushed the envelope of what certification means FAR beyond it's original intention.

"The four building blocks of the universe are fire, water, gravel and vinyl." -- Dave Barry

Working...