This page answers frequently-asked questions about EFF's HTTPS Everywhere project.

Q. Why does Facebook chat not work with HTTPS Everywhere?

A. The HTTPS version of appears not to support chat. There's not much we can do about that unless and until Facebook adds an HTTPS version of chat. If you'd like to use HTTPS Everywhere for other sites, but want to keep using the unencrypted version of Facebook so that you can chat, you can do that by going into the Tools->Add Ons->HTTPS Everywhere->Preferences dialog and unchecking the Facebook rule.

Q. Why does Google look so different with HTTPS Everywhere?

A. The HTTPS version of does not include links to Google services, like Google Images, that are not available in HTTPS. (You can see this for yourself by doing searches on and using some other browser.) Google also does not show the daily Google Doodle artwork on their HTTPS homepage. This user interface is Google's decision, not ours; there's not much we can do about it unless and until Google adds an HTTPS version of these other services. If you'd like to use HTTPS Everywhere for other sites, but want to keep using the unencrypted version of Google so that you can get links to these services, you can do that by going into the Tools->Add Ons->HTTPS Everywhere->Preferences dialog and unchecking the Google rule.

Q. Will there be a version of HTTPS Everywhere for Chrome? Or IE, Safari, Opera, or some other browser?

A. The Chrome extensions API does not support request rewriting. That means that there is currently no way to write a secure version of HTTPS Everywhere without modifying the Chrome source code. However, Chrome's developers have shown interest in supporting extensions of this sort, so this limitation may change in a future version of Chrome.

We believe the IE and Safari APIs have similar limitations. But if you happen to know a way to perform secure request rewriting in these browsers, feel free to let us know at https-everywhere at (but note that modifying document.location or window.location in JavaScript is not secure).

Q. Why is HTTPS Everywhere preventing me from joining this hotel/school/other wireless network?

A. Some wireless networks hijack your HTTP connections when you first join them, in order to demand authentication or simply to try to make you agree to terms of use. HTTPS pages are protected against this type of hijacking, which is as it should be. If you go to a website that isn't protected by HTTPS Everywhere (currently, is one such site) that will allow your browser to be hijacked.

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

A. There are several problems with the idea of trying to automatically detect HTTPS on every site. Firstly, there is no guarantee that sites are going to give the same response via HTTPS that they give via HTTP. As of 2010, LiveJournal is a good example of this problem: compare these HTTP and HTTPS responses. Secondly, we don't think it's 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). Lastly, in some cases, HTTPS Everywhere has to perform quite complicated transformations on URIs — for example the Wikipedia rule turns an address like into one like

Q. When does HTTPS Everywhere protect me? When does it not protect me?

A. 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 (like Wikipedia) 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.

Q. What does HTTPS Everywhere protect me against?

A. 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 and HTTPS Everywhere rewrites it to, an eavesdropper can still trivially recognize that you are accessing (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.

Q. How do I get support for an additional site in HTTPS Everywhere?

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

Q. What if the site doesn't support HTTPS, or only supports it for some activities, like entering credit card information?

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

Q. Why isn't HTTPS Everywhere available for download from like most other Firefox add-ons?

A. We felt that the Mozilla privacy policy that applies to downloads from is somewhat less protective than the privacy policies of the organizations that develop HTTPS Everywhere, and we prefer for HTTPS Everywhere users to be protected by our privacy policy. This decision could change in the future as Mozilla's privacy practices evolve or as we re-examine the details of the current Mozilla policy.

Q. Isn't it more expensive or slower for a site to support HTTPS compared to regular HTTP?

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

Q. Why should I use HTTPS Everywhere instead of just typing https:// at the beginning of site names?

A. 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, HTTPS Everywhere will automatically rewrite the link to Thus, you might get some protection even if you wouldn't have noticed that the target site is available in HTTPS.

Q. What if HTTPS Everywhere breaks some part of a site I use?

A. 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 going into the Tools->Add Ons->HTTPS Everywhere->Preferences dialog and unchecking the rule for that site).

You can also report the problem to the site, since they have the power to fix it by making their HTTPS support better, and since making all their site resources available in HTTPS improves their security. However, some site operators may respond that using their sites with a tool like HTTPS Everywhere is not officially supported.

Q. 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"?

A. If a site is accessed over HTTPS and loads some parts of a page over insecure HTTP, the user might still be vulnerable to some attacks or some kinds of surveillance. For instance, Wikipedia makes almost the entire site available in HTTPS, but images are all loaded from, which has no HTTPS version. That means that the images are sent unencrypted, and someone spying on you might be able to use the combination of images on a page to figure out which Wikipedia pages you are viewing.

There are also potential vulnerabilities when parts of a page are loaded over HTTP because an attacker might replace them with versions containing false information, or Javascript code that helps the attacker spy on the user or take over an account.

Currently, HTTPS Everywhere 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. 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.

Q. Why does HTTPS Everywhere include rules for sites like PayPal that already require HTTPS on all their pages?

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