ssl_intro.html

mod_ssl-2.8.31-1.3.41.tar.gz 好用的ssl工具

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#ToC13"><strong>Key Exchange Method</strong></a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#ToC14"><strong>Cipher for Data Transfer</strong></a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#ToC15"><strong>Digest Function</strong></a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#ToC16"><strong>Handshake Sequence Protocol</strong></a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#ToC17"><strong>Data Transfer</strong></a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#ToC18"><strong>Securing HTTP Communication</strong></a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#ToC19"><strong>References</strong></a><br>
</font>
</td>
</tr>
</table>
</div>
</td>
</tr>
</table>
<h2><a name="ToC1">Cryptographic Techniques</a></h2>
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.
<h3><a name="ToC2">Cryptographic Algorithms</a></h3>
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 except by those it is intended for. Once in this
form, the message may only be interpreted through the use of 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>
There are two categories of cryptographic algorithms:
conventional and public key.
<ul>
<li><em>Conventional cryptography</em>, 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.
If this key is secret, then nobody other than the sender or receiver may
read the message. If Alice and the bank know a secret key, then they
may send each other private messages. The task of privately choosing a key
before communicating, however, can be problematic.
<p>
<li><em>Public key cryptography</em>, 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).
<p>
Anyone may 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 may 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.
</ul>
<h3><a name="ToC3">Message Digests</a></h3>
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 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 they agree then the message was received intact.
<p>
A summary such as this is called a <em>message digest</em>, <em>one-way
function</em> or <em>hash function</em>. Message digests are used to create
short, fixed-length representations of longer, variable-length messages.
Digest algorithms are designed to produce unique digests for different
messages. Message digests are designed to make it too difficult to determine
the message from the digest, and also 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>
Another challenge that Alice faces is finding a way to send the digest to the
bank securely; when this is achieved, the integrity of the associated message
is assured. One way to to this is to include the digest in a digital
signature.
<h3><a name="ToC4">Digital Signatures</a></h3>
When Alice sends a message to the bank, the bank needs to ensure that the
message is really from her, so an intruder does not request a transaction
involving her account. A <em>digital signature</em>, created by Alice and
included with the message, serves this purpose.
<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 may <em>decrypt</em> the signature using the public
key, only the signer knows the private key. This means that only they may
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>
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).
<h2><a name="ToC5">Certificates</a></h2>
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 corresponds to the bank's private key. Similarly,
the bank also needs to verify that the message signature really corresponds to
Alice's signature.
<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 they both will 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.
<h3><a name="ToC6">Certificate Contents</a></h3>
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>
<div align="center">
<a name="table1"></a>
<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
<caption align="bottom" id="sf">Table 1: Certificate Information</caption>
<tr><td bgcolor="#cccccc">
<table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
<tr><td valign="top" align="center" bgcolor="#ffffff">
<table summary="">
<tr valign="top"><td><b>Subject:</b></td>
<td>Distinguished Name, Public Key</td></tr>
<tr valign="top"><td><b>Issuer:</b></td>
<td>Distinguished Name, Signature</td></tr>
<tr><td><b>Period of Validity:</b></td>
<td>Not Before Date, Not After Date</td></tr>
<tr><td><b>Administrative Information:</b></td>
<td>Version, Serial Number</td></TR>
<tr><td><b>Extended Information:</b></td>
<td>Basic Contraints, Netscape Flags, etc.</td></TR>
</table>
</td>
</tr></table>
</td></tr></table>
</div>
<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>
<div align="center">
<a name="table2"></a>
<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
<caption align="bottom" id="sf">Table 2: Distinguished Name Information</caption>
<tr><td bgcolor="#cccccc">
<table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
<tr><td valign="top" align="center" bgcolor="#ffffff">
<table summary="">
<tr valign="top"><td><b>DN Field:</b></td><td><b>Abbrev.:</b></td><td><b>Description:</b></td>
<td><b>Example:</b></td>
</t>
<tr valign="top"><td>Common Name</td><td>CN</td>
<td>Name being certified</td><td>CN=Joe Average</td></tr>
<tr valign="top"><td>Organization or Company</td><td>O</td>
<td>Name is associated with this<br>organization</td><td>O=Snake Oil, Ltd.</td></tr>
<tr valign="top"><td>Organizational Unit</td><td>OU</td>
<td>Name is associated with this <br>organization unit, such as a department</td><td>OU=Research Institute</td></tr>
<tr valign="top"><td>City/Locality</td><td>L</td>
<td>Name is located in this City</td><td>L=Snake City</td></tr>
<tr valign="top"><td>State/Province</td><td>ST</td>
<td>Name is located in this State/Province</td><td>ST=Desert</td></tr>
<tr valign="top"><td>Country</td><td>C</td>
<td>Name is located in this Country (ISO code)</td><td>C=XZ</td></tr>
</table>
</td>
</tr></table>
</td></tr></table>
</div>
<p>
A Certificate Authority may define a policy specifying which distinguished
field names are optional, and which are required. It may also place
requirements upon the field contents, as may users of certificates. As an
example, a Netscape browser requires that the Common Name for a certificate
representing a server has a name which matches a wildcard pattern for the
domain name of that server, such as <code>*.snakeoil.com</code>.
<p>
The binary format of a certificate is defined using the ASN.1 notation [ <a
href="#X208">X208</a>] [<a href="#PKCS">PKCS</a>]. This notation defines how to
specify the contents, and encoding rules define how this information is
translated into binary form. The binary encoding of the certificate is
defined using Distinguished Encoding Rules (DER), which are based on the more
general Basic Encoding Rules (BER). For those transmissions which cannot
handle binary, the binary form may be translated into an ASCII form by using
Base64 encoding [<a href="#MIME">MIME</a>]. This encoded version is called PEM
encoded (the name comes from "Privacy Enhanced Mail"), when placed between
begin and end delimiter lines as illustrated in <a href="#table3">Table 3</a>.
<p>
<div align="center">
<a name="table3"></a>
<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
<caption align="bottom" id="sf">Table 3: Example of a PEM-encoded certificate (snakeoil.crt)</caption>
<tr><td bgcolor="#cccccc">
<table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
<tr><td valign="top" align="center" bgcolor="#ffffff">
<table cellspacing="0" cellpadding="0" summary=""><tr><td>
<div class="code"><pre>
-----BEGIN CERTIFICATE-----
MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
-----END CERTIFICATE-----</pre></div>
</td></tr></table>
</td>
</tr></table>
</td></tr></table>
</div>
<h3><a name="ToC7">Certificate Authorities</a></h3>
By first verifying the information in a certificate request before granting
the certificate, the Certificate Authority assures the identity of the private
key owner of a key-pair. For instance, if Alice requests a personal
certificate, the Certificate Authority must first make sure that Alice really
is the person the certificate request claims.
<h4><a name="ToC8">Certificate Chains</a></h4>
A Certificate Authority may also issue a certificate for another Certificate
Authority. When examining a certificate, Alice may need to examine the
certificate of the issuer, for each parent Certificate Authority, until
reaching one which she has confidence in. She may decide to trust only
certificates with a limited chain of issuers, to reduce her risk of a "bad"
certificate in the chain.
<h4><a name="ToC9">Creating a Root-Level CA</a></h4>
As noted earlier, each certificate requires an issuer to assert the validity
of the identity of the certificate subject, up to the top-level Certificate
Authority (CA). This presents a problem: Since this is who vouches for the
certificate of the top-level authority, which has no issuer?
In this unique case, the certificate is "self-signed", so the issuer of the
certificate is the same as the subject. As a result, one must exercise extra
care in trusting a self-signed certificate. The wide publication of a public
key by the root authority reduces the risk in trusting this key -- it would be
obvious if someone else publicized a key claiming to be the authority.
Browsers are preconfigured to trust well-known certificate authorities.
<p>
A number of companies, such as <a href="http://www.thawte.com/">Thawte</a> and
<a href="http://www.verisign.com/">VeriSign</a> have established themselves as
Certificate Authorities. These companies provide the following services:
<ul>
<li>Verifying certificate requests
<li>Processing certificate requests
<li>Issuing and managing certificates
</ul>
<p>
It is also possible to create your own Certificate Authority. Although risky
in the Internet environment, it may be useful within an Intranet where the
organization can easily verify the identities of individuals and servers.
<h4><a name="ToC10">Certificate Management</a></h4>
Establishing a Certificate Authority is a responsibility which requires a
solid administrative, technical, and management framework.
Certificate Authorities not only issue certificates, they also manage them --
that is, they determine how long certificates are valid, they renew them, and
they keep lists of certificates that have already been issued but are no
longer valid (Certificate Revocation Lists, or CRLs).
Say Alice is entitled to a certificate as an employee of a company. Say too,
that the certificate needs to be revoked when Alice leaves the company. Since
certificates are objects that get passed around, it is impossible to tell from
the certificate alone that it has been revoked.
When examining certificates for validity, therefore, it is necessary to
contact the issuing Certificate Authority to check CRLs -- this is not usually
an automated part of the process.
<p>
<div align="center"><B>Note:</B></div>
If you use a Certificate Authority that is not configured into browsers by
default, it is necessary to load the Certificate Authority certificate into
the browser, enabling the browser to validate server certificates signed by
that Certificate Authority. Doing so may be dangerous, since once loaded, the
browser will accept all certificates signed by that Certificate Authority.
<h2><a name="ToC11">Secure Sockets Layer (SSL)</a></h2>
The Secure Sockets Layer protocol is a protocol layer which may be placed
between a reliable connection-oriented network layer protocol (e.g. TCP/IP)
and the application protocol layer (e.g. HTTP). SSL provides for secure
communication between client and server by allowing mutual authentication, the
use of digital signatures for integrity, and encryption for privacy.
<p>
The protocol is designed to support a range of choices for specific algorithms
used for cryptography, digests, and signatures. This allows algorithm
selection for specific servers to be made based on legal, export or other
concerns, and also enables the protocol to take advantage of new algorithms.
Choices are negotiated between client and server at the start of establishing
a protocol session.
<p>
<div align="center">
<a name="table4"></a>
<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
<caption align="bottom" id="sf">Table 4: Versions of the SSL protocol</caption>
<tr><td bgcolor="#cccccc">
<table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
<tr><td valign="top" align="center" bgcolor="#ffffff">