Tag Archives: SSL Decryption

Palo Alto Networks NGFW “SSL Inbound Inspection” with different Certificate

I had a use case where I wanted to use the SSL Inbound Inspection on a Palo, but with a different X.509 certificate than the one on the server itself. That is: the backend server has its self-signed (or internal PKI-signed) certificate along with its hostname, while the decryption policy on the Palo uses a publicly trusted signed certificate for the same hostname. Just like a reverse proxy / load balancer / WAF.

TL;DR: While it would be technically feasible, this configuration is not working. :(

Continue reading Palo Alto Networks NGFW “SSL Inbound Inspection” with different Certificate

Decrypting TLS Traffic with PolarProxy

This is a guest blog post by Erik Hjelmvik, an expert in network forensics and network security monitoring at NETRESEC.


PolarProxy is a transparent TLS proxy that outputs decrypted TLS traffic as PCAP files. PolarProxy doesn’t interfere with the tunnelled data in any way, it simply takes the incoming TLS stream, decrypts it, re-encrypts it and forwards it to the destination. Because of this PolarProxy can be used as a generic TLS decryption proxy for just about any protocol that uses TLS encryption, including HTTPS, HTTP/2, DoH, DoT, FTPS, SMTPS, IMAPS, POP3S and SIP-TLS.

PolarProxy is primarily designed for inspecting otherwise encrypted traffic from malware, such as botnets that use HTTPS for command-and-control of victim PCs. Other popular use cases for PolarProxy is to inspect encrypted traffic from IoT devices and other embedded products or to analyze otherwise encrypted traffic from mobile phones and tablets. The fact that PolarProxy exports the decrypted traffic in a decrypted format without any TLS headers also enables users to inspect the decrypted traffic with products that don’t support TLS decryption, such as intrusion detection and network forensics products like Suricata, Zeek and NetworkMiner.

Continue reading Decrypting TLS Traffic with PolarProxy

Idea: On-the-Fly TLSA Record Spoofing

It is quite common that organizations use some kind of TLS decryption to have a look at the client traffic in order to protect against malware or evasion. (Some synonyms are SSL/TLS interception, decryption, visibility, man-in-the-middle, …) Next-generation firewalls as well as proxies implement such techniques, e.g., Palo Alto Networks or Blue Coat. To omit the certificate warnings by the clients, all spoofed certificates are signed by an internal root CA that is known to all internal clients. For example, the root CA is published via group policies to all end nodes.

But what happens if the DNS-based Authentication of Named Entities (DANE) is widely used within browsers? From the CA perspective, the spoofed certificates are valid, but not from the DANE perspective. To my mind we need something like an on-the-fly TLSA record spoofing technique that works in conjunction with TLS decryption.

Continue reading Idea: On-the-Fly TLSA Record Spoofing