github.com/krum110487/go-htaccess@v0.0.0-20240316004156-60641c8e7598/tests/data/apache_2_2_34/manual/ssl/ssl_intro.html.en (about) 1 <?xml version="1.0" encoding="ISO-8859-1"?> 2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 3 <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head> 4 <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type" /> 5 <!-- 6 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 7 This file is generated from xml source: DO NOT EDIT 8 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 9 --> 10 <title>SSL/TLS Strong Encryption: An Introduction - Apache HTTP Server Version 2.2</title> 11 <link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" /> 12 <link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" /> 13 <link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link rel="stylesheet" type="text/css" href="../style/css/prettify.css" /> 14 <script src="../style/scripts/prettify.min.js" type="text/javascript"> 15 </script> 16 17 <link href="../images/favicon.ico" rel="shortcut icon" /><link href="http://httpd.apache.org/docs/current/ssl/ssl_intro.html" rel="canonical" /></head> 18 <body id="manual-page"><div id="page-header"> 19 <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p> 20 <p class="apache">Apache HTTP Server Version 2.2</p> 21 <img alt="" src="../images/feather.gif" /></div> 22 <div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div> 23 <div id="path"> 24 <a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.2</a> > <a href="./">SSL/TLS</a></div><div id="page-content"><div class="retired"><h4>Please note</h4> 25 <p> This document refers to a legacy release (<strong>2.2</strong>) of Apache httpd. The active release (<strong>2.4</strong>) is documented <a href="http://httpd.apache.org/docs/current">here</a>. If you have not already upgraded, please follow <a href="http://httpd.apache.org/docs/current/upgrading.html">this link</a> for more information.</p> 26 <p>You may follow <a href="http://httpd.apache.org/docs/current/ssl/ssl_intro.html">this link</a> to go to the current version of this document.</p></div><div id="preamble"><h1>SSL/TLS Strong Encryption: An Introduction</h1> 27 <div class="toplang"> 28 <p><span>Available Languages: </span><a href="../en/ssl/ssl_intro.html" title="English"> en </a> | 29 <a href="../ja/ssl/ssl_intro.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a></p> 30 </div> 31 32 <blockquote> 33 <p>The nice thing about standards is that there are so many to choose 34 from. And if you really don't like all the standards you just have to 35 wait another year until the one arises you are looking for.</p> 36 37 <p class="cite">-- <cite>A. Tanenbaum</cite>, "Introduction to 38 Computer Networks"</p> 39 </blockquote> 40 41 <p>As an introduction this chapter is aimed at readers who are familiar 42 with the Web, HTTP, and Apache, but are not security experts. It is not 43 intended to be a definitive guide to the SSL protocol, nor does it discuss 44 specific techniques for managing certificates in an organization, or the 45 important legal issues of patents and import and export restrictions. 46 Rather, it is intended to provide a common background to <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> users by pulling together various concepts, definitions, 47 and examples as a starting point for further exploration.</p> 48 49 <p>The presented content is mainly derived, with the author's permission, 50 from the article <a href="http://home.comcast.net/~fjhirsch/Papers/wwwj/">Introducing 51 SSL and Certificates using SSLeay</a> by <a href="http://home.comcast.net/~fjhirsch/">Frederick J. Hirsch</a>, of The 52 Open Group Research Institute, which was published in <a href="http://www.ora.com/catalog/wjsum97/">Web Security: A Matter of 53 Trust</a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997. 54 Please send any positive feedback to <a href="mailto:hirsch@fjhirsch.com">Frederick Hirsch</a> (the original 55 article author) and all negative feedback to <a href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> (the 56 <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> author).</p> 57 </div> 58 <div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#cryptographictech">Cryptographic Techniques</a></li> 59 <li><img alt="" src="../images/down.gif" /> <a href="#certificates">Certificates</a></li> 60 <li><img alt="" src="../images/down.gif" /> <a href="#ssl">Secure Sockets Layer (SSL)</a></li> 61 <li><img alt="" src="../images/down.gif" /> <a href="#references">References</a></li> 62 </ul><ul class="seealso"><li><a href="#comments_section">Comments</a></li></ul></div> 63 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> 64 <div class="section"> 65 <h2><a name="cryptographictech" id="cryptographictech">Cryptographic Techniques</a></h2> 66 67 <p>Understanding SSL requires an understanding of cryptographic 68 algorithms, message digest functions (aka. one-way or hash functions), and 69 digital signatures. These techniques are the subject of entire books (see 70 for instance [<a href="#AC96">AC96</a>]) and provide the basis for privacy, 71 integrity, and authentication.</p> 72 73 <h3><a name="cryptographicalgo" id="cryptographicalgo">Cryptographic Algorithms</a></h3> 74 75 <p>Suppose Alice wants to send a message to her bank to transfer some 76 money. Alice would like the message to be private, since it will 77 include information such as her account number and transfer amount. One 78 solution is to use a cryptographic algorithm, a technique that would 79 transform her message into an encrypted form, unreadable until it is 80 decrypted. Once in this form, the message can only be 81 decrypted by using a secret key. Without the key the message is useless: 82 good cryptographic algorithms make it so difficult 83 for intruders to decode the original text that it isn't worth their 84 effort.</p> 85 86 <p>There are two categories of cryptographic algorithms: conventional 87 and public key.</p> 88 89 <dl> 90 <dt>Conventional cryptography</dt> 91 <dd>also known as symmetric cryptography, requires the sender and 92 receiver to share a key: a secret piece of information that may be 93 used to encrypt or decrypt a message. As long as this key is kept 94 secret, nobody other than the sender or recipient can read the message. 95 If Alice and the bank know a secret key, then they can send each other 96 private messages. The task of sharing a key between sender and recipient 97 before communicating, while also keeping it secret from others, can be 98 problematic.</dd> 99 100 <dt>Public key cryptography</dt> 101 <dd>also known as asymmetric cryptography, solves the key exchange 102 problem by defining an algorithm which uses two keys, each of which 103 may be used to encrypt a message. If one key is used to encrypt a 104 message then the other must be used to decrypt it. This makes it 105 possible to receive secure messages by simply publishing one key 106 (the public key) and keeping the other secret (the private key).</dd> 107 </dl> 108 109 <p>Anyone can encrypt a message using the public key, but only the 110 owner of the private key will be able to read it. In this way, Alice 111 can send private messages to the owner of a key-pair (the bank), by 112 encrypting them using their public key. Only the bank will be able to 113 decrypt them.</p> 114 115 116 <h3><a name="messagedigests" id="messagedigests">Message Digests</a></h3> 117 118 <p>Although Alice may encrypt her message to make it private, there 119 is still a concern that someone might modify her original message or 120 substitute it with a different one, in order to transfer the money 121 to themselves, for instance. One way of guaranteeing the integrity 122 of Alice's message is for her to create a concise summary of her 123 message and send this to the bank as well. Upon receipt of the message, 124 the bank creates its own summary and compares it with the one Alice 125 sent. If the summaries are the same then the message has been received 126 intact.</p> 127 128 <p>A summary such as this is called a <dfn>message digest</dfn>, <em>one-way 129 function</em> or <em>hash function</em>. Message digests are used to create 130 a short, fixed-length representation of a longer, variable-length message. 131 Digest algorithms are designed to produce a unique digest for each 132 message. Message digests are designed to make it impractically difficult 133 to determine the message from the digest and (in theory) impossible to 134 find two different messages which create the same digest -- thus 135 eliminating the possibility of substituting one message for another while 136 maintaining the same digest.</p> 137 138 <p>Another challenge that Alice faces is finding a way to send the digest 139 to the bank securely; if the digest is not sent securely, its integrity may 140 be compromised and with it the possibility for the bank to determine the 141 integrity of the original message. Only if the digest is sent securely can 142 the integrity of the associated message be determined.</p> 143 144 <p>One way to send the digest securely is to include it in a digital 145 signature.</p> 146 147 148 <h3><a name="digitalsignatures" id="digitalsignatures">Digital Signatures</a></h3> 149 <p>When Alice sends a message to the bank, the bank needs to ensure that the 150 message is really from her, so an intruder cannot request a transaction 151 involving her account. A <em>digital signature</em>, created by Alice and 152 included with the message, serves this purpose.</p> 153 154 <p>Digital signatures are created by encrypting a digest of the message and 155 other information (such as a sequence number) with the sender's private key. 156 Though anyone can <em>decrypt</em> the signature using the public key, only the 157 sender knows the private key. This means that only the sender can have signed 158 the message. Including the digest in the signature means the signature is only 159 good for that message; it also ensures the integrity of the message since no one 160 can change the digest and still sign it.</p> 161 <p>To guard against interception and reuse of the signature by an intruder at a 162 later date, the signature contains a unique sequence number. This protects 163 the bank from a fraudulent claim from Alice that she did not send the message 164 -- only she could have signed it (non-repudiation).</p> 165 166 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> 167 <div class="section"> 168 <h2><a name="certificates" id="certificates">Certificates</a></h2> 169 170 <p>Although Alice could have sent a private message to the bank, signed 171 it and ensured the integrity of the message, she still needs to be sure 172 that she is really communicating with the bank. This means that she needs 173 to be sure that the public key she is using is part of the bank's key-pair, 174 and not an intruder's. Similarly, the bank needs to verify that the message 175 signature really was signed by the private key that belongs to Alice.</p> 176 177 <p>If each party has a certificate which validates the other's identity, 178 confirms the public key and is signed by a trusted agency, then both 179 can be assured that they are communicating with whom they think they are. 180 Such a trusted agency is called a <em>Certificate Authority</em> and 181 certificates are used for authentication.</p> 182 183 <h3><a name="certificatecontents" id="certificatecontents">Certificate Contents</a></h3> 184 185 <p>A certificate associates a public key with the real identity of 186 an individual, server, or other entity, known as the subject. As 187 shown in <a href="#table1">Table 1</a>, information about the subject 188 includes identifying information (the distinguished name) and the 189 public key. It also includes the identification and signature of the 190 Certificate Authority that issued the certificate and the period of 191 time during which the certificate is valid. It may have additional 192 information (or extensions) as well as administrative information 193 for the Certificate Authority's use, such as a serial number.</p> 194 195 <h4><a name="table1" id="table1">Table 1: Certificate Information</a></h4> 196 197 <table> 198 199 <tr><th>Subject</th> 200 <td>Distinguished Name, Public Key</td></tr> 201 <tr><th>Issuer</th> 202 <td>Distinguished Name, Signature</td></tr> 203 <tr><th>Period of Validity</th> 204 <td>Not Before Date, Not After Date</td></tr> 205 <tr><th>Administrative Information</th> 206 <td>Version, Serial Number</td></tr> 207 <tr><th>Extended Information</th> 208 <td>Basic Constraints, Netscape Flags, etc.</td></tr> 209 </table> 210 211 212 <p>A distinguished name is used to provide an identity in a specific 213 context -- for instance, an individual might have a personal 214 certificate as well as one for their identity as an employee. 215 Distinguished names are defined by the X.509 standard [<a href="#X509">X509</a>], which defines the fields, field names and 216 abbreviations used to refer to the fields (see <a href="#table2">Table 217 2</a>).</p> 218 219 <h4><a name="table2" id="table2">Table 2: Distinguished Name Information</a></h4> 220 221 <table class="bordered"> 222 223 <tr><th>DN Field</th> 224 <th>Abbrev.</th> 225 <th>Description</th> 226 <th>Example</th></tr> 227 <tr><td>Common Name</td> 228 <td>CN</td> 229 <td>Name being certified</td> 230 <td>CN=Joe Average</td></tr> 231 <tr><td>Organization or Company</td> 232 <td>O</td> 233 <td>Name is associated with this<br />organization</td> 234 <td>O=Snake Oil, Ltd.</td></tr> 235 <tr><td>Organizational Unit</td> 236 <td>OU</td> 237 <td>Name is associated with this <br />organization unit, such 238 as a department</td> 239 <td>OU=Research Institute</td></tr> 240 <tr><td>City/Locality</td> 241 <td>L</td> 242 <td>Name is located in this City</td> 243 <td>L=Snake City</td></tr> 244 <tr><td>State/Province</td> 245 <td>ST</td> 246 <td>Name is located in this State/Province</td> 247 <td>ST=Desert</td></tr> 248 <tr><td>Country</td> 249 <td>C</td> 250 <td>Name is located in this Country (ISO code)</td> 251 <td>C=XZ</td></tr> 252 </table> 253 254 255 <p>A Certificate Authority may define a policy specifying which 256 distinguished field names are optional and which are required. It 257 may also place requirements upon the field contents, as may users of 258 certificates. For example, a Netscape browser requires that the 259 Common Name for a certificate representing a server matches a wildcard 260 pattern for the domain name of that server, such 261 as <code>*.snakeoil.com</code>.</p> 262 263 <p>The binary format of a certificate is defined using the ASN.1 264 notation [<a href="#X208">X208</a>] [<a href="#PKCS">PKCS</a>]. This 265 notation defines how to specify the contents and encoding rules 266 define how this information is translated into binary form. The binary 267 encoding of the certificate is defined using Distinguished Encoding 268 Rules (DER), which are based on the more general Basic Encoding Rules 269 (BER). For those transmissions which cannot handle binary, the binary 270 form may be translated into an ASCII form by using Base64 encoding 271 [<a href="#MIME">MIME</a>]. When placed between begin and end delimiter 272 lines (as below), this encoded version is called a PEM ("Privacy Enhanced 273 Mail") encoded certificate.</p> 274 275 <div class="example"><h3>Example of a PEM-encoded certificate (snakeoil.crt)</h3><pre>-----BEGIN CERTIFICATE----- 276 MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx 277 FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG 278 A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv 279 cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz 280 bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL 281 MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h 282 a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl 283 cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN 284 AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB 285 gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b 286 vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa 287 lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV 288 HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB 289 gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt 290 2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7 291 dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ== 292 -----END CERTIFICATE-----</pre></div> 293 294 295 <h3><a name="certificateauthorities" id="certificateauthorities">Certificate Authorities</a></h3> 296 297 <p>By verifying the information in a certificate request 298 before granting the certificate, the Certificate Authority assures 299 itself of the identity of the private key owner of a key-pair. 300 For instance, if Alice requests a personal certificate, the 301 Certificate Authority must first make sure that Alice really is the 302 person the certificate request claims she is.</p> 303 304 <h4><a name="certificatechains" id="certificatechains">Certificate Chains</a></h4> 305 306 <p>A Certificate Authority may also issue a certificate for 307 another Certificate Authority. When examining a certificate, 308 Alice may need to examine the certificate of the issuer, for each 309 parent Certificate Authority, until reaching one which she has 310 confidence in. She may decide to trust only certificates with a 311 limited chain of issuers, to reduce her risk of a "bad" certificate 312 in the chain.</p> 313 314 315 <h4><a name="rootlevelca" id="rootlevelca">Creating a Root-Level CA</a></h4> 316 317 <p>As noted earlier, each certificate requires an issuer to assert 318 the validity of the identity of the certificate subject, up to 319 the top-level Certificate Authority (CA). This presents a problem: 320 who can vouch for the certificate of the top-level 321 authority, which has no issuer? In this unique case, the 322 certificate is "self-signed", so the issuer of the certificate is 323 the same as the subject. Browsers are preconfigured to trust well-known 324 certificate authorities, but it is important to exercise extra care in 325 trusting a self-signed certificate. The wide publication of a 326 public key by the root authority reduces the risk in trusting this 327 key -- it would be obvious if someone else publicized a key 328 claiming to be the authority.</p> 329 330 <p>A number of companies, such as <a href="http://www.thawte.com/">Thawte</a> and <a href="http://www.verisign.com/">VeriSign</a> 331 have established themselves as Certificate Authorities. These 332 companies provide the following services:</p> 333 334 <ul> 335 <li>Verifying certificate requests</li> 336 <li>Processing certificate requests</li> 337 <li>Issuing and managing certificates</li> 338 </ul> 339 340 <p>It is also possible to create your own Certificate Authority. 341 Although risky in the Internet environment, it may be useful 342 within an Intranet where the organization can easily verify the 343 identities of individuals and servers.</p> 344 345 346 <h4><a name="certificatemanagement" id="certificatemanagement">Certificate Management</a></h4> 347 348 <p>Establishing a Certificate Authority is a responsibility which 349 requires a solid administrative, technical and management 350 framework. Certificate Authorities not only issue certificates, 351 they also manage them -- that is, they determine for how long 352 certificates remain valid, they renew them and keep lists of 353 certificates that were issued in the past but are no longer valid 354 (Certificate Revocation Lists, or CRLs).</p> 355 356 <p>For example, if Alice is entitled to a certificate as an 357 employee of a company but has now left 358 that company, her certificate may need to be revoked. 359 Because certificates are only issued after the subject's identity has 360 been verified and can then be passed around to all those with whom 361 the subject may communicate, it is impossible to tell from the 362 certificate alone that it has been revoked. 363 Therefore when examining certificates for validity 364 it is necessary to contact the issuing Certificate Authority to 365 check CRLs -- this is usually not an automated part of the process.</p> 366 367 <div class="note"><h3>Note</h3> 368 <p>If you use a Certificate Authority that browsers are not configured 369 to trust by default, it is necessary to load the Certificate 370 Authority certificate into the browser, enabling the browser to 371 validate server certificates signed by that Certificate Authority. 372 Doing so may be dangerous, since once loaded, the browser will 373 accept all certificates signed by that Certificate Authority.</p> 374 </div> 375 376 377 378 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> 379 <div class="section"> 380 <h2><a name="ssl" id="ssl">Secure Sockets Layer (SSL)</a></h2> 381 382 <p>The Secure Sockets Layer protocol is a protocol layer which may be 383 placed between a reliable connection-oriented network layer protocol 384 (e.g. TCP/IP) and the application protocol layer (e.g. HTTP). SSL provides 385 for secure communication between client and server by allowing mutual 386 authentication, the use of digital signatures for integrity and encryption 387 for privacy.</p> 388 389 <p>The protocol is designed to support a range of choices for specific 390 algorithms used for cryptography, digests and signatures. This allows 391 algorithm selection for specific servers to be made based on legal, export 392 or other concerns and also enables the protocol to take advantage of new 393 algorithms. Choices are negotiated between client and server when 394 establishing a protocol session.</p> 395 396 <h3><a name="table4" id="table4">Table 4: Versions of the SSL protocol</a></h3> 397 398 <table class="bordered"> 399 400 <tr><th>Version</th> 401 <th>Source</th> 402 <th>Description</th> 403 <th>Browser Support</th></tr> 404 <tr><td>SSL v2.0</td> 405 <td>Vendor Standard (from Netscape Corp.) [<a href="#SSL2">SSL2</a>]</td> 406 <td>First SSL protocol for which implementations exist</td> 407 <td>- NS Navigator 1.x/2.x<br /> 408 - MS IE 3.x<br /> 409 - Lynx/2.8+OpenSSL</td></tr> 410 <tr><td>SSL v3.0</td> 411 <td>Expired Internet Draft (from Netscape Corp.) [<a href="#SSL3">SSL3</a>]</td> 412 <td>Revisions to prevent specific security attacks, add non-RSA 413 ciphers and support for certificate chains</td> 414 <td>- NS Navigator 2.x/3.x/4.x<br /> 415 - MS IE 3.x/4.x<br /> 416 - Lynx/2.8+OpenSSL</td></tr> 417 <tr><td>TLS v1.0</td> 418 <td>Proposed Internet Standard (from IETF) [<a href="#TLS1">TLS1</a>]</td> 419 <td>Revision of SSL 3.0 to update the MAC layer to HMAC, add block 420 padding for block ciphers, message order standardization and more 421 alert messages.</td> 422 <td>- Lynx/2.8+OpenSSL</td></tr> 423 </table> 424 425 426 <p>There are a number of versions of the SSL protocol, as shown in 427 <a href="#table4">Table 4</a>. As noted there, one of the benefits in 428 SSL 3.0 is that it adds support of certificate chain loading. This feature 429 allows a server to pass a server certificate along with issuer certificates 430 to the browser. Chain loading also permits the browser to validate the 431 server certificate, even if Certificate Authority certificates are not 432 installed for the intermediate issuers, since they are included in the 433 certificate chain. SSL 3.0 is the basis for the Transport Layer Security 434 [<a href="#TLS1">TLS</a>] protocol standard, currently in development by 435 the Internet Engineering Task Force (IETF).</p> 436 437 <h3><a name="session" id="session">Establishing a Session</a></h3> 438 439 <p>The SSL session is established by following a handshake sequence 440 between client and server, as shown in <a href="#figure1">Figure 1</a>. This sequence may vary, depending on whether the server 441 is configured to provide a server certificate or request a client 442 certificate. Although cases exist where additional handshake steps 443 are required for management of cipher information, this article 444 summarizes one common scenario. See the SSL specification for the full 445 range of possibilities.</p> 446 447 <div class="note"><h3>Note</h3> 448 <p>Once an SSL session has been established, it may be reused. This 449 avoids the performance penalty of repeating the many steps needed 450 to start a session. To do this, the server assigns each SSL session a 451 unique session identifier which is cached in the server and which the 452 client can use in future connections to reduce the handshake time 453 (until the session identifer expires from the cache of the server).</p> 454 </div> 455 456 <p class="figure"> 457 <img src="../images/ssl_intro_fig1.gif" alt="" width="423" height="327" /><br /> 458 <a id="figure1" name="figure1"><dfn>Figure 1</dfn></a>: Simplified SSL 459 Handshake Sequence</p> 460 461 <p>The elements of the handshake sequence, as used by the client and 462 server, are listed below:</p> 463 464 <ol> 465 <li>Negotiate the Cipher Suite to be used during data transfer</li> 466 <li>Establish and share a session key between client and server</li> 467 <li>Optionally authenticate the server to the client</li> 468 <li>Optionally authenticate the client to the server</li> 469 </ol> 470 471 <p>The first step, Cipher Suite Negotiation, allows the client and 472 server to choose a Cipher Suite supported by both of them. The SSL3.0 473 protocol specification defines 31 Cipher Suites. A Cipher Suite is 474 defined by the following components:</p> 475 476 <ul> 477 <li>Key Exchange Method</li> 478 <li>Cipher for Data Transfer</li> 479 <li>Message Digest for creating the Message Authentication Code (MAC)</li> 480 </ul> 481 482 <p>These three elements are described in the sections that follow.</p> 483 484 485 <h3><a name="keyexchange" id="keyexchange">Key Exchange Method</a></h3> 486 487 <p>The key exchange method defines how the shared secret symmetric 488 cryptography key used for application data transfer will be agreed 489 upon by client and server. SSL 2.0 uses RSA key exchange only, while 490 SSL 3.0 supports a choice of key exchange algorithms including 491 RSA key exchange (when certificates are used), and Diffie-Hellman key 492 exchange (for exchanging keys without certificates, or without prior 493 communication between client and server).</p> 494 495 <p>One variable in the choice of key exchange methods is digital 496 signatures -- whether or not to use them, and if so, what kind of 497 signatures to use. Signing with a private key provides protection 498 against a man-in-the-middle-attack during the information exchange 499 used to generating the shared key [<a href="#AC96">AC96</a>, p516].</p> 500 501 502 <h3><a name="ciphertransfer" id="ciphertransfer">Cipher for Data Transfer</a></h3> 503 504 <p>SSL uses conventional symmetric cryptography, as described earlier, 505 for encrypting messages in a session. 506 There are nine choices of how to encrypt, including the option not to 507 encrypt:</p> 508 509 <ul> 510 <li>No encryption</li> 511 <li>Stream Ciphers 512 <ul> 513 <li>RC4 with 40-bit keys</li> 514 <li>RC4 with 128-bit keys</li> 515 </ul></li> 516 <li>CBC Block Ciphers 517 <ul><li>RC2 with 40 bit key</li> 518 <li>DES with 40 bit key</li> 519 <li>DES with 56 bit key</li> 520 <li>Triple-DES with 168 bit key</li> 521 <li>Idea (128 bit key)</li> 522 <li>Fortezza (96 bit key)</li> 523 </ul></li> 524 </ul> 525 526 <p>"CBC" refers to Cipher Block Chaining, which means that a 527 portion of the previously encrypted cipher text is used in the 528 encryption of the current block. "DES" refers to the Data Encryption 529 Standard [<a href="#AC96">AC96</a>, ch12], which has a number of 530 variants (including DES40 and 3DES_EDE). "Idea" is currently one of 531 the best and cryptographically strongest algorithms available, 532 and "RC2" is a proprietary algorithm from RSA DSI [<a href="#AC96">AC96</a>, ch13].</p> 533 534 535 <h3><a name="digestfuntion" id="digestfuntion">Digest Function</a></h3> 536 537 <p>The choice of digest function determines how a digest is created 538 from a record unit. SSL supports the following:</p> 539 540 <ul> 541 <li>No digest (Null choice)</li> 542 <li>MD5, a 128-bit hash</li> 543 <li>Secure Hash Algorithm (SHA-1), a 160-bit hash</li> 544 </ul> 545 546 <p>The message digest is used to create a Message Authentication Code 547 (MAC) which is encrypted with the message to verify integrity and to 548 protect against replay attacks.</p> 549 550 551 <h3><a name="handshake" id="handshake">Handshake Sequence Protocol</a></h3> 552 553 <p>The handshake sequence uses three protocols:</p> 554 555 <ul> 556 <li>The <dfn>SSL Handshake Protocol</dfn> 557 for performing the client and server SSL session establishment.</li> 558 <li>The <dfn>SSL Change Cipher Spec Protocol</dfn> for actually 559 establishing agreement on the Cipher Suite for the session.</li> 560 <li>The <dfn>SSL Alert Protocol</dfn> for conveying SSL error 561 messages between client and server.</li> 562 </ul> 563 564 <p>These protocols, as well as application protocol data, are 565 encapsulated in the <dfn>SSL Record Protocol</dfn>, as shown in 566 <a href="#figure2">Figure 2</a>. An encapsulated protocol is 567 transferred as data by the lower layer protocol, which does not 568 examine the data. The encapsulated protocol has no knowledge of the 569 underlying protocol.</p> 570 571 <p class="figure"> 572 <img src="../images/ssl_intro_fig2.gif" alt="" width="428" height="217" /><br /> 573 <a id="figure2" name="figure2"><dfn>Figure 2</dfn></a>: SSL Protocol Stack 574 </p> 575 576 <p>The encapsulation of SSL control protocols by the record protocol 577 means that if an active session is renegotiated the control protocols 578 will be transmitted securely. If there was no previous session, 579 the Null cipher suite is used, which means there will be no encryption and 580 messages will have no integrity digests, until the session has been 581 established.</p> 582 583 584 <h3><a name="datatransfer" id="datatransfer">Data Transfer</a></h3> 585 586 <p>The SSL Record Protocol, shown in <a href="#figure3">Figure 3</a>, 587 is used to transfer application and SSL Control data between the 588 client and server, where necessary fragmenting this data into smaller units, 589 or combining multiple higher level protocol data messages into single 590 units. It may compress, attach digest signatures, and encrypt these 591 units before transmitting them using the underlying reliable transport 592 protocol (Note: currently, no major SSL implementations include support 593 for compression).</p> 594 595 <p class="figure"> 596 <img src="../images/ssl_intro_fig3.gif" alt="" width="423" height="323" /><br /> 597 <a id="figure3" name="figure3"><dfn>Figure 3</dfn></a>: SSL Record Protocol 598 </p> 599 600 601 <h3><a name="securehttp" id="securehttp">Securing HTTP Communication</a></h3> 602 603 <p>One common use of SSL is to secure Web HTTP communication between 604 a browser and a webserver. This does not preclude the use of 605 non-secured HTTP - the secure version (called HTTPS) is the same as 606 plain HTTP over SSL, but uses the URL scheme <code>https</code> 607 rather than <code>http</code>, and a different server port (by default, 608 port 443). This functionality is a large part of what <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> provides for the Apache webserver.</p> 609 610 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> 611 <div class="section"> 612 <h2><a name="references" id="references">References</a></h2> 613 614 <dl> 615 <dt><a id="AC96" name="AC96">[AC96]</a></dt> 616 <dd>Bruce Schneier, <q>Applied Cryptography</q>, 2nd Edition, Wiley, 617 1996. See <a href="http://www.counterpane.com/">http://www.counterpane.com/</a> for various other materials by Bruce 618 Schneier.</dd> 619 620 <dt><a id="X208" name="X208">[X208]</a></dt> 621 <dd>ITU-T Recommendation X.208, <q>Specification of Abstract Syntax Notation 622 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>. 623 </dd> 624 625 <dt><a id="X509" name="X509">[X509]</a></dt> 626 <dd>ITU-T Recommendation X.509, <q>The Directory - Authentication 627 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>. 628 </dd> 629 630 <dt><a id="PKCS" name="PKCS">[PKCS]</a></dt> 631 <dd><q>Public Key Cryptography Standards (PKCS)</q>, 632 RSA Laboratories Technical Notes, See <a href="http://www.rsasecurity.com/rsalabs/pkcs/">http://www.rsasecurity.com/rsalabs/pkcs/</a>.</dd> 633 634 <dt><a id="MIME" name="MIME">[MIME]</a></dt> 635 <dd>N. Freed, N. Borenstein, <q>Multipurpose Internet Mail Extensions 636 (MIME) Part One: Format of Internet Message Bodies</q>, RFC2045. 637 See for instance <a href="http://ietf.org/rfc/rfc2045.txt">http://ietf.org/rfc/rfc2045.txt</a>.</dd> 638 639 <dt><a id="SSL2" name="SSL2">[SSL2]</a></dt> 640 <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> 641 642 <dt><a id="SSL3" name="SSL3">[SSL3]</a></dt> 643 <dd>Alan O. Freier, Philip Karlton, Paul C. Kocher, <q>The SSL Protocol 644 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> 645 646 <dt><a id="TLS1" name="TLS1">[TLS1]</a></dt> 647 <dd>Tim Dierks, Christopher Allen, <q>The TLS Protocol Version 1.0</q>, 648 1999. See <a href="http://ietf.org/rfc/rfc2246.txt">http://ietf.org/rfc/rfc2246.txt</a>.</dd> 649 </dl> 650 </div></div> 651 <div class="bottomlang"> 652 <p><span>Available Languages: </span><a href="../en/ssl/ssl_intro.html" title="English"> en </a> | 653 <a href="../ja/ssl/ssl_intro.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a></p> 654 </div><div class="top"><a href="#page-header"><img src="../images/up.gif" alt="top" /></a></div><div class="section"><h2><a id="comments_section" name="comments_section">Comments</a></h2><div class="warning"><strong>Notice:</strong><br />This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our <a href="http://httpd.apache.org/lists.html">mailing lists</a>.</div> 655 <script type="text/javascript"><!--//--><![CDATA[//><!-- 656 var comments_shortname = 'httpd'; 657 var comments_identifier = 'http://httpd.apache.org/docs/2.2/ssl/ssl_intro.html'; 658 (function(w, d) { 659 if (w.location.hostname.toLowerCase() == "httpd.apache.org") { 660 d.write('<div id="comments_thread"><\/div>'); 661 var s = d.createElement('script'); 662 s.type = 'text/javascript'; 663 s.async = true; 664 s.src = 'https://comments.apache.org/show_comments.lua?site=' + comments_shortname + '&page=' + comments_identifier; 665 (d.getElementsByTagName('head')[0] || d.getElementsByTagName('body')[0]).appendChild(s); 666 } 667 else { 668 d.write('<div id="comments_thread">Comments are disabled for this page at the moment.<\/div>'); 669 } 670 })(window, document); 671 //--><!]]></script></div><div id="footer"> 672 <p class="apache">Copyright 2017 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p> 673 <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div><script type="text/javascript"><!--//--><![CDATA[//><!-- 674 if (typeof(prettyPrint) !== 'undefined') { 675 prettyPrint(); 676 } 677 //--><!]]></script> 678 </body></html>