The Check Point multi-portal provides connectivity for SSL VPN connections, WebUI (GAIA web portal) as well as end-users using the Check Point Mobile client.
Which ciphers you are using becomes incredibly important during an audit, for demonstrating compliance, or even just “best practice.”
A fresh gateway is going to have (as of this writing) 23 ciphers to choose from. Most of which you DO NOT want to use, and are present for backwards compatibility (in some cases these are outdated and basically compromised ciphers).
A great resource is ciphersuite.info. This site will allow you to look up ciphers and compare them to others.
I linked all 23 ciphers which are present on a Check Point gateway to ciphersuite.info :
By default, all of the ciphers above are enabled on an R81.10/R81.20 gateway.
According to the FBI (and other sources) it is currently a good practice to disable ciphers using any of the following:
“RSA, AES-CBC, SHA, MD5, EDH, DHE, null, DES, 3DES, RC4, EXPORT-Strength Ciphers.”
“Only use TLS protocols TLS 1.2 or TLS 1.3 with non-compromised ciphers/authentication only.”
As of the day of this post, only 6 (of the 23) should be used in production:
According to my testing, of the six only two elliptical curve RSA ciphers actually work on R81.20 without having to create an ECDSA certificate:
So the quick answer is to only use the two directly above, which automatically have a certificate generated and installed on the gateways. There is no need to generate a separate certificate, and have it imported in SmartConsole (different article).
In Part 2, I will show you how to limit the ciphers to only the ones that are secure and the ones that actually work.
In Part3, I will show you how to generate elliptical curve certificates using ECDSA (as opposed to RSA).