Using SSL for Erlang Distribution

20002013 Ericsson AB. All Rights Reserved. The contents of this file are subject to the Erlang Public License, Version 1.1, (the "License"); you may not use this file except in compliance with the License. You should have received a copy of the Erlang Public License along with this software. If not, it can be retrieved online at http://www.erlang.org/. Software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License. Using SSL for Erlang Distribution P Nyblom 2003-04-01 B ssl_distribution.xml

This section describes how the Erlang distribution can use SSL to get extra verification and security.

The Erlang distribution can in theory use almost any connection-based protocol as bearer. However, a module that implements the protocol-specific parts of the connection setup is needed. The default distribution module is inet_tcp_dist in the kernel application. When starting an Erlang node distributed, net_kernel uses this module to set up listen ports and connections.

In the ssl application, an exra distribution module, inet_tls_dist, can be used as an alternative. All distribution connections will use SSL and all participating Erlang nodes in a distributed system must use this distribution module.

The security level depends on the parameters provided to the SSL connection setup. Erlang node cookies are however always used, as they can be used to differentiate between two different Erlang networks.

To set up Erlang distribution over SSL:

Step 1: Build boot scripts including the ssl application. Step 2: Specify the distribution module for net_kernel. Step 3: Specify the security options and other SSL options. Step 4: Set up the environment to always use SSL.

The following sections describe these steps.

Building Boot Scripts Including the ssl Application

Boot scripts are built using the systools utility in the sasl application. For more information on systools, see the sasl documentation. This is only an example of what can be done.

The simplest boot script possible includes only the kernel and stdlib applications. Such a script is located in the bin directory of the Erlang distribution. The source for the script is found under the Erlang installation top directory under /start_clean.rel]]>.

Do the following:

Copy that script to another location (and preferably another name).

Add the applications crypto, public_key, and ssl with their current version numbers after the stdlibapplication.

The following shows an example .rel file with ssl added:


      {release, {"OTP  APN 181 01","R15A"}, {erts, "5.9"},
      [{kernel,"2.15"},
      {stdlib,"1.18"},
      {crypto, "2.0.3"},
      {public_key, "0.12"},
      {ssl, "5.0"}
      ]}.

The version numbers differ in your system. Whenever one of the applications included in the script is upgraded, change the script.

Do the following:

Build the boot script.

Assuming the .rel file is stored in a file start_ssl.rel in the current directory, a boot script can be built as follows:


   1> systools:make_script("start_ssl",[]).

There is now a start_ssl.boot file in the current directory.

Do the following:

Test the boot script. To do this, start Erlang with the -boot command-line parameter specifying this boot script (with its full path, but without the .boot suffix). In UNIX it can look as follows:

 whereis(ssl_manager).
<0.41.0>    ]]>

The whereis function-call verifies that the ssl application is started.

As an alternative to building a bootscript, you can explicitly add the path to the ssl ebin directory on the command line. This is done with command-line option -pa. This works as the ssl application does not need to be started for the distribution to come up, as a clone of the ssl application is hooked into the kernel application. So, as long as the ssl application code can be reached, the distribution starts. The -pa method is only recommended for testing purposes.

The clone of the ssl application must enable the use of the SSL code in such an early bootstage as needed to set up the distribution. However, this makes it impossible to soft upgrade the ssl application.

Specifying Distribution Module for net_kernel

The distribution module for ssl is named inet_tls_dist and is specified on the command line with option -proto_dist. The argument to -proto_dist is to be the module name without suffix _dist. So, this distribution module is specified with -proto_dist inet_tls on the command line.

Extending the command line gives the following:


$ erl -boot /home/me/ssl/start_ssl -proto_dist inet_tls

For the distribution to be started, give the emulator a name as well:


$ erl -boot /home/me/ssl/start_ssl -proto_dist inet_tls -sname ssl_test
Erlang (BEAM) emulator version 5.0 [source]
 
Eshell V5.0  (abort with ^G)
(ssl_test@myhost)1>

However, a node started in this way refuses to talk to other nodes, as no ssl parameters are supplied (see the next section).

Specifying SSL Options

For SSL to work, at least a public key and a certificate must be specified for the server side. In the following example, the PEM-files consist of two entries, the server certificate and its private key.

On the erl command line you can specify options that the SSL distribution adds when creating a socket.

The simplest SSL options in the following list can be specified by adding the prefix server_ or client_ to the option name:

certfile keyfile password cacertfile verify reuse_sessions secure_renegotiate depth hibernate_after ciphers (use old string format)

The server can also take the options dhfile and fail_if_no_peer_cert (also prefixed).

client_-prefixed options are used when the distribution initiates a connection to another node. server_-prefixed options are used when accepting a connection from a remote node.

More complex options, such as verify_fun, are currently not available, but a mechanism to handle such options may be added in a future release.

Raw socket options, such as packet and size must not be specified on the command line.

The command-line argument for specifying the SSL options is named -ssl_dist_opt and is to be followed by pairs of SSL options and their values. Argument -ssl_dist_opt can be repeated any number of times.

An example command line can now look as follows (line breaks in the command are for readability, and are not be there when typed):


$ erl -boot /home/me/ssl/start_ssl -proto_dist inet_tls
  -ssl_dist_opt server_certfile "/home/me/ssl/erlserver.pem" 
  -ssl_dist_opt server_secure_renegotiate true client_secure_renegotiate true
  -sname ssl_test
Erlang (BEAM) emulator version 5.0 [source]
 
Eshell V5.0  (abort with ^G)
(ssl_test@myhost)1>

A node started in this way is fully functional, using SSL as the distribution protocol.

Setting up Environment to Always Use SSL

A convenient way to specify arguments to Erlang is to use environment variable ERL_FLAGS. All the flags needed to use the SSL distribution can be specified in that variable and are then interpreted as command-line arguments for all subsequent invocations of Erlang.

In a Unix (Bourne) shell, it can look as follows (line breaks are for readability, they are not to be there when typed):


$ ERL_FLAGS="-boot /home/me/ssl/start_ssl -proto_dist inet_tls
  -ssl_dist_opt server_certfile /home/me/ssl/erlserver.pem
  -ssl_dist_opt server_secure_renegotiate true client_secure_renegotiate true"
$ export ERL_FLAGS
$ erl -sname ssl_test
Erlang (BEAM) emulator version 5.0 [source]
 
Eshell V5.0  (abort with ^G)
(ssl_test@myhost)1> init:get_arguments().
[{root,["/usr/local/erlang"]},
 {progname,["erl "]},
 {sname,["ssl_test"]},
 {boot,["/home/me/ssl/start_ssl"]},
 {proto_dist,["inet_tls"]},
 {ssl_dist_opt,["server_certfile","/home/me/ssl/erlserver.pem"]},
 {ssl_dist_opt,["server_secure_renegotiate","true",
                "client_secure_renegotiate","true"]
 {home,["/home/me"]}]

The init:get_arguments() call verifies that the correct arguments are supplied to the emulator.