| <?xml version='1.0' encoding='UTF-8' ?> |
| <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd"> |
| <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?> |
| <!-- $Revision: 1.10 $ --> |
| |
| <!-- |
| Copyright 2002-2004 The Apache Software Foundation |
| |
| Licensed under the Apache License, Version 2.0 (the "License"); |
| you may not use this file except in compliance with the License. |
| You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| |
| <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> |