In the last few months we’ve talked quite a bit about malware threats, and how viruses like Cryptolocker and Sirefef have crippled unprepared companies in the past year. PAR3 recommends a layered defense strategy of Antivirus, Firewall, Patching, Web Filtering, and User Training to combat these threats.
A key component of a layered defense is your firewall. The firewall is the gateway to and from your network. It can (and should!) provide services such as Antivirus, Web Filtering, Intrusion Prevention, Application Control, and Data Leak Prevention. The weak spot we’re discussing today is the major hole in scanning traffic at the firewall — SSL connections.
In the past, SSL connections weren’t a big threat because for the most part, the only encrypted traffic on the internet was financial transactions and other e-commerce. But over time, more and more websites have become completely encrypted. Facebook and Twitter have used SSL connections for years and last year Google also switched complete encryption for all web searches. Before very long most websites will use SSL for better user privacy.
If someone shares a virus or infects an SSL-encrypted website, your users will be able to download it without the firewall ever knowing it’s there.
“SSL” stands for secure socket layer. It’s a level of encryption designed to keep information private between the sender and its destination, and insure no one in between can read it. As part of this encryption process, each website is issued a unique SSL certificate. When an end user opens information sent from a website, the encryption routine should match the unique SSL certificate assigned to that website, or else a “certificate error” like this one will appear.
This the primary purpose of using SSL, and the reason certificate errors should not be ignored. What your browser is trying to tell you is there is potentially someone eavesdropping on your transaction, which could be very bad if it’s financial information.
However a firewall protects you by ‘scanning’ the data, checking for viruses or bandwidth issues, before passing it along to the end user. When data comes from an SSL connection, most firewalls can impersonate the end user and decrypt the data. However, the problem arises when the firewall then needs to re-encrypt the data before sending it to the end user. The firewall is forced to re-encrypt using their own SSL certificate, since they don’t have access to the website original – which means the end user will get a certificate error, warning that the encryption routine has been tampered with.
How can we protect our network while still letting the users know that their traffic is private and secure on the internet? This is the tough question we find ourselves facing today.
There is a way to set up your security appliance to unobtrusively scan SSL connections. We can accomplish this by getting your users to trust your firewall as a valid certification authority. In this example I will be using a Fortigate security appliance.
1) First, enable the SSL Inspection on the Fortigate Firewall Policy
2) Next, go to a computer behind the firewall, open Internet Explorer, and navigate to any https page (in this example we’ll use https://www.google.com).
– You will be greeted with a certificate error. Choose to continue anyway.
– Once the page loads, you can click on the error and choose View Certificates and go to the Certification Path.
– As you can see, this is a valid certificate for www.google.com, however it has been issued by Fortigate CA instead of a real certificate authority.
3) Click on the Foritgate CA Certificate (or whatever your root certificate happens to be).
– Choose View Certificate.
– Click on the Details Tab, and choose “Copy to File”
– If you don’t see the Copy to File button then you need to add the site you are using to your Trusted Sites, refresh the page and try again.
– After you click the “Copy to File” button you will get a short wizard. You can stick with the default DER format to export the certificate, but you must choose a place to put it.
Now you have a copy of your firewall’s root certificate.
4) Next you need to take this certificate, and deploy it to all your users. The easiest way to do this is through Group Policy.
– Go to your server and open your Group Policy Management tool.
– Create a new Policy and link it to the root of your domain.
– Open the new group policy and navigate to the following location: Policies\Windows Settings\Security Settings\Public Key Policies.
– Right-click on “Trusted Root Certification Authorities” and choose import.
– Select the certificate you exported earlier, and save and close.
One small caveat is that this will only work for Internet Explorer and Chrome. Firefox uses its own Trusted Certificate store that you will have to import the certificate to. We have found a few ways of centrally deploying certificates to firefox but they are complex and require custom scripting based on your environment. Contact us for further info.
[contact-form-7 id=”6092″ title=”Contact form 1″]