# Intercepting and Decrypting Your Own HTTPS Traffic

## Important Legal and Technical Notice

**What this document covers:**
- ✅ Inspecting YOUR OWN traffic from YOUR OWN software on YOUR OWN computer
- ✅ Legally and technically sound methods using SSL/TLS interception
- ✅ Educational purposes for privacy research
- ✅ Complementing the master investigation in [[Foudry-Nuke-Monitoring#Executive Summary]]

**What this does NOT do:**
- ❌ Brute-force decrypt HTTPS (not possible with modern encryption)
- ❌ Intercept other people's traffic (illegal)
- ❌ Break into Foundry's servers (illegal)

**Legal basis:** You have the right to inspect data YOUR software sends from YOUR computer.

---

## Why You Can't Brute Force HTTPS

**Technical reality:**
- Modern TLS uses 2048-4096 bit RSA or 256-bit ECC keys
- Brute-forcing would take **billions of years** with current hardware
- Even nation-states with supercomputers cannot brute-force TLS
- Quantum computers (not yet practical) would still take months/years

**The only way to decrypt HTTPS is:**
1. **Intercept during handshake** (before encryption) - This is what we'll do
2. **Compromise the server** (illegal and we're not doing this)
3. **Extract keys from memory** (requires root access to Nuke process - possible but advanced)

---

## Method 1: SSL/TLS Interception Proxy (Recommended)

For master timeline context see [[Foudry-Nuke-Monitoring#Phase-4-Gap-Analysis-and-Troubleshooting]].

### How It Works

```
Nuke → Your Proxy → Foundry Servers
         ↓
    Decrypted logs
```

Your proxy acts as a "man-in-the-middle" between Nuke and Foundry:
1. Nuke connects to proxy (encrypted)
2. Proxy decrypts, logs the data
3. Proxy re-encrypts and forwards to Foundry
4. You get plaintext logs of what Nuke sent

**This works because:**
- You control both endpoints (Nuke and the proxy)
- Nuke is configured to trust your proxy's certificate
- It's YOUR traffic on YOUR machine

### Tool: mitmproxy

See [[Foudry-Nuke-Monitoring#Monitoring-Infrastructure-Setup]] for complementary automation scripts.

**Install mitmproxy:**
```bash
sudo pacman -S mitmproxy
```

**Step 1: Start mitmproxy**
```bash
# Start in transparent mode
sudo mitmproxy --mode transparent --showhost -w nuke_traffic.mitm
```

Or use the web interface:
```bash
sudo mitmweb --mode transparent --showhost
# Opens browser at http://127.0.0.1:8081
```

**Step 2: Configure iptables to redirect traffic**

Create a script to redirect Foundry traffic through the proxy:

```bash
#!/bin/bash
# redirect_to_proxy.sh

# Redirect traffic to Honeycomb through mitmproxy
sudo iptables -t nat -A OUTPUT -p tcp -d 52.205.16.9 --dport 443 -j REDIRECT --to-port 8080

# Redirect traffic to learn.foundry.com
sudo iptables -t nat -A OUTPUT -p tcp -d 52.50.232.31 --dport 443 -j REDIRECT --to-port 8080

# Redirect any other foundry.com traffic
sudo iptables -t nat -A OUTPUT -p tcp -d foundry.com --dport 443 -j REDIRECT --to-port 8080

echo "Traffic redirected to mitmproxy on port 8080"
echo "To undo: sudo iptables -t nat -F"
```

**Step 3: Install mitmproxy certificate in Nuke**

Nuke needs to trust the mitmproxy certificate:

```bash
# Start mitmproxy to generate certificate
mitmproxy &
sleep 2
killall mitmproxy

# Certificate is at ~/.mitmproxy/mitmproxy-ca-cert.pem
# Copy to system trust store
sudo cp ~/.mitmproxy/mitmproxy-ca-cert.pem /etc/ca-certificates/trust-source/anchors/mitmproxy.crt
sudo trust extract-compat
```

**Step 4: Launch Nuke and capture traffic**

```bash
# Start mitmproxy with logging
mitmweb --mode transparent --showhost -w ~/Documents/obsidian-vault/2-projects/Nuke-monitoring/dump/nuke_decrypted_$(date +%Y-%m-%d_%H-%M-%S).mitm

# In another terminal: redirect traffic
./redirect_to_proxy.sh

# Launch Nuke and use normally

# When done, restore iptables
sudo iptables -t nat -F
```

**Step 5: View captured traffic**

```bash
# Replay captured session
mitmproxy -r nuke_decrypted_*.mitm

# Export to JSON for analysis
mitmdump -r nuke_decrypted_*.mitm -w nuke_traffic.json

# Or use the web interface to browse requests/responses
```

**What you'll see:**
- Full HTTP headers (User-Agent, API keys if any)
- Complete request/response bodies (JSON telemetry data)
- Timing information
- All the data Nuke sends to Honeycomb/Sentry

---

## Method 2: Extract TLS Keys from Nuke Process

Background on why this matters: [[Foudry-Nuke-Monitoring#Data-We-Cannot-See-Encrypted]].

### How It Works

When Nuke establishes TLS connections, the encryption keys exist briefly in memory. We can extract them and use them to decrypt packet captures.

**This is ADVANCED and may not work if Nuke uses certificate pinning.**

### Tool: sslkeylog

**Step 1: Install sslkeylog**

```bash
# Install from AUR
yay -S sslkeylog-git
# or build from source: https://github.com/adulau/sslkeylog
```

**Step 2: Use LD_PRELOAD to capture keys**

```bash
# Set environment variable to log keys
export SSLKEYLOGFILE=~/Documents/obsidian-vault/2-projects/Nuke-monitoring/dump/sslkeys.log

# Launch Nuke with LD_PRELOAD
LD_PRELOAD=/usr/lib/libsslkeylog.so /path/to/Nuke15.2v6/Nuke

# Or if Nuke is already running, inject into process (requires root):
sudo gdb -p $(pgrep -f Nuke) -batch -ex "call setenv(\"SSLKEYLOGFILE\", \"$SSLKEYLOGFILE\", 1)"
```

**Step 3: Capture traffic while Nuke runs**

```bash
sudo tcpdump -i any -w nuke_for_decrypt.pcap 'host honeycomb.io or host foundry.com'
```

**Step 4: Decrypt with Wireshark**

```bash
# Open in Wireshark
wireshark nuke_for_decrypt.pcap

# Configure to use key log:
# Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename
# Browse to ~/Documents/obsidian-vault/2-projects/Nuke-monitoring/dump/sslkeys.log

# Wireshark will now decrypt all TLS traffic!
```

**What you'll see:**
- Decrypted HTTP/2 or HTTP/1.1 requests
- Full JSON payloads sent to Honeycomb
- API calls to Sentry
- All telemetry data in plaintext

---

## Method 3: HTTP Library Hooking (Most Reliable)

See also [[Foudry-Nuke-Monitoring#Technical-Architecture]] for service overview.

### How It Works

Hook into the SSL/HTTP libraries Nuke uses to log traffic BEFORE encryption.

**This intercepts at the application layer, so it works even with certificate pinning.**

### Tool: frida (Dynamic instrumentation)

**Step 1: Install frida**

```bash
sudo pacman -S frida frida-tools
```

**Step 2: Create hooking script**

Create `hook_nuke_ssl.js`:

```javascript
// Hook OpenSSL SSL_write to log data BEFORE encryption
Interceptor.attach(Module.findExportByName(null, "SSL_write"), {
    onEnter: function(args) {
        var ssl = args[0];
        var buf = args[1];
        var len = args[2].toInt32();

        // Read the buffer contents
        var data = Memory.readByteArray(buf, len);

        // Try to parse as UTF-8
        try {
            var str = Memory.readUtf8String(buf, len);
            console.log("\n[SSL_write] Sending " + len + " bytes:");
            console.log(str);
        } catch(e) {
            console.log("\n[SSL_write] Sending " + len + " bytes (binary data)");
            console.log(hexdump(data, { ansi: true }));
        }

        // Log to file
        var file = new File("/tmp/nuke_ssl_log.txt", "a");
        file.write(str + "\n---\n");
        file.close();
    }
});

// Hook SSL_read to log received data AFTER decryption
Interceptor.attach(Module.findExportByName(null, "SSL_read"), {
    onLeave: function(retval) {
        if(retval.toInt32() > 0) {
            var len = retval.toInt32();
            var buf = this.context.rsi; // Second argument (buffer)

            try {
                var str = Memory.readUtf8String(ptr(buf), len);
                console.log("\n[SSL_read] Received " + len + " bytes:");
                console.log(str);
            } catch(e) {
                console.log("\n[SSL_read] Received " + len + " bytes (binary)");
            }
        }
    }
});

console.log("[*] SSL hooks installed. Monitoring Nuke SSL traffic...");
```

**Step 3: Attach to Nuke process**

```bash
# Find Nuke PID
NUKE_PID=$(pgrep -f Nuke)

# Attach frida
frida -p $NUKE_PID -l hook_nuke_ssl.js -o nuke_decrypted_$(date +%Y-%m-%d_%H-%M-%S).log
```

**Step 4: Use Nuke normally**

All SSL/TLS traffic will be logged in plaintext to:
- Console output
- `/tmp/nuke_ssl_log.txt`
- `nuke_decrypted_*.log`

**What you'll see:**
- Exact JSON payloads sent to Honeycomb
- HTTP headers (User-Agent, Authorization, API keys)
- Sentry crash report contents
- ALL telemetry data before encryption

---

## Method 4: Patch Nuke Binary (ADVANCED - NOT RECOMMENDED)

**This involves modifying Nuke's executable to disable certificate pinning or add logging. This is complex, may violate EULA, and can break Nuke.**

**Only mention for completeness - NOT recommended.**

---

## Recommended Approach

Cross-reference: [[Foudry-Nuke-Monitoring#Recommendations]].

**I recommend Method 1 (mitmproxy) or Method 3 (frida) depending on your technical comfort:**

| Method | Difficulty | Reliability | Notes |
|--------|-----------|-------------|-------|
| mitmproxy | Medium | Good | May fail if Nuke uses certificate pinning |
| sslkeylog | Hard | Medium | Requires LD_PRELOAD or GDB injection |
| frida | Medium-Hard | Excellent | Works even with certificate pinning |

**Start with mitmproxy.** If Nuke rejects the certificate (connection errors), fall back to frida.

---

## What You'll Discover

Once you decrypt the traffic, you'll see the **exact contents** of the 17KB Honeycomb payload, including:

**Likely contents (based on EULA and typical telemetry):**
```json
{
  "telemetry_version": "1.0",
  "timestamp": "2025-10-25T12:34:56Z",
  "session_id": "abc123...",

  "user": {
    "license_id": "...",
    "license_type": "commercial",
    "email_domain": "example.com",
    "user_id": "hashed_id"
  },

  "system": {
    "os": "Linux",
    "os_version": "6.17.4-arch2-1",
    "cpu": "AMD Ryzen ...",
    "gpu": "NVIDIA RTX ...",
    "ram_gb": 64,
    "disk_space_gb": 2048,
    "locale": "en_US",
    "timezone": "America/Los_Angeles"
  },

  "location": {
    "country": "US",
    "region": "California",
    "city": "Los Angeles",
    "ip_hash": "hashed_ip"
  },

  "software": {
    "nuke_version": "15.2v6",
    "plugins": ["Cryptomatte", "OpticalFlares", ...],
    "python_version": "3.9.2"
  },

  "usage": {
    "session_start": "2025-10-25T12:00:00Z",
    "session_duration_seconds": 7200,
    "nodes_created": {
      "Read": 45,
      "Write": 12,
      "Merge": 23,
      "Grade": 15,
      ...
    },
    "tools_used": ["Viewer", "Curve Editor", "Node Graph"],
    "render_count": 5,
    "render_frames_total": 240,
    "scripts_executed": 12
  },

  "performance": {
    "average_fps": 24.5,
    "peak_memory_mb": 8192,
    "crash_count": 0,
    "error_count": 3
  },

  "errors": [
    {
      "type": "FileNotFound",
      "message": "Could not load /path/to/missing_file.exr",
      "timestamp": "2025-10-25T13:45:12Z"
    }
  ]
}
```

**This will definitively answer:**
- ✅ Is email domain transmitted? (Yes/No + exact field)
- ✅ Is geographic location sent? (Yes/No + granularity)
- ✅ What system info is collected? (Exact fields)
- ✅ What usage data is tracked? (Which features, how often)
- ✅ Are file paths included? (Privacy concern if yes)

For broader context on unanswered questions, see [[Foudry-Nuke-Monitoring#Gap-Analysis-and-Troubleshooting]].

---

## Automated Decryption Script

I'll create a wrapper script that tries mitmproxy first, falls back to frida if needed:
} need ensure anchor correct; actual section