HTTPS by default
In 2017 EMBL-EBI moved to using HTTPS by default. This was the guide we wrote for internal teams about the project
Summary
- Web browsers, including the next version of Chrome launching October, are being increasingly assertive to their users that sites not using HTTPS are insecure
- If we continue to run on HTTP by default this will bring a negative reputation to EMBL-EBI
- From the 2-October users on the www.ebi.ac.uk domain will be automatically redirected from HTTP -> HTTPS urls
- If you operate a service which does not run on HTTPS you need to raise a ticket before this date with Web Production. State that you want either:
- An exception put in to redirect from HTTPS -> HTTP (the prefered workaround)
- The service left as is, e.g. operating on both HTTP and HTTPS (this has risks – see below)
Note: Originally we’d said 1-Oct, however that is a Sunday and we want to perform this update during office hours to give maximum support during the roll out.
The details
Why are we doing this?
Why is HTTPS better than HTTP?
The benefits of HTTPS are numerous. The major benefits are improving end user trust in our site, services and brand. HTTPS means that users have privacy, can have confidence in the integrity of the delivery of our services, and can validate the identity of EMBL-EBI.
HTTPS is better for SEO and enables the use of new technologies such as HTTP/2. It is rapidly becoming the default for many trusted sites and services, both in science and in the wider web. Services like NCBI, ExPasy, and already many of our own EMBL-EBI websites: PDBe, EGA, ChEMBL use HTTPS by default.
Why do this now?
As of October 2017 Chrome will be marking all pages that are not served by HTTPS as insecure when a user focus an input element.
Firefox is less assertive, but does warn users when you are submitting password data on HTTP.
Why apply this to all traffic on the domain?
In terms of a user’s experience, if some of the EMBL-EBI site is on HTTP and some on HTTPS this creates an issue when navigating , users jump from the encrypted navigation space to a non-encrypted one and see the “Secure” and “Insecure” symbols and warnings appear intermittently.
What has been done already?
For a long time the Web Production team have provided certificates and configuration for EMBL-EBI hosted services to run on both HTTP and HTTPS urls. Services have the choice to make one of these the default if they so desire by adding an appropriate redirect.
Although the main EMBL-EBI public site runs on both HTTP and HTTPS the version on HTTP is the default listed in search engines, thus 97% of our users are on HTTP. As most users enter a service via a search engine or via the main EMBL-EBI site then enter the service on a HTTP link.
What is the plan?
On 1-October users on the www.ebi.ac.uk domain will be automatically redirected from HTTP -> HTTPS urls. This will be setup by the Web Production team.
To help you test if your service has any issues the same redirect will be added to the wwwdev domain on 15-September.
By performing this for the whole domain we maximise the benefits for our users, and minimise any reputational impact from users seeing warnings in their web browsers.
The majority of links on the public site are ‘protocol relative’, and use the protocol the user is currently on, but some are not. Adding this redirect means that we don’t need to update links on individual services or web pages, users will be automatically updated to the secure version.
That said the www.ebi.ac.uk domain is a collection of many hundreds of interconnected websites and webservices. We know that some of these are not yet ready to run on only the secure HTTPS urls. For these service we can add execptions to these redirects.
We strongly recommend that if your service does not run on HTTPS that you ask for a redirect from HTTPS -> HTTP. Although your service might currently be running on both protocols, and you’re not seeing much traffic on the broken HTTPS version this will very likely change when we roll out the redirect to the remainder of the domain. This is because users will now be coming from HTTPS pages, and links into the service will most likely be protocol relative and from 1-October link into the service on the HTTPS url.
If you operate a service which does not run on HTTPS you need to raise a ticket before this date with Web Production.
The web development team will be making required updates to the corporate and training websites, including the service directory. They will also be setting the appropriate settings for the search engines that are dealt with at a global level.
What do I need to do?
If you manage a service that runs on www.ebi.ac.uk you need to:
- Check if your service can be accessed on HTTPS
- Does the service respond?
- Does the service function as expected?
- Does the padlock next to the URL go green? If not clicking on the padlock will give you diagnostic information.
- If you have issues, and are unable to fix them before 1-October then raise a ticket before this date with Web Production and ask for an exception to be added, either:
- An expection put in to redirect from HTTPS -> HTTP (the prefered workaround)
- The service left as is, e.g. operating on both HTTP and HTTPS
- If you run APIs you may wish to communicate this change to your users, and update your documentation so that clients expect to be redirected from insecure to secure urls.
How can I get help?
The following resources may be of use when checking your service:
- Google guide to avoiding mixed content warnings:
- Mixed content scanning tools:
If you have questions on the process for redirects please contact Web Production.
If you have questions on the corporate website, or the Visual Framework (e.g. shared EMBL-EBI JS and CSS), please contact Web Development.