LWN.net Logo

HTTPS Everywhere brings HTTPS almost everywhere

June 30, 2010

This article was contributed by Nathan Willis

Widespread end-to-end encryption for online communication often seems like a pipe dream: few email users bother with PGP, still fewer VoIP users ever use SRTP or ZRTP. But the one area where the general public has caught on to the need for secure transport channels is in web traffic, thanks to electronic commerce. The Electronic Frontier Foundation (EFF) recently released a Firefox extension called HTTPS Everywhere that leverages the widespread availability of HTTPS connections among popular Internet services. HTTPS Everywhere automatically rewrites URLs for a variety of providers, from software-as-a-service offerings to news outlets. The add-on is not configured to rewrite every URL by default, but it is a plug-and-play security enhancement.

In the initial HTTPS Everywhere announcement on June 17, Peter Eckersly said that the inspiration for the project was Google's launch of an HTTPS-encrypted search service in May. He later told ZDNet that the initial goal of the add-on was to create a tool to encrypt all Google searches (the Google HTTPS service initially worked only through the www.google.com domain and not the localized, international Google sites), but was quickly extended to other sites once the team — which also includes volunteers from the Tor (aka The Onion Router) project — found how simple it was.

HTTPS Everywhere is built on top of code that originated in the NoScript project, modified both to be easier to use and with additional functionality. Thus far, the extension is only available on the EFF's project page, not through the official Mozilla Add-ons site. The latest release is 0.1.2, though unfortunately no Firefox version-compatibility information is provided.

[preferences]

When installed, the extension provides a very simple preferences interface: a single pop-up window with checkboxes for each supported site or service. The result is instantaneous rewriting of URL requests to keep traffic on TLS or SSL encrypted HTTPS connections — including the initial request and subsequent internal links. The effect of checking or unchecking a site is instantaneous as of the next URL request; however it should be noted that previously-rewritten URLs already in the location bar or history are not "reverted" merely by changing the extension's preferences.

What it does

HTTPS Everywhere works by rewriting URLs based on matching requests against a series of regular-expression-based rules. Each rule is specific to a service, so that users can deactivate particular rules if they prove problematic. That is a valid concern, as some sites provide HTTPS connections, but do not offer the same services as they do over HTTP. Google Search, for example, supports web, video, news, books, blog, microblog, and forum content over HTTPS, but not image or shopping content. Many users have reported that using Facebook's HTTPS service disables the built-in chat client.

The current list of supported sites includes Google's search and services (such as Gmail and Google Voice) as separately-selectable options, as well as Facebook, Identi.ca, Twitter, the DuckDuckGo, Scroogle, and Ixquick search engines, Wikipedia, the New York Times, the Washington Post, the EFF, Mozilla, and Tor sites, San Francisco hacker space Noisebridge, and the Gentoo project's Bugzilla. Users can write their own URL matching and rewriting rules by following a tutorial at the HTTPS Everywhere site. Authors are encouraged to send in their creations to the project for possible inclusion in subsequent releases.

Rule sets use a simple XML format; each ruleset element can contain one or more rule elements with a "from" and "to" pattern to map the rewriting required. The patterns use JavaScript regular expressions, which is part of why HTTPS Everywhere can provide more redirects than NoScript's simple HTTP-to-HTTPS replacement.

An example from the site is Wikipedia, which runs an HTTPS server at secure.wikimedia.org, but not at the language-specific host names, such as sm.wikipedia.org or uk.wikipedia.org. HTTPS Everywhere's ruleset rewrites http://en.wikipedia.org/wiki/Example to https://secure.wikimedia.org/wikipedia/en/wiki/Example. HTTPS Everywhere also supports exclusion rules to work around HTTP-only subdomains in an otherwise HTTPS-supported domain, and it can gracefully downgrade to HTTP for sites that automatically redirect HTTPS requests to HTTP, without getting trapped in a loop .

Eckersly said that he hopes NoScript will be able to incorporate some of HTTPS Everywhere's enhancements back into its own extension, but for the foreseeable future intends to keep offering HTTPS Everywhere as its own, easy-to-use alternative.

What it doesn't

HTTPS Everywhere simply rewrites the outgoing URL requested by the browser, so it is only of use with sites already running an HTTPS server. Tor, in contrast, provides an encrypted first-step channel into the anonymous Tor network for every site visited, though the last step link from Tor to HTTP-only web sites is, of course, not encrypted.

EFF points out that users using HTTPS Everywhere may still see the broken-lock icon in Firefox for some sites, because many services use HTTP servers for some of their own page content (such as images) and to include insecure third-party content.

It is also important to note that while HTTPS encrypts the connection to the server and the resource path portion of the requested URL, the server name portion of the request is still visible (not only through setting up the connection, of course, but also potentially via DNS lookup). In addition, although HTTPS Everywhere can encrypt cookie requests over HTTPS, it does not provide the stronger cookie-management policies of NoScript. Thus, while eavesdroppers and credential thieves will be set back by HTTPS Everywhere, it does not encompass every security and privacy feature.

Finally, the genuinely paranoid no doubt know that encryption does not mean anonymity. Your IP address is visible in every request, and user tracking can be performed in many esoteric ways without peeking at the contents of the sites you read. The latter danger is ingeniously displayed by EFF's own Panopticlick, which gathers potentially trackable information from request headers, browser plugins, fonts, and other system information.

Security everywhere

The HTTPS Everywhere page discusses several similar secure-browsing alternatives, in addition to the aforementioned NoScript and Tor. Sid Stamm's Force-TLS is a Firefox extension that implements Strict Transport Security (STS) — although STS itself does not encrypt the initial request, it only tells the user agent to use HTTPS for subsequent requests, making it marginally less secure. Stanford's ForceHTTPS also includes a custom database of URL rewriting schemes, but was only released as a prototype in 2008, supporting Gmail and a handful of banking web sites.

The Chrome extension KB SSL Enforcer receives a little heat on the HTTPS Everywhere site, because it loads both HTTP and HTTPS requests for each page, thus potentially exposing the HTTP page to eavesdroppers. According to the developer, this is due to limitations in Chrome's APIs. Eckersley said that HTTPS Everywhere uses multiple Firefox APIs, including nsIObserver, nsIContentPolicy, and nsITraceableChannel, to try to capture every request path — even favicons and requests initiated by other add-ons — but still welcomes further networking testing by users.

The project reports that it has received dozens of user-contributed rulesets, including many for high-traffic sites, but that merging them all into a new default rule set for the next release will take some time. A 0.2.x "development" branch XPI installer was uploaded to the site on June 29th, which incorporates some of these additions.

Privacy and security online is a non-stop arms race between exploit-crafters and those making tools to thwart them. In that context, HTTPS Everywhere is not a perfect solution, but for many people it is an excellent, easy-to-use way to secure a large chunk of their daily web traffic.


(Log in to post comments)

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 1, 2010 5:04 UTC (Thu) by markc (guest, #4419) [Link]

I find it unacceptable to encourage a system that requires commercial pay-for third party certificates. The idea that the EFF is tacitly supporting companies like Verisign to extort even more money out of us is abhorrent.

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 1, 2010 6:46 UTC (Thu) by Darkmere (subscriber, #53695) [Link]

cacert, Gandi and others. I won't go into details here since it would be considered corporate spam and unfit for the medium, but I'd recommend Gandi as of the moment due to their cert+registration in bundle which made my life easier.

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 1, 2010 11:38 UTC (Thu) by cortana (subscriber, #24596) [Link]

But what is the alternative, and how will it ever displace the crappy CA model that we already use?

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 1, 2010 14:56 UTC (Thu) by cesarb (subscriber, #6266) [Link]

Perhaps DNSSEC plus RFC 4398.

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 1, 2010 16:19 UTC (Thu) by cortana (subscriber, #24596) [Link]

That would be really cool. Such a system could totally replace the role of the CA in verifying that a public key is attached to a particular domain name.

I guess we'll still need CAs to perform detailed identity checks in order to issue the so-called 'extended validation' certificates, for high-security web sites.

I wonder how to get everyone to switch though? The existing CAs will lobby against any change. One advantage of getting certificates via DNSSEC would be that it would finally be possible to actually *revoke* a certificate, something which is basically impossible with the current system, since no one configures their browser to check the CRL of each and every CA that it trusts...

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 2, 2010 4:20 UTC (Fri) by TRS-80 (subscriber, #1804) [Link]

RFC 5054 is also useful for certain websites, and IMAP particularly.

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 4, 2010 4:45 UTC (Sun) by foom (subscriber, #14868) [Link]

Really? Cause I've looked at the SRP/TLS spec before, and for the life of me cannot figure out what the heck the point is.

Why is it useful to add password authentication to TLS? Both IMAP and HTTP already have ways of doing user authentication within the protocol itself. And, of course, you can use those mechanisms after setting up a TLS session if you want encryption.

Now, SRP *itself* looks like a nice replacement for CRAM-MD5, but why is it being proposed as an addition to TLS rather than as an additional mechanism in SASL? It seems like it'd be much more at home there...

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 4, 2010 6:05 UTC (Sun) by TRS-80 (subscriber, #1804) [Link]

There is SASL/SRP too, but it's never been standardised in an RFC and isn't widely supported.

As for why SRP/TLS instead of TLS+SASL, the latter still requires a CA or self-signed certificates. HTTP auth isn't used much in the real world, and TLS/SRP isn't useful everywhere, since it requires a shared secret before establishing TLS. But when you have that, it's better than TLS+HTTP auth becuase again you don't require a CA, which is what cortana was asking about.

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 4, 2010 19:15 UTC (Sun) by foom (subscriber, #14868) [Link]

Sure, HTTP auth isn't used *much*, but TLS client auth is barely used at all!

I find it really hard to imagine a website which could actually use TLS/SRP instead of a server certificate (if even any browsers supported it). You couldn't display content at all unless the user already has a valid login. No user registration, no "forgot password", etc. That just doesn't seem realistic.

The main issue with deployment of HTTP auth is that it has no way to "logout" or to timeout a session. SRP/TLS has the exact same problem. At least with HTTP auth, you can have some pages on your site require logging in, and others not require a login, and you can display content to the user without a login...

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 5, 2010 4:41 UTC (Mon) by TRS-80 (subscriber, #1804) [Link]

I wasn't talking about HTTPS with client certs, I was talking about HTTPS with cookied login forms. And yes, there's no registration or forgotten password, hence why I said "shared secret" - it's suitable for environments where those are handled separately, like universities, companies etc.

HTTP auth can't be natively timed out (although there have been some nasty hacks that can work around it; I don't have examples to hand, but could find them if you want), but Firefox 3+ has UI for it, under "Clear Private Data..."

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 1, 2010 15:23 UTC (Thu) by jimparis (subscriber, #38647) [Link]

StartSSL gives free SSL certificates and is accepted by most browsers and OSes: http://en.wikipedia.org/wiki/StartCom

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 2, 2010 17:32 UTC (Fri) by MattPerry (guest, #46341) [Link]

Talk about throwing out the baby with the bathwater. Sheesh!

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 1, 2010 20:57 UTC (Thu) by Kwi (subscriber, #59584) [Link]

"[Users] may still see the broken-lock icon in Firefox for some sites, because many services use HTTP servers for some of their own page content (such as images) and to include insecure third-party content."

I wonder why browsers still insist on flagging this behavior as particularly insecure. A https site can be perfectly secure and still reference images on a non-secured HTTP server, while (on the other hand) no amount of cryptography can protect the user if the site is not coded securely.

If my bank chooses to serve up a logo from a non-secured CDN, I'll just have to trust them that this makes sense. Just as I'd have to trust them not to display my card number in 10 feet tall letters on Times Square (can we get a browser warning for that?).

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 2, 2010 7:44 UTC (Fri) by paulj (subscriber, #341) [Link]

If by "insecure third-party content" it means to include anything that can pull in javascripts, then the damage they can do includes things like "observe what you're doing" and "rewrite your whole page", is it not? I don't know enough about the HTML DOM and CSS, but even just with HTML and CSS you could certainly hide parts of the page, I think.

If the banking page I'm looking at can include javascript that could be modified by 3rd party, then I'd be unhappy if the browser told me the page was secure.

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 3, 2010 11:13 UTC (Sat) by Kwi (subscriber, #59584) [Link]

But you'll be happy when the browser tells you the page is secure, because it only contains https content?

The browser can't give any guarantees about security! It can only guarantee that you're seeing the real bankofcalisota.com website, secure or not.

Once identity has been established, it's completely irrelevant to the user whether all the HTTP requests are secure or not. In either case, the security level is entirely determined by the website, and the user doesn't get a say in the matter. (Okay, client-side vulnerabilities can lower the security, but that's another discussion.)

The warning maintains an illusion that the user has any way to diagnose an insecure website. Sure, the browser warns about this one particular case of reduced security, but has no way of warning about the millions of other potential security problems.

I'm not saying https is useless, far from it. To the website, it's a critical part of the overall security. But to the user, its only role is to verify the identity of the website, which the user may then choose to trust. Nothing else.

Increasing Global Warming one SSL connection at a time

Posted Jul 6, 2010 6:00 UTC (Tue) by jhhaller (subscriber, #56103) [Link]

While the extra computation to set up a SSL connection is not terribly significant, the computation to set up lots of SSL connections is significant. If everyone took the approach of setting up SSL connections for everything, there would need to be an increase in the number of servers, or replacement of systems to add ciphering assist hardware. Caching services can produce/sign certificates allowing them to handle the SSL and use a less computationally complex ciphering between it and the ultimate server, allowing the caching server provider to invest in cipher assist hardware, while using cheaper hardware at the ultimate destination of the request.

I understand the dangers of not using https, but is it truly necessary to protect every connection?

Increasing Global Warming one SSL connection at a time

Posted Jul 6, 2010 7:11 UTC (Tue) by bronson (subscriber, #4806) [Link]

Is it truly necessary to use an envelope for almost every piece of mail?

(which is far more damaging to the planet than negotiating ssl connections I'm sure)

Increasing Global Warming one SSL connection at a time

Posted Jul 6, 2010 10:24 UTC (Tue) by nye (guest, #51576) [Link]

>Is it truly necessary to use an envelope for almost every piece of mail?

No. That's why we invented postcards. And almost every piece of mail (~90% in my case) is spam which doesn't come in an envelope anyway.

Increasing Global Warming one SSL connection at a time

Posted Jul 13, 2010 14:48 UTC (Tue) by smowton (guest, #57076) [Link]

Even more no: feel free to read most of my mail (I'll use an envelope for letters to my bank, of course). Similarly, feel free to view my web history, and 99% of my email inbox; I guarantee you will be exceptionally bored by the time you get done reading.

So surely the problem here is a matter for user interface design: users should be in the habit of "classifying" certain emails, web transactions, etc. A big red button marked "this ought to be secret" would cause your mail client to mention if the SMTP server doesn't support encryption, if it can't verify the server's key, and so on; otherwise it wouldn't care, because the user doesn't.

Increasing Global Warming one SSL connection at a time

Posted Jul 13, 2010 16:01 UTC (Tue) by bronson (subscriber, #4806) [Link]

If you only place important mail in envelopes, then the thieves will know exactly which letters to steal. Envelopes make it harder to be a successful mail thief.

As far as your example, if encryption is opt-in then you're guaranteed to make the occasional accident. That sounds like a dangerous tradeoff to me.

Using HTTPS Everywhere with LWN.net

Posted Jul 13, 2010 17:52 UTC (Tue) by cesarb (subscriber, #6266) [Link]

Based on the ruleset from https://lwn.net/Articles/392701/, with extra exclusions for very old articles (which do not work with https). Put it on HTTPSEverywhereUserRules/LWN.xml as explained at https://www.eff.org/https-everywhere/rulesets.

<ruleset name="LWN">
<exclusion pattern="^http://lwn\.net/\d\d\d\d/"/>
<exclusion pattern="^http://www\.lwn\.net/\d\d\d\d/"/>
<rule from="^http://lwn\.net" to="https://lwn.net"/>
<rule from="^http://www\.lwn\.net" to="https://lwn.net"/>
</ruleset>

Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds