From 150fbc75ca713527faa8dda0dee819f1e06f1ea1 Mon Sep 17 00:00:00 2001
From: Ingela Anderton Andin Here we consider the creation of example certificates.
- The where We shall use the following subcommands to create certificates for
- the purpose of testing Erlang/OTP SSL:
- We create the following certificates:
- An The required sections for the subcommands we are going to
- use are as follows:
- The Erlang root CA is created with the command where the option The OTP CA is created by first creating a certificate request
- with the command and the ask the Erlang CA to sign it: where the option The The following module The purpose of the Note that the module creates temporary OpenSSL configuration files
- for the The peer certificate is returned as a DER encoded binary.
diff --git a/lib/ssl/doc/src/ssl_app.xml b/lib/ssl/doc/src/ssl_app.xml
index fac2053532..2ba6f48611 100644
--- a/lib/ssl/doc/src/ssl_app.xml
+++ b/lib/ssl/doc/src/ssl_app.xml
@@ -22,38 +22,11 @@
The Secure Socket Layer (SSL) application provides secure
- socket communication over TCP/IP. Note that this documentation
- is mainly valid for the old ssl implementation and will
- be replaced in a future release.
- In previous versions of Erlang/OTP SSL it was advised, as a
- work-around, to set the operating system environment variable
- However, the OpenSSL package does interpret that environment
- variable. Hence a setting of that variable might have
- unpredictable effects on the Erlang/OTP SSL application. It is
- therefore adviced to not used that environment variable at all. ]]>
-
-
-
-
-
-
-
-
- openssl req -new -x509 -config /some/path/req.cnf \\
- -keyout /some/path/key.pem -out /some/path/cert.pem
-
- openssl req -new -config /some/path/req.cnf \\
- -keyout /some/path/key.pem -out /some/path/req.pem
-
- openssl ca -batch -notext -config /some/path/req.cnf \\
- -extensions ca_cert -in /some/path/req.pem -out /some/path/cert.pem
-
-This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This product includes software written by Tim Hudson (tjh@cryptsoft.com). Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com). All rights reserved.
-For further OpenSSL and SSLeay license information se the chapter
- http://www.erlang.org
-
-
-/* ====================================================================
- * Copyright (c) 1998-2002 The OpenSSL Project. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in
- * the documentation and/or other materials provided with the
- * distribution.
- *
- * 3. All advertising materials mentioning features or use of this
- * software must display the following acknowledgment:
- * "This product includes software developed by the OpenSSL Project
- * for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
- *
- * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
- * endorse or promote products derived from this software without
- * prior written permission. For written permission, please contact
- * openssl-core@openssl.org.
- *
- * 5. Products derived from this software may not be called "OpenSSL"
- * nor may "OpenSSL" appear in their names without prior written
- * permission of the OpenSSL Project.
- *
- * 6. Redistributions of any form whatsoever must retain the following
- * acknowledgment:
- * "This product includes software developed by the OpenSSL Project
- * for use in the OpenSSL Toolkit (http://www.openssl.org/)"
- *
- * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
- * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
- * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
- * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
- * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
- * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
- * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
- * OF THE POSSIBILITY OF SUCH DAMAGE.
- * ====================================================================
- *
- * This product includes cryptographic software written by Eric Young
- * (eay@cryptsoft.com). This product includes software written by Tim
- * Hudson (tjh@cryptsoft.com).
- *
- */
-
-/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)
- * All rights reserved.
- *
- * This package is an SSL implementation written
- * by Eric Young (eay@cryptsoft.com).
- * The implementation was written so as to conform with Netscapes SSL.
- *
- * This library is free for commercial and non-commercial use as long as
- * the following conditions are aheared to. The following conditions
- * apply to all code found in this distribution, be it the RC4, RSA,
- * lhash, DES, etc., code; not just the SSL code. The SSL documentation
- * included with this distribution is covered by the same copyright terms
- * except that the holder is Tim Hudson (tjh@cryptsoft.com).
- *
- * Copyright remains Eric Young's, and as such any Copyright notices in
- * the code are not to be removed.
- * If this package is used in a product, Eric Young should be given attribution
- * as the author of the parts of the library used.
- * This can be in the form of a textual message at program startup or
- * in documentation (online or textual) provided with the package.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the copyright
- * notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in the
- * documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- * must display the following acknowledgement:
- * "This product includes cryptographic software written by
- * Eric Young (eay@cryptsoft.com)"
- * The word 'cryptographic' can be left out if the rouines from the library
- * being used are not cryptographic related :-).
- * 4. If you include any Windows specific code (or a derivative thereof) from
- * the apps directory (application code) you must include an acknowledgement:
- * "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
- *
- * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- *
- * The licence and distribution terms for any publically available version or
- * derivative of this code cannot be changed. i.e. this code cannot simply be
- * copied and put under another distribution licence
- * [including the GNU Public Licence.]
- */
-
Note that the environment parameters can be set on the command line, for instance,
-Enables all SSL servers (those that listen and accept)
- to use ephemeral RSA key generation when a clients connect with
- weak handshake cipher specifications, that need equally weak
- ciphers from the server (i.e. obsolete restrictions on export
- ciphers). Default is
Protocol that will be supported by started clients and + servers. If this option is not set it will default to all + protocols currently supported by the erlang ssl application. + Note that this option may be overridden by the version option + to ssl:connect/[2,3] and ssl:listen/2. +
Causes debug information to be written to standard
- output. Default is
Causes debug information output controlled by
Sets
Name of port program. The default is
Name of protocols to use. If this option is not set,
- all protocols are assumed, i.e. the default value is
-
The lifetime of session data in seconds. +
Define the port number of the listen port of the - SSL port program. Almost never is this option needed. +
+ Name of session cache callback module that implements + the ssl_session_cache_api behavior, defaults to + ssl_session_cache.erl.
Set the listen queue size of the listen port of the - SSL port program. The default is 128. -
++ List of arguments to the init function in session cache + callback module, defaults to []. +
The current implementation of the Erlang SSL application is - based on the OpenSSL package version 0.9.7 or higher. - There are source and binary releases on the web. -
-Source releases of OpenSSL can be downloaded from the
The same URL also contains links to some compiled binaries and
- libraries of OpenSSL (see the
For some Unix flavours there are binary packages available - on the net. -
-If you cannot find a suitable binary OpenSSL package, you - have to fetch an OpenSSL source release and compile it. -
-You then have to compile and install the libraries
-
For Unix The
If that is not applicable to the particular Unix operating
- system used, the example
For
Users must be aware of export restrictions and patent rights - concerning cryptographic software. -
+This chapter describes how the Erlang distribution can use - SSL to get additional verification and security.
+ SSL to get additional verification and security. + +Note this + documentation is written for the old ssl implementation and + will be updated for the new one once this functionallity is + supported by the new implementation.
Here we provide a short introduction to the SSL protocol. We only - consider those part of the protocol that are important from a - programming point of view. -
-For a very good general introduction to SSL and TLS see the book - . -
-Outline:
-The erlang ssl application currently supports SSL 3.0 and TLS 1.0 + RFC 2246, and will in the future also support later versions of TLS. + SSL 2.0 is not supported. +
-The SSL protocol is implemented on top of the TCP/IP protocol. - From an endpoint view it also has the same type of connections - as that protocol, almost always created by calls to socket - interface functions listen, accept and - connect. The endpoints are servers and - clients. -
-A serverlistens for connections on a - specific address and port. This is done once. The server then - accepts each connections on that same address and - port. This is typically done indefinitely many times. -
-A client connects to a server on a specific address - and port. For each purpose this is done once. -
-For a plain TCP/IP connection the establishment of a connection - (through an accept or a connect) is followed by data transfer between - the client and server, finally ended by a connection close. -
-An SSL connection also consists of data transfer and connection - close, However, the data transfer contains encrypted data, and - in order to establish the encryption parameters, the data - transfer is preceded by an SSL handshake. In this - handshake the server plays a dominant role, and the main - instrument used in achieving a valid SSL connection is the - server's certificate. We consider certificates in the - next section, and the SSL handshake in a subsequent section.
-By default erlang ssl is run over the TCP/IP protocol even + though you could plug in an other reliable transport protocol + with the same API as gen_tcp.
+ +If a client and server wants to use an upgrade mechanism, such as + defined by RFC2817, to upgrade a regular TCP/IP connection to a ssl + connection the erlang ssl API supports this. This can be useful for + things such as supporting HTTP and HTTPS on the same port and + implementing virtual hosting. +
A certificate is similar to a driver's license, or a - passport. The holder of the certificate is called the - subject. First of all the certificate identifies the - subject in terms of the name of the subject, its postal address, - country name, company name (if applicable), etc. -
-Although a driver's license is always issued by a well-known and - distinct authority, a certificate may have an issuer - that is not so well-known. Therefore a certificate also always - contains information on the issuer of the certificate. That - information is of the same type as the information on the - subject. The issuer of a certificate also signs the certificate - with a digital signature (the signature is an inherent - part of the certificate), which allow others to verify that the - issuer really is the issuer of the certificate. -
-Now that a certificate can be checked by verifying the - signature of the issuer, the question is how to trust the - issuer. The answer to this question is to require that there is - a certificate for the issuer as well. That issuer has in turn an - issuer, which must also have a certificate, and so on. This - certificate chain has to have en end, which then must - be a certificate that is trusted by other means. We shall cover - this problem of authentication in a subsequent - section. -
+To achive authentication and privacy the client and server will + perform a TLS Handshake procedure before transmitting or receiving + any data. During the handshake they agree on a protocol version and + cryptographic algorithms, they generate shared secrets using public + key cryptographics and optionally authenticate each other with + digital certificates.
An encryption algorithm is a mathematical algorithm for - encryption and decryption of messages (arrays of bytes, - say). The algorithm as such is always required to be publicly - known, otherwise its strength cannot be evaluated, and hence it - cannot be used reliably. The secrecy of an encrypted message is - not achieved by the secrecy of the algorithm used, but by the - secrecy of the keys used as input to the encryption and - decryption algorithms. For an account of cryptography in general - see . -
-There are two classes of encryption algorithms: symmetric key algorithms and public key algorithms. Both - types of algorithms are used in the SSL protocol. -
-In the sequel we assume holders of keys keep them secret (except - public keys) and that they in that sense are trusted. How a - holder of a secret key is proved to be the one it claims to be - is a question of authentication, which, in the context - of the SSL protocol, is described in a section further below. -
- -A symmetric key algorithm has one key only. The key - is used for both encryption and decryption. Obviously the key - of a symmetric key algorithm must always be kept secret by the - users of the key. DES is an example of a symmetric key - algorithm. -
-Symmetric key algorithms are fast compared to public key - algorithms. They are therefore typically used for encrypting - bulk data. -
-A public key algorithm has two keys. Any of the two - keys can be used for encryption. A message encrypted with one - of the keys, can only be decrypted with the other key. One of - the keys is public (known to the world), while the other key - is private (i.e. kept secret) by the owner of the two keys. -
-RSA is an example of a public key algorithm. -
-Public key algorithms are slow compared to symmetric key - algorithms, and they are therefore seldom used for bulk data - encryption. They are therefore only used in cases where the - fact that one key is public and the other is private, provides - features that cannot be provided by symmetric algorithms. -
-An interesting feature of a public key algorithm is that its - public and private keys can both be used for encryption. - Anyone can use the public key to encrypt a message, and send - that message to the owner of the private key, and be sure of - that only the holder of the private key can decrypt the - message. -
-On the other hand, the owner of the private key can encrypt a - message with the private key, thus obtaining an encrypted - message that can decrypted by anyone having the public key. -
-The last approach can be used as a digital signature - algorithm. The holder of the private key signs an array of - bytes by performing a specified well-known message digest algorithm to compute a hash of the array, encrypts the - hash value with its private key, an then presents the original - array, the name of the digest algorithm, and the encryption of - the hash value as a signed array of bytes. -
-Now anyone having the public key, can decrypt the encrypted - hash value with that key, compute the hash with the specified - digest algorithm, and check that the hash values compare equal - in order to verify that the original array was indeed signed - by the holder of the private key. -
-What we have accounted for so far is by no means all that can - be said about digital signatures (see for - further details). -
-A message digest algorithm is a hash function that accepts - an array bytes of arbitrary but finite length of input, and - outputs an array of bytes of fixed length. Such an algorithm - is also required to be very hard to invert. -
-MD5 (16 bytes output) and SHA1 (20 bytes output) are examples - of message digest algorithms. -
-A symmetric key algorithm has one key only. The key is + used for both encryption and decryption. These algoritms are fast + compared to public key algorithms (using two keys, a public and a + private one) and are therefore typically used for encrypting bulk + data. +
+ +The keys for the symmetric encryption are generated uniquely + for each connection and are based on a secret negotiated + in the TLS handshake.
+ +The TLS handsake protocol and data transfer is run on top of + the TLS Record Protocol that uses a keyed-hash MAC (Message + Authenticity Code), or HMAC, to protect the message's data + integrity. From the TLS RFC "A Message Authentication Code is a + one-way hash computed from a message and some secret data. It is + difficult to forge without knowing the secret data. Its purpose is + to detect if the message has been altered." +
+The main purpose of the handshake performed before an an SSL - connection is established is to negotiate the encryption - algorithm and key to be used for the bulk data transfer between - the client and the server. We are writing the key, - since the algorithm to choose for bulk encryption one of the - symmetric algorithms. -
-There is thus only one key to agree upon, and obviously that - key has to be kept secret between the client and the server. To - obtain that the handshake has to be encrypted as well. -
-The SSL protocol requires that the server always sends its - certificate to the client in the beginning of the handshake. The - client then retrieves the server's public key from the - certificate, which means that the client can use the server's - public key to encrypt messages to the server, and the server can - decrypt those messages with its private key. Similarly, the - server can encrypt messages to the client with its private key, - and the client can decrypt messages with the server's public - key. It is thus is with the server's public and private keys - that messages in the handshake are encrypted and decrypted, and - hence the key agreed upon for symmetric encryption of bulk data - can be kept secret (there are more things to consider to really - keep it secret, see ). -
-The above indicates that the server does not care who is - connecting, and that only the client has the possibility to - properly identify the server based on the server's certificate. - That is indeed true in the minimal use of the protocol, but it - is possible to instruct the server to request the certificate of - the client, in order to have a means to identify the client, but - it is by no means required to establish an SSL connection. -
-If a server request the client certificate, it verifies, as a - part of the protocol, that the client really holds the private - key of the certificate by sending the client a string of bytes - to encrypt with its private key, which the server then decrypts - with the client's public key, the result of which is compared - with the original string of bytes (a similar procedure is always - performed by the client when it has received the server's - certificate). -
-The way clients and servers authenticate each other, - i.e. proves that their respective peers are what they claim to - be, is the topic of the next section. -
-A certificate is similar to a driver's license, or a + passport. The holder of the certificate is called the + subject. The certificate is signed + with the private key of the issuer of the certificate. A chain + of trust is build by having the issuer in its turn being + certified by an other certificate and so on until you reach the + so called root certificate that is self signed e.i. issued + by itself.
+ +Certificates are issued by certification + authorities (CAs) only. There are a handful of + top CAs in the world that issue root certificates. You can + examine the certificates of several of them by clicking + through the menus of your web browser. +
+Authentication of the sender is done by public key path + validation as defined in RFC 3280. Simplified that means that + each certificate in the certificate chain is issued by the one + before, the certificates attributes are valid ones, and the + root cert is a trusted cert that is present in the trusted + certs database kept by the peer.
+ +The server will always send a certificate chain as part of + the TLS handshake, but the client will only send one if + the server requests it. If the client does not have + an appropriate certificate it may send an "empty" certificate + to the server.
+ +The client may choose to accept some path evaluation errors + for instance a web browser may ask the user if they want to + accept an unknown CA root certificate. The server, if it request + a certificate, will on the other hand not accept any path validation + errors. It is configurable if the server should accept + or reject an "empty" certificate as response to + a certificate request.
+From the TLS RFC "A TLS session is an association between a + client and a server. Sessions are created by the handshake + protocol. Sessions define a set of cryptographic security + parameters, which can be shared among multiple + connections. Sessions are used to avoid the expensive negotiation + of new security parameters for each connection."
-As we have already seen the reception of a certificate from a - peer is not enough to prove that the peer is authentic. More - certificates are needed, and we have to consider how certificates - are issued and on what grounds. -
-Certificates are issued by certification authorities - (CAs) only. They issue certificates both for other CAs - and ordinary users (which are not CAs). -
-Certain CAs are top CAs, i.e. they do not have a - certificate issued by another CA. Instead they issue their own - certificate, where the subject and issuer part of the - certificate are identical (such a certificate is called a - self-signed certificate). A top CA has to be well-known, and has - to have a publicly available policy telling on what grounds it - issues certificates. -
-There are a handful of top CAs in the world. You can examine the - certificates of several of them by clicking through the menus of - your web browser. -
-A top CA typically issues certificates for other CAs, called - intermediate CAs, but possibly also to ordinary users. Thus - the certificates derivable from a top CA constitute a tree, where - the leaves of the tree are ordinary user certificates. -
-A certificate chain is an ordered sequence of
- certificates,
Now to verify that a certificate chain is unbroken we have to
- take the public key from each certificate
Session data is by default kept by the ssl application in a + memory storage hence session data will be lost at application + restart or takeover. Users may define their own callback module + to handle session data storage if persistent data storage is + required. Session data will also be invalidated after 24 hours + from it was saved, for security reasons. It is of course + possible to configure the amount of time the session data should be + saved.
-Now that there is a way to authenticate a certificate by - checking that all links of a certificate chain are unbroken, - the question is how you can be sure to trust the certificates - in the chain, and in particular the top CA certificate of the - chain. -
-To provide an answer to that question consider the
- perspective of a client, which have just received the
- certificate of the server. In order to authenticate the server
- the client has to construct a certificate chain and to prove
- that the chain is unbroken. The client has to have a set of CA
- certificates (top CA or intermediate CA certificates) not
- obtained from the server, but obtained by other means. Those
- certificates are kept
More specifically, the client does not really have to have - top CA certificates in its local storage. In order to - authenticate a server it is sufficient for the client to - posses the trusted certificate of the issuer of the server - certificate. -
-Now that is not the whole story. A server can send an - (incomplete) certificate chain to its client, and then the - task of the client is to construct a certificate chain that - begins with a trusted certificate and ends with the server's - certificate. (A client can also send a chain to its server, - provided the server requested the client's certificate.) -
-All this means that an unbroken certificate chain begins with - a trusted certificate (top CA or not), and ends with the peer - certificate. That is the end of the chain is obtained from the - peer, but the beginning of the chain is obtained from local - storage, which is considered trusted. -
-Ssl clients will by default try to reuse an available session, + ssl servers will by default agree to reuse sessions when clients + ask to do so.
+ +The following data types are used in the functions below: +
+ +Delets a cache entry. Will only be called from the cache + handling process. +
+Calls Fun(Elem, AccIn) on successive elements of the + cache, starting with AccIn == Acc0. Fun/2 must return a new + accumulator which is passed to the next call. The function returns + the final value of the accumulator. Acc0 is returned if the cache is + empty. +
+Performes possible initializations of the cache and returns + a reference to it that will be used as parameter to the other + api functions. Will be called by the cache handling processes + init function, hence puting the same requierments on it as + a normal process init function. +
+Looks up a cach entry. Should be callable from any + process. +
+Selects sessions that could be reused. Should be callable + from any process. +
+Takes care of possible cleanup that is needed when the + cache handling process terminates. +
+Caches a new session or updates a already cached one. Will + only be called from the cache handling process. +
+The SSL application provides secure communication over - sockets. Note that this users guide was written for - the old ssl implementation that is now being phased out and - will be replaced by a new guide in a future release. -
-This product includes software developed by the OpenSSL Project for - use in the OpenSSL Toolkit (http://www.openssl.org/). -
-This product includes cryptographic software written by Eric Young - (eay@cryptsoft.com). -
-This product includes software written by Tim Hudson - (tjh@cryptsoft.com). -
-For full OpenSSL and SSLeay license texts, see
To see relevant version information for ssl you can + call ssl:versions/0
+ +To see all supported cipher suites + call ssl:cipher_suites/0. Note that available cipher suites + for a connection will depend on your certificate. It is also + possible to specify a specific cipher suite(s) that you + want your connection to use. Default is to use the strongest + available.
+ +Here follows some small example of how to set up client/server connections
+ using the erlang shell. The returned value of the sslsocket has been abbreviated with
+
The minimal setup is not the most secure setup of ssl.
+Start server side
+1 server> ssl:start().
+ok
+
+ Create a ssl listen socket
+2 server> {ok, ListenSocket} =
+ssl:listen(9999, [{certfile, "cert.pem"}, {keyfile, "key.pem"},{reuseaddr, true}]).
+{ok,{sslsocket, [...]}}
+
+ Do a transport accept on the ssl listen socket
+3 server> {ok, Socket} = ssl:transport_accept(ListenSocket).
+{ok,{sslsocket, [...]}}
+
+ Start client side
+1 client> ssl:start().
+ok
+
+ 2 client> {ok, Socket} = ssl:connect("localhost", 9999, [], infinity).
+{ok,{sslsocket, [...]}}
+
+ Do the ssl handshake
+4 server> ok = ssl:ssl_accept(Socket).
+ok
+
+ Send a messag over ssl
+5 server> ssl:send(Socket, "foo").
+ok
+
+ Flush the shell message queue to see that we got the message + sent on the server side
+3 client> flush().
+Shell got {ssl,{sslsocket,[...]},"foo"}
+ok
+ To upgrade a TCP/IP connection to a ssl connection the + client and server have to aggre to do so. Agreement + may be accompliced by using a protocol such the one used by HTTP + specified in RFC 2817.
Start server side
+1 server> ssl:start().
+ok
+
+ Create a normal tcp listen socket
+2 server> {ok, ListenSocket} = gen_tcp:listen(9999, [{reuseaddr, true}]).
+{ok, #Port<0.475>}
+
+ Accept client connection
+3 server> {ok, Socket} = gen_tcp:accept(ListenSocket).
+{ok, #Port<0.476>}
+
+ Start client side
+1 client> ssl:start().
+ok
+
+ 2 client> {ok, Socket} = gen_tcp:connect("localhost", 9999, [], infinity).
+
+ Make sure active is set to false before trying + to upgrade a connection to a ssl connection, otherwhise + ssl handshake messages may be deliverd to the wrong process.
+4 server> inet:setopts(Socket, [{active, false}]).
+ok
+
+ Do the ssl handshake.
+5 server> {ok, SSLSocket} = ssl:ssl_accept(Socket, [{cacertfile, "cacerts.pem"},
+{certfile, "cert.pem"}, {keyfile, "key.pem"}]).
+{ok,{sslsocket,[...]}}
+
+ Upgrade to a ssl connection. Note that the client and server + must agree upon the upgrade and the server must call + ssl:accept/2 before the client calls ssl:connect/3.
+3 client>{ok, SSLSocket} = ssl:connect(Socket, [{cacertfile, "cacerts.pem"},
+{certfile, "cert.pem"}, {keyfile, "key.pem"}], infinity).
+{ok,{sslsocket,[...]}}
+
+ Send a messag over ssl
+4 client> ssl:send(SSLSocket, "foo").
+ok
+
+ Set active true on the ssl socket
+4 server> ssl:setopts(SSLSocket, [{active, true}]).
+ok
+
+ Flush the shell message queue to see that we got the message + sent on the client side
+5 server> flush().
+Shell got {ssl,{sslsocket,[...]},"foo"}
+ok
+ Here we provide an introduction to using the Erlang/OTP SSL
- application, which is accessed through the
We also present example code in the Erlang module
-
The
Servers use the interface functions
Clients use the
The
The most important SSL specific option is the
The
Similarly, the
The
The
The
Here is a simple client server example. -
-