As you might have read, Mule 3.8 includes a number of improvements regarding TLS. In this post, we will analyze the TLS environment prior to this release and explore all of the new enhancements in detail so that you can start taking advantage of them.
The basics of Transport Layer Security
TLS (as SSL), is a protocol that provides security across a network. It guarantees privacy by encrypting each message (no one else can see the data), providing integrity with an authentication code for each message (no one else can modify the data) and confirming authenticity of each party’s digital certificates (no one can pretend to be someone they are not).
There are many versions of the protocol, including the SSL ones, so the first step when establishing a connection is for the client and server to agree on one. Then they must agree on which cipher suite to use: said cipher suite will determine the key exchange, authentication, encryption and message authentication code algorithms to be used. These steps are crucial because some versions might be less secure than others (or even insecure) and some algorithms might be stronger and others easier to break or obsolete.
When it comes to authentication, the server sends the client it’s certificate, so it can check whether the server is to be trusted. This is determined by analysing the certificate’s digital signature: if the signing entity that’s verifying the certificate is trusted then so is the certificate. That entity is usually a well known certificate authority (CA) that all clients trust. The same process is repeated from client to server if both ends need authenticating, as in two way authentication. For this step it’s important to note that, at the very least, a server will need it’s own certificate and a client will need a list of trusted ones.
TLS and Mule
Setting up TLS/SSL with Mule has always been a pain point, mainly because each connector has had its own way of dealing with it. That’s why in the 3.6 release we introduced the TLS context component, currently used by HTTP, OAuth, and the WS Consumer, but meant to become the standard for all connectors requiring TLS.
This component lets you establish a keystore (from where to take your own certificate) and a truststore (with a list of certificates considered safe). It can be defined globally in your app to share it across connectors or on each one of them, as in the example below for an HTTP listener.
The other piece of the puzzle is the setup of allowed protocols and cipher suites. These can be rendered insecure from one day to another because of a new exploit (think POODLE and SSLv3) so being able to decide which protocols are to be used is of utmost importance and a system administration’s main concern. That’s where the runtime’s TLS configuration file (found in MULE_HOME/conf) comes in. In it you can list the enabled protocols and cipher suites that the TLS connections established should respect, covering all applications at once. Below is the default one in 3.8, where you can notice TLSv1 is no longer included because of it’s known vulnerabilities.
TLS and Mule 3.8
Protocols and cipher suites per connector
As you can see, the protocols and cipher suites configuration was only possible at the container level, meaning it would affect all apps deployed in that runtime and should one of them require a higher security level, all others would be affected by the changes needed to support it.
In 3.8 you can now define your enabled protocols and cipher suites in the TLS context component, next to your keystore and truststore. Should there be any global restrictions from a TLS configuration file, those would still apply, but you’ll be able to tweak it for your connector as desired.
In the example below, the HTTP requester will only establish connections using TLSv1.2.
Domains support
Another improvement came from seeing the proliferation of the same keystore and truststore files replicated across applications and the need to share their passwords with each application owner. Though TLS contexts could be shared among connectors, they couldn’t be shared among apps.
Now, however, you’ll be able to define your TLS context in a domain and share it with all apps in it. Your keystore and truststore along with their passwords will only need to be available for that domain and only the context name shared with the app owners.
For example, if your app is part of the domain below you’ll be able to select “domainTlsConfig” as a global configuration for your HTTP requester.
Insecure option
Configuring TLS was even more troublesome considering the time it may take to get a proper certificate signed or your truststore ready with a self-signed version. Thankfully, we have now added a way to disable certificate validation so that prototyping, development and testing are not held back by the truststore setup. Of course, this renders your connections vulnerable to attacks, so it should not be used in production environments.
If you have yet to add the required certificates to trustStore.jks but want to test your app, you can mark the TLS config as insecure as shown below:
Mule User Guide for more details on TLS config
I hope you found these improvements useful and can start taking advantage of them soon! For more details on this and for a guide to creating your own certificates, you can check out our Mule User Guide on TLS configuration.
