should be using TLS

Case number:699969-2005089
Opened by:movermeyer
Opened on:Friday, April 20, 2018 - 19:21
Last modified:Thursday, April 26, 2018 - 01:04

I've recently signed up for (as part of CitSciDay) and noticed that something was odd.
When a user signs up or logs in, they are presented with a warning:

On Firefox: "This connection is not secure. Logins entered here could be compromised."
See it visually:

Since Firefox 52 (March 2017) and Chrome 56 (January 2017), warnings like this are displayed any time a site is asking for a password over an unencrypted connection. is not using encryption (ie. TLS). This has been an increasingly dangerous thing for websites to do, as user details are being sent in plaintext across the internet. This allows third parties to collect the user details which can be used to compromise accounts on (including admin accounts), and also endangers other accounts of users (more than 60%) who re-use their passwords across multiple sites. Beyond that, we have seen nation-states take advantage of non-TLS connections in order to perform man-in-the-middle attacks on users, which can harm both the users and the reputation of the site.

This is all to say that encrypting connections to websites has become table stakes for being secure on the web. Thankfully, it is easier than ever to get encryption set up on your website. Previously, it used to require money to buy TLS certificates, but now with projects like "Let's Encrypt!" it can even be free.

To be clear, I am just a concerned, tech-savvy user of your site. I'm not trying to sell you anything, nor am trying to scare you. I'm writing this email simply to inform you of the risks and the negligence with which is handling user details.

I'm more than willing to answer any questions you might have about getting TLS set up on, and am even willing to volunteer my time to give technical support with the process if you'd like. I simply want to see and similar citizen science portals be made secure from attacks.

More reading:

- Let's Encrypt free TLS certificates:
- Firefox documentation for insecure password warning:
- China taking advantage of non-TLS connections:
- More than 60% of users reuse passwords:

(Fri, 04/20/2018 - 19:21  |  7 comments)

LociOiling's picture
User offline. Last seen 41 min 27 sec ago. Offline
Joined: 12/27/2012

Welcome to Foldit!

One other aspect of the browser changes you mention is that Firefox at least won't auto-fill your credentials on

I go to instead, and Firefox seems mostly happy with that.

It appears the has one "mixed content" element, a request for "tracking_pixel.gif" that's sent to a University of Washington server using http instead of https. (It looks to me like the GET request for the gif never receives a response.)

Firefox has an "HTTPS Everywhere" add-on, which is supposed to switch to https automatically. I haven't tried it. It might allay some of concerns, but probably has limited uptake among those who use the same password for everything.

There are some other related problems with, such as using the search box that appears on many pages. Apparently the request goes out http, and prompts a Firefox warning "the information you have entered on this page will be sent over an insecure connection and could be read by a third party". That's something that HTTPS Everywhere might fix. (I may give it a try.)

Not sure that these issues are a big priority with the Foldit team. The development is focused mainly on improving the client, while the web developers are listed as "past contributors" in the credits. Maybe someday they'll get around to dropping the mention of Vista and adding Windows 10 under the download link....

LociOiling's picture
User offline. Last seen 41 min 27 sec ago. Offline
Joined: 12/27/2012

Tried the "HTTPS Everywhere" add-on in Firefox.

It fixes the problems with the search box on

Unfortunately, it doesn't fix itself. So entering is necessary for a secure login.

It turns out that website owners must develop a custom rule and submit it in order for "HTTPS Everywhere" to work....

Joined: 04/18/2018
Groups: None

Hey LociOiling,

Thanks for your reply. I actually already use HTTPS Everywhere, so I knew that didn't work.
I didn't notice the search bar warning. That's a good catch.
Glad to hear that the https:// endpoint already exists. That means that is just missing the redirect (and the mixed content).

I believe uses lighttpd for its web server. Creating the redirect seems to be a simple modification of the lighttpd.conf file:

I hope that someone on the team sees this and corrects it. The default experience should not be insecure.

Joined: 04/18/2018
Groups: None

It looks like someone at has set up the redirect. So now people will have their credentials sent securely. :)

There are other easy things that can be done to further secure's TLS configuration:

For example, should enable Strict Transport Security (HSTS). This prevents attackers from being able to mount Man-in-the-Middle attacks against users who are still visiting the "http://" endpoint (due to bookmarks or old links). This is a smaller attack surface than the previous issue, but it is also a simple 1-line change:

In a sentence, HSTS is making a promise to the user's web browser that will always use TLS, so the browser will remember the promise and never go to the "http://", but will always jump straight to the "https://" endpoint. This prevents attacks that target that first non-TLS request before the redirect.

Other than that, cleaning up the loose ends outlined on this TLS security report would be good:

For example, disabling weak Diffie-Hellman (DH) key exchange parameters:

Thanks for getting TLS to be the default for It helps a lot.

LociOiling's picture
User offline. Last seen 41 min 27 sec ago. Offline
Joined: 12/27/2012
Type: Suggestion » Bug

Wow, that was fast service, but movermeyer is correct, is now redirecting to https.

The bad part is that the search box now gives a "404 - Not Found" error. Somehow there's an extra "" in the URL. Removing the extra bit gives a usable Google search URL.

I've moved this one to "bug" as a result.

For example, enter "food" in the search box, and you'll get the URL:

which returns a 404 error.

Adjusting the URL to

gives the desired results.

jflat06's picture
User offline. Last seen 5 days 11 hours ago. Offline
Joined: 09/29/2010
Groups: Window Group

Thanks for the feedback everyone.

We had been meaning to switch over to HTTPS-only, but there were a few internal issues that had popped up when we had tried it before.

I believe I've resolved all of those now (including the search box error), and everything should be functioning now.

The biggest remaining problems are:

* Some "no shared cipher" errors are popping up in our logs. This may be a sign that we've broken compatibility for users with very old systems and out of date software. I have set the available ciphers to try and be as inclusive as possible, but those users should probably update their systems, as they pose a security vulnerability.
* There is still mixed content on some pages due to the content linking to images via http. These links are stored in the drupal page content in our database, so the options are either do a bulk search/replace over our DB, or try to filter it on its way out to the user. This is a low priority, so it may not happen any time soon.

LociOiling's picture
User offline. Last seen 41 min 27 sec ago. Offline
Joined: 12/27/2012
Status: Open » Closed

OK, looks like search is working again, and redirect is still working. I don't think some mixed content is a big issue, so I'm closing this one.


Developed by: UW Center for Game Science, UW Institute for Protein Design, Northeastern University, Vanderbilt University Meiler Lab, UC Davis
Supported by: DARPA, NSF, NIH, HHMI, Amazon, Microsoft, Adobe, Boehringer Ingelheim, RosettaCommons