Secure Sockets Layer also known as SSL is getting more and more common. People are getting more concerned about their security on the internet, and how they are supposed to get secured. We see many common applications now turning in to HTTPS as twitter, facebook, gmail by deafult/supported. It gives the user a certain amount of privacy. Unfortunately SSL is also used as evasion tactics by hackers and cyber criminals. It’s used to hide the activity within the ssl package. This is why we are interested in decrypting ssl packages for visibility controlling and granular security. I will show in an example later how a virus could infect a computer and not get detected if it is enclosure by ssl encryption.
This is where the Palo Alto comes in. A handful of networking vendors inspect SSL encrypted HHTP traffic (HTTPS). This firewall goes further by inspecting compliant SSL traffic, no matter the protocol encapsulated by it. The firewall understands SSL and can unwrap the encapsulation to expose the underlying protocol and applications.
There are two types of decryption Inbound SSL decryption and Outbound SSL decryption:
Inbound SSL decryption:
In this case, the administrator imports a copy of the protected serve’s certificate and key. Once the ssl server certificate is loaded on the firewall, and a ssl decryption policy is configured for the inbound traffic, the device will be able to decrypt and read the traffic as it forwards it on.
Outbound SSL decryption:
In this case, the firewall proxies the outbound connections. It intercepts the outbound requests, and generates a certificate on the fly for the site that the client was going to.
Setup configuration steps
- Install the proper certificates on the firewall
- Configure SSL decryption rules
- Enable SSL decryption noticiation page (optional)
- Export the certifcate and import it with GPO to client computers
- Commit your changes, test the decryption
1. The first thing we would like to do is to install and manage the certificate we would like to use. Navigate Device > Certificates and generate a new self signed Certificate, be sure to activate CA,Forward Trust Certificate, Untrust and Trusted Root CA:
2. Navigate Policys > Decryption.
Here are some suggestions for configuring SSL decryption rules:
- Do not decrypt known-good SSL connections, such as connections between internal users and internal servers.
- Do not decrypt the following URL categories, as users may consider this to be an invasion of privacy:
- Financial services
- Do not decrypt URL category “unknown”, as it includes many non-HTTP applications, some of which will not correctly SSL decrypt.
- Do not decrypt URL category “computer-and-internet info”, as it includes the Windows Update service, which requires specific server certificates from Microsoft. (As an alternative, you can create a rule that does not decrypt traffic to the IP addresses of the Microsoft Update servers.)
- Do not decrypt applications where the server requires client-side certificates.
- Be precise in your source and target zones—do not use “any”
- You should implement rules in a phased approach. Start with very specific rules for decryption, and monitor the typical number of SSL connections being decrypted by the device (refer to Appendix A for those commands). You want to make sure you do not exceed the maximum number of concurrent SSL decrypted sessions that is supported on a device. Over time, you can add additional decryption rules.
3. Enable response page:
The user can be notified that their SSL connection is going to be decrypted using the response page found on the Device tab -> Response Pages screen. Enable this feature if you choose. This page can be exported, edited via an html editor, and imported to give company-specific information. Here is an example of the default page:
4. Export the certificate from palo and import it to clients computers using GPO. Make a new computer based gpo, Policies > Windows > Security Settings > Public Key > Trusted Root Cert Authorities. Make it available for those computers/user groups that you would like to manage ssl decrypt on.
To test outbound decryption:
Make sure that on your outbound policy, you are alerting for any viruses found. Also enable packet capture on that anti-virus security profile. Commit any changes you made.On a PC internal to the firewall, go to www.eicar.org. In the top-right hand corner, you will see: Click on “anti-malware testfile”. In the screen that appears, scroll down to the bottom.
Download the eicar test virus using http. Any of the 4 files shown here will be detected. Go to the Monitor tab -> Threat log, and look for the log message that detects the vicar file. Click on the green down arrow in the left-hand column. This brings up a view of the packets that were captured.
Also click on the magnifying class in the far left column. Scroll to the bottom, and look for the field “SSL Decryption.” You will see that the session was not decrypted.
Now that you have proven that your policy will detect viruses in unencrypted traffic, you will now try detecting the virus in encrypted traffic. Go back to the www.eicar.org downloads page. This time use SSL to download the test virus. If you get a certificate error, you can still proceed with downloading the file. Examine the Threat logs. The virus should have been detected, since the SSL connection was decrypted. You will see a log message that shows Eicar was detected in web browsing on port 443. You can also view the packet capture by clicking on the green down arrow. To the left of that log entry, click on the magnifying class. Scroll to the bottom, and look for the field “SSL Decrypted”. The value should say “yes”.
Therefore, the virus was successfully detected in an SSL-encrypted session. To test the “no-decrypt” rule, first determine what URLs fall into the financial services, shopping, or health and medicine categories. Go tohttp://www.brightcloud.com/testasite.aspx and enter various URLs that you believe fall into those categories. Once you have found some web sites that are classified into categories that will NOT be decrypted, use a browser to go to those sites using https. You should not see a certificate error when you go to those sites. The web pages will be displayed properly. If you look at the traffic logs, the sessions will show application SSL going over port 443, as expected.
Summary As with any enterprise security policy, individual policy decisions will vary as organizations match their security controls to their unique needs and tolerances for risk. However, as more and more critical traffic becomes encrypted by SSL, enterprises will increasingly be forced to find ways to decrypt high-risk traffic without the performance impacts of decrypting ALL traffic. The simple guidelines discussed above simply illustrate a policy driven model that can enable an enterprise to strike the appropriate balance and retain full visibility and control over traffic even when encrypted.