Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

OpenSSL Revalidated Following Suspension

Posted by Zonk on Fri Feb 09, 2007 11:25 AM
from the can't-keep-a-penguin-down dept.
Security Encryption
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.
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

OpenSSL Revalidated Following Suspension 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.
    • 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.

      • Re: (Score:2, Insightful)

        by stratjakt (596332)
        Sure you could, *if* you knew exactly what the insecurities were and worked around them.

      • Re: (Score:3, Interesting)

        by tomstdenis (446163)
        Given that I'm doing NIST certification right now, I can assure you it's meaningless. They basically throw a bunch of vectors at you, you reply, if you get it right they give you a cert # and list you on some website.

        The only reason ANYONE does this is so they can get on that website. Getting a compliant AES routine isn't hard. There are dozens of implementation under BSD, MIT, GPL, and various other FLOSS [including public domain]. That you picked an AESVS certified implementation doesn't mean you're ap
        • I wrote a valid implementation of SHA-1 and AES in JASS (scripting language of Warcraft III) just to see how poor the integer arithmatic was. It was poor. (I had to code my own bitwise functions too, which really hurt. None are standard!)
          • What?

            No, as in my company is doing the test so we can get a cert and listed on the perdy website. We've already done it for our hardware crypto, this time around it's the software crypto.

            I think you don't actually know what goes on in validation. Because if you had the slightest clue you'd just say "so what?"

            Tom
          • >It would just confirm my estimate of the IQ of the average civil-servant! (with apologies to all three of those civil servants out there with IQ's > 80)

            I believe you have "the average civil servant" confused with "the average civil servant's manager."
    • 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 . . .

      • Hi, I'm the author of the LibTom Projects. I know for a *fact* that they're used within the government (USA). None of my projects have 800 or 140 series validation.

        Thanks for playing the "OMG there is a diff between policy and reality" game. You lose.

        Tom
        • I know I'll sleep better if non-certified code such as you describe is agressively and immediately removed from government servers.

          Validation exists for a reason. If you feel the criteria are too lax, you should be lobbying to have them tightened, not proclaiming "oh, well. C'est la vie!".

          Then again, perhaps you have a vested interest in denigrating the validation process - by your own declaration, you have non-validated code ostensibly running where it shouldn't be? How much do you stand to lose here

          • My projects are public domain. I stand to lose nothing if they stopped using them.

            Note I should have been clearer. I said they use them, I didn't mean specifically they end up in actual fielded projects (because I don't know about the latter). But logically from the logs and support emails I get from various organizations they're at least using it for something. I do know that some folk at NIST used the projects testing CCM implementations. Heard that from former employees.

            Point is, non-validated code
          • 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 TER
            • How much security do you think your local municipalities roads department needs?

              If road departments are anything like they are in my city, the dates when a particular section of road is coned off for resurfacing seems to be on a level of "for eyes only".

              We never see the constructing crews arriving. My neighbour is convinced the road crews materialise out of a higher dimension or burrow out of the hole they are repairing in an explosion of dirt, traffic cones, workers huts and heavy duty industrial machiner
          • From the Too-much-information-for-those-who-do-not-wish-to - hear-it file:

            The DoD policy which requires the FIPS validation process for programs such as OpenSSL is the National Security Telecommunication and Information Systems Security Policy Number 11 (NSTISSP No. 11). Overview can be found here: http://www.enpointe.com/security/pdf/nstissp11_fac tsheet2.pdf [enpointe.com]

            In short, it states that for govt/DoD to purchase/acquire any Information Assurance (IA) or IA-enabled products, they must pass through the a
          • If the article is accurate then this process seems to be political in nature and not security oriented. What would it matter if a commie wrote it if it was secure? If the software needs to pass certification by answering questions like "Does the programmers mother wears army boots?" or "What are your political beliefs?" then the process is more of a scam to keep the "IN FOLK" in and all others out. It is very easy to throw out allegations when you can hide behind a veil of secrecy. I would not sleep any be

        • Re: (Score:2, Insightful)

          by stratjakt (596332)
          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
      • Validation for anything is a lot like the political process in general: intended to be painfully slow. Political candidates are vetted thoroughly beforehand because no one likes to be surprised (imagine if Howard Dean's outburst had happened right as he was about to be sworn in). Legislation is debated until the problem they are trying to address no longer requires government intervention. No one wants to take a stand only to be embarassed later.

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      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.

    • What good would it do you if the AES implementation was just *wrong*? Or if the crypto library processes the key in unprotected memory?

      That's what validation gets you.

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

    by lisah (987921) on Friday February 09 2007, @11:36AM (#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.

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

      by lymond01 (314120) on Friday February 09 2007, @11:40AM (#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...

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

      by stratjakt (596332) on Friday February 09 2007, @11:56AM (#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.
      • This public scrutiny is a method that crypto algorithms must go through to gain any value in the public. I'm sure everyone reading this thread can recall the lame DVD CSS once called "encryption". The MPAA tried to maintain security of this "encryption" by keeping its methods in their secret vault but that didn't do them much good. Having the public attempt to poke holes in a technology claimed to be secure is the only way to prove it is. I salute those who worked so hard to validate OpenSSL. Now IT fo

  • Huh? (Score:5, Insightful)

    by teridon (139550) on Friday February 09 2007, @11:57AM (#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?

    • I don't know all the ins-and-outs of the process, but it's my understanding, based on the level of certification and any issues that may arise during certification, a source code review is necessary to clarify concerns and issues.
    • 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

      • 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

        They may be comfortable using it, but if they were a government agency with a requirement to use validated code it doesn't look like they could use a "uniquely configured version".

        Taken from the CMVP validation list on the CMVP website.

        (When built, installed, protected and initialized as specified in the provid

    • Some level of source code review is required in all FIPS levels for all validations.
      • That's true - but it's mostly to prove that the finite state diagram properly describes the module operation and that the key initialization, known answer tests and zeroization are properly implemented. It's not a complete source code review. Lastly, only the certifying lab (not NIST) checks the code.

    • Re: (Score:3, Insightful)

      by Panaflex (13191) *
      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 whol

  • m$^8 (Score:1, Interesting)

    by Anonymous Coward
    Was this also sponsored by microsoft or was it some other biggie this time?

    Oh wait, there are no other hostile biggies.

  • Misconceptions in the write-up (Score:5, Informative)

    by Cerebus (10185) on Friday February 09 2007, @12:15PM (#17950204) Homepage
    1. FIPS 140 validations taking a long time is not unusual.

    2. OpenSSL was validated as *source*. All other FIPS 140 validations are of *object code* or devices. This is the first cryptomodule to be validated in source form and contributed to the time taken to validate.

    3. The OpenSSL original cert was suspended because there was a small bit crypto code that resided outside the security boundary. Confusion between sponsor, lab, and NIST contributed to the suspension. See #2.

    4. Claims of vendor FUD are overblown. NSS, another Open Source cryptomodule, already has FIPS 140-1 certification (for version 3.6; 3.11 will be entering FIPS 140-2 eval soon).

    • 2. OpenSSL was validated as *source*. All other FIPS 140 validations are of *object code* or devices. This is the first cryptomodule to be validated in source form and contributed to the time taken to validate.

      This is very misleading. The OpenSSL code was submitted as source, but the lab still evaluated it as a binary blob (after compiling/installing it using the instructions provided). The lab did not evaluate the source anymore than they did for NSS or the MS crypt libs. etc.

  • who were behind the complaints .. (Score:5, Informative)

    by rs232 (849320) on Friday February 09 2007, @12:16PM (#17950236)
    "We called it the FUD campaign," he says. "There were all kinds of complaints sent to the CMVP including one about 'Commie code.'"

    '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 [linux.com] were lodging the complaints'
  • This is an excellent example of how large and deep the cesspool is in government contracting.

    The competitors intentionally draw out the certification process for the newcomer to literally exhauste them and drive the competition away. This is just one relatively small library/suite of applications. (albeit critical)

    For any of you entrepreneurial developers thinking they're onto the the next great thing that gov'ts will buy, please consider this story carefully. A long career at the top of an agency you wis
    • I can assure you that the certification process was not created by the companies that are having their products validated. I think that validating OpenSSL presented a unique problem as the writers of the standard did not foresee a source only module.
  • If OpenSSL is validated in both binary and source form while proprietary implementations of SSL are only validated as binaries, one could reasonably conclude that proprietary versions are not really fully validated.

    Certainly once validity of visible source code is established it should be possible to relatively easily continue to demonstrate validity of that code. Meanwhile in the case of proprietary versions it is possible to make source changes that change the behavior of binary product in ways difficult
  • Disclaimer, I work for Red Hat so I am very familiar with competitors efforts to spread FUD about open source software but I don't believe any nefarious activities were at work here. The NSS Project [mozilla.org] is an open source SSL toolkit that received FIPS140 certification in 2002. Five years ago! The opensource Crypto++ project was certifed in 2003.

    So if (as the sensationalist headline proclaims) "the idea of an open source SSL toolkit didn't sit right with proprietary vendors of similar products." They've had 5 y

    • Re: (Score:1)

      by Anonymous Coward
      So a complaint about "commie code" being present in the source isn't FUD in you opinion? You're a lot more tolerant of that crap than I would be.

  • It was not a cheap process either... (Score:4, Informative)

    by wherrera (235520) on Friday February 09 2007, @01:58PM (#17951908)
    It seems to have cost over US$ 120,000 (by 2006) to certify, not including volunteer hours:

    http://groups.google.com/group/mailing.openssl.use rs/browse_frm/thread/7aa07e7a6ba9bbe8/d3c4113f0a49 998a?lnk=st&q=cost+FIPS+certification&rnum=3&hl=en #d3c4113f0a49998a [google.com]
  • Operating System likes to implement their open message digest command ( if they provide one at all ). If your system is missing a digest command, you can use the openssl utility to generate one-time hashes. OpenSSL supports the SHA1, MD5 and RIPEMD160 algorithms, and accepts one or more files as arguments

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.