3DES/SHA1 Still IPSec Default for Remote Access IPSec VPNs?

[Timothy_Hall]

So a few weeks ago I had a customer complaining about poor VPN performance for their Check Point Mobile IPSec clients, along with high gateway CPU utilization.  After some investigation in the SmartView Monitor Users View, we found that the Phase2/IPSec settings (which is used for the vast majority of the traffic sent through the VPN) were still set to 3DES/SHA1 like this:

So even VPN clients that supported stronger and more efficient alternatives such as AES and SHA256 were not allowed to use them by the gateway.  I assumed this was because this was a 10+ year old Check Point customer and these settings were brought forward through countless upgrades over the years.  We moved it over to AES256/SHA256 in a change window and even with the much stronger algorithms, performance was substantially improved and the CPU was far less loaded.  This is a well-known issue: sk98950: Slow traffic speed (high latency) when transferring files over VPN tunnel with 3DES encrypt...

So out of curiosity I pulled up this screen for a freshly installed R81.20 GA implementation in my training lab environment to see what the modern IPSec P2 defaults are...and they are still 3DES/SHA1 with no options for anything else?  Surprising that two deprecated protocols are still the default on a new R81.20 installation, with no other option available to the clients by default.  I understand the need for backwards compatibility for older clients, but are there really that many ancient VPN clients out there that don't support AES at all?  SHA256 I could understand as it is relatively new.

Wouldn't the following be more appropriate going forward as default, even getting changed automatically by an upgrade or Jumbo HFA installation:

Allow the ancient clients to still work with 3DES/SHA1, but I assume the newer VPN clients would minimally try to select something more secure such as AES.  DES-only clients would be out of luck, too bad so sad.  This really needs to be addressed, and I assume it will be with the R82 VPN clients that will add support for IKEv2, I hope they still won't still be using 3DES/SHA1.  In R82 SmartConsole demo mode it looks like this setting is AES-256/SHA1.

Thanks for reading!

[the_rock]

I just checked my R82 lab, appears its the same.

Andy

 

[Ave_Joe]

Are you able to share what the default Phase 2 settings are in your R82 lab setup?  It would be good to see if the fresh install settings have gotten new defaults over the years.

[PhoneBoy]

I'n not @the_rock but I also got R82 in the lab 😉
Phase 2 settings look like they might need to be adjusted:

[the_rock]

You are genius @PhoneBoy , who cares about the rock haha 🤣

I dont know, maybe it will be different with R82 GA? 🙂

Lets see...

Andy

[PhoneBoy]

Entirely possible it will be different in GA.
We'll find out for sure in the near future. 😉

[Timothy_Hall]

Just confirmed with a fresh load of the latest R82 EA that IPSec/Phase 2 settings are still 3DES/SHA1.  Would really love to see this addressed for R82 GA, possibly with the settings in my second screenshot that would prefer the client be AES256/SHA256 but let them fall back into 3DES/SHA1 if absolutely necessary. 

SHA1 has been deprecated for security reasons when used by itself for things like file hash verification and password hashes, but to my understanding it is still plenty secure and computationally very cheap for how it is utilized within the context of the IPSec suite.  Replacing it with SHA256 as the default may not be strictly necessary but 3DES definitely needs to go.

[nmelay2]

I'm surprised you guys are discovering this now!

Poor default VPN settings, for RA and also for S2S, has been a long standing issue with Check Point firewalls.
But I guess it's where a partner's added value is. 😉

[the_rock]

In all fairness, default values are pretty much the same with most major fw vendors 🙂

Andy

[PhoneBoy]

I assume those defaults got adjusted in R82 with the addition of IKEv2 for Remote Access clients.
I agree that these defaults are...sub-optimal.

We don't typically change defaults in JHFs, though, that's usually reserved for version updates.

[Ave_Joe]

This is an excellent topic.  Thanks for starting the conversation.  Your discovery certainly will help customers that have been using remote access vpn for many years improve their setups.

[Timothy_Hall]

Just fired up a copy of R82 GA and was disappointed to see the default IPSec 3DES/SHA1 enforced settings for all Remote Access VPN clients are still there (also still with only DH Group 2 MODP allowed by default).  Kind of odd considering the default IKE/Phase1 hash algorithm for site-to-site VPN communities was updated from SHA1 to SHA384 for R82 (and the default DH group was updated from Group 2 to Group 15 MODP).  Looks like R82 site-to-site default for P2/IPSec is AES-GCM-128 which is perfectly fine.

I understand the need for backward compatibility here, but if customers are still running Remote Access VPN software (which is obviously security-oriented) that is so old it does not support AES or SHA256/SHA384, then they deserve to get broken.

[the_rock]

Agree 100%

[Alex-]

In all fairness, I would have preferred to have these settings in the Remote Access Community, like Star/Mesh VPN instead of being hidden in Global Properties.

Experience Check Point administrators will know to go there, it will be much less obvious for newcomers.

[the_rock]

I could not agree more. I cant even count number of times I mentioned that exact thing in CP meetings.

Andy

[JozkoMrkvicka]

Within R82 homepage (sk181127), there is one of key new capability mentioned:

"For future-proofing, R82 enables NIST-approved Kyber (ML-KEM) encryption to protect today’s VPN traffic against future quantum computing-based hacking."

Much better would be to modify that statement to include only S2S VPN traffic while C2S (RemoteAccess) is still not properly protected by default.

But at least R82 now supports IKEv2 for Remote Access VPN...

[PhoneBoy]

From what I'm hearing, the next maintrain (R82.10) is expected to include multiple improvements to Remote Access, including at least one feature that has been requesting for a LONG time 🙂
I assume some of the goodness we brought to S2S VPN will also be included.

In any case, I'm with the various folks on this thread that the default algorithms for Remote Access are...not optimal.
I'll see what I can find out about it.

[aloish]

dh key exchange I still see in R81.20 goes up to dh-14, in R82 as @the_rock shows there were some important dh groups added.
No excuse to a security vendor to have only low encryption and key exchange algorithms.

Maybe again some extra tricks needed to add higher dh-groups like for site-to-site vpn Defining Advanced Diffie-Hellman Groups for IKE in Site-to-Site VPN but the sk excluded RAS and no hint about any sk for RAS.

[the_rock]

Even in GA version, its exactly same as in EA, no difference. But as Phoneboy said, lets hope in R82.10. we see improvements 🙂

Andy

[Lesley]

Agree I see many clients that make this mistake, the option is to hidden and many do not know that 3DES is bad for performance and security. There is no reason to even have this option in the first place.