User's Guide
Reference Manual
Release Notes
PDF
Top

Secure Socket Layer
User's Guide
Version 5.0

Expand All
Contract All

Chapters

# 3 Using SSL for Erlang Distribution

This chapter describes how the Erlang distribution can use SSL to get additional verification and security.

### 3.1 Introduction

The Erlang distribution can in theory use almost any connection based protocol as bearer. A module that implements the protocol specific parts of the connection setup is however needed. The default distribution module is inet_tcp_dist which is included in the Kernel application. When starting an Erlang node distributed, net_kernel uses this module to setup listen ports and connections.

In the SSL application there is an additional distribution module, inet_tls_dist which can be used as an alternative. All distribution connections will be using 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.

Setting up Erlang distribution over SSL involves some simple but necessary steps:

- Building boot scripts including the SSL application
- Specifying the distribution module for net_kernel
- Specifying security options and other SSL options

The rest of this chapter describes the above mentioned steps in more detail.

### 3.2 Building boot scripts including the SSL application

Boot scripts are built using the systools utility in the SASL application. Refer to the SASL documentations for more information on systools. 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 Erlang distributions bin directory. The source for the script can be found under the Erlang installation top directory under releases/<OTP version>/start_clean.rel. Copy that script to another location (and preferably another name) and add the applications crypto, public_key and SSL with their current version numbers after the STDLIB application.

An example .rel file with SSL added may look like this:

          {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"}
          ]}.

Note that the version numbers surely will differ in your system. Whenever one of the applications included in the script is upgraded, the script has to be changed.

Assuming the above .rel file is stored in a file start_ssl.rel in the current directory, a boot script can be built like this:

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

There will now be a file start_ssl.boot in the current directory. To test the boot script, start Erlang with the -boot command line parameter specifying this boot script (with its full path but without the .boot suffix), in Unix it could look like this:

    $ erl -boot /home/me/ssl/start_ssl
    Erlang (BEAM) emulator version 5.0

    Eshell V5.0  (abort with ^G)
    1> whereis(ssl_manager).
    <0.41.0>

The whereis function call verifies that the SSL application is really started.

As an alternative to building a bootscript, one can explicitly add the path to the SSL ebin directory on the command line. This is done with the 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 applications code can be reached, the distribution will start. The -pa method is only recommended for testing purposes.

Note

Note that the clone of the SSL application is necessary to enable the use of the SSL code in such an early bootstage as needed to setup the distribution, however this will make it impossible to soft upgrade the SSL application.

### 3.3 Specifying distribution module for net_kernel

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

Extending the command line from above gives us the following:

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

For the distribution to actually be started, we need to 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>

Note however that a node started in this way will refuse to talk to other nodes, as no ssl parameters are supplied (see below).

### 3.4 Specifying SSL options

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

On the erl command line one can specify options that the SSL distribution will add when creating a socket.

One can specify the simpler SSL options certfile, keyfile, password, cacertfile, verify, reuse_sessions, secure_renegotiate, depth, hibernate_after and ciphers (use old string format) by adding the prefix server_ or client_ to the option name. The server can also take the options dhfile and fail_if_no_peer_cert (also prefixed). client_-prfixed options are used when the distribution initiates a connection to another node and the server_-prefixed options are used when accepting a connection from a remote node.

More complex options such as verify_fun are not available at the moment 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 should be followed by pairs of SSL options and their values. The -ssl_dist_opt argument can be repeated any number of times.

An example command line would now look something like this (line breaks in the command are for readability, they should 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 will be fully functional, using SSL as the distribution protocol.

### 3.5 Setting up environment to always use SSL

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

In a Unix (Bourne) shell it could look like this (line breaks for readability, they should not 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.