Hacker News Reader

Comment by jfrunyon | Hacker News Reader

Can't duplicate. 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.

Also, I'm a bit curious why this looks more like a request that it would send when someone types a search into the Startmenu rather than the Run box.

In fact, when typing into (or even running from) the Run box, I see no network requests over ports 80/443. When typing into the Startmenu, I see network requests going to the same M$ IP shown (204.79.197.200), but they are, of course, TLS-encrypted on port 443. Even if I block port 443 in the Windows firewall, it does not fall back to port 80.

This is either false, or version dependent. I would lean towards the former. Frankly, if this is real, a bigger problem than the sending of telemetry is the sending of unencrypted telemetry.

View on HN

As with many things, the initial outrage will get much more publicity than any follow on correction. This blog posts talks about how you can see everything Windows sends with its telemetry system here: https://www.neweggbusiness.com/smartbuyer/windows/should-you...

I wish more people would follow the maxim, "extraordinary claims require extraordinary evidence".

That app doesn't show some requests which I know Windows does make, like Start menu searches. And frankly I wouldn't trust it to be accurate even if I couldn't find anything which wasn't included.

Agreed w/r/t outrage and the maxim, though.

With Microsoft these days, claiming that they won't backstab you is the extraordinary claim. You may disagree, but their track record is pretty poor.

You are correct. This traffic was not generated by typing text into the "run box", it was generated by typing text into the "start menu box". We are very sorry for the confusion this has caused. The wireshark screenshot shown in our tweet was showing TLS traffic that has been decrypted by PolarProxy. That’s why it shows up as HTTP/2 traffic over TCP port 80.

Wouldn't the safest option be to delete the tweet?

It took reading around to see that this is incorrect.

EDIT: Thanks for deleting it

We first tried to post replies with corrected information, but it didn't seem to help. The tweet has now been deleted and a correction tweet has been posted instead.

> 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?

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.

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.

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.

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.

After reading the full twitter thread, that tweet got called out fairly quickly. For, as you say "search into the Startmenu rather than the Run box" - which turns out is encrypted (443 / start menu - not run box). Also the PCAP is said to be more than a year old (which in fairness, is still pretty shoddy)

OP has posted an update, it was not the run dialog but the start menu search after all...

Yes. Sorry for the confusion. The original tweet has now been removed and a correction has been posted instead.

Reply on news.ycombinator.com