分类： LINUX
2008-03-08 12:35:55
Apache HTTP Server Version 2.0
Available Languages: |
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.
-- A. Tanenbaum, "Introduction to Computer Networks"
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 mod_ssl users by pulling together various concepts, definitions, and examples as a starting point for further exploration.
The presented content is mainly derived, with permission by the author, from
the article from , of The Open
Group Research Institute, which was published in Web Security: A Matter of Trust,
World Wide Web Journal, Volume 2, Issue 3, Summer 1997. Please send any positive
feedback to (the
original article author) and all negative feedback to (the
author).
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 []) and provide the basis for privacy, integrity, and authentication.
# 注释 ：要了解 SSL ，你必须了解密码算法、消息摘要函数（单向或者 hash 函数）、数字签名，分别用于提供隐密性、完整性、认证
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.
# 注释 ：如果一个会话不想让别人知道其内容，可以通过加密实现。好的加密算法应是难以破解（decode）的。
There are two categories of cryptographic algorithms: conventional and public key.
# 注释 ：目前有两类加密算法 ：传统加密和公钥加密
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.
# 注释 ：发送消息时采用对方的公钥加密，只有拥有对应的私钥的人才能解密
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.
# 注释 ：即使消息被加密，也存在一个被篡改的问题，所以这就引入了消息摘要
A summary such as this is called a message digest, one-way function or hash function. 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.
# 注释 ：它采用单向函数或者 hash 函数。消息摘要的长度是固定的，不管原文有多长。
# 不同的原文应该生成不同的摘要，或者说要保证两个不同的消息不可能得出相同的摘要。
# 这样一旦修改了原文，只要对被修改过的消息计算摘要，再和原来的摘要想比较，就可以知道消息被修改了
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 do this is to include the digest in a digital signature.
# 注释 ：但如果消息摘要被修改了呢？所以这又引入了数字签名的概念
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 digital signature, created by Alice and included with the message, serves this purpose.
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 decrypt 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.
# 注释 ：所谓数字签名就是对一个消息的摘要进行加密，使用的是发送方的私钥。
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).
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.
# 注释 ：尽管使用了加密、消息摘要、数字签名，但发送方还是需要确保它所连接的对方就是它所想要通信的那个人。
# 这意味着它需要发送方需要确认它所使用的收方的公钥的确就是属于它所想要通信的那个人。
# 同样另外一方也存在该问题。
# 总之通信双方存在一个相互认证的过程
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 Certificate Authority, and certificates are used for authentication.
# 注释 ：假如通信的任何一方都有一个对方的证书，它确认了这个公钥就是属于所想要通信的那个人，并且这个证书是由一个可信的机构发出的，
# 这就可以让双方都相信对方就是自己想要找的那个人。提供这样一个证书的机构称为 CA（认证中心），而证书就是用于向对方证实自己的身份用的。
A certificate associates a public key with the real identity of an individual, server, or other entity, known as the subject. As shown in , 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.
# 注释 ：一个证书把一个 public key 和一个特定的身份联系在一起，这个身份可以是个人、组织或者其他，例如服务器、代码等。
# 我们把这个身份称之为 Subject 。就像表-1 一样，关于该 subject 的信息包括“身份信息（一个可以用于彼此区分的名称）”以及公钥。
# 它也包含了颁发该证书的 CA 的身份信息和签名、以及该证书的有效期（从xxx-到yyy）。
# 它还可以包含其他信息，例如证书的序列号。
| Subject | Distinguished Name, Public Key |
|---|---|
| Issuer | Distinguished Name, Signature |
| Period of Validity | Not Before Date, Not After Date |
| Administrative Information | Version, Serial Number |
| Extended Information | Basic Constraints, Netscape Flags, etc. |
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 [], which defines the fields, field names, and abbreviations used to refer to the fields (see ).
# 注释 ：Subject 是按照 x.509 规定的格式，注意，issuer 也有一个名称，它们都有下面的全部或者部分字段
# -）1、CN（Common Name）：公共名称。也就是被认证的名称，如果是Subject 则是证书持有人的名称。例如 CN = 14883304I
# -）2、O （Organization / Company）：例如 O = CCB （中国建行）
# -）3、OU（Organization Unit）：例如 OU = NET_BANK
# -）4、L（Location）：例如 L = Xi Cheng
# -）5、ST（省份）：例如 S=BJ（北京）
# -）6、C （Country) ：例如 C=CN
| DN Field | Abbrev. | Description | Example |
|---|---|---|---|
| Common Name | CN | Name being certified | CN=Joe Average |
| Organization or Company | O | Name is associated with this organization |
O=Snake Oil, Ltd. |
| Organizational Unit | OU | Name is associated with this organization unit, such as a department |
OU=Research Institute |
| City/Locality | L | Name is located in this City | L=Snake City |
| State/Province | ST | Name is located in this State/Province | ST=Desert |
| Country | C | Name is located in this Country (ISO code) | C=XZ |
# 补充 ：下面是一个中国建行的网上银行个人证书 ：
# 其中的 “颁发者” 一项的值为 ：
E =
L = Xi
Cheng
CN = CCB CA ROOT
S = BJ
OU = CCB_Netbank
O = CCB
C =
CN
# 而“主题（subject）” 的值为 ：
C = CN
O = CCB
OU = NET_BANK
CN =
14883304I
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 *.snakeoil.com.
# 注释 ：CA 可以定义那些字段是必须的，那些是可选的。也可以对字段的值进行限制。
The binary format of a certificate is defined using the ASN.1 notation [] []. 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 []. 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 the following example.
# 注释 ：证书可以被导出，而且你可以选择导出的格式，一种是 DER 格式，一种是 Base64 格式。
# DER 是16进制格式的，而 Base64 是 ASCII 编码的。DER 格式的直接含有公钥，而 Base64 的则需要解码。
# 下面就是一个 Base64 格式的证书，在 BEGIN 和 END 行之间的就是证书的内容。
# 这样它可以被导入
-----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-----
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.
# 注释 ：CA 在颁发证书前需要检查证书申请中的信息的正确性。CA 需要确保申请人和申请表上的资料一致，
# 或者说 CA 需要确保申请表上的申请人的确拥有该私钥。
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.
# 注释 ：一个 CA 可以对另外一个 CA 颁发一个证书。当校验一个证书时，一方需要验证该证书的颁发者的证书。
# 这样一直查上去，直到它可以确信一个证书为止。它可以决定只信任有限的 CA ，以减少碰到证书链中假冒证书的机会
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.
# 注释 ：就像前面提到的，每个证书都需要上级的证书才能证明其真实性和有效性。总不能一直持续下去，所以存在一个顶级的 CA 。
# 这个顶级 CA 的证书是自签名的，也就是自己承认自己的真实性、有效性、权威性。
# 所以在顶级 CA 的证书中，它的 subject 和 issuer 的值是一样的。
# 所以要小心那些自签名的证书。所以根 CA 的证书必须被广泛传播，以让大部分人都知道。
# 浏览器一般都预先配置了信任那些 well-known 的 CA
A number of companies, such as and have established themselves as Certificate Authorities. These companies provide the following services:
# 注释 ：有很多的公司，例如 Thawte 和 VeriSign 都用于自己的 CA 。它也对外提供下面的服务 ：
# -）1、验证证书的请求
# -）2、处理证书的请求
# -）3、发出/管理证书
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.
# 注释 ：你也可以建立属于你自己的 CA 。
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.
# 注释 ：建立一个 CA 需要做很多的事情，其中很重要的一项就是对证书的管理。CA 不仅仅只是发放证书而已，也需要无干里。
# 也即使它们决定一个证书的有效期、延长证书的有效期、定期维护一个 CRL （证书收回列表，证书已经发出，但不再有效）。
# 要验证证书的有效性，需要联系发放该证书的 CA 检查 CRL ，这一般不是自动的。
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.
# 注释 ：假如你使用一个 CA 而该 CA 并没有被浏览器所预先配置，则你需要导入该 CA 的证书到浏览器中，以允许浏览器验证那些由该 CA
# 所签名的服务器的证书。这么做可能有些危险，因为一旦导入了该 CA 的证书，则浏览器会自动接受所有由该 CA 所签名的证书。
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.
# 注释 ：SSL 协议是一个协议层，它可以被放置于一个可靠的面向连接的网络层协议（例如 TCP/IP）和应用层协议（HTTP）之间，
# SSL 在客户端和服务器之间提供安全通信，这是通过通信双方的相互认证实现、数字前面和加密实现的。
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.
# 注释 ：SSL 协议被设计为支持很多的加密算法、消息摘要、签名。这允许针对特定的服务器来选择特定的算法， 同时该协议必须具备可扩展性。
# 客户端和服务器端在建立协议会话的开始就需要对一些参数进行协商。
# 注释 ：下面是 SSL 协议的各个版本
| Version | Source | Description | Browser Support |
|---|---|---|---|
| SSL v2.0 | Vendor Standard (from Netscape Corp.) [] |
First SSL protocol for which implementations exists
# 注释 ：SSL v2.0 是第一个 SSL 协议。 |
- NS Navigator 1.x/2.x - MS IE 3.x - Lynx/2.8+OpenSSL |
| SSL v3.0 |
Expired Internet Draft (from Netscape Corp.) []
# 注释 ：SSL v3.0 是已经
# 过期的Internet 草案 |
Revisions to prevent specific security attacks, add non-RSA ciphers, and
support for certificate chains
# 注释 ：SSL v3.0 是对 V2.0 的一个修订，用于防止一些安全攻击、增加非 RSA
的密
# 码、支持证书链 |
- NS Navigator 2.x/3.x/4.x - MS IE 3.x/4.x - Lynx/2.8+OpenSSL |
| TLS v1.0 |
Proposed Internet Standard (from IETF) []
# 注释 ：TLS v1.0 是已经提交
# 的 Internet 标准 |
Revision of SSL 3.0 to update the MAC layer to HMAC, add block padding for
block ciphers, message order standardization and more alert messages.
# 注释 ：TLS v1.0 是对 SSL v3.0 的修订版，更新 MAC 层为 HMAC
层，
# 增加 block padding ，消息顺序标准化、以及更多的告警信息 |
- Lynx/2.8+OpenSSL |
There are a number of versions of the SSL protocol, as shown in . As noted there, one of the benefits in SSL 3.0 is that it adds support of certificate chain loading. This feature allows a server to pass a server certificate along with issuer certificates to the browser. Chain loading also permits the browser to validate the server certificate, even if Certificate Authority certificates are not installed for the intermediate issuers, since they are included in the certificate chain. SSL 3.0 is the basis for the Transport Layer Security [] protocol standard, currently in development by the Internet Engineering Task Force (IETF).
# 注释 ：SSL 协议有几个版本，SSL v3.0 的一个好处就是它增加了对证书链加载的支持。该功能允许一个服务器把一个服务器证书以及给它颁发证书的 CA
# 的证书一起传递给浏览器。证书链的加载同样允许浏览器验证服务器的证书，即使中间的 CA 的 证书没有事先安装。
# SSL v3.0 是 TLS （传输层安全）的基础，而 TLS 当前是处于开发期
The SSL session is established by following a handshake sequence between client and server, as shown in . This sequence may vary, depending on whether the server is configured to provide a server certificate or request a client certificate. Though cases exist where additional handshake steps are required for management of cipher information, this article summarizes one common scenario: see the SSL specification for the full range of possibilities.
# 注释 ：SSL 会话的是通过客户机和服务器之间的 handshakre 序列建立的。就象图-1。
# 这个序列取决于服务器是否配置为提供一个服务器证书或者要求客户端的证书。
Once an SSL session has been established it may be reused, thus avoiding the performance penalty of repeating the many steps needed to start a session. For this the server assigns each SSL session a unique session identifier which is cached in the server and which the client can use on forthcoming connections to reduce the handshake (until the session identifer expires in the cache of the server).
# 注释 ：一旦一个 SSL 会话被建立，它可以被重用。这主要是处于性能上的考虑，可以减少很多启动一个会话的步骤。
# 所以服务器会为每个 SSL 会话分配一个唯一的 session identifier（会话标识），它被缓存在服务器中，客户机可以用它
# 来继续之前的连接以减少 handshake 的过程。
# 注释 ：不过这个 session identifier 是有有效期，会过期的。
: Simplified SSL
Handshake Sequence
The elements of the handshake sequence, as used by the client and server, are listed below:
# 注释 ：下面介绍上面的过程
# -）1、首先是 Hello 阶段（用于协商一些参数，包括 session key）
# -）2、服务器发送自己的证书给客户机，并要求客户机的证书
# -）3、客户机发送自己的证书
# -）4、交换 Cipher suite 并完整握手过程
The first step, Cipher Suite Negotiation, allows the client and server to choose a Cipher Suite supportable by both of them. The SSL3.0 protocol specification defines 31 Cipher Suites. A Cipher Suite is defined by the following components:
# 注释 ：第一步中，Ciper Suite Negotiation ，允许客户机和服务器选择一个双方都支持的 Ciper suite 。SSL v3.0 协议定义了 31 种 Ciper suites 。
# 一个 Ciper Suite 由下面的组件组成 ：
# -）1、key 交换方法
# -）2、用于数据传输的 Cipher
# -）3、用于建立消息认证代码（MAC）的消息摘要
These three elements are described in the sections that follow.
# 注释 ：下面分别介绍这3个组件
The key exchange method defines how the shared secret symmetric cryptography key used for application data transfer will be agreed upon by client and server. SSL 2.0 uses RSA key exchange only, while SSL 3.0 supports a choice of key exchange algorithms including the RSA key exchange when certificates are used, and Diffie-Hellman key exchange for exchanging keys without certificates and without prior communication between client and server.
# 注释 ：key 交换方法定义 share secrete （一个对称加密 key，用于数据传输）如何协商。SSL 2.0 使用只使用 RSA key ，而 SSL v3.0 则支持包括 RSA
# （使用证书的时候）、Diffie-Hellman key exchange（不使用证书）
One variable in the choice of key exchange methods is digital signatures -- whether or not to use them, and if so, what kind of signatures to use. Signing with a private key provides assurance against a man-in-the-middle-attack during the information exchange used in generating the shared key [, p516].
# 注释 ：在 key 交换方法中的一个变种就是数字签名。是否使用它，使用什么类型的数字签名。 使用私钥签名可以确保防止在交换过程中的 man-in-middle
# 攻击
SSL uses the conventional cryptography algorithm (symmetric cryptography) described earlier for encrypting messages in a session. There are nine choices, including the choice to perform no encryption:
# 注释 ：SSL 使用传统加密算法（对称加密），有9个可选的类型，包括不加密 ，分别如下 ：
Here "CBC" refers to Cipher Block Chaining, which means that a portion of the previously encrypted cipher text is used in the encryption of the current block. "DES" refers to the Data Encryption Standard [, ch12], which has a number of variants (including DES40 and 3DES_EDE). "Idea" is one of the best and cryptographically strongest available algorithms, and "RC2" is a proprietary algorithm from RSA DSI [, ch13].
# 注释 ：CBC 表示 Cipher Block Chaning 。DES 表示 Data Encryption Standard、IDEA 则是目前最好的一种加密算法。而 RC2 则是属于 RSA DSI
# 的一种私有算法。
The choice of digest function determines how a digest is created from a record unit. SSL supports the following:
# 注释 ：摘要函数定义一个消息摘要如何生成。SSL 支持下面几种，包括不生成摘要
# -）1、不生成摘要
# -）2、MD5 算法：摘要是 128 bit 长的 hash 值
# -）3、SHA-1 ，摘要是 160 bit 长的 hash 值
# 补充 ：在 IE 中，摘要被称为”微缩图“，用16进制表示，如果是40 bit 长的则是 SHA-1 。
The message digest is used to create a Message Authentication Code (MAC) which is encrypted with the message to provide integrity and to prevent against replay attacks.
# 注释 ：消息摘要用于建立 MAC ，它和消息本身被加密，以提供完整性，和防止重放攻击
The handshake sequence uses three protocols:
# 注释 ：握手序列使用3中协议 ：
# -）1、SSL 握手协议，用于完成客户机和服务器的 SSL 会话建立
# -）2、SSL Change Cipher Spec 协议 ：用于真正建了针对该会话的 Cipher suite 协商
# -）3、SSL Alert 协议 ：在通信双方传送 SSL 错误消息
These protocols, as well as application protocol data, are encapsulated in the SSL Record Protocol, as shown in . An encapsulated protocol is transferred as data by the lower layer protocol, which does not examine the data. The encapsulated protocol has no knowledge of the underlying protocol.
# 注释 ：这些协议和应用层（HTTP）协议数据，被封装在 SSL Record Protocol 内，就像图-2。
: SSL Protocol
Stack
The encapsulation of SSL control protocols by the record protocol means that if an active session is renegotiated the control protocols will be transmitted securely. If there were no session before, then the Null cipher suite is used, which means there is no encryption and messages have no integrity digests until the session has been established.
The SSL Record Protocol, shown in , is used to transfer application and SSL Control data between the client and server, possibly fragmenting this data into smaller units, or combining multiple higher level protocol data messages into single units. It may compress, attach digest signatures, and encrypt these units before transmitting them using the underlying reliable transport protocol (Note: currently all major SSL implementations lack support for compression).
# 注释 ：SSL Record 协议，就像图-3 ，用于传输应用层和 SSL 控制数据。它可以被压缩，追加数字签名
: SSL Record
Protocol
One common use of SSL is to secure Web HTTP communication between a browser
and a webserver. This case does not preclude the use of non-secured HTTP. The
secure version is mainly plain HTTP over SSL (named HTTPS), but with one major
difference: it uses the URL scheme https rather than
http and a different server port (by default 443). This mainly is
what
provides to you for the Apache webserver...
# 注释 ：SSL 的一个常见用途就是实现客户机和服务器之间的 '安全 web HTTP 通信' 。
# HTTPS 实际上就是运行在 SSL 的明文 HTTP ，但它使用 https 而不是 http 作为 URL scheme ，而且端口默认是443 而不是 80 。
# 这些都是 mod_ssl 负责提供给 Apache 的。
Applied Cryptography, 2nd Edition, Wiley, 1996. See for various other materials by Bruce Schneier.
Specification of Abstract Syntax Notation One (ASN.1), 1988. See for instance .
The Directory - Authentication Framework. See for instance .
Public Key Cryptography Standards (PKCS), RSA Laboratories Technical Notes, See http://www.rsasecurity.com/rsalabs/pkcs/.
Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC2045. See for instance .
The SSL Protocol, 1995. See http://www.netscape.com/eng/security/SSL_2.html.
The SSL Protocol Version 3.0, 1996. See .
The TLS Protocol Version 1.0, 1999. See .
Available Languages: |
