PolarProxy 1.0.1 Released

PolarProxy 1.0.1

The new release of PolarProxy generates JA4 fingerprints and enables ruleset to match on specific decryption errors, for example to enable fail-open in case the TLS traffic cannot be decrypted and inspected.

JA4 Fingerprints

JA4 fingerprints provide several improvements over its JA3 predecessor. One advantage is that JA4 fingerprints have a human readable segment that allow humans (as well as computers) to instantly see important features in a client handshake, such as the TLS version and whether or not the SNI and ALPN extensions are used. JA4 is also resilient against TLS extension order randomization.

JA4 hash explained. Breakdown of Remcos JA4 hash t13i010400_0f2cb44170f4_5c4c70b73fa0

We added support for rule based matching of JA4 fingerprints in the previous release of PolarProxy. Such a JA4 rule can be used to have PolarProxy take different actions (block, intercept, bypass etc.) based on the JA4 fingerprint of the client’s TLS handshake.

This release additionally includes JA4 fingerprints in the flow metadata that PolarProxy writes to disk when the -f <file> argument is provided.

Flexible Handling of TLS Auth Failures

PolarProxy’s firewall rules now support using TLS authentication error codes as triggers. As an example, the ruleset fail-open.json attempts to inspect (decrypt and re-encrypt) all TLS traffic, except when the client has rejected the server’s certificate at least once during the past 60 seconds. More specifically, it only bypasses decryption if the reason for the rejection was either “bad certificate” or “unknown CA”.

{
  "name": "Inspect TLS with fail open for OpenSSL alerts", "version": "1.0.1", "rules": [
    {
      "active": true,
      "match": { "type": "nontls" },
      "action": { "type": "block" },
      "description": "Block non-TLS traffic"
    },
    {
      "active": true,
      "match": { "type": "decrypt_fail_errorcode", "expression": "0x0A000412", "period": 60, "count": 1 },
      "action": { "type": "bypass" },
      "description": "bad certificate"
    },
    {
      "active": true,
      "match": { "type": "decrypt_fail_errorcode", "expression": "0x0A000418", "period": 60, "count": 1 },
      "action": { "type": "bypass" },
      "description": "unknown CA"
    }
    ],
  "default": {
    "action": { "type": "inspect" },
    "description": "Attempt to inspect TLS traffic"
  }
}
Figure: PolarProxy fail-open.json ruleset

The specific error codes (here 0x0A000412 for “bad certificate” and 0x0A000418 for “unknown CA”) might differ between deployments, since they depend on the underlying TLS library of the PolarProxy machine. The specific values in this example are from a Linux deployment with OpenSSL 3.0.13 installed. Look for the “decrypt_fail_errorcode” messages that PolarProxy prints to stderr to find out what error codes your system is using. You can also run PolarProxy with -v (verbose) or -d (debug) to get even more information about the error codes.

Ruleset Reload on SIGHUP

A PolarProxy ruleset can now be updated on the fly without having to restart PolarProxy. Simply send a SIGHUP signal to PolarProxy, for example pkill -HUP PolarProxy, to have it reload the updated ruleset without affecting sessions that PolarProxy is currently proxying.

If PolarProxy is running as a systemd service, then adding

ExecReload=/bin/kill -HUP $MAINPID
to the unit file allows PolarProxy’s ruleset to be reloaded with:

sudo systemctl reload PolarProxy.service

.NET 8

The .NET version has been bumped from 6 to 8 in the 1.0.1 release, which provides better performance as well as long-term support. We've also bumped the System.Security.Cryptography.Xml library from version 4.5 to 9.0.

Posted by Erik Hjelmvik on Friday, 07 February 2025 10:10:00 (UTC/GMT)

Tags: #PolarProxy#JA4#fail-open

Short URL: https://netresec.com/?b=2523c96

X / twitter

X / Twitter: @netresec


Bluesky

Bluesky: @netresec.com


Mastodon

Mastodon: @netresec@infosec.exchange