bah. blacksheep.

It's a deeply satisfying way to defeat an attacker: give him a taste of his own medicine, and the BlackSheep add-on attempts to do just that. This add-on listens for Firesheep's patterns on the network and warns a user that they are being watched. BlackSheep drops juicy bait for Firesheep (fake session cookies wrapped in legitimate-looking requests to sites) and waits for Firesheep to pick them up. When a Firesheep attacker tries to exploit these fake insecure sessions, BlackSheep picks up on it and alerts its user.

While there are some Firesheep users that will set off this alarm, the problem is a bit more serious. Many attackers have probably looked deeper into the fundamental flaw and also want to protect themselves from such an attack. These folks will be using a security-forcing add-on like Force-TLS, STS-UI on Firefox 4, HTTPS Everywhere or NoScript. All of the protected bad guy's connections to vulnerable sites will be secure, including the sessions that have been copied from other users on the network.

The upshot is that while BlackSheep may see the attacker connecting to vulnerable sites, it won't always know when the bait was taken. For many serious Firesheep-like attacks, BlackSheep will remain quiet.

There are many Firesheep users who are just playing around with the new, hot hacking tool, and so BlackSheep will cry out some of the time; it can't however be relied on to detect most Firesheep attacks. While I like the idea of an alarm like BlackSheep, solving the underlying problem (and stopping serious attackers that are more of a cause for concern) is a bit more complex and requires a different approach. Ultimately, we need to secure wifi networks, protect ourselves with HTTPS-forcing technologies, and ask sites to protect their users by using HTTPS for the whole session.

Managing HSTS Data

I blogged about HTTP Strict-Transport-Security before and how it's all new and shiny in Firefox 4. With all the happy firesheep attacks on the horizon, it's made it even more important that sites start using HSTS.

In case you don't want to wait for your favorite sites to start deploying strict-transport-security, here's a way for you to enable it yourself. I whipped up a quick add-on proof of concept that lets you add and remove HSTS data.

There are two ways to manage HSTS data for sites using this add-on:

1. Navigate to an HTTPS page, open the page info dialog, and tick the "Always access content from this site securely" box
2. Choose the "Manage Strict-Transport-Security..." item from the Tools menu, and enter the host names for your favorite sites there.

Let me know what you think!

UPDATE: Instead of maintaining the add-on in parallel with Force-TLS, I've decided to adapt Force-TLS to use the HSTS bits built into Firefox 4 and show you the same UI. Instead of the STS-UI add-on, try installing Force-TLS!

behavioral advertising icon

I think self regulation in the behavioral ad industry is generally productive, but this IAB press release suggests the newest effort is promoting something that will induce a false sense of disclosure.

This Advertising Option Icon thing is something I heard rumblings about a little while back. The idea is to badge ads that use your behavior, and badge sites who collect your behavior for this use.

A couple of things make me skeptical:

First, this is a stigmatizing mark -- a tattoo that will label pages as "spying" to some and other simply won't notice. I'm willing to bet that such an icon won't be an effective indicator (no matter what the self-regulating body claims) since people
won't pay attention. We all know how poorly the lock icon worked, and people actually paid attention to that one. As an added disincentive, major advertisers have to pay yearly to use the tattoo.

Second, not just advertisers do this tracking, and the advertisers can capitalize on this. They would likely find a way to use third parties for data collection in order to get around the requirement of showing the badge.

Finally, the icon is a play button looking thing. Nothing in the visual suggests what's going on. A pair of eyeballs might be a more intuitive representation.

Icons in web pages aren't going to help. My opinion is that if we want to represent hidden behavior to users we have to have more flexibility. Such visual representations shouldn't be limited to ads, because if we start using icons to represent this tracking behavior for other contexts, the number of icons users must understand multiplies.

Aza's privacy icons project is a good direction; I think it would encompass what is being attempted here without restricting it to ads and with more efficacy since it would be one comprehensive set for all the web.

AppSec USA was great

A bunch of us from Mozilla attended OWASP AppSec USA 2010 in Irvine, and I have to say, it was a pretty great event. There were some bits of the meeting that stood out in my mind as more productive than many conferences or workshops I've attended.

The Booth: we don't often have a vendor booth at security conferences (honestly, what are we selling?), but this time we did and I found it fantastic. A variety of people approached us to learn what security features are available for web sites, and a few had pretty specific questions about CSP.

The Audience: the community present in Irvine was mostly composed of security contractors and security specialists from organizations with big web properties. The meeting was a fantastic opportunity for us to connect with folks who work on securing sites and make sure our efforts in Firefox are pragmatic and useful.

The OWASP Leaders: some of the community leaders from OWASP organized a "browser lunch" meeting with two goals: (1) to bring everyone up to date with what the others are working on and (2) figure out how OWASP can affect the security of the web through browsers. This was an incredible high-bandwidth discussion where we were able to quickly convey all the hard work we're putting into web security and also learn about concerns and new security research being done by industry leaders. It turned out that our goals were pretty much aligned with the security research community, and CSP is a big step in the right direction.

So my takeaway is that OWASP AppSec USA was incredibly productive -- rich with high energy researchers, vast resources and knowledge -- and I am looking forward to working with the OWASP community to reach our common goal of making the web a safer place for us all.

HTTP Strict Transport Security has landed!

It was a year ago now that I first blogged about ForceTLS, and it's matured quite a bit since. I revised ForceTLS to be more robust, and began actually implementing it as HTTP-Strict-Transport-Security in Firefox. I'm excited to say that my patch has been reviewed and landed in mozilla-central.

What's that mean? Look for it in the next beta release of Firefox 4! If you can't wait, grab a nightly build, but when 4.0 is released, HTTP Strict-Transport-Security will be built-in and turned on by default.


Though the feature's core functionality is there, work on HSTS is not completely finished. There are still a few tweaks I'd like to make, mainly providing a decent UI so people can add/remove HSTS state for servers themselves -- but none of this is necessary to be specification compliant. As landed, HSTS is the behind-the-scenes implementation that listens to the HTTP Strict-Transport-Security header and follows those instructions.


In case you don't feel like trawling through the IETF Internet Draft specification but you want to figure out how it works, here's a quick summary:

1. Over an HTTPS connection, the server provides the Strict-Transport-Security header indicating it wants to be an HSTS host. It looks something like this:
   

   Strict-Transport-Security: max-age=60000

   The header's presence indicates the server's desire to be an HSTS host, and the max-age states for how many seconds the browser should remember this.
2. For an HSTS host (e.g., paypal.com), any subsequent requests assembled for an insecure connection to that host (http://paypal.com), will be rewritten to a secure request (https://paypal.com) before any network connection is opened.
3. Optionally, the header can include a second includeSubdomains directive that tells the browser to additionally "upgrade" all subdomains of the serving host. That looks like this:
   

   Strict-Transport-Security: max-age=60000; includeSubdomains

If Firefox knows your host is an HSTS one, it will automatically establish a secure connection to your server without even trying an insecure one. This way, if I am surfing the 'net in my favorite cafe and a hacker is playing MITM with paypal.com (intercepting http requests for paypal.com and then forwarding them on to the real site), either I'll thwart the attacker by getting an encrypted connection to paypal.com immediately, or the attack will be detected by HSTS and the connection won't work at all.

There are more details in the specification, like some further restrictions on cert errors and the like, but this is the general setup, and I believe a pretty nice feature to increase your site's security.


Also: Jeff and Andy at Paypal are working hard at standardizing this.

facebook again

Aarrghh!

I was gonna blog about this new Facebook data collection feature, but why rehash a the same thoughts? From Michael Coates:

"The last thing to consider is facebook's track record on protecting data. How long will it be until advertisers find a way to pilfer this data from people? Or what about the next privacy setting overhaul which changes the defaults or makes it more difficult to control who sees your location data?"

And the vicious cycle begins again. I don't agree that it's all about advertisers (I'm an optimist here), but the wash-rinse-repeat cycle gets tiresome: (1) add new data collection feature (2) public outrage (3) respin privacy settings (4) repeat.

OWASP AppSec USA

Michael Coates writes:

Several Mozilla employees will be attending this year's OWASP AppSecUSA event held in Irvine, CA (Sept 7-10). OWASP conferences focuse entirely on application security and are considered the premier event for this area of security.

I'm one of those mysterious Mozilla folk going to the meeting, and if you're there drop by and say hi. If you're not, you should consider coming! OWASP does wonderful things for web application security, and there are always fantastic talks to look forward to at AppSec USA.

This year, I'm hoping to spread the word about Content Security Policy a bit more; if you run a web site (or better yet, if you secure one) come find us at our booth or harass one of the Mozilla folk in the hallway and we'll be more than happy to help figure out how CSP can make your site more secure for your users.

mind the gap

( Image credit: tnaric via Flickr )

Web privacy is a very hard problem to solve. Well, at least what people perceive as "the privacy problem."

One of the main reasons it's hard to "solve privacy" is that the term privacy is used in many contexts to indicate many things.

This is ironic, since user data is also used in many contexts to indicate many different things. That is, a piece of data may be considered private in some contexts, but not in others.

I'd like to take a more focused approach and concentrate on one main cause of the "ZOMG my privacy is violated!!1!" uproars to see if we can't help address it.

Facebook Beacon. In late 2007, Facebook launched a new Beacon feature that caused a brisk community reaction. The feature automatically syndicated users' activities on partner sites to their Facebook news feed. For example, if you bought tickets to the Harry Potter movie on fandango.com (a Beacon partner), it might be broadcast to all your friends where and when you were going to the movie. People were mad because non-Facebook activities were now automatically imported into Facebook and shared.

Google Buzz. Google turned their new "buzz" feature on for some of google users in February 2010. This feature automatically created a twitter-like stream for things you do (such as what you read in google reader and photos you upload to picasa) and immediately connected you to "follow" other google users in your "exchanged mail with" list. Harriet Jacobs' article exemplifies the reaction. She didn't want people who emailed her on occasion to know everything she does, but suddenly this new technology connected her activities to everyone she had received mail from.

LSOs, a.k.a. Flash Cookies. When people clear their cookies, not all cookies actually get deleted! Gasp! Here's why: Adobe's Flash plug-in has its own data storage space on your computer -- separate from where your browser stores cookies, bookmarks and passwords. The browser doesn't have direct control over Flash's data, since Flash is essentially a separate application that happens to show its content inside your browser window. The result? You clear cookies, but your browser doesn't know how to clear flash cookies. How is this used? In many ways, but one particular sneaky use rubs many people the wrong way: web sites can use flash to keep longer lived cookies on your system that can be used to re-populate regular cookies after you clear them. People are mad. (FYI, this is being worked out, see this bug).

The Gap. There's this dark and mysterious area between what users think is happening with the data they put on the web and what actually happens. I call this the Privacy Perception Gap (PPG). There are a variety of reasons this gap exists:

1. Software makers are not psychologists -- they don't know what people expect, only how the system works.
2. Software makers are not anthropologists -- they don't know how different cultures expect secrets to be kept or shared.
3. Software is reactive -- users complain, software is re-engineered, and the cycle repeats
4. The PPG is not well understood

This last reason is something we can address with proper research. First, we need to understand the size and reason for the PPG before we can close it, especially before we know who is best poised to do the work. Is it users, user agents, infrastructure, applications, or a combination who should take the giant leap? How big is this gap on average? Surely it's different for various web applications.

If we minimize the PPG, we can expect users to be better informed, and that may have solved the variety of situations enumerated above. Users wouldn't be surprised with what happens, and the suspicion that web companies are out to violate their users would be reduced significantly.

I'm a big fan of transparency (see Open and Obvious), as it is a big part of the PPG problem. We should start by making data relationships transparent: this includes disclosure first and then most importantly user accessibility second. For instance, having a privacy policy linked from my web site doesn't really make me transparent unless users can find and understand it. The gap doesn't shrink if users don't understand! My theory is that an informed user is a happy user, and if we can better understand the PPG we can take the first step towards making web users happy.