Facebook Introduces HTTPS Opt-In for Users, Impacts App Developers

In an article posted today on the Facebook Developer Blog, Facebook announced that they would be offering users the option to switch their Facebook experience to HTTPS-only, which would force all Facebook page loads to be routed over SSL.

According to the blog entry, this feature would be opt-in, and canvas application developers would need to provide an SSL url for the “Secure Canvas URL”.

If a user who has opted into the SSL-only version of Facebook attempts to access a Facebook Application that doesn’t have a Secure Canvas URL set, the user will evidently be shown a message (which will likely be confusing and scary, not because Facebook will purposefully make it so, but because most users don’t really understand SSL) that will give them the option to switch from HTTPS to HTTP. From the post:

If you do not provide a secure Canvas URL, we will display a confirmation page to let HTTPS users switch to HTTP and continue to your app.

This currently affects CANVAS apps only – not application tabs – although that may very well change once Facebook pushes the IFRAME version of tabs out some time in Q1.

HTTPS is slower and more server intense than HTTP, and it’s one more cost/timeline issue that has to be factored in. For some clients, I set up the hosting environment (which would include DNS, SSL, etc) – for others, their IT department provisions web space and handles DNS, and they often require a mountain of paperwork and a week to process.

For the latter scenario, the cost of the certificate is negligible, but for a highly-trafficked app, the increase in server load could have serious financial impact. It could mean the difference between needing one server and several.

For smaller companies, stepping up to SSL would mean buying a certificate and potentially paying extra for the dedicated IP address it will need, and if the app takes off, a much heftier hosting bill for running everything over SSL.

If the above would actually, truly improve the safety of the users in some significant way, I’d probably still be on-board.

Security is something I take very seriously, and in 2010, Firesheep showed the world how easy it was to hijack a user’s Facebook session and essentially pwn their account because the session data was being transmitted unencrypted and was sniffable over public wifi. To be fair, it wasn’t just Facebook that was affected, but if you’re logging into websites on an unencrypted public wifi, odds are your email accounts and everything else are at risk too.

That said, this seems like it will give naive users a false sense of security and not actually provide that much value for the effort involved by the app developers.

“Oh, this application must be safe – I’m using HTTPS, and the S stands for *secure*!”

Phishing, rogue apps and malware are already horrendous problems on social media websites, Facebook especially. I would much rather see Facebook (and others) improve their session handling before going in this direction. Reputable companies who are collecting any kind of PII are already running data submission over HTTPS, and non-reputable companies aren’t going to become more honest just by forcing them to encrypt the data they’re mining from your profile.

The net result is a lot of extra work for developers and companies for not a lot of benefit to not a lot of users, with the side effect of confusing people into thinking that SSL = trustworthy, or that a non-SSL app is malicious and trying to eat their souls.

IMHO, the much bigger threat to Facebook users is their own poor judgment on what to click on. Social engineering rules social networks, and no amount of encryption is going to fix that. As the fabulous shirt from Jinx says “there is no patch for human stupidity”.

Until people start being more critical of what they’re clicking on and what apps they’re allowing access to their profile, they’ve got a lot more to worry about than SSL. It’s the same false sense of security that users running antivirus programs often suffer from.

“I don’t need to worry about what I click on – I’m running antivirus! My virus definitions are up to date, so I am safe and protected and nothing can harm me.”

To prove my point, I’ve created FB Profile Spy. It’s still a work in progress, but it’s a better-security-through-humiliation project, similar to my better-behavior-through-humiliation project socialmediadouchebag.net. It’s completely safe – and not even hooked up to the Facebook API at all (but of course please feel free to use NoScript and check it out thoroughly before interacting with the links. I have nothing to hide.) Click through and “allow” the “app”. I need to tighten up the javascript slideshow lecture at the end and I need to sync up the layout with the new profile design, but it’s coming along.

What do you think? Am I just being a whine-ass lazy developer? Am I being a slacker security pundit? Let me know in the comments.

About the author

snipe

I’m a tech geek/dev/infosec-nerd/scuba diver/blacksmith/sword-fighter/crime fighter/ENTP/warcrafter/activist. I run Grokability, Inc, and run several open source projects, including Snipe-IT Asset Management. Tweet at me @snipeyhead or read more…

#1) I think the real eventual threat here is IPv4 space depletion – how many facebook apps are there? My cursory research is coming up with all kinds of numbers, but if we were to (eventually) get to a world where *every* FB app had SSL, every SSL connection will need its own IP (due to the layering of SSL and HTTP). This could cause serious, serious strain on available IPv4 space.

#2) Moving towards SSL is the *only* real way to start to protect peoples interactions with Facebook. If the login to FB is SSL protected, but the connection between FB and an app (let’s say, Farmville) is not – then something like Firesheep could be used to grab the FB->Farmville authorization token, then the Evil Third Party could use that to start making penis sculptures in the middle of people’s FB gardens. Or, as a less trivial example, imagine some kind of (innocent) app with a viral component – without SSL protecting the FB->app tokenization, that exchange could be exploited badly with some type of Man-In-The-Middle attack.

In terms of protecting users’ FB credentials, in the wake of Firesheep + Starbucks WiFi – what else could FB do? There may be something, but I don’t know what that could be. I *do* know that if that interaction is not encrypted, it can be sniffed, and played back. Maybe some kind of hash with a shared secret key (per-app)…and some kind of client-created-nonce, along with parameters – and FB’s job is to record the nonce and make sure it’s not re-used? There we go; maybe I *do* know what it could be 🙂 Though if the MITM attack was able to stop the original request from getting to FB, it would still be able to replay…well, it would just be able to replay the precise interaction that the end-user wanted to do, so maybe that would work…

I agree with respect to IPv4 – had meant to mention that in the article, but forgot, because I’m dumb.

I understand the importance of moving to SSL- and I don’t oppose them doing it. I think I’m just frustrated at the increase in cost and resources. The FB API is already HTTPS, so as an app dev, or as a small company who made an app, we’re being strong-armed into a significant increase in cost and resources. If we opt not to use SSL, users will see a message that will scare and confuse them. Again, there’s a chance I’m just being a whiny dev, but this has a huge impact on our clients – and I will probably end up taking down the FB apps I run personally, because I don’t want to pay the extra money for certs and IPs, and I don’t want to have to field the rating comments on the app from people who complain that it’s insecure. I’ve already had people accuse me of trying to *steal* their warcraft logins because of the WoW app I created. (It’s not even technically possible to steal creds using the API, but people are stupid and they write stupid things.)

I actually googled to find the answer, and it answered my question too.

Server Name Indication is an extension to allow the server to pass along the virtual host name as part of the initial handshake, so that the server knows which certificate to present prior to encryption being set up.

I’ve heard some people say “then a snooper will be able to tell which virtual host a visitor is visiting”

But of course, a snooper can do that already with the current system because the IP is unique 😀

Hmmm. I parse signed request for everything now too, so I guess I could do that too now.

The reason I originally split it, was when there was a problem with facebooks dns once, and the host lookups were causing the canvas connection to hang. But I still wanted to resolve user hosts.. I guess I’m just anal 😀

Search

About Me

I’m a tech geek/dev/infosec-nerd/scuba diver/blacksmith/sword-fighter/crime fighter/ENTP/warcrafter/activist. I run Grokability, Inc, and run several open source projects, including Snipe-IT Asset Management. Tweet at me @snipeyhead or read more…