NETRESEC Network Security Blog

Discovered Artifacts in Decrypted HTTPS

We released a PCAP file earlier this year, which was recorded as part of a live TLS decryption demo at the CS3Sthlm conference. The demo setup used PolarProxy running on a Raspberry Pi in order to decrypt all HTTPS traffic and save it in a PCAP file as unencrypted HTTP.

Laptop, Raspberry Pi, PolarProxy, Internet ASCII

This capture file was later used as a challenge for our twitter followers, when we made the following announcement:

The capture file released in this blog post contains a few interesting things that were captured unintentionally. Can you find anything strange, funny or unexpected in the pcap file? (1/2)

Followed by this message:

The person to submit the most interesting answer wins a “PCAP or it didn’t happen” t-shirt. Compete by including your discovery in a retweet or reply to this tweet, or in an email to info(at) We want your answers before the end of January. (2/2)

We'd like to thank everyone who submitted answers in this challenge, such as David Ledbetter, Christoffer Strömblad, RunΞ and Chris Sistrunk.

We're happy to announce that the winner of our challenge is David Ledbetter. Congratulations David!

So what were the interesting thing that could be found in the released capture file? Below is a short summary of some things that can be found.

Telemetry data sent to

A surprising amount of information about the Firefox browser was sent to, including things like:

  • Active browser addons
  • Active browser plugins
  • Firefox profile creation date
  • Browser search region
  • Default search engine
  • Regional locales
  • Screen width
  • Screen height
  • CPU vendor, family and model
  • HDD model, revision and type
  • Installed RAM
  • Operating system
  • Etc..

Here's an excerpt showing a part of the data sent to Mozilla:

"build": { "applicationId": "{ec8030f7-c20a-464f-9b0e-13a3a9e97384}", "applicationName": "Firefox", "architecture": "x86-64", "buildId": "20191002194346", "version": "69.0.2", "vendor": "Mozilla", "displayVersion": "69.0.2", "platformVersion": "69.0.2", "xpcomAbi": "x86_64-gcc3", "updaterAvailable": false }, "partner": { "distributionId": "canonical", "distributionVersion": "1.0", "partnerId": "ubuntu", "distributor": "canonical", "distributorChannel": "ubuntu", "partnerNames": [ "ubuntu" ] }, "system": { "memoryMB": 3943, "virtualMaxMB": null, "cpu": { "count": 1, "cores": 1, "vendor": "GenuineIntel", "family": 6, "model": 42, "stepping": 7, "l2cacheKB": 256, "l3cacheKB": 4096, "speedMHz": null, "extensions": [ "hasMMX", "hasSSE", "hasSSE2", "hasSSE3", "hasSSSE3", "hasSSE4_1", "hasSSE4_2", "hasAVX", "hasAES" ] }, "os": { "name": "Linux", "version": "5.0.0-31-generic", "locale": "en-US" }, "hdd": { "profile": { "model": null, "revision": null, "type": null }, "binary": { "model": null, "revision": null, "type": null }, "system": { "model": null, "revision": null, "type": null } }, "gfx": { "D2DEnabled": null, "DWriteEnabled": null, "ContentBackend": "Skia", "Headless": false, "adapters": [ { "description": "llvmpipe (LLVM 8.0, 256 bits)", "vendorID": "0xffff", "deviceID": "0xffff", "subsysID": null, "RAM": 3942, "driver": null, "driverVendor": "mesa/llvmpipe", "driverVersion": "", "driverDate": null, "GPUActive": true } ], "monitors": [ { "screenWidth": 681, "screenHeight": 654 } ], "features": { "compositor": "basic", "gpuProcess": { "status": "unavailable" }, "wrQualified": { "status": "blocked-vendor-unsupported" }, "webrender": { "status": "opt-in" } } }, "appleModelId": null }, "settings": { "blocklistEnabled": true, "e10sEnabled": true, "e10sMultiProcesses": 8, "telemetryEnabled": false, "locale": "en-US", "intl": { "requestedLocales": [ "en-US" ], "availableLocales": [ "en-US", "en-CA", "en-GB" ], "appLocales": [ "en-US", "en-CA", "en-GB", "und" ], "systemLocales": [ "en-US" ], "regionalPrefsLocales": [ "sv-SE" ], "acceptLanguages": [ "en-US", "en" ] }, "update": { "channel": "release", "enabled": true, "autoDownload": false }, "userPrefs": { "browser.cache.disk.capacity": 1048576, "": "SE", "": false, "network.trr.mode": 2 }, "sandbox": { "effectiveContentProcessLevel": 4 }, "addonCompatibilityCheckEnabled": true, "isDefaultBrowser": false, "defaultSearchEngine": "google", "defaultSearchEngineData": { "name": "Google", "loadPath": "[distribution]/searchplugins/locale/en-US/google.xml", "origin": "default", "submissionURL": "" } }, "profile": { "creationDate": 18183, "firstUseDate": 18183 }

You can use the following Wireshark display filter to find all the data sent to Mozilla:

http.request.method eq POST and contains telemetry

Public IP Revealed in PCAP

The client's IP address was, which is part of the RFC 1918 192.168/16 private address space. It's therefore safe to assume that the client was behind a NAT (the client was in fact behind a double NAT). However, we noticed that the public IP of the client was revealed through multiple services in the captured network traffic. One of these services is the advertising exchange company AppNexus (, which sent the client's public IP address in an X-Proxy-Origin HTTP header.

X-Proxy-Origin HTTP header in Wireshark

You can use the following Wireshark/tshark display filter to find X-Proxy-Origin headers:

http.response.line matches "x-proxy-origin" or matches "x-proxy-origin"

We are using the "matches" operator here instead of "contains" or "==" because we want to perform case insensitive matching. You might also notice that we need a completely different display filter syntax to match HTTP/2 headers compared to what we are used to with HTTP/1.1.

Monty Python "Majestik møøse" reference in reddit x-header

The reddit server sends an HTTP/2 header called "x-moose" with a value of "majestic".

x-moose 1 : majestic header from reddit

This header refers to the opening credits of Monty Python and the Holy Grail.

Wi nøt trei a høliday in Sweden this yër?

Posted by Erik Hjelmvik on Tuesday, 17 March 2020 09:00:00 (UTC/GMT)

Tags: #HTTP/2 #http2 #TLS #decrypt #TLSI #PolarProxy #NetworkMiner #Wireshark #CS3Sthlm #CS3 #Forensics #PCAP

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

Reverse Proxy and TLS Termination

PolarProxy is primarily a TLS forward proxy, but it can also be used as a TLS termination proxy or reverse TLS proxy to intercept and decrypt incoming TLS traffic, such as HTTPS or IMAPS, before it is forwarded to a server. The proxied traffic can be accessed in decrypted form as a PCAP formatted data stream, which allows real-time analysis of the decrypted traffic by an IDS as well as post incident forensics with Wireshark.

PolarProxy version 0.8.15 and later can import an existing X.509 server certificate (aka leaf certificate or end-entity certificate) in order to perform the TLS decryption using a valid certificate signed by a trusted certificate authority. If no server certificate is provided, then PolarProxy falls back to generating server certificates on the fly and signing them with its own root CA certificate.

There are two principal ways to run PolarProxy as a reverse proxy, either as a TLS termination proxy or as a reverse proxy that decrypts and re-encrypts the traffic.

PolarProxy as a TLS Termination Proxy

TLS Termination Proxy

The TLS termination proxy mode is useful in order to offload the task of performing TLS encryption to PolarProxy instead of doing the decryption on the web server. This mode can also be used when the proxied services don’t support TLS encryption, such as legacy web servers or servers hosting other unencrypted services that you want to secure with TLS.

The following command sequence shows how to create a Let’s Encrypt SSL certificate, convert it to the PKCS#12 format, and load the server certificate into PolarProxy to terminate incoming HTTPS connections. In this setup PolarProxy decrypts the TLS traffic and relays the HTTP traffic to the web server on TCP port 80.

sudo certbot certonly --manual --preferred-challenges dns -d,

sudo openssl pkcs12 -export -out /etc/example.p12 -inkey /etc/letsencrypt/live/ -in /etc/letsencrypt/live/ --passout pass:PASSWORD

sudo mkdir /var/log/TlsTerminationProxy/

sudo ./PolarProxy --terminate --connect --nosni --servercert, -p 443,80,80 -o /var/log/TlsTerminationProxy/

Here’s a breakdown of the arguments sent to PolarProxy:

  • --terminate : Terminate incoming TLS sessions and forward proxied traffic in unencrypted form.
  • --connect : Forward all proxied traffic to instead of connecting to the host name provided in the SNI extension of the TLS ClientHello message.
  • --nosni : Treat incoming TLS sessions that don’t define a host name with the SNI extension as if they wanna to connect to “”.
  • --servercert, : Use the server certificate “/etc/example.p12” for incoming connections to “” and “”.
  • -p 443,80,80 : Listen on TCP port 443, save decrypted traffic in PCAP file as if it was directed to port 80, forward decrypted traffic to port 80.
  • -o /var/log/TlsTerminationProxy/ : Save decrypted traffic to hourly rotated PCAP files in “/var/log/TlsTerminationProxy/”.

PolarProxy is a generic TLS proxy that doesn’t care what application layer protocol the TLS tunnel carries. So if you want to terminate the TLS encryption of incoming IMAPS sessions as well, then simply append an additional argument saying “-p 993,143,143” to also forward decrypted IMAP sessions to This method can be used in order to wrap almost any TCP based protocol in a TLS tunnel, which can be useful for privacy reasons as well as to prevent network monitoring tools from detecting the actual application layer protocol.

PolarProxy as a Reverse TLS Proxy

Reverse TLS Proxy

There are setups for which it is preferable to also encrypt the internal sessions between PolarProxy and the final server. One such setup is when the server is hosting a web service with support for the HTTP/2 protocol, which in practice always uses TLS. Luckily PolarProxy is designed to decrypt and re-encrypt proxied traffic while also forwarding important TLS parameters, such as ALPN and SNI, between the internal and external TLS sessions.

To use TLS encryption on the inside as well as outside of PolarProxy, simply do as explained in the previous TLS termination section, but remove the “--terminate” argument and change the port argument to “-p 443,80,443” like this:

sudo ./PolarProxy --connect --nosni --servercert, -p 443,80,443 -o /var/log/ReverseTlsProxy/

PolarProxy will save the decrypted traffic as cleartext HTTP (or HTTP/2) to PCAP files in the “/var/log/ReverseTlsProxy/” directory.

Real-Time Analysis of Decrypted Traffic

Both the external (client-to-proxy) and internal (proxy-to-server) TCP sessions, in the reverse TLS proxy example above, are encrypted with TLS. This prevents passive network security monitoring tools, such as IDSs, DPI and DLP appliances, from analyzing the application layer data being sent and received. The PCAP files written to “/var/log/ReverseTlsProxy/” can be a valuable forensic asset when investigating an incident, but a real-time stream of the decrypted data is needed in order to swiftly detect and alert on potential security breaches and other incidents.

PolarProxy’s “--pcapoverip” option can be used to provide such a real-time stream of the decrypted data passing through the proxy. This data can easily be sent to a network interface using tcpreplay, as explained in our blog post “Sniffing Decrypted TLS Traffic with Security Onion”.

Security Considerations

The examples shown in this blog post all run PolarProxy with root privileges using sudo, which can be dangerous from a security perspective. PolarProxy is actually designed to be run without root privileges, but doing so prevents it from listening on a port below 1024. Luckily, this issue can easily be overcome with a simple port forwarding or redirect rule. The following iptables redirect rule can be used if PolarProxy is listening on TCP port 20443 and incoming HTTPS request are arriving to the eth0 interface of the proxy:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to 20443

PolarProxy does not support loading settings from a config file. The password for the PKCS12 certificate will therefore need to be supplied on the command line, which can make it visible from a process listing. If this is a concern for you, then please consider using “hidepid” to hide processes from other users. You can find instructions on how to use hidepid in hardening guides for Debian, Arch, SUSE and most other Linux flavors.

Posted by Erik Hjelmvik on Thursday, 12 March 2020 15:45:00 (UTC/GMT)

Tags: #PolarProxy #TLS #SSL #PCAP #decrypt #HTTPS #HTTP #HTTP/2 #http2 #IMAPS #decrypt

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

RawCap Redux

RawCap A new version of RawCap has been released today. This portable little sniffer now supports writing PCAP data to stdout and named pipes as an alternative to saving the captured packets to disk. We have also changed the target .NET Framework version from 2.0 to 4.7.2, so that you can run RawCap on a modern Windows OS without having to install a legacy .NET Framework.

Here’s a summary of the improvements in the new RawCap version ( compared to the old version (

  • Uses .NET 4.7.2 instead of 2.0
  • Support for writing to stdout
  • Support for writing to named pipes
  • Large (64 MB) ring buffer to prevent packet drops
  • Automatic firewall configuration

Out of the software we develop and maintain here at Netresec, NetworkMiner is the most popular one. But you’re probably not aware that RawCap is our second most popular tool in terms of downloads, with around 100 unique downloads every day. RawCap started out as just being a quick hack that we released for free to the community in 2011 without expecting it to gain much attention. However, it quickly gained popularity, maybe due to the fact that it’s just a tiny .exe file and that it doesn’t require any external libraries or DLL’s to sniff network traffic (other than the .NET Framework).

RawCap embraces the Unix philosophy to do only one thing, and do it well. Thanks to RawCap’s simplicity we have only needed to make a few minor updates of the tool since its first release 9 years ago. However, today we’re finally adding some new features that have been requested by users over the years. One such feature is that RawCap now automatically creates a Windows firewall rule when the tool is started. Before this feature was introduced users would have to run wf.msc (i.e. the "Windows Defender Firewall with Advanced Security") and manually create an inbound rule to allow RawCap.exe to receive incoming traffic. Without such a firewall rule RawCap would only be able to capture outgoing traffic.

RawCap can be started in two different modes. Either as an interactive console application, or as a “normal” command line utility. Run RawCap.exe without any arguments, or simply double click the RawCap.exe icon to use the interactive mode. You will then be asked which interface to capture packets from and what filename you’d like to save them to.

Network interfaces:
0.    Local Area Connection
1.    Wireless Network Connection
2.   3G UMTS Internet
3.   VMware Network Adapter VMnet1
4.   VMware Network Adapter VMnet2
5.       Loopback Pseudo-Interface
Select network interface to sniff [default '0']: 1
Output path or filename [default 'dumpfile.pcap']:
Sniffing IP :
Output File : dumpfile.pcap
 --- Press [Ctrl]+C to stop ---
Packets     : 1337

The other alternative is to supply all the arguments to RawCap when it is started. Use “RawCap --help” to show which arguments you can use. You’ll need to use this mode if you want to write the captured traffic to standard output (stdout) or a named pipe, or if you want RawCap to automatically stop capturing after a certain time or packet count.

F:\Tools>RawCap.exe --help
NETRESEC RawCap version

Usage: RawCap.exe [OPTIONS] <interface> <pcap_target>
 <interface> can be an interface number or IP address
 <pcap_target> can be filename, stdout (-) or named pipe (starting with \\.\pipe\)

 -f          Flush data to file after each packet (no buffer)
 -c <count>  Stop sniffing after receiving <count> packets
 -s <sec>    Stop sniffing after <sec> seconds
 -m          Disable automatic creation of RawCap firewall entry
 -q          Quiet, don't print packet count to standard out

 0.     IP        :
        NIC Name  : Local Area Connection
        NIC Type  : Ethernet

 1.     IP        :
        NIC Name  : WiFi
        NIC Type  : Wireless80211

 2.     IP        :
        NIC Name  : Loopback Pseudo-Interface 1
        NIC Type  : Loopback

 3.     IP        :
        NIC Name  : Mobile 12
        NIC Type  : Wwanpp

Example 1: RawCap.exe 0 dumpfile.pcap
Example 2: RawCap.exe -s 60 localhost.pcap
Example 3: RawCap.exe \\.\pipe\RawCap
Example 4: RawCap.exe -q - | Wireshark.exe -i - -k

As you can see, running “RawCap.exe -s 60 localhost.pcap” will capture packets from localhost to a file called “localhost.pcap” for 60 seconds and then exit.

There are a couple of drawbacks with the new RawCap version though, it is a larger binary (48kB instead of 23kB) and it uses more CPU and RAM compared to the old version. We will therefore continue making the old RawCap version available to anyone who might need it.

Visit the RawCap product page to download this tool and learn more.

Posted by Erik Hjelmvik on Thursday, 30 January 2020 14:32:00 (UTC/GMT)

Tags: #Netresec #RawCap #sniffer #PCAP #named pipe #Wireshark #WiFi #loopback #

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:


NETRESEC on Twitter

Follow @netresec on twitter:


Recommended Books

» The Practice of Network Security Monitoring, Richard Bejtlich (2013)

» Applied Network Security Monitoring, Chris Sanders and Jason Smith (2013)

» Network Forensics, Sherri Davidoff and Jonathan Ham (2012)

» The Tao of Network Security Monitoring, Richard Bejtlich (2004)

» Practical Packet Analysis, Chris Sanders (2017)

» Windows Forensic Analysis, Harlan Carvey (2009)

» TCP/IP Illustrated, Volume 1, Kevin Fall and Richard Stevens (2011)

» Industrial Network Security, Eric D. Knapp and Joel Langill (2014)