Thu. Nov 26th, 2020

Discovered Artifacts in Decrypted HTTPS

Laptop, Raspberry Pi, PolarProxy, Internet ASCII

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:

“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
“distributionId”: “canonical”,
“distributionVersion”: “1.0”,
“partnerId”: “ubuntu”,
“distributor”: “canonical”,
“distributorChannel”: “ubuntu”,
“partnerNames”: [
“memoryMB”: 3943,
“virtualMaxMB”: null,
“count”: 1,
“cores”: 1,
“vendor”: “GenuineIntel”,
“family”: 6,
“model”: 42,
“stepping”: 7,
“l2cacheKB”: 256,
“l3cacheKB”: 4096,
“speedMHz”: null,
“extensions”: [
“name”: “Linux”,
“version”: “5.0.0-31-generic”,
“locale”: “en-US”
“model”: null,
“revision”: null,
“type”: null
“model”: null,
“revision”: null,
“type”: null
“model”: null,
“revision”: null,
“type”: null

“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

“compositor”: “basic”,
“status”: “unavailable”
“status”: “blocked-vendor-unsupported”
“status”: “opt-in”

“appleModelId”: null
“blocklistEnabled”: true,
“e10sEnabled”: true,
“e10sMultiProcesses”: 8,
“telemetryEnabled”: false,
“locale”: “en-US”,
“requestedLocales”: [
“availableLocales”: [
“appLocales”: [
“systemLocales”: [
“regionalPrefsLocales”: [
“acceptLanguages”: [
“channel”: “release”,
“enabled”: true,
“autoDownload”: false
“browser.cache.disk.capacity”: 1048576,
“”: “SE”,
“”: false,
“network.trr.mode”: 2
“effectiveContentProcessLevel”: 4
“addonCompatibilityCheckEnabled”: true,
“isDefaultBrowser”: false,
“defaultSearchEngine”: “google”,
“name”: “Google”,
“loadPath”: “[distribution]/searchplugins/locale/en-US/google.xml”,
“origin”: “default”,
“submissionURL”: “”

“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<!–X-Proxy-Origin HTTP header in NetworkMiner–>

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?

Facebook Share on Facebook  Twitter Tweet  Reddit Submit to