Hacker News Reader

Comment by josephcsible | Hacker News Reader

> Also, I'm a bit curious how this person is able to see HTTP2 contents in Wireshark, given its almost-mandatory TLS. Also, I'm extremely surprised that Microsoft would send telemetry without encryption.

Install your own root CA then MITM it?

View on HN

You are completely right. The traffic was sent as TLS encrypted HTTP/2 traffic to Microsoft. We decrypted it using PolarProxy in order to see what was transmitted. The screenshot in the tweet shows the decrypted PCAP generated by PolarProxy.

I wonder if this is the result of some tool that intercepts all traffic in Layer 2 and rewrites everything to put a MitM proxy while keeping the original IP addresses. It can even be running in a different machine, with the traffic coming through an actual NIC and cable (so the OS being analyzed does not see strange network interfaces nor changes behavior when it detects that it is running in a VM).

Does somebody know about such a tool?

It does not explain the port 80, however.

I wrote such a tool once: https://github.com/SySS-Research/Lauschgeraet

Unfortunately, no one really uses it (not even me) and it is probably full of bugs.

The PCAP in the referenced tweet was created using PolarProxy, which decrypts and re-encrypts TLS traffic while saving the decrypted traffic to a PCAP file.

Well, firstly, it wouldn't be port 80 in that case.

Could be an artifact of however the proxying or decryption is done, particularly if the goal was to have the traffic be decrypted as it went across the NIC not just to get a copy of the data being proxied locally.

Or it could be an artifact of bad editpcap-ing. Same with the all 0s Ethernet source/destinations.

Either way I don't think it was the run box that triggered it. Either they didn't know the original run box is still a thing and the field in the taskbar is a search box or they have clipboard history enabled and didn't realize that's a cloud function while they were ctrl+c and ctrl+v-ing into the box.

Frankly, I can't think of any way to proxy or decrypt it that would result in the packets still being destined for the same Microsoft IP, but with port 80 instead of 443.

The only explanation I could think of was that it falls back to HTTP if HTTPS is unavailable and they blocked port 443, which not only would be bat**** insane, but I tested and that does not occur.

"Many also interpreted the screen shot as if the traffic was sent in clear text. That is not the case, whatever you type on the Win start menu is sent using HTTPS over TCP 443. We used a TLS proxy to decrypt the TLS traffic in order to show what is being sent to Microsoft."

https://twitter.com/netresec/status/1440298939509399553

Yeah, turns out their capturing proxy just creates inaccurate pcaps. Who woulda thunk.

Only if you also disable all ciphers with perfect forward secrecy and hope that there is still a cipher overlap with the server.

MitM'ing the traffic using a trusted root CA allows TLS traffic to be decrypted, even if perfect forward secrecy is used. That's what we did to produce the decrypted PCAP shown in the Wireshark screenshot.

If you use an HTTP proxy or terminate the TLS connection in some other way, yes. I was thinking of the situation where you use Wireshark directly on one of the endpoints, i.e. a passive MitM attack.

Reply on news.ycombinator.com