On 4/1/2022 11:25 AM, Enzo Matsumiya wrote:
On 04/01, Tom Talpey wrote:
Is SMB2 really FIPS compliant? Even if it is, a server that doesn't
support anything higher is obviously far out of date.
It's more that the crypto stuff used by SMB1 is *not* compliant.
Sure, but that's not the point here. It's time to simply state
"don't use SMB1".
If SMB2 keeps using FIPS-approved hashing/crypto algorightms, I guess it
makes it FIPS compliant, and the burden is on their end to disqualify
older algorithms for their certification.
I don't think the crypto algorithm is enough. SMB2 is vulnerable
to man-in-the-middle attacks and therefore the crypto type is
only a part of the picture. SMB3 is much stronger, even with the
same crypto algs.
I think it
would be better to recommend, or maybe even require, SMB3 here.
So, I've added a bit in the SECURITY section saying that mount.cifs
doesn't enforce anything, and all crypto blocking/allowing is made on
the kernel.
Do you think we should? An informed user, with particular requirements,
might want to use SMB2 *and* still be FIPS compliant, but we would be
enforcing something (non-SMB3) that's not quite right.
The Microsoft FIPS statement only refers to SMB3, for example:
https://docs.microsoft.com/en-us/windows/security/threat-protection/fips-140-validation
Is SMB3 (Server Message Block) FIPS 140 compliant in Windows?
SMB3 can be FIPS 140 compliant, if Windows is configured to operate in
FIPS 140 mode on both client and server. In FIPS mode, SMB3 relies on
the underlying Windows FIPS 140 validated cryptographic modules for
cryptographic operations.
I think anyone who is serious enough to want FIPS should darn well
be advised that the best security means running the strongest version
of the protocol, and the doc should not waffle around with discussion
of SMB1 or SMB2.
MHO.
Tom.
And if the kernel is not in FIPS mode, we should only inform the user,
because we don't actually use/do any crypto computation in mount.cifs.
Cheers,
Enzo
