Apache的SSL/TLS加密

       在处理这个问题的时候，我遇到了一个意外，我使用了X-Windows的工具修改了httpd.conf，导致httpd无法启动，报的错误是[Hint: SSLCertificateFile]。正好此时，我覆盖了SSL的认证文件，导致我认为问题出在SSL上，从而导致问题出的比较厉害。

       但也因为这样，我对SSL的应用也更加的了解了。如果使用指令直接生成证书文件当然特别麻烦了，有别的办法。http://www.openssl.org/contrib/ssl.ca-0.1.tar.gz 可以download一些脚本程序。

       解压后，可以执行下列脚本。

       ./new-root-ca.sh                         (生成根证书)

       ./new-server-cert.sh server              (这个证书的名字是server)

       ./sign-server-cert.sh server

       这里面有一些信息可以填写。主要是涉及到ServerName的选项，最好和httpd.conf中保持一致。然后拷贝生成的Server.*到conf下面的ssl.*对应的目录下。注意，这些文件都是配置的，配置文件在conf.d下面的ssl.conf。然后启动服务就可以了。

       我本来认为还需要额外配置ssl，但事实上，默认的配置中已经包含了这一部分，详情请参考ssl.conf。

       现在，我将SSL的使用过程简述如下。

 

SSL/TLS高强度加密：绪论

标准的好处就是你有充足的选择。如果确实不喜欢现存的标准，你只需等待来年发布一个你喜欢的新标准。

-- A. Tanenbaum, "Introduction to Computer Networks"

作为绪论，本文针对的是熟悉Web、HTTP、Apache的读者而不是安全方面的专家，它不是SSL协议的权威性指南，不讨论在一个组织中管理证书的特殊技术，也没有重要的法定专利声明及摘录和引用限制。但是，本文会通过综合讲述各种概念、定义和例子，给mod_ssl的使用者提供背景资料，作为更深入探索的起点。

这里的内容主要是来源于Introducing SSL and Certificates using SSLeay并经过作者Frederick J. Hirsch许可。此文由 Open Group Research Institute于1997年夏，发表在Web Security: A Matter of Trust, World Wide Web Journal, Volume 2, Issue 3, Summer 1997，肯定意见请反馈给Frederick Hirsch(原作者)，反对意见请反馈给Ralf S. Engelschall(mod_ssl的作者)。

密码技术

要理解SSL就必须理解密码系统、消息摘要函数(单向或散列函数)和数字签名，这些技术是许多文献所讨论的主题(比如[AC96)，提供了保密性、完整性和认证的基础。

密码系统

假 设Alice想给她的银行发一个消息以划转资金，并希望这个消息是保密的，因为其中含有她的帐号和划转金额等信息。一种方案是使用密码系统，将要传输的信 息转变为加密形式，从而只能为希望他读懂的人读懂。一旦加密为这种形式，这条消息也许只能用一个密钥来破译，如果没有，那么这条信息毫无用处，因为好的密 码系统可以使破译难度高到入侵者认为原文不值得他们花费那么大的努力。

密码系统有两大类：常规的和公共密钥。

常规密码

又 称为对称密码，需要发送者和接收者共同持有一个密钥：一小段用来加密和解密的秘密信息。如果这个密钥是保密的，那么这条消息除了发送者和接受者以外可能没 有人可以阅读。如果Alice和银行共同持有一个密钥，则可以互相发送保密信息。但是，私有通讯密钥的选择行为本身，却可能不是无懈可击的。

公共密钥密码

又称为不对称密码，定义了一种使用两个密钥的算法以解决密钥交换问题，一个密钥用于加密，另一个用于解密，从而使简单公布一个密钥(公共的密钥，简称：公钥)而保留其他的(私有的密钥，简称：私钥)以接收保密消息成为可能。

任何人都可以用公钥加密一条消息，而仅允许私钥的持有者阅读。如此，Alice就可能使用公钥加密其保密消息，发送给私钥的持有者(银行)，只有银行能够对它解密。

消息摘要

虽然Alice可能加密其消息使它称为私有的，但仍应注意到某些人可能会篡改或替换其原始消息，以划转资金到他们自己的帐户。一种保证Alice消息完整性的方法是同时发一个其消息的简单摘要给银行，供银行与消息本身比对，如果相符则消息正确。

这样的方法被称为消息摘要、单向函数或散列函数。消息摘要用于对较大而且变长的消息建立较短而且等长的一种表述，其设计使将摘要还原成消息极其困难，而且对两个不同的消息几乎不可能生成相同的摘要，从而排除了替换一个消息为另一个而维持相同摘要的可能性。

Alice面临的另一个挑战是要保证摘要发送到银行的安全，如此，才能确保消息的完整性。

一种解决方法是在摘要中包含数字签名。

数字签名

当Alice发送消息到银行，银行需要确认此消息的确是她发送的，而不是入侵者盗用其帐号。为此，可以在消息中包含一个由Alice建立的数字签名。

数字签名是以加密的消息摘要和其他信息(比如一个流水号)以及发送者的私有密钥建立的。虽然任何人都可能用公共密钥解密签名，但是只有签发者知道其私有密钥，也就是，只有密钥的持有者才能签发。包含在签名中的摘要只对该消息有效，以确保没有人可以改变摘要而保持签名不变。

为了避免签名日后被入侵者破译和再利用，签名包含有一个流水号。如此，万一(只是假设)Alice并没有发送此消息，虽然她可能真的签发过，银行可以免遭其欺诈性指控。

证书

虽然Alice可能已经发送了一个保密的消息给银行，签了名，并可以保证消息的完整性，但是她仍然需要确认她的确是在和那个银行通讯，也就是说，她需要确认她用的公共密钥的确对应于银行用的私有密钥。同样，银行也需要验证此消息的签名的确对应于Alice的签名。

如果各部分有验证其余部分一致性的证书，以确认公共密钥，并是由一个可以信任的代理所签发的，那么他们双方都可以肯定其通讯对象的身份。这个可以信任的代理称为证书机构(Certificate Authority)，其证书用于认证。

证书的内容

与一个公共密钥关联的证书有一个主题，即一个个体或者服务器或者其他实体的真实身份，如表1所示。主题中的信息包含身份信息(识别名[Distinguished Name])和公共密钥，还包括发布此证书的证书机构的名称和签名以及证书的有效期限，还可能会有证书机构监管者信息和流水号等附加信息。

表 1: Certificate Information

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.

识别名用于在一个特定的上下文中指明身份，比如，一个个体可能有一个个人证书，同时还有一个其雇佣者的证书。X.509标准[X509]中定义了识别名的各个项及其名称和缩写(见表2)。

表 2: Distinguished Name Information

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

证书机构可能会定义规定哪些识别名是可选的，而哪些是必须的一个规范，还可能对项的内容和证书使用人数有所要求。比如，一个Netscape浏览器要求证书中的Common Name项必须是服务器名称，此名称可以是服务器域名的通配模式，形如：*.snakeoil.com 。

证书的二进制形式用ASN.1记号法[X208] [PKCS] 表示，记号法定义了如何表示内容，编码规则定义了如何将信息转变成二进制形式。证书的二进制编码使用了基于更通用的基本编码规则(Basic Encoding Rules[BER])的识别名编码规则(Distinguished Encoding Rules[DER])。为了在不能处理二进制的情况下进行传输，二进制形式用Base64编码方式[MIME]转换成ASCII形式，其编码结果是以开始和结束符号分隔的若干的行，称为PEM形式(其名称来源于"Privacy Enhanced Mail")，如下所示：

Example of a PEM-encoded certificate (snakeoil.crt)

-----BEGIN CERTIFICATE-----

MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx

FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU
  
  
   
   25ha
  
  2UgVG93bjEXMBUG

A1UEChMOU
  
  
   
   25ha
  
  2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv

cml0eTEVMBMGA1UEAxMMU
  
  
   
   25ha
  
  2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz

bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL

MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h

a2UgVG93bjEXMBUGA1UEChMOU
  
  
   
   25ha
  
  2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl

cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc
  
  
   
   25ha
  
  2VvaWwuZG9tMR8wHQYJKoZIhvcN

AQkBFhB3d3dAc
  
  
   
   25ha
  
  2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB

gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b

vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa

lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV

HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB

gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt

2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7

dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==

-----END CERTIFICATE-----

证书机构

证书机构在授予证书前会验证证书的申请信息，以确认密钥对中私有密钥的持有实体。比如：如果Alice申请一个个人证书，则证书机构首先会确认Alice的确是申请证书的那个人。

证书链

一个证书机构也可能给另一个证书机构授予证书。所以，Alice可能需要检查证书的授予者，及其父授予者，直到找到一个她所信任的。她可以只信任由一个有限的授予者链所授予的证书，以减小这个链中"劣质"证书带来的风险。

建立顶级CA

如 前所述，每个证书要求其授予者指定证书主题中实体的有效性，直到最高一级的证书机构。这样就产生一个问题：最高一级的证书机构没有授予者，那么谁为它的证 书作担保呢？仅在这种情况下，此证书是"自签名的"，即证书的授予者和主题中的一样，所以，必须对自签名的证书备加注意。顶级机构广泛发布的公共密钥可以 减小信任这个密钥所带来的风险--这显然比其他某个人发布密钥并宣称他是证书机构要安全一些。浏览器被默认地配置为信任著名的证书机构。

许多公司是专业证书机构，如Thawte和VeriSign，提供如下服务：

• 验证证书的申请
• 处理证书的申请
• 授予和管理证书

自己建立一个证书机构也是可能的，虽然在Internet环境中有风险，但在验证个体或服务器较容易的Intranet环境中，会很有用。

证书的管理

建 立一个证书机构需要一个坚强的监管、技术和管理体系。证书机构不仅仅是授予证书，还必须管理证书的有效期和更新，并维护一个已授予的但已经失效的证书列表 (作废证书列表[Certificate Revocation Lists，或CRL])。比如，Alice作为公司雇员有资格申请证书，又如，Alice离开公司后需要作废此证书等。由于凭证书可以到处通行无阻，所 以不可能从证书本身看出已经作废，因此，验证证书的有效性就必须查作废证书列表(而这通常不是自动处理的一部分)。

说明

如果使用了一个浏览器没有默认配置的证书机构，则必须加载这个证书机构的证书进入浏览器，使浏览器可以验证由这个证书机构签发的服务器证书。这样做是有风险的，因为一旦加载，浏览器会接受由这个证书机构签发的所有证书。

安全套接字层(SSL)

安全套接字层协议是位于可靠的面向连接的网络层协议(如TCP/IP)和应用程序协议层(如HTTP)之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。

这个协议被设计为支持许多用于密码、摘要和签名的特定算法，允许因各种目的对特定的服务器选择算法，并允许采用新算法以得其利。其选择的协商操作发生在客户和服务器建立协议对话的开始阶段。

表 4: Versions of the SSL protocol

Version	Source	Description	Browser Support
SSL v2.0	Vendor Standard (from Netscape Corp.) [SSL2]	First SSL protocol for which implementations exists	- NS Navigator 1.x/2.x - MS IE 3.x - Lynx/2.8+OpenSSL
SSL v3.0	Expired Internet Draft (from Netscape Corp.) [SSL3]	Revisions to prevent specific security attacks, add non-RSA ciphers, and support for certificate chains	- 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) [TLS1]	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.	- Lynx/2.8+OpenSSL

如表4所 示，SSL协议有多种版本。SSL3.0的一个优点是增加了对加载证书链的支持，以允许服务器在发给浏览器的授予者证书上附加一个服务器证书。链的加载也 允许浏览器验证服务器证书，即使对此授予者的证书机构证书并没有安装，因为它已经包含在这个证书链中了。SSL3.0目前正由Internet Engineering Task Force(IETF)研发，是传输层安全[TLS]协议标准的基础。

会话的建立

SSL会话在客户端和服务器的握手过程之后建立，如Figure 1所示，其过程可能因服务器是否配置为支持服务器证书和是否要求有客户证书有所不同。虽然存在密码信息管理需要额外握手操作的情况，本文只说明其中有共性的部分，参见所有可能情况下的SSL规范。

说明

SSL会话一旦建立就可能是可重用的，以避免在初始会话时的性能损失和许多步骤的重复。为此，服务器为其后的连接缓存了为每个SSL会话设定的唯一的会话标志，以减少握手操作(直到服务器缓存中的会话标志过期为止)。

Figure 1: Simplified SSL Handshake Sequence

客户端和服务器的握手过程如下所示：

1. 协商用于数据传输的密码组
2. 建立并共享客户端和服务器的会话密钥
3. 可选的客户端对服务器的认证
4. 可选的服务器对客户端的认证

第一步的密码组协商，允许客户端和服务器选择一个共同支持的密码组。SSL3.0协议规范定义了31个密码组。密码组由以下各部分组成：

• 密钥交换法
• 数据传输密码
• 建立消息认证代码(Message Authentication Code[MAC])的消息摘要

此三个组成部分说明如下。

密钥交换方法

密钥交换法指明如何在客户端和服务器的数据传输中使用共享的对称密钥。SSL2.0仅使用RSA密钥交换，而SSL3.0可以在启用证书时，选择使用包括RSA的多种密钥交换算法，以及无须证书和客户端-服务器先期通讯的Diffie-Hellman密钥交换法。

密钥交换法的一个变数是数字签名(可用可不用)，如果用，用哪一种。私有密钥配合签名可以确保在生成共享密钥[AC96, p516]的信息交换过程中抵御攻击。

数据传输密码

SSL使用在前面加密对话消息中有所讲述的常规密码算法(对称密码)，可以有包括不加密在内的九种选择：

• No encryption
• Stream Ciphers
• • RC4 with 40-bit keys
  • RC4 with 128-bit keys
• CBC Block Ciphers
• • RC2 with 40 bit key
  • DES with 40 bit key
  • DES with 56 bit key
  • Triple-DES with 168 bit key
  • Idea (128 bit key)
  • Fortezza (96 bit key)

这里的"CBC"是Cipher Block Chaining，指在加密当前块时会用到先前已经加密的部分文本；"DES"是Data Encryption Standard[AC96, ch12]，有多个变种(包括DES40和3DES_EDE)；"Idea"是现有最好的最坚强的加密算法之一；"RC2"是RSADSI[AC96, ch13]的专属的算法。

摘要函数

摘要函数指明对一个记录单元如何建立摘要。SSL有如下支持：

• No digest (Null choice)
• MD5, a 128-bit hash
• Secure Hash Algorithm (SHA-1), a 160-bit hash

消息摘要用于建立加密的消息认证码(MAC)，与消息本身一同发送，以确保消息完整性并抵御还原攻击。

握手序列协议

握手序列使用三个协议：

• SSL Handshake Protocol ，以完成客户端和服务器之间对话的建立。
• SSL Change Cipher Spec Protocol ，以实际建立对话用密码组的约定。
• SSL Alert Protocol ，在客户端和服务器之间传输SSL出错消息。

这些协议和应用协议的数据用 SSL Record Protocol 进行封装，如Figure 2所示，在不检查数据的较底层的协议中传输。封装协议对其底层协议来说是未知的。

Figure 2: SSL Protocol Stack

SSL控制协议对记录协议的封装，使一个正在进行的对话在重协商其控制协议后得以安全地进行传输。如果事先没有建立对话，则会使用Null密码组，也就是说，在建立对话以前，不使用密码，且消息没有完整性摘要。

数据传输

SSL记录协议，如Figure 3所 示，用于客户端和服务器之间的传输应用和SSL控制数据，可能把数据分割成较小的单元，或者组合多个较高层协议数据为一个单元。在使用底层可靠传输协议传 输数据单元之前，它可能会对这些单元进行压缩、附着摘要签名和加密(注意：目前所有主要SSL的实现都缺乏对压缩的支持)。

Figure 3: SSL Record Protocol

保护HTTP通讯

SSL的一个常见的用途是保护浏览器和网络服务器之间的网络HTTP通讯，但这并排除应用于不加保护的HTTP。其方法主要是，对普通HTTP加以SSL保护(称为HTTPS)，但有一个重要的区别：它使用URL类型https而不是http ，而且使用不同的服务器端口(默认的是443)。mod_ssl为Apache网络服务器提供的功能主要就是这些了...

References

[AC96]

Bruce Schneier, Applied Cryptography, 2nd Edition, Wiley, 1996. See http://www.counterpane.com/ for various other materials by Bruce Schneier.

[X208]

ITU-T Recommendation X.208, Specification of Abstract Syntax Notation One (ASN.1), 1988. See for instance http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I.

[X509]

ITU-T Recommendation X.509, The Directory - Authentication Framework. See for instance http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509.

[PKCS]

Public Key Cryptography Standards (PKCS), RSA Laboratories Technical Notes, See http://www.rsasecurity.com/rsalabs/pkcs/.

[MIME]

N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC2045. See for instance http://ietf.org/rfc/rfc2045.txt.

[SSL2]

Kipp E.B. Hickman, The SSL Protocol, 1995. See http://www.netscape.com/eng/security/SSL_2.html.

[SSL3]

Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol Version 3.0, 1996. See http://www.netscape.com/eng/ssl3/draft302.txt.

[TLS1]

Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0, 1999. See http://ietf.org/rfc/rfc2246.txt.

 

 

SSL/TLS高强度加密：兼容性

所有PC都是兼容的。但是其中一些比另一些更兼容。

-- 无名氏

本文讨论对其他SSL方案的向下兼容性。mod_ssl并不是Apache唯一存在的SSL方案，另外还有四种主要的产品：Ben Laurie的免费的Apache-SSL(出现在1998年，与mod_ssl同源)，RedHat商业化的Secure Web Server(基于mod_ssl)，Covalent商业化的Raven SSL Module(同样基于mod_ssl)和C2Net的商业化产品Stronghold(直到Stringhold2.x都基于一个不同的演化分支Sioux，从Stronghold3.x起基于mod_ssl)。

使用mod_ssl的原因是，mod_ssl几乎提供了在大多数情况下能够兼容其他方案的功能的超集。事实上，兼容性包括三个方面：配置指令、环境变量和自定义日志功能。

配置指令

为了兼容SSL方案的配置指令，我们做了一个简单的对应：有直接对应的指令则简单对应，没有直接对应的指令则会在日志文件中产生警告信息。表1列出已实现对应的指令。目前仅对Apache-SSL1.x和mod_ssl2.0.x有完整的向下兼容支持，而仅支持Sioux1.x和Stronghold2.x的一部分，由于其接口中的特殊功能mod_ssl目前尚不支持。

表1: 配置指令的对应

旧指令	mod_ssl指令	说明
Apache-SSL 1.x & mod_ssl 2.0.x 兼容性:
SSLEnable	SSLEngine on	已强化
SSLDisable	SSLEngine off	已强化
SSLLogFile file	SSLLog file	已强化
SSLRequiredCiphers spec	SSLCipherSuite spec	被更名
SSLRequireCipher c1 ...	SSLRequire %{SSL_CIPHER} in {"c1", ...}	无显著改变
SSLBanCipher c1 ...	SSLRequire not (%{SSL_CIPHER} in {"c1", ...})	无显著改变
SSLFakeBasicAuth	SSLOptions +FakeBasicAuth	被合并
SSLCacheServerPath dir	-	已废除
SSLCacheServerPort integer	-	已废除
Apache-SSL 1.x 兼容性:
SSLExportClientCertificates	SSLOptions +ExportCertData	被合并
SSLCacheServerRunDir dir	-	不再支持
Sioux 1.x 兼容性:
SSL_CertFile file	SSLCertificateFile file	被更名
SSL_KeyFile file	SSLCertificateKeyFile file	被更名
SSL_CipherSuite arg	SSLCipherSuite arg	被更名
SSL_X509VerifyDir arg	SSLCACertificatePath arg	被更名
SSL_Log file	SSLLogFile file	被更名
SSL_Connect flag	SSLEngine flag	被更名
SSL_ClientAuth arg	SSLVerifyClient arg	被更名
SSL_X509VerifyDepth arg	SSLVerifyDepth arg	被更名
SSL_FetchKeyPhraseFrom arg	-	没有直接的对应；使用：SSLPassPhraseDialog
SSL_SessionDir dir	-	没有直接的对应；使用：SSLSessionCache
SSL_Require expr	-	没有直接的对应；使用：SSLRequire
SSL_CertFileType arg	-	不再支持
SSL_KeyFileType arg	-	不再支持
SSL_X509VerifyPolicy arg	-	不再支持
SSL_LogX509Attributes arg	-	不再支持
Stronghold 2.x 兼容性:
StrongholdAccelerator dir	-	不再支持
StrongholdKey dir	-	不再支持
StrongholdLicenseFile dir	-	不再支持
SSLFlag flag	SSLEngine flag	被更名
SSLSessionLockFile file	SSLMutex file	被更名
SSLCipherList spec	SSLCipherSuite spec	被更名
RequireSSL	SSLRequireSSL	被更名
SSLErrorFile file	-	不再支持
SSLRoot dir	-	不再支持
SSL_CertificateLogDir dir	-	不再支持
AuthCertDir dir	-	不再支持
SSL_Group name	-	不再支持
SSLProxyMachineCertPath dir	-	不再支持
SSLProxyMachineCertFile file	-	不再支持
SSLProxyCACertificatePath dir	-	不再支持
SSLProxyCACertificateFile file	-	不再支持
SSLProxyVerifyDepth number	-	不再支持
SSLProxyCipherList spec	-	不再支持

环境变量

当使用"SSLOptions +CompatEnvVars"时，会产生附加的、对应于现存官方mod_ssl变量的环境变量。表2列出了已实现的变量的演变。

表2: 环境变量的演变

旧变量	mod_ssl 变量	说明
SSL_PROTOCOL_VERSION	SSL_PROTOCOL	被更名
SSLEAY_VERSION	SSL_VERSION_LIBRARY	被更名
HTTPS_SECRETKEYSIZE	SSL_CIPHER_USEKEYSIZE	被更名
HTTPS_KEYSIZE	SSL_CIPHER_ALGKEYSIZE	被更名
HTTPS_CIPHER	SSL_CIPHER	被更名
HTTPS_EXPORT	SSL_CIPHER_EXPORT	被更名
SSL_SERVER_KEY_SIZE	SSL_CIPHER_ALGKEYSIZE	被更名
SSL_SERVER_CERTIFICATE	SSL_SERVER_CERT	被更名
SSL_SERVER_CERT_START	SSL_SERVER_V_START	被更名
SSL_SERVER_CERT_END	SSL_SERVER_V_END	被更名
SSL_SERVER_CERT_SERIAL	SSL_SERVER_M_SERIAL	被更名
SSL_SERVER_SIGNATURE_ALGORITHM	SSL_SERVER_A_SIG	被更名
SSL_SERVER_DN	SSL_SERVER_S_DN	被更名
SSL_SERVER_CN	SSL_SERVER_S_DN_CN	被更名
SSL_SERVER_EMAIL	SSL_SERVER_S_DN_Email	被更名
SSL_SERVER_O	SSL_SERVER_S_DN_O	被更名
SSL_SERVER_OU	SSL_SERVER_S_DN_OU	被更名
SSL_SERVER_C	SSL_SERVER_S_DN_C	被更名
SSL_SERVER_SP	SSL_SERVER_S_DN_SP	被更名
SSL_SERVER_L	SSL_SERVER_S_DN_L	被更名
SSL_SERVER_IDN	SSL_SERVER_I_DN	被更名
SSL_SERVER_ICN	SSL_SERVER_I_DN_CN	被更名
SSL_SERVER_IEMAIL	SSL_SERVER_I_DN_Email	被更名
SSL_SERVER_IO	SSL_SERVER_I_DN_O	被更名
SSL_SERVER_IOU	SSL_SERVER_I_DN_OU	被更名
SSL_SERVER_IC	SSL_SERVER_I_DN_C	被更名
SSL_SERVER_ISP	SSL_SERVER_I_DN_SP	被更名
SSL_SERVER_IL	SSL_SERVER_I_DN_L	被更名
SSL_CLIENT_CERTIFICATE	SSL_CLIENT_CERT	被更名
SSL_CLIENT_CERT_START	SSL_CLIENT_V_START	被更名
SSL_CLIENT_CERT_END	SSL_CLIENT_V_END	被更名
SSL_CLIENT_CERT_SERIAL	SSL_CLIENT_M_SERIAL	被更名
SSL_CLIENT_SIGNATURE_ALGORITHM	SSL_CLIENT_A_SIG	被更名
SSL_CLIENT_DN	SSL_CLIENT_S_DN	被更名
SSL_CLIENT_CN	SSL_CLIENT_S_DN_CN	被更名
SSL_CLIENT_EMAIL	SSL_CLIENT_S_DN_Email	被更名
SSL_CLIENT_O	SSL_CLIENT_S_DN_O	被更名
SSL_CLIENT_OU	SSL_CLIENT_S_DN_OU	被更名
SSL_CLIENT_C	SSL_CLIENT_S_DN_C	被更名
SSL_CLIENT_SP	SSL_CLIENT_S_DN_SP	被更名
SSL_CLIENT_L	SSL_CLIENT_S_DN_L	被更名
SSL_CLIENT_IDN	SSL_CLIENT_I_DN	被更名
SSL_CLIENT_ICN	SSL_CLIENT_I_DN_CN	被更名
SSL_CLIENT_IEMAIL	SSL_CLIENT_I_DN_Email	被更名
SSL_CLIENT_IO	SSL_CLIENT_I_DN_O	被更名
SSL_CLIENT_IOU	SSL_CLIENT_I_DN_OU	被更名
SSL_CLIENT_IC	SSL_CLIENT_I_DN_C	被更名
SSL_CLIENT_ISP	SSL_CLIENT_I_DN_SP	被更名
SSL_CLIENT_IL	SSL_CLIENT_I_DN_L	被更名
SSL_EXPORT	SSL_CIPHER_EXPORT	被更名
SSL_KEYSIZE	SSL_CIPHER_ALGKEYSIZE	被更名
SSL_SECKEYSIZE	SSL_CIPHER_USEKEYSIZE	被更名
SSL_SSLEAY_VERSION	SSL_VERSION_LIBRARY	被更名
SSL_STRONG_CRYPTO	-	mod_ssl不支持
SSL_SERVER_KEY_EXP	-	mod_ssl不支持
SSL_SERVER_KEY_ALGORITHM	-	mod_ssl不支持
SSL_SERVER_KEY_SIZE	-	mod_ssl不支持
SSL_SERVER_SESSIONDIR	-	mod_ssl不支持
SSL_SERVER_CERTIFICATELOGDIR	-	mod_ssl不支持
SSL_SERVER_CERTFILE	-	mod_ssl不支持
SSL_SERVER_KEYFILE	-	mod_ssl不支持
SSL_SERVER_KEYFILETYPE	-	mod_ssl不支持
SSL_CLIENT_KEY_EXP	-	mod_ssl不支持
SSL_CLIENT_KEY_ALGORITHM	-	mod_ssl不支持
SSL_CLIENT_KEY_SIZE	-	mod_ssl不支持

自定义日志功能

如果mod_ssl被静态编译进Apache或者被动态加载(以DSO方式)，则可以使用参考文档中说明的由mod_log_config提供的自定义日志格式。但是为了向下兼容，不能使用用于扩展任何模块中任何变量的扩展格式"%{varname}x"和附加的密码格式"%{name}c"。表3列出了已实现的格式。

表 3: 自定义日志加密格式

Function Call	格式说明
%...{version}c	SSL协议版本
%...{cipher}c	SSL密码
%...{subjectdn}c	客户证书的 Subject Distinguished Name
%...{issuerdn}c	客户证书的 Issuer Distinguished Name
%...{errcode}c	客户证书的出错代码(数值)
%...{errstr}c	客户证书的出错信息(文字)

 

SSL/TLS高强度加密：如何...?

这个问题的解决方案是简单而且直接的，只是为了给读者做做练习。

-- 标准教科书

由于SSL、HTTP、Apache三者共同对请求进行处理，这使得在支持SSL的web服务器上实现特殊的安全制约变得不那么简单。本节介绍了普 通情况下的解决方案，作为找出最终方案的第一步。采用这些方案以前，先要尽量地去理解，不了解其限制和相关性就贸然使用是最糟糕的了。

加密方案和强制性高等级安全

• 仅使用SSLv2的服务器
• 仅接受高强度加密请求的服务器
• 以服务器为网关的加密
• 更强的针对目录的加密需求

如何建立一个仅使用SSLv2的服务器？

可以这样建立一个仅使用SSLv2协议及其密码算法的服务器：

httpd.conf

SSLProtocol -all +SSLv2
SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP

如何建立一个仅接受高强度加密请求的SSL服务器？

如下设置为仅使用最强的七种密码算法：

httpd.conf

SSLProtocol all
SSLCipherSuite HIGH:MEDIUM

如何建立一个仅接受高强度加密请求的SSL服务器，而又允许对外浏览器使用更强的加密？

这个功能被称为以服务器为网关的加密(Server Gated Cryptography[SGC])，在随mod_ssl发布的README.GlobalID文 档中有详细说明。简单地说就是：服务器拥有一个由来自Verisign的一个特殊的CA证书签发的服务器身份证，从而在对外浏览器上实现高强度加密。其过 程如下：浏览器使用对外密码进行连接，服务器返回其全局ID身份证，浏览器校验后在后继HTTP通讯产生之前提升其密码组。现在的问题是：如何允许这样的 提升，而又强制性地使用高强度加密。换句话说就是：浏览器必须在开始连接时就使用高强度加密，或者提升到高强度加密，但是维持对外密码是不允许的。以下巧 妙地解决了这个问题：

httpd.conf

# 允许在初始握手阶段使用所有的密码，以允许对外服务器通过SGC功能提升密码组
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

<Directory /usr/local/apache2/htdocs>
# 但是最终会拒绝所有没有提升密码组的浏览器
SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
</Directory>

如何建立接受所有类型密码的SSL服务器，但对特定的URL实施高强度加密？

显然，不能使用服务器全局设置SSLCipherSuite，它会限制密码为强类型。但是，mod_ssl允许重配置针对目录的密码组，并自动进行一个带有服重新配置的SSL参数的重协商。因此，其解决方案成了：

# 在一般情况下的处理是宽松的
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

<Location /strong/area>
# 但对于 https://hostname/strong/area/ 及其以下的内容要求高强度密码
SSLCipherSuite HIGH:MEDIUM
</Location>

客户认证和访问控制

• 简单的基于证书的客户认证
• 选择性的基于证书的客户认证
• 特殊的基于证书的客户认证
• intranet和internet的认证

在知道所有客户的情况下，如何实现基于证书的客户认证？

如果你了解你的用户群体(比如：一个封闭的用户组)，正如在一个Intranet中，则可以使用一般的证书认证。所有要做的事情只是，建立由你自己的CA证书签发的客户证书ca.crt ，并依此证书校验客户。

httpd.conf

# require a client certificate which has to be directly
# signed by our CA certificate in ca.crt
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile conf/ssl.crt/ca.crt

如何针对一个特定的URL对客户实施基于证书的认证，而同时又允许任何客户访问服务器其余部分？

这又要用到mod_ssl提供的针对目录的重配置功能：

httpd.conf

SSLVerifyClient none
SSLCACertificateFile conf/ssl.crt/ca.crt

<Location /secure/area>
SSLVerifyClient require
SSLVerifyDepth 1
</Location>

如何针对某些URL对特定的客户实施基于证书的认证，而同时又允许任何客户访问服务器其余部分？

其关键在于对客户证书的各个组成部分进行验证，一般就是指验证 Distinguished Name (DN) 的全部或部分。有基于mod_auth_basic和基于SSLRequire类型的两种方法以验证。第一种方法适合用于客户完全属于不同类型，并为所有客户建立了密码数据库的情形；第二种方法适用于客户都属于一个被编码写入DN的公共分级的一部分的情形，因为匹配客户会更容易。

第一种方法：

httpd.conf

SSLVerifyClient      none

<Directory /usr/local/apache2/htdocs/secure/area>

SSLVerifyClient      require

SSLVerifyDepth       5

SSLCACertificateFile conf/ssl.crt/ca.crt

SSLCACertificatePath conf/ssl.crt

SSLOptions           +FakeBasicAuth

SSLRequireSSL

AuthName             "Snake Oil Authentication"

AuthType             Basic

AuthBasicProvider    file

AuthUserFile         /usr/local/apache2/conf/httpd.passwd

require              valid-user

</Directory>

httpd.passwd

/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA

/C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA

/C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA

第二种方法：

httpd.conf

SSLVerifyClient      none

<Directory /usr/local/apache2/htdocs/secure/area>

  SSLVerifyClient      require

  SSLVerifyDepth       5

  SSLCACertificateFile conf/ssl.crt/ca.crt

  SSLCACertificatePath conf/ssl.crt

  SSLOptions           +FakeBasicAuth

  SSLRequireSSL

  SSLRequire       %{SSL_CLIENT_S_DN_O}  eq "Snake Oil, Ltd." /

               and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}

</Directory>

如何要求来自Internet的客户使用强密码的HTTPS，并对其访问Intranet站点的子区域实施或者基本的或者客户证书的认证，而同时又允许Intranet的客户进行普通的HTTP访问？

假设Intranet客户的IP地址是192.160.1.0/24，Intranet站点子区域的URL是/subarea ，则可以在HTTPS虚拟主机以外这样配置(以同时作用于HTTPS和HTTP)：

httpd.conf

SSLCACertificateFile conf/ssl.crt/company-ca.crt

<Directory /usr/local/apache2/htdocs>

# subarea以外的区域只允许来自Intranet的访问

Order                deny,allow

Deny                 from all

Allow                from 192.168.1.0/24

</Directory>

<Directory /usr/local/apache2/htdocs/subarea>

# 在subarea以内，允许所有来自Intranet的访问，

# 但对来自Internet的访问，仅允许HTTPS+Strong-Cipher+Password

# 或者HTTPS+Strong-Cipher+Client-Certificate

# 如果使用了HTTPS，则确保使用高强度加密

# 同时允许客户以基本认证的形式认证

SSLVerifyClient      optional

SSLVerifyDepth       1

SSLOptions           +FakeBasicAuth +StrictRequire

SSLRequire           %{SSL_CIPHER_USEKEYSIZE} >= 128

# 强制来自Internet的客户使用HTTPS

RewriteEngine        on

RewriteCond          %{REMOTE_ADDR} !^192/.168/.1/.[0-9]+$

RewriteCond          %{HTTPS} !=on

RewriteRule          .* - [F]

# 允许网络访问和基本认证

Satisfy              any

# 控制网络访问

Order                deny,allow

Deny                 from all

Allow                192.168.1.0/24

# HTTP基本认证

AuthType             basic

AuthName             "Protected Intranet Area"

AuthBasicProvider    file

AuthUserFile         conf/protected.passwd

Require              valid-user

</Directory>