Christian Huitema's Internet experience

I have the privilege of working for Microsoft, and with that come a few interesting side-effects. Periodically, I would receive e-mail from some friends who complain about a bug or maybe a feature in one of our products. And they will ask me to use my influence, talk to the team in charge, and get it fixed. A tall order indeed, since in a large company like Microsoft your sphere of influence tends to be limited to the products you directly work on. But, hey, one can always try.

It happened again last month. A friend had read a report about the privacy implication of the "anti-phishing" feature of IE7. That particular report implied that, if the anti-phishing feature was selected, IE7 would contact Microsoft for each web page, asking whether the page's URL was or was not listed as a phishing site. My friend was quite incensed. He was concerned that ever computer in his company would report to Microsoft a complete list of all URL visited by their employees, providing Microsoft with a detailed view of this company's activity. He went on to mention the various counter-measures that the company could take, from blocking the access to the Microsoft anti-phishing server in their firewall to prohibiting use of IE7 or even Windows.

Privacy is actually something I care a lot about. In fact, Microsoft as a company cares a lot about it. There have been some incidents in the past in which products "called home" to the dismay of privacy advocates, but we now have well delineated internal procedures to protect the privacy of our customers. Products are only supposed to call home when they have a good reason to do so, e.g. provide a service or collect statistics. The feature has to be opted in by the user. The collection of data should be limited to the strict minimum required to provide the feature. Any use of personal identifiers faces a lot of scrutiny. There must be procedures in place on the back end to protect the data, and dispose of it when it is not needed. In fact, some product managers believe that our protections are too strict and place us at a disadvantage relative to competitors who seem to have no second thought archiving people's entire web history, but personally I like it that way.

So, when I received the mail about IE7 and privacy, I was a bit puzzled, and asked some colleagues in the IE7 team about it. It turns out that they had indeed followed our guidelines, and that the blog entry that my friend's read was unduly alarmist. By nature, the anti-phishing feature requires some contact with Microsoft, since there will sometimes be a need to check an URL against a database of phishing sites, and there will also be a need to report phishing sites for inclusion in the database. Given that constraint, the IE7 team tried to minimize the privacy impact. (They pointed me to an entry on this subject in their blog: http://blogs.msdn.com/ie/archive/2006/05/08/592677.aspx. It contains more information on the topic, including a pointer to a review by independent auditors.) Their design has multiple levels of protection:

• The feature is opt-in, i.e. it is only activated if the user explicitly agrees to use it.
• There is a way for IT managers to disable it on their company's PC.
• IE7 first applies a local filter, and only queries the database if the page fails that local filter.
• The query is transmitted over SSL, so bad guys will not be able to look at the traffic.
• The query only contains the "path" component of the URL, not the parameters entered in a form.
• The database back-end does not receive any personal information about the user, not even the IP address of the computer.

In fact, I can easily picture the team going through brainstorms and reviews to make sure that their feature met the privacy guidelines. Frankly, I believe they did a very good job.

Of course, all that reasoning will not be worth much if people do not trust Microsoft. We can repeat as much as we want that we don't actually store the information, and that we are not trying to keep tabs on the user. There will always be someone who doesn't believe us. Oh well. The summary is that the feature is opt-in, can be controlled by IT administrators, and has been implemented to mitigate privacy risks as much as possible, given the basic need to occasionally check URL against a centrally updated list of phishing sites. Users, and IT managers, will have to evaluate the trade-off: trust that Microsoft will not do anything stupid with the data, versus trust users to not do anything stupid when stumbling on a phishing site. Now, I can wait for the next question…

-- Christian Huitema

The common wisdom is that, if you want to secure your Wi-Fi network, you should program your access point to hide the SSID. The common wisdom is wrong, and I wonder how long it will take to reverse that.

On the surface, it seems to make sense. If your access point does not broadcast the name of the network, the hacker in the parking lot should be dumbfounded. To connect to a network, the client must know the SSID. If it is unknown, the hacker should not be able to guess it, and thus should not connect. Right? Wrong, of course!

In normal procedure, the access point send "beacons" at regular intervals. The beacons include the name of the network: "Hello, I am an access point serving network EXAMPLE-1." The client hears it, recognizes that "EXAMPLE-1" is a network to which they want to connect, and proceed with establishing the connection.

Suppose now that the AP is programmed to not broadcast the name of the network. It will still send beacons at regular intervals, but these beacons will be somewhat cryptic: "Hello, I am an access point serving some network, but I won't tell you which one." The client hears that, and must now explicitly "probe" the access point, sending a message much like: "Do you happen to serve the network EXAMPLE-1?"

At this point, attackers have two options. First, the can lay in wait near an access point, and listen to the airwaves until a client shows up. When the client sends its probe, the hacker learns that the network could very well be named "EXAMPLE-1". Bingo, here comes the SSID. In fact, attackers can force clients to send a probe by messing with the 802.11 control packets, and effectively force an authorized client to restart the connection procedure. So, even if the access point does not broadcast the SSID, attackers can learn it from the clients, with minimal effort and minimal delay. Hiding the SSID in the access point is at best a speed bump on the way of the attacker.

But let's look at the second option. Suppose that the attacker lays in wait in some public place, such as an airport lounge. The attacker will mimic an SSID that hides its name. If a laptop is programmed to connect to a "hidden" network, it will send a probe: "Hello, are you the MUMBLE network?" Replace here MUMBLE by the name of your company's network, Microsoft, Boeing, etc. The attacker just learned the name of your company. That is already a significant information disclosure, placing your privacy at risk.

But it gets even worse. Suppose that the attacker programs its "mock access point" to just acknowledge any request: "Yes, I am indeed the MUMBLE network." The laptop will happily recognize a "good" network, and will establish the connection. All the ensuing traffic will flow through the attacker's computer. At this point, the attacker can play all kinds of games: spying on the traffic, redirecting queries to chosen sites, probing the laptop for open ports, etc. This is a very powerful attack.

The bad news is that, until recently, the Wi-Fi stack in Windows XP did not make the difference between hidden and public networks. If it heard an "empty beacon", it would automatically send probes for all its preferred networks, effectively empowering the attackers. We changed that in Vista. In Vista, the Wi-Fi stack will only send probes for the networks that have been explicitly programmed as "hidden". If there are no hidden networks at all, the stack will not send any probes, and the attack will be thwarted. Recently, we also back-ported the changes to XP – they are available through Windows Update.

But, of course, if there is at least one hidden network, the stack will still send the probe messages. The alternative would be to require an explicit "manual" connection to any hidden networks. Customers would not be happy. So, the only way to be safe is to not require these customers to connect to a hidden network. So, now, you are warned. You should not program your network to hide its SSID. It does not improve the network's security, since attacker will deduce the SSID value from client traffic. And it does expose clients to automatic attacks, when they travel to public places.