Hey all. I’m a sysadmin for a small MSP and we’ve just inherited a new client, a police department. Their desktop machines (win10/win11) are all domain joined and hardwired and there are no wireless networks. They have an HA pair of Sonicwall TZ270 firewalls guarding the gate. A new request has come through to add several laptops to their domain. These laptops will be used in patrol vehicles and need to be connected back to their LAN subnet and the domain controller (win server 2022).
Since they’re a police department, they have to comply with CJIS regulations, and my understanding is that the connection between the laptops and LAN subnet has to use FIPS 140-2 validated cryptography. (The possibility exists that CJI, the sensitive data that requires protection, may transit this connection.) This is all new territory for me, but I did some digging and learned that their firewalls are already running in FIPS mode. So that’s a start.
I’m completely confused though on what needs to happen on the laptop side of this equation. The laptops are all running win10/win11 and I know that I can enable FIPS mode through group policy. In fact, I tried this and it doesn’t work. The Sonicwalls require SHA256 authentication to remain in FIPS mode and the only way that I could get the laptops to connect was to change the Sonicwalls to SHA1, which knocks them out of FIPS mode. I found a list online that suggests that win10/win11 only support SHA1 for authentication which is kind of strange. (I was connecting via the built-in L2TP/IPSec VPN client.)
Sonicwall has a couple of VPN clients, but none appear to be FIPS validated. So I’m at a loss here. For those with more experience on the subject matter, how would you connect these laptops to the main network while remaining compliant with the FIPS 140-2 validation requirement? The laptops need to be connected at all times and all traffic needs to be tunneled through the Sonicwalls. So how would you approach this issue?
To my knowledge if the sonicwall is running with the FIPS mode toggle on, then all traffic flowing through it is using a validated crypto module. It disables in the GUI any algorithms that didn’t pass validation.
Effectively this should mean that any VPN tunnel you get up and running successfully is validated as long as FIPS mode is enabled on the firewall. I’ve personally only ever run the SSL VPN on sonicwalls running FIPS…but all other tunnels should work too. If you don’t want to run the SSL VPN I’d personally recommend IKEv2 over L2TP. More modern protocol and faster more reliable connection in my experience for direct Windows VPN needs.
If you are using some other kind of encryption to protect your traffic, the VPN itself doesn’t need to part of your secure system. It can just be bonus encryption.
One additional thing you may want to be aware of. The latest release of the CJIS security policy 5.9.6 FIPS 140-2 certificates will not be acceptable beginning September 21,2026. Also depending on your agency’s requirements; the “or” statement of SC-13 may apply. which may allow for use of a FIPS validated encryption algorithm vs FIPS certified product.
Implement the following types of cryptography required for each specified cryptographic
use: cryptographic modules which are Federal Information Processing Standard (FIPS) 140-3
certified,
or FIPS validated algorithm for symmetric key encryption and decryption (FIPS
197 [AES]), with a symmetric cipher key of at least 128-bit strength for CJI in-transit.
As for a specific product you might want to look into absolute core (previously known as Netmotion mobility suite)
Not sure which NIST controls you need. If you can find a good list of all the controls you need to implement, it would help to know the specific requirements. ----In the 800-53 - The assessor will need proof that either the protected data is encrypted before it leaves the boundary or that the VPN is FIPs 140-2 validated - meaning you must find the actual validated module from that vendor, for that model and version. https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search
The entire connection would need to be FIPS, which means enabling it on all the devices.
Just because the firewall is generating ciphers correctly doesn’t mean the laptops are. They’ll need to be in FIPS mode as well (Windows setting), plus whatever software being configured to use FIPS (eg the laptop VPN client)
Bitlocker is being used to satisfy the need for encrypting data-at-rest. The issue I’m facing is with data-in-transit and there are no other encryption mechanisms in place, so the VPN would need to provide the encryption. The firewall side appears to be fine as it’s already running in FIPS mode and the FIPS certificate numbers are readily available. The Windows built-in VPN side is a puzzle though. It doesn’t help that I’ve never really understood how all the different encryption algorithms work. And then determining which FIPS certificate is applicable is an entirely different challenge.
This is very interesting. So with a FIPS certified module, you’d be able to search the NIST CMVP database and find the corresponding certificate for that module. If you’re using that module AND operating in an approved mode, you can then present that certificate to prove your compliance with the policy. This process is fairly straight forward.
But it doesn’t seem as straight forward with the FIPS validated algorithm approach. The CAVP lists AES-CBC as an approved encryption algorithm. And according to SC-13, the key length must be at least 128-bits. So, assuming I’m using AES-256-CBC for bulk encryption, I’d be considered to be in compliance with the policy? Would you not still have to prove that the cryptographic module responsible for that encryption is performing it’s functions properly? Isn’t that the entire point of the mandated validation for the module?
That is a typo in the security policy. In-Transit AWAYS requires FIPS 140-2 (or the upcoming 140-3). At-rest can be EITHER 140-2 OR 197 AES 256.
The section you are referring to is a typo. It is obvious because it mixes FIPS 197 and 128-bit together. FIPS 197 never allows 128-bit. 128-bit minimum is only for FIPS 140-2. FIPS 197 always requires 256-bit. Also, everywhere else in that same document, in-transit only allows for FIPS 140-2.
If a document editor notices this, it will be changed in the next revision to be only FIPS 140-2.
Yeah, this is my understanding. Both sides (firewall and laptop) have to be in FIPS mode and using approved algorithms. I’ve been unable to locate a vendor-specific VPN client that meets FIPS 140-2 validation. That’s why I’m trying to use the built-in Windows VPN client. I’m assuming that when I place Windows in FIPS mode, that covers the built-in VPN as well. Just don’t understand how to get around the differences in supported algorithms to make this thing work.
Sonicwall provides the following for FIPS mode:
Use FIPS-approved encryption and authentication algorithms when creating VPN tunnels. The SonicWall UTM appliance supports the following FIPS-approved cryptographic algorithms:
– AES (128, 192, and 256-bit) in CBC mode (Cert. #1200)
– Triple-DES in CBC mode (Cert. #868)
– SHA-1 (Cert. #1105)
– DSA (Cert. #398)
– RNG (Cert. #664)
– RSA (Cert. #577)
– HMAC-SHA-1 (Cert. #697)
Only SHA-256 Authentication or higher is allowed in FIPS mode
IKEv2 Dynamic Client Proposal in VPN advanced settings requires SHA-256 or higher
So everything there seems to indicate that SHA256 or better is required. But when you research the Windows policy setting for enabling FIPS mode, it has the following to say:
System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing
TLS/SSL
This policy setting determines whether the TLS/SSL security provider supports only the FIPS-compliant strong cipher suite known as TLS_RSA_WITH_3DES_EDE_CBC_SHA, which means that the provider only supports the TLS protocol as a client computer and as a server, if applicable. It uses only the Triple Data Encryption Standard (3DES) encryption algorithm for the TLS traffic encryption, only the Rivest-Shamir-Adleman (RSA) public key algorithm for the TLS key exchange and authentication, and only the Secure Hash Algorithm version 1 (SHA-1) hashing algorithm for the TLS hashing requirements.
This part… “and only the Secure Hash Algorithm version 1 (SHA-1) hashing algorithm for the TLS hashing requirements”… seems pretty clear that only SHA1 is supported. So Sonicwall wants SHA256 and Windows wants SHA1. In my testing, if the Sonicwall was set to SHA256, no connection. As soon as I changed it to SHA1, the Windows VPN connected. The Sonicwall FIPS mode automatically toggled off after changing from SHA256 to SHA1. So, I’m not sure if this is even possible…
That is a typo in the security policy. In-Transit AWAYS requires FIPS 140-2 (or the upcoming 140-3). At-rest can be EITHER 140-2 OR 197 AES 256.
The section you are referring to is a typo. It is obvious because it mixes FIPS 197 and 128-bit together. FIPS 197 never allows 128-bit. 128-bit minimum is only for FIPS 140-2. FIPS 197 always requires 256-bit. Also, everywhere else in that same document, in-transit only allows for FIPS 140-2.
If a document editor notices this, it will be changed in the next revision to be only FIPS 140-2.
Are you sure I’m just checked the FIPS 197 documentation and found this from the may 9, 2023 update to FIPS 197.
Explanation. The Advanced Encryption Standard (AES) specifes a FIPS-approved cryptographic algorithm that can be used to protect electronic data.
The AES algorithm is a symmetric block cipher that can encrypt (encipher) and decrypt (decipher) digital information. The AES algorithm is capable of using cryptographic keys of 128, 192, and 256 bits to encrypt and decrypt data in blocks of 128 bits.
FIPS 140-x is a combination of the encryption algorithm as well as deployment requirements tamper proof circuit board etc.
This is where you’re conflating a requirement that doesn’t exist. It’s not up to a VPN client to be FIPS validated because a VPN client doesn’t set the tunnel configuration and acceptable protocols, the VPN server does. The VPN client only negotiates the tunnel and configures it according to VPN server’s parameters.
In this case the VPN Server is your firewall. If you choose to use SSL VPN, you’d use the NetExtender client on the Windows side and it sets up the tunnel appropriately with the proper TLS encryption as specified on the server. Same goes for if you setup IKEv2: on the VPN Server side you’ll be forced into specific DH Group types and also algorithms that are FIPS approved (SHA-256 in SonicWalls case). Then the VPN client is forced to negotiate the tunnel based on those parameters. It doesn’t matter if it’s the built in Windows one or not. Any 3rd party client won’t be able to establish a tunnel that uses algorithms the VPN server does not accept.
In summary, VPNs aren’t validated based on their client components but the server side instead. While the NIST FIPS controls talk about using validated encryption across your entire system boundary, it doesn’t care what client you use because the client doesn’t specify the requirements or validated algorithms, the server side does. Same goes for SASE/SSEs like zScaler. It’s not their client side connector that is validated, it’s their cryptographic module they use on their server side components.
Here is a direct cut and paste excerpt from the same current CJIS Security Policy stating the difference:
FIPS 140-2 certification is required when CJI is in transit outside a physically secure location. When at rest outside a physically secure location, encryption methods can use Advanced Encryption Standard (AES) at 256 bit strength or a FIPS 140-2 certified method.
Notice that it says FIPS 140 is required when in transit, but either method can be used while at rest. AES 256 is the “FIPS 197” method that doesn’t require certification. FIPS 140 is an actual certificate number, FIPS 197 is an approved method that doesn’t have a certificate.
I’m going to disagree with your logic. Sure, the VPN server can force clients to use FIPS approved algorithms… and the cryptographic modules of the server and client may very well provide the required degree of encryption. But if those modules are not “FIPS validated”, then that encryption is meaningless. (In terms of compliance) Simply using the algorithm is not good enough.
It’s like raising chickens as meat birds. You can raise them following completely organic practices. But in the US, you can’t sell them at market as “organic” without a USDA Organic certification. Simply following standards isn’t enough. You need the certification to be legit.
Each side (server and client) encrypts the data before sending through the tunnel. Therefore, to be compliant, each side must encrypt that data using a cryptographic module that is FIPS validated. So I believe the VPN client also needs a valid FIPS certificate.
So again you’re correct in that there are two different FIPS compliance mechanisms in play here, algorithms vs modules. Very key and something a lot of people overlook is that you can’t just use crypto algorithms from the Cryptographic Algorithm Validation Program. You have to use solutions that have gone through the Cryptographic Module Validation Program. But that’s just it, SonicWall’s cryptographic module is validated. You’re right in that you couldn’t use a Watchguard firewall running in FIPS mode because their module hasn’t passed validation. But SonicWall’s and Fortinet’s modules have. And it’s the software cryptographic module that’s been validated, same as the Windows cryptographic modules in various components. It isn’t Windows 110 running on a specific Dell Latitude module, it’s any Windows 10 instance running on any hardware with FIPS mode turned on at the OS level.
Your misstep here isn’t about algorithms vs modules, it’s about networking architecture at its core (no offense intended at all). VPN server architecture defines a network segment, and the crypto module in play at the server level is what matters. If that module is validated and any required FIPS mode is enabled, the FIPS control is satisfied for the network segment. Again VPN clients themselves don’t define the network segment.
Take the disk side about using FIPS mode in Windows and Bitlocker encryption…by extension your FIPS application to a VPN client is like saying that if your Bitlocker disk is formatted as an exFAT or ReFS volume…the at-rest segment is no longer validated since the FIPS certificate was issued against an NTFS implementation at NIST’s lab. That’s just ridiculous because that’s not how encryption of disks works at the hardware level. Same goes for comparing a VPN client to a VPN server from a networking side of things. The validation only cares about the module, not the nuance behind unrelated aspects of the technology.
Yes, 5.9.5 is where my copy/paste came from. A different section of the same document that you are looking at.
My point is that even though you are correct that the document does show what you are saying, the part you are referencing is very likely a mistake in the document. I am in no way saying that you are misinterpreting the document. I am saying that the document itself conflicts with itself.
Here are my reasons:
#1 In every other location of the same document where it references FIPS-197, it specifics a minimum of 256-bit. In every other location where it references FIPS-140, it specifies a minimum of 128-bit. In the section that you reference, it mixes those and specifies 128-bit for FIPS-197.
#2 In every other location of the same document where it references data in-transit, it specifies FIPS-140 ONLY. In every other location where it references data at-rest, it specifics “OR” (either 140 or 197). In the section that you reference, it mixes those and has “in-transit” with “OR”.
#3 It has always been the case that Federal Agencies use FIPS 140 for data in-transit. Vendors spend hundreds of thousands of dollars to make their software and hardware compliant. If it really were the case that you could use either 140 OR 197 and still be compliant, then there would be no reason for anyone to ever go through the painful process of becoming 140 certified. However, they do because the policy requires it.
Basically, this 1 section that you reference goes against all of the other sections and seems to mix things together. I would argue that the editor of this document made a typo or a mistake in copy/paste, and that if they were made aware of this, they would modify this section to be in alignment with the other sections.
Of course, I personally would love to have FIPS-197 to be approved for in-transit (and for you to be correct) because it is much easier to implement than FIPS-140, but I don’t believe that to be the intended case.
FIPS compliance, as it relates to encryption, has nothing to do with network architecture. At all. I’m not sure why you’re hung up on that.
The FIPS 140-2 requirement states that whenever CJI (sensitive data) is transmitted, you will encrypt that data using an approved algorithm and a validated module. That’s it. Since both the server and the client are capable of transmitting data, they must also both be capable of encrypting that data with a validated module. It’s a two way road. If the client is not generating compliant ciphers, the entire VPN is non-compliant. At that point, it doesn’t matter what the server is doing.
So the problem remains… I have a FIPS validated server, but still lack a FIPS validated client that can negotiate with that server…