From 07ae4f993de7dc717aec096943aa91b9029bada3 Mon Sep 17 00:00:00 2001
From: Ingela Anderton Andin
- This module contains interface functions for the SSL/TLS protocol.
+ This module contains interface functions for the SSL/TLS/DTLS protocol.
For detailed information about the supported standards see
The following data types are used in the functions for SSL: The following data types are used in the functions for SSL/TLS/DTLS: The default socket options are
For valid options, see the
-
Defaults to
Defaults to
The following options have the same meaning in the client and the server:
@@ -289,11 +292,11 @@ atom()}} |If the verify callback fun returns
If the verify callback fun returns
If the verify callback fun always returns
-
If called with an extension unknown to the user application,
@@ -464,7 +467,7 @@ marker="public_key:public_key#pkix_path_validation-3">public_key:pkix_path_valid
See also
When an integer-value is specified, When an integer-value is specified, The following options are client-specific or have a slightly different
meaning in the client than in the server: The following options are server-specific or have a slightly different
meaning in the server than in the client: Used together with Used together with Enables the SSL server to have a local policy
+ Enables the TLS/DTLS server to have a local policy
for deciding if a session is to be reused or not.
Meaningful only if When an SSL socket is in active mode (the default), data from the
+ When an TLS/DTLS socket is in active mode (the default), data from the
socket is delivered to the owner of the socket in the form of
messages: Upgrades a If the option Opens an SSL connection to Opens an TLS/DTLS connection to When the option Closes an SSL connection. Closes an TLS/DTLS connection. Closes or downgrades an SSL connection. In the latter case the transport
+ Closes or downgrades an TLS connection. In the latter case the transport
connection will be handed over to the Can only be used with TLS connections; Can only be used with TLS/DTLS connections; Performs the SSL/TLS server-side handshake. Performs the SSL/TLS/DTLS server-side handshake. If If The socket returned can only be used with
The SSL application uses the default 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
@@ -45,16 +45,16 @@
In the SSL application, an extra distribution
module, The security level depends on the parameters provided to the
- SSL connection setup. Erlang node cookies are however always
+ TLS 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: To set up Erlang distribution over TLS: The following sections describe these steps. Boot scripts are built using the The following shows an example The following shows an example The distribution module for SSL is named The distribution module for SSL/TLS is named However, a node started in this way refuses to talk
- to other nodes, as no SSL parameters are supplied
+ to other nodes, as no TLS parameters are supplied
(see the next section).
- The SSL distribution options can be written into a file
+ The SSL/TLS distribution options can be written into a file
that is consulted when the node is started. This file name
is then specified with the command line argument
- Any available SSL option can be specified in an options file,
+ Any available SSL/TLS option can be specified in an options file,
but note that options that take a
- For SSL to work, at least a public key and a certificate
+ For SSL/TLS to work, at least a public key and a certificate
must be specified for the server side.
In the following example, the PEM file
- A node started in this way is fully functional, using SSL
+ A node started in this way is fully functional, using TLS
as the distribution protocol.
As in the previous section the PEM file
@@ -272,9 +272,9 @@ $ erl -boot /home/me/ssl/start_ssl -proto_dist inet_tls
On the
-
{release, {"OTP APN 181 01","R15A"}, {erts, "5.9"},
@@ -154,7 +154,7 @@ Eshell V5.0 (abort with ^G)
The simplest SSL options in the following list can be specified +
The simplest SSL/TLS options in the following list can be specified
by adding the
prefix
Note that
The server can also take the options
Raw socket options, such as
The command-line argument for specifying the SSL options is named +
The command-line argument for specifying the SSL/TLS options is named
A convenient way to specify arguments to Erlang is to use environment
variable
It is possible to use SSL distribution over IPv6 instead of +
It is possible to use SSL/TLS distribution over IPv6 instead of
IPv4. To do this, pass the option
A node started in this way will only be able to communicate with - other nodes using SSL distribution over IPv6.
+ other nodes using SSL/TLS distribution over IPv6.It is assumed that the reader is familiar with the Erlang programming language, the concepts of OTP, and has a basic - understanding of SSL/TLS.
+ understanding of SSL/TLS/DTLS.The Erlang SSL application implements the SSL/TLS protocol +
The Erlang SSL application implements the SSL/TLS/DTLS protocol
for the currently supported versions, see the
By default SSL/TLS is run over the TCP/IP protocol even
though you can plug in any other reliable transport protocol
with the same Application Programming Interface (API) as the
-
If a client and a server wants to use an upgrade mechanism, such as - defined by RFC 2817, to upgrade a regular TCP/IP connection to an SSL + defined by RFC 2817, to upgrade a regular TCP/IP connection to an TLS connection, this is supported by the Erlang SSL application API. This can be useful for, for example, supporting HTTP and HTTPS on the same port and - implementing virtual hosting. + implementing virtual hosting. Note this is a TLS feature only.
To achieve authentication and privacy, the client and server - perform a TLS handshake procedure before transmitting or receiving + perform a TLS/DTLS handshake procedure before transmitting or receiving any data. During the handshake, they agree on a protocol version and cryptographic algorithms, generate shared secrets using public key cryptographies, and optionally authenticate each other with @@ -73,10 +75,10 @@
The keys for the symmetric encryption are generated uniquely for each connection and are based on a secret negotiated - in the TLS handshake.
+ in the TLS/DTLS handshake. -The TLS handshake protocol and data transfer is run on top of - the TLS Record Protocol, which uses a keyed-hash Message +
The TLS/DTLS handshake protocol and data transfer is run on top of + the TLS/DTLS Record Protocol, which uses a keyed-hash Message Authenticity Code (MAC), or a Hash-based MAC (HMAC), to protect the message data integrity. From the TLS RFC: "A Message Authentication Code is a @@ -152,8 +154,8 @@ from it was saved, for security reasons. The amount of time the session data is to be saved can be configured.
-By default the SSL clients try to reuse an available session and - by default the SSL servers agree to reuse sessions when clients +
By default the TLS/DTLS clients try to reuse an available session and + by default the TLS/DTLS servers agree to reuse sessions when clients ask for it.
The minimal setup is not the most secure setup of SSL.
+The minimal setup is not the most secure setup of SSL/TLS/DTLS.
To set up client/server connections:
@@ -60,27 +60,27 @@1 server> ssl:start().
ok
- Step 2: Create an SSL listen socket:
+Step 2: Create an TLS listen socket: (To run DTLS add the option {protocol, dtls})
2 server> {ok, ListenSocket} =
ssl:listen(9999, [{certfile, "cert.pem"}, {keyfile, "key.pem"},{reuseaddr, true}]).
{ok,{sslsocket, [...]}}
- Step 3: Do a transport accept on the SSL listen socket:
+Step 3: Do a transport accept on the TLS listen socket:
3 server> {ok, Socket} = ssl:transport_accept(ListenSocket).
{ok,{sslsocket, [...]}}
- Step 4: Start the client side:
+Step 4: Start the client side:
1 client> ssl:start().
ok
-
+ To run DTLS add the option {protocol, dtls} to third argument.
2 client> {ok, Socket} = ssl:connect("localhost", 9999, [], infinity).
{ok,{sslsocket, [...]}}
- Step 5: Do the SSL handshake:
+Step 5: Do the TLS handshake:
4 server> ok = ssl:ssl_accept(Socket).
ok
- Step 6: Send a message over SSL:
+Step 6: Send a message over TLS:
5 server> ssl:send(Socket, "foo").
ok
@@ -92,7 +92,7 @@ ok
To upgrade a TCP/IP connection to an SSL connection, the
client and server must agree to do so. The agreement
@@ -125,24 +125,24 @@ ok
4 server> inet:setopts(Socket, [{active, false}]).
ok
-
Step 6: Do the SSL handshake:
-5 server> {ok, SSLSocket} = ssl:ssl_accept(Socket, [{cacertfile, "cacerts.pem"},
+ Step 6: Do the TLS handshake:
+ 5 server> {ok, TLSSocket} = ssl:ssl_accept(Socket, [{cacertfile, "cacerts.pem"},
{certfile, "cert.pem"}, {keyfile, "key.pem"}]).
{ok,{sslsocket,[...]}}
- Step 7: Upgrade to an SSL connection. The client and server
+
Step 7: Upgrade to an TLS connection. The client and server
must agree upon the upgrade. The server must call
ssl:accept/2 before the client calls ssl:connect/3.
- 3 client>{ok, SSLSocket} = ssl:connect(Socket, [{cacertfile, "cacerts.pem"},
+ 3 client>{ok, TLSSocket} = ssl:connect(Socket, [{cacertfile, "cacerts.pem"},
{certfile, "cert.pem"}, {keyfile, "key.pem"}], infinity).
{ok,{sslsocket,[...]}}
- Step 8: Send a message over SSL:
- 4 client> ssl:send(SSLSocket, "foo").
+ Step 8: Send a message over TLS:
+ 4 client> ssl:send(TLSSocket, "foo").
ok
- Step 9: Set active true on the SSL socket:
- 4 server> ssl:setopts(SSLSocket, [{active, true}]).
+ Step 9: Set active true on the TLS socket:
+ 4 server> ssl:setopts(TLSSocket, [{active, true}]).
ok
Step 10: Flush the shell message queue to see that the message
--
cgit v1.2.3
From 9a67fbf96da78df54bd18d487c6237256b8bef60 Mon Sep 17 00:00:00 2001
From: Ingela Anderton Andin
Date: Fri, 8 Dec 2017 15:17:17 +0100
Subject: ssl: Document enhancment
---
lib/ssl/doc/src/ssl_app.xml | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/lib/ssl/doc/src/ssl_app.xml b/lib/ssl/doc/src/ssl_app.xml
index 07cbfb3bd9..e79b79a434 100644
--- a/lib/ssl/doc/src/ssl_app.xml
+++ b/lib/ssl/doc/src/ssl_app.xml
@@ -72,7 +72,7 @@
DEPENDENCIES
- The SSL application uses the public_key and
+
The SSL application uses the public_key , asn1 and
Crypto application to handle public keys and encryption, hence
these applications must be loaded for the SSL application to work.
In an embedded environment this means they must be started with
@@ -123,14 +123,14 @@
new client connections. If the maximum number of sessions is
reached, the current cache entries will be invalidated
regardless of their remaining lifetime. Defaults to
- 1000.
Limits the growth of the servers session cache, that is how many client sessions are cached by the server. If the maximum number of sessions is reached, the current cache entries will be invalidated regardless of their remaining - lifetime. Defaults to 1000.
Introduced in ssl-8.0.2. Disables the PEM-cache. - The PEM cache has proven to be a bottleneck, until the - implementation has been improved this can be used as - a workaround. Defaults to false. + Can be used as a workaround for the PEM-cache bottlneck + before ssl-8.1.1. Defaults to false.
opaque()
According to old API.
TLS protocol versions supported by started clients and servers.
This option overrides the application environment option
-
Returns a list of supported ECCs.
Returns version information relevant for the SSL
@@ -1345,19 +1354,35 @@ fun(srp, Username :: string(), UserState :: term()) ->
- The ssl application is an implementation of the SSL/TLS protocol in Erlang. + The ssl application is an implementation of the SSL/TLS/DTLS protocol in Erlang.
Protocol supported by started clients and
servers. If this option is not set, it defaults to all
- protocols currently supported by the SSL application.
+ TLS protocols currently supported by the SSL application.
This option can be overridden by the version option
to
Protocol supported by started clients and
+ servers. If this option is not set, it defaults to all
+ DTLS protocols currently supported by the SSL application.
+ This option can be overridden by the version option
+ to
Maximum lifetime of the session data in seconds. Defaults to 24 hours which is the maximum
recommended lifetime by Introduced in ssl-8.0.2. Disables the PEM-cache.
- Can be used as a workaround for the PEM-cache bottlneck
+ Can be used as a workaround for the PEM-cache bottleneck
before ssl-8.1.1. Defaults to false.