<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html xmlns:fn="http://www.w3.org/2005/02/xpath-functions">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="stylesheet" href="../../../../doc/otp_doc.css" type="text/css">
<title>Erlang -- Transport Layer Security (TLS) and its predecessor, Secure Socket Layer (SSL)</title>
</head>
<body bgcolor="white" text="#000000" link="#0000ff" vlink="#ff00ff" alink="#ff0000"><div id="container">
<script id="js" type="text/javascript" language="JavaScript" src="../../../../doc/js/flipmenu/flipmenu.js"></script><script id="js2" type="text/javascript" src="../../../../doc/js/erlresolvelinks.js"></script><script language="JavaScript" type="text/javascript">
<!--
function getWinHeight() {
var myHeight = 0;
if( typeof( window.innerHeight ) == 'number' ) {
//Non-IE
myHeight = window.innerHeight;
} else if( document.documentElement && ( document.documentElement.clientWidth ||
document.documentElement.clientHeight ) ) {
//IE 6+ in 'standards compliant mode'
myHeight = document.documentElement.clientHeight;
} else if( document.body && ( document.body.clientWidth || document.body.clientHeight ) ) {
//IE 4 compatible
myHeight = document.body.clientHeight;
}
return myHeight;
}
function setscrollpos() {
var objf=document.getElementById('loadscrollpos');
document.getElementById("leftnav").scrollTop = objf.offsetTop - getWinHeight()/2;
}
function addEvent(obj, evType, fn){
if (obj.addEventListener){
obj.addEventListener(evType, fn, true);
return true;
} else if (obj.attachEvent){
var r = obj.attachEvent("on"+evType, fn);
return r;
} else {
return false;
}
}
addEvent(window, 'load', setscrollpos);
//--></script><div id="leftnav"><div class="innertube">
<img alt="Erlang logo" src="../../../../doc/erlang-logo.png"><br><small><a href="users_guide.html">User's Guide</a><br><a href="index.html">Reference Manual</a><br><a href="release_notes.html">Release Notes</a><br><a href="../pdf/ssl-5.1.2.pdf">PDF</a><br><a href="../../../../doc/index.html">Top</a></small><p><strong>Secure Socket Layer </strong><br><strong>User's Guide</strong><br><small>Version 5.1.2</small></p>
<br><a href="javascript:openAllFlips()">Expand All</a><br><a href="javascript:closeAllFlips()">Contract All</a><p><small><strong>Chapters</strong></small></p>
<ul class="flipMenu" imagepath="../../../../doc/js/flipmenu">
<li id="loadscrollpos" title="Transport Layer Security (TLS) and its predecessor, Secure Socket Layer (SSL)" expanded="true">Transport Layer Security (TLS) and its predecessor, Secure Socket Layer (SSL)<ul>
<li><a href="ssl_protocol.html">
Top of chapter
</a></li>
<li title="Security overview"><a href="ssl_protocol.html#id57982">Security overview</a></li>
<li title="Data Privacy and Integrity"><a href="ssl_protocol.html#id56532">Data Privacy and Integrity</a></li>
<li title="Digital Certificates"><a href="ssl_protocol.html#id58292">Digital Certificates</a></li>
<li title="Authentication of Sender"><a href="ssl_protocol.html#id56624">Authentication of Sender</a></li>
<li title="TLS Sessions"><a href="ssl_protocol.html#id56507">TLS Sessions</a></li>
</ul>
</li>
<li id="no" title="Using the SSL API" expanded="false">Using the SSL API<ul>
<li><a href="using_ssl.html">
Top of chapter
</a></li>
<li title="General information"><a href="using_ssl.html#id57223">General information</a></li>
<li title="Setting up connections"><a href="using_ssl.html#id56966">Setting up connections</a></li>
</ul>
</li>
<li id="no" title="Using SSL for Erlang Distribution" expanded="false">Using SSL for Erlang Distribution<ul>
<li><a href="ssl_distribution.html">
Top of chapter
</a></li>
<li title="Introduction"><a href="ssl_distribution.html#id61749">Introduction</a></li>
<li title="Building boot scripts including the SSL application"><a href="ssl_distribution.html#id60782">Building boot scripts including the SSL application</a></li>
<li title="Specifying distribution module for net_kernel"><a href="ssl_distribution.html#id57343">Specifying distribution module for net_kernel</a></li>
<li title="Specifying SSL options"><a href="ssl_distribution.html#id57400">Specifying SSL options</a></li>
<li title="Setting up environment to always use SSL"><a href="ssl_distribution.html#id62020">Setting up environment to always use SSL</a></li>
</ul>
</li>
</ul>
</div></div>
<div id="content">
<div class="innertube">
<h1>1 Transport Layer Security (TLS) and its predecessor, Secure Socket Layer (SSL)</h1>
<p>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.
</p>
<p>By default erlang SSL is run over the TCP/IP protocol even
though you could plug in any other reliable transport protocol
with the same API as gen_tcp.</p>
<p>If a client and server wants to use an upgrade mechanism, such as
defined by RFC2817, to upgrade a regular TCP/IP connection to an 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.
</p>
<h3><a name="id57982">1.1
Security overview</a></h3>
<p>To achieve 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.</p>
<h3><a name="id56532">1.2
Data Privacy and Integrity</a></h3>
<p>A <strong>symmetric key</strong> algorithm has one key only. The key is
used for both encryption and decryption. These algorithms 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.
</p>
<p>The keys for the symmetric encryption are generated uniquely
for each connection and are based on a secret negotiated
in the TLS handshake. </p>
<p>The TLS handshake 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."
</p>
<h3><a name="id58292">1.3
Digital Certificates</a></h3>
<p>A certificate is similar to a driver's license, or a
passport. The holder of the certificate is called the
<strong>subject</strong>. 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 i.e. issued
by itself.</p>
<p>Certificates are issued by <strong>certification
authorities</strong> (<strong>CA</strong>s) 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.
</p>
<h3><a name="id56624">1.4
Authentication of Sender</a></h3>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h3><a name="id56507">1.5
TLS Sessions</a></h3>
<p>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."</p>
<p>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.</p>
<p>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.</p>
</div>
<div class="footer">
<hr>
<p>Copyright © 1999-2012 Ericsson AB. All Rights Reserved.</p>
</div>
</div>
</div></body>
</html>
distrib
>
Fedora
>
17
>
i386
>
media
>
updates
>
by-pkgid
>
675c8c8167236dfcf8d66da674f931e8
>
files
>
1371
