Categories
Mozilla Security

Firesheep Demonstrates The Need For SSL

There’s been a storm of discussion over the past 72 hours about Eric Butler’s Firefox extension Firesheep. To summarize, it’s a Firefox extension that facilitates session hijacking by packet sniffing for data from certain websites. As far as software goes, it’s more evolutionary than revolutionary, at its core it’s a packet sniffer. The evolution is the pretty UI which makes it trivial to hijack someone’s session (he really did do a good job on the UI, it’s so easy a child could use it).

It’s actually surprising to me that so many people are shocked by what this demonstrates. Even those who claim to be technically literate seem taken back. Insecure sites by definition are insecure. Anyone can read what’s going across the wire (that includes WiFi) when it is sent unencrypted. If your browser can interpret and use the information to let you browse Facebook, Twitter, etc. so can any browser, on any computer. It’s that simple. Firesheep only supports a handful of sites, but adding support for more sites isn’t difficult. If your favorite website hasn’t been done yet, I expect it will be soon enough.

How Do You Protect Yourself?

The best way to protect yourself is to demand that websites that hold private information use HTTPS from the moment you log in until you log out. Short of that, the best you can do is use a Firefox extension like EFF’s HTTPS Everywhere to force your browser to use HTTPS. This won’t work everywhere as not every web server even has HTTPS working, but many secretly do. They sometimes use HTTPS for certain things like login, then use insecure HTTP for the rest of your visit. That’s so your password isn’t transmitted in plain text. Protecting a password is important, but if the session is insecure anyone can intercept what you do. HTTPS Everywhere works by rewriting all requests to many popular sites to use HTTPS ensuring your privacy and security through the length of your visit. Some websites will have minor issues. For example Facebook Chat is impossible to support right now due to it not working via HTTPS. The rest of Facebook however works.

For more advanced users, HTTPS Everywhere lets you write your own rulesets for sites it doesn’t support.

How Do Websites Protect Their Users?

It’s very simple. Use HTTPS for the period a user is logged in, not just when authenticating and submitting sensitive data. Sure it’s a little slower and requires more hardware, but scaling HTTPS these days isn’t nearly as difficult as it was just 5 years ago. In 2 years it will be even easier. Google went as far as forcing HTTPS upon all of Gmail users. Binding a session to an IP address is fussy and largely ineffective due to NAT, WiFi hotspots and mobile services that can cause an IP to just change with little/no notice. It’s not effective security. It’s better than nothing, but it’s not a fix.

Google could make a huge difference by supporting SSL in Google AdSense, something I’ve called for since 2008. Google has supported SSL with Google Analytics for some time, but they have lagged with rolling out support in other services. Lots of websites monetize with AdSense and this is just another reason websites put off supporting SSL. Other ad networks should do the same. Google AdSense has the least barrier to entry since they serve their text ads off of their own infrastructure, vs. creatives hosted by other parties like some smaller ad networks. One could argue having third-party code inserted on a page mitigates security but it would still be a major improvement over the current state of affairs and would prevent simple session jacking.

Categories
Mozilla Security

On HTML5 And The Future Of Privacy

Today’s alarmist without much research news is “New Web Code Draws Concern Over Risks to Privacy” about HTML5 and its threat to privacy. How evil of HTML5 and its creators.

The Real Deal

Persistent cookies are nothing new. Essentially the strategy works like this: Store data everywhere you can on the users footprint, and if data it deleted in a few locations, you copy it back from another location the next time you can. It’s regenerative by design. A popular example is evercookie which uses:

  • Standard HTTP Cookies
  • Local Shared Objects (Flash Cookies)
  • Storing cookies in RGB values of auto-generated, force-cached PNGs using HTML5 Canvas tag to read pixels (cookies) back out
  • Storing cookies in and reading out Web History
  • Storing cookies in HTTP ETags
  • Internet Explorer userData storage
  • HTML5 Session Storage
  • HTML5 Local Storage
  • HTML5 Global Storage
  • HTML5 Database Storage via SQLite

Note that several of these aren’t HTML5 specific. More than one of which isn’t cleared by just “erasing cookies”.

HTML5 does add a few new possibilities, but they are also by design as easy to control, monitor and restrict as your browser (or third-party add-on) will allow. HTML5 storage mechanisms are bound to the host that created them making them easy to search/sift/manage as HTTP cookies. Much worse are some of the more obscure cookie methods (Flash Cookies, various history hacks). They don’t really provide any more of a privacy risk than what the browser already has been offering for the past decade.

To Shut Up The Geolocaiton Conspiracy Theorists

Before someone even attempts the “Geolocation API lets advertisers know my location” myth, lets get this out of the way. The specification explicitly states:

User agents must not send location information to Web sites without the express permission of the user. User agents must acquire permission through a user interface, unless they have prearranged trust relationships with users, as described below. The user interface must include the URI of the document origin [DOCUMENTORIGIN]. Those permissions that are acquired through the user interface and that are preserved beyond the current browsing session (i.e. beyond the time when the browsing context [BROWSINGCONTEXT] is navigated to another URL) must be revocable and user agents must respect revoked permissions.

Some user agents will have prearranged trust relationships that do not require such user interfaces. For example, while a Web browser will present a user interface when a Web site performs a geolocation request, a VOIP telephone may not present any user interface when using location information to perform an E911 function.

To my knowledge no user agent implements Geolocation without complying with these specifications. None.

No HTML5 Needed For Fingerprinting

Even if you do manage to wipe all the above storage locations, you’re still not untraceable. Browser fingerprinting is the idea that just your system configuration makes you unique enough to be traceable. This includes things like your browser version, platform, flash version, and various other bits of data plugins may additionally leak. The EFF recently did a rather impressive study to learn about the accuracy of this technique. Computers with Flash and Java installed sport 18.8 bits of entropy and result in 94.2% of browsers being unique in the EFF study [cite, PDF]. Of course their data was likely skewing towards more experienced web users who are more likely to have an assortment of customizations to their computer (specific plugins, more variety in web browsers, operating systems, fonts) than the average internet user. I’d wager that their data downplays the effectiveness of this technique.

The idea that HTML5 is a privacy risk is FUD. It doesn’t provide any worse security than anything else already out there. It’s actually easier to counteract than what’s already being used since it’s handled by the browser.

The Future

I still believe all browsers out there can do a much better job of protecting privacy when it comes to local data storage for the purpose of tracking. What I believe what needs to happen is web browsers need to start moving away from the “cookie manager” interfaces that are now a decade+ old and move towards a “my data management” interface that lets users view and delete more than just cookies. It needs to encompass all the storage methods listed above as supported by the browser. Hooks should also exist so that plug-ins that have data storage (like Flash) can also be dealt with using the same UI.

Additionally it needs to be possible to control retention policies per website. For example I should be able to let Google storage persist indefinitely, Facebook for 2 weeks, and Yahoo for the length of my browser session should I wish.

My personal preference would be for a website to denote the longest storage time for any object on a webpage in the UI. Clicking on it would give a breakdown of all hostnames that makeup the page, what they are storing and let the user select their own policy. With 2 clicks I could then control my privacy on a granular level. For example visiting SafePasswd.com would give me a [6] in the UI. Clicking would show me a panel this:

+------------------------------------------------------------------------------+
| My Data Settings for SafePasswd.com:                                         |
|                                                                              |
|  Host                        Longest Requested Lifespan    Your Choice       |
|                                                                              |
| *safepasswd.com              2 years                       [site default]    |
| googleads.g.doubleclick.net  6 years                       [browser session] |
|                                                                              |
|                                                                              |
|                                                       (Done)  (Cancel)       |
+------------------------------------------------------------------------------+

I could then override googleads.g.doubleclick.net to be for the browser session via the drop down if that’s what I wanted. I could optionally forbid it from saving anything if that’s what I wanted. I could optionally click-through for more detail or view the data to help me make my decision. Perhaps this would also be a good place for P3P like data to be available. One of the notable failures of P3P that impeded usage was it was never easy to view so it never caught on.

The browser would then remember I forbid googleads.g.doubleclick.net from storing data beyond my browser session. This would apply to googleads.g.doubleclick.net regardless of what website it was used on.

This model works better than the “click to confirm cookie” model that only a handful of people on earth ever had the patience for. It provides easy access to control and view information with minimal click-throughs.

It also makes a web page much more transparent to an end-user who could then easily see who they are interacting with when they visit one webpage with several ads, widgets, social media integration points etc.

One click to view data policies, two clicks to customize, three to save.

HTML5 is not a risk here. The web moving to HTML5 is like going from the lawless land to a civilized society where structure and order rule.

Categories
Mozilla Security

Decrypting The Internet

Bruce Schneier on the new wiretapping proposal:

Any surveillance system invites both criminal appropriation and government abuse. Function creep is the most obvious abuse: New police powers, enacted to fight terrorism, are already used in situations of conventional nonterrorist crime. Internet surveillance and control will be no different.

Official misuses are bad enough, but the unofficial uses are far more worrisome. An infrastructure conducive to surveillance and control invites surveillance and control, both by the people you expect and the people you don’t. Any surveillance and control system must itself be secured, and we’re not very good at that. Why does anyone think that only authorized law enforcement will mine collected internet data or eavesdrop on Skype and IM conversations?

I 100% agree here. A security vulnerability, intentional or not is a vulnerability. Even systems with no known security holes are eventually broken. Look at the recent reverse engineering of HDCP, which was theorized as vulnerable in 2001 but not broken for several years, a pretty good run. Eventually all security mechanisms will be broken. Starting with something broken just increases the window of opportunity for abuse and misuse.

In theory this proposal could (I’m no lawyer, I don’t even play one on TV) even impact things like Firefox Sync (Formerly Weave) which employs the best security mechanism I’ve seen in a service. To summarize, it works by encrypting your data before transmission to the server. However the key is never sent. That means even if the Gestapo took the servers with your data, they would still need to get the key from you, or do battle with the encryption which isn’t easy. Even Mozilla can’t read your data, unless a flaw were found in the encryption algorithm. The question is if sync were considered to fall under “services that enable communications”. That seems broad enough to leave room to argue that sync facilitates communication since the browser is the ultimate communication client. The browser is also valuable since it potentially has passwords, bookmarks, and history giving a good motivator to make that argument. Argue that to a 75-year-old judge who never used a computer and it might work.

Meanwhile just weeks ago UAE ironically gets criticized by the US for proposing a Blackberry ban for the same reasons.

Categories
Security

More On Facebook Places Privacy

Via NY Times:

“I like Foursquare because I can actually pick who sees where I actually am, compared to Facebook, where I have 1,200 friends,” she said. “I don’t want 1,200 people knowing where I am.” Facebook does let users pick a smaller subgroup of friends who can see location updates, but MS. Lovelidge said it would be too much trouble to set that up.

Emphasis mine. This isn’t lost on Facebook. Zuckerberg himself said: “But guess what? Nobody wants to make lists”.

The problem is that for every MS. Lovelidge who at least acknowledges the risk and avoids it, there will be 10 others completely oblivious to the risks.

One great lesson here is that you can’t change the paradigm and assume an old security model, in this case the “friends” network will continue to work. This is the equivalent to turning a store into a private residence without bothering to replace the open store front with a more traditional door.

Categories
Security

Sharing Location With Strangers Via Facebook Places

Twice in a weeks time [1, 2] I’ve suggested that teens in particular have more “friends” than friends. AOL apparently did some of the research for me regarding the prevalence:

…more than half of the children surveyed (54%) don’t personally know all of the friends…

54% of teens surveyed don’t know all their “friends”. Facebook defaults the privacy settings on places to “friends”. 54% of children surveyed will likely be sharing their current location with people they don’t personally know. Places will catch on, especially once the check-in games start coming up and it becomes more fun and competitive. Half will likely share their location with people they don’t know.

Think about this for a second. Just a few years ago society would have found the idea of teenagers revealing their current location to people they don’t even personally know to be insanity.

It’s easy to fix, just setup a group and include/exclude as desired. The problem is awareness of the problem is low. Also problematic is the desire and patience to sort through several hundred “friends” and bucket people.

It would also be easy for Facebook to fix by forcing users to either select specific groups or individuals rather than just defaulting to the overly broad “friends”. They have the UI, and it’s actually pretty good (I’ve got some gripes, but they don’t apply to 99.9% of the population) they just don’t make users go through it for the sake of simplicity.

I don’t really like this.

Categories
Security

More On Facebook “Friends” And Privacy

Last week when I wrote about the risks of Facebook Places I specifically said:

Decisions on who qualifies as a friend may have been made a few years ago when the risks were different and content being exposed was much less harmful. Letting a stranger see your obnoxious status update is different than letting them know where you are.

MG Siegler at TechCrunch just realized this himself and cut the number of friends he had in half. To quote:

Facebook is mutating. The problem is that the original social graph isn’t built for this mutation. And we’re going to see that very clearly with things like this new location element.

I’d argue MG Siegler is brighter and more in tune to this sort of thing than 90%+ of Facebook users. Perhaps 99%. If he just realized this now, it’s going to take a long time for the more casual user to catch on.

As I wrote last week, the term “friend” has been grossly distorted over the past few years. I strongly suspect the most at risk users are the ones who distorted it the most. Defaulting things like Places to “friends” isn’t good enough.

You’ll be seeing more about this in the press over the coming several months. This is going to get messy as people leak information they didn’t intend to.

Categories
Security

The Real Risks Behind Facebook “Places”

Facebook made some peculiar decisions in the privacy rules for Facebook Places. The problem is hardly just a technical limitation, it’s endemic of the way social media has altered society and technology must help the user be aware and workaround it.

Categories
Internet Mozilla Security

Protecting Photo Privacy Via Browsers

Browsers can do more to protect users from inadvertently violating their own privacy. The NY Times today had an article about a topic that has been discussed in various circles several times now. The existence of geotagging data in photos. Many cameras, in particular smart phones like the iPhone can tag photos with GPS data. This is pretty handy for various purposes including organizing photos at a later date, iPhoto for example does a pretty nice job of it. Most photo applications however don’t make this information very visible, as a result many users don’t even know it exists, others simply forget.

What the problem looks like

The data, embedded in a photo looks something like this:

GPSLatitude                    : 57.64911
GPSLongitude                   : 10.40744
GPSPosition                    : 57.64911 10.40744

Which I could map.

Proposal

I propose that browsers need to have a content policy for when users upload images that can better protect them from uploading information they may not even realize. Here’s what I’m imagining:

The first time a user attempts to upload a photo that has EXIF or XMP data containing location they are prompted if they want it stripped from the image they are uploading. The original file remains unharmed, just the uploaded version won’t have the data. They can also choose to have the browser remember their preference to prevent being prompted in the future. They can revise their choice in the preferences window later if they want. This isn’t to different from how popups are handled. I thnk that per-site policy might be too confusing and not warranted, but perhaps I’m wrong.

Warning users about hidden information they may be revealing is a worthwhile effort. It’s only a matter of time before someone uses a “contest” or some other form of social engineering to solicit pictures that may reveal location data for users. Evildoers always find creative ways to exploit people.

Caveat

There are a notable caveat to this approach. The most notable is that flash uploaders would bypass this security measure though individual uploaders could do it themselves, or Adobe could do it, but I don’t think that’s enough of a turnoff to this approach. The same caveat applied to “private browsing” in browsers.

Prior Work

As far as I know no browser actually implements a security feature like this yet. There are a few Firefox Add-ons like Exif Viewer and FxIF (both written in pure JavaScript) that look at EXIF data but nothing that intercepts uploads.

Who Can Do It First?

I’m curious who can do it first. By add-on (seems like it should be possible at least in Firefox), and dare I say include in a browser itself? If this were earlier in the year I would have added this to the Summer of Code ideas list. Instead I’m just throwing it into the wind until 2011 rolls around.

Categories
Internet Security

DNSSEC Root Key

Bruce Schneier pointed out that DNSSEC root key has been divided among seven people for security:

Part of ICANN’s security scheme is the Domain Name System Security, a security protocol that ensures Web sites are registered and “signed” (this is the security measure built into the Web that ensures when you go to a URL you arrive at a real site and not an identical pirate site). Most major servers are a part of DNSSEC, as it’s known, and during a major international attack, the system might sever connections between important servers to contain the damage.

A minimum of five of the seven keyholders – one each from Britain, the U.S., Burkina Faso, Trinidad and Tobago, Canada, China, and the Czech Republic – would have to converge at a U.S. base with their keys to restart the system and connect eveything once again.

Based on this key signing video it looks like they are using smart cards and an AEP Keyper HSM for this critical task. Schneier suspects it implements the Shamir’s Secret Sharing algorithm.

Considering how much our economy and our lives rely on the Internet these days, DNS is becoming a more and more critical part of our society. This is a very big event. No precaution is too great to ensure security of such critical infrastructure.

Categories
Around The Web Security

Caffeine Algebra

This is a very interesting tidbit from LifeHacker about caffeine:

The effectiveness of caffeine varies significantly from person to person, due to genetics and other factors in play. The average half-life of caffeine—that is, how long it takes for half of an ingested dose to wear off—is about five to six hours in a human body. Women taking oral birth control require about twice as long to process caffeine. Women between the ovulation and beginning of menstruation see a similar, if less severe, extended half-life. For regular smokers, caffeine takes half as long to process—which, in some ways, explains why smokers often drink more coffee and feel more agitated and anxious, because they’re unaware of how their bodies work without cigarettes.

Assuming you know some of the variables at play here and track over an extended period (at least 1 month) so that you derive a baseline, you can essentially use algebra to solve for what you don’t know about a person, in particular for a woman based on their observable behavior regarding caffeine consumption and reaction. I recall reading between ovulation and menstruation it’s about 35-40% longer or roughly 9-10 hours. The half-life of a pregnant woman is 9-11 hours [cite].

In practice this would require some dedication as you need to derive a baseline and it would still never be truly accurate, but interesting regardless. I’m sure you can add other statistics and metrics to help improve the accuracy but again it wouldn’t be terribly accurate. Regardless I bet it would surprise some people.

It just shows how easily information is revealed through our mundane activities regardless of how well people conceal it. Psychology, chemistry, medicine, and security all in this one beverage consumption.

I’m sure you can come up with a more male specific scheme as well as many more gender neutral schemes. I just ran across this more female specific example and found it rather interesting.