Showing posts with label ssl. Show all posts
Showing posts with label ssl. Show all posts

Thursday, November 11, 2010

Thoughts on Microsoft's Hotmail SSL deployment

Update 10:00pm: I was contacted by an extremely well informed individual who told me that my speculation about Microsoft's webserver SSL performance was completely wrong. The individual declined to reveal the reason why the company opted to make SSL opt-in, which makes the decision even more curious. Why expose users to needless security risks if protecting them doesn't require significant additional computing resources.


On November 9, Microsoft rolled out opt-in HTTPS (SSL) protection for its Hotmail service, which came just a couple weeks after Firesheep made the importance of such security measures quite clear. For those of you just tuning in to SSL issues, Microsoft's announcement might seem like a great move. This blog post will explain why Microsoft deployed this security enhancement, why it hasn't done it by default, and why it should.

Background

Over the past few years, researchers released several security tools that automated the capture of credentials and session cookies, allowing an attacker to easily hijack user accounts that were logged into over an insecure wifi connection. In October, 2008, Mike Perry released Cookiemonster, which made session hijacking against several major popular web 2.0 services even easier. Across the board, webmail and social networking services totally ignored the individual pleas from security researchers and academics that they protect their users by default. Google offered SSL, but disabled it by default, and the other big companies, Facebook, Microsoft, Yahoo, didn't offer SSL at all.

Fed up with the lack of any progress, in June 2009, I published an open letter to Google's CEO, asking him to protect his customers and deploy SSL default. 37 other big name security researchers, academics and legal experts signed on, helping to get a bit of press attention. Google soon said they'd begin to study the possibility of deploying SSL by default, and then in January 2010, the company did it -- encrypting every Gmail users' entire session by default.

In addition to publishing the open letter, I sent copies of it to privacy bigshots at both Microsoft and Facebook, and told them, essentially, "don't make me write a letter for you too." Individuals at both companies thanked me for the warning, and told me they were looking into the possibility of offering SSL.

In March 2010, outgoing FTC Commissioner Pamela Jones Habour spent much of her final public speech talking about SSL.
Even though these service providers know about the vulnerabilities, and the ease with which they can be exploited, the firms continue to send private customer information over unsecured Internet connections that easily could have been secured.

My bottom line is simple: security needs to be a default in the cloud. Today, I challenge all of the companies that are not yet using SSL by default. That includes all email providers, social networking sites, and any website that transmits consumer data. Step up and protect consumers. Don’t do it just some of the time. Make your websites secure by default.
Commissioner Habour's remarks were, to my knowledge, the first time a senior government official had ever weighed in on the issue. The fact that this happened seven months after I joined the FTC is entirely coincidental.

Microsoft's move towards SSL

Just one month later, in April 2010, Microsoft announced that they too would soon offer SSL, although not by default. Fast forward to November 9, 2010, and Microsoft has made good on its promise.

Users who go out of their way to type https://www.hotmail.com will now receive protection for just that session. Furthermore, the first time users type in the https URL, they see a helpful dialog offering to make SSL the default for future connections.



The dialog states that Microsoft recommends the use of HTTPS by default. The problem with this, of course, is that Microsoft only shows this dialog to consumers who know enough about SSL to have visited the secure version of hotmail in the first place.

Consumers who do not know about the risks of using Hotmail over an insecure wifi connection will never see this dialog, and will thus not know that Microsoft recommends they use SSL by default.

That isn't the only way that Hotmail users can discover the availability of SSL and turn it on.

Hotmail users who regularly read the Inside Windows Live blog may have seen Microsoft's announcement of its SSL deployment, where the company announced a special URL that Hotmail users can visit to set the SSL preference: https://account.live.com/ManageSSL (shown below).



Curiously, neither the Inside Windows Live blog, nor the special ManageSSL web page state that Microsoft recommends the use of SSL by default, and the ManageSSL web page even has the "Don't use HTTPS automatically" option pre-selected by default.

Realistically, the vast majority of Hotmail users simply type "www.hotmail.com" into their browser, and do not read the Inside Windows Live blog, and so will be completely unaware that Microsoft now offers an SSL option. There is no mention of SSL on the regular Hotmail front page.

These users are not completely out of luck, as there is a preference within the Hotmail options that they can flip to enable SSL by default. From within their Hotmail Inbox, they need to click on "Options", then "More Options", then "Account details (password, aliases, time zone)", then "Connect with HTTPS" (the last option on the page), then "Use HTTPS automatically", and finally, click "save". See, that was easy. It only took 6 mouse clicks.

Why Microsoft doesn't use SSL by default for Hotmail

At the same time as Microsoft started to offer SSL as an option for Hotmail, it also enabled SSL by default for its SkyDrive, Photos, Docs, and Devices products. What is the difference between these services? Hotmail has lots of users, and no one uses Photos or Skydrive. Simply put, it is easy (and cheap) to deploy SSL for a service when it only has a few (hundred?) thousand users. Hotmail, which reportedly has over 500 million users, is a bit more expensive to protect.

"Wait a minute.. didn't Google say they didn't need any additional servers for SSL?" you may ask. Yes, it's true. Google was able to deploy SSL by default on their their existing servers, and according to Adam Langley, a senior Google engineer, after tweaking the OpenSSL library used by Google, SSL accounts for just 1% of the CPU overhead on those servers.

However, Google has a top notch server infrastructure, running on Linux, and a lot of really skilled engineers. Microsoft, on the other hand, uses their own products.

While Microsoft doesn't reveal too many details about the infrastructure hosting Hotmail, from Netcraft, we can see that they are using their own IIS/6.0 webserver (Netcraft lists the OS as Linux, but that is because Akamai is sitting in front of Microsoft's servers). It is of course understandable that Microsoft likes to use its own products -- unfortunately, the IIS webserver isn't very good, does not use OpenSSL, and thus SSL likely consumes quite a bit more CPU than the 1% hit that Google described.

As such, I suspect that Microsoft has instead opted to either: Pay Akamai to take care of SSL, or the company bought a large number of off the shelf SSL accelerator devices. In either case, SSL is likely costing Microsoft real money -- and, given that the company's Online Services Division lost half a billion dollars last year, it isn't too surprising why the company might be keen to try and keep its SSL related costs to a minimum.

Simply put, if Microsoft is paying a direct financial cost for SSL, then it is easy to understand why it is not offering SSL to its 500 million hotmail users by default.


What should Microsoft (and other companies) do?

When it comes to privacy and security, I think that the government can play a really important role in protecting consumers, particularly when the market has failed to deliver products that are safe by default. The problems that Firesheep has highlighted existed for years, in fact, as long as Hotmail or Facebook have existed, they have been vulnerable to account hijacking. These companies have had more than enough time to protect their customers, and have simply ignored the problem.

While I do think that privacy regulators can play a role here, I don't think it is appropriate for regulators to require that companies deliver specific products -- things get very messy when technology-ignorant bureaucrats mandate product features. However, I do think that governments can, and should compel those companies that have not protected their customers by default to at least warn users about the risks.

Earlier this year, I published a law journal article about encryption in the cloud -- which specifically focuses on fact that most services don't even offer SSL, let alone turn it on by default. In that article, I argue that if companies do not wish to protect their customers, they should at least warn them about the risks of connecting to their services when using an insecure wifi connection. Knowing that companies are unlikely to voluntarily provide such notices, I call on the government to compel the display of cigarette packet style warnings for insecure cloud based services, such as:

WARNING: Email messages that you write can be read and intercepted by others when you connect to this service using a public network (such a wireless network at a coffee shop, public library or school). If you wish to protect yourself from this risk, click here for a secure version of this service.

WARNING: The word processing documents that you create using this service can be read and modified by others when you connect to this site using a public network (such a wireless network at a coffee shop, public library or school). Widely available technologies exist that will protect you from these risks, but this service provider has opted to not offer such protective functionality.


Of course, I suspect that Microsoft and Facebook would rather eat the financial cost of deploying SSL, even if it runs into the millions of dollars, rather than display such a scary warning.. and that is exactly the point. Simply by forcing companies to reveal known risks in their products, governments can gently nudge companies to protect their customers.

Tuesday, June 16, 2009

An open letter to Google

This six page letter (pdf) to Google's CEO, Eric Schmidt, is signed by 38 researchers and academics in the fields of computer science, information security and privacy law. Together, they ask Google to honor the important privacy promises it has made to its customers and protect users' communications from theft and snooping by enabling industry standard transport encryption technology (HTTPS) for Google Mail, Docs, and Calendar.

Google already uses industry-standard Hypertext Transfer Protocol Secure (HTTPS) encryption technology to protect customers' login information. However, encryption is not enabled by default to protect other information transmitted by users of Google Mail, Docs or Calendar. As a result, Google customers who compose email, documents, spreadsheets, presentations and calendar plans from a public connection (such as open wireless networks in coffee shops, libraries, and schools) face a very real risk of data theft and snooping, even by unsophisticated attackers. Tools to steal information are widely available on the Internet.

Google supports HTTPS encryption for the entire Gmail, Docs or Calendar session. However, this is disabled by default, and the configuration option controlling this security mechanism is not easy to discover. Few users know the risks they face when logging into Google's Web applications from an unsecured network, and Google.s existing efforts are little help.

Support for HTTPS is built into every Web browser and is widely used in the finance and health industries to protect consumers. sensitive information. Google even uses HTTPS encryption, enabled by default, to protect customers using Google Voice, Health, AdSense and Adwords. Google should now extend this degree of protection to users of Gmail, Docs and Calendar.

Rather than forcing its customers to "opt-in" to adequate security, Google should make security and privacy the default.




View the full letter at cloudprivacy.net

Saturday, February 24, 2007

My blog post leads to congressional investigation of TSA

Woot!

Wired News is reporting that Henry Waxman - acting as chairman of the powerful House Committee on Oversight and Government Reform - has sent a letter to Kip Hawley, TSA director, demanding information on TSA's shamefully insecure and phishy TRIP website.

The letter, in its full glory, can be found here (pdf).

I was the first person to notice the website, and its lack of SSL encryption. I tipped off Ryan Singel of Wired News, and Brian Krebs from the Washington Post. There have been a couple articles written about the story so far...

I'm crossing my fingers, and hoping for hearings...

Tuesday, February 20, 2007

New TSA Website back online - Now Less Phishy

Both Ryan Singel of Wired News, and Brian Krebs of the Washington Post picked up the story of TSA's extremely amateurish looking website last week.

The website was hosted by a private company, did not use SSL, did not have a OBM form number, and was riddled with typos - sure signs that you shouldn't trust it, and enough reason for some to claim (albeit humorously), that it was a phishing site.. After a few phone calls from members of the press, TSA pulled the website.


The TSA Traveler Identity Verification Program website still tells passengers to download and fill out a .pdf form. However,
just like a shady, perpetual going-out-of-business sale retailer, TSA's website has resurfaced again, only this time, with a new name. It isn't linked to yet from the main TSA.gov site, but can be found via links from dhs.gov

The new website is: https://trip.dhs.gov/.

New improvements:


  1. http is redirected to https. Thus, even if their webmasters make future mistakes, and forget to link to the secure website, their webserver will redirect all non-secure content to their secure server. Good move! Try it. Go to http://trip.dhs.gov and watch as your browser gets redirected to https://trip.dhs.gov/.

  2. OBM Control Number. Any collection of personal information by the government is required to include a OBM Control Number. This was absent from their previous website, and as reportedly, from the Microsoft Word file previously available for download. You can view their Paperwork Reduction Act Statement (which includes their OBM #1652-0044) here: https://trip.dhs.gov/pra.htm

  3. No more word documents! They previously had a MS-word file available for download, if you didn't wish to send your information to their outsourced webserver. Predictably, this ms word file included meta-data on who at TSA had edited the file. They have now shifted to a pdf file.


Problem: It is still outsourced.

Both http://www.tsa.gov and http://www.dhs.gov are served by akamai distributed proxies, so it's impossible to figure out where they're actually being hosted.

However, someone from TSA visited my website last month, so I do know that TSA's outbound web proxies are:

pnxuser1.tsa.dhs.gov A 129.33.119.12
pnxuser2.tsa.dhs.gov A 129.33.119.13
pnxuser3.tsa.dhs.gov A 129.33.119.14
pnxuser4.tsa.dhs.gov A 129.33.119.25
pnxuser5.tsa.dhs.gov A 129.33.119.26

(Note, this is why Tor is useful)

Additonally, http://tsa.dhs.gov (which runs a webserver, albeit not one configured for public viewing) resolves to:
tsa.dhs.gov A 129.33.119.130

TSA's new website, http://trip.dhs.gov, resolves to
trip.dhs.gov A 64.124.212.23

Now, it's quite possible that TSA/DHS own a number of chunks of ip address space. All i'm stating here, is that the ip addresses are known to be owned by TSA/DHS are nowhere near the ip used by the trip.dhs.gov website.

I don't know the ip address of the old website rms.desyne.com - since it is no longer listed in DNS records. However, www.desyne.com resolves to 64.124.142.34.

Furthermore, a traceroute of http://trip.dhs.gov, and http://www.desyne.com leads me to believe that they're both hosted in the same data-center. I'd be willing to bet a couple Fin Du Monde beers that even with a change of DNS, that desyne is still running and hosting TSA's Traveler Redress Inquiry Program (TRIP) website.



traceroute to trip.dhs.gov (64.124.212.23), 30 hops max, 38 byte packets

.....

12 so-5-0-0.mpr2.iad1.us.above.net (64.125.27.209) 81.561 ms 118.933 ms 84.338 ms
13 so-3-0-0.mpr1.iad2.us.above.net (64.125.29.134) 82.985 ms 81.489 ms 83.893 ms
14 * * *

traceroute to www.desyne.com (64.124.142.34), 30 hops max, 38 byte packets

.....

12 so-5-0-0.mpr2.iad1.us.above.net (64.125.27.209) 84.352 ms 83.722 ms 84.142 ms
13 so-3-0-0.mpr1.iad2.us.above.net (64.125.29.134) 82.005 ms 82.326 ms 83.552 ms
14 * * *




Problem: It still uses cookies!

As Ryan Singel expertly notes, 2003 White House OBM rules state that government websites should not use cookies: "Particular privacy concerns may be raised when uses of web technology can track the activities of users over time and across different web sites. [...] Because of the unique laws and traditions about government access to citizens' personal information, the presumption should be that "cookies" will not be used at Federal web sites."

Ryan additionally states: If cookies are going to be used, the rules require that the site include "clear and conspicuous notice" of the cookies, that there exists a "a compelling need to gather the data on the site," that there are "appropriate and publicly disclosed privacy safeguards" for cookie information, and that the head of the agency personally approves the cookies.

When I browse to both http://www.tsa.gov, and this new unannounced TSA website, I am given a web cookie - "ForeseeLoyalty_MID_8El4YcUdgN".

Admittedly, this is not nearly as big a problem as their un-SSL encrypted webserver. However, I want TSA to have to follow the rules. Especially since they make us follow them, even in cases where they won't actually tell us what the rules are.

The big question is: If TSA is following official US government policy, Kip Hawley, Director of TSA will have signed off on the use of cookies for TSA's website. Did he indeed sign off? Inquiring minds wish to know.

Tuesday, February 13, 2007

TSA has outsourced the TSA Traveler Identity Verification Program?

Feb 20 2007 Update: TSA took the site down, and has put it back up again. They've fixed a few of the problems, but the website is still outsourced, and still uses cookies (a violation of federal policy). See more here


Browsing TSA's website this evening, I came across a link to the new TSA Traveler Identity Verification Program.

"The TSA Traveler Identity Verification Program is designed to assist those airline passengers who have been delayed or prevented from traveling as a result of TSA's security measures."

The site is specifically aimed at passengers who have suffered from any of the following problems:

* Unable to print Boarding Pass at Kiosk/Home
* Directed to Ticket Counter every time I fly.
* Ticket Agent states that I am on a Federal Government Watch List
* Missed flight while attempting to obtain boarding pass

You can submit a handy-dandy form online to register your request/complaint.

Two things immediately jump out at me.

1. You are required to enter sensitive information from three of the following forms of identification:

A non-U.S. Passport, Voter Registration Card, Immigrant Visa, Driver's License, Birth Certificate, Government Identification Card, Naturalization Card, Military Identification Card, Certificate of Citizenship, DD Form 214.

These are very sensitive bits of info. A drivers licence number in particular, is often used by banks (due to Patriot Act provisions) to authenticate you when you open an account.

Worst of all - the form you submit doesn't go over an SSL connection! It goes plaintext over the wire. Heaven forbid you do this from an airport starbucks after being denied boarding, as anyone could sniff your info.

The relevant bit of code in question: form method=POST action=/pivf.htm

Now, they do at least have a ssl webserver running at https://rms.desyne.com/. But they're using a self-signed cert.

Update: I want to make it clear. I've only tested this by pressing submit on an empty form, and by viewing the source code to the form. To tell for sure, I'd have to submit a request to TSA - with bogus data.. and my now finely tuned "will TSA investigate me for this" radar tells me that submitting false information to an official government request form is a bad bad idea.

I searched the source for the words "https" - nothing.
I also found the 'form method' section, where it describes how the form is submitted.
It's quite possible that the creators of the website have created some kind of url-rewriting javascript sneaky tricks - although Occam's Razor leads me to believe that a simple mistake on a web designer's part is far more likely....

2. Unlike the rest of the TSA website, this is served from a different domain: http://rms.desyne.com/

Which means that a private company is running this site...

The whois database shows as follows:

Administrative Contact, Technical Contact:
Desyne, Inc. dns@DESYNE.COM
Desyne Web Services, Inc.
PO Box 143
Boston, VA 22713
US
(703) 391-2400 fax: (703) 391-2550


Record expires on 21-Mar-2015.
Record created on 20-Mar-1996.
Database last updated on 13-Feb-2007 21:32:10 EST.



This begs the question: Who are these guys, why don't they know how to use SSL and how were they awarded this sweet contract?

Why can't TSA do a simple form submission themselves?