3 Using SSL for Erlang Distribution

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

Note

Note this documentation is written for the old ssl implementation and will be updated for the new one once this functionality is supported by the new implementation.

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 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_ssl_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 depends on how the connections are set up, one can use key files or certificates to just get a encrypted connection. One can also make the SSL package verify the certificates of other nodes to get additional security. 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 SSL application with its current version number after the STDLIB application.

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

{release, {"OTP  APN 181 01","P7A"}, {erts, "5.0"},
 [{kernel,"2.5"},
  {stdlib,"1.8.1"},
  {ssl,"2.2.1"}]}.

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_server).
<0.32.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 really need not be started for the distribution to come up, a primitive version of the ssl server is started by the distribution module itself, so as long as the primitive code server can reach the code, the distribution will start. The -pa method is only recommended for testing purposes.

3.3 Specifying distribution module for net_kernel

The distribution module for SSL is named inet_ssl_dist and is specified on the command line whit 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_ssl on the command line.

Extending the command line from above gives us the following:

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

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_ssl -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 certificates or key files are supplied (see below).

When the SSL distribution starts, the OTP system is in its early boot stage, why neither application nor code are usable. As SSL needs to start a port program in this early stage, it tries to determine the path to that program from the primitive code loaders code path. If this fails, one need to specify the directory where the port program resides. This can be done either with an environment variable ERL_SSL_PORTPROGRAM_DIR or with the command line option -ssl_portprogram_dir. The value should be the directory where the ssl_esock port program is located. Note that this option is never needed in a normal Erlang installation.

3.4 Specifying security options and other SSL options

For SSL to work, you either need certificate files or a key file. Certificate files can be specified both when working as client and as server (connecting or accepting).

On the erl command line one can specify options that the ssl distribution will add when creation a socket. It is mandatory to specify at least a key file or client and server certificates. One can specify any SSL option on the command line, but must not specify any socket options (like packet size and such). The SSL options are listed in the Reference Manual. The only difference between the options in the reference manual and the ones that can be specified to the distribution on the command line is that certfile can (and usually needs to) be specified as client_certfile and server_certfile. The client_certfile is used when the distribution initiates a connection to another node and the server_certfile is used when accepting a connection from a remote node.

The command line argument for specifying the SSL options is named -ssl_dist_opt and should be followed by an even number of SSL options/option 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_ssl 
  -ssl_dist_opt client_certfile "/home/me/ssl/erlclient.pem" 
  -ssl_dist_opt server_certfile "/home/me/ssl/erlserver.pem" 
  -ssl_dist_opt verify 1 depth 1     
  -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):

$ ERL_FLAGS="-boot \\"/home/me/ssl/start_ssl\\" -proto_dist inet_ssl 
  -ssl_dist_opt client_certfile \\"/home/me/ssl/erlclient.pem\\" 
  -ssl_dist_opt server_certfile \\"/home/me/ssl/erlserver.pem\\" 
  -ssl_dist_opt verify 1 -ssl_dist_opt depth 1"
$ 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_ssl"]},
 {ssl_dist_opt,["client_certfile","/home/me/ssl/erlclient.pem"]},
 {ssl_dist_opt,["server_certfile","/home/me/ssl/erlserver.pem"]},
 {ssl_dist_opt,["verify","1"]},
 {ssl_dist_opt,["depth","1"]},
 {home,["/home/me"]}]

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