Facebook Going HTTPS

Apparently HTTPS is going to be standard for all Facebook users:

As announced last year, we are moving to HTTPS for all users. This week, we’re starting to roll out HTTPS for all North America users and will be soon rolling out to the rest of the world.

Great move, I’m glad they are finally getting to that point. Performance should improve over time as it appears they are on board with SPDY. I think that this will benefit them in the long run. Users win the day it rolls out.

UK Wants to MITM SSL Connections to Facebook/Gmail

The UK Government wants ISP’s to record secure transmission of messages with services like Facebook and Gmail, which are currently using SSL. I’d be curious to know how the UK government actually plans to pull this off. To pull that off they’d need to get browsers to include their root certificate so they can MITM Gmail and Facebook. I can’t see that happening.

Of course anyone really wanting to do something criminal will just employ a VPN to tunnel past these ISP’s, or encrypt messages using GPG. Therefore, I don’t see what the point is.

Even DHS Blindly Accepts Invalid SSL Certificates

Via Forbes:

On page 37, DHS instructs analysts to accept invalid SSL certificates forever without verification. Although invalid SSL warnings often appear in benign situations, they can also signal a man-in-the-middle attack. Not a good practice for the security conscience.

I think that’s grounds for termination by incompetence for whomever was behind that. DHS Phishing attack anyone? I’d expect better practices from a local library branch.

That said, it’s yet more proof that SSL as a form of identity verification just doesn’t work.

How To Configure SSL For Apache Securely

I’ve been doing some reading up on best practices for SSL. From what I can gather, and seeing what other big sites are doing this seems to be the best practice as of today. This is assuming you’re in an OpenSSL 0.9.x (via mod_ssl) and Apache2 world, which is the majority of Linux/Unix based environments. Use a 2048 bits key SHA1 signed cert. Which is now pretty much standard.

SSLHonorCipherOrder On
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

That will disable potentially insecure cyphers and help mitigate a BEAST attack. Note that this disables SSL 2.0 which shouldn’t be necessary for the vast majority of visitors. I don’t think many websites still support it.

Use SSL By Default

Twitter is now the latest site defaulting to HTTPS. Kudos to them. I love seeing the web get more secure, even if it’s one site at a time.

If you’ve got a site where login is required, please make sure to use SSL. It’s not that costly anymore. Even this blog uses SSL where necessary.

It’s not needed for general public consumption things (like this webpage), but anywhere a session can be hijacked or confidential data could be transfered, SSL is a good idea. When not possible to default, at least make it an option (I do this for safepasswd.com).

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.

The Future Of SSL

Google announced the other day that it will now enable HTTPS by default on Gmail. Previously a user had to either manually type in HTTPS or change a setting to default to it, something most people likely never bothered to do. Google says it’s not related but it seems oddly coincidental that this chance coincides with its China announcement.

However Gmail using HTTPS is not the big story here.

The big story is that HTTPS is now being used in places where it before was considered excessive. Once upon only financial information was generally sent over HTTPS. As time went on, so did most website login pages, though the rest of the sites often were unencrypted. The reason for being so selective is that it’s more costly to scale HTTPS due to it’s CPU usage on the server-side, and it’s performance on the client side. These days CPU is becoming very cheap.

In the next few years I think we’ll see more and more of the web switch to using HTTPS. If things like network neutrality don’t work this trend could accelerate at an even quicker rate just like it did for P2P using MSE/PE to mask traffic.

Like I said, these days the CPU impact is pretty affordable, however the performance impact due to HTTP handshaking can be pretty substantial. Minimizing HTTP requests obviously helps. HTTP Keepalive is a good solution however that generally results in more child processes on the server as they aren’t freed as quickly (read: more memory needed).

Mobile is a whole different ballgame since CPU is still more limited. I’m not aware of any mobile devices that have hardware to specifically handle SSL, which does exist for servers. Add in the extra latency and mobile really suffers. Perhaps it’s time to re-examine how various Crypto libraries are optimized for running on ARM hardware? I think the day will come where performance over SSL will matter as it becomes more ubiquitous.

Google AdSense And SSL

Google’s implementation of AdSense never ceases to amaze me. AdSense has been a major source of revenue for many websites for a few years now and has allowed many businesses to succeed where previously they would have had little chance. It’s a great program and I appreciate how it allows websites to monetize content quickly and with little effort. That said, I’m still so confused by Google’s implementation. It just doesn’t make much sense.

Since July 2007 Google AdSense has had the ability to crawl login protected pages so that it can scan (and therefore provide relevant ads) to pages behind logins. This is great since many pages on sites, in particular social networks where the the majority of page views are post-login can now be monetized.

Despite this progress, Google still doesn’t provide an SSL version of AdSense, so while the page itself can be served over SSL, the ad isn’t. This is problematic since the browser will alert the user that the page is not entirely secure. I really don’t understand why this can’t be done. Google does appear to scan these pages as the ads are relevant, so I don’t think the crawler is the issue. They just don’t want to serve ads over SSL.

Come on Google, the web would be a much more secure place if AdSense supported SSL. It would remove a big reason for sites to not use SSL in places that they should.

For those who would argue that putting third party ads on an SSL page defeats the purpose, that’s only partially true. Yes in an ideal world there’s no third party content on an SSL page. In the real world, Google already supports using SSL with Google Analytics (as do virtually all other analytics services), and you can bet almost any SSL page you access has some analytics on it already. This is no worse. If anything it’s better since unlike Analytics, the nature of the service involves much less recording of user behavior.

By not supporting SSL it’s just encouraging sites to not use it in places where a users privacy and security would be better off with it.

How To Be More Secure With Your Data & Identity

It’s amazing how on a daily basis there’s a story about someone’s identity or data being stolen, personal info being misused, or just getting screwed via the Internet. Most of the time it’s due to a complete lack of standards regarding how people treat their digital property and identity. It’s the electronic equivalent of leaving your home and not locking the door. Anyone can come in and take what they want.
Continue reading

First CVE

I just found out the other day I found my first bug worthy of being a CVE (Common Vulnerabilities and Exposures) Candidate: CVE-2008-3747. Low profile, but I guess still a potential vulnerability.

I must admit I didn’t know that the database is funded by the National Cyber Security Division of the United States Department of Homeland Security. I did know US-CERT was.