3 ms·
The problem is that it's TLS encrypted traffic going from a black box component to a remote black box service so it's pretty hard to determine what is going ove
by blackbeard 11y ago
The problem is that it's TLS encrypted traffic going from a black box component to a remote black box service so it's pretty hard to determine what is going over the channel. Without extensive and complex reverse engineering, you can only infer what is going over it and draw some hypotheses that need to be tested. I think that the article is spot on with respect to that.
And of course there is no word from the horse's mouth (Microsoft) at all on ANYTHING related to this. Silence is always worrying.
- mahouse 11y agoTaking into account it is Windows, even if it the traffic is "encrypted", I suppose the part of the OS that encrypts it is not obfuscated in any way, so it should be easy to know what it really is doing.
- blackbeard 11y agoYou're right hence the extensive reverse engineering. I think you can expose call graphs and assembly with SoftICE or some product like that and infer which windows API calls are used so that's a starting point. However some of the things that talk are going to be heavily optimised binaries, code signed and difficult to poke inside.
- mahouse 11y agoI'm not sure of that, they could even be C# binaries, which are usually easy to disassemble and follow.
- blackbeard 11y agoPossible. I suspect anything interesting will be C++ however, possibly by design.
- balabaster 11y agoGenerally speaking you don't need to go to such lengths to intercept client/server communication from your own device. You can even have your wireless devices use your local WiFi, computer and Fiddler (which I think is roughly equivalent to Charles on Linux/iOS) as a proxy to intercept SSL and decrypt communication. You don't need to bust open the codebase itself to figure out what comms are occurring. You can stage your own MITM attack against yourself with a couple of home made SSL certificates and a router you have the ability to install your own software on.
- blackbeard 11y agoThat's true but then you still have to understand the data that is sent rather than where it is collected from. The of latter is much easier than the former from experience (I've had to reverse engineer a couple of protocols in my time)
- juliangregorian 11y agoSince when does TLS warrant scare quotes around the word "encrypted"?
- Someone1234 11y agoWhy whenever anyone quote anything someone replies criticising them for using "scare quotes?" People commonly use quotations (in English) to emphasise, or to distinguish. It is like a poor man's italics. Look at the context to decide if someone is using it to imply something is bad/evil/scary, in this case you cannot draw that conclusion. The OP is clearly just using it instead of italics.
- deleted 11y ago[deleted]
- juliangregorian 11y agoYou're full of shit. It's not a quotation. The sentence makes no sense if you put the word "encrypted" in italics rather than quote marks. HN even supports italics, so it's not like it's a needed thing. Also, your English is suspect, so don't tell me how people use quotations in English. Your reading comprehension is pretty questionable as well, seeing as you read a post criticizing Windows as not doing so. So kindly fuck right off.
- dang 11y agoWe've banned this account for posting abusive, uncivil, and unsubstantive comments.
- Dylan16807 11y ago>The problem is that it's TLS encrypted traffic Unless you can just install a local certificate and proxy it.
- userbinator 11y agoNaturally, if they were following "security best practices", they will have pinned the certificates and made no option of overriding them with your own. It's all "for your security", of course.
- balabaster 11y agoExactly, it takes less than 5 minutes to figure out how to do this with Fiddler or Wireshark...