On Deprecating HTTP

Mozilla announced:

There’s pretty broad agreement that HTTPS is the way forward for the web. In recent months, there have been statements from IETF, IAB (even the other IAB), W3C, and the US Government calling for universal use of encryption by Internet applications, which in the case of the web means HTTPS.

I’m on board with this development 100%. I say this as a web developer who has, and will face some uphill battles to bring everything into HTTPS land. It won’t happen immediately, but the long-term plan is 100% HTTPS . It’s not the easiest move for the internet, but it’s undoubtedly the right move for the internet.

A brief history

The lack of encryption on the internet is not to different from the weaknesses in email and SMTP that make spam so prolific. Once upon a time the internet was mainly a tool of academics, trust was implicit and ethics was paramount. Nobody thought security was of major importance. Everything was done in plain text for performance and easy debugging. That’s why you can use telnet to debug most older popular protocols.

In 2015 the landscape has changed. Academic use of the internet is a small fraction of its traffic. Malicious traffic is a growing concern. Free sharing of information, the norm in the academic world is the exception in some of the places the internet reaches.

Protecting the user

Users deserve to be protected as much as technology will allow. Some folks claim “non-sensitive” data exist. I disagree with this as it’s objective and a matter of personal perspective. What’s sensitive to someone in a certain situation is not sensitive to others. Certain topics that are normal and safe to discuss in most of the world are not safe in others. Certain search queries are more sensitive than others (medical questions, sensitive business research). A web developer doesn’t have a good grasp of what is sensitive or not. It’s specific to the individual user. It’s not every network admin’s right to know if someone on their network browsed and/or purchased pregnancy tests or purchased a book on parenting children with disabilities on Amazon. The former may not go over well at a “free” conservative school in the United States for example. More than just credit card information is considered “sensitive data” in this case. Nobody should be so arrogant as to think they understand how every person on earth might come across their website.

Google and Yahoo took the first step to move search to HTTPS (Bing still seems to be using HTTP oddly enough). This is the obvious second step to protecting the world’s internet users.

Protecting the website’s integrity

Michelangelo David - CensoredUnfortunately you can no longer be certain a user sees a website as you intended it as a web developer. Sorry, but it doesn’t work that way. For years ISP’s have been testing the ability to do things like insert ads into webpages. As far as I’m aware in the U.S. there’s nothing explicitly prohibiting replacing ads. Even net neutrality rules seem limited to degrading or discriminating against certain traffic, not modifying payloads.

I’m convinced the next iteration of the great firewall will not explicitly block content, but censor it. It will be harder to detect than just being denied access to a website. The ability to do large-scale processing like this is becoming more practical. Just remove the offending block of text or image. Citizens of oppressed nations will possibly not notice a thing.

There’s also been attempts to “optimize” images and video. Again even net-neutrality is not entirely clear assuming this isn’t targeted to competitors for example.

But TLS isn’t perfect!

True, but let’s be honest, it’s 8,675,309 times better than using nothing. CA’s are a vulnerability, they are a bottleneck, and a potential target for governments looking to control information. But browsers and OS’s allow you to manage certificates. The ability to stop trusting CA’s exists. Technology will improve over time. I don’t expect us to be still using TLS 1.1 and 1.2 in 2025. Hopefully substantial improvements get made over time. This argument is akin to not buying a computer because there will be a faster one next year. It’s the best option today, and we can replace it with better methods when available.

SSL Certificates are expensive!

First of all, domain validation certificates can be found for as little as $10. Secondly, I fully expect these prices to drop as demand increases. Domain verification certificates have virtually no cost as it’s all automated. The cheaper options will experience substantial growth as demand grows. There’s no limit in “supply” except computing power to generate them. A pricing war is inevitable. It would happen even faster if someone like Google bought a large CA and dropped prices to rock bottom. Certificates will get way cheaper before it’s essential. $10 is the early adopter fee.

But XYZ doesn’t support HTTPS!

True, not everyone is supporting it yet. That will change. It’s also true some (like CDN’s) are still charging insane prices for HTTPS. It’s not practical for everyone to switch today. Or this year. But that will change as well as demand increases. Encryption overhead is nominal. Once again pricing wars will happen once someone wants more than their shopping cart served over SSL. The problem today is demand is minimal, but those who need it must have it. Therefore price gouging is the norm.

Seriously, we need to do this?

Yes, seriously. HTTPS is the right direction for the Internet. There’s valid arguments for not switching your site over today, but those roadblocks will disappear and you should be re-evaluating where you stand periodically. I’ve moved a few sites including this blog (SPDY for now, HTTP/2 soon) to experience what would happen. It was largely a smooth transition. I’ve got some sites still on HTTP. Some will be on HTTP for the foreseeable future due to other circumstances, others will switch sooner. This doesn’t mean HTTP is dead tomorrow, or next year. It just means the future of the internet is HTTPS, and you should be part of it.

Google Giving Preference To SSL

Looks like I beat this one by a few months. SSL is now a ranking signal for Google. I switched this and a few other sites over to SSL a few months ago, while enabling SPDY and a few other things I’m playing around with. So far this has been pretty painless and actually simplified a few things. Doing this at scale with legacy infrastructure and 3rd parties however is a whole different ballgame. It will take a while for this switch to happen for bigger players not already on board.

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
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.