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.

[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.