1<html> 2<head> 3<title>mod_ssl: Introduction</title> 4 5<!-- 6 Copyright (c) 1998-2001 Ralf S. Engelschall. All rights reserved. 7 8 Redistribution and use in source and binary forms, with or without 9 modification, are permitted provided that the following conditions 10 are met: 11 12 1. Redistributions of source code must retain the above 13 copyright notice, this list of conditions and the following 14 disclaimer. 15 16 2. Redistributions in binary form must reproduce the above 17 copyright notice, this list of conditions and the following 18 disclaimer in the documentation and/or other materials 19 provided with the distribution. 20 21 3. All advertising materials mentioning features or use of this 22 software must display the following acknowledgment: 23 "This product includes software developed by 24 Ralf S. Engelschall <rse@engelschall.com> for use in the 25 mod_ssl project (http://www.modssl.org/)." 26 27 4. The name "mod_ssl" must not be used to endorse or promote 28 products derived from this software without prior written 29 permission. 30 31 5. Redistributions of any form whatsoever must retain the 32 following acknowledgment: 33 "This product includes software developed by 34 Ralf S. Engelschall <rse@engelschall.com> for use in the 35 mod_ssl project (http://www.modssl.org/)." 36 37 THIS SOFTWARE IS PROVIDED BY RALF S. ENGELSCHALL ``AS IS'' AND ANY 38 EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 39 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 40 PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL RALF S. ENGELSCHALL OR 41 HIS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 42 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 43 NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 44 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 45 HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, 46 STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 47 ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED 48 OF THE POSSIBILITY OF SUCH DAMAGE. 49--> 50<style type="text/css"><!-- 51A:link { 52 text-decoration: none; 53 color: #6666cc; 54} 55A:active { 56 text-decoration: none; 57 color: #6666cc; 58} 59A:visited { 60 text-decoration: none; 61 color: #6666cc; 62} 63#sf { 64 font-family: arial,helvetica; 65 font-variant: normal; 66 font-style: normal; 67} 68H1 { 69 font-weight: bold; 70 font-size: 24pt; 71 line-height: 24pt; 72 font-family: arial,helvetica; 73 font-variant: normal; 74 font-style: normal; 75} 76H2 { 77 font-weight: bold; 78 font-size: 18pt; 79 line-height: 18pt; 80 font-family: arial,helvetica; 81 font-variant: normal; 82 font-style: normal; 83} 84H3 { 85 font-weight: bold; 86 font-size: 14pt; 87 line-height: 14pt; 88 font-family: arial,helvetica; 89 font-variant: normal; 90 font-style: normal; 91} 92H4 { 93 font-weight: bold; 94 font-size: 12pt; 95 line-height: 12pt; 96 font-family: arial,helvetica; 97 font-variant: normal; 98 font-style: normal; 99} 100#H { 101} 102#D { 103 background-color: #f0f0f0; 104} 105#faq { 106 font-weight: bold; 107 font-size: 16pt; 108 line-height: 16pt; 109 font-family: arial,helvetica; 110 font-variant: normal; 111 font-style: normal; 112} 113#howto { 114 font-weight: bold; 115 font-size: 16pt; 116 line-height: 16pt; 117 font-family: arial,helvetica; 118 font-variant: normal; 119 font-style: normal; 120} 121#term { 122 font-weight: bold; 123 font-size: 16pt; 124 line-height: 16pt; 125 font-family: arial,helvetica; 126 font-variant: normal; 127 font-style: normal; 128} 129--></style> 130<script type="text/javascript" language="JavaScript"> 131<!-- Hiding the code 132function ro_imgNormal(imgName) { 133 if (document.images) { 134 document[imgName].src = eval(imgName + '_n.src'); 135 self.status = ''; 136 } 137} 138function ro_imgOver(imgName, descript) { 139 if (document.images) { 140 document[imgName].src = eval(imgName + '_o.src'); 141 self.status = descript; 142 } 143} 144// done hiding --> 145</script> 146<script type="text/javascript" language="JavaScript"> 147<!-- Hiding the code 148if (document.images) { 149 ro_img_prev_top_n = new Image(); 150 ro_img_prev_top_n.src = 'ssl_template.navbut-prev-n.gif'; 151 ro_img_prev_top_o = new Image(); 152 ro_img_prev_top_o.src = 'ssl_template.navbut-prev-s.gif'; 153} 154// done hiding --> 155</script> 156<script type="text/javascript" language="JavaScript"> 157<!-- Hiding the code 158if (document.images) { 159 ro_img_prev_bot_n = new Image(); 160 ro_img_prev_bot_n.src = 'ssl_template.navbut-prev-n.gif'; 161 ro_img_prev_bot_o = new Image(); 162 ro_img_prev_bot_o.src = 'ssl_template.navbut-prev-s.gif'; 163} 164// done hiding --> 165</script> 166<script type="text/javascript" language="JavaScript"> 167<!-- Hiding the code 168if (document.images) { 169 ro_img_next_top_n = new Image(); 170 ro_img_next_top_n.src = 'ssl_template.navbut-next-n.gif'; 171 ro_img_next_top_o = new Image(); 172 ro_img_next_top_o.src = 'ssl_template.navbut-next-s.gif'; 173} 174// done hiding --> 175</script> 176<script type="text/javascript" language="JavaScript"> 177<!-- Hiding the code 178if (document.images) { 179 ro_img_next_bot_n = new Image(); 180 ro_img_next_bot_n.src = 'ssl_template.navbut-next-n.gif'; 181 ro_img_next_bot_o = new Image(); 182 ro_img_next_bot_o.src = 'ssl_template.navbut-next-s.gif'; 183} 184// done hiding --> 185</script> 186</head> 187<body bgcolor="#ffffff" text="#000000" link="#333399" alink="#9999ff" vlink="#000066"> 188<div align="center"> 189<table width="600" cellspacing="0" cellpadding="0" border="0" summary=""> 190<tr> 191 <td> 192 <img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="600" height="1" align="bottom" border="0"><br> 193 <table width="600" cellspacing="0" cellpadding="0" summary=""> 194 <tr> 195 <td> 196 <table width="600" summary=""> 197 <tr> 198 <td align="left" valign="bottom"> 199 <font face="Arial,Helvetica" size="+2"><b>mod_ssl</b></font> 200 </td> 201 <td align="right"> 202 <img src="ssl_template.head-chapter.gif" alt="Chapter" width="175" height="94"> <img src="ssl_template.head-num-2.gif" alt="2" width="74" height="89"> 203 </td> 204 </tr> 205 </table> 206 </td> 207 </tr> 208 <tr> 209 <td><img src="ssl_template.imgdot-1x1-000000.gif" alt="" width="600" height="2" align="bottom" border="0"></td> 210 </tr> 211 <tr> 212 <td> 213 <table width="600" border="0" summary=""> 214 <tr> 215 <td valign="top" align="left" width="250"> 216<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> 217 </td> 218 <td valign="top" align="right" width="250"> 219<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> 220 </td> 221 </tr> 222 </table> 223 </td> 224 </tr> 225 <tr> 226 <td> 227 <br> 228 <img src="ssl_template.title-intro.gif" alt="Introduction" width="456" height="60"> 229 </td> 230 </tr> 231 </table> 232<div align="right"> 233<table cellspacing="0" cellpadding="0" width="400" summary=""> 234<tr> 235<td> 236<em> 237``The nice thing about standards is that there are so many to choose from. 238And if you really don't like all the standards you just have to wait another 239year until the one arises you are looking for.'' 240</em> 241</td> 242</tr> 243<tr> 244<td align="right"> 245<font size="-1"> 246A. Tanenbaum, ``Introduction to Computer Networks'' 247</font> 248</td> 249</tr> 250</table> 251</div> 252<p> 253<table cellspacing="0" cellpadding="0" border="0" summary=""> 254<tr valign="bottom"> 255<td> 256<img src="ssl_intro.gfont000.gif" alt="A" width="37" height="35" border="0" align="left"> 257s an introduction this chapter is aimed at readers who are familiar 258with the Web, HTTP, and Apache, but are not security experts. It is not 259intended to be a definitive guide to the SSL protocol, nor does it discuss 260specific techniques for managing certificates in an organization, or the 261important legal issues of patents and import and export restrictions. Rather, 262it is intended to provide a common background to mod_ssl users by pulling 263together various concepts, definitions, and examples as a starting point for 264further exploration. 265<p> 266The presented content is mainly derived, with permission by the author, from 267the article <a 268href="http://www.ultranet.com/~fhirsch/Papers/wwwj/index.html"><em>Introducing SSL 269and Certificates using SSLeay</em></a> from <a 270href="http://www.ultranet.com/~fhirsch/">Frederick J. Hirsch</a>, of The Open 271Group Research Institute, which was published in <a 272href="http://www.ora.com/catalog/wjsum97/"><em>Web Security: A Matter of 273Trust</em></a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997. 274Please send any postive feedback to <a 275href="mailto:fjh@alum.mit.edu">Frederick Hirsch</a> (the original 276article author) and all negative feedback to <a 277href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> (the mod_ssl 278author). 279</td> 280<td> 281 282</td> 283<td> 284<div align="right"> 285<table cellspacing="0" cellpadding="5" border="0" bgcolor="#ccccff" summary=""> 286<tr> 287<td bgcolor="#333399"> 288<font face="Arial,Helvetica" color="#ccccff"> 289<b>Table Of Contents</b> 290</font> 291</td> 292</tr> 293<tr> 294<td> 295<font face="Arial,Helvetica" size="-1"> 296 <a href="#ToC1"><strong>Cryptographic Techniques</strong></a><br> 297 <a href="#ToC2"><strong>Cryptographic Algorithms</strong></a><br> 298 <a href="#ToC3"><strong>Message Digests</strong></a><br> 299 <a href="#ToC4"><strong>Digital Signatures</strong></a><br> 300 <a href="#ToC5"><strong>Certificates</strong></a><br> 301 <a href="#ToC6"><strong>Certificate Contents</strong></a><br> 302 <a href="#ToC7"><strong>Certificate Authorities</strong></a><br> 303 <a href="#ToC8"><strong>Certificate Chains</strong></a><br> 304 <a href="#ToC9"><strong>Creating a Root-Level CA</strong></a><br> 305 <a href="#ToC10"><strong>Certificate Management</strong></a><br> 306 <a href="#ToC11"><strong>Secure Sockets Layer (SSL)</strong></a><br> 307 <a href="#ToC12"><strong>Session Establishment</strong></a><br> 308 <a href="#ToC13"><strong>Key Exchange Method</strong></a><br> 309 <a href="#ToC14"><strong>Cipher for Data Transfer</strong></a><br> 310 <a href="#ToC15"><strong>Digest Function</strong></a><br> 311 <a href="#ToC16"><strong>Handshake Sequence Protocol</strong></a><br> 312 <a href="#ToC17"><strong>Data Transfer</strong></a><br> 313 <a href="#ToC18"><strong>Securing HTTP Communication</strong></a><br> 314 <a href="#ToC19"><strong>References</strong></a><br> 315</font> 316</td> 317</tr> 318</table> 319</div> 320</td> 321</tr> 322</table> 323<h2><a name="ToC1">Cryptographic Techniques</a></h2> 324Understanding SSL requires an understanding of cryptographic algorithms, 325message digest functions (aka. one-way or hash functions), and digital 326signatures. These techniques are the subject of entire books (see for instance 327[<a href="#AC96">AC96</a>]) and provide the basis for privacy, integrity, and 328authentication. 329<h3><a name="ToC2">Cryptographic Algorithms</a></h3> 330Suppose Alice wants to send a message to her bank to transfer some money. 331Alice would like the message to be private, since it will include information 332such as her account number and transfer amount. One solution is to use a 333cryptographic algorithm, a technique that would transform her message into an 334encrypted form, unreadable except by those it is intended for. Once in this 335form, the message may only be interpreted through the use of a secret key. 336Without the key the message is useless: good cryptographic algorithms make it 337so difficult for intruders to decode the original text that it isn't worth 338their effort. 339<p> 340There are two categories of cryptographic algorithms: 341conventional and public key. 342<ul> 343<li><em>Conventional cryptography</em>, also known as symmetric 344cryptography, requires the sender and receiver to share a key: a secret 345piece of information that may be used to encrypt or decrypt a message. 346If this key is secret, then nobody other than the sender or receiver may 347read the message. If Alice and the bank know a secret key, then they 348may send each other private messages. The task of privately choosing a key 349before communicating, however, can be problematic. 350<p> 351<li><em>Public key cryptography</em>, also known as asymmetric cryptography, 352solves the key exchange problem by defining an algorithm which uses two keys, 353each of which may be used to encrypt a message. If one key is used to encrypt 354a message then the other must be used to decrypt it. This makes it possible 355to receive secure messages by simply publishing one key (the public key) and 356keeping the other secret (the private key). 357<p> 358Anyone may encrypt a message using the public key, but only the owner of the 359private key will be able to read it. In this way, Alice may send private 360messages to the owner of a key-pair (the bank), by encrypting it using their 361public key. Only the bank will be able to decrypt it. 362</ul> 363<h3><a name="ToC3">Message Digests</a></h3> 364Although Alice may encrypt her message to make it private, there is still a 365concern that someone might modify her original message or substitute 366it with a different one, in order to transfer the money to themselves, for 367instance. One way of guaranteeing the integrity of Alice's message is to 368create a concise summary of her message and send this to the bank as well. 369Upon receipt of the message, the bank creates its own summary and compares it 370with the one Alice sent. If they agree then the message was received intact. 371<p> 372A summary such as this is called a <em>message digest</em>, <em>one-way 373function</em> or <em>hash function</em>. Message digests are used to create 374short, fixed-length representations of longer, variable-length messages. 375Digest algorithms are designed to produce unique digests for different 376messages. Message digests are designed to make it too difficult to determine 377the message from the digest, and also impossible to find two different 378messages which create the same digest -- thus eliminating the possibility of 379substituting one message for another while maintaining the same digest. 380<p> 381Another challenge that Alice faces is finding a way to send the digest to the 382bank securely; when this is achieved, the integrity of the associated message 383is assured. One way to to this is to include the digest in a digital 384signature. 385<h3><a name="ToC4">Digital Signatures</a></h3> 386When Alice sends a message to the bank, the bank needs to ensure that the 387message is really from her, so an intruder does not request a transaction 388involving her account. A <em>digital signature</em>, created by Alice and 389included with the message, serves this purpose. 390<p> 391Digital signatures are created by encrypting a digest of the message, 392and other information (such as a sequence number) with the sender's 393private key. Though anyone may <em>decrypt</em> the signature using the public 394key, only the signer knows the private key. This means that only they may 395have signed it. Including the digest in the signature means the signature is 396only good for that message; it also ensures the integrity of the message since 397no one can change the digest and still sign it. 398<p> 399To guard against interception and reuse of the signature by an intruder at a 400later date, the signature contains a unique sequence number. This protects 401the bank from a fraudulent claim from Alice that she did not send the message 402-- only she could have signed it (non-repudiation). 403<h2><a name="ToC5">Certificates</a></h2> 404Although Alice could have sent a private message to the bank, signed it, and 405ensured the integrity of the message, she still needs to be sure that she is 406really communicating with the bank. This means that she needs to be sure that 407the public key she is using corresponds to the bank's private key. Similarly, 408the bank also needs to verify that the message signature really corresponds to 409Alice's signature. 410<p> 411If each party has a certificate which validates the other's identity, confirms 412the public key, and is signed by a trusted agency, then they both will be 413assured that they are communicating with whom they think they are. Such a 414trusted agency is called a <em>Certificate Authority</em>, and certificates are 415used for authentication. 416<h3><a name="ToC6">Certificate Contents</a></h3> 417A certificate associates a public key with the real identity of an individual, 418server, or other entity, known as the subject. As shown in <a 419href="#table1">Table 1</a>, information about the subject includes identifying 420information (the distinguished name), and the public key. It also includes 421the identification and signature of the Certificate Authority that issued the 422certificate, and the period of time during which the certificate is valid. It 423may have additional information (or extensions) as well as administrative 424information for the Certificate Authority's use, such as a serial number. 425<p> 426<div align="center"> 427<a name="table1"></a> 428<table width="600" cellspacing="0" cellpadding="1" border="0" summary=""> 429<caption align="bottom" id="sf">Table 1: Certificate Information</caption> 430<tr><td bgcolor="#cccccc"> 431<table width="598" cellpadding="5" cellspacing="0" border="0" summary=""> 432<tr><td valign="top" align="center" bgcolor="#ffffff"> 433<table summary=""> 434<tr valign="top"><td><b>Subject:</b></td> 435<td>Distinguished Name, Public Key</td></tr> 436<tr valign="top"><td><b>Issuer:</b></td> 437<td>Distinguished Name, Signature</td></tr> 438<tr><td><b>Period of Validity:</b></td> 439<td>Not Before Date, Not After Date</td></tr> 440<tr><td><b>Administrative Information:</b></td> 441<td>Version, Serial Number</td></TR> 442<tr><td><b>Extended Information:</b></td> 443<td>Basic Contraints, Netscape Flags, etc.</td></TR> 444</table> 445</td> 446</tr></table> 447</td></tr></table> 448</div> 449<p> 450A distinguished name is used to provide an identity in a specific context -- 451for instance, an individual might have a personal certificate as well as one 452for their identity as an employee. Distinguished names are defined by the 453X.509 standard [<a href="#X509">X509</A>], which defines the fields, field 454names, and abbreviations used to refer to the fields 455(see <a href="#table2">Table 2</a>). 456<p> 457<div align="center"> 458<a name="table2"></a> 459<table width="600" cellspacing="0" cellpadding="1" border="0" summary=""> 460<caption align="bottom" id="sf">Table 2: Distinguished Name Information</caption> 461<tr><td bgcolor="#cccccc"> 462<table width="598" cellpadding="5" cellspacing="0" border="0" summary=""> 463<tr><td valign="top" align="center" bgcolor="#ffffff"> 464<table summary=""> 465<tr valign="top"><td><b>DN Field:</b></td><td><b>Abbrev.:</b></td><td><b>Description:</b></td> 466<td><b>Example:</b></td> 467</t> 468<tr valign="top"><td>Common Name</td><td>CN</td> 469<td>Name being certified</td><td>CN=Joe Average</td></tr> 470<tr valign="top"><td>Organization or Company</td><td>O</td> 471<td>Name is associated with this<br>organization</td><td>O=Snake Oil, Ltd.</td></tr> 472<tr valign="top"><td>Organizational Unit</td><td>OU</td> 473<td>Name is associated with this <br>organization unit, such as a department</td><td>OU=Research Institute</td></tr> 474<tr valign="top"><td>City/Locality</td><td>L</td> 475<td>Name is located in this City</td><td>L=Snake City</td></tr> 476<tr valign="top"><td>State/Province</td><td>ST</td> 477<td>Name is located in this State/Province</td><td>ST=Desert</td></tr> 478<tr valign="top"><td>Country</td><td>C</td> 479<td>Name is located in this Country (ISO code)</td><td>C=XZ</td></tr> 480</table> 481</td> 482</tr></table> 483</td></tr></table> 484</div> 485<p> 486A Certificate Authority may define a policy specifying which distinguished 487field names are optional, and which are required. It may also place 488requirements upon the field contents, as may users of certificates. As an 489example, a Netscape browser requires that the Common Name for a certificate 490representing a server has a name which matches a wildcard pattern for the 491domain name of that server, such as <code>*.snakeoil.com</code>. 492<p> 493The binary format of a certificate is defined using the ASN.1 notation [ <a 494href="#X208">X208</a>] [<a href="#PKCS">PKCS</a>]. This notation defines how to 495specify the contents, and encoding rules define how this information is 496translated into binary form. The binary encoding of the certificate is 497defined using Distinguished Encoding Rules (DER), which are based on the more 498general Basic Encoding Rules (BER). For those transmissions which cannot 499handle binary, the binary form may be translated into an ASCII form by using 500Base64 encoding [<a href="#MIME">MIME</a>]. This encoded version is called PEM 501encoded (the name comes from "Privacy Enhanced Mail"), when placed between 502begin and end delimiter lines as illustrated in <a href="#table3">Table 3</a>. 503<p> 504<div align="center"> 505<a name="table3"></a> 506<table width="600" cellspacing="0" cellpadding="1" border="0" summary=""> 507<caption align="bottom" id="sf">Table 3: Example of a PEM-encoded certificate (snakeoil.crt)</caption> 508<tr><td bgcolor="#cccccc"> 509<table width="598" cellpadding="5" cellspacing="0" border="0" summary=""> 510<tr><td valign="top" align="center" bgcolor="#ffffff"> 511<table cellspacing="0" cellpadding="0" summary=""><tr><td> 512<div class="code"><pre> 513-----BEGIN CERTIFICATE----- 514MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx 515FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG 516A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv 517cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz 518bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL 519MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h 520a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl 521cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN 522AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB 523gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b 524vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa 525lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV 526HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB 527gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt 5282q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7 529dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ== 530-----END CERTIFICATE-----</pre></div> 531</td></tr></table> 532</td> 533</tr></table> 534</td></tr></table> 535</div> 536<h3><a name="ToC7">Certificate Authorities</a></h3> 537By first verifying the information in a certificate request before granting 538the certificate, the Certificate Authority assures the identity of the private 539key owner of a key-pair. For instance, if Alice requests a personal 540certificate, the Certificate Authority must first make sure that Alice really 541is the person the certificate request claims. 542<h4><a name="ToC8">Certificate Chains</a></h4> 543A Certificate Authority may also issue a certificate for another Certificate 544Authority. When examining a certificate, Alice may need to examine the 545certificate of the issuer, for each parent Certificate Authority, until 546reaching one which she has confidence in. She may decide to trust only 547certificates with a limited chain of issuers, to reduce her risk of a "bad" 548certificate in the chain. 549<h4><a name="ToC9">Creating a Root-Level CA</a></h4> 550As noted earlier, each certificate requires an issuer to assert the validity 551of the identity of the certificate subject, up to the top-level Certificate 552Authority (CA). This presents a problem: Since this is who vouches for the 553certificate of the top-level authority, which has no issuer? 554In this unique case, the certificate is "self-signed", so the issuer of the 555certificate is the same as the subject. As a result, one must exercise extra 556care in trusting a self-signed certificate. The wide publication of a public 557key by the root authority reduces the risk in trusting this key -- it would be 558obvious if someone else publicized a key claiming to be the authority. 559Browsers are preconfigured to trust well-known certificate authorities. 560<p> 561A number of companies, such as <a href="http://www.thawte.com/">Thawte</a> and 562<a href="http://www.verisign.com/">VeriSign</a> have established themselves as 563Certificate Authorities. These companies provide the following services: 564<ul> 565<li>Verifying certificate requests 566<li>Processing certificate requests 567<li>Issuing and managing certificates 568</ul> 569<p> 570It is also possible to create your own Certificate Authority. Although risky 571in the Internet environment, it may be useful within an Intranet where the 572organization can easily verify the identities of individuals and servers. 573<h4><a name="ToC10">Certificate Management</a></h4> 574Establishing a Certificate Authority is a responsibility which requires a 575solid administrative, technical, and management framework. 576Certificate Authorities not only issue certificates, they also manage them -- 577that is, they determine how long certificates are valid, they renew them, and 578they keep lists of certificates that have already been issued but are no 579longer valid (Certificate Revocation Lists, or CRLs). 580Say Alice is entitled to a certificate as an employee of a company. Say too, 581that the certificate needs to be revoked when Alice leaves the company. Since 582certificates are objects that get passed around, it is impossible to tell from 583the certificate alone that it has been revoked. 584When examining certificates for validity, therefore, it is necessary to 585contact the issuing Certificate Authority to check CRLs -- this is not usually 586an automated part of the process. 587<p> 588<div align="center"><B>Note:</B></div> 589If you use a Certificate Authority that is not configured into browsers by 590default, it is necessary to load the Certificate Authority certificate into 591the browser, enabling the browser to validate server certificates signed by 592that Certificate Authority. Doing so may be dangerous, since once loaded, the 593browser will accept all certificates signed by that Certificate Authority. 594<h2><a name="ToC11">Secure Sockets Layer (SSL)</a></h2> 595The Secure Sockets Layer protocol is a protocol layer which may be placed 596between a reliable connection-oriented network layer protocol (e.g. TCP/IP) 597and the application protocol layer (e.g. HTTP). SSL provides for secure 598communication between client and server by allowing mutual authentication, the 599use of digital signatures for integrity, and encryption for privacy. 600<p> 601The protocol is designed to support a range of choices for specific algorithms 602used for cryptography, digests, and signatures. This allows algorithm 603selection for specific servers to be made based on legal, export or other 604concerns, and also enables the protocol to take advantage of new algorithms. 605Choices are negotiated between client and server at the start of establishing 606a protocol session. 607<p> 608<div align="center"> 609<a name="table4"></a> 610<table width="600" cellspacing="0" cellpadding="1" border="0" summary=""> 611<caption align="bottom" id="sf">Table 4: Versions of the SSL protocol</caption> 612<tr><td bgcolor="#cccccc"> 613<table width="598" cellpadding="5" cellspacing="0" border="0" summary=""> 614<tr><td valign="top" align="center" bgcolor="#ffffff"> 615<table summary=""> 616<tr valign="top"> 617<td><b>Version:</b></td> 618<td><b>Source:</b></td> 619<td><b>Description:</b></td> 620<td><b>Browser Support:</b></td> 621</tr> 622<tr valign="top"> 623<td>SSL v2.0</td> 624<td>Vendor Standard (from Netscape Corp.) [<a href="#SSL2">SSL2</a>]</td> 625<td>First SSL protocol for which implementations exists</td> 626<td>- NS Navigator 1.x/2.x<br> 627 - MS IE 3.x<br> 628 - Lynx/2.8+OpenSSL 629</td> 630</tr> 631<tr valign="top"> 632<td>SSL v3.0</td> 633<td>Expired Internet Draft (from Netscape Corp.) [<a href="#SSL3">SSL3</a>]</td> 634<td>Revisions to prevent specific security attacks, add non-RSA ciphers, and support for certificate chains</td> 635<td>- NS Navigator 2.x/3.x/4.x<br> 636 - MS IE 3.x/4.x<br> 637 - Lynx/2.8+OpenSSL 638</td> 639</tr> 640<tr valign="top"> 641<td>TLS v1.0</td> 642<td>Proposed Internet Standard (from IETF) [<a href="#TLS1">TLS1</a>]</td> 643<td>Revision of SSL 3.0 to update the MAC layer to HMAC, add block padding for 644 block ciphers, message order standardization and more alert messages. 645</td> 646<td>- Lynx/2.8+OpenSSL</td> 647</table> 648</td> 649</tr></table> 650</td></tr></table> 651</div> 652<p> 653There are a number of versions of the SSL protocol, as shown in <a 654href="#table4">Table 4</a>. As noted there, one of the benefits in SSL 3.0 is 655that it adds support of certificate chain loading. This feature allows a 656server to pass a server certificate along with issuer certificates to the 657browser. Chain loading also permits the browser to validate the server 658certificate, even if Certificate Authority certificates are not installed for 659the intermediate issuers, since they are included in the certificate chain. 660SSL 3.0 is the basis for the Transport Layer Security [<A 661HREF="#TLS1">TLS</A>] protocol standard, currently in development by the 662Internet Engineering Task Force (IETF). 663<h3><a name="ToC12">Session Establishment</a></h3> 664The SSL session is established by following a <I>handshake sequence</I> 665between client and server, as shown in <a href="#figure1">Figure 1</a>. This 666sequence may vary, depending on whether the server is configured to provide a 667server certificate or request a client certificate. Though cases exist where 668additional handshake steps are required for management of cipher information, 669this article summarizes one common scenario: see the SSL specification for the 670full range of possibilities. 671<p> 672<div align="center"><b>Note</b></div> 673Once an SSL session has been established it may be reused, thus avoiding the 674performance penalty of repeating the many steps needed to start a session. 675For this the server assigns each SSL session a unique session identifier which 676is cached in the server and which the client can use on forthcoming 677connections to reduce the handshake (until the session identifer expires in 678the cache of the server). 679<p> 680<div align="center"> 681<a name="figure1"></a> 682<table width="600" cellspacing="0" cellpadding="1" border="0" summary=""> 683<caption align="bottom" id="sf">Figure 1: Simplified SSL Handshake Sequence</caption> 684<tr><td bgcolor="#cccccc"> 685<table width="598" cellpadding="5" cellspacing="0" border="0" summary=""> 686<tr><td valign="top" align="center" bgcolor="#ffffff"> 687<img src="ssl_intro_fig1.gif" alt="" width="423" height="327"> 688</td> 689</tr></table> 690</td></tr></table> 691</div> 692<p> 693The elements of the handshake sequence, as used by the client and server, are 694listed below: 695<ol> 696<li>Negotiate the Cipher Suite to be used during data transfer 697<li>Establish and share a session key between client and server 698<li>Optionally authenticate the server to the client 699<li>Optionally authenticate the client to the server 700</ol> 701<p> 702The first step, Cipher Suite Negotiation, allows the client and server to 703choose a Cipher Suite supportable by both of them. The SSL3.0 protocol 704specification defines 31 Cipher Suites. A Cipher Suite is defined by the 705following components: 706<ul> 707<li>Key Exchange Method 708<li>Cipher for Data Transfer 709<li>Message Digest for creating the Message Authentication Code (MAC) 710</ul> 711These three elements are described in the sections that follow. 712<h3><a name="ToC13">Key Exchange Method</a></h3> 713The key exchange method defines how the shared secret symmetric cryptography 714key used for application data transfer will be agreed upon by client and 715server. SSL 2.0 uses RSA key exchange only, while SSL 3.0 supports a choice of 716key exchange algorithms including the RSA key exchange when certificates are 717used, and Diffie-Hellman key exchange for exchanging keys without certificates 718and without prior communication between client and server. 719<p> 720One variable in the choice of key exchange methods is digital signatures -- 721whether or not to use them, and if so, what kind of signatures to use. 722Signing with a private key provides assurance against a 723man-in-the-middle-attack during the information exchange used in generating 724the shared key [<a href="#AC96">AC96</a>, p516]. 725<h3><a name="ToC14">Cipher for Data Transfer</a></h3> 726SSL uses the conventional cryptography algorithm (symmetric cryptography) 727described earlier for encrypting messages in a session. There are nine 728choices, including the choice to perform no encryption: 729<ul> 730<li>No encryption 731<li>Stream Ciphers 732 <ul> 733 <li>RC4 with 40-bit keys 734 <li>RC4 with 128-bit keys 735 </ul> 736<li>CBC Block Ciphers 737 <ul> 738 <li>RC2 with 40 bit key 739 <li>DES with 40 bit key 740 <li>DES with 56 bit key 741 <li>Triple-DES with 168 bit key 742 <li>Idea (128 bit key) 743 <li>Fortezza (96 bit key) 744 </ul> 745</ul> 746Here "CBC" refers to Cipher Block Chaining, which means that a portion of the 747previously encrypted cipher text is used in the encryption of the current 748block. "DES" refers to the Data Encryption Standard [<a href="#AC96">AC96</a>, 749ch12], which has a number of variants (including DES40 and 3DES_EDE). "Idea" 750is one of the best and cryptographically strongest available algorithms, and 751"RC2" is a proprietary algorithm from RSA DSI [<a href="#AC96">AC96</a>, 752ch13]. 753<h3><a name="ToC15">Digest Function</a></h3> 754The choice of digest function determines how a digest is created from a record 755unit. SSL supports the following: 756<ul> 757<li>No digest (Null choice) 758<li>MD5, a 128-bit hash 759<li>Secure Hash Algorithm (SHA-1), a 160-bit hash 760</ul> 761The message digest is used to create a Message Authentication Code (MAC) which 762is encrypted with the message to provide integrity and to prevent against 763replay attacks. 764<h3><a name="ToC16">Handshake Sequence Protocol</a></h3> 765The handshake sequence uses three protocols: 766<ul> 767<li>The <em>SSL Handshake Protocol</em> 768 for performing the client and server SSL session establishment. 769<li>The <em>SSL Change Cipher Spec Protocol</em> for actually establishing agreement 770 on the Cipher Suite for the session. 771<li>The <em>SSL Alert Protocol</em> for 772 conveying SSL error messages between client and server. 773</ul> 774These protocols, as well as application protocol data, are encapsulated in the 775<em>SSL Record Protocol</em>, as shown in <a href="#figure2">Figure 2</a>. An 776encapsulated protocol is transferred as data by the lower layer protocol, 777which does not examine the data. The encapsulated protocol has no knowledge of 778the underlying protocol. 779<p> 780<div align="center"> 781<a name="figure2"></a> 782<table width="600" cellspacing="0" cellpadding="1" border="0" summary=""> 783<caption align="bottom" id="sf">Figure 2: SSL Protocol Stack</caption> 784<tr><td bgcolor="#cccccc"> 785<table width="598" cellpadding="5" cellspacing="0" border="0" summary=""> 786<tr><td valign="top" align="center" bgcolor="#ffffff"> 787<img src="ssl_intro_fig2.gif" alt="" width="428" height="217"> 788</td> 789</tr></table> 790</td></tr></table> 791</div> 792<p> 793The encapsulation of SSL control protocols by the record protocol means that 794if an active session is renegotiated the control protocols will be transmitted 795securely. If there were no session before, then the Null cipher suite is 796used, which means there is no encryption and messages have no integrity 797digests until the session has been established. 798<h3><a name="ToC17">Data Transfer</a></h3> 799The SSL Record Protocol, shown in <a href="#figure3">Figure 3</a>, is used to 800transfer application and SSL Control data between the client and server, 801possibly fragmenting this data into smaller units, or combining multiple 802higher level protocol data messages into single units. It may compress, attach 803digest signatures, and encrypt these units before transmitting them using the 804underlying reliable transport protocol (Note: currently all major SSL 805implementations lack support for compression). 806<p> 807<div align="center"> 808<a name="figure3"></a> 809<table width="600" cellspacing="0" cellpadding="1" border="0" summary=""> 810<caption align="bottom" id="sf">Figure 3: SSL Record Protocol</caption> 811<tr><td bgcolor="#cccccc"> 812<table width="598" cellpadding="5" cellspacing="0" border="0" summary=""> 813<tr><td valign="top" align="center" bgcolor="#ffffff"> 814<img src="ssl_intro_fig3.gif" alt="" width="423" height="323"> 815</td> 816</tr></table> 817</td></tr></table> 818</div> 819<h3><a name="ToC18">Securing HTTP Communication</a></h3> 820One common use of SSL is to secure Web HTTP communication between a browser 821and a webserver. This case does not preclude the use of non-secured HTTP. The 822secure version is mainly plain HTTP over SSL (named HTTPS), but with one major 823difference: it uses the URL scheme <code>https</code> rather than 824<code>http</code> and a different server port (by default 443). This mainly 825is what mod_ssl provides to you for the Apache webserver... 826<h2><a name="ToC19">References</a></h2> 827<ul> 828<p> 829<li><a name="AC96"></a> 830[AC96] Bruce Schneier, <em>Applied Cryptography</em>, 2nd Edition, Wiley, 831 1996. See <a href="http://www.counterpane.com/">http://www.counterpane.com/</a> for 832 various other materials by Bruce Schneier. 833<p> 834<li><a name="X208"></a> 835[X208] ITU-T Recommendation X.208, <em>Specification of Abstract Syntax Notation 836 One (ASN.1)</em>, 1988. See for instance <a 837 href="ftp://ftp.neda.com/pub/itu/x.series/x208.ps"> 838 ftp://ftp.neda.com/pub/itu/x.series/x208.ps</a>. 839<p> 840<li><a name="X509"></a> 841[X509] ITU-T Recommendation X.509, <em>The Directory - Authentication 842 Framework</em>, 1988. See for instance <a 843 href="ftp://ftp.bull.com/pub/OSIdirectory/ITUnov96/X.509/97x509final.doc"> 844 ftp://ftp.bull.com/pub/OSIdirectory/ITUnov96/X.509/97x509final.doc</a>. 845<p> 846<li><a name="PKCS"></a> 847[PKCS] Kaliski, Burton S., Jr., <em>An Overview of the PKCS Standards</em>, An RSA 848 Laboratories Technical Note, revised November 1, 1993. 849 See <a href="http://www.rsa.com/rsalabs/pubs/PKCS/"> 850 http://www.rsa.com/rsalabs/pubs/PKCS/</a>. 851<p> 852<li><a name="MIME"></a> 853[MIME] N. Freed, N. Borenstein, <em>Multipurpose Internet Mail Extensions 854 (MIME) Part One: Format of Internet Message Bodies</em>, RFC2045. 855 See for instance <a href="ftp://ftp.isi.edu/in-notes/rfc2045.txt"> 856 ftp://ftp.isi.edu/in-notes/rfc2045.txt</a>. 857<p> 858<li><a name="SSL2"></a> 859[SSL2] Kipp E.B. Hickman, <em>The SSL Protocol</em>, 1995. 860 See <a href="http://www.netscape.com/eng/security/SSL_2.html"> 861 http://www.netscape.com/eng/security/SSL_2.html</a>. 862<p> 863<li><a name="SSL3"></a> 864[SSL3] Alan O. Freier, Philip Karlton, Paul C. Kocher, <em>The SSL Protocol 865 Version 3.0</em>, 1996. See <a 866 href="http://www.netscape.com/eng/ssl3/draft302.txt"> 867 http://www.netscape.com/eng/ssl3/draft302.txt</a>. 868<p> 869<li><a name="TLS1"></a> 870[TLS1] Tim Dierks, Christopher Allen, <em>The TLS Protocol Version 1.0</em>, 871 1997. See <a 872 href="ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-protocol-06.txt"> 873 ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-protocol-06.txt</a>. 874</ul> 875 <p> 876 <br> 877 <table summary=""> 878 <tr> 879 <td> 880 <table width="600" border="0" summary=""> 881 <tr> 882 <td valign="top" align="left" width="250"> 883<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> 884 </td> 885 <td valign="top" align="right" width="250"> 886<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> 887 </td> 888 </tr> 889 </table> 890 </td> 891 </tr> 892 <tr> 893 <td><img src="ssl_template.imgdot-1x1-000000.gif" alt="" width="600" height="2" align="bottom" border="0"></td> 894 </tr> 895 <tr> 896 <td><table width="598" summary=""> 897 <tr> 898 <td align="left"><font face="Arial,Helvetica"> 899 <a href="http://www.modssl.org/">mod_ssl</a> 2.8, User Manual<br> 900 The Apache Interface to OpenSSL 901 </font> 902 </td> 903 <td align="right"><font face="Arial,Helvetica"> 904 Copyright © 1998-2001 905 <a href="http://www.engelschall.com/">Ralf S. Engelschall</a><br> 906 All Rights Reserved<br> 907 </font> 908 </td> 909 </tr> 910 </table> 911 </td> 912 </tr> 913 </table> 914 </td> 915</tr> 916</table> 917</div> 918</body> 919</html> 920
