You wouldn’t write your username and passwords on a postcard and mail it for the world to see, so why are you doing it online? Every time you log in to Twitter, Facebook or any other service that uses a plain HTTP connection, that’s essentially what you’re doing.
There is a better way, the secure version of HTTP — HTTPS. That extra “S” in the URL means your connection is secure, and it’s much harder for anyone else to see what you’re doing. But if HTTPS is more secure, why doesn’t the entire web use it?
HTTPS has been around nearly as long as the web, but it’s primarily used by sites that handle money — your bank’s website or shopping carts that capture credit card data. Even many sites that do use HTTPS use it only for the portions of their websites that need it — like shopping carts or account pages.
Web security got a shot in the arm last year when the FireSheep network-sniffing tool made it easy for anyone to detect your login info over insecure networks — your local cafe’s hotspot or public Wi-Fi at the library. That prompted a number of large sites to begin offering encrypted versions of their services on HTTPS connections.
Even sites like Twitter (which has almost entirely public data anyway) are nevertheless offering HTTPS connections. You might not mind anyone sniffing and reading your Twitter messages en route to the server, but most people don’t want someone also reading their username and password info. That’s why Twitter recently announced a new option to force HTTPS connections (note that Twitter’s HTTPS option only works with a desktop browser, not the mobile site, which still requires manually entering the HTTPS address).
Google has even announced it will add HTTPS to many of the company’s APIs. Firefox users can go a step further and use the HTTPS Everywhere add-on to force HTTPS connections to several dozen websites that offer HTTPS, but don’t use it by default.
So, with the web clearly moving toward more HTTPS connections, why not just make everything HTTPS?
There are some practical issues most web developers are aware of, such as the cost of secure certificates, but obviously that’s not as much of an issue with large web services that have big budgets.
The real problem seems to be that with HTTPS you lose the ability to cache. Not really an issue when servers and clients are in the same continent), but people in Australia (for example) looking at UK content will have better experiences when something can be cached and served without a huge response time.
There’s another small performance hit when using HTTPS, since the SSL initial key exchange adds to the latency.
For sites that don’t have any reason to encrypt anything — in other words, you never log in, so there’s nothing to protect — the overhead and loss of caching that comes with HTTPS just doesn’t make sense. However, for big sites like Facebook, Google Apps or Twitter, many users might be willing to take the slight performance hit in exchange for a more-secure connection. And the fact that more and more websites are adding support of HTTPS shows that users do value security over speed, so long as the speed difference is minimal.
Another problem with running an HTTPS site is the cost of operations. Although servers are faster, and implementations of SSL more optimised, it still costs more than doing plain HTTP, while less of a concern for smaller sites with little traffic, HTTPS can add up, if your site suddenly becomes popular.
Perhaps the main reason most of us are not using HTTPS to serve our websites is simply that it doesn’t work with virtual hosts. Virtual hosts, which are what the most common cheap web-hosting providers offer, allow the web host to serve multiple websites from the same physical server — hundreds of websites all with the same IP address. That works just fine with regular HTTP connections, but it doesn’t work at all with HTTPS.
There is a way to make virtual hosting and HTTPS work together — the TLS Extensions protocol — but it’s noted that, so far, it’s only partially implemented. Of course that’s not an issue for big sites, which often have entire server farms behind them. But until that spec — or something similar — is widely used, HTTPS isn’t going to work for small, virtually hosted websites.
In the end there is no real reason the whole web couldn’t use HTTPS. There are practical reasons why it isn’t happening today, but eventually the practical hurdles will fall away. Broadband speeds will improve, which will make caching less of a concern, and improved servers will be further optimized for secure connections.
In the future the main concern won’t just be how fast a site loads, as that’ll become an obsolete consideration, but moreover how well it safeguards and protects our data surely?
(cred’ to WebMonkey for the background detail)
