1 <?xml version='1.0' encoding='UTF-8' ?>
2 <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
3 <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
4 <manualpage metafile="ssl_intro.xml.meta">
5 <parentdocument href="./">SSL/TLS</parentdocument>
7 <title>SSL/TLS Strong Encryption: An Introduction</title>
11 <p>The nice thing about standards is that there are so many to choose
12 from. And if you really don't like all the standards you just have to
13 wait another year until the one arises you are looking for.</p>
15 <p class="cite">-- <cite>A. Tanenbaum</cite>, "Introduction to
16 Computer Networks"</p>
19 <p>As an introduction this chapter is aimed at readers who are familiar
20 with the Web, HTTP, and Apache, but are not security experts. It is not
21 intended to be a definitive guide to the SSL protocol, nor does it discuss
22 specific techniques for managing certificates in an organization, or the
23 important legal issues of patents and import and export restrictions.
24 Rather, it is intended to provide a common background to mod_ssl users by
25 pulling together various concepts, definitions, and examples as a starting
26 point for further exploration.</p>
28 <p>The presented content is mainly derived, with permission by the author,
30 href="http://home.earthlink.net/~fjhirsch/Papers/wwwj/article.html">Introducing
31 SSL and Certificates using SSLeay</a> from <a
32 href="http://home.earthlink.net/~fjhirsch/">Frederick J. Hirsch</a>, of The
33 Open Group Research Institute, which was published in <a
34 href="http://www.ora.com/catalog/wjsum97/">Web Security: A Matter of
35 Trust</a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997.
36 Please send any positive feedback to <a
37 href="mailto:hirsch@fjhirsch.com">Frederick Hirsch</a> (the original
38 article author) and all negative feedback to <a
39 href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> (the
40 <module>mod_ssl</module> author).</p>
43 <section id="cryptographictech">
44 <title>Cryptographic Techniques</title>
45 <p>Understanding SSL requires an understanding of cryptographic
46 algorithms, message digest functions (aka. one-way or hash functions), and
47 digital signatures. These techniques are the subject of entire books (see
48 for instance [<a href="#AC96">AC96</a>]) and provide the basis for privacy,
49 integrity, and authentication.</p>
51 <section id="cryptographicalgo">
52 <title>Cryptographic Algorithms</title>
53 <p>Suppose Alice wants to send a message to her bank to transfer some
54 money. Alice would like the message to be private, since it will
55 include information such as her account number and transfer amount. One
56 solution is to use a cryptographic algorithm, a technique that would
57 transform her message into an encrypted form, unreadable except by
58 those it is intended for. Once in this form, the message may only be
59 interpreted through the use of a secret key. Without the key the
60 message is useless: good cryptographic algorithms make it so difficult
61 for intruders to decode the original text that it isn't worth their
64 <p>There are two categories of cryptographic algorithms: conventional
68 <dt>Conventional cryptography</dt>
69 <dd>also known as symmetric cryptography, requires the sender and
70 receiver to share a key: a secret piece of information that may be
71 used to encrypt or decrypt a message. If this key is secret, then
72 nobody other than the sender or receiver may read the message. If
73 Alice and the bank know a secret key, then they may send each other
74 private messages. The task of privately choosing a key before
75 communicating, however, can be problematic.</dd>
77 <dt>Public key cryptography</dt>
78 <dd>also known as asymmetric cryptography, solves the key exchange
79 problem by defining an algorithm which uses two keys, each of which
80 may be used to encrypt a message. If one key is used to encrypt a
81 message then the other must be used to decrypt it. This makes it
82 possible to receive secure messages by simply publishing one key
83 (the public key) and keeping the other secret (the private key).</dd>
86 <p>Anyone may encrypt a message using the public key, but only the
87 owner of the private key will be able to read it. In this way, Alice
88 may send private messages to the owner of a key-pair (the bank), by
89 encrypting it using their public key. Only the bank will be able to
93 <section id="messagedigests">
94 <title>Message Digests</title>
95 <p>Although Alice may encrypt her message to make it private, there
96 is still a concern that someone might modify her original message or
97 substitute it with a different one, in order to transfer the money
98 to themselves, for instance. One way of guaranteeing the integrity
99 of Alice's message is to create a concise summary of her message and
100 send this to the bank as well. Upon receipt of the message, the bank
101 creates its own summary and compares it with the one Alice sent. If
102 they agree then the message was received intact.</p>
104 <p>A summary such as this is called a <dfn>message digest</dfn>, <em>one-way
105 function</em> or <em>hash function</em>. Message digests are used to create
106 short, fixed-length representations of longer, variable-length messages.
107 Digest algorithms are designed to produce unique digests for different
108 messages. Message digests are designed to make it too difficult to determine
109 the message from the digest, and also impossible to find two different
110 messages which create the same digest -- thus eliminating the possibility of
111 substituting one message for another while maintaining the same digest.</p>
112 <p>Another challenge that Alice faces is finding a way to send the digest to the
113 bank securely; when this is achieved, the integrity of the associated message
114 is assured. One way to do this is to include the digest in a digital
118 <section id="digitalsignatures"><title>Digital Signatures</title>
119 <p>When Alice sends a message to the bank, the bank needs to ensure that the
120 message is really from her, so an intruder does not request a transaction
121 involving her account. A <em>digital signature</em>, created by Alice and
122 included with the message, serves this purpose.</p>
124 <p>Digital signatures are created by encrypting a digest of the message,
125 and other information (such as a sequence number) with the sender's
126 private key. Though anyone may <em>decrypt</em> the signature using the public
127 key, only the signer knows the private key. This means that only they may
128 have signed it. Including the digest in the signature means the signature is
129 only good for that message; it also ensures the integrity of the message since
130 no one can change the digest and still sign it.</p>
131 <p>To guard against interception and reuse of the signature by an intruder at a
132 later date, the signature contains a unique sequence number. This protects
133 the bank from a fraudulent claim from Alice that she did not send the message
134 -- only she could have signed it (non-repudiation).</p>
137 <!-- /cryptographictech -->
139 <section id="certificates">
140 <title>Certificates</title>
141 <p>Although Alice could have sent a private message to the bank, signed
142 it, and ensured the integrity of the message, she still needs to be sure
143 that she is really communicating with the bank. This means that she needs
144 to be sure that the public key she is using corresponds to the bank's
145 private key. Similarly, the bank also needs to verify that the message
146 signature really corresponds to Alice's signature.</p>
148 <p>If each party has a certificate which validates the other's identity,
149 confirms the public key, and is signed by a trusted agency, then they both
150 will be assured that they are communicating with whom they think they are.
151 Such a trusted agency is called a <em>Certificate Authority</em>, and
152 certificates are used for authentication.</p>
154 <section id="certificatecontents">
155 <title>Certificate Contents</title>
156 <p>A certificate associates a public key with the real identity of
157 an individual, server, or other entity, known as the subject. As
158 shown in <a href="#table1">Table 1</a>, information about the subject
159 includes identifying information (the distinguished name), and the
160 public key. It also includes the identification and signature of the
161 Certificate Authority that issued the certificate, and the period of
162 time during which the certificate is valid. It may have additional
163 information (or extensions) as well as administrative information
164 for the Certificate Authority's use, such as a serial number.</p>
166 <section id="table1">
167 <title>Table 1: Certificate Information</title>
170 <td>Distinguished Name, Public Key</td></tr>
172 <td>Distinguished Name, Signature</td></tr>
173 <tr><th>Period of Validity</th>
174 <td>Not Before Date, Not After Date</td></tr>
175 <tr><th>Administrative Information</th>
176 <td>Version, Serial Number</td></tr>
177 <tr><th>Extended Information</th>
178 <td>Basic Constraints, Netscape Flags, etc.</td></tr>
182 <p>A distinguished name is used to provide an identity in a specific
183 context -- for instance, an individual might have a personal
184 certificate as well as one for their identity as an employee.
185 Distinguished names are defined by the X.509 standard [<a
186 href="#X509">X509</a>], which defines the fields, field names, and
187 abbreviations used to refer to the fields (see <a href="#table2">Table
190 <section id="table2">
191 <title>Table 2: Distinguished Name Information</title>
193 <tr><th>DN Field</th>
196 <th>Example</th></tr>
197 <tr><td>Common Name</td>
199 <td>Name being certified</td>
200 <td>CN=Joe Average</td></tr>
201 <tr><td>Organization or Company</td>
203 <td>Name is associated with this<br />organization</td>
204 <td>O=Snake Oil, Ltd.</td></tr>
205 <tr><td>Organizational Unit</td>
207 <td>Name is associated with this <br />organization unit, such
209 <td>OU=Research Institute</td></tr>
210 <tr><td>City/Locality</td>
212 <td>Name is located in this City</td>
213 <td>L=Snake City</td></tr>
214 <tr><td>State/Province</td>
216 <td>Name is located in this State/Province</td>
217 <td>ST=Desert</td></tr>
220 <td>Name is located in this Country (ISO code)</td>
225 <p>A Certificate Authority may define a policy specifying which
226 distinguished field names are optional, and which are required. It
227 may also place requirements upon the field contents, as may users of
228 certificates. As an example, a Netscape browser requires that the
229 Common Name for a certificate representing a server has a name which
230 matches a wildcard pattern for the domain name of that server, such
231 as <code>*.snakeoil.com</code>.</p>
233 <p>The binary format of a certificate is defined using the ASN.1
234 notation [<a href="#X208">X208</a>] [<a href="#PKCS">PKCS</a>]. This
235 notation defines how to specify the contents, and encoding rules
236 define how this information is translated into binary form. The binary
237 encoding of the certificate is defined using Distinguished Encoding
238 Rules (DER), which are based on the more general Basic Encoding Rules
239 (BER). For those transmissions which cannot handle binary, the binary
240 form may be translated into an ASCII form by using Base64 encoding
241 [<a href="#MIME">MIME</a>]. This encoded version is called PEM encoded
242 (the name comes from "Privacy Enhanced Mail"), when placed between
243 begin and end delimiter lines as illustrated in the following
247 <title>Example of a PEM-encoded certificate (snakeoil.crt)</title>
248 <pre>-----BEGIN CERTIFICATE-----
249 MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
250 FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
251 A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
252 cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
253 bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
254 MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
255 a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
256 cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
257 AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
258 gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
259 vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
260 lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
261 HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
262 gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
263 2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
264 dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
265 -----END CERTIFICATE-----</pre>
269 <section id="certificateauthorities">
270 <title>Certificate Authorities</title>
271 <p>By first verifying the information in a certificate request
272 before granting the certificate, the Certificate Authority assures
273 the identity of the private key owner of a key-pair. For instance,
274 if Alice requests a personal certificate, the Certificate Authority
275 must first make sure that Alice really is the person the certificate
278 <section id="certificatechains">
279 <title>Certificate Chains</title>
280 <p>A Certificate Authority may also issue a certificate for
281 another Certificate Authority. When examining a certificate,
282 Alice may need to examine the certificate of the issuer, for each
283 parent Certificate Authority, until reaching one which she has
284 confidence in. She may decide to trust only certificates with a
285 limited chain of issuers, to reduce her risk of a "bad" certificate
289 <section id="rootlevelca">
290 <title>Creating a Root-Level CA</title>
291 <p>As noted earlier, each certificate requires an issuer to assert
292 the validity of the identity of the certificate subject, up to
293 the top-level Certificate Authority (CA). This presents a problem:
294 Since this is who vouches for the certificate of the top-level
295 authority, which has no issuer? In this unique case, the
296 certificate is "self-signed", so the issuer of the certificate is
297 the same as the subject. As a result, one must exercise extra care
298 in trusting a self-signed certificate. The wide publication of a
299 public key by the root authority reduces the risk in trusting this
300 key -- it would be obvious if someone else publicized a key
301 claiming to be the authority. Browsers are preconfigured to trust
302 well-known certificate authorities.</p>
304 <p>A number of companies, such as <a href="http://www.thawte.com/"
305 >Thawte</a> and <a href="http://www.verisign.com/">VeriSign</a>
306 have established themselves as Certificate Authorities. These
307 companies provide the following services:</p>
310 <li>Verifying certificate requests</li>
311 <li>Processing certificate requests</li>
312 <li>Issuing and managing certificates</li>
315 <p>It is also possible to create your own Certificate Authority.
316 Although risky in the Internet environment, it may be useful
317 within an Intranet where the organization can easily verify the
318 identities of individuals and servers.</p>
321 <section id="certificatemanagement">
322 <title>Certificate Management</title>
323 <p>Establishing a Certificate Authority is a responsibility which
324 requires a solid administrative, technical, and management
325 framework. Certificate Authorities not only issue certificates,
326 they also manage them -- that is, they determine how long
327 certificates are valid, they renew them, and they keep lists of
328 certificates that have already been issued but are no longer valid
329 (Certificate Revocation Lists, or CRLs). Say Alice is entitled to
330 a certificate as an employee of a company. Say too, that the
331 certificate needs to be revoked when Alice leaves the company. Since
332 certificates are objects that get passed around, it is impossible
333 to tell from the certificate alone that it has been revoked. When
334 examining certificates for validity, therefore, it is necessary to
335 contact the issuing Certificate Authority to check CRLs -- this
336 is not usually an automated part of the process.</p>
338 <note><title>Note</title>
339 <p>If you use a Certificate Authority that is not configured into
340 browsers by default, it is necessary to load the Certificate
341 Authority certificate into the browser, enabling the browser to
342 validate server certificates signed by that Certificate Authority.
343 Doing so may be dangerous, since once loaded, the browser will
344 accept all certificates signed by that Certificate Authority.</p>
348 <!-- /certificateauthorities -->
350 <!-- /certificates -->
353 <title>Secure Sockets Layer (SSL)</title>
354 <p>The Secure Sockets Layer protocol is a protocol layer which may be
355 placed between a reliable connection-oriented network layer protocol
356 (e.g. TCP/IP) and the application protocol layer (e.g. HTTP). SSL provides
357 for secure communication between client and server by allowing mutual
358 authentication, the use of digital signatures for integrity, and encryption
361 <p>The protocol is designed to support a range of choices for specific
362 algorithms used for cryptography, digests, and signatures. This allows
363 algorithm selection for specific servers to be made based on legal, export
364 or other concerns, and also enables the protocol to take advantage of new
365 algorithms. Choices are negotiated between client and server at the start
366 of establishing a protocol session.</p>
368 <section id="table4">
369 <title>Table 4: Versions of the SSL protocol</title>
374 <th>Browser Support</th></tr>
375 <tr><td>SSL v2.0</td>
376 <td>Vendor Standard (from Netscape Corp.) [<a href="#SSL2"
378 <td>First SSL protocol for which implementations exists</td>
379 <td>- NS Navigator 1.x/2.x<br />
381 - Lynx/2.8+OpenSSL</td></tr>
382 <tr><td>SSL v3.0</td>
383 <td>Expired Internet Draft (from Netscape Corp.) [<a href="#SSL3"
385 <td>Revisions to prevent specific security attacks, add non-RSA
386 ciphers, and support for certificate chains</td>
387 <td>- NS Navigator 2.x/3.x/4.x<br />
388 - MS IE 3.x/4.x<br />
389 - Lynx/2.8+OpenSSL</td></tr>
390 <tr><td>TLS v1.0</td>
391 <td>Proposed Internet Standard (from IETF) [<a href="#TLS1"
393 <td>Revision of SSL 3.0 to update the MAC layer to HMAC, add block
394 padding for block ciphers, message order standardization and more
396 <td>- Lynx/2.8+OpenSSL</td></tr>
400 <p>There are a number of versions of the SSL protocol, as shown in
401 <a href="#table4">Table 4</a>. As noted there, one of the benefits in
402 SSL 3.0 is that it adds support of certificate chain loading. This feature
403 allows a server to pass a server certificate along with issuer certificates
404 to the browser. Chain loading also permits the browser to validate the
405 server certificate, even if Certificate Authority certificates are not
406 installed for the intermediate issuers, since they are included in the
407 certificate chain. SSL 3.0 is the basis for the Transport Layer Security
408 [<a href="#TLS1">TLS</a>] protocol standard, currently in development by
409 the Internet Engineering Task Force (IETF).</p>
411 <section id="session">
412 <title>Session Establishment</title>
413 <p>The SSL session is established by following a handshake sequence
414 between client and server, as shown in <a href="#figure1"
415 >Figure 1</a>. This sequence may vary, depending on whether the server
416 is configured to provide a server certificate or request a client
417 certificate. Though cases exist where additional handshake steps
418 are required for management of cipher information, this article
419 summarizes one common scenario: see the SSL specification for the full
420 range of possibilities.</p>
422 <note><title>Note</title>
423 <p>Once an SSL session has been established it may be reused, thus
424 avoiding the performance penalty of repeating the many steps needed
425 to start a session. For this the server assigns each SSL session a
426 unique session identifier which is cached in the server and which the
427 client can use on forthcoming connections to reduce the handshake
428 (until the session identifer expires in the cache of the server).</p>
432 <img src="ssl_intro_fig1.gif" alt="" width="423" height="327" /><br />
433 <a id="figure1" name="figure1"><dfn>Figure 1</dfn></a>: Simplified SSL
434 Handshake Sequence</p>
436 <p>The elements of the handshake sequence, as used by the client and
437 server, are listed below:</p>
440 <li>Negotiate the Cipher Suite to be used during data transfer</li>
441 <li>Establish and share a session key between client and server</li>
442 <li>Optionally authenticate the server to the client</li>
443 <li>Optionally authenticate the client to the server</li>
446 <p>The first step, Cipher Suite Negotiation, allows the client and
447 server to choose a Cipher Suite supportable by both of them. The SSL3.0
448 protocol specification defines 31 Cipher Suites. A Cipher Suite is
449 defined by the following components:</p>
452 <li>Key Exchange Method</li>
453 <li>Cipher for Data Transfer</li>
454 <li>Message Digest for creating the Message Authentication Code (MAC)</li>
457 <p>These three elements are described in the sections that follow.</p>
460 <section id="keyexchange">
461 <title>Key Exchange Method</title>
462 <p>The key exchange method defines how the shared secret symmetric
463 cryptography key used for application data transfer will be agreed
464 upon by client and server. SSL 2.0 uses RSA key exchange only, while
465 SSL 3.0 supports a choice of key exchange algorithms including the
466 RSA key exchange when certificates are used, and Diffie-Hellman key
467 exchange for exchanging keys without certificates and without prior
468 communication between client and server.</p>
470 <p>One variable in the choice of key exchange methods is digital
471 signatures -- whether or not to use them, and if so, what kind of
472 signatures to use. Signing with a private key provides assurance
473 against a man-in-the-middle-attack during the information exchange
474 used in generating the shared key [<a href="#AC96">AC96</a>, p516].</p>
477 <section id="ciphertransfer">
478 <title>Cipher for Data Transfer</title>
479 <p>SSL uses the conventional cryptography algorithm (symmetric
480 cryptography) described earlier for encrypting messages in a session.
481 There are nine choices, including the choice to perform no
485 <li>No encryption</li>
488 <li>RC4 with 40-bit keys</li>
489 <li>RC4 with 128-bit keys</li>
491 <li>CBC Block Ciphers
492 <ul><li>RC2 with 40 bit key</li>
493 <li>DES with 40 bit key</li>
494 <li>DES with 56 bit key</li>
495 <li>Triple-DES with 168 bit key</li>
496 <li>Idea (128 bit key)</li>
497 <li>Fortezza (96 bit key)</li>
501 <p>Here "CBC" refers to Cipher Block Chaining, which means that a
502 portion of the previously encrypted cipher text is used in the
503 encryption of the current block. "DES" refers to the Data Encryption
504 Standard [<a href="#AC96">AC96</a>, ch12], which has a number of
505 variants (including DES40 and 3DES_EDE). "Idea" is one of the best
506 and cryptographically strongest available algorithms, and "RC2" is
507 a proprietary algorithm from RSA DSI [<a href="#AC96">AC96</a>,
511 <section id="digestfuntion">
512 <title>Digest Function</title>
513 <p>The choice of digest function determines how a digest is created
514 from a record unit. SSL supports the following:</p>
517 <li>No digest (Null choice)</li>
518 <li>MD5, a 128-bit hash</li>
519 <li>Secure Hash Algorithm (SHA-1), a 160-bit hash</li>
522 <p>The message digest is used to create a Message Authentication Code
523 (MAC) which is encrypted with the message to provide integrity and to
524 prevent against replay attacks.</p>
527 <section id="handshake">
528 <title>Handshake Sequence Protocol</title>
529 <p>The handshake sequence uses three protocols:</p>
532 <li>The <dfn>SSL Handshake Protocol</dfn>
533 for performing the client and server SSL session establishment.</li>
534 <li>The <dfn>SSL Change Cipher Spec Protocol</dfn> for actually
535 establishing agreement on the Cipher Suite for the session.</li>
536 <li>The <dfn>SSL Alert Protocol</dfn> for conveying SSL error
537 messages between client and server.</li>
540 <p>These protocols, as well as application protocol data, are
541 encapsulated in the <dfn>SSL Record Protocol</dfn>, as shown in
542 <a href="#figure2">Figure 2</a>. An encapsulated protocol is
543 transferred as data by the lower layer protocol, which does not
544 examine the data. The encapsulated protocol has no knowledge of the
545 underlying protocol.</p>
548 <img src="ssl_intro_fig2.gif" alt="" width="428" height="217" /><br />
549 <a id="figure2" name="figure2"><dfn>Figure 2</dfn></a>: SSL Protocol Stack
552 <p>The encapsulation of SSL control protocols by the record protocol
553 means that if an active session is renegotiated the control protocols
554 will be transmitted securely. If there were no session before, then
555 the Null cipher suite is used, which means there is no encryption and
556 messages have no integrity digests until the session has been
560 <section id="datatransfer">
561 <title>Data Transfer</title>
562 <p>The SSL Record Protocol, shown in <a href="#figure3">Figure 3</a>,
563 is used to transfer application and SSL Control data between the
564 client and server, possibly fragmenting this data into smaller units,
565 or combining multiple higher level protocol data messages into single
566 units. It may compress, attach digest signatures, and encrypt these
567 units before transmitting them using the underlying reliable transport
568 protocol (Note: currently all major SSL implementations lack support
569 for compression).</p>
572 <img src="ssl_intro_fig3.gif" alt="" width="423" height="323" /><br />
573 <a id="figure3" name="figure3"><dfn>Figure 3</dfn></a>: SSL Record Protocol
577 <section id="securehttp">
578 <title>Securing HTTP Communication</title>
579 <p>One common use of SSL is to secure Web HTTP communication between
580 a browser and a webserver. This case does not preclude the use of
581 non-secured HTTP. The secure version is mainly plain HTTP over SSL
582 (named HTTPS), but with one major difference: it uses the URL scheme
583 <code>https</code> rather than <code>http</code> and a different
584 server port (by default 443). This mainly is what <module
585 >mod_ssl</module> provides to you for the Apache webserver...</p>
590 <section id="references">
591 <title>References</title>
593 <dt><a id="AC96" name="AC96">[AC96]</a></dt>
594 <dd>Bruce Schneier, <q>Applied Cryptography</q>, 2nd Edition, Wiley,
595 1996. See <a href="http://www.counterpane.com/"
596 >http://www.counterpane.com/</a> for various other materials by Bruce
599 <dt><a id="X208" name="X208">[X208]</a></dt>
600 <dd>ITU-T Recommendation X.208, <q>Specification of Abstract Syntax Notation
601 One (ASN.1)</q>, 1988. See for instance <a
602 href="http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I"
603 >http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I</a>.
606 <dt><a id="X509" name="X509">[X509]</a></dt>
607 <dd>ITU-T Recommendation X.509, <q>The Directory - Authentication
608 Framework</q>. See for instance <a
609 href="http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509"
610 >http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509</a>.
613 <dt><a id="PKCS" name="PKCS">[PKCS]</a></dt>
614 <dd><q>Public Key Cryptography Standards (PKCS)</q>,
615 RSA Laboratories Technical Notes, See <a
616 href="http://www.rsasecurity.com/rsalabs/pkcs/"
617 >http://www.rsasecurity.com/rsalabs/pkcs/</a>.</dd>
619 <dt><a id="MIME" name="MIME">[MIME]</a></dt>
620 <dd>N. Freed, N. Borenstein, <q>Multipurpose Internet Mail Extensions
621 (MIME) Part One: Format of Internet Message Bodies</q>, RFC2045.
622 See for instance <a href="http://ietf.org/rfc/rfc2045.txt"
623 >http://ietf.org/rfc/rfc2045.txt</a>.</dd>
625 <dt><a id="SSL2" name="SSL2">[SSL2]</a></dt>
626 <dd>Kipp E.B. Hickman, <q>The SSL Protocol</q>, 1995. See <a
627 href="http://www.netscape.com/eng/security/SSL_2.html"
628 >http://www.netscape.com/eng/security/SSL_2.html</a>.</dd>
630 <dt><a id="SSL3" name="SSL3">[SSL3]</a></dt>
631 <dd>Alan O. Freier, Philip Karlton, Paul C. Kocher, <q>The SSL Protocol
632 Version 3.0</q>, 1996. See <a
633 href="http://www.netscape.com/eng/ssl3/draft302.txt"
634 >http://www.netscape.com/eng/ssl3/draft302.txt</a>.</dd>
636 <dt><a id="TLS1" name="TLS1">[TLS1]</a></dt>
637 <dd>Tim Dierks, Christopher Allen, <q>The TLS Protocol Version 1.0</q>,
638 1999. See <a href="http://ietf.org/rfc/rfc2246.txt"
639 >http://ietf.org/rfc/rfc2246.txt</a>.</dd>