您的位置：首页 > 运维架构 > Apache

Apache的SSL/TLS加密

2008-05-23 11:09 429 查看
在处理这个问题的时候，我遇到了一个意外，我使用了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.shserver(这个证书的名字是server)
./sign-server-cert.shserver
这里面有一些信息可以填写。主要是涉及到ServerName的选项，最好和httpd.conf中保持一致。然后拷贝生成的Server.*到conf下面的ssl.*对应的目录下。注意，这些文件都是配置的，配置文件在conf.d下面的ssl.conf。然后启动服务就可以了。
我本来认为还需要额外配置ssl，但事实上，默认的配置中已经包含了这一部分，详情请参考ssl.conf。
现在，我将SSL的使用过程简述如下。

SSL/TLS高强度加密：绪论

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

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

这里的内容主要是来源于IntroducingSSLandCertificatesusingSSLeay并经过作者FrederickJ.Hirsch许可。此文由OpenGroupResearchInstitute于1997年夏，发表在WebSecurity:AMatterofTrust,WorldWideWebJournal,Volume2,Issue3,Summer1997，肯定意见请反馈给FrederickHirsch(原作者)，反对意见请反馈给RalfS.Engelschall(
mod_ssl
的作者)。




密码技术

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

密码系统

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

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

常规密码
又称为对称密码，需要发送者和接收者共同持有一个密钥：一小段用来加密和解密的秘密信息。如果这个密钥是保密的，那么这条消息除了发送者和接受者以外可能没有人可以阅读。如果Alice和银行共同持有一个密钥，则可以互相发送保密信息。但是，私有通讯密钥的选择行为本身，却可能不是无懈可击的。
公共密钥密码
又称为不对称密码，定义了一种使用两个密钥的算法以解决密钥交换问题，一个密钥用于加密，另一个用于解密，从而使简单公布一个密钥(公共的密钥，简称：公钥)而保留其他的(私有的密钥，简称：私钥)以接收保密消息成为可能。
任何人都可以用公钥加密一条消息，而仅允许私钥的持有者阅读。如此，Alice就可能使用公钥加密其保密消息，发送给私钥的持有者(银行)，只有银行能够对它解密。

消息摘要

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

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

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

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

数字签名

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

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

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




证书

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

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

证书的内容

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

表1:CertificateInformation

Subject
DistinguishedName,PublicKey
Issuer
DistinguishedName,Signature
PeriodofValidity
NotBeforeDate,NotAfterDate
AdministrativeInformation
Version,SerialNumber
ExtendedInformation
BasicConstraints,NetscapeFlags,etc.
识别名用于在一个特定的上下文中指明身份，比如，一个个体可能有一个个人证书，同时还有一个其雇佣者的证书。X.509标准[X509]中定义了识别名的各个项及其名称和缩写(见表2)。

表2:DistinguishedNameInformation

DNField
Abbrev.
Description
Example
CommonName
CN
Namebeingcertified
CN=JoeAverage
OrganizationorCompany
O
Nameisassociatedwiththis
organization
O=SnakeOil,Ltd.
OrganizationalUnit
OU
Nameisassociatedwiththis
organizationunit,suchasadepartment
OU=ResearchInstitute
City/Locality
L
NameislocatedinthisCity
L=SnakeCity
State/Province
ST
NameislocatedinthisState/Province
ST=Desert
Country
C
NameislocatedinthisCountry(ISOcode)
C=XZ
证书机构可能会定义规定哪些识别名是可选的，而哪些是必须的一个规范，还可能对项的内容和证书使用人数有所要求。比如，一个Netscape浏览器要求证书中的CommonName项必须是服务器名称，此名称可以是服务器域名的通配模式，形如：
*.snakeoil.com
。

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

ExampleofaPEM-encodedcertificate(snakeoil.crt)

-----BEGINCERTIFICATE-----

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==

-----ENDCERTIFICATE-----

证书机构

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

证书链

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

建立顶级CA

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

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

验证证书的申请

处理证书的申请

授予和管理证书

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

证书的管理

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

说明

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




安全套接字层(SSL)

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

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

表4:VersionsoftheSSLprotocol

Version
Source
Description
BrowserSupport
SSLv2.0
VendorStandard(fromNetscapeCorp.)[SSL2]
FirstSSLprotocolforwhichimplementationsexists
-NSNavigator1.x/2.x
-MSIE3.x
-Lynx/2.8+OpenSSL
SSLv3.0
ExpiredInternetDraft(fromNetscapeCorp.)[SSL3]
Revisionstopreventspecificsecurityattacks,addnon-RSAciphers,andsupportforcertificatechains
-NSNavigator2.x/3.x/4.x
-MSIE3.x/4.x
-Lynx/2.8+OpenSSL
TLSv1.0
ProposedInternetStandard(fromIETF)[TLS1]
RevisionofSSL3.0toupdatetheMAClayertoHMAC,addblockpaddingforblockciphers,messageorderstandardizationandmorealertmessages.
-Lynx/2.8+OpenSSL
如表4所示，SSL协议有多种版本。SSL3.0的一个优点是增加了对加载证书链的支持，以允许服务器在发给浏览器的授予者证书上附加一个服务器证书。链的加载也允许浏览器验证服务器证书，即使对此授予者的证书机构证书并没有安装，因为它已经包含在这个证书链中了。SSL3.0目前正由InternetEngineeringTaskForce(IETF)研发，是传输层安全[TLS]协议标准的基础。

会话的建立

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

说明

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



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

协商用于数据传输的密码组

建立并共享客户端和服务器的会话密钥

可选的客户端对服务器的认证

可选的服务器对客户端的认证

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

密钥交换法

数据传输密码

建立消息认证代码(MessageAuthenticationCode[MAC])的消息摘要

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

密钥交换方法

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

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

数据传输密码

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

Noencryption

StreamCiphers

RC4with40-bitkeys

RC4with128-bitkeys

CBCBlockCiphers

RC2with40bitkey

DESwith40bitkey

DESwith56bitkey

Triple-DESwith168bitkey

Idea(128bitkey)

Fortezza(96bitkey)

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

摘要函数

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

Nodigest(Nullchoice)

MD5,a128-bithash

SecureHashAlgorithm(SHA-1),a160-bithash

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

握手序列协议

握手序列使用三个协议：

SSLHandshakeProtocol，以完成客户端和服务器之间对话的建立。

SSLChangeCipherSpecProtocol，以实际建立对话用密码组的约定。

SSLAlertProtocol，在客户端和服务器之间传输SSL出错消息。

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



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

数据传输

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



Figure3:SSLRecordProtocol

保护HTTP通讯

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




References

[AC96]
BruceSchneier,AppliedCryptography,2ndEdition,Wiley,1996.Seehttp://www.counterpane.com/forvariousothermaterialsbyBruceSchneier.
[X208]
ITU-TRecommendationX.208,SpecificationofAbstractSyntaxNotationOne(ASN.1),1988.Seeforinstancehttp://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I.
[X509]
ITU-TRecommendationX.509,TheDirectory-AuthenticationFramework.Seeforinstancehttp://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509.
[PKCS]
PublicKeyCryptographyStandards(PKCS),RSALaboratoriesTechnicalNotes,Seehttp://www.rsasecurity.com/rsalabs/pkcs/.
[MIME]
N.Freed,N.Borenstein,MultipurposeInternetMailExtensions(MIME)PartOne:FormatofInternetMessageBodies,RFC2045.Seeforinstancehttp://ietf.org/rfc/rfc2045.txt.
[SSL2]
KippE.B.Hickman,TheSSLProtocol,1995.Seehttp://www.netscape.com/eng/security/SSL_2.html.
[SSL3]
AlanO.Freier,PhilipKarlton,PaulC.Kocher,TheSSLProtocolVersion3.0,1996.Seehttp://www.netscape.com/eng/ssl3/draft302.txt.
[TLS1]
TimDierks,ChristopherAllen,TheTLSProtocolVersion1.0,1999.Seehttp://ietf.org/rfc/rfc2246.txt.

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

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

--无名氏
本文讨论对其他SSL方案的向下兼容性。mod_ssl并不是Apache唯一存在的SSL方案，另外还有四种主要的产品：BenLaurie的免费的Apache-SSL(出现在1998年，与mod_ssl同源)，RedHat商业化的SecureWebServer(基于mod_ssl)，Covalent商业化的RavenSSLModule(同样基于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-SSL1.x&mod_ssl2.0.x兼容性:
SSLEnable

SSLEngineon

已强化
SSLDisable

SSLEngineoff

已强化
SSLLogFile
file
SSLLog
file
已强化
SSLRequiredCiphers
spec
SSLCipherSuite
spec
被更名
SSLRequireCipher
c1...
SSLRequire%{SSL_CIPHER}in{"
c1
",...}

无显著改变
SSLBanCipher
c1...
SSLRequirenot(%{SSL_CIPHER}in{"
c1
",...})

无显著改变
SSLFakeBasicAuth

SSLOptions+FakeBasicAuth

被合并
SSLCacheServerPath
dir
-
已废除
SSLCacheServerPort
integer
-
已废除
Apache-SSL1.x兼容性:
SSLExportClientCertificates

SSLOptions+ExportCertData

被合并
SSLCacheServerRunDir
dir
-
不再支持
Sioux1.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
-
不再支持
Stronghold2.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:自定义日志加密格式

FunctionCall
格式说明
%...{version}c

SSL协议版本
%...{cipher}c

SSL密码
%...{subjectdn}c

客户证书的SubjectDistinguishedName
%...{issuerdn}c

客户证书的IssuerDistinguishedName
%...{errcode}c

客户证书的出错代码(数值)
%...{errstr}c

客户证书的出错信息(文字)

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

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

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




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

仅使用SSLv2的服务器

仅接受高强度加密请求的服务器

以服务器为网关的加密

更强的针对目录的加密需求

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

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

httpd.conf

SSLProtocol-all+SSLv2

SSLCipherSuiteSSLv2:+HIGH:+MEDIUM:+LOW:+EXP


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

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

httpd.conf

SSLProtocolall

SSLCipherSuiteHIGH:MEDIUM


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

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

httpd.conf

#允许在初始握手阶段使用所有的密码，以允许对外服务器通过SGC功能提升密码组

SSLCipherSuiteALL:!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参数的重协商。因此，其解决方案成了：

#在一般情况下的处理是宽松的

SSLCipherSuiteALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL


<Location/strong/area>

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

SSLCipherSuiteHIGH:MEDIUM

</Location>





客户认证和访问控制

简单的基于证书的客户认证

选择性的基于证书的客户认证

特殊的基于证书的客户认证

intranet和internet的认证

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

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

httpd.conf

#requireaclientcertificatewhichhastobedirectly

#signedbyourCAcertificateinca.crt

SSLVerifyClientrequire

SSLVerifyDepth1

SSLCACertificateFileconf/ssl.crt/ca.crt


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

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

httpd.conf

SSLVerifyClientnone

SSLCACertificateFileconf/ssl.crt/ca.crt


<Location/secure/area>

SSLVerifyClientrequire

SSLVerifyDepth1

</Location>


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

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

第一种方法：

httpd.conf

SSLVerifyClientnone

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


SSLVerifyClientrequire

SSLVerifyDepth5

SSLCACertificateFileconf/ssl.crt/ca.crt

SSLCACertificatePathconf/ssl.crt

SSLOptions+FakeBasicAuth

SSLRequireSSL

AuthName"SnakeOilAuthentication"

AuthTypeBasic

AuthBasicProviderfile

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

requirevalid-user

</Directory>

httpd.passwd
/C=DE/L=Munich/O=SnakeOil,Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA

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

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

第二种方法：

httpd.conf
SSLVerifyClientnone

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


SSLVerifyClientrequire

SSLVerifyDepth5

SSLCACertificateFileconf/ssl.crt/ca.crt

SSLCACertificatePathconf/ssl.crt

SSLOptions+FakeBasicAuth

SSLRequireSSL

SSLRequire%{SSL_CLIENT_S_DN_O}eq"SnakeOil,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
SSLCACertificateFileconf/ssl.crt/company-ca.crt


<Directory/usr/local/apache2/htdocs>

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

Orderdeny,allow

Denyfromall

Allowfrom192.168.1.0/24

</Directory>


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

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

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

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


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

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

SSLVerifyClientoptional

SSLVerifyDepth1

SSLOptions+FakeBasicAuth+StrictRequire

SSLRequire%{SSL_CIPHER_USEKEYSIZE}>=128


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

RewriteEngineon

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

RewriteCond%{HTTPS}!=on

RewriteRule.*-[F]


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

Satisfyany


#控制网络访问

Orderdeny,allow

Denyfromall

Allow192.168.1.0/24


#HTTP基本认证

AuthTypebasic

AuthName"ProtectedIntranetArea"

AuthBasicProviderfile

AuthUserFileconf/protected.passwd

Requirevalid-user

</Directory>

                                            

                                        

                        
                        内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息 
                    

                    

                    

                        

                         标签： 
                                                

                        

                    


                

            


            

                
相关文章推荐

                

                
            

        

        

            

            
            

                

                    
新的分享

                    

                        
                    

                

            


            

                

                    
章节导航