- Web browsers, including the next version of Chrome launching \nOctober, are being increasingly assertive to their users that sites not \nusing HTTPS are insecure<\/li>
- If we continue to run on HTTP by default this will bring a negative reputation to EMBL-EBI<\/li>
- From the 2-October<\/strong> users on the www.ebi.ac.uk<\/strong> domain will be automatically redirected from HTTP -> HTTPS urls<\/li>
- If you operate a service which does not run on HTTPS you need to raise a ticket before this date with Web Production<\/a>. State that you want either:\n
- An exception put in to redirect from HTTPS -> HTTP (the prefered workaround)<\/li>
- The service left as is, e.g. operating on both HTTP and HTTPS (this has risks \u2013 see below)<\/li><\/ul>\n<\/li><\/ul>\n\n\n\n
Note<\/strong>: Originally we\u2019d said 1-Oct, however that \nis a Sunday and we want to perform this update during office hours to \ngive maximum support during the roll out.<\/em><\/p>\n\n\n\n
The details<\/h3>\n\n\n\n
Why are we doing this?<\/h4>\n\n\n\n
Why is HTTPS better than HTTP?<\/h5>\n\n\n\n
The benefits of HTTPS are numerous. The major benefits are improving \nend user trust in our site, services and brand. HTTPS means that users \nhave privacy<\/strong>, can have confidence in the integrity<\/strong> of the delivery of our services, and can validate the identity<\/strong> of EMBL-EBI.<\/p>\n\n\n\n
HTTPS is better for SEO and enables the use of new technologies such \nas HTTP\/2. It is rapidly becoming the default for many trusted sites and\n services, both in science and in the wider web. Services like NCBI, \nExPasy, and already many of our own EMBL-EBI websites: PDBe, EGA, ChEMBL\n use HTTPS by default.<\/p>\n\n\n\n
Why do this now?<\/h5>\n\n\n\n
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.<\/p>\n\n\n\n
Firefox is less assertive, but does warn users when you are submitting password data on HTTP.<\/p>\n\n\n\n
![\"Screnshot](\"https:\/\/www.ebi.ac.uk\/about\/clusters\/technical-services\/wp-content\/uploads\/2017\/09\/Screen-Shot-2017-09-08-at-15.46.07.png\")
Chrome 62 \u2013 Focusing any input field on a HTTP connection causes a \u2018Not Secure\u2019 warning to appear<\/figcaption><\/figure>\n\n\n\n ![\"Firefox](\"https:\/\/www.ebi.ac.uk\/about\/clusters\/technical-services\/wp-content\/uploads\/2017\/09\/Screen-Shot-2017-09-08-at-15.44.48.png\")
Firefox \u2013 Warning shown on a password field on HTTP<\/figcaption><\/figure>\n\n\n\n Why apply this to all traffic on the domain?<\/h5>\n\n\n\n
In terms of a user\u2019s experience, if some of the EMBL-EBI site is on \nHTTP and some on HTTPS this creates an issue when navigating , users \njump from the encrypted navigation space to a non-encrypted one and see \nthe \u201cSecure\u201d and \u201cInsecure\u201d symbols and warnings appear intermittently.<\/p>\n\n\n\n
What has been done already?<\/h5>\n\n\n\n
For a long time the Web Production team have provided certificates \nand configuration for EMBL-EBI hosted services to run on both HTTP and \nHTTPS urls. Services have the choice to make one of these the default if\n they so desire by adding an appropriate redirect.<\/p>\n\n\n\n
Although the main EMBL-EBI public site runs on both HTTP and HTTPS \nthe version on HTTP is the default listed in search engines, thus 97% of\n our users are on HTTP. As most users enter a service via a search \nengine or via the main EMBL-EBI site then enter the service on a HTTP \nlink.<\/p>\n\n\n\n
What is the plan?<\/h4>\n\n\n\n
On 1-October<\/strong> users on the www.ebi.ac.uk<\/strong> domain will be automatically redirected from HTTP -> HTTPS urls. This will be setup by the Web Production team.<\/p>\n\n\n\n
To help you test if your service has any issues the same redirect will be added to the wwwdev domain on 15-September<\/strong>.<\/p>\n\n\n\n
By performing this for the whole domain we maximise the benefits for \nour users, and minimise any reputational impact from users seeing \nwarnings in their web browsers.<\/p>\n\n\n\n
The majority of links on the public site are \u2018protocol relative\u2019<\/a>,\n and use the protocol the user is currently on, but some are not. \nAdding this redirect means that we don\u2019t need to update links on \nindividual services or web pages, users will be automatically updated to\n the secure version.<\/p>\n\n\n\n
That said the www.ebi.ac.uk domain is a collection of many hundreds \nof interconnected websites and webservices. We know that some of these \nare not yet ready to run on only the secure HTTPS urls. For these \nservice we can add execptions to these redirects.<\/p>\n\n\n\n
We strongly recommend that if your service does not run on HTTPS that\n you ask for a redirect from HTTPS -> HTTP. Although your service \nmight currently be running on both protocols, and you\u2019re not seeing much\n traffic on the broken HTTPS version this will very likely change when \nwe roll out the redirect to the remainder of the domain. This is because\n users will now be coming from HTTPS pages, and links into the service \nwill most likely be protocol relative and from 1-October link into the \nservice on the HTTPS url.<\/p>\n\n\n\n
If you operate a service which does not run on HTTPS you need to raise a ticket before this date with Web Production<\/a>.<\/p>\n\n\n\n
The web development team will be making required updates to the \ncorporate and training websites, including the service directory. They \nwill also be setting the appropriate settings for the search engines \nthat are dealt with at a global level.<\/p>\n\n\n\n
What do I need to do?<\/h4>\n\n\n\n
If you manage a service that runs on www.ebi.ac.uk you need to:<\/p>\n\n\n\n
- Check if your service can be accessed on HTTPS\n
- Does the service respond?<\/li>
- Does the service function as expected?<\/li>
- Does the padlock next to the URL go green? If not clicking on the padlock will give you diagnostic information.<\/li><\/ul>\n<\/li>
- If you have issues, and are unable to fix them before 1-October then raise a ticket before this date with Web Production<\/a> and ask for an exception to be added, either:\n
- An expection put in to redirect from HTTPS -> HTTP (the prefered workaround)<\/li>
- The service left as is, e.g. operating on both HTTP and HTTPS<\/li><\/ul>\n<\/li>
- If you run APIs you may wish to communicate this change to your \nusers, and update your documentation so that clients expect to be \nredirected from insecure to secure urls.<\/li><\/ol>\n\n\n\n
How can I get help?<\/h4>\n\n\n\n
The following resources may be of use when checking your service:<\/p>\n\n\n\n
- Google guide to avoiding mixed content warnings<\/a>:<\/li>
- Mixed content scanning tools:\n
- Google guide to avoiding mixed content warnings<\/a>:<\/li>
- Check if your service can be accessed on HTTPS\n
- If you operate a service which does not run on HTTPS you need to raise a ticket before this date with Web Production<\/a>. State that you want either:\n