2086N/A<
title>mod_ssl: Introduction</
title>
2086N/A Copyright (c) 1998-2001 Ralf S. Engelschall. All rights reserved. 2086N/A Redistribution and use in source and binary forms, with or without 2086N/A modification, are permitted provided that the following conditions 2086N/A 1. Redistributions of source code must retain the above 2086N/A copyright notice, this list of conditions and the following 2086N/A 2. Redistributions in binary form must reproduce the above 2086N/A copyright notice, this list of conditions and the following 2086N/A disclaimer in the documentation and/or other materials 2086N/A provided with the distribution. 2086N/A 3. All advertising materials mentioning features or use of this 2086N/A software must display the following acknowledgment: 2086N/A "This product includes software developed by 2086N/A Ralf S. Engelschall <rse@engelschall.com> for use in the 2086N/A 4. The name "mod_ssl" must not be used to endorse or promote 2086N/A products derived from this software without prior written 2086N/A 5. Redistributions of any form whatsoever must retain the 2202N/A "This product includes software developed by 2086N/A Ralf S. Engelschall <rse@engelschall.com> for use in the 2086N/A THIS SOFTWARE IS PROVIDED BY RALF S. ENGELSCHALL ``AS IS'' AND ANY 2086N/A EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 2086N/A IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 2086N/A PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL RALF S. ENGELSCHALL OR 2086N/A HIS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 2086N/A SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 2086N/A NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 2086N/A LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 2086N/A HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, 2086N/A STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 2086N/A ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED 2086N/A OF THE POSSIBILITY OF SUCH DAMAGE. 2086N/A font-family: arial,helvetica; 2086N/A font-family: arial,helvetica; 2086N/A font-family: arial,helvetica; 2202N/A font-family: arial,helvetica; 2086N/A font-family: arial,helvetica; 2086N/A font-family: arial,helvetica; 2202N/A font-family: arial,helvetica; 2086N/A font-family: arial,helvetica; 2086N/Afunction ro_imgNormal(imgName) { 2127N/Afunction ro_imgOver(imgName, descript) { 2127N/A ro_img_prev_top_n = new Image(); 2086N/A ro_img_prev_top_o = new Image(); 2086N/A ro_img_prev_bot_n = new Image(); 2086N/A ro_img_prev_bot_o = new Image(); 2202N/A ro_img_next_top_n = new Image(); 2202N/A ro_img_next_top_o = new Image(); 2086N/A ro_img_next_bot_n = new Image(); 2086N/A ro_img_next_bot_o = new Image(); 2086N/A<
body bgcolor="#ffffff" text="#000000" link="#333399" alink="#9999ff" vlink="#000066">
2086N/A<
table width="600" cellspacing="0" cellpadding="0" border="0" summary="">
2086N/A <
table width="600" cellspacing="0" cellpadding="0" summary="">
2086N/A <
table width="600" summary="">
2086N/A <
td align="left" valign="bottom">
2086N/A <
font face="Arial,Helvetica" size="+2"><
b>mod_ssl</
b></
font>
2086N/A <
table width="600" border="0" summary="">
2086N/A <
td valign="top" align="left" width="250">
2086N/A<
a href="ssl_overview.html" onmouseover="ro_imgOver('ro_img_prev_top', 'previous page'); return true" onmouseout="ro_imgNormal('ro_img_prev_top'); return true" onfocus="ro_imgOver('ro_img_prev_top', 'previous page'); return true" onblur="ro_imgNormal('ro_img_prev_top'); return true"><
img name="ro_img_prev_top" src="ssl_template.navbut-prev-n.gif" alt="previous page" width="70" height="18" border="0"></
a><
br><
font color="#000000">Overview</
font>
2086N/A <
td valign="top" align="right" width="250">
2086N/A<
a href="ssl_reference.html" onmouseover="ro_imgOver('ro_img_next_top', 'next page'); return true" onmouseout="ro_imgNormal('ro_img_next_top'); return true" onfocus="ro_imgOver('ro_img_next_top', 'next page'); return true" onblur="ro_imgNormal('ro_img_next_top'); return true"><
img name="ro_img_next_top" src="ssl_template.navbut-next-n.gif" alt="next page" width="70" height="18" border="0"></
a><
br><
font color="#000000">Reference</
font>
2086N/A<
table cellspacing="0" cellpadding="0" width="400" summary="">
2086N/A``The nice thing about standards is that there are so many to choose from.
2086N/AAnd if you really don't like all the standards you just have to wait another
2086N/Ayear until the one arises you are looking for.''
2127N/AA. Tanenbaum, ``Introduction to Computer Networks''
2086N/A<
table cellspacing="0" cellpadding="0" border="0" summary="">
2086N/As an introduction this chapter is aimed at readers who are familiar
2086N/Awith the Web, HTTP, and Apache, but are not security experts. It is not
2127N/Aintended to be a definitive guide to the SSL protocol, nor does it discuss
2127N/Aspecific techniques for managing certificates in an organization, or the
2086N/Aimportant legal issues of patents and import and export restrictions. Rather,
2086N/Ait is intended to provide a common background to mod_ssl users by pulling
2086N/Atogether various concepts, definitions, and examples as a starting point for
2086N/AThe presented content is mainly derived, with permission by the author, from
2086N/Aand Certificates using SSLeay</
em></
a> from <
a 2086N/AGroup Research Institute, which was published in <
a 2086N/ATrust</
em></
a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997.
2086N/APlease send any postive feedback to <
a 2086N/Ahref="mailto:fjh@alum.mit.edu">Frederick Hirsch</
a> (the original
2202N/Aarticle author) and all negative feedback to <
a 2202N/Ahref="mailto:rse@engelschall.com">Ralf S. Engelschall</
a> (the mod_ssl
2086N/A<
table cellspacing="0" cellpadding="5" border="0" bgcolor="#ccccff" summary="">
2086N/A<
font face="Arial,Helvetica" color="#ccccff">
2086N/A<
font face="Arial,Helvetica" size="-1">
2086N/A <
a href="#ToC1"><
strong>Cryptographic Techniques</
strong></
a><
br>
2127N/A <
a href="#ToC2"><
strong>Cryptographic Algorithms</
strong></
a><
br>
2086N/A <
a href="#ToC3"><
strong>Message Digests</
strong></
a><
br>
2086N/A <
a href="#ToC4"><
strong>Digital Signatures</
strong></
a><
br>
2127N/A <
a href="#ToC5"><
strong>Certificates</
strong></
a><
br>
2127N/A <
a href="#ToC6"><
strong>Certificate Contents</
strong></
a><
br>
2086N/A <
a href="#ToC7"><
strong>Certificate Authorities</
strong></
a><
br>
2086N/A <
a href="#ToC8"><
strong>Certificate Chains</
strong></
a><
br>
2086N/A <
a href="#ToC9"><
strong>Creating a Root-Level CA</
strong></
a><
br>
2086N/A <
a href="#ToC10"><
strong>Certificate Management</
strong></
a><
br>
2086N/A <
a href="#ToC11"><
strong>Secure Sockets Layer (SSL)</
strong></
a><
br>
2086N/A <
a href="#ToC12"><
strong>Session Establishment</
strong></
a><
br>
2086N/A <
a href="#ToC13"><
strong>Key Exchange Method</
strong></
a><
br>
2086N/A <
a href="#ToC14"><
strong>Cipher for Data Transfer</
strong></
a><
br>
2086N/A <
a href="#ToC15"><
strong>Digest Function</
strong></
a><
br>
2127N/A <
a href="#ToC16"><
strong>Handshake Sequence Protocol</
strong></
a><
br>
2086N/A <
a href="#ToC17"><
strong>Data Transfer</
strong></
a><
br>
2086N/A <
a href="#ToC18"><
strong>Securing HTTP Communication</
strong></
a><
br>
2127N/A <
a href="#ToC19"><
strong>References</
strong></
a><
br>
2086N/A<
h2><
a name="ToC1">Cryptographic Techniques</
a></
h2>
2086N/AUnderstanding SSL requires an understanding of cryptographic algorithms,
2086N/Amessage digest functions (aka. one-way or hash functions), and digital
2086N/Asignatures. These techniques are the subject of entire books (see for instance
2086N/A[<
a href="#AC96">AC96</
a>]) and provide the basis for privacy, integrity, and
2086N/A<
h3><
a name="ToC2">Cryptographic Algorithms</
a></
h3>
2086N/ASuppose Alice wants to send a message to her bank to transfer some money.
2086N/AAlice would like the message to be private, since it will include information
2202N/Asuch as her account number and transfer amount. One solution is to use a
2202N/Acryptographic algorithm, a technique that would transform her message into an
2202N/Aencrypted form, unreadable except by those it is intended for. Once in this
2202N/Aform, the message may only be interpreted through the use of a secret key.
2202N/AWithout the key the message is useless: good cryptographic algorithms make it
2202N/Aso difficult for intruders to decode the original text that it isn't worth
2086N/AThere are two categories of cryptographic algorithms:
2086N/Aconventional and public key.
2086N/A<
li><
em>Conventional cryptography</
em>, also known as symmetric
2086N/Acryptography, requires the sender and receiver to share a key: a secret
2086N/Apiece of information that may be used to encrypt or decrypt a message.
2086N/AIf this key is secret, then nobody other than the sender or receiver may
2086N/Aread the message. If Alice and the bank know a secret key, then they
2086N/Amay send each other private messages. The task of privately choosing a key
2086N/Abefore communicating, however, can be problematic.
2086N/A<
li><
em>Public key cryptography</
em>, also known as asymmetric cryptography,
2086N/Asolves the key exchange problem by defining an algorithm which uses two keys,
2127N/Aeach of which may be used to encrypt a message. If one key is used to encrypt
2086N/Aa message then the other must be used to decrypt it. This makes it possible
2086N/Ato receive secure messages by simply publishing one key (the public key) and
2127N/Akeeping the other secret (the private key).
2086N/AAnyone may encrypt a message using the public key, but only the owner of the
2086N/Aprivate key will be able to read it. In this way, Alice may send private
2086N/Amessages to the owner of a key-pair (the bank), by encrypting it using their
2086N/Apublic key. Only the bank will be able to decrypt it.
2086N/A<
h3><
a name="ToC3">Message Digests</
a></
h3>
2086N/AAlthough Alice may encrypt her message to make it private, there is still a
2086N/Aconcern that someone might modify her original message or substitute
2086N/Ait with a different one, in order to transfer the money to themselves, for
2127N/Ainstance. One way of guaranteeing the integrity of Alice's message is to
2086N/Acreate a concise summary of her message and send this to the bank as well.
2086N/AUpon receipt of the message, the bank creates its own summary and compares it
2127N/Awith the one Alice sent. If they agree then the message was received intact.
2086N/AA summary such as this is called a <
em>message digest</
em>, <
em>one-way
2086N/Afunction</
em> or <
em>hash function</
em>. Message digests are used to create
2086N/Ashort, fixed-length representations of longer, variable-length messages.
2086N/ADigest algorithms are designed to produce unique digests for different
2086N/Amessages. Message digests are designed to make it too difficult to determine
2086N/Athe message from the digest, and also impossible to find two different
2086N/Amessages which create the same digest -- thus eliminating the possibility of
2086N/Asubstituting one message for another while maintaining the same digest.
2086N/AAnother challenge that Alice faces is finding a way to send the digest to the
2086N/Abank securely; when this is achieved, the integrity of the associated message
2086N/Ais assured. One way to to this is to include the digest in a digital
2086N/A<
h3><
a name="ToC4">Digital Signatures</
a></
h3>
2086N/AWhen Alice sends a message to the bank, the bank needs to ensure that the
2086N/Amessage is really from her, so an intruder does not request a transaction
2086N/Ainvolving her account. A <
em>digital signature</
em>, created by Alice and
2202N/Aincluded with the message, serves this purpose.
2202N/ADigital signatures are created by encrypting a digest of the message,
2202N/Aand other information (such as a sequence number) with the sender's
2202N/Aprivate key. Though anyone may <
em>decrypt</
em> the signature using the public
2202N/Akey, only the signer knows the private key. This means that only they may
2202N/Ahave signed it. Including the digest in the signature means the signature is
2086N/Aonly good for that message; it also ensures the integrity of the message since
2086N/Ano one can change the digest and still sign it.
2127N/ATo guard against interception and reuse of the signature by an intruder at a
2086N/Alater date, the signature contains a unique sequence number. This protects
2086N/Athe bank from a fraudulent claim from Alice that she did not send the message
2086N/A-- only she could have signed it (non-repudiation).
2086N/A<
h2><
a name="ToC5">Certificates</
a></
h2>
2086N/AAlthough Alice could have sent a private message to the bank, signed it, and
2086N/Aensured the integrity of the message, she still needs to be sure that she is
2086N/Areally communicating with the bank. This means that she needs to be sure that
2086N/Athe public key she is using corresponds to the bank's private key. Similarly,
2086N/Athe bank also needs to verify that the message signature really corresponds to
2086N/AIf each party has a certificate which validates the other's identity, confirms
2086N/Athe public key, and is signed by a trusted agency, then they both will be
2127N/Aassured that they are communicating with whom they think they are. Such a
2127N/Atrusted agency is called a <
em>Certificate Authority</
em>, and certificates are
2086N/A<
h3><
a name="ToC6">Certificate Contents</
a></
h3>
2086N/AA certificate associates a public key with the real identity of an individual,
2086N/Aserver, or other entity, known as the subject. As shown in <
a 2086N/Ahref="#table1">Table 1</
a>, information about the subject includes identifying
2086N/Ainformation (the distinguished name), and the public key. It also includes
2086N/Athe identification and signature of the Certificate Authority that issued the
2086N/Acertificate, and the period of time during which the certificate is valid. It
2086N/Amay have additional information (or extensions) as well as administrative
2127N/Ainformation for the Certificate Authority's use, such as a serial number.
2127N/A<
table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
2086N/A<
caption align="bottom" id="sf">Table 1: Certificate Information</
caption>
2086N/A<
table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
2086N/A<
tr><
td valign="top" align="center" bgcolor="#ffffff">
2086N/A<
tr valign="top"><
td><
b>Subject:</
b></
td>
2086N/A<
td>Distinguished Name, Public Key</
td></
tr>
2086N/A<
tr valign="top"><
td><
b>Issuer:</
b></
td>
2086N/A<
td>Distinguished Name, Signature</
td></
tr>
2086N/A<
tr><
td><
b>Period of Validity:</
b></
td>
2086N/A<
td>Not Before Date, Not After Date</
td></
tr>
2086N/A<
tr><
td><
b>Administrative Information:</
b></
td>
2086N/A<
td>Version, Serial Number</
td></
TR>
2086N/A<
tr><
td><
b>Extended Information:</
b></
td>
2086N/A<
td>Basic Contraints, Netscape Flags, etc.</
td></
TR>
2202N/AA distinguished name is used to provide an identity in a specific context --
2202N/Afor instance, an individual might have a personal certificate as well as one
2202N/Afor their identity as an employee. Distinguished names are defined by the
2202N/AX.509 standard [<
a href="#X509">X509</
A>], which defines the fields, field
2086N/Anames, and abbreviations used to refer to the fields
2086N/A(see <
a href="#table2">Table 2</
a>).
2086N/A<
table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
2086N/A<
caption align="bottom" id="sf">Table 2: Distinguished Name Information</
caption>
2086N/A<
table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
2086N/A<
tr><
td valign="top" align="center" bgcolor="#ffffff">
2086N/A<
tr valign="top"><
td><
b>DN Field:</
b></
td><
td><
b>Abbrev.:</
b></
td><
td><
b>Description:</
b></
td>
2086N/A<
tr valign="top"><
td>Common Name</
td><
td>CN</
td>
2086N/A<
td>Name being certified</
td><
td>CN=Joe Average</
td></
tr>
2127N/A<
tr valign="top"><
td>Organization or Company</
td><
td>O</
td>
2086N/A<
td>Name is associated with this<
br>organization</
td><
td>O=Snake Oil, Ltd.</
td></
tr>
2086N/A<
tr valign="top"><
td>Organizational Unit</
td><
td>OU</
td>
2127N/A<
td>Name is associated with this <
br>organization unit, such as a department</
td><
td>OU=Research Institute</
td></
tr>
2086N/A<
td>Name is located in this City</
td><
td>L=Snake City</
td></
tr>
2086N/A<
tr valign="top"><
td>Country</
td><
td>C</
td>
2086N/A<
td>Name is located in this Country (ISO code)</
td><
td>C=XZ</
td></
tr>
2086N/AA Certificate Authority may define a policy specifying which distinguished
2127N/Afield names are optional, and which are required. It may also place
2127N/Arequirements upon the field contents, as may users of certificates. As an
2086N/Aexample, a Netscape browser requires that the Common Name for a certificate
2086N/Arepresenting a server has a name which matches a wildcard pattern for the
2086N/AThe binary format of a certificate is defined using the ASN.1 notation [ <
a 2086N/Ahref="#X208">X208</
a>] [<
a href="#PKCS">PKCS</
a>]. This notation defines how to
2086N/Aspecify the contents, and encoding rules define how this information is
2086N/Atranslated into binary form. The binary encoding of the certificate is
2086N/Adefined using Distinguished Encoding Rules (DER), which are based on the more
2086N/Ageneral Basic Encoding Rules (BER). For those transmissions which cannot
2086N/Ahandle binary, the binary form may be translated into an ASCII form by using
2086N/ABase64 encoding [<
a href="#MIME">MIME</
a>]. This encoded version is called PEM
2086N/Aencoded (the name comes from "Privacy Enhanced Mail"), when placed between
2086N/Abegin and end delimiter lines as illustrated in <
a href="#table3">Table 3</
a>.
2086N/A<
table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
2086N/A<
caption align="bottom" id="sf">Table 3: Example of a PEM-encoded certificate (
snakeoil.crt)</
caption>
2202N/A<
table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
2202N/A<
tr><
td valign="top" align="center" bgcolor="#ffffff">
2202N/A<
table cellspacing="0" cellpadding="0" summary=""><
tr><
td>
2202N/AMIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
2086N/AFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
2086N/AA1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
2086N/Acml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
2127N/AbmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
2086N/AMAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
2086N/Aa2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
2086N/AcnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
2086N/AAQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
2086N/AlWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
2086N/AgQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
2086N/A2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
2086N/A-----END CERTIFICATE-----</
pre></
div>
2086N/A<
h3><
a name="ToC7">Certificate Authorities</
a></
h3>
2086N/ABy first verifying the information in a certificate request before granting
2086N/Athe certificate, the Certificate Authority assures the identity of the private
2086N/Akey owner of a key-pair. For instance, if Alice requests a personal
2086N/Acertificate, the Certificate Authority must first make sure that Alice really
2086N/Ais the person the certificate request claims.
2086N/A<
h4><
a name="ToC8">Certificate Chains</
a></
h4>
2086N/AA Certificate Authority may also issue a certificate for another Certificate
2086N/AAuthority. When examining a certificate, Alice may need to examine the
2127N/Acertificate of the issuer, for each parent Certificate Authority, until
2086N/Areaching one which she has confidence in. She may decide to trust only
2086N/Acertificates with a limited chain of issuers, to reduce her risk of a "bad"
2127N/A<
h4><
a name="ToC9">Creating a Root-Level CA</
a></
h4>
2086N/AAs noted earlier, each certificate requires an issuer to assert the validity
2086N/Aof the identity of the certificate subject, up to the top-level Certificate
2086N/AAuthority (CA). This presents a problem: Since this is who vouches for the
2086N/Acertificate of the top-level authority, which has no issuer?
2086N/AIn this unique case, the certificate is "self-signed", so the issuer of the
2086N/Acertificate is the same as the subject. As a result, one must exercise extra
2086N/Acare in trusting a self-signed certificate. The wide publication of a public
2086N/Akey by the root authority reduces the risk in trusting this key -- it would be
2086N/Aobvious if someone else publicized a key claiming to be the authority.
2086N/ABrowsers are preconfigured to trust well-known certificate authorities.
2086N/ACertificate Authorities. These companies provide the following services:
2086N/A<
li>Verifying certificate requests
2086N/A<
li>Processing certificate requests
2086N/A<
li>Issuing and managing certificates
2086N/AIt is also possible to create your own Certificate Authority. Although risky
2202N/Ain the Internet environment, it may be useful within an Intranet where the
2202N/Aorganization can easily verify the identities of individuals and servers.
2202N/A<
h4><
a name="ToC10">Certificate Management</
a></
h4>
2202N/AEstablishing a Certificate Authority is a responsibility which requires a
2202N/Asolid administrative, technical, and management framework.
2202N/ACertificate Authorities not only issue certificates, they also manage them --
2202N/Athat is, they determine how long certificates are valid, they renew them, and
2086N/Athey keep lists of certificates that have already been issued but are no
2086N/Alonger valid (Certificate Revocation Lists, or CRLs).
2086N/ASay Alice is entitled to a certificate as an employee of a company. Say too,
2127N/Athat the certificate needs to be revoked when Alice leaves the company. Since
2086N/Acertificates are objects that get passed around, it is impossible to tell from
2086N/Athe certificate alone that it has been revoked.
2086N/AWhen examining certificates for validity, therefore, it is necessary to
2086N/Acontact the issuing Certificate Authority to check CRLs -- this is not usually
2086N/Aan automated part of the process.
2086N/A<
div align="center"><
B>Note:</
B></
div>
2086N/AIf you use a Certificate Authority that is not configured into browsers by
2086N/Adefault, it is necessary to load the Certificate Authority certificate into
2086N/Athe browser, enabling the browser to validate server certificates signed by
2086N/Athat Certificate Authority. Doing so may be dangerous, since once loaded, the
2127N/Abrowser will accept all certificates signed by that Certificate Authority.
2086N/A<
h2><
a name="ToC11">Secure Sockets Layer (SSL)</
a></
h2>
2086N/AThe Secure Sockets Layer protocol is a protocol layer which may be placed
2127N/Abetween a reliable connection-oriented network layer protocol (
e.g. TCP/
IP)
2127N/Aand the application protocol layer (
e.g. HTTP). SSL provides for secure
2086N/Acommunication between client and server by allowing mutual authentication, the
2086N/Ause of digital signatures for integrity, and encryption for privacy.
2086N/AThe protocol is designed to support a range of choices for specific algorithms
2086N/Aused for cryptography, digests, and signatures. This allows algorithm
2086N/Aselection for specific servers to be made based on legal, export or other
2086N/Aconcerns, and also enables the protocol to take advantage of new algorithms.
2086N/AChoices are negotiated between client and server at the start of establishing
2127N/A<
table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
2127N/A<
caption align="bottom" id="sf">Table 4: Versions of the SSL protocol</
caption>
2086N/A<
table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
2086N/A<
tr><
td valign="top" align="center" bgcolor="#ffffff">
2086N/A<
td><
b>Description:</
b></
td>
2086N/A<
td><
b>Browser Support:</
b></
td>
2086N/A<
td>Vendor Standard (from Netscape Corp.) [<
a href="#SSL2">SSL2</
a>]</
td>
2086N/A<
td>First SSL protocol for which implementations exists</
td>
2086N/A<
td>Expired Internet Draft (from Netscape Corp.) [<
a href="#SSL3">SSL3</
a>]</
td>
2202N/A<
td>Revisions to prevent specific security attacks, add non-RSA ciphers, and support for certificate chains</
td>
2086N/A<
td>Proposed Internet Standard (from IETF) [<
a href="#TLS1">TLS1</
a>]</
td>
2086N/A<
td>Revision of SSL 3.0 to update the MAC layer to HMAC, add block padding for
2110N/A block ciphers, message order standardization and more alert messages.
2086N/AThere are a number of versions of the SSL protocol, as shown in <
a 2086N/Ahref="#table4">Table 4</
a>. As noted there, one of the benefits in SSL 3.0 is
2086N/Athat it adds support of certificate chain loading. This feature allows a
2127N/Aserver to pass a server certificate along with issuer certificates to the
2086N/Abrowser. Chain loading also permits the browser to validate the server
2086N/Acertificate, even if Certificate Authority certificates are not installed for
2127N/Athe intermediate issuers, since they are included in the certificate chain.
2127N/ASSL 3.0 is the basis for the Transport Layer Security [<
A 2086N/AHREF="#TLS1">TLS</
A>] protocol standard, currently in development by the
2086N/AInternet Engineering Task Force (IETF).
2086N/A<
h3><
a name="ToC12">Session Establishment</
a></
h3>
2086N/AThe SSL session is established by following a <
I>handshake sequence</
I>
2086N/Abetween client and server, as shown in <
a href="#figure1">Figure 1</
a>. This
2086N/Asequence may vary, depending on whether the server is configured to provide a
2086N/Aserver certificate or request a client certificate. Though cases exist where
2086N/Aadditional handshake steps are required for management of cipher information,
2086N/Athis article summarizes one common scenario: see the SSL specification for the
2127N/Afull range of possibilities.
2086N/A<
div align="center"><
b>Note</
b></
div>
2127N/AOnce an SSL session has been established it may be reused, thus avoiding the
2127N/Aperformance penalty of repeating the many steps needed to start a session.
2086N/AFor this the server assigns each SSL session a unique session identifier which
2086N/Ais cached in the server and which the client can use on forthcoming
2086N/Aconnections to reduce the handshake (until the session identifer expires in
2086N/A<
table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
2086N/A<
caption align="bottom" id="sf">Figure 1: Simplified SSL Handshake Sequence</
caption>
2086N/A<
table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
2086N/A<
tr><
td valign="top" align="center" bgcolor="#ffffff">
2086N/AThe elements of the handshake sequence, as used by the client and server, are
2086N/A<
li>Negotiate the Cipher Suite to be used during data transfer
2086N/A<
li>Establish and share a session key between client and server
2202N/A<
li>Optionally authenticate the server to the client
2202N/A<
li>Optionally authenticate the client to the server
2202N/AThe first step, Cipher Suite Negotiation, allows the client and server to
2202N/Achoose a Cipher Suite supportable by both of them. The SSL3.0 protocol
2202N/Aspecification defines 31 Cipher Suites. A Cipher Suite is defined by the
2127N/A<
li>Cipher for Data Transfer
2086N/A<
li>Message Digest for creating the Message Authentication Code (MAC)
2086N/AThese three elements are described in the sections that follow.
2086N/A<
h3><
a name="ToC13">Key Exchange Method</
a></
h3>
2086N/AThe key exchange method defines how the shared secret symmetric cryptography
2086N/Akey used for application data transfer will be agreed upon by client and
2086N/Aserver. SSL 2.0 uses RSA key exchange only, while SSL 3.0 supports a choice of
2086N/Akey exchange algorithms including the RSA key exchange when certificates are
2086N/Aused, and Diffie-Hellman key exchange for exchanging keys without certificates
2086N/Aand without prior communication between client and server.
2086N/AOne variable in the choice of key exchange methods is digital signatures --
2127N/Awhether or not to use them, and if so, what kind of signatures to use.
2086N/ASigning with a private key provides assurance against a
2086N/Aman-in-the-middle-attack during the information exchange used in generating
2127N/Athe shared key [<
a href="#AC96">AC96</
a>, p516].
2127N/A<
h3><
a name="ToC14">Cipher for Data Transfer</
a></
h3>
2086N/ASSL uses the conventional cryptography algorithm (symmetric cryptography)
2086N/Adescribed earlier for encrypting messages in a session. There are nine
2086N/Achoices, including the choice to perform no encryption:
2086N/A <
li>Triple-DES with 168 bit key
2086N/AHere "CBC" refers to Cipher Block Chaining, which means that a portion of the
2086N/Apreviously encrypted cipher text is used in the encryption of the current
2086N/Ablock. "DES" refers to the Data Encryption Standard [<
a href="#AC96">AC96</
a>,
2086N/Ach12], which has a number of variants (including DES40 and 3DES_EDE). "Idea"
2086N/Ais one of the best and cryptographically strongest available algorithms, and
2086N/A"RC2" is a proprietary algorithm from RSA DSI [<
a href="#AC96">AC96</
a>,
2086N/A<
h3><
a name="ToC15">Digest Function</
a></
h3>
2086N/AThe choice of digest function determines how a digest is created from a record
2086N/Aunit. SSL supports the following:
2086N/A<
li>Secure Hash Algorithm (SHA-1), a 160-bit hash
2086N/AThe message digest is used to create a Message Authentication Code (MAC) which
2086N/Ais encrypted with the message to provide integrity and to prevent against
2202N/A<
h3><
a name="ToC16">Handshake Sequence Protocol</
a></
h3>
2202N/AThe handshake sequence uses three protocols:
2202N/A<
li>The <
em>SSL Handshake Protocol</
em>
2202N/A for performing the client and server SSL session establishment.
2202N/A<
li>The <
em>SSL Change Cipher Spec Protocol</
em> for actually establishing agreement
2202N/A on the Cipher Suite for the session.
2086N/A<
li>The <
em>SSL Alert Protocol</
em> for
2086N/A conveying SSL error messages between client and server.
2127N/AThese protocols, as well as application protocol data, are encapsulated in the
2086N/A<
em>SSL Record Protocol</
em>, as shown in <
a href="#figure2">Figure 2</
a>. An
2086N/Aencapsulated protocol is transferred as data by the lower layer protocol,
2086N/Awhich does not examine the data. The encapsulated protocol has no knowledge of
2086N/A<
table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
2086N/A<
caption align="bottom" id="sf">Figure 2: SSL Protocol Stack</
caption>
2086N/A<
table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
2086N/A<
tr><
td valign="top" align="center" bgcolor="#ffffff">
2086N/AThe encapsulation of SSL control protocols by the record protocol means that
2086N/Aif an active session is renegotiated the control protocols will be transmitted
2086N/Asecurely. If there were no session before, then the Null cipher suite is
2086N/Aused, which means there is no encryption and messages have no integrity
2086N/Adigests until the session has been established.
2086N/A<
h3><
a name="ToC17">Data Transfer</
a></
h3>
2086N/AThe SSL Record Protocol, shown in <
a href="#figure3">Figure 3</
a>, is used to
2086N/Atransfer application and SSL Control data between the client and server,
2086N/Apossibly fragmenting this data into smaller units, or combining multiple
2127N/Ahigher level protocol data messages into single units. It may compress, attach
2086N/Adigest signatures, and encrypt these units before transmitting them using the
2086N/Aunderlying reliable transport protocol (Note: currently all major SSL
2127N/Aimplementations lack support for compression).
2086N/A<
table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
2086N/A<
caption align="bottom" id="sf">Figure 3: SSL Record Protocol</
caption>
2086N/A<
table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
2086N/A<
tr><
td valign="top" align="center" bgcolor="#ffffff">
2086N/A<
h3><
a name="ToC18">Securing HTTP Communication</
a></
h3>
2202N/AOne common use of SSL is to secure Web HTTP communication between a browser
2202N/Aand a webserver. This case does not preclude the use of non-secured HTTP. The
2202N/Asecure version is mainly plain HTTP over SSL (named HTTPS), but with one major
2202N/Adifference: it uses the URL scheme <
code>https</
code> rather than
2202N/A<
code>http</
code> and a different server port (by default 443). This mainly
2202N/Ais what mod_ssl provides to you for the Apache webserver...
2202N/A<
h2><
a name="ToC19">References</
a></
h2>
2086N/A[AC96] Bruce Schneier, <
em>Applied Cryptography</
em>, 2nd Edition, Wiley,
2086N/A various other materials by Bruce Schneier.
2086N/A[X208] ITU-T Recommendation X.208, <
em>Specification of Abstract Syntax Notation
2086N/A One (ASN.1)</
em>, 1988. See for instance <
a 2086N/A[X509] ITU-T Recommendation X.509, <
em>The Directory - Authentication
2086N/A Framework</
em>, 1988. See for instance <
a 2086N/A[PKCS] Kaliski, Burton S., Jr., <
em>An Overview of the PKCS Standards</
em>, An RSA
2086N/A Laboratories Technical Note, revised November 1, 1993.
2086N/A[MIME] N. Freed, N. Borenstein, <
em>Multipurpose Internet Mail Extensions
2086N/A (MIME) Part One: Format of Internet Message Bodies</
em>, RFC2045.
2202N/A[SSL2] Kipp
E.B. Hickman, <
em>The SSL Protocol</
em>, 1995.
2086N/A[SSL3] Alan O. Freier, Philip Karlton, Paul C. Kocher, <
em>The SSL Protocol
2086N/A Version 3.0</
em>, 1996. See <
a 2127N/A[TLS1] Tim Dierks, Christopher Allen, <
em>The TLS Protocol Version 1.0</
em>,
2086N/A <
table width="600" border="0" summary="">
2086N/A <
td valign="top" align="left" width="250">
2086N/A<
a href="ssl_overview.html" onmouseover="ro_imgOver('ro_img_prev_bot', 'previous page'); return true" onmouseout="ro_imgNormal('ro_img_prev_bot'); return true" onfocus="ro_imgOver('ro_img_prev_bot', 'previous page'); return true" onblur="ro_imgNormal('ro_img_prev_bot'); return true"><
img name="ro_img_prev_bot" src="ssl_template.navbut-prev-n.gif" alt="previous page" width="70" height="18" border="0"></
a><
br><
font color="#000000">Overview</
font>
2086N/A <
td valign="top" align="right" width="250">
2086N/A<
a href="ssl_reference.html" onmouseover="ro_imgOver('ro_img_next_bot', 'next page'); return true" onmouseout="ro_imgNormal('ro_img_next_bot'); return true" onfocus="ro_imgOver('ro_img_next_bot', 'next page'); return true" onblur="ro_imgNormal('ro_img_next_bot'); return true"><
img name="ro_img_next_bot" src="ssl_template.navbut-next-n.gif" alt="next page" width="70" height="18" border="0"></
a><
br><
font color="#000000">Reference</
font>
2202N/A <
td><
table width="598" summary="">
2202N/A <
td align="left"><
font face="Arial,Helvetica">
2202N/A The Apache Interface to OpenSSL
2086N/A <
td align="right"><
font face="Arial,Helvetica">
