Komunikasi Node Aman (TLS)

When Erlang nodes communicate, especially across a network or in a production environment, their interactions need to be secure. This prevents eavesdropping, tampering, and unauthorized access.

By default, Erlang's distribution protocol doesn't encrypt communication. This lesson will show you how to add a layer of security using TLS/SSL.

TLS (Transport Layer Security) and its predecessor SSL (Secure Sockets Layer) are cryptographic protocols designed to provide communication security over a computer network.

They achieve this by:

• Encryption: Scrambling data so only the intended recipient can read it.
• Authentication: Verifying the identity of the communicating parties.
• Data Integrity: Ensuring data hasn't been altered in transit.

Erlang nodes communicate using a built-in distribution protocol. Typically, you start nodes like this:

erl -sname node1

This creates a connection that's fast and efficient, but it does not inherently use encryption. For secure communication, we need to instruct Erlang to use TLS for its distribution.

TLS relies on a system of digital certificates and private keys to establish trust and secure connections. Think of them as digital IDs.

• Private Key: A secret key used to encrypt/decrypt data and sign certificates. Keep it absolutely secure!
• Certificate (Public Key): Contains a public key and information about the entity (node). It's shared and used to verify identity.
• CA Certificate: A certificate from a Certificate Authority (CA) that signs other certificates, establishing a chain of trust.

For local testing, we can generate self-signed certificates using tools like openssl. In a production environment, you'd use certificates from a trusted CA.

Here's how to create a CA, a server certificate, and a client certificate:

# CA key and cert
openssl genrsa -out ca_key.pem 2048
openssl req -new -x509 -days 365 -key ca_key.pem -out ca.pem -subj "/CN=MyTestCA"

# Server key and cert
openssl genrsa -out server_key.pem 2048
openssl req -new -key server_key.pem -out server.csr -subj "/CN=server.test"
openssl x509 -req -days 365 -in server.csr -CA ca.pem -CAkey ca_key.pem -CAcreateserial -out server.pem

# Client key and cert
openssl genrsa -out client_key.pem 2048
openssl req -new -key client_key.pem -out client.csr -subj "/CN=client.test"
openssl x509 -req -days 365 -in client.csr -CA ca.pem -CAkey ca_key.pem -CAcreateserial -out client.pem

To enable TLS, we need to configure the Erlang kernel application. We set proto_dist to inet_tls and provide SSL options.

Node A (the 'server' in this context, listening for connections) needs its certificate, private key, and the CA certificate to verify clients.

erl -sname nodeA -kernel proto_dist inet_tls -kernel dist_listen_min 9000 -kernel dist_listen_max 9000 -kernel ssl_dist_opt '[{server,{certfile,"server.pem"},{keyfile,"server_key.pem"},{cacertfile,"ca.pem"}}, {client,{cacertfile,"ca.pem"}}]'

Note the dist_listen_min/max to fix the port for easier firewall setup.

Node B (the 'client', initiating a connection) also needs similar configuration. It provides its own certificate and key, and the CA certificate to verify the server.

erl -sname nodeB -kernel proto_dist inet_tls -kernel dist_listen_min 9001 -kernel dist_listen_max 9001 -kernel ssl_dist_opt '[{client,{certfile,"client.pem"},{keyfile,"client_key.pem"},{cacertfile,"ca.pem"}}]'

Both nodes must trust the CA that signed the other's certificate. This is why they both reference ca.pem.

Let's put it all together! First, compile this simple module on both nodes. Then, start two Erlang nodes with the necessary TLS options (using your generated certificate files). Finally, try calling my_module:hello/0 remotely to see a secure interaction.

1. Compile the module:
erlc my_module.erl

2. Start Node A (replace hostname with your machine's hostname):
erl -sname nodeA@hostname -kernel proto_dist inet_tls -kernel dist_listen_min 9000 -kernel dist_listen_max 9000 -kernel ssl_dist_opt '[{server,{certfile,"server.pem"},{keyfile,"server_key.pem"},{cacertfile,"ca.pem"}}, {client,{cacertfile,"ca.pem"}}]'

3. Start Node B (in a new terminal):
erl -sname nodeB@hostname -kernel proto_dist inet_tls -kernel dist_listen_min 9001 -kernel dist_listen_max 9001 -kernel ssl_dist_opt '[{client,{certfile,"client.pem"},{keyfile,"client_key.pem"},{cacertfile,"ca.pem"}}]'

4. On Node B, connect and call:
net_adm:ping('nodeA@hostname').
rpc:call('nodeA@hostname', my_module, hello, []).

After connecting the nodes, you can verify that the connection is indeed using TLS. The ssl application provides functions to inspect active connections.

From either connected node, you can get information about the SSL connection. For example, on nodeA, after nodeB has connected:

{ok, Socket} = gen_tcp:connect("localhost", 9001, [binary, {active, false}, {packet, 4}, {reuseaddr, true}]).
{ok, SslSocket} = ssl:handshake(Socket, [{mode, client}]).
ssl:connection_info(SslSocket).

You should see details about the TLS version, cipher suite, and certificates in use.

Congratulations! You've taken your first steps into securing distributed Erlang applications.

We covered:

• The importance of TLS for secure node communication.
• The core components: certificates, private keys, and Certificate Authorities.
• How to generate self-signed certificates for testing.
• Configuring Erlang nodes to use TLS with proto_dist and ssl_dist_opt.
• Running a basic secure distributed application.

Securing your Erlang systems is vital. Next, we'll explore how to handle authentication and authorization within your applications.