×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

102 comments

I'm guessing (5, Funny)

PunkOfLinux (870955) | more than 7 years ago | (#15743266)

I'm guessing that this certification is necessary if you want your product to be used in the federal government, right???

Re:I'm guessing (2, Insightful)

Ana10g (966013) | more than 7 years ago | (#15743506)

That, and a myriad of other certifications... I think they make up certifications so that politics can decide what software can be used where... "Your application doesn't meet certification 'X', sorry, we're going to use your competitor's product, (who, btw, funded the creation of the certification)."
I of course, can't really back that up, but that's what it seems like to me.

Re:I'm guessing (0)

Anonymous Coward | more than 7 years ago | (#15744167)

"Your application doesn't meet certification 'X', sorry, we're going to use your competitor's product, (who, btw, funded the creation of the certification)."

(and who, btw, gave me lots of money)

Re:I'm guessing (2, Informative)

glitch23 (557124) | more than 6 years ago | (#15746816)

I know you were being sarcastic but I'll bite. The answer is yes at least for certain U.S. gov't departments. I work on a U.S. gov't contract and when implementing a custom application that was ported to Java we had to abide by security requirements as part of our overall project requirements. One of those requirements was that no passwords shall be sent in the clear but the kicker was that we had to use something that was FIPS compliant and certified. I was told the mere use of certified algorithms wasn't enough but that meant we had to buy something because rolling our own implementation of the algorithms would require certification and we didn't have time or the money for that.

In the end it was sufficient to roll our own and write up what was done until a long term solution was developed. It was a pain in the ass because of the products that are FIPS compliant, a lot of them are hardware solutions and some of the others weren't even available for use outside of the company who developed them. An example of that was a library that I believe IBM made. I contacted the people listed on the FIPS site for that item and I was told that the library was for internal use only. A lot of good it does for it to be listed on the FIPS site. We also needed a Java implementation which made it even more difficult because the FIPS 140-2 list just isn't that long which lowers the chances of finding just what you need. YMMV

Stupid Politics (3, Interesting)

neonprimetime (528653) | more than 7 years ago | (#15743271)

"I am discouraged with what appears to be another change after certification has been awarded," said executive director John Weathersby. "It is disheartening after three-and-a-half years of work to have the certification pulled twice for reasons not clear to us."
... NIST is not saying why the certificate was removed.


Stupid politics.

Re:Stupid Politics (0)

Anonymous Coward | more than 7 years ago | (#15743304)

Something to do with OpenTheo, no doubt.

Re:Stupid Politics (1)

AndroSyn (89960) | more than 7 years ago | (#15743841)

What the fuck does Theo have to do with it? A lot of people seem to be under the false impression that OpenSSL has something to do with the OpenBSD project. It doesn't...

Re:Stupid Politics (3, Interesting)

andrewman327 (635952) | more than 7 years ago | (#15743318)

Punishing a company and not explaining why? That is just bad business. I imagine it could have to do with national security concerns, but if that were the case, why would they have awarded cert in the first place? Something really does not add up here.

Re:Stupid Politics (1)

markjo (977895) | more than 7 years ago | (#15743608)

I'm guessing that the company will get an explination as to why it's cert gets pulled, but that doesn't mean that the rest of the world needs to know.

Re:Stupid Politics (3, Insightful)

hey! (33014) | more than 7 years ago | (#15743613)

Well, certification should not be viewed as reward, and removing certification should not be a punishment.

It should have nothing to do with the recipient of the certification; it should be based on whether the product meets certain well established and reasonable criteria, given the best information at the time.

Furthermore, it makes sense not to tell the world exactly what the vulnerability you found which caused the product to be decertified, until your agencies can stop using it, which is not overnight.

However.

What doesn't make sense is concealing this from the organization that obtained the certification to begin with, and presumably could save the Federal government much cost and inconvenience by addressing the problem. IN fact, it's terrible.

How can we know this wasn't done as favor to a political contributor?

We can't.

Even before 9/11, the stance of this administration has been that explaining its reasons for doing things -- only in certain situations mind you -- unduly hampered it's ability to get frank and unvarnished advice from industry. Leaving aside that no presidency in living memory ever felt this to be a problem, we have to decide. We either can know that our officials aren't taking payoffs, OR we deprive those officials of advice whose nature is such that if we knew what it was there would be a public scandal.

If that last sentence seems hard to parse, it's because it doesn't make any sense. The underlying premise is absurd: that public officials need to be able to do shameful things.

Re:Stupid Politics (1)

andrewman327 (635952) | more than 7 years ago | (#15743683)

Government has always been able to lie about its reasons for doing things to avoid scandel. If they were simply aiding a benefactor, they would say something vague like "substanciated security concerns" and leave it at that. In my experience in DC, lots of money only gets you part of the way there. Especially when it comes to national security, you need to be able to prove that your product works.

Re:Stupid Politics (1)

hey! (33014) | more than 7 years ago | (#15744132)

Government has always been able to lie about its reasons for doing things to avoid scandel. If they were simply aiding a benefactor, they would say something vague like "substanciated security concerns" and leave it at that.

Yes, of course it always could lie. But you risk getting caught. The actual process of "substantiating security concerns" would leave a paper trail.

Especially when it comes to national security, you need to be able to prove that your product works.

Logically, if by "works" you mean "contains no security defects", what you are asking is impossible. You can prove non-existence. Which means all products need to be assumed to have undiscovered defects. All products.

What you can do is say that your product has been through a particular process which has been shown to uncover a number of typical defects. That process needs to be open. It isn't the case that secrecy never helps security; sometimes obscurity is the best we have. But in cases like this, secrecy actually undermines security, because it allows flawed processes to continue uncorrected.

Re:Stupid Politics (1)

LurkerXXX (667952) | more than 7 years ago | (#15744079)

While I agree with all the rest of your post, I disagree with this bit:

What doesn't make sense is concealing this from the organization that obtained the certification to begin with, and presumably could save the Federal government much cost and inconvenience by addressing the problem. IN fact, it's terrible.

It makes sense to conceal it from the organization... temporarily. Until you get your machines switched over to some other secure system if you found a major security hole in theirs.

Although the protocol was certified, that doesn't mean that every person in the organization which made it has passed a 'top-secret' or whatever level background check, or sworn an oath about keeping the new hole secret from spouses, friends, colleagues, etc. They might fear someone 'bad' in the organization, or who knows someone in it, will find out about the hole before their machines are secured. I think that as long as they inform the organization within a reasonable timeframe (how long should it take to switch all their machines to a new system? A couple weeks?), that temporarily withholding the information from the organization might be prudent.

Of course, with the track record of the current administration, I'm skeptical that they will actually 'do-the-right-thing' in the end.

Re:Stupid Politics (1)

hey! (33014) | more than 7 years ago | (#15744189)

It makes sense to conceal it from the organization... temporarily. Until you get your machines switched over to some other secure system if you found a major security hole in theirs.

I think you make a good point here. However, it's not clear that there is a plan for switching the machines over. The process is opaque, in a way that I think does not really do much for security.

Although the protocol was certified, that doesn't mean that every person in the organization which made it has passed a 'top-secret' or whatever level background check, or sworn an oath about keeping the new hole secret from spouses, friends, colleagues, etc. They might fear someone 'bad' in the organization, or who knows someone in it, will find out about the hole before their machines are secured. I think that as long as they inform the organization within a reasonable timeframe (how long should it take to switch all their machines to a new system? A couple weeks?), that temporarily withholding the information from the organization might be prudent.

If what you are saying is the motivating factor, then it seems to me the sensible response -- open source or proprietary -- is that vendors wishing to certify a product must employ engineers with an appropriate security clearance. That would be a fair and reasonable rule. The engineers would handle any security issues that came up. This would apply not just after certification, but during the certification process itself, which is bound to yield information useful to a black hat.

Re:Stupid Politics (1)

macdaddy (38372) | more than 7 years ago | (#15745376)

This train of thought doesn't get you out of the gates though. If Uncle Sam had to secretly spend millions of $$ to make changes due to a security problem or other major issue then none of the tech they used would have ever gotten off the ground. For example, McDonald Douglas's and Boeing's planes have been fraught with problems, many of which were serious security problems (Google for more info). Not all of these problems were found in the testing phases either. Uncle Sam still brought in the developers to try and resolve the problems instead of scrapping the project and switching to another manufacturer. Serious security problems are found in Windows every day. I'm sure some of them were discovered by Uncle Sam. I'm sure Uncle Sam shared the discovery with Microsoft so that they could fix the problem. Uncle Sam didn't keep it a secret while switching to Macs to preserve their national security.

When it comes right down to it there is absolutely no reason why the missing details couldn't have been shared with the OpenSSL people. Getting FIPS 140-2 requires some significant background checks as it is. If Uncle Sam was really worried they could have approached OpenSSL and said "we've found a major problem. We'd like to fix it with you. Before we do we need you and any other person that may be required to work on this problem or know about this problem to submit to a stringent background check prior to us divulging the nature of this security issue.". I'm sure the OSSL would have been glad to have that level of interaction with such an important client.

Re:Stupid Politics (0)

Anonymous Coward | more than 7 years ago | (#15744067)

I have a feeling that somehow, in some way, the issues have been relayed to someone working on OpenVPN, such that the project can choose to do something about it if they like, which no doubt they will do.

Re:Stupid Politics (1)

Schraegstrichpunkt (931443) | more than 7 years ago | (#15745985)

RTFA. Their policy is not to tell the public the details of the problem because the information might be "proprietary" (Hah!). Somebody associated with OpenSSL will be told.

Biased Reporting (1)

RingDev (879105) | more than 7 years ago | (#15743469)

There was a concern that was raised back in June. Since then, the code has been updated and procedure has been modified. If the reason for the initial "pull" was not clear, how did the know what requirements to change the functionality for?

I haven't followed along with this project, but it doesn't sound that bad. There was a technical issue, they lost their cert. They fixed the technical issue and resubmitted. Screwiness ensues as their cert disappears, then reappears as suspended (which it already had been).

Could the certing authority be rejecting them after a payoff from big corps? Maybe. Could a summer intern have accidentally hit the wrong button and wiped out the cert, then later recovered from back up? Maybe. In the end, it's just speculation until the authority makes a statement clarifying the situation.

-Rick

OpenSSL is good software (1)

Seriously, who (969215) | more than 7 years ago | (#15743286)

Seriously, who can name a more secure SSL implementation than OpenSSL? This is pretty ridiculous.

Re:OpenSSL is good software (0)

Anonymous Coward | more than 7 years ago | (#15743341)

Welcome to the government. Tons and tons of documentation and requirements, not on how to make the best product, but to make the exact same product as everyone else. It's the same for all of their computer certifications. They don't care whether there's 0 or a million holes in a piece of software, if you developed it "wrong" you don't get EAL or any other certification.

Re:OpenSSL is good software (0)

Anonymous Coward | more than 7 years ago | (#15743603)

who can name a more secure SSL implementation than OpenSSL?

You're kidding, right? Am I the only person who remembers the half-dozen vulnerabilities a couple of years ago? Was I the only one who cursed OpenSSL under their breath as they updated a dozen machines for the third time in a single month?

OpenSSL has the *worst* security track record of any SSL implementation I know of.

Re:OpenSSL is good software (0)

Anonymous Coward | more than 7 years ago | (#15743885)

The problem is, you are probably one of the few that ever used anythings else here...
The problem is, you are right, and most people here are wrong. Most people here don't understand how these certifications work, and think the competiion is not being scrutenized.

so, tell us then (0)

Anonymous Coward | more than 7 years ago | (#15744383)

if you know the magic secrets to getting gov certs, this is a discussion forum, make with the real explanations. If most of us "don't know", then add some enlightenment, and use a name, hey, you might get a +5 informative out of it if you care for the karma and for letting people get to the good stuff easier.

Re:so, tell us then (0)

Anonymous Coward | more than 7 years ago | (#15744722)

What does any of that have to do with OpenSSL's horrible security record?

Re:so, tell us then (0)

Anonymous Coward | more than 7 years ago | (#15744974)

Does scoring +5 on some forum really give me an incentive...

Nah don't think so...

That would mean I'm in the same league wih mos posts ha get a +5 here...

Re:OpenSSL is good software (0)

Anonymous Coward | more than 7 years ago | (#15743910)

Could that be because OpenSSL is open source and has lots of eyes looking over the code?

How many vulnerabilities exist in closed source implementations that are waiting to be exploited by some black hat? Especially if only he knows about it, then everyone thinks that the software must be secure when it isn't.

Re:OpenSSL is good software (0)

Anonymous Coward | more than 7 years ago | (#15744707)

Could that be because OpenSSL is open source

Which would matter if it was the only open-source implementation. Other Open-source SSL implementations (such as GNU/TLS, or the one in Pike) don't have near as many security flaws as OpenSSL.

It's not an open-source/closed-source problem, it's an OpenSSL problem.

Take a look at the code. It's a horrible mess.

Weasel words (3, Funny)

sharkey (16670) | more than 7 years ago | (#15743303)

On July 14 the CMVP Web site listed the OpenSSL certificate 642 as revoked. On Monday it was listed as not available. A statement from CMVP supervisor Randy Easter indicated there is no distinction between the two terms.

Then what honest reason is there for HAVING different terms?

Re:Weasel words (2, Insightful)

Southpaw018 (793465) | more than 7 years ago | (#15743433)

It's the government. There is, unfortunately, no reason needed. Bureaucracy is part of the equation.

Re:Weasel words (0)

Anonymous Coward | more than 7 years ago | (#15743525)

Better than using one term to refer to multiple, distinctly different meanings.

I once got a health care notice saying that my 'insurance has not responded' to a bill, and that I was going to have to foot it myself. I had given them my insurance info, so I assumed that they had actually used that info to submit a payment request. In the end, I found out that 'insurance not responded' was a shared code, and was also used for 'we lost or never had your insurance info, let alone tried to submit a request'. I tried to explain that if they added a code which said 'no insurance information' it would have saved both of us a lot of wasted time. The woman just didn't get why there was any confusion on my part.

I thought all would be well after I gave her my info, but she promptly submitted a random policy number to some other insurance company.
-J

Re:Weasel words (0)

Anonymous Coward | more than 7 years ago | (#15744142)

Huh.

I had a hospital send me something like that once. I guess if I'd known the code, I might have talked to them again.

As it was, I "didn't respond to" their request that I pay the whole thing. They should have used a different code.

And it's now been over 6 years, past the deadline for them to sue me in this state. They're stuck with eating the cost.

Reasons Not Given? (5, Insightful)

mr_rattles (303158) | more than 7 years ago | (#15743308)

"The CMVP does not provide information regarding the status or reason as in many cases it may be proprietary"

This is one of the most ridiculous statements I've ever read. How is the problem supposed to be fixed if the vendor is never told what the problem is, and so what if it's proprietary? When I read a statement like this it suggests to me that there's doesn't have to be a method behind how they determine what's rejected and what's not, the person(s) deciding could have simply had a proprietary "I'm in a bad mood today and want to take it out on someone" reason.

Re:Reasons Not Given? (1)

GreyPoopon (411036) | more than 7 years ago | (#15743380)

the person(s) deciding could have simply had a proprietary "I'm in a bad mood today and want to take it out on someone" reason.
Or maybe the person had a proprietary receipt of goods or money from other entities that might or might not have competing products....

Re:Reasons Not Given? (2, Informative)

Anonymous Coward | more than 7 years ago | (#15743419)

They were refering to publicly providing the info. They do provide it to the vendor/developer of the product.
They would not tell the person researching/writing the article why it was revoked.

Re:Reasons Not Given? (4, Interesting)

smooth wombat (796938) | more than 7 years ago | (#15743459)

Normal operating procedure. Years ago, when I applied for a position with an unnamed 3-letter agency, I gave them several, double-sided, sheets of information going back ten years. Went through the whole process of urine testing, blood analysis, polygraph (twice), and psychological evaluation (bubble test and actual person). After all was said and done I received notice that I would not proceed to the next stage.

I wrote a letter requesting the specific reason for this and was told that that information was proprietary and might disclose operational procedures.

So let's review. I give them almost 20 pages of documentation, agree that they can ask questions about me from family members, relatives,neighbors, etc., agree to let them do a credit check on me and contact other law enforcement agencies to see if I have a record, answer an entire booklet of psychological questions, undergo two polygraph tests, a blood test and urinalysis and they won't tell me how they came to their decistion because in doing so it might reveal how they gather the information.

Um, yeah.

Re:Reasons Not Given? (3, Funny)

Anonymous Coward | more than 7 years ago | (#15743562)



Dear Smooth Wombat,
You had heroin in your system and traces of anally absorbed KY Jelly.

Regards,
Three Letter Agency

Re:Reasons Not Given? (4, Funny)

ChrisDolan (24101) | more than 7 years ago | (#15743724)

TLA Psych Report for: [Smooth Wombat]
Recommendation: REJECT
Reason:
  Psych models predict subject shows high likelihood
  of revealing operational procedures to Slashdot

Re:Reasons Not Given? (0)

Anonymous Coward | more than 7 years ago | (#15743758)

They simply checked your slashdot profile.

Re:Reasons Not Given? (2, Insightful)

Ginger Unicorn (952287) | more than 7 years ago | (#15744161)

i think it's probably that they dont want to give away their analytical procedures, rather than their information gathering procedure, which as you point out you already knew, having gone through it.

think about it, if they told you why they rejected you, you could tell someone else what to do in order to pass that part of the test, thus jeopardising the validity of future tests.

Re:Reasons Not Given? (0)

Anonymous Coward | more than 7 years ago | (#15744563)

It doesn't say much about the test if you can fool the test that easily.

Re:Reasons Not Given? (0)

Anonymous Coward | more than 7 years ago | (#15747460)

is that really so easy if you never find out what is the test?

Re:Reasons Not Given? (0)

Anonymous Coward | more than 7 years ago | (#15747487)

you also never find out who knows what is the test
or for how long they know
or for what purposes they act on such

Re:Reasons Not Given? (1)

pla (258480) | more than 7 years ago | (#15744868)

thus jeopardising the validity of future tests.

Yeah, because polygraphs have such a great reputation for validity, right?

You can learn to make them show whatever answer you want, and they can return false positives on people not lying. When you can't trust the answer in either direction, it doesn't say much for the test.

The courts don't accept polygraphs as evidence for a reason. It doesn't exactly give me the warm-n'-fuzzies that the so-called "intelligence" community doesn't have the same level of sensibility.

Hell, why not just use an e-meter? They'd get just as meaningful of a result, and could at least give applicants the cop-out that their Thetan level disqualified them.

Re:Reasons Not Given? (1)

Zeinfeld (263942) | more than 7 years ago | (#15745254)

Hell, why not just use an e-meter? They'd get just as meaningful of a result, and could at least give applicants the cop-out that their Thetan level disqualified them.

Because the Scientologists would charge more than the poligraphers?

My understanding of the FIPS140 program is that they are required to give reasons for rejection. It is ten years since I did one but that was the case then.

There is a difference though between providing an instant reply in email and spending a couple of months crafting a fully documented explanation that states exactly why the module is not in conformance and the full set of steps required to bring it into conformance.

FOIA discovery is fully applicable to NIST so its not like they can hide the reason.

Re:Reasons Not Given? (1)

Ginger Unicorn (952287) | more than 7 years ago | (#15748564)

i wasnt really thinking of the polygraph test, more like them giving away the correct answers to some questions by telling you which ones you got wrong.

perhaps the testers just took the polygraph readings with a grain of salt; perhaps they used them purely to measure stress rather than to detect lies; perhaps they used the polygraph readings in conjunction with other lie detection measures such as body language and voice stress. the thing is they arent going to tell you what happened one way or the other, because that would release information that needs to be kept secret otherwise people can use it to try and cheat the testing procedure.

Re:Reasons Not Given? (0)

Anonymous Coward | more than 7 years ago | (#15744303)

Was it CTU? I hear the guy who runs that is a real asshole.

good possibility here (0)

Anonymous Coward | more than 7 years ago | (#15744451)

If it was any agency where you might have a badge and a gun (overt or covert) and might be working "out of the office", most likely it was because your IQ tests were *too high* and your psych eval showed that you might question orders occassionally.

And no, I am not joking at all.

Re:Reasons Not Given? (1)

ediron2 (246908) | more than 7 years ago | (#15747891)

I've worked with the 3LA crowd a fair amount, and I have yet to meet one that wasn't a bit mental. Half of them have a creepy elevated-charisma thing going. The other half? Well, to be blunt, they almost *always* leave me the impression of that wierd guy arguing with his elbow and asking you to pick sides while you're waiting in queue.

And then there's the oppenheimer moments: Doin' cool stuff that is given a usage scenario that seems noble/harmless enough, but losing sleep as you consider all the ways your work could be abused.

So, I guess I'm saying 1: don't take it personally, and 2: count your blessings.

Reasons were given, but not to the public. (1)

mephistus (217351) | more than 7 years ago | (#15745912)

No, the CMVP does not provide the information regarding the status or reason on the website that lists all the approved modules. It does however inform the certification lab that performs the testing on the module of the problem, and then the lab informs the OpenSSL folks. Then the vendor and lab work together to fix whatever it is that brought up the problem.
I don't know what the specific problem is with their module validation, but it's probably more of a paperwork issue than a technical problem. There are testing requirements that are described in the publically available Derived Test Requirements at http://csrc.nist.gov/cryptval/ [nist.gov] as well as more information than you'll ever want to know about the FIPS 140-2 cert.

Each crypto module has a publically available Security Policy that describes how the module works in regards to each section of the FIPS 140-2 standard. Skim through http://csrc.nist.gov/cryptval/140-1/140sp/140sp642 .pdf [nist.gov] to read the Security Policy for OpenSSL. It could be that information in that security policy doesn't jive with how the module actually works, or how CMVP thinks that it works. That's enough of a discrepency that CMVP would start this whole hub-bub.

So hopefully the OpenSSL people will be able to provide whatever other information that they have to and they'll be revalidated and all the noise will die down. Could the competition have gone through the source code and looked for any possible reason to make problems for the OSS institute? Absolutely. But that's not the guhb'ment.

But hey, it's a lot more fun to put on the tinfoil hats and speak of dark conspiracies and governmental corruption. :)

Re:Reasons Not Given? (1)

99BottlesOfBeerInMyF (813746) | more than 7 years ago | (#15746104)

This is one of the most ridiculous statements I've ever read. How is the problem supposed to be fixed if the vendor is never told what the problem is, and so what if it's proprietary?

I believe the answer is, you hire a consulting group who just happens to be buddies with the department in question. After paying them a pile of money, they get whatever agency to "certify" your software in some ridiculous and meaningless way. It is just the normal price of doing business in the sector.

One piece of software can be an industry standard, open source, heavily reviewed, and nearly bulletproof. The other can be closed source, complete crap who outsourced everything to unnamed parties in China. If the company that sells the latter pays the right consulting group their product will be "certified" even if the testing only proves that it exists, not that it works or is secure, and proves they have the right documentation written in the right style. This latter software may be the only option for a government agency to use due to policies that require certification. It is dumb, but that is what happens in bureaucracies.

Re:Reasons Not Given? (0)

Anonymous Coward | more than 6 years ago | (#15746584)

"The CMVP does not provide information regarding the status or reason as in many cases it may be proprietary"

This is one of the most ridiculous statements I've ever read. How is the problem supposed to be fixed if the vendor is never told what the problem is, and so what if it's proprietary? When I read a statement like this it suggests to me that there's doesn't have to be a method behind how they determine what's rejected and what's not, the person(s) deciding could have simply had a proprietary "I'm in a bad mood today and want to take it out on someone" reason.
As other people have pointed out the CMVP doesn't publicly disclose problems. (And while OpenSSL wouldn't have anything proprietary due to their open source nature, CMVP is a government program; they couldn't just change the rules that were set up for commercial product just because it seemed unnecessary in this instance. Even if they could ignore that rule, they wouldn't however.) CMVP also does not directly tell the vendor; what they do instead is they tell the FIPS 140-2 test laboratory that the vendor was working with.

It is the lab's responsibility to coordinate with the vendor, because the lab understands both the FIPS 140-2 testing process/requirements and because the lab has an in depth understanding of the vendor's product (as a result of their testing). CMVP doesn't have the manpower or time to coordinate directly with the vendor. (Also in general, vendors don't always understand or correctly use FIPS 140-2 terminology; the lab would know, based on their previous work experience with the vendor, how to translate the problem into something the vendor can clearly understand.)

So sure, if someone from OpenSSL called up CMVP they would be told that CMVP isn't going to discuss the problem. First of all, CMVP doesn't necessarily know that they are from OpenSSL, after all it might be a social engineering attack, and second it is the test lab's responsibility to talk to the vendor. (The lab would have an established relationship with their point of contact at OpenSSL, and would know they were talking to an authorized person.)

I got this in the fips-nis-update mailing list (5, Informative)

Argon (6783) | more than 7 years ago | (#15743310)

3:00 pm -- Tuesday, July 18, 2006

http://oss-institute.org/index.php?option=content& task=view&id=166&Itemid= [oss-institute.org]

OpenSSL Module Certification Number 642: back on again...

To: OSSI
From: DOMUS IT Labs
RE: Status of OpenSSL Module (Certification #642)

I received a call this afternoon (Tuesday, July 18, 2006) from the NIST side from the CMVP. They have indicated that certificate #642 had incorrectly been marked as "revoked" during the web site update on Friday 14-Jul-2006. The CMVP has returned the certificate to its "not available" status and posted the following explanation regarding the terminology:

If a validation certificate is marked not available, the module is no longer available for procurement, but may still be retained and used to demonstrate compliance to FIPS 140-1 or FIPS 140-2.

If a validation certificate is marked as revoked, the module validation is no longer valid and may not be referenced to demonstrate compliance to FIPS 140-1 or FIPS 140-2.

Refer to http://csrc.nist.gov/cryptval/140-1/1401val.htm [nist.gov]

Updated and resubmission continues on previous schedule.

----
it's never boring, that I can promise you.
stay tuned.
jmw

--
John M. Weathersby, Jr.
Executive Director
Open Source Software Institute
www.oss-institute.org
tel: 601.427.0152

Ad maiorem dei gloriam (AMDG)
Audentes fortuna juvat

Re:I got this in the fips-nis-update mailing list (1)

Intron (870560) | more than 7 years ago | (#15744901)

It's interesting that OpenSSL is the only listed module that has either "Revoked" or "Not Available" status. If it were due to a change in procedures or testing, one would expect it to affect multiple modules.

Re:I got this in the fips-nis-update mailing list (2, Interesting)

Mr. Hankey (95668) | more than 7 years ago | (#15746014)

More interesting is the fact that several commercial products from companies such as Oracle and Cisco rely on OpenSSL. I'm curious to see just how long this will last. My guess is not as long as some people think.

Saving$ are for Sucker$ (3, Informative)

digitaldc (879047) | more than 7 years ago | (#15743339)

An official with the Defense Department's Defense Medical Logistics Standard Support program told GCN when certification was granted that OpenSSL could save the program hundreds of thousands of dollars.

Just speculating here, but maybe it is due to 'competition' by a high-priced commercial alternative that was pushed through by lobbyists?
Why save US taxpayers hundreds of thousands of dollars when you can benefit yourself and rack up huge profits for your corporate friends?


Further reading: http://www.boston.com/news/local/maine/articles/20 06/07/19/audit_finds_ipods_dog_booties_on_homeland _security_credit_cards/ [boston.com]
"Audit finds iPods, dog booties on Homeland Security credit cards By Lara Jakes Jordan, Associated Press Writer | July 19, 2006
WASHINGTON --Wielding government-issued credit cards, Homeland Security employees racked up hundreds of thousands of dollars in unjustified expenses last year, including booties for rescue dogs, iPods, designer rain jackets and beer-making equipment, a congressional audit shows."

Re:Saving$ are for Sucker$ (1)

chrpai (806494) | more than 7 years ago | (#15743764)

I spent 6 years on the DMLSS project... I know Steve Marquess very well. There is no way that what you suggest is even remotely possible.

Info (0)

Anonymous Coward | more than 7 years ago | (#15743975)

"The DMLSS System is an automated information system used by the four major branches of the service to provide medical logistics support to military hospitals and other medical facilities". I suspect someone that hasn't had tricare might not know this. Also Steve Marquess is the technical manager of DMLSS.


I think the point of your comment is "bad things happen in some US Govt departments but not in the XYZ". For the benefit of others: someplaces are much, much better than others. As for DoD Civil Service employees: the vast majority of them realize that a lot of Military folk are depending on them to do their job right and most do. I think you're also trying to say something like "Don't confuse bad choices at the top, petty theft or a few LIFERs as the entire work force."

Re:Info (1)

chrpai (806494) | more than 7 years ago | (#15745701)

I wouldn't say that `bad` things never happen on the DMLSS program.

I would say that for better or for worse, Steve is as heavily vested in Linux/Unix and FOSS as any of your most vocal supporters here on Slashdot. The notion of him bowing down to some pressure to replace OpenSSL with some other vendors implementation is just beyond conceivable.

Theft and US Govt. fuel cards (0)

Anonymous Coward | more than 7 years ago | (#15743788)

You know how many 5 gal gas cans I've seen in US Govt issued cars? Yup, hit the fuel station, fill up Uncle Sammy's ride and the gas can is your "bonus" for the day. I once saw a tap installed on one truck to "aid" in the removal of fuel. Audits (after the fact) on said truck showed it was getting about -4 mpg.


Welcome to Midnight Fuel Supply (right next door to Midnight Office Supply).

Re:Theft and US Govt. fuel cards (0)

Anonymous Coward | more than 7 years ago | (#15744279)

I hope you called the agency's Office of Inspector General with tag number, etc.

Re: Saving$ are for Sucker$ (1)

dramenbejs (817956) | more than 7 years ago | (#15744348)

Which dumbhead marked the parent comment as flamebait?
Did he read it?

Slashdot discussion seems to be increasingly polutted with touchy teenagers...

In current news... (0)

Anonymous Coward | more than 7 years ago | (#15743345)

Re:In current news... (3, Interesting)

neonprimetime (528653) | more than 7 years ago | (#15743405)

If a validation certificate is marked "not available," the module is no longer available for procurement, but may still be retained and used to demonstrate compliance to FIPS 140-1 or FIPS 140-2.

Weathersby said the problems have been corrected and the workaround submitted to the certifying laboratory, Domus IT Security Laboratory of Ottawa, for re-evaluation.
Weathersby said the results of the re-evaluation would be submitted to CMVP for a final review and reinstatement of the certificate.


Seems like we're in for a wait.

FOIA? National Security?? (3, Informative)

2phar (137027) | more than 7 years ago | (#15743361)

"The CMVP does not provide information regarding the status or reason as in many cases it may be proprietary"

Could someone explain how a flaw discovered in public source code is "proprietary"?!

Are they saying they can't tell anyone what's wrong with it because it would reveal some sort of flaw in SSL to 'terrorists'? Will this stand up to the Freedom of Information Act?

And then.. if the developers via divine intervention determine what the problem is, does this mean they can't put comments in the open source describing it?!

Rediculous.

Re:FOIA? National Security?? (1, Insightful)

Anonymous Coward | more than 7 years ago | (#15743477)

They have a policy not to publicly disclose this info. This policy was set up for propriatary/closed source vendors. They just continued to follow that policy when dealing with an open source vendor. OpenSSL/OpenBSD will most likely tell the public this info at some point, but it still may be something they want to fix before publishing -- a practice which is common in both open and closed source products/projects.

Re:FOIA? National Security?? (2, Informative)

Shanep (68243) | more than 7 years ago | (#15743883)

They have a policy not to publicly disclose this info. This policy was set up for propriatary/closed source vendors. They just continued to follow that policy when dealing with an open source vendor. OpenSSL/OpenBSD will most likely tell the public this info at some point, but it still may be something they want to fix before publishing -- a practice which is common in both open and closed source products/projects.

Why would the OpenBSD project make public announcements on behalf of the seperate OpenSSL project? The OpenSSL project cannot speak for themselves?

Re:FOIA? National Security?? (1)

GigsVT (208848) | more than 7 years ago | (#15745298)

Well they all work for this "Open" company.

It's just like that "Ars" company that ran that Digita site and that Technica site.

Re:FOIA? National Security?? (1)

fferreres (525414) | more than 7 years ago | (#15747433)

They are just stating they have a secret criteria for choosing and don't want anyone to know the criteria. Exactly what we are complaining about is THE FEATURE, no the error of the policy.

That's because (2, Funny)

caluml (551744) | more than 7 years ago | (#15743364)

That's because they've found the back door I embedded in it while no-one was looking last Christmas. Wait, someone's at the door.

Re:That's because (1)

glitch23 (557124) | more than 7 years ago | (#15747384)

That's because they've found the back door I embedded in it while no-one was looking last Christmas. Wait, someone's at the door.

Offtopic - It's "last holiday" you insensitive clod. Think of all the atheists you just offended. By the way, I forgot to wish all the Americans happy holiday recently. Remember, we aren't allowed to say "Independence Day" (oops, sorry) because that would offend people who don't set off fireworks or maybe it offends those who aren't truly independent. I don't know.

Politics != Security (4, Insightful)

ttfkam (37064) | more than 7 years ago | (#15743373)

Weathersby said OpenSSL has been challenged by companies with competing proprietary encryption technologies, and that those challenges are aided by the open-source model, which makes source code for the tools publicly available.

"Now the opposing forces have the luxury of going in and trying to pick us apart," he said. "That's fine. That's fair. This is about dollars and cents. This is not about technology."

This doesn't bother me so much on its face; OpenSSL can only get better after this intense review. What bothers me is that the "opposing forces" are not likely receiving the same level of scrutiny and yet presumably are fully certified for sensitive information by the US government.

But of course they can't release the code for everyone else to review. People might steal their ideas, right? So how do we know they are secure rather than "mostly secure"? Or even worse, that they are "sort of secure, but the right people were taken out to dinner."

Re:Politics != Security (1)

Padrino121 (320846) | more than 7 years ago | (#15743637)

You are correct in your assertion that the "opposing forces" are not receiving the same level of review. I cannot go into great detail but I can say based on public information that one of those opposing forces is RSA, it is definitely in their interest to not see a free software model reach a level 1 certification because they turn some serious revenue over with their product. Instead of producing a product that provides a value add that makes the purchase worth the money they, as well as a few other vendors are playing dirty pool by using NIST's process to send complaint after compliant over the wall. NIST is obligated to research each complaint however the motivation is extremely questionable.

Re: Thank you proprietary competitors! (1)

nadamsieee (708934) | more than 7 years ago | (#15744184)

Keep those bug reports rolling in! Eventually you'll run out of steam, and OpenSSL will run out of bugs. Hmmm, do I want a SSL product that has been reviewed by company X, or a SSL product that has been reviewed by companies X, Y, Z, A, B... ;)

If you work within the DoD (1)

guisar (69737) | more than 7 years ago | (#15744211)

Those of you within the DoD should voice your support for the OSSI's effort to T02 or the CTO at DISA. It's important for NIST to understand this delay on their part can have a significant (negative) operational impact and if there's not an actual technical issue, this has to be resolved post haste.

this is good. (1)

brenddie (897982) | more than 7 years ago | (#15743376)

This will only mean that whatever was "wrong" will get fixed for the benefit of us all. Something propietary formats cant benefit from.
Weathersby said OpenSSL has been challenged by companies with competing proprietary encryption technologies, and that those challenges are aided by the open-source model, which makes source code for the tools publicly available.
"Now the opposing forces have the luxury of going in and trying to pick us apart," he said. "That's fine. That's fair. This is about dollars and cents. This is not about technology."

Re:this is good. (1)

Peter Simpson (112887) | more than 7 years ago | (#15743521)

Absolutely! Though somewhat discouraging in the short term, the product will be better in the long term, for the many eyes (some unfriendly, no doubt) searching for flaws. This is how you get good, robust software. A lot like peer-reviewed research.

So, don't get discouraged; changes will be made, recertification will happen, and OpenSSL will emerge better for the experience!

Re:this is good. (1)

mclaincausey (777353) | more than 7 years ago | (#15743581)

Not necessarily true. It doesn't have to be something wrong, it can be something that is in violation of a standard that itself is not perfect, or it could be a problem with the documentation OSSI has provided. Remediation might involve "fixing" something that wasn't really broken to start with, or with modifying documents to suit algorithms or vice-versa.

Re:this is good. (1)

AndroSyn (89960) | more than 7 years ago | (#15743892)

Damnit..you people...The OpenSSL project has *nothing* to do with OpenBSD other than starting with the word Open.

Strange (1)

PrayingWolf (818869) | more than 7 years ago | (#15743377)

FTA:
"The certificate apparently was suspended in June when questions were raised about the validated module's interaction with outside software elements."
"NIST is not saying why the certificate was removed."

Sounds like an inside job to me

Must have been Microsoft. (0)

Anonymous Coward | more than 7 years ago | (#15743754)

Must have been Microsoft. Yeah, that's it. Microsoft is responsible for all attackes on OSS, right? Evil Microsoft.

ahem (0, Troll)

tomstdenis (446163) | more than 7 years ago | (#15743508)

CERTIFICATION is a SCAM!

It means nothing other than your implementation of an algo is correct. It doesn't mean you used it right.

Tom

Re:ahem (0)

Anonymous Coward | more than 7 years ago | (#15743747)

True but sans certification you can't use your code in a lot of places where you can make a lot of money.

Re:ahem (0, Troll)

tomstdenis (446163) | more than 7 years ago | (#15743777)

In my case, my code is used everywhere AND I make no money off it. :-)

Tom

Re:ahem! (0)

Anonymous Coward | more than 7 years ago | (#15744928)

Good for you. Now stop being so smug and contribute positively.

Re:ahem! (1)

tomstdenis (446163) | more than 7 years ago | (#15745049)

I am, by suggesting that the "testing centres" are scamsters who want you to keep thinking that with a FIPS seal your product is actually secure.

FIPS certification is largely meaningless outside of RNG and EM testing.

Tom

Re:ahem (0)

Anonymous Coward | more than 7 years ago | (#15745340)

Didn't you learn not to toot your own horn on sci.crypt? At least slashdot has moderation...

Re:ahem (1)

tomstdenis (446163) | more than 6 years ago | (#15746450)

I'm not tooting my own horn. I'm saying certification is meaningless and that people will use ANYTHING so long as it meets their needs and budget. My code happens to be free and apparently they don't care that I haven't forked over the required 10 grand or so PER RELEASE to get it verified [per platform too btw].

Tom

certification done in canada ? (0)

Anonymous Coward | more than 7 years ago | (#15743547)

Does it strike anyone else as strange that the U.S outsources their certification for sensitive security products to other countries ? Isn't this kind of asking for trouble ?

I mean as far as trustworthy neighbors go you can pretty much rely on canada, but you would expect they would defer to some of the highly qualified hackers in the NSA.

(disclaimer:I know jack shit about us govt)

Certifiably Broken (1)

Doc Ruby (173196) | more than 7 years ago | (#15743849)

NIST certification fluctuating [gcn.com] unintelligibly is a security nightmare. NIST's certification process needs to be reliable, or the uncertainty will create not only risk of using broken or incompatible security, but also spikes in attacks as crackers get the news that some product might be broken. The products might not be broken, just NIST's decertification process, but who needs the extra waves of attacks?

I'm not surprised that this procurement certification is broken. Bush's top procurement official got busted for being badly broken [google.com]. Spending $3 TRILLION a year on stuff while lining your pockets has got to leave some holes in the system.

yo?u FAiL it.. (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#15744108)

so on, FreeBSD went thei8 hand...she

FYI: Openssl FIPS Details (1)

mpapet (761907) | more than 7 years ago | (#15744992)

Keep in mind a FIPs certified build of openssl requires specific but not complex build parameters.

Also keep in mind the Openssl project can't modify the fips-certified code parts. It would have to go back for certification and I doubt Novell/HP and ? want to pay for that again and again.

It would be interesting to hear if distros (or any users) are building and using it in applications in the FIPS mode.

Obligatory link: http://oss-institute.org/fips-faq.html [oss-institute.org]

Re:FYI: Openssl FIPS Details (1)

Frogular (961545) | more than 7 years ago | (#15745687)

From http://oss-institute.org/fips-faq.html [oss-institute.org]
3) What exactly is being validated? The OpenSSL Crypto modules? The whole distribution? FIPS 140-2 is concerned with cryptographic module implementations, not applications or products per se. The FIPS 140-2 "cryptographic module" defined for OpenSSL contains the FIPS 140 specific cryptographic API and algorithm implementations only; i.e. the API for low level algorithms (RSA, AES, 3DES, DSA, SHA-1). This cryptographic module is a minimal subset of the full OpenSSL distribution which is essentially just the *.c and *.h files for the relevant crypto algorithms
And they don't even certify the entire package, only the encryption algorithms. Haven't cryptographers spent forever showing how to implement secure algorithms? It would seem the majority of security flaws arise from the rest of the software package. The dinner the NIST guys got must have been pretty delicious.

Mozilla NSS is open-source and FIPS140-1 validated (1)

madbrain (11432) | more than 6 years ago | (#15746760)

It is unfortunate that OpenSSL had its certificate revoked. Condolences to the developers, and good luck going through the revalidation process with NIST.

I would like to point out however that Mozilla's NSS (Network Security Services) library is also open-source, performs much of the same functions as OpenSSL, and has been previously FIPS140-1 validated several times - the first validation was over 5 years ago. A FIPS140-2 validation is ongoing. See http://www.mozilla.org/projects/security/pki/nss/f ips/ [mozilla.org] for more information. NSS is used in Mozilla, Evolution, OpenOffice, Solaris, Sun Java Enterprise System, RedHat Linux, among others.

FIPS-140 SSL in hardware alternative! (0)

Anonymous Coward | more than 6 years ago | (#15746987)

We looked into this about the time OpenSSL was first awarded FIPS certification and decided that for both performance and security reasons we had to have a hardware-based solution. What we found is that not very many such solutions exist. We found a company named Britestream Networks (https://www.britestream.com/ [britestream.com]) that has an "SSL NIC" card that does full SSL (and TLS) offload for the server and is really fast (something like 10,000 TPS). It also has some good security features such as strong crypto (AES-256, support for 4K RSA keys, etc) and storage of SSL certificates and keys in encrypted flash memory on the card itself. So even if the server is hacked, the RSA key isn't exposed. From what I remember, the FIPS 140-2 Level 3 version of this Britestream card was actually joint developed with nCipher and carries an nCipher brand name. But I'm sure the Britestream folks can give the additional details. Our project got delayed to late this year, so I'll have to pick this up again then. By the way, does anyone have any experience with the Britestream "SSL NIC"?

Big deal.... (1)

nighty5 (615965) | more than 7 years ago | (#15748165)

Its only helpful to businesses that make money off the hard non-paid work of contributors of OpenSSL, for which they don't receive funds.

Let the companies buy an SSL approved mechanism, they have the cash. We sell an appliance that has SSL built in, the cost of the appliance can be up to 250k and above.

Says more about the rejector (0)

Anonymous Coward | more than 7 years ago | (#15748882)

Frankly, if the US govt organisation refuses to certify a security and encryption platform in widespread use for non-transparent reasons, it says more about the buggered-as-batshit operational procedures at that US govt organisation than about OpenSSL.

Why don't they just select Cheney's Haliburton in a no-bid contract to supply encryption and have done?
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...