Sniffing an outbound HTTPS packet - only intercepted by certain software, can't decrypt

Question

I'm trying to sniff an SSL-encrypted outbound packet. It's sent by the game Mass Effect 3 to an EA web service.

When I sniff packets with Nirsoft SocketSniff, I can see the packet (positively identified by the moment it appears in SocketSniff):

Socket      Index  Type  Local Address  Local Port  Remote Address  Remote Port  Send Calls  Receive Calls  Sent Received  Closed
0x00000CBC  24     TCP   192.168.0.111  49191       94.236.58.180   443          5           492            661  1,753     Yes    

I can then click on this row to view hex dumps of all communications (in both directions) on the relevant socket. There are 5 sent packets, and 12 received packets, one of which is a partially legible certificate from Electronic Arts inbound to my PC.

I can also see the communication in more detail in Wireshark, which shows this:

When I click on the Application Data row, I can see hex-dumped ciphertext. However, I want to view the plaintext, so I need to use an HTTPS proxy.

I first tried Charles, which I configured and successfully used to decrypt some HTTPS data to and from a website, as well as some different HTTPS traffic from Mass Effect 3. However, the packet described above does not show up in Charles. I also tried Fiddler 4, which I similarly used to successfully decrypt HTTPS traffic, but the packet does not show up in Fiddler either.

So out of the 4 pieces of software that I used, 2 of them can pick up the packet, but not decrypt it, and 2 of them can decrypt HTTPS traffic, but can't pick up this particular packet.

Any ideas for what I might be doing wrong, or what I can try next? I can provide more information if needed.

Answer 1

Using an HTTPS Proxy relies on the fact that you can MitM the connection by using a self-signed certificate. Effectively you can create a certificate for "*.ea.com" issued by your own CA and tell the HTTPS proxy to send it to your game, in case it tries to establish an outbound connection.

This is the normal process:

1. Game wants to contact ea.com
2. Performs a TLS handshake with ea.com
3. Receives a certificate saying "this public key belongs to ea.com"
4. Game determines whether the certificate is authentic and trusted
5. If no, terminate connection, otherwise send encrypted data which can only be decrypted by the owner of the private key

As soon as the game encrypts the data, you cannot decrypt it, even if you use Wireshark. Using a proxy which breaks HTTPS does this:

1. Game wants to contact ea.com
2. Tries to perform TLS handshake with ea.com
3. HTTPS proxy establishes the connection to ea.com itself instead
4. HTTPS proxy gives the self-signed certificate (which YOU have the private key for) to the game
   1. All traffic is now decrypted and re-encrypted in the HTTPS proxy using the self-signed certificate
5. Game determines whether the certificate is authentic and trusted
6. If no, terminate connection, otherwise send encrypted data which can only be decrypted by the owner of the private key (which is YOU in this case)

Step 5 is problematic. An HTTPS proxy only works if the game relies on the OS to determine the authenticity of a certificate. In this case, you can locally install your self-signed cert and the OS happily tells the game "yup, everything is fine". If the game does some sort of HSTS- and certificate pinning technique to avoid fake-certificates and insist on an original on (or even stores the only accepted (root)certificate locally in its code), you cannot trick it in accepting a self-signed certificate (without messing with the game's code itself).

I assume this is the reason for your HTTPS proxy failing to replace the original certificate with a fake one. Your proxy does either not pick it up, as it cannot reveal the plain text or pick it up without being able to decrypt it.