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