SNX vs IPSEC Security

[Shahar_Grober]

Hi,

Are there any security risk created by using SNX technology 

I am forced to use SNX due to some Linux users.

I want to know what are the security risks that this technology creates vs. IPSEC 

Some thoughts:

1. You need to open a portal to the internet 

2. you use browsers  which can be vulnerable to MiTM attacks and other vulnerabilities 

3. which encryption algorithms are used with SSL - does CP update the encryption algorithms

4. client maintenance and troubleshooting with different OS/Browsers (Some of them still needs Java) 

[G_W_Albrecht]

Legacy SNX uses the IP Sec Blade only, not MAB SSL VPN - so you better explain that you want to use MAB portal for Linux users ! For Linux CLI access, see Connection to VPN server from Linux with SecureID

To compare security features, the best place is sk67820: Check Point Remote Access Solutions !

[Shahar_Grober]

Hi Gunthar,

Please refer to my questions instead of throwing SK's up in the air

[Wolfgang]

Hello Shahar,

at first you have to decide to use SNX only or SNX via MobileAccessBlade.

With MOB more features are available, like accessing fileshare, ActiveSync, WebApplication etc.

To your question, I'll answer for SNX only mode:

1. You need to open a portal to the internet 

>>> Yes, you open a portal on your gateway on Port 443, but only SNX (SSL extender is running there).

2. you use browsers  which can be vulnerable to MiTM attacks and other vulnerabilities 

>>> You have to use browser they are supporting JAVA " SSL Network Extender requires that Java is installed on the endpoint computer"

3. which encryption algorithms are used with SSL - does CP update the encryption algorithms

>>> You can see the supported encryption algorithm in SmartConsole global properties => Remote Access => SSL network extender => excryption (AES, 3DES). This changed from some releases. 

4. client maintenance and troubleshooting with different OS/Browsers (Some of them still needs Java) 

In my opinion this is a nightmare. If you have a client configuration that works, never change it. SNX is really nice, but with every browser or Java update you are starting a new long support session to get it running.

Shahar, as I read from your reply to Guenther you don't like sk articles, but I think for better understanding you should have a look at SSL extender and Mobile Access Portal and Java Compatibility - New Mobile Access Portal Agent technology

Wolfgang

[PhoneBoy]

There is a CLI-only client for Linux, but it's limited to 3DES/RC4: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

The browser-based clients are updated with modern ciphers the same as on Windows. 

The other risks you mention don't seem all that different from any other end user use of Linux/Windows (MITM possibility, keeping software up to date), but maybe I'm missing something.

[Jerry]

just my 5 cents - the only risk with all above mentioned is ... "Java".
there are no other indicators whatsoever except, SSL is much faster than IPSec (tcp vs udp) and is more flexible for Linux/Apple/Mobile users. That's all. All the factors you've been asking specifically are valid when designing solution for specific use or in a TELCO not ENTERPRISE environment. In my humble opinion SNX/MAB solution are very robust for again, all depends on the scale and purpose of the usage (users wise).

[Timothy_Hall]

> SSL is much faster than IPSec (tcp vs udp)

In the real world yes.  In theory IPSec should be faster than HTTPS/TLS as there is no in-depth error checking on the outer ESP packet header, and it is assumed the tunneled protocol will handle any packet loss/out of order issues.  Considering that the tunneled protocol is usually TCP this assumption is correct, and avoids the extra overhead of doing TCP twice.  However given the speed of systems & networks these days that extra TCP overhead is pretty negligible.

HTTPS/TLS is incurring the extra overhead of doing TCP twice, BUT is much more tolerant of adverse networking conditions that happen in the real world.  Low MTUs and fragmentation don't really hurt the performance of HTTPS/TLS, but massively screws up the performance of IPSec and lead to nasty hacks like TCP MSS Clamping that can get even more complicated when SecureXL is involved.  Intervening NAT between the two peers really doesn't affect HTTPS/TLS much, but forces the double encapsulation of IPSec traffic into UDP 4500 datagrams via NAT-T which incurs a ridiculous amount of additional overhead.

[Shahar_Grober]

Thanks for the reply guys,

leaving performance aside, my concerns are due to the fact that SNX has too many moving parts which I don't have control of (browsers, portals, Java updates, thin clients). My first choice will always be to go with a fixed client. It works flawlessly once you start running with it. Security wise, as far as I understand, SNX might be good as long as the browser or the Java are not vulnerable.

Another point is that SNX is more than a hassle to provision than IPSec but with Linux users, I don't have a lot of choices. The best solution in my point of view would be to support a Linux client (Open VPN style) which supports SSL VPN, but I have already discussed it in a separate thread