Tuesday, August 28, 2012

Fisking hell.

I love a good fisking. Sadly, this post by Nadim Kobeissi was not a good fisking of my article.

Now, much to my distaste, I shall fisk through Mr. Bright’s article, a true labyrinth of misinterpretations, inaccuracies and horrible, headache-inducing journalism. First, regarding above claim that the data is anonymized, the whole point of my research was to show you that it isn’t. It is not. IP addresses are communicated to Microsoft in the clear.

That IP addresses are known to both endpoints of an IP connection is not noteworthy. SmartScreen is one of many, many Windows services that require IP connectivity to Redmond’s servers. Windows Update, Windows Activation, the Microsoft Store, crash reporting, CEIP and many more all require occasional connections to servers controlled by the software giant.

Kobeissi’s articles both equivocate somewhat between “users” and “IP addresses”, which is not entirely accurate, but perhaps close enough. The value of an IP address varies from person to person. In the olden days of widespread dial-up, end-user IP addresses could be expected to vary daily, if not more often, due to the vagaries of dial-up access. Thanks to the broadband revolution, this is less often the case; IP addresses can identify single households or offices for long periods of time. For those with static addresses, they can do so more or less indefinitely. This is not quite a per-user identification,

If this information leakage offends you, SmartScreen is neither the only offender, nor is it the first—and if it offends you, then you are probably not using Windows in any case, due to the many ways in which Microsoft can see your IP address.

That this communication is “in the clear” is similarly unexceptional. Every IP address is communicated “in the clear”; to do otherwise requires some kind of IP-in-IP encapsulation (e.g. IPsec ESP tunnel mode), though even here, the “outer” IP address is still in the clear, for obvious reasons.

Kobeissi says that the server Microsoft sends the information to supports the SSLv2 protocol, which is known to be insecure.

Yes, However, far before Mr. Bright wrote his article, I updated my research with the following new finding:

Update 3: Approximately 14 hours after this article was published, another scan of Microsoft’s SmartScreen servers reveals that they have been reconfigured to no longer support SSLv2. The servers now only support SSLv3 connections.

This is unfortunate. I wrote my article before Kobeissi updated his post. It wasn’t published, however, until the following day. These things happen.

This update went completely ignored by Mr. Bright, who brings up SSLv2 again and again in his article, much to my sadness. He later goes on to state that my research was about security risks (No, it’s about privacy risks with only a few notes on security) and that focusing on SSLv2 is unwarranted.

  1. I mention SSLv2 on four occasions. First in a brief description of Kobeissi’s findings; second in a description of the alleged privacy problem; third in explaining why server-side support is not a concern; fourth in Microsoft’s statement. Is this truly “again and again”?

  2. I use the term “security risk” on one occasion. I stand by that usage, as Kobeissi positioned his article as a “security” piece at least as much as he positioned it as a privacy one. The SSL issues, in particular, are security problems as much as they are privacy problems. The original article complains that Microsoft transmits the data “Not Very Securely”, and Kobeissi says that he was “tinkering around from a security/privacy perspective”. He repeats security concerns twice; “The Microsoft server is configured to support SSLv2 which is known to be insecure and susceptible to interception.” and again “Windows 8 appears to send this information to Microsoft to a server that relies on Certificate Authorities for authentication and supports an outdated and insecure method of encrypted communication.”

  3. I do not “focus” on SSLv2. The largest part of the article is about SmartScreen; its history, its purpose, a few pieces about its implementation, and its configuration. I do, however, address the matter of SSLv2, because Kobeissi’s initial research raised it as a concern.

My research was about how Microsoft is making itself an omniscient and single point of data collection regarding what every Windows 8 computer is downloading and installing, and that this is very dangerous from a privacy perspective. In actuality, I’ve found Microsoft’s SmartScreen servers to be vulnerable to the BEAST attack (In retrospect, I don’t think this is the case.)

This is a remarkable statement. Although Kobeissi added the parenthetical after a comment was posted, he initially claimed that SmartScreen was vulnerable to the BEAST attack. The BEAST attack against SSLv3 and TLS 1.0 requires the use of a CBC algorithm on the server side, and Microsoft’s servers do support this cipher suite (indeed, they use AES-CBC algorithm in preference to the BEAST-proof RC4 algorithm, even when the client supports RC4), but it also requires the ability for a hostile party to inject adaptive chosen plaintext to determine the encryption keys being used. This is possible with, for example, Java applets (and WebSockets code written against older versions of the WebSockets specification), but it isn’t possible with the essentially hard-coded SmartScreen check.

On one level, that’s OK. Kobeissi made a mistake (or perhaps had not studied BEAST or previous literature in any great detail) and when the error was pointed out he updated his post accordingly.

On a deeper, however, level it’s problematic. At the very least, this indicates poor attention to detail on Kobeissi’s part—the fact that he has heard of BEAST and knows that SSLv3 and TLS 1.0 are susceptible is enough for him to mention it, regardless of its relevance. But it does more than that. He does not simply say that there may be a possibility of a BEAST attack. No, he states unambiguously “In actuality, I’ve found Microsoft’s SmartScreen servers to be vulnerable to the BEAST attack”. In actuality, he has found no such thing.

But lo and behold, Mr. Bright brings up SSLv2 yet again:

There are some technical problems with Kobeissi’s complaint. Although he says that the server supports SSLv2, that is only part of the story.

Here my state of frustration at Peter Bright’s lacking in the journalistic faculties morphs into a state of boyish wonder; Could it be? Has Peter Bright exceeded the natural limits of misinformed, under-researched journalism? Has he set a new standard? For the entire Internet, perhaps? Am I witnessing history?

Or perhaps, he is witnessing an article written before he updated his post.

This still means that Microsoft could determine which programs individual IP addresses are using.

But lo, a ray of light! A sign of redemption; Peter Bright might actually focus on what I’m trying to say after all!

Here Kobeissi attempts to change history. His original post goes far beyond saying “Microsoft could log IP addresses”. He claims, for example that “The user is not informed [of SmartScreen’s behaviour] while installing and setting up Windows 8”. This is false. He claims—still, even after his later SSLv2 update—”Windows 8 appears to send this information to Microsoft to a server that […] supports an outdated and insecure method of encrypted communication.” He suggests that “SmartScreen is not easy to disable”, which is farcial. He might wish his original claim had been as narrow as “Microsoft can correlate executable hashes to IP addresses” but it was not.

When asked for comment, a Microsoft spokeswoman told us:

“We can confirm that we are not building a historical database of program and user IP data. Like all online services, IP addresses are necessary to connect to our service, but we periodically delete them from our logs. As our privacy statements indicate, we take steps to protect our users’ privacy on the backend. We don’t use this data to identify, contact or target advertising to our users and we don’t share it with third parties.”

The company has also talked in the past about the privacy implications of earlier iteration of SmartScreen. Although Microsoft does collect some data (for example, it distinguishes between popular downloads and unpopular downloads, as part of its application reputation feature), that same data is also anonymized.

As such, the privacy risk here is minimal.

Peter Bright, a tech journalist, just came to the conclusion that a privacy risk was minimal because the corporation being accused of the privacy risk asked him to please trust them; they swear it’s minimal.

My conclusion is that it’s minimal because Microsoft does not, contrary to common belief, set out to deliberately open itself up to legal liability. The company has clear privacy policies in place, and operates in a regulatory climate that is hostile to privacy breaches, whether perceived or real (especially in the EU). Creating such a database would plainly violate the terms of Microsoft’s own privacy policy and as such open up the company to considerable legal liability. The downsides are obvious.

The upsides, however, are not. No advantage to Microsoft of building a persistent database cross-referencing IP addresses to applications is immediately apparent; nor is any such advantage described in Kobeissi’s post.

My reaction to just how ready Mr. Bright is to dismiss my body of evidence that Microsoft could, at any time, record what every default Windows 8 configuration is installing because a Microsoft spokesperson told him to was first this, this, then this, then realizing how painfully backwards parts of the Internet can be, coming to peace with it, and writing this article where I nicely explain to Peter Bright why he sucks at being a tech journalist.

My heart, it is breaking.

It might be unfashionable, but although I am happy to regard corporations as essentially amoral entities, it’s simply not enough to say “Well, they could do something bad” and regard that as reason enough to condemn their actions. There needs to be some evidence of some degree of wrong-doing first. Such evidence is entirely lacking from his analysis.

E&OE.