Skip to end of metadata
Go to start of metadata

HTTPS protocol

HTTPS is the most commonly used security protection among services. The use of HTTPS would be indicated by a service’s URL starting with https:// instead of http://. HTTPS is a secured version of the HTTP communication protocol and provides a connection between a client and a server that is confidential (i.e. private, no one can eavesdrop it). It also verifies the identity of the server by means of a digital certificate – the server must possess a valid certificate issued by a trusted Certificate Authority (CA), such as the Verisign, for the HTTPS connection to be opened successfully.

Trusted certificates

All modern Web browsers include a pre-defined list of trusted CAs (e.g. for Mozilla Firefox, seehttp://www.mozilla.org/projects/security/certs/included/). That means that if you were browsing a Web site which URL started with https://, your browser would first verify if the site’s certificate was among trusted certificates or if it was signed by one of the built-in CAs. If yes – it would proceed to that site. If not, it would ask you if you wanted to trust it. By answering yes, the browser would remember this site’s certificate as trusted and would not ask you next time.

Similarly, Java (which is used to run Taverna) has its own list of trusted certificates (that belong to trusted CAs) saved in a special truststore file somewhere on your hard drive (Java's list of trusted certificates is typically sightly different from that used by browsers). This enables you to open an HTTPS connection from Java to a service whose certificate is signed (i.e. vouched for) by one of the built-in trusted CAs. Taverna’s Credential Manager is also making use if this truststore – see the question about Credential Manager for details.

HTTPS and other security support in Java

There is one other important aspect of Java security. By default, Oracle's Java comes with a security policy that lets you use only limited-strength cryptography. This means that, for example, you can only use short (an therefore not-so-secure) keys for encryption. The reason why Oracle's Java by default only comes with limited-strength cryptography support is due to import control restrictions in some countries, where unlimited-strength cryptography is classified as a “weapon technology”.

Obviously, we want Taverna to use the strongest possible security protections available. The good news is that Taverna 2.5 is now shipped with embedded OpenJDK Java, which includes the strong cryptography policy and allows the use of unlimited-strength cryptography out of the box.

As of Taverna 2.5, users are no longer required to install the strong cryptography policy for Java.

If you still want to use Oracle's Java to run Taverna instead of OpenJDK, you should download and install the ‘Unlimited Strength Java Cryptography Extension’ policy from Oracle (see below for links) in place of the default restrictive policy shipped with Oracle's Java. Replacing the policy effectively switches on the “strong” cryptography.

Java’s security policy consists of two files located in:

<java-home>/lib/security/local_policy.jar

<java-home>/lib/security/US_export_policy.jar

where <java-home> is the jre directory of the Java Development Kit (JDK) or the top-level directory of the JRE (Java Runtime Environment) on your system. You need to replace both of these files with their “unrestricted” versions.

For Oracle's Java 7 (used by Taverna 2.5) , you can download the unlimited cryptography policy from here.

If you have not heard about this before, your country most probably allows the use of unlimited-strength security and you will be OK to download and install the new policy.

Not installing these files will cause Credential Manager to fail. It will also cause invocation of secure services from Taverna to fail. Note that if you switch to another Java version you would have to install the policy files again in the appropriate directory of your new Java installation.

Labels
  • None