HTTPS Everywhere FAQ
- What if HTTPS Everywhere breaks some site that I use?
- Why is HTTPS Everywhere preventing me from joining this hotel/school/other wireless network?
- Will there be a version of HTTPS Everywhere for IE, Safari, or some other browser?
- Why use a whitelist of sites that support HTTPS? Why can't you try to use HTTPS for every last site, and only fall back to HTTP if it isn't available?
- How do I get rid of/move the HTTPS Everywhere button in the toolbar?
- When does HTTPS Everywhere protect me? When does it not protect me?
- What does HTTPS Everywhere protect me against?
- How do I get support for an additional site in HTTPS Everywhere?
- What if the site doesn't support HTTPS, or only supports it for some activities, like entering credit card information?
- Isn't it more expensive or slower for a site to support HTTPS compared to regular HTTP?
- Why should I use HTTPS Everywhere instead of just typing https:// at the beginning of site names?
- What's the meaning of the broken padlock icon at the bottom of the browser, or the warning that a site contains "insecure information" or "unauthenticated content"?
- Why does HTTPS Everywhere include rules for sites like PayPal that already require HTTPS on all their pages?
- What do the different colors for rulesets in the toolbar menu mean?
- I'm having a problem installing the browser extension.
This is occasionally possible because of inconsistent support for HTTPS on sites (e.g., when a site seems to support HTTPS access but makes a few, unpredictable, parts of the site unavailable in HTTPS). If you report the problem to us, we can try to fix it. In the meantime, you can disable the rule affecting that particular site in your own copy of HTTPS Everywhere by clicking on the HTTPS Everywhere toolbar button () and unchecking the rule for that site.
You can also report the problem to the site, since they have the power to fix it!
Why use a whitelist of sites that support HTTPS? Why can't you try to use HTTPS for every last site, and only fall back to HTTP if it isn't available?
There are several problems with the idea of trying to automatically detect HTTPS on every site. There is no guarantee that sites are going to give the same response via HTTPS that they give via HTTP. As of 2015, Forbes is a good example of this problem: compare these HTTP and HTTPS responses. Also, it's not possible to test for HTTPS in real time without introducing security vulnerabilities (What should the extension do if the HTTPS connection attempt fails? Falling back to insecure HTTP isn't safe). And in some cases, HTTPS Everywhere has to perform quite complicated transformations on URIs — for example until recently the Wikipedia rule had to turn an address like http://en.wikipedia.org/wiki/World_Wide_Web into one like https://secure.wikimedia.org/wikipedia/en/wiki/World_Wide_Web because HTTPS was not available on Wikipedia's usual domains.
The HTTPS Everywhere button is useful because it allows you to see, and disable, a ruleset if it happens to be causing problems with a site. But if you'd rather disable it, go to View->Toolbars->Customize, and drag the button out of the toolbar into the Addons bar at the bottom of the page. Then you can hide the Addons bar. (In theory you should be able to drag it into the tray of available icons too, but that may trigger this bug.
HTTPS Everywhere protects you only when you are using encrypted portions of supported web sites. On a supported site, it will automatically activate HTTPS encryption for all known supported parts of the site (for some sites, this might be only a portion of the entire site). For example, if your web mail provider does not support HTTPS at all, HTTPS Everywhere can't make your access to your web mail secure. Similarly, if a site allows HTTPS for text but not images, someone might be able to see which images your browser loads and guess what you're accessing.
HTTPS Everywhere depends entirely on the security features of the individual web sites that you use; it activates those security features, but it can't create them if they don't already exist. If you use a site not supported by HTTPS Everywhere or a site that provides some information in an insecure way, HTTPS Everywhere can't provide additional protection for your use of that site. Please remember to check that a particular site's security is working to the level you expect before sending or receiving confidential information, including passwords.
One way to determine what level of protection you're getting when using a particular site is to use a packet-sniffing tool like Wireshark to record your own communications with the site. The resulting view of your communications is about the same as what an eavesdropper on your wifi network or at your ISP would see. This way, you can determine whether some or all of your communications would be protected; however, it may be quite time-consuming to make sense of the Wireshark output with enough care to get a definitive answer.
You can also turn on the "Block all HTTP requesets" feature for added protection. Instead of loading insecure pages or images, HTTPS Everywhere will block them outright.
On supported parts of supported sites, HTTPS Everywhere enables the sites' HTTPS protection which can protect you against eavesdropping and tampering with the contents of the site or with the information you send to the site. Ideally, this provides some protection against an attacker learning the content of the information flowing in each direction — for instance, the text of e-mail messages you send or receive through a webmail site, the products you browse or purchase on an e-commerce site, or the particular articles you read on a reference site.
However, HTTPS Everywhere does not conceal the identities of the sites you access, the amount of time you spend using them, or the amount of information you upload or download from a particular site. For example, if you access http://www.eff.org/issues/nsa-spying and HTTPS Everywhere rewrites it to https://www.eff.org/issues/nsa-spying, an eavesdropper can still trivially recognize that you are accessing www.eff.org (but might not know which issue you are reading about). In general, the entire hostname part of the URL remains exposed to the eavesdropper because this must be sent repeatedly in unencrypted form while setting up the connection. Another way of saying this is that HTTPS was never designed to conceal the identity of the sites that you visit.
Researchers have also shown that it may be possible for someone to figure out more about what you're doing on a site merely through careful observation of the amount of data you upload and download, or the timing patterns of your use of the site. A simple example is that if the site only has one page of a certain total size, anyone downloading exactly that much data from the site is probably accessing that page.
If you want to protect yourself against monitoring of the sites you visit, consider using HTTPS Everywhere together with software like Tor.
You can learn how to write rules that teach HTTPS Everywhere to support new sites. You can install these rules in your own browser or send them to us for possible inclusion in the official version.
What if the site doesn't support HTTPS, or only supports it for some activities, like entering credit card information?
You could try to contact the site and point out that using HTTPS for all site features is an increasingly common practice nowadays and protects users (and sites) against a variety of Internet attacks. For instance, it defends against the ability of other people on a wifi network to spy on your use of the site or even take over your account. You can also point out that credit card numbers aren't the only information you consider private or sensitive.
Sites like Google, Twitter, and Facebook now support HTTPS for non-financial information — for general privacy and security reasons.
It can be, but some sites have been pleasantly surprised to see how practical it can be. Also, experts at Google are currently implementing several enhancements to the TLS protocol that make HTTPS dramatically faster; if these enhancements are added to the standard soon, the speed gap between the two should almost disappear. See Adam Langley's description of the HTTPS deployment situation for more details on these issues. Notably, Langley states: "In order to [enable HTTPS by default for Gmail] we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead."
Although we're quite concerned about the certificate authority system, certificates in the current system are now quite cheap — paid certificates can cost just ten to twenty dollars a year.
Even if you normally type https://, HTTPS Everywhere might protect you if you occasionally forget. Also, it can rewrite other people's links that you follow. For instance, if you click on a link to http://en.wikipedia.org/wiki/EFF_Pioneer_Award, HTTPS Everywhere will automatically rewrite the link to https://secure.wikimedia.org/wikipedia/en/wiki/EFF_Pioneer_Award. Thus, you might get some protection even if you wouldn't have noticed that the target site is available in HTTPS.
What's the meaning of the broken padlock icon at the bottom of the browser, or the warning that a site contains "insecure information" or "unauthenticated content"?
Currently, HTTPS Everywhere for Firefox does not try to forbid access to pages with mixed secure and insecure content, since the user would have been at least vulnerable to these risks already (although Chrome version 18+ has some built-in protections against insecure scripts in pages, and HTTPS Everywhere for Chrome will in fact trigger these on a site like the New York Times). If you encounter a page that contains mixed secure and insecure content, you can contact the responsible site and ask them to address this risk.
We hope to provide a clearer solution for users who are especially concerned about the security risks from mixed-content pages, but the best general solution is to contact the operators of web sites that generate a mixed-content warning and ask them to fix their sites by making all the required resources available in HTTPS. Update: in recent versions of Firefox, Mozilla has removed the broken padlock indicator. Now, the only difference between a secure and insecure HTTPS deployment is the blue or green tint on the left of the address bar for secure deployments
Why does HTTPS Everywhere include rules for sites like PayPal that already require HTTPS on all their pages?
HTTPS Everywhere, like the HSTS protocol, tries to address an attack called SSL stripping. Users are only protected against the SSL stripping attack if their browsers don't even try to connect to the HTTP version of the site — even if the site would have redirected them to the HTTPS version. With HTTPS Everywhere, the browser won't even attempt the insecure HTTP connection, even if that's what you ask it to do. (Note that HTTPS Everywhere currently does not include a comprehensive list of such sites, which are mainly financial institutions.)
The colors are:
Dark Green: ruleset was active in loading the resources in the current page.
Light Green: ruleset was ready to prevent HTTP loads in the current page, but everything that the ruleset would have covered was loaded over HTTPS anyway (in the code, light green is called a "moot rule").
Dark Brown or Clockwise Red Arrow: broken rule -- the ruleset is active but the server is redirecting at least some URLs back from HTTPS to HTTP.
Gray: the ruleset is disabled.
Some people report that installing HTTPS Everywhere gives them the error: "The addon could not be downloaded because of a connection failure on www.eff.org." This may be caused by Avast anti-virus, which blocks installation of browser extensions. You may be able to install from addons.mozilla.org instead.