Comment by b112 | Hacker News Reader

Comment by b112 | Hacker News Reader

Parent Full thread

Uh, yes it will. OpenSSL in Trixie is a version supported.

https://packages.debian.org/trixie/openssl-provider-fips

It's just the library, nothing special about the OS.

https://csrc.nist.gov/projects/cryptographic-module-validati...

As far as I know, compliance comes with an external module:

https://openssl-library.org/post/2025-03-11-fips-140-3/

This module seems to be in Debian:

# apt-cache search fips | grep open openssl-provider-fips - Secure Sockets Layer toolkit - cryptographic utility

# dpkg -L openssl-provider-fips /. /usr /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/ossl-modules /usr/lib/x86_64-linux-gnu/ossl-modules/fips.so /usr/share /usr/share/doc /usr/share/doc/openssl-provider-fips /usr/share/doc/openssl-provider-fips/changelog.Debian.gz /usr/share/doc/openssl-provider-fips/changelog.gz /usr/share/doc/openssl-provider-fips/copyright

There seems to be the validation process, which supposedly must run on each machine it is used on.

openssl fipsinstall -out /tmp/configfile.cnf -module /usr/lib/x86_64-linux-gnu/ossl-modules/fips.so 2>&1 | tee /tmp/result.txt

--

The above are from my notes, and a test run. But I don't see how Redhat is "special" here. If the module loads and cites compliance, you comply.

> OpenSSL in Trixie is a version supported.

It isn't a validated build. It works the same, but it isn't sufficient if you actually need a validated FIPS module.

> It's just the library, nothing special about the OS.

If you need validation, then the kernel also need to be validated.

Now, it isn't impossible to get a FIPS validated system working with Debian, but you will probably need to contract with another commercial provider like WolfSSL to get validated components. Or compile things yourself. But that is more complicated and involved than just paying for an OS that is validated off the shelf from Ubuntu, Red Hat, or Suse.

I compile software every day. There's nothing difficult about it until cmake starts complaining, but I've got it back on track every time.

Companies who care about whether their FIPS implementation is validated or not would probably prefer buying from a company who sells it over relying on a guy at their company to get cmake back on track regularly. At that point, it's not just about the module, it's about custody, liability, etc.

Jeez laweez. Since when can lawyers make good technical decisions?

I saw a PIN terminal reboot a while ago and the openSSL version was ancient, pretty much historic at that point. But it has an unbroken seal on it, so it's safe, right?

The problem always boils down to money.

It isn't just compiling something that works. You need to compile it exactly as specified. And document the entire process so you can prove to an auditor that you did everything correctly. Oh, and there's a list of tested platforms, and if your platform isn't on there, which Debian probably isn't, you need to explain to the auditor why it's ok, and why it isn't reasonable for you to use one of the platforms it was tested on.

What you are paying for is not saving the time of a developer compiling something. It's reducing the friction when you go through an audit.

I wonder what the specifics of certification are. No certificate can ever prove a given binary works correctly. No one really understands how computers work, but here's a piece of paper that says Oracle Linux 11.0 is okay. It was expensive and it has a seal of approval on it, so that proves it.

Reply on news.ycombinator.com