Live data from Hacker News

LibreSSL: FIPS mode is not coming back

marc.info

81–90 of 98 posts

Re: LibreSSL: FIPS mode is not coming back

#81
post #39

Earlier quoted context omitted.

Nonsense. What would you do if you where the NSA and you've now been repeatedly caught lying, bribing (RSA dual ec), and backdooring (dual ec) security software? At this point, you have a problem: working for the nsa probably taints you in the eyes of many, and nobody (rightly) trust you. But what nation states do have is money and bribery. So you do two things: you attempt to subvert (oh, your brother got busted for…

You're conflating two issues. FIPS validation means that you're using a reasonable set of algorithms. Like any standard they are imperfect and their development lags the state of the art in some cases. In my daily business, I worry more about casual incompetence, as it has a more direct affect on my boring daily life. Re: Your rant about the NSA bribing people, etc. Why do you magically trust OpenBSD? Much of the pro…

>Why do you magically trust OpenBSD?

It isn't magical. I've spoken to many of them. I've seen the work they've done over the last 15 years. They earned my trust.

>Much of the projects early funding was via DARPA

No, a relatively small amount was via DARPA, and that funding was pulled due to Theo criticizing the US government. And that was not early in the project, it was like 8 years into the project's life. Doesn't really scream "NSA plants".

Re: LibreSSL: FIPS mode is not coming back

#82
post #4

For those who don't know what FIPS mode is (like me): https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NS...

Thank you for the primer. Can anybody comment as to why FIPS mode in OpenSSL is considered harmful?

The tactic that the OpenSSL project took to get the FIPS 140-2 validation, but to avoid having to do it over again every time a new openssl release was issued, was to build all the parts of openssl that were audited into a single object (fipscanister.o) that is to be loaded at run time. It is stored at some location on the machine along with a fingerprint, and when one enables FIPS mode, fipscanister.o's fingerprint is confirmed, and then the object is loaded.

In practice, what this means is that you take one of the fips-openssl-x.y.z releases, and build fipscanister.o from it; that has the fundamental crypto bits in it, it's released as infrequently as possible. Then you build a plain old openssl-x.y.z release with a flag to enable the fips feature. At runtime when you enable FIPS mode, your local openssl library would switch to using crypto functions from fipscanister.o, which might be a year or two old. The idea is that the crypto bits don't generally change, although the rest of libssl/libcrypto might change several times during the year.

Anyway building and using openssl this way is a giant pain in the ass, especially if you statically link. To make matters even more confusing, Redhat took an altogether different tack, and have their own variant of openssl that, when FIPS mode is enabled, switches to using the Linux Kernel crypto functions, which they got independently NIST validated, so if you're deploying the RHEL machines in the .gov space, a different FIPS 140-2 validation applies to you.

It leads to a fair amount of crap in the configure scripts, and macros throughout the code.

Re: LibreSSL: FIPS mode is not coming back

#83
post #58
post #53

Earlier quoted context omitted.

So any change to openssl fips has to happen as compiler patches?

No, changing the source means you're not using FIPS-compliant source so you're breaking your terms. This is why you might have to use old versions of OpenSSL for FIPS compliance - not all versions might be certified.

I think the GP is talking about a trusting trust attack on OpenSSL: Change the compiler to compile OpenSSL differently, rather than change the source itself.

Re: LibreSSL: FIPS mode is not coming back

#84

If people really need FIPS mode, somebody will fork again and create libfipssl.com and charge a million bucks for it. And then the ones who need FIPS mode can pay to get it, but they won't pay us. The OpenBSD Foundation will gladly take donations to improve libressl, but some money is just too expensive to accept. Sitting on (or more accurately, under) a million dollars in custom contracts creates what I will charita…

Or here - https://https.openbsd.org/cgi-bin/donations

If you, like me, want to use a credit card but live somewhere where PayPal blocks donations (Japan in my case).

Re: LibreSSL: FIPS mode is not coming back

#86

Earlier quoted context omitted.

Fortunately or unfortunately, there are also a reasonable number of abrasive people who tend not to be right, so I'm not sure it's a good marker either way. There's a whole rock-star persona around people who make consulting careers out of trying to position themselves as security badasses, and not all of them are.

I include amongst these, security/network guys that disable ICMP because they read it in a book somewhere. Leads to a lot of facepalming when you are actually trying to get something done.

Particularly now that ICMP is actually a requirement for IPv6 networks to actually function.

Re: LibreSSL: FIPS mode is not coming back

#87
post #3

The OpenBSD people sure are abrasive, but they deserve a ton of praise for taking on a tough task that no one else was willing to do, and for fixing the damn mess. Between FIPS, the NIST and the OpenSSL foundation it's amazing that crypto even works.

"Fixing" it in a way that guarantees that the changes will not be pulled back into OpenSSL has the following problems:

* the fork will lag behind when new features are introduced into OpenSSL

* the fork will lag behind when new fixes for OpenSSL are implemented

This creates a permanent maintenance burden for the LibreSSL maintainers; sure they have attention now, but in 3 months nobody will give a shit any more.

Re: LibreSSL: FIPS mode is not coming back

#89

Earlier quoted context omitted.

Fortunately or unfortunately, there are also a reasonable number of abrasive people who tend not to be right, so I'm not sure it's a good marker either way. There's a whole rock-star persona around people who make consulting careers out of trying to position themselves as security badasses, and not all of them are.

I include amongst these, security/network guys that disable ICMP because they read it in a book somewhere. Leads to a lot of facepalming when you are actually trying to get something done.

This hits too close too home.

Re: LibreSSL: FIPS mode is not coming back

#90
post #87
post #3

The OpenBSD people sure are abrasive, but they deserve a ton of praise for taking on a tough task that no one else was willing to do, and for fixing the damn mess. Between FIPS, the NIST and the OpenSSL foundation it's amazing that crypto even works.

"Fixing" it in a way that guarantees that the changes will not be pulled back into OpenSSL has the following problems: * the fork will lag behind when new features are introduced into OpenSSL * the fork will lag behind when new fixes for OpenSSL are implemented This creates a permanent maintenance burden for the LibreSSL maintainers; sure they have attention now, but in 3 months nobody will give a shit any more.

Unless the rest of the world switches to using LibreSSL by default, (eg. for security reasons). Then the situation could reverse.

Given the state of the OpenSSL codebase, I think this has a greater chance of happening than most other forks.

Post reply on HN