Hacker News Reader

Comment by jacurtis | Hacker News Reader

Bottlerocket does not off FIPS mode like most other enterprise *nix distributions.

Just to save anybody the trouble who needs FIPS approved encryption for host OSes that you use at work for various compliance programs. This makes Bottlerocket a non-starter for us. A very active issue has been open for over 2 years on this and the dev teams don't seem to be convinced that this is important. We even communicated with the dev team through our dedicated AWS reps and they have no interest in adding this.

Here is the open 2+ year thread on this: https://github.com/bottlerocket-os/bottlerocket/issues/1667

View on HN

Disclosure: I work for Amazon. I’m also the principal engineer for Bottlerocket.

FIPS support continues to be the top customer ask by a wide margin. Unfortunately the timing here is not kind for a new distro with no previous FIPS offering. New FIPS 140-2 certifications are no longer available, and new FIPS 140-3 certifications have to make it through a lengthy queue as the entire industry switches over.

If this were something the dev team could just power through, I assure you it would have happened by now. I apologize for giving the impression that it’s not important. It is, but that doesn’t help the timeline in this case.

In my experience with FIPS certification usually requires some changes that undermine security.

If you need it, then you need it, but having the certification is a mildly bad sign in my opinion.

I’m not the only one with this opinion. For instance, the Microsoft Windows team seems to agree:

https://techcommunity.microsoft.com/t5/microsoft-security-ba...

In the GitHub issue, there is a mention of replacing rustls and Go's crypto library with OpenSSL. That seems like a serious security downgrade.

Having been around a bunch of former-government people and bumping into FIPS myself a few times (like yubikeys) and reading about it, that's also been my sense, but it's nice to see a formal writeup with examples.

Thanks for the link.

It makes no sense if your goal is "have the most secure system feasible under your resource constraints and usage requirements", which is a reasonable goal.

However, the whole FIPS and USG compliance in general mindset is not that; the goal instead is "be aware of ways in which your system is known to not be secure". The idea that a known flaw is better than an less-known fix is infuriating to devs, but from a business standpoint it makes some sense.

That might make sense, but I’ve never seen it with FIPS.

I’ve only seen them force changes were ones that weaken or remove defenses against known attacks.

I’ve never seen them require additional standard defenses, or identity and propose fixes against attacks that were not already considered and addressed by the existing system.

That's... what I said. It's not about making systems more secure but about documenting known insecurities.

"FIPS is the answer to the question, 'How can we force all cryptographic software to be approved by a government committee?'" [1]

Here's your reminder that even if FIPS itself isn't evil, it moves in evil circles with evil people. [2]

[1] https://twitter.com/matthew_d_green/status/41279364233232384...

[2] https://threadreaderapp.com/thread/1433451378391883782.html

Reply on news.ycombinator.com