📄 ssl_intro.html.en
字号:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><!--
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
This file is generated from xml source: DO NOT EDIT
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-->
<title>SSL/TLS Strong Encryption: An Introduction - Apache HTTP Server</title>
<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
<link href="../images/favicon.ico" rel="shortcut icon" /></head>
<body id="manual-page"><div id="page-header">
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p>
<p class="apache">Apache HTTP Server Version 2.2</p>
<img alt="" src="../images/feather.gif" /></div>
<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
<div id="path">
<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 id="preamble"><h1>SSL/TLS Strong Encryption: An Introduction</h1>
<div class="toplang">
<p><span>Available Languages: </span><a href="../en/ssl/ssl_intro.html" title="English"> en </a> |
<a href="../ja/ssl/ssl_intro.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a></p>
</div>
<blockquote>
<p>The nice thing about standards is that there are so many to choose
from. And if you really don't like all the standards you just have to
wait another year until the one arises you are looking for.</p>
<p class="cite">-- <cite>A. Tanenbaum</cite>, "Introduction to
Computer Networks"</p>
</blockquote>
<p>As an introduction this chapter is aimed at readers who are familiar
with the Web, HTTP, and Apache, but are not security experts. It is not
intended to be a definitive guide to the SSL protocol, nor does it discuss
specific techniques for managing certificates in an organization, or the
important legal issues of patents and import and export restrictions.
Rather, it is intended to provide a common background to <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> users by pulling together various concepts, definitions,
and examples as a starting point for further exploration.</p>
<p>The presented content is mainly derived, with the author's permission,
from the article <a href="http://home.comcast.net/~fjhirsch/Papers/wwwj/">Introducing
SSL and Certificates using SSLeay</a> by <a href="http://home.comcast.net/~fjhirsch/">Frederick J. Hirsch</a>, of The
Open Group Research Institute, which was published in <a href="http://www.ora.com/catalog/wjsum97/">Web Security: A Matter of
Trust</a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997.
Please send any positive feedback to <a href="mailto:hirsch@fjhirsch.com">Frederick Hirsch</a> (the original
article author) and all negative feedback to <a href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> (the
<code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> author).</p>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#cryptographictech">Cryptographic Techniques</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#certificates">Certificates</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#ssl">Secure Sockets Layer (SSL)</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#references">References</a></li>
</ul></div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="cryptographictech" id="cryptographictech">Cryptographic Techniques</a></h2>
<p>Understanding SSL requires an understanding of cryptographic
algorithms, message digest functions (aka. one-way or hash functions), and
digital signatures. These techniques are the subject of entire books (see
for instance [<a href="#AC96">AC96</a>]) and provide the basis for privacy,
integrity, and authentication.</p>
<h3><a name="cryptographicalgo" id="cryptographicalgo">Cryptographic Algorithms</a></h3>
<p>Suppose Alice wants to send a message to her bank to transfer some
money. Alice would like the message to be private, since it will
include information such as her account number and transfer amount. One
solution is to use a cryptographic algorithm, a technique that would
transform her message into an encrypted form, unreadable until it is
decrypted. Once in this form, the message can only be
decrypted by using a secret key. Without the key the message is useless:
good cryptographic algorithms make it so difficult
for intruders to decode the original text that it isn't worth their
effort.</p>
<p>There are two categories of cryptographic algorithms: conventional
and public key.</p>
<dl>
<dt>Conventional cryptography</dt>
<dd>also known as symmetric cryptography, requires the sender and
receiver to share a key: a secret piece of information that may be
used to encrypt or decrypt a message. As long as this key is kept
secret, nobody other than the sender or recipient can read the message.
If Alice and the bank know a secret key, then they can send each other
private messages. The task of sharing a key between sender and recipient
before communicating, while also keeping it secret from others, can be
problematic.</dd>
<dt>Public key cryptography</dt>
<dd>also known as asymmetric cryptography, solves the key exchange
problem by defining an algorithm which uses two keys, each of which
may be used to encrypt a message. If one key is used to encrypt a
message then the other must be used to decrypt it. This makes it
possible to receive secure messages by simply publishing one key
(the public key) and keeping the other secret (the private key).</dd>
</dl>
<p>Anyone can encrypt a message using the public key, but only the
owner of the private key will be able to read it. In this way, Alice
can send private messages to the owner of a key-pair (the bank), by
encrypting it using their public key. Only the bank will be able to
decrypt it.</p>
<h3><a name="messagedigests" id="messagedigests">Message Digests</a></h3>
<p>Although Alice may encrypt her message to make it private, there
is still a concern that someone might modify her original message or
substitute it with a different one, in order to transfer the money
to themselves, for instance. One way of guaranteeing the integrity
of Alice's message is for her to create a concise summary of her
message and send this to the bank as well. Upon receipt of the message,
the bank creates its own summary and compares it with the one Alice
sent. If the summaries are the same then the message has been received
intact.</p>
<p>A summary such as this is called a <dfn>message digest</dfn>, <em>one-way
function</em> or <em>hash function</em>. Message digests are used to create
a short, fixed-length representation of a longer, variable-length message.
Digest algorithms are designed to produce a unique digests for each
message. Message digests are designed to make it impractically difficult
to determine the message from the digest, and (in theory) impossible to
find two different messages which create the same digest -- thus
eliminating the possibility of substituting one message for another while
maintaining the same digest.</p>
<p>Another challenge that Alice faces is finding a way to send the digest
to the bank securely; if the digest is not sent securely, its integrity may
be compromised, and with it, the possibility for the bank to determine the
integrity of the original message. Only if the digest is sent securely can
the integrity of the associated message be determined.</p>
<p>One way to send the digest securely is to include it in a digital
signature.</p>
<h3><a name="digitalsignatures" id="digitalsignatures">Digital Signatures</a></h3>
<p>When Alice sends a message to the bank, the bank needs to ensure that the
message is really from her, so an intruder cannot request a transaction
involving her account. A <em>digital signature</em>, created by Alice and
included with the message, serves this purpose.</p>
<p>Digital signatures are created by encrypting a digest of the message,
and other information (such as a sequence number) with the sender's
private key. Though anyone can <em>decrypt</em> the signature using the public
key, only the sender knows the private key. This means that only they can
have signed it. Including the digest in the signature means the signature is
only good for that message; it also ensures the integrity of the message since
no one can change the digest and still sign it.</p>
<p>To guard against interception and reuse of the signature by an intruder at a
later date, the signature contains a unique sequence number. This protects
the bank from a fraudulent claim from Alice that she did not send the message
-- only she could have signed it (non-repudiation).</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="certificates" id="certificates">Certificates</a></h2>
<p>Although Alice could have sent a private message to the bank, signed
it, and ensured the integrity of the message, she still needs to be sure
that she is really communicating with the bank. This means that she needs
to be sure that the public key she is using is part of the bank's key-pair,
and not an intruder's. Similarly, the bank needs to verify that the message
signature really was signed by the private key that belongs to Alice.</p>
<p>If each party has a certificate which validates the other's identity,
confirms the public key, and is signed by a trusted agency, then both
can be assured that they are communicating with whom they think they are.
Such a trusted agency is called a <em>Certificate Authority</em>, and
certificates are used for authentication.</p>
<h3><a name="certificatecontents" id="certificatecontents">Certificate Contents</a></h3>
<p>A certificate associates a public key with the real identity of
an individual, server, or other entity, known as the subject. As
shown in <a href="#table1">Table 1</a>, information about the subject
includes identifying information (the distinguished name), and the
public key. It also includes the identification and signature of the
Certificate Authority that issued the certificate, and the period of
time during which the certificate is valid. It may have additional
information (or extensions) as well as administrative information
for the Certificate Authority's use, such as a serial number.</p>
<h4><a name="table1" id="table1">Table 1: Certificate Information</a></h4>
<table>
<tr><th>Subject</th>
<td>Distinguished Name, Public Key</td></tr>
<tr><th>Issuer</th>
<td>Distinguished Name, Signature</td></tr>
<tr><th>Period of Validity</th>
<td>Not Before Date, Not After Date</td></tr>
<tr><th>Administrative Information</th>
<td>Version, Serial Number</td></tr>
<tr><th>Extended Information</th>
<td>Basic Constraints, Netscape Flags, etc.</td></tr>
</table>
<p>A distinguished name is used to provide an identity in a specific
context -- for instance, an individual might have a personal
certificate as well as one for their identity as an employee.
Distinguished names are defined by the X.509 standard [<a href="#X509">X509</a>], which defines the fields, field names, and
abbreviations used to refer to the fields (see <a href="#table2">Table
2</a>).</p>
<h4><a name="table2" id="table2">Table 2: Distinguished Name Information</a></h4>
<table class="bordered">
<tr><th>DN Field</th>
<th>Abbrev.</th>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -