Today we have the answer to the question – Without SSL decryption how many threats/attempted vulnerability exploits/other bad stuff will I miss that are coming from the internet at my internally hosted (externally published) web sites and services?
To run some simple tests (which will be detected as malicious attacks) I’m going to be running the Nessus scanner against a website behind a Palo Alto Networks Next Generation Firewall, while we won’t get the same results that might be seen from a ‘determined attacker’ we will get an idea of how things look from the standpoint of a ‘casual attacker’.

In short the answer is you’ll miss a lot – without decryption of traffic coming at your own web servers it’s pretty much impossible to detect attacks (with some minor exceptions) that are hiding inside HTTPS, either way let’s see how it’s done…

Kit list for this testing:

  • An ‘internal’ web service, in this case the web console for PRTG Network Monitor (running on Windows Server)
  • A Palo Alto Networks Next Generation Firewall – a PA-850 running PAN-OS 8.1 with a full suite of licences
  • The Nessus vulnerability scanner

Both the firewall and the web service have been configured to run TLS1.2 with the private key for the certificate on both (which allows the firewall to decrypt the traffic without breaking connections) and the latest firmware/security updates have been applied across the board.

To have a closer look at the configuration on PRTG server and NGFW take a look at the screenshots below.

I ran the testing in two phases, first with decryption enabled and then without decryption enabled. Before each test I cleared the Threat, URL and Data logs on the firewall.

The Results

The results turned out as expected, when running without decryption only threats on port 80 (over plain text) were detected – although this might allow for blocking by source IP it’s far from the best solution.
With decryption turned on it immediately lit up all the traffic inside HTTPS with 236 threats being detected – of which 169 were detected as medium/high/critical and in turn would have been blocked by a firewall configured to the best practice templates.

Number of threats detected with decryption: 448 (236 over HTTPS)
Number of threats detected without decryption: 226 (0 over HTTPS)

With decryption turned on threats hiding inside HTTPS traffic were very easy to find.

If you are interested have a look at the Excel files below which shows the detected scans from the Nessus server.

Decryption Off

Decryption On

The ultimate question – should I enable inbound decryption?

Yes; but, it’s important to remember that security always needs to be a layered approach – here we’ve proven beyond doubt that by enabling inbound decryption more threats can be detected and blocked. Things get more complicated with very specific attacks that might try and exploit specific features of a website/web service (like SQL injection and whatnot) – here you have to look beyond the firewall and towards ‘web application firewalls’ which dials this kind of security up even further. For your more determined attackers you will have to look even further beyond these edge protections, here it’s worth a look at the MITRE ATT&CK Matrix and other similar frameworks.

VN:F [1.9.22_1171]
Thumbs up if this article helped you 🙂
Rating: +3 (from 3 votes)
Detecting threats with inbound SSL (TLS) decryption, 100% based on 3 ratings

2 Responses to Detecting threats with inbound SSL (TLS) decryption

Leave a Reply

Your email address will not be published. Required fields are marked *