498 lines
33 KiB
HTML
498 lines
33 KiB
HTML
|
<!-- BeginDsi "dsi/head.html" -->
|
||
|
|
<!DOCTYPE html>
|
||
|
|
<html lang="en">
|
||
|
|
<head>
|
||
|
|
<title>Embedthis Appweb 4.3.4 Documentation</title>
|
||
|
|
<meta name="keywords" content="embedded web server, web server software, embedded HTTP, application web server,
|
||
|
|
embedded server, small web server, HTTP server, library web server, library HTTP, HTTP library" />
|
||
|
|
<meta name="description" content="Embedthis Sofware provides commercial and open source embedded web servers for
|
||
|
|
devices and applications." />
|
||
|
|
<meta name="robots" content="index,follow" />
|
||
|
|
<link href="../../../doc.css" rel="stylesheet" type="text/css" />
|
||
|
|
<link href="../../../print.css" rel="stylesheet" type="text/css" media="print"/>
|
||
|
|
<!--[if IE]>
|
||
|
|
<link href="../../../iehacks.css" rel="stylesheet" type="text/css" />
|
||
|
|
<![endif]-->
|
||
|
|
<link href="http://www.google.com/cse/style/look/default.css" type="text/css" rel="stylesheet" />
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<body>
|
||
|
|
<div class="top">
|
||
|
|
<a class="logo" href="http://appwebserver.org/"> </a>
|
||
|
|
<div class="topRight">
|
||
|
|
<div class="search">
|
||
|
|
<div id="cse-search-form"></div>
|
||
|
|
<div class="version">Embedthis Appweb 4.3.4</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="crumbs">
|
||
|
|
<a href="../../../index.html">Home</a>
|
||
|
|
<!-- EndDsi -->
|
||
|
|
> <a href="index.html">Users Guide</a> > <b>SSL Overview</b>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="content">
|
||
|
|
<div class="contentRight">
|
||
|
|
<h1>Quick Nav</h1>
|
||
|
|
<ul class="nav">
|
||
|
|
<li><a href="#cryptographicTechniques">Cryptographic Techniques</a></li>
|
||
|
|
<li><a href="#symmetricCryptography">Symmetric Cryptography</a></li>
|
||
|
|
<li><a href="#publicKeyCryptography">Public Key Cryptography</a></li>
|
||
|
|
<li><a href="#digitalSignatures">Digital Signatures</a></li>
|
||
|
|
<li><a href="#messageDigests">Message Digests</a></li>
|
||
|
|
<li><a href="#certificates">Certificates</a></li>
|
||
|
|
<li><a href="#certificateAuthorities">Certificate Authorities</a></li>
|
||
|
|
<li><a href="#sslOverview">SSL Overview</a></li>
|
||
|
|
</ul>
|
||
|
|
<!-- BeginDsi "dsi/usersGuideSeeAlso.html" -->
|
||
|
|
<h1>See Also</h1>
|
||
|
|
<ul class="nav">
|
||
|
|
<li><a href="../../../guide/appweb/users/index.html">User Guide Overview</a></li>
|
||
|
|
<li><a href="../../../guide/appweb/users/configuration.html">Configuring Appweb</a></li>
|
||
|
|
<li><a href="../../../guide/appweb/users/ports.html">Ports and Binding</a></li>
|
||
|
|
<li><a href="../../../guide/appweb/users/lang.html">Multi-Language Support</a></li>
|
||
|
|
<li><a href="../../../guide/appweb/users/authentication.html">User Authorization</a></li>
|
||
|
|
<li><a href="../../../guide/appweb/users/logFiles.html">Log Files</a></li>
|
||
|
|
<li><a href="../../../guide/appweb/users/vhosts.html">Virtual Hosts</a></li>
|
||
|
|
<li><a href="../../../guide/appweb/users/security.html">Security Considerations</a></li>
|
||
|
|
<li><a href="../../../guide/appweb/users/ssl.html">SSL</a></li>
|
||
|
|
<li><a href="../../../guide/appweb/users/modules.html">Appweb Modules</a></li>
|
||
|
|
<li><a href="../../../guide/appweb/users/stages.html">Pipeline Stages</a></li>
|
||
|
|
<li><a href="../../../guide/appweb/users/client.html">HTTP Client</a></li>
|
||
|
|
<li><a href="../../../guide/appweb/users/webSockets.html">WebSockets</a></li>
|
||
|
|
<li><a href="../../../guide/appweb/users/frameworks.html">Web Frameworks</a></li>
|
||
|
|
<li><a href="../../../ref/appweb/architecture.html">Appweb Architecture</a></li>
|
||
|
|
</ul>
|
||
|
|
<!-- EndDsi -->
|
||
|
|
</div>
|
||
|
|
<div class="contentLeft">
|
||
|
|
<h1>Secure Socket Layer (SSL) Overview</h1>
|
||
|
|
<p>Appweb supports the Secure Sockets Layer (SSL) protocol for authenticating systems and encrypting data.
|
||
|
|
Use of this protocol enables secure data transmission to and from clients in a standards-based manner. The
|
||
|
|
Secure Sockets Layer protocol is a protocol layer which may be placed between a reliable
|
||
|
|
connection-oriented network layer protocol (e.g. TCP/IP) and the application protocol layer (e.g. HTTP).
|
||
|
|
SSL provides for secure communication between client and server by allowing mutual authentication, the use
|
||
|
|
of digital signatures for integrity, and encryption for privacy.</p>
|
||
|
|
<p>This following document explains SSL and how to configure SSL in Appweb. It has heavily borrowed from
|
||
|
|
the Apache Documentation. Many thanks to the fine folks at Apache for this excellent base material and for
|
||
|
|
Frederick Hirsch who authored quite a bit of the original material.</p>
|
||
|
|
<p>If you have a good understanding of SSL and now you want to configure SSL for Appweb, you may wish
|
||
|
|
to skip the background and read immediately how to setup
|
||
|
|
<a href="ssl.html">SSL for Appweb</a>.</p>
|
||
|
|
<a id="cryptographicTechniques"></a>
|
||
|
|
<h2 class="section">Cryptographic Techniques</h2>
|
||
|
|
<p>Understanding SSL requires an understanding of cryptographic algorithms, message digest functions (aka.
|
||
|
|
one-way or hash functions), and digital signatures. The following section provides a brief introduction to
|
||
|
|
the cryptographic foundations of SSL. If you are already familiar with this material, please skip forward
|
||
|
|
to the <a href="#sslOverview">SSL Overview</a> section.</p>
|
||
|
|
<h3>Cryptographic Algorithms</h3>
|
||
|
|
<p>Consider the example of Alice who wants to send a message to her bank to transfer some money. She would
|
||
|
|
like the message to be private, since it will include information such as her account number and transfer
|
||
|
|
amount. One solution is to use a cryptographic algorithm, a technique that would transform her message into
|
||
|
|
an encrypted form, unreadable except by those it is intended for. Once in this form, the message may only
|
||
|
|
be interpreted through the use of a secret key. Without the key, the message is useless: good cryptographic
|
||
|
|
algorithms make it so difficult for intruders to decode the original text that it isn't worth their
|
||
|
|
effort.</p>
|
||
|
|
<p>There are two categories of cryptographic algorithms: conventional and public key.</p>
|
||
|
|
<h4><a id="symmetricCryptography"></a>Symmetric Cryptography</h4>
|
||
|
|
<p>Symmetric cryptography, requires the sender and receiver to share a key: a secret piece of information
|
||
|
|
that may be used to encrypt or decrypt a message. If this key is secret, then nobody other than the sender
|
||
|
|
or receiver may read the message. If Alice and the bank know a secret key, then they may send each other
|
||
|
|
private messages. The task of privately choosing a key before communicating, however, can be
|
||
|
|
problematic.</p>
|
||
|
|
<h4><a id="publicKeyCryptography"></a>Public Key Cryptography</h4>
|
||
|
|
<p>Public key cryptography also known as asymmetric cryptography, solves the key exchange problem by
|
||
|
|
defining an algorithm which uses two keys, each of which may be used to encrypt a message. If one key is
|
||
|
|
used to encrypt a message then the other may be used to decrypt it. This makes it possible to receive
|
||
|
|
secure messages by simply publishing one key (the public key) and keeping the other secret (the private
|
||
|
|
key).</p>
|
||
|
|
<p>Anyone may encrypt a message using the public key, but only the owner of the private key will be able to
|
||
|
|
read it. In this way, you may send private messages to the owner of a key-pair (the bank), by encrypting it
|
||
|
|
using their public key. Only the bank will be able to decrypt it.</p>
|
||
|
|
<h3><a id="messageDigests"></a>Message Digests</h3>
|
||
|
|
<p>Although Alice may encrypt her message to make it private, there is still a concern that someone might
|
||
|
|
modify her original message or substitute it with a different one, in order to transfer the money to
|
||
|
|
themselves, for instance. One way of guaranteeing the integrity of Alice's message is to create a concise
|
||
|
|
summary of her message and send this to the bank as well. Upon receipt of the message, the bank creates its
|
||
|
|
own summary and compares it with the one Alice sent. If they agree then the message was received
|
||
|
|
intact.</p>
|
||
|
|
<p>A summary such as this is called a <b>message digest</b>, <em>one-way function</em> or <em>hash
|
||
|
|
function</em>. Message digests are used to create short, fixed-length representations of longer,
|
||
|
|
variable-length messages. Digest algorithms are designed to produce unique digests for different messages.
|
||
|
|
Message digests are designed to make it too difficult to determine the message from the digest, and also
|
||
|
|
impossible to find two different messages which create the same digest — thus eliminating the
|
||
|
|
possibility of substituting one message for another while maintaining the same digest.</p>
|
||
|
|
<p>Another challenge that Alice faces is finding a way to send the digest to the bank securely; when this
|
||
|
|
is achieved, the integrity of the associated message is assured. One way to do this is to include the
|
||
|
|
digest in a digital signature.</p>
|
||
|
|
<h3><a id="digitalSignatures"></a>Digital Signatures</h3>
|
||
|
|
<p>When Alice sends a message to the bank, the bank needs to ensure that the message is really from her, so
|
||
|
|
an intruder does not request a transaction involving her account. A <em>digital signature</em>, created by
|
||
|
|
Alice and included with the message, serves this purpose.</p>
|
||
|
|
<p>Digital signatures are created by encrypting a digest of the message, and other information (such as a
|
||
|
|
sequence number) with the sender's private key. Though anyone may <em>decrypt</em> the signature using the
|
||
|
|
public key, only the signer knows the private key. This means that only they may have signed it. Including
|
||
|
|
the digest in the signature means the signature is only good for that message; it also ensures the
|
||
|
|
integrity of the message since no one can change the digest and still sign it.</p>
|
||
|
|
<p>To guard against interception and reuse of the signature by an intruder at a later date, the signature
|
||
|
|
contains a unique sequence number. This protects the bank from a fraudulent claim from Alice that she did
|
||
|
|
not send the message — only she could have signed it (non-repudiation).</p><a id="certificates"></a>
|
||
|
|
<h2 class="section">Certificates</h2>
|
||
|
|
<p>Although Alice could have sent a private message to the bank, signed it, and ensured the integrity of
|
||
|
|
the message, she still needs to be sure that she is really communicating with the bank. This means that she
|
||
|
|
needs to be sure that the public key she is using corresponds to the bank's private key. Similarly, the
|
||
|
|
bank also needs to verify that the message signature really corresponds to Alice's signature.</p>
|
||
|
|
<p>If each party has a certificate which validates the other's identity, confirms the public key, and is
|
||
|
|
signed by a trusted agency, then they both will be assured that they are communicating with whom they think
|
||
|
|
they are. Such a trusted agency is called a <em>Certificate Authority</em>, and certificates are used for
|
||
|
|
authentication.</p>
|
||
|
|
<h3>Certificate Contents</h3>
|
||
|
|
<p>A certificate associates a public key with the real identity of an individual, server, or other entity,
|
||
|
|
known as the subject. As shown in <a href="#table1">Table 1</a>, information about the subject includes
|
||
|
|
identifying information (the distinguished name), and the public key. It also includes the identification
|
||
|
|
and signature of the Certificate Authority that issued the certificate, and the period of time during which
|
||
|
|
the certificate is valid. It may have additional information (or extensions) as well as administrative
|
||
|
|
information for the Certificate Authority's use, such as a serial number.</p>
|
||
|
|
<h4><a id="table1"></a>Table 1: Certificate Information</h4>
|
||
|
|
<table title="cert">
|
||
|
|
<tbody>
|
||
|
|
<tr>
|
||
|
|
<td class="pivot">Subject</td>
|
||
|
|
<td>Distinguished Name, Public Key</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td class="pivot">Issuer</td>
|
||
|
|
<td>Distinguished Name, Signature</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td class="pivot">Period of Validity</td>
|
||
|
|
<td>Not Before Date, Not After Date</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td class="pivot class">Administrative Information</td>
|
||
|
|
<td>Version, Serial Number</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td class="pivot">Extended Information</td>
|
||
|
|
<td>Basic Constraints, Netscape Flags, etc.</td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
<p>A distinguished name is used to provide an identity in a specific context — for instance, an
|
||
|
|
individual might have a personal certificate as well as one for their identity as an employee.
|
||
|
|
Distinguished names are defined by the X.509 standard, which defines the fields, field names, and
|
||
|
|
abbreviations used to refer to the fields (see <a href="#table2">Table 2</a>).</p>
|
||
|
|
<h4><a id="table2"></a>Table 2: Distinguished Name Information</h4>
|
||
|
|
<table title="info">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>DN Field</th>
|
||
|
|
<th>Abbrev.</th>
|
||
|
|
<th>Description</th>
|
||
|
|
<th>Example</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
<tbody>
|
||
|
|
<tr>
|
||
|
|
<td>Common Name</td>
|
||
|
|
<td>CN</td>
|
||
|
|
<td>Name being certified</td>
|
||
|
|
<td>CN=Joe Average</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td>Organization or Company</td>
|
||
|
|
<td>O</td>
|
||
|
|
<td>Name is associated with this organization</td>
|
||
|
|
<td>O=Snake Oil, Ltd.</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td>Organizational Unit</td>
|
||
|
|
<td>OU</td>
|
||
|
|
<td>Name is associated with this organization unit, such as a department</td>
|
||
|
|
<td>OU=Research Institute</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td>City/Locality</td>
|
||
|
|
<td>L</td>
|
||
|
|
<td>Name is located in this City</td>
|
||
|
|
<td>L=Snake City</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td>State/Province</td>
|
||
|
|
<td>ST</td>
|
||
|
|
<td>Name is located in this State/Province</td>
|
||
|
|
<td>ST=Desert</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td>Country</td>
|
||
|
|
<td>C</td>
|
||
|
|
<td>Name is located in this Country (ISO code)</td>
|
||
|
|
<td>C=XZ</td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
<p>A Certificate Authority may define a policy specifying which distinguished field names are optional, and
|
||
|
|
which are required. It may also place requirements upon the field contents, as may users of certificates.
|
||
|
|
As an example, a Netscape browser requires that the Common Name for a certificate representing a server has
|
||
|
|
a name which matches a wildcard pattern for the domain name of that server, such as
|
||
|
|
<code>*.snakeoil.com</code></p>
|
||
|
|
<p>The binary format of a certificate is defined using the ASN.1 notation. This notation defines how to
|
||
|
|
specify the contents, and encoding rules define how this information is translated into binary form. The
|
||
|
|
binary encoding of the certificate is defined using Distinguished Encoding Rules (DER), which are based on
|
||
|
|
the more general Basic Encoding Rules (BER). For those transmissions which cannot handle binary, the binary
|
||
|
|
form may be translated into an ASCII form by using Base64 encoding. This encoded version is called PEM
|
||
|
|
encoded (the name comes from "Privacy Enhanced Mail"), when placed between begin and end delimiter lines as
|
||
|
|
illustrated in the following example.</p>
|
||
|
|
<h3>Example of a PEM-encoded certificate (snakeoil.crt)</h3>
|
||
|
|
<pre>
|
||
|
|
-----BEGIN CERTIFICATE-----
|
||
|
|
MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
|
||
|
|
FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1PEBxMKU25ha2UgVG93bjEXMBUG
|
||
|
|
A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
|
||
|
|
cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
|
||
|
|
bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
|
||
|
|
MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIELlc2VydDETMBEGA1UEBxMKU25h
|
||
|
|
a2UgVG93bjEXMBAGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
|
||
|
|
cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
|
||
|
|
AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
|
||
|
|
gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
|
||
|
|
vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
|
||
|
|
lWoANFlAzlSdbxeEVHoT0K+gT5w3UxwZKv2DLbETzLZyPwIDAQABoyYwJDAPBgNV
|
||
|
|
HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
|
||
|
|
gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
|
||
|
|
2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
|
||
|
|
dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
|
||
|
|
-----END CERTIFICATE-----
|
||
|
|
</pre>
|
||
|
|
<h3><a id="certificateAuthorities"></a>Certificate Authorities</h3>
|
||
|
|
<p>By first verifying the information in a certificate request before granting the certificate, the
|
||
|
|
Certificate Authority assures the identity of the private key owner of a key-pair. For instance, if Alice
|
||
|
|
requests a personal certificate, the Certificate Authority must first make sure that Alice really is the
|
||
|
|
person the certificate request claims.</p>
|
||
|
|
<h4>Certificate Chains</h4>
|
||
|
|
<p>A Certificate Authority may also issue a certificate for another Certificate Authority. When examining a
|
||
|
|
certificate, Alice may need to examine the certificate of the issuer, for each parent Certificate
|
||
|
|
Authority, until reaching one which she has confidence in. She may decide to trust only certificates with a
|
||
|
|
limited chain of issuers, to reduce her risk of a "bad" certificate in the chain.</p>
|
||
|
|
<h4>Creating a Root-Level CA</h4>
|
||
|
|
<p>As noted earlier, each certificate requires an issuer to assert the validity of the identity of the
|
||
|
|
certificate subject, up to the top-level Certificate Authority (CA). This presents a problem: Since this is
|
||
|
|
who vouches for the certificate of the top-level authority, which has no issuer? In this unique case, the
|
||
|
|
certificate is "self-signed", so the issuer of the certificate is the same as the subject. As a result, one
|
||
|
|
must exercise extra care in trusting a self-signed certificate. The wide publication of a public key by the
|
||
|
|
root authority reduces the risk in trusting this key — it would be obvious if someone else publicized
|
||
|
|
a key claiming to be the authority. Browsers are preconfigured to trust well-known certificate
|
||
|
|
authorities.</p>
|
||
|
|
<p>A number of companies, such as <a href="http://www.thawte.com/">Thawte</a> and <a href=
|
||
|
|
"http://www.verisign.com/">VeriSign</a> have established themselves as Certificate Authorities. These
|
||
|
|
companies provide the following services:</p>
|
||
|
|
<ul>
|
||
|
|
<li>Verifying certificate requests</li>
|
||
|
|
<li>Processing certificate requests</li>
|
||
|
|
<li>Issuing and managing certificates</li>
|
||
|
|
</ul>
|
||
|
|
<p>It is also possible to create your own Certificate Authority. Although risky in the Internet
|
||
|
|
environment, it may be useful within an Intranet where the organization can easily verify the identities of
|
||
|
|
individuals and servers.</p>
|
||
|
|
<h4>Certificate Management</h4>
|
||
|
|
<p>Establishing a Certificate Authority is a responsibility which requires a solid administrative,
|
||
|
|
technical, and management framework. Certificate Authorities not only issue certificates, they also manage
|
||
|
|
them — that is, they determine how long certificates are valid, they renew them, and they keep lists
|
||
|
|
of certificates that have already been issued but are no longer valid (Certificate Revocation Lists, or
|
||
|
|
CRLs). Say Alice is entitled to a certificate as an employee of a company. Say too, that the certificate
|
||
|
|
needs to be revoked when Alice leaves the company. Since certificates are objects that get passed around,
|
||
|
|
it is impossible to tell from the certificate alone that it has been revoked. When examining certificates
|
||
|
|
for validity, therefore, it is necessary to contact the issuing Certificate Authority to check CRLs —
|
||
|
|
this is not usually an automated part of the process.</p>
|
||
|
|
<h3>Note</h3>
|
||
|
|
<p>If you use a Certificate Authority that is not configured into browsers by default, it is necessary to
|
||
|
|
load the Certificate Authority certificate into the browser, enabling the browser to validate server
|
||
|
|
certificates signed by that Certificate Authority. Doing so may be dangerous, since once loaded, the
|
||
|
|
browser will accept all certificates signed by that Certificate Authority.</p>
|
||
|
|
</div><a id="sslOverview"></a>
|
||
|
|
<h2 class="section">Secure Sockets Layer (SSL) Overview</h2>
|
||
|
|
<p>The Secure Sockets Layer protocols designed to support a range of choices for specific algorithms used for
|
||
|
|
cryptography, digests, and signatures. This allows algorithm selection for specific servers to be made based on
|
||
|
|
legal, export or other concerns, and also enables the protocol to take advantage of new algorithms. Choices are
|
||
|
|
negotiated between client and server at the start of establishing a protocol session.</p>
|
||
|
|
<h3>Table 4: Versions of the SSL protocol</h3>
|
||
|
|
<a id="table4"></a>
|
||
|
|
<table title="protocols">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>Version</th>
|
||
|
|
<th>Source</th>
|
||
|
|
<th>Description</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
<tbody>
|
||
|
|
<tr>
|
||
|
|
<td>SSL v2.0</td>
|
||
|
|
<td>Vendor Standard (from Netscape Corp.)</td>
|
||
|
|
<td>First SSL protocol for which implementations exists</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td>SSL v3.0</td>
|
||
|
|
<td>Expired Internet Draft (from Netscape Corp.)</td>
|
||
|
|
<td>Revisions to prevent specific security attacks, add non-RSA ciphers, and support for
|
||
|
|
certificate chains</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td>TLS v1.0</td>
|
||
|
|
<td>Internet Standard (from IETF)</td>
|
||
|
|
<td>TLSv1.0 is a revision of SSL 3.0 to update the MAC layer to HMAC, add block padding for
|
||
|
|
block ciphers, message order standardization and more alert messages.</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td>TLS v1.1</td>
|
||
|
|
<td>Internet Standard (from IETF)</td>
|
||
|
|
<td>TLSv1.1 adds protection against Cipher block chaining attacks.</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td>TLS v1.2</td>
|
||
|
|
<td>Internet Standard (from IETF)</td>
|
||
|
|
<td>TLSv1.2 deprecates using MD5 as a hash and deprecates SSLv2.</td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
<p>There are a number of versions of the SSL protocol, as shown in <a href="#table4">Table 4</a>. As noted
|
||
|
|
there, one of the benefits in SSL 3.0 is that it adds support of certificate chain loading. This feature allows
|
||
|
|
a server to pass a server certificate along with issuer certificates to the browser. Chain loading also permits
|
||
|
|
the browser to validate the server certificate, even if Certificate Authority certificates are not installed
|
||
|
|
for the intermediate issuers, since they are included in the certificate chain. SSL 3.0 is the basis for the
|
||
|
|
Transport Layer Security protocol standard, currently in development by the Internet Engineering Task Force
|
||
|
|
(IETF).</p>
|
||
|
|
<h3>Session Establishment</h3>
|
||
|
|
<p>The SSL session is established by following a handshake sequence between client and server. This sequence
|
||
|
|
may vary, depending on whether the server is configured to provide a server certificate or request a client
|
||
|
|
certificate. Though cases exist where additional handshake steps are required for management of cipher
|
||
|
|
information, this article summarizes one common scenario: see the SSL specification for the full range of
|
||
|
|
possibilities.</p>
|
||
|
|
<h3>Note</h3>
|
||
|
|
<p>Once an SSL session has been established it may be reused, thus avoiding the performance penalty of
|
||
|
|
repeating the many steps needed to start a session. For this the server assigns each SSL session a unique
|
||
|
|
session identifier which is cached in the server and which the client can use on forthcoming connections to
|
||
|
|
reduce the handshake (until the session identifier expires in the cache of the server).</p>
|
||
|
|
<p class="figure">The elements of the handshake sequence, as used by the client and server, are listed
|
||
|
|
below:</p>
|
||
|
|
<ol>
|
||
|
|
<li>Negotiate the Cipher Suite to be used during data transfer</li>
|
||
|
|
<li>Establish and share a session key between client and server</li>
|
||
|
|
<li>Optionally authenticate the server to the client</li>
|
||
|
|
<li>Optionally authenticate the client to the server</li>
|
||
|
|
</ol>
|
||
|
|
<p>The first step, Cipher Suite Negotiation, allows the client and server to choose a Cipher Suite supportable
|
||
|
|
by both of them. The SSL3.0 protocol specification defines 31 Cipher Suites. A Cipher Suite is defined by the
|
||
|
|
following components:</p>
|
||
|
|
<ul>
|
||
|
|
<li>Key Exchange Method</li>
|
||
|
|
<li>Cipher for Data Transfer</li>
|
||
|
|
<li>Message Digest for creating the Message Authentication Code (MAC)</li>
|
||
|
|
</ul>
|
||
|
|
<p>These three elements are described in the sections that follow.</p>
|
||
|
|
<h3>Key Exchange Method</h3>
|
||
|
|
<p>The key exchange method defines how the shared secret symmetric cryptography key used for application data
|
||
|
|
transfer will be agreed upon by client and server. SSL 2.0 uses RSA key exchange only, while SSL 3.0 supports a
|
||
|
|
choice of key exchange algorithms including the RSA key exchange when certificates are used, and Diffie-Hellman
|
||
|
|
key exchange for exchanging keys without certificates and without prior communication between client and
|
||
|
|
server.</p>
|
||
|
|
<p>One variable in the choice of key exchange methods is digital signatures — whether or not to use them,
|
||
|
|
and if so, what kind of signatures to use. Signing with a private key provides assurance against a
|
||
|
|
man-in-the-middle-attack during the information exchange used in generating the shared key.</p>
|
||
|
|
<h3>Cipher for Data Transfer</h3>
|
||
|
|
<p>SSL uses the conventional cryptography algorithm (symmetric cryptography) described earlier for encrypting
|
||
|
|
messages in a session. There are nine choices, including the choice to perform no encryption:</p>
|
||
|
|
<ul>
|
||
|
|
<li>No encryption</li>
|
||
|
|
<li>Stream Ciphers
|
||
|
|
<ul>
|
||
|
|
<li>RC4 with 40-bit keys</li>
|
||
|
|
<li>RC4 with 128-bit keys</li>
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
<li>CBC Block Ciphers
|
||
|
|
<ul>
|
||
|
|
<li>RC2 with 40 bit key</li>
|
||
|
|
<li>DES with 40 bit key</li>
|
||
|
|
<li>DES with 56 bit key</li>
|
||
|
|
<li>Triple-DES with 168 bit key</li>
|
||
|
|
<li>Idea (128 bit key)</li>
|
||
|
|
<li>Fortezza (96 bit key)</li>
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
<p>Here "CBC" refers to Cipher Block Chaining, which means that a portion of the previously encrypted cipher
|
||
|
|
text is used in the encryption of the current block. "DES" refers to the Data Encryption Standard, which has a
|
||
|
|
number of variants (including DES40 and 3DES_EDE). "Idea" is one of the best and cryptographically strongest
|
||
|
|
available algorithms, and "RC2" is a proprietary algorithm from RSA DSI.</p>
|
||
|
|
<h3>Digest Function</h3>
|
||
|
|
<p>The choice of digest function determines how a digest is created from a record unit. SSL supports the
|
||
|
|
following:</p>
|
||
|
|
<ul>
|
||
|
|
<li>No digest (Null choice)</li>
|
||
|
|
<li>MD5, a 128-bit hash (deprecated in TLS/1.2)</li>
|
||
|
|
<li>Secure Hash Algorithm (SHA-1), a 160-bit hash</li>
|
||
|
|
</ul>
|
||
|
|
<p>The message digest is used to create a Message Authentication Code (MAC) which is encrypted with the message
|
||
|
|
to provide integrity and to prevent against replay attacks.</p>
|
||
|
|
<h3>Handshake Sequence Protocol</h3>
|
||
|
|
<p>The handshake sequence uses three protocols:</p>
|
||
|
|
<ul>
|
||
|
|
<li>The <dfn>SSL Handshake Protocol</dfn> for performing the client and server SSL session
|
||
|
|
establishment.</li>
|
||
|
|
<li>The <dfn>SSL Change Cipher Spec Protocol</dfn> for actually establishing agreement on the Cipher Suite
|
||
|
|
for the session.</li>
|
||
|
|
<li>The <dfn>SSL Alert Protocol</dfn> for conveying SSL error messages between client and server.</li>
|
||
|
|
</ul>
|
||
|
|
<p>These protocols, as well as application protocol data, are encapsulated in the <dfn>SSL Record
|
||
|
|
Protocol</dfn>. An encapsulated protocol is transferred as data by the lower layer protocol, which does not
|
||
|
|
examine the data. The encapsulated protocol has no knowledge of the underlying protocol.</p>
|
||
|
|
<p>The encapsulation of SSL control protocols by the record protocol means that if an active session is
|
||
|
|
renegotiated the control protocols will be transmitted securely. If there were no session before, then the Null
|
||
|
|
cipher suite is used, which means there is no encryption and messages have no integrity digests until the
|
||
|
|
session has been established.</p>
|
||
|
|
<h3>Data Transfer</h3>
|
||
|
|
<p>The SSL Record Protocol is used to transfer application and SSL Control data between the client and server,
|
||
|
|
possibly fragmenting this data into smaller units, or combining multiple higher level protocol data messages
|
||
|
|
into single units. It may compress, attach digest signatures, and encrypt these units before transmitting them
|
||
|
|
using the underlying reliable transport protocol (Note: currently all major SSL implementations lack support
|
||
|
|
for compression).</p>
|
||
|
|
<h3 class="figure">Securing HTTP Communication</h3>
|
||
|
|
<p>One common use of SSL is to secure Web HTTP communication between a browser and a web server. This case does
|
||
|
|
not preclude the use of non-secured HTTP. The secure version is mainly plain HTTP over SSL (named HTTPS), but
|
||
|
|
with one major difference: it uses the URL scheme <code>https</code> rather than <code>http</code> and a
|
||
|
|
different server port (by default 443). Appweb as installed will use port 4443 which may be changed by editing
|
||
|
|
the appweb.conf configuration file.</p>
|
||
|
|
</div>
|
||
|
|
<!-- BeginDsi "dsi/bottom.html" -->
|
||
|
|
<div class="bottom">
|
||
|
|
<p class="footnote">
|
||
|
|
<a href="../../../product/copyright.html" >© Embedthis Software LLC, 2003-2013.
|
||
|
|
All rights reserved. Embedthis, Appweb, ESP, Ejscript and Embedthis GoAhead are trademarks of Embedthis Software LLC.</a>
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
<script src="http://www.google.com/jsapi" type="text/javascript"></script>
|
||
|
|
<script type="text/javascript">
|
||
|
|
google.load('search', '1', {language : 'en'});
|
||
|
|
google.setOnLoadCallback(function() {
|
||
|
|
var customSearchControl = new google.search.CustomSearchControl(
|
||
|
|
'000262706376373952077:1hs0lhenihk');
|
||
|
|
customSearchControl.setResultSetSize(google.search.Search.FILTERED_CSE_RESULTSET);
|
||
|
|
var options = new google.search.DrawOptions();
|
||
|
|
options.enableSearchboxOnly("http://appwebserver.org/search.html");
|
||
|
|
customSearchControl.draw('cse-search-form', options);
|
||
|
|
}, true);
|
||
|
|
</script>
|
||
|
|
<script type="text/javascript">
|
||
|
|
var _gaq = _gaq || [];
|
||
|
|
_gaq.push(['_setAccount', 'UA-179169-2']);
|
||
|
|
_gaq.push(['_trackPageview']);
|
||
|
|
(function() {
|
||
|
|
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
|
||
|
|
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
|
||
|
|
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
|
||
|
|
})();
|
||
|
|
</script>
|
||
|
|
</body>
|
||
|
|
</html>
|