mirror of
https://github.com/apache/httpd.git
synced 2025-11-03 17:53:20 +03:00
c1787db624
- Remove some <br>s where they really shouldn't be - Reorder the sitemap slightly (indexes at the end) git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@100244 13f79535-47bb-0310-9956-ffa450edef68
651 lines
30 KiB
XML
651 lines
30 KiB
XML
<?xml version='1.0' encoding='UTF-8' ?>
|
|
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
|
|
<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
|
|
<manualpage metafile="ssl_intro.xml.meta">
|
|
<parentdocument href="./">SSL/TLS</parentdocument>
|
|
|
|
<title>SSL/TLS Strong Encryption: An Introduction</title>
|
|
|
|
<summary>
|
|
<blockquote>
|
|
<p>The nice thing about standards is that there are so many to choose
|
|
from. And if you really don't like all the standards you just have to
|
|
wait another year until the one arises you are looking for.</p>
|
|
|
|
<p class="cite">-- <cite>A. Tanenbaum</cite>, "Introduction to
|
|
Computer Networks"</p>
|
|
</blockquote>
|
|
|
|
<p>As an introduction this chapter is aimed at readers who are familiar
|
|
with the Web, HTTP, and Apache, but are not security experts. It is not
|
|
intended to be a definitive guide to the SSL protocol, nor does it discuss
|
|
specific techniques for managing certificates in an organization, or the
|
|
important legal issues of patents and import and export restrictions.
|
|
Rather, it is intended to provide a common background to mod_ssl users by
|
|
pulling together various concepts, definitions, and examples as a starting
|
|
point for further exploration.</p>
|
|
|
|
<p>The presented content is mainly derived, with permission by the author,
|
|
from the article <a
|
|
href="http://home.earthlink.net/~fjhirsch/Papers/wwwj/article.html">Introducing
|
|
SSL and Certificates using SSLeay</a> from <a
|
|
href="http://home.earthlink.net/~fjhirsch/">Frederick J. Hirsch</a>, of The
|
|
Open Group Research Institute, which was published in <a
|
|
href="http://www.ora.com/catalog/wjsum97/">Web Security: A Matter of
|
|
Trust</a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997.
|
|
Please send any positive feedback to <a
|
|
href="mailto:hirsch@fjhirsch.com">Frederick Hirsch</a> (the original
|
|
article author) and all negative feedback to <a
|
|
href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> (the
|
|
<module>mod_ssl</module> author).</p>
|
|
</summary>
|
|
|
|
<section id="cryptographictech">
|
|
<title>Cryptographic Techniques</title>
|
|
<p>Understanding SSL requires an understanding of cryptographic
|
|
algorithms, message digest functions (aka. one-way or hash functions), and
|
|
digital signatures. These techniques are the subject of entire books (see
|
|
for instance [<a href="#AC96">AC96</a>]) and provide the basis for privacy,
|
|
integrity, and authentication.</p>
|
|
|
|
<section id="cryptographicalgo">
|
|
<title>Cryptographic Algorithms</title>
|
|
<p>Suppose Alice wants to send a message to her bank to transfer some
|
|
money. Alice 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>
|
|
|
|
<dl>
|
|
<dt>Conventional cryptography</dt>
|
|
<dd>also known as 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.</dd>
|
|
|
|
<dt>Public key cryptography</dt>
|
|
<dd>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 must 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).</dd>
|
|
</dl>
|
|
|
|
<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, Alice
|
|
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>
|
|
</section>
|
|
|
|
<section id="messagedigests">
|
|
<title>Message Digests</title>
|
|
<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 <dfn>message digest</dfn>, <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>
|
|
</section>
|
|
|
|
<section id="digitalsignatures"><title>Digital Signatures</title>
|
|
<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>
|
|
</section>
|
|
</section>
|
|
<!-- /cryptographictech -->
|
|
|
|
<section id="certificates">
|
|
<title>Certificates</title>
|
|
<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>
|
|
|
|
<section id="certificatecontents">
|
|
<title>Certificate Contents</title>
|
|
<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>
|
|
|
|
<section id="table1">
|
|
<title>Table 1: Certificate Information</title>
|
|
<table>
|
|
<columnspec><column width=".35"/><column width=".35"/>
|
|
</columnspec>
|
|
<tr><th>Subject</th>
|
|
<td>Distinguished Name, Public Key</td></tr>
|
|
<tr><th>Issuer</th>
|
|
<td>Distinguished Name, Signature</td></tr>
|
|
<tr><th>Period of Validity</th>
|
|
<td>Not Before Date, Not After Date</td></tr>
|
|
<tr><th>Administrative Information</th>
|
|
<td>Version, Serial Number</td></tr>
|
|
<tr><th>Extended Information</th>
|
|
<td>Basic Constraints, Netscape Flags, etc.</td></tr>
|
|
</table>
|
|
</section>
|
|
|
|
<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 [<a
|
|
href="#X509">X509</a>], which defines the fields, field names, and
|
|
abbreviations used to refer to the fields (see <a href="#table2">Table
|
|
2</a>).</p>
|
|
|
|
<section id="table2">
|
|
<title>Table 2: Distinguished Name Information</title>
|
|
<table border="1">
|
|
<columnspec><column width=".25"/><column width=".15"/>
|
|
<column width=".3"/><column width=".25"/></columnspec>
|
|
<tr><th>DN Field</th>
|
|
<th>Abbrev.</th>
|
|
<th>Description</th>
|
|
<th>Example</th></tr>
|
|
<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<br />organization</td>
|
|
<td>O=Snake Oil, Ltd.</td></tr>
|
|
<tr><td>Organizational Unit</td>
|
|
<td>OU</td>
|
|
<td>Name is associated with this <br />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>
|
|
</table>
|
|
</section>
|
|
|
|
<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 [<a href="#X208">X208</a>] [<a href="#PKCS">PKCS</a>]. 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
|
|
[<a href="#MIME">MIME</a>]. 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>
|
|
|
|
<example>
|
|
<title>Example of a PEM-encoded certificate (snakeoil.crt)</title>
|
|
<pre>-----BEGIN CERTIFICATE-----
|
|
MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
|
|
FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
|
|
A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
|
|
cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
|
|
bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
|
|
MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
|
|
a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
|
|
cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
|
|
AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
|
|
gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
|
|
vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
|
|
lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
|
|
HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
|
|
gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
|
|
2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
|
|
dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
|
|
-----END CERTIFICATE-----</pre>
|
|
</example>
|
|
</section>
|
|
|
|
<section id="certificateauthorities">
|
|
<title>Certificate Authorities</title>
|
|
<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>
|
|
|
|
<section id="certificatechains">
|
|
<title>Certificate Chains</title>
|
|
<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>
|
|
</section>
|
|
|
|
<section id="rootlevelca">
|
|
<title>Creating a Root-Level CA</title>
|
|
<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>
|
|
</section>
|
|
|
|
<section id="certificatemanagement">
|
|
<title>Certificate Management</title>
|
|
<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>
|
|
|
|
<note><title>Note</title>
|
|
<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>
|
|
</note>
|
|
</section>
|
|
</section>
|
|
<!-- /certificateauthorities -->
|
|
</section>
|
|
<!-- /certificates -->
|
|
|
|
<section id="ssl">
|
|
<title>Secure Sockets Layer (SSL)</title>
|
|
<p>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>The protocol is 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>
|
|
|
|
<section id="table4">
|
|
<title>Table 4: Versions of the SSL protocol</title>
|
|
<table border="1">
|
|
<columnspec><column width=".15"/><column width=".2"/>
|
|
<column width=".30"/><column width=".25"/></columnspec>
|
|
<tr><th>Version</th>
|
|
<th>Source</th>
|
|
<th>Description</th>
|
|
<th>Browser Support</th></tr>
|
|
<tr><td>SSL v2.0</td>
|
|
<td>Vendor Standard (from Netscape Corp.) [<a href="#SSL2"
|
|
>SSL2</a>]</td>
|
|
<td>First SSL protocol for which implementations exists</td>
|
|
<td>- NS Navigator 1.x/2.x<br />
|
|
- MS IE 3.x<br />
|
|
- Lynx/2.8+OpenSSL</td></tr>
|
|
<tr><td>SSL v3.0</td>
|
|
<td>Expired Internet Draft (from Netscape Corp.) [<a href="#SSL3"
|
|
>SSL3</a>]</td>
|
|
<td>Revisions to prevent specific security attacks, add non-RSA
|
|
ciphers, and support for certificate chains</td>
|
|
<td>- NS Navigator 2.x/3.x/4.x<br />
|
|
- MS IE 3.x/4.x<br />
|
|
- Lynx/2.8+OpenSSL</td></tr>
|
|
<tr><td>TLS v1.0</td>
|
|
<td>Proposed Internet Standard (from IETF) [<a href="#TLS1"
|
|
>TLS1</a>]</td>
|
|
<td>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>
|
|
<td>- Lynx/2.8+OpenSSL</td></tr>
|
|
</table>
|
|
</section>
|
|
|
|
<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
|
|
[<a href="#TLS1">TLS</a>] protocol standard, currently in development by
|
|
the Internet Engineering Task Force (IETF).</p>
|
|
|
|
<section id="session">
|
|
<title>Session Establishment</title>
|
|
<p>The SSL session is established by following a handshake sequence
|
|
between client and server, as shown in <a href="#figure1"
|
|
>Figure 1</a>. 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>
|
|
|
|
<note><title>Note</title>
|
|
<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 identifer expires in the cache of the server).</p>
|
|
</note>
|
|
|
|
<p class="figure">
|
|
<img src="ssl_intro_fig1.gif" alt="" width="423" height="327" /><br />
|
|
<a id="figure1" name="figure1"><dfn>Figure 1</dfn></a>: Simplified SSL
|
|
Handshake Sequence</p>
|
|
|
|
<p>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>
|
|
</section>
|
|
|
|
<section id="keyexchange">
|
|
<title>Key Exchange Method</title>
|
|
<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 [<a href="#AC96">AC96</a>, p516].</p>
|
|
</section>
|
|
|
|
<section id="ciphertransfer">
|
|
<title>Cipher for Data Transfer</title>
|
|
<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 [<a href="#AC96">AC96</a>, ch12], 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 [<a href="#AC96">AC96</a>,
|
|
ch13].</p>
|
|
</section>
|
|
|
|
<section id="digestfuntion">
|
|
<title>Digest Function</title>
|
|
<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</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>
|
|
</section>
|
|
|
|
<section id="handshake">
|
|
<title>Handshake Sequence Protocol</title>
|
|
<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>, as shown in
|
|
<a href="#figure2">Figure 2</a>. 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 class="figure">
|
|
<img src="ssl_intro_fig2.gif" alt="" width="428" height="217" /><br />
|
|
<a id="figure2" name="figure2"><dfn>Figure 2</dfn></a>: SSL Protocol Stack
|
|
</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>
|
|
</section>
|
|
|
|
<section id="datatransfer">
|
|
<title>Data Transfer</title>
|
|
<p>The SSL Record Protocol, shown in <a href="#figure3">Figure 3</a>,
|
|
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>
|
|
|
|
<p class="figure">
|
|
<img src="ssl_intro_fig3.gif" alt="" width="423" height="323" /><br />
|
|
<a id="figure3" name="figure3"><dfn>Figure 3</dfn></a>: SSL Record Protocol
|
|
</p>
|
|
</section>
|
|
|
|
<section id="securehttp">
|
|
<title>Securing HTTP Communication</title>
|
|
<p>One common use of SSL is to secure Web HTTP communication between
|
|
a browser and a webserver. 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). This mainly is what <module
|
|
>mod_ssl</module> provides to you for the Apache webserver...</p>
|
|
</section>
|
|
</section>
|
|
<!-- /ssl -->
|
|
|
|
<section id="references">
|
|
<title>References</title>
|
|
<dl>
|
|
<dt><a id="AC96" name="AC96">[AC96]</a></dt>
|
|
<dd>Bruce Schneier, <q>Applied Cryptography</q>, 2nd Edition, Wiley,
|
|
1996. See <a href="http://www.counterpane.com/"
|
|
>http://www.counterpane.com/</a> for various other materials by Bruce
|
|
Schneier.</dd>
|
|
|
|
<dt><a id="X208" name="X208">[X208]</a></dt>
|
|
<dd>ITU-T Recommendation X.208, <q>Specification of Abstract Syntax Notation
|
|
One (ASN.1)</q>, 1988. See for instance <a
|
|
href="http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I"
|
|
>http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I</a>.
|
|
</dd>
|
|
|
|
<dt><a id="X509" name="X509">[X509]</a></dt>
|
|
<dd>ITU-T Recommendation X.509, <q>The Directory - Authentication
|
|
Framework</q>. See for instance <a
|
|
href="http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509"
|
|
>http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509</a>.
|
|
</dd>
|
|
|
|
<dt><a id="PKCS" name="PKCS">[PKCS]</a></dt>
|
|
<dd><q>Public Key Cryptography Standards (PKCS)</q>,
|
|
RSA Laboratories Technical Notes, See <a
|
|
href="http://www.rsasecurity.com/rsalabs/pkcs/"
|
|
>http://www.rsasecurity.com/rsalabs/pkcs/</a>.</dd>
|
|
|
|
<dt><a id="MIME" name="MIME">[MIME]</a></dt>
|
|
<dd>N. Freed, N. Borenstein, <q>Multipurpose Internet Mail Extensions
|
|
(MIME) Part One: Format of Internet Message Bodies</q>, RFC2045.
|
|
See for instance <a href="http://ietf.org/rfc/rfc2045.txt"
|
|
>http://ietf.org/rfc/rfc2045.txt</a>.</dd>
|
|
|
|
<dt><a id="SSL2" name="SSL2">[SSL2]</a></dt>
|
|
<dd>Kipp E.B. Hickman, <q>The SSL Protocol</q>, 1995. See <a
|
|
href="http://www.netscape.com/eng/security/SSL_2.html"
|
|
>http://www.netscape.com/eng/security/SSL_2.html</a>.</dd>
|
|
|
|
<dt><a id="SSL3" name="SSL3">[SSL3]</a></dt>
|
|
<dd>Alan O. Freier, Philip Karlton, Paul C. Kocher, <q>The SSL Protocol
|
|
Version 3.0</q>, 1996. See <a
|
|
href="http://www.netscape.com/eng/ssl3/draft302.txt"
|
|
>http://www.netscape.com/eng/ssl3/draft302.txt</a>.</dd>
|
|
|
|
<dt><a id="TLS1" name="TLS1">[TLS1]</a></dt>
|
|
<dd>Tim Dierks, Christopher Allen, <q>The TLS Protocol Version 1.0</q>,
|
|
1999. See <a href="http://ietf.org/rfc/rfc2246.txt"
|
|
>http://ietf.org/rfc/rfc2246.txt</a>.</dd>
|
|
</dl>
|
|
</section>
|
|
<!-- /references -->
|
|
|
|
</manualpage>
|