SSL与TLS 区别 以及介绍   
文章分类:Java编程 
SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和ＳＳＬ握手协议。
TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。
SSL是Netscape开发的专门用户保护Web通讯的，目前版本为3.0。最新版本的TLS 1.0是IETF(工程任务组)制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。两者差别极小，可以理解为SSL 3.1，它是写入了RFC的。在TLS与SSL3.0之间存在着显著的差别，主要是它们所支持的加密算法不同，所以TLS与SSL3.0不能互操作。

1．TLS与SSL的差异

1）版本号：TLS记录格式与SSL记录格式相同，但版本号的值不同，TLS的版本1.0使用的版本号为SSLv3.1。

2）报文鉴别码：SSLv3.0和TLS的MAC算法及MAC计算的范围不同。TLS使用了RFC-2104定义的HMAC算法。SSLv3.0使用了相似的算法，两者差别在于SSLv3.0中，填充字节与密钥之间采用的是连接运算，而HMAC算法采用的是异或运算。但是两者的安全程度是相同的。

3）伪随机函数：TLS使用了称为PRF的伪随机函数来将密钥扩展成数据块，是更安全的方式。

4）报警代码：TLS支持几乎所有的SSLv3.0报警代码，而且TLS还补充定义了很多报警代码，如解密失败（decryption_failed）、记录溢出（record_overflow）、未知CA（unknown_ca）、拒绝访问（access_denied）等。

5）密文族和客户证书：SSLv3.0和TLS存在少量差别，即TLS不支持Fortezza密钥交换、加密算法和客户证书。

6）certificate_verify和finished消息：SSLv3.0和TLS在用certificate_verify和finished消息计算MD5和SHA-1散列码时，计算的输入有少许差别，但安全性相当。

7）加密计算：TLS与SSLv3.0在计算主密值（master secret）时采用的方式不同。

8）填充：用户数据加密之前需要增加的填充字节。在SSL中，填充后的数据长度要达到密文块长度的最小整数倍。而在TLS中，填充后的数据长度可以是密文块长度的任意整数倍（但填充的最大长度为255字节），这种方式可以防止基于对报文长度进行分析的攻击。

2．TLS的主要增强内容TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。

TLS 在SSL v3.0 的基础上，提供了以下增强内容：

1）更安全的MAC算法；

2）更严密的警报；

3）“灰色区域”规范的更明确的定义；

3．TLS对于安全性的改进

1）对于消息认证使用密钥散列法：TLS 使用“消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。

2）增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。

3）改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。

4）一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。

5）特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

ssl

        SSL (Secure Socket Layer)为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取。目前一般通用之规格为40 bit之安全标准，美国则已推出128 bit之更高安全标准，但限制出境。只要3.0版本以上之I.E.或Netscape浏览器即可支持SSL。 当前版本为3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。

SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。

SSL协议可分为两层：

SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。

SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

SSL协议提供的服务主要有：

1）认证用户和服务器，确保数据发送到正确的客户机和服务器；

2）加密数据以防止数据中途被窃取；

3）维护数据的完整性，确保数据在传输过程中不被改变。

SSL协议的工作流程：

服务器认证阶段：

1）客户端向服务器发送一个开始信息“Hello”以便开始一个新的会话连接；

2）服务器根据客户的信息确定是否需要生成新的主密钥，如需要则服务器在响应客户的“Hello”信息时将包含生成主密钥所需的信息；

3）客户根据收到的服务器响应信息，产生一个主密钥，并用服务器的公开密钥加密后传给服务器；

4）服务器恢复该主密钥，并返回给客户一个用主密钥认证的信息，以此让客户认证服务器。

用户认证阶段：

在此之前，服务器已经通过了客户认证，这一阶段主要完成对客户的认证。经认证的服务器发送一个提问给客户，客户则返回（数字）签名后的提问和其公开密钥，从而向服务器提供认证。

        从SSL 协议所提供的服务及其工作流程可以看出，SSL协议运行的基础是商家对消费者信息保密的承诺，这就有利于商家而不利于消费者。在电子商务初级阶段，由于运作电子商务的企业大多是信誉较高的大公司，因此这问题还没有充分暴露出来。但随着电子商务的发展，各中小型公司也参与进来，这样在电子支付过程中的单一认证问题就越来越突出。虽然在SSL3.0中通过数字签名和数字证书可实现浏览器和Web服务器双方的身份验证，但是SSL协议仍存在一些问题，比如，只能提供交易中客户与服务器间的双方认证，在涉及多方的电子交易中，SSL协议并不能协调各方间的安全传输和信任关系。在这种情况下，Visa和 MasterCard两大信用卡公组织制定了SET协议，为网上信用卡支付提供了全球性的标准。

概况

　　安全传输层协议（TLS）用于在两个通信应用程序之间提供保密性和数据完整性。

该协议由两层组成：

TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。 

协议结构
　　TLS 协议包括两个协议组―― TLS 记录协议和 TLS 握手协议――每组具有很多不同格式的信息。 
　　TLS 记录协议是一种分层协议。每一层中的信息可能包含长度、描述和内容等字段。记录协议支持信息传输、将数据分段到可处理块、压缩数据、应用 MAC 、加密以及传输结果等。对接收到的数据进行解密、校验、解压缩、重组等，然后将它们传送到高层客户机。 
　　TLS 连接状态指的是TLS 记录协议的操作环境。它规定了压缩算法、加密算法和 MAC 算法。 
　　TLS 记录层从高层接收任意大小无空块的连续数据。密钥计算：记录协议通过算法从握手协议提供的安全参数中产生密钥、 IV 和 MAC 密钥。TLS 握手协议由三个子协议组构成，允许对等双方在记录层的安全参数上达成一致、自我认证、例示协商安全参数、互相报告出错条件。 
TLS握手协议： 

　　1.改变密码规格协议

　　2.警惕协议 

　　3.握手协议

TLS 记录协议

　　TLS 记录协议提供的连接安全性具有两个基本特性： 
　　私有――对称加密用以数据加密（DES 、RC4 等）。对称加密所产生的密钥对每个连接都是唯一的，且此密钥基于另一个协议（如握手协议）协商。记录协议也可以不加密使用。 
　　可靠――信息传输包括使用密钥的 MAC 进行信息完整性检查。安全哈希功能（ SHA、MD5 等）用于 MAC 计算。记录协议在没有 MAC 的情况下也能操作，但一般只能用于这种模式，即有另一个协议正在使用记录协议传输协商安全参数。 
　　TLS 记录协议用于封装各种高层协议。作为这种封装协议之一的握手协议允许服务器与客户机在应用程序协议传输和接收其第一个数据字节前彼此之间相互认证，协商加密算法和加密密钥。 
TLS 握手协议
　　TLS 握手协议提供的连接安全具有三个基本属性： 
　　1.可以使用非对称的，或公共密钥的密码术来认证对等方的身份。该认证是可选的，但至少需要一个结点方。 
　　2.共享加密密钥的协商是安全的。对偷窃者来说协商加密是难以获得的。此外经过认证过的连接不能获得加密，即使是进入连接中间的攻击者也不能。 
　　3.协商是可靠的。没有经过通信方成员的检测，任何攻击者都不能修改通信协商。 
综述
　　TLS 的最大优势就在于：TLS 是独立于应用协议。高层协议可以透明地分布在 TLS 协议上面。然而，TLS 标准并没有规定应用程序如何在 TLS 上增加安全性；它把如何启动 TLS 握手协议以及如何解释交换的认证证书的决定权留给协议的设计者和实施者来判断。 
　　TLS包含三个基本阶段： 
　　1.对等协商支援的密钥算法 
　　2.基于私钥加密交换公钥、基于PKI证书的身份认证 
　　3.基于公钥加密的数据传输保密 
SSL工作原理
    SSL 是一个安全协议，它提供使用 TCP/IP 的通信应用程序间的隐私与完整性。因特网的 超文本传输协议 （HTTP）使用 SSL 来实现安全的通信。 
    在客户端与服务器间传输的数据是通过使用对称算法（如 DES 或 RC4）进行加密的。公用密钥算法（通常为 RSA）是用来获得加密密钥交换和数字签名的，此算法使用服务器的SSL数字证书中的公用密钥。有了服务器的SSL数字证书，客户端也可以验证服务器的身份。SSL 协议的版本 1 和 2 只提供服务器认证。版本 3 添加了客户端认证，此认证同时需要客户端和服务器的数字证书。 
    SSL 握手 
    SSL 连接总是由客户端启动的。在SSL 会话开始时执行 SSL 握手。此握手产生会话的密码参数。关于如何处理 SSL 握手的简单概述，如下图所示。此示例假设已在 Web 浏览器 和 Web 服务器间建立了 SSL 连接。 

    图 SSL的客户端与服务器端的认证握手 

    (1) 客户端发送列出客户端密码能力的客户端“您好”消息（以客户端首选项顺序排序），如 SSL 的版本、客户端支持的密码对和客户端支持的数据压缩方法。消息也包含 28 字节的随机数。 
    (2) 服务器以服务器“您好”消息响应，此消息包含密码方法（密码对）和由服务器选择的数据压缩方法，以及会话标识和另一个随机数。     注意:客户端和服务器至少必须支持一个公共密码对，否则握手失败。服务器一般选择最大的公共密码对。 
    (3) 服务器发送其SSL数字证书。（服务器使用带有 SSL 的 X.509 V3 数字证书。）     如果服务器使用 SSL V3，而服务器应用程序（如 Web 服务器）需要数字证书进行客户端认证，则客户端会发出“数字证书请求”消息。在 “数字证书请求”消息中，服务器发出支持的客户端数字证书类型的列表和可接受的CA的名称。 
    (4) 服务器发出服务器“您好完成”消息并等待客户端响应。 
    (5) 一接到服务器“您好完成”消息，客户端（ Web 浏览器）将验证服务器的SSL数字证书的有效性并检查服务器的“你好”消息参数是否可以接受。     如果服务器请求客户端数字证书，客户端将发送其数字证书；或者，如果没有合适的数字证书是可用的，客户端将发送“没有数字证书”警告。此警告仅仅是警告而已，但如果客户端数字证书认证是强制性的话，服务器应用程序将会使会话失败。 
    (6) 客户端发送“客户端密钥交换”消息。此消息包含 pre-master secret （一个用在对称加密密钥生成中的 46 字节的随机数字），和 消息认证代码 （ MAC ）密钥（用服务器的公用密钥加密的）。     如果客户端发送客户端数字证书给服务器，客户端将发出签有客户端的专用密钥的“数字证书验证”消息。通过验证此消息的签名，服务器可以显示验证客户端数字证书的所有权。     注意: 如果服务器没有属于数字证书的专用密钥，它将无法解密 pre-master 密码，也无法创建对称加密算法的正确密钥，且握手将失败。 
    (7) 客户端使用一系列加密运算将 pre-master secret 转化为 master secret ，其中将派生出所有用于加密和消息认证的密钥。然后，客户端发出“更改密码规范” 消息将服务器转换为新协商的密码对。客户端发出的下一个消息（“未完成”的消息）为用此密码方法和密钥加密的第一条消息。 
    (8) 服务器以自己的“更改密码规范”和“已完成”消息响应。 
　　(9) SSL 握手结束，且可以发送加密的应用程序数据。

　　TLS原理 收藏 

　　cited from http://ciw.chinaitlab.com/tech/7319.html

　　一 前言 

　　　　首先要澄清一下名字的混淆： 
　　　　1 SSL(Secure Socket Layer)是netscape公司设计的主要用于web的安全传输协议。这种协议在WEB上获得了广泛的应用。 
　　　2 IETF(www.ietf.org)将SSL作了标准化，即RFC2246,并将其称为TLS（Transport Layer Security），从技术上讲，TLS1.0与SSL3.0的差别非常微小。由于本文中没有涉及两者间的细小差别，本文中这两个名字等价。 
　　　　3 在WAP的环境下，由于手机及手持设备的处理和存储能力有限，wap论坛（www.wapforum.org）在TLS的基础上做了...WTLS协议（Wireless Transport Layer Security），以适应无线的特殊环境。
　　　　我们从各式各样的文章中得知，SSL可以用于保密的传输，这样我们与web server之间传输的消息便是“安全的”。 
　　　　而这种“安全”究竟是怎么实现的，最终有能实现多大程度的保密？本文希望能用通俗的语言阐明其实现原理。

　　　　二 整体结构概览 

　　　　SSL是一个介于HTTP协议与TCP之间的一个可选层，其位置大致如下： 
　　　　－－－－－－－－－ 
　　　　| HTTP | 
　　　　－－－－－－－－－ 
　　　　| SSL | 
　　　　－－－－－－－－－ 
　　　　| TCP | 
　　　　－－－－－－－－－ 
　　　　| IP | 
　　　　－－－－－－－－－ 
　　　　
　　　　如果利用SSL协议来访问网页，其步骤如下： 
　　　　用户：在浏览器的地址栏里输入https://www.sslserver.com 
　　HTTP层：将用户需求翻译成HTTP请求，如 
　　GET /index.htm HTTP/1.1 
　　Host http://www.sslserver.com 
　　SSL层: 借助下层协议的的信道安全的协商出一份加密密钥，并用此密钥来加密HTTP请求。 
　　TCP层：与web server的443端口建立连接，传递SSL处理后的数据。 
　　接收端与此过程相反。 
　　SSL在TCP之上建立了一个加密通道，通过这一层的数据经过了加密，因此达到保密的效果。 
　　SSL协议分为两部分：Handshake Protocol和Record Protocol,。其中Handshake Protocol用来协商密钥，协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol则定义了传输的格式。 

　　　四 密钥协商过程 

　　　　由于对称加密的速度比较慢，所以它一般用于密钥交换，双方通过公钥算法协商出一份密钥，然后通过对称加密来通信，当然，为了保证数据的完整性，在加密前要先经过HMAC的处理。 
　　　　SSL缺省只进行server端的认证，客户端的认证是可选的。以下是其流程图（摘自TLS协议）。 
　　　　Client Server 
　　　　Clienth*llo --------> 
　　　　Serverh*llo 
　　　　Certificate* 
　　　　ServerKeyExchange* 
　　　　CertificateRequest* 
　　　　<-------- Serverh*lloDone 
　　　　Certificate*
　　　　ClientKeyExchange 
　　　　CertificateVerify* 
　　　　[ChangeCipherSpec] 
　　　　Finished --------> 
　　　　[ChangeCipherSpec] 
　　　　<-------- Finished 
　　　　Application Data <-------> Application Data 
　　　　简单的说便是：SSL客户端（也是TCP的客户端）在TCP链接建立之后，发出一个Clienth*llo来发起握手，这个消息里面包含了自己可实现的算法列表和其它一些需要的消息，SSL的服务器端会回应一个Serverh*llo，这里面确定了这次通信所需要的算法，然后发过去自己的证书（里面包含了身份和自己的公钥）。Client在收到这个消息后会生成一个秘密消息，用SSL服务器的公钥加密后传过去，SSL服务器端用自己的私钥解密后，会话密钥协商成功，双方可以用同一份会话密钥来通信了。 

　　　五 密钥协商的形象化比喻 

　　如果上面的说明不够清晰，这里我们用个形象的比喻，我们假设A与B通信，A是SSL客户端，B是SSL服务器端，加密后的消息放在方括号[]里，以突出明文消息的区别。双方的处理动作的说明用圆括号（）括起。 
　　　　A：我想和你安全的通话，我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH，摘要算法有MD5和SHA。 
　　　　B：我们用DES－RSA－SHA这对组合好了。 
　　　　这是我的证书，里面有我的名字和公钥，你拿去验证一下我的身份（把证书发给A）。 
　　　　目前没有别的可说的了。 
　　　　A：（查看证书上B的名字是否无误，并通过手头早已有的CA的证书验证了B的证书的真实性，如果其中一项有误，发出警告并断开连接，这一步保证了B的公钥的真实性） 
　　　　（产生一份秘密消息，这份秘密消息处理后将用作加密密钥，加密初始化向量和hmac的密钥。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密，封装成称作ClientKeyExchange的消息。由于用了B的公钥，保证了第三方无法窃听） 
　　　　我生成了一份秘密消息，并用你的公钥加密了，给你（把ClientKeyExchange发给B） 
　　　　注意，下面我就要用加密的办法给你发消息了！ 
　　　　（将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥） 
　　　　[我说完了] 
　　　　B：（用自己的私钥将ClientKeyExchange中的秘密消息解密出来，然后将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥，这时双方已经安全的协商出一套加密办法了） 
　　　　注意，我也要开始用加密的办法给你发消息了！ 
　　　　[我说完了]　
　　　　A: [我的秘密是...] 
　　　　B: [其它人不会听到的...] 

　　　　六 加密的计算 

　　　　上一步讲了密钥的协商，但是还没有阐明是如何利用加密密钥，加密初始化向量和hmac的密钥来加密消息的。 
　　　　其实其过程不过如此： 
　　　　1 借助hmac的密钥，对明文的消息做安全的摘要处理，然后和明文放到一起。 
　　　　2 借助加密密钥，加密初始化向量加密上面的消息。 

　　　　七 安全性 

　　　　SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的讨论， 
　　　　目前也有一些成熟的工具如dsniff（http://www.monkey.org/~dugsong/dsniff/）可以 
　　　　通过man in the middle攻击来截获https的消息。 
　　　　
　　　　从上面的原理可知，SSL的结构是严谨的，问题一般出现在实际不严谨的应用中。常见的攻击就是 
　　　　middle in the middle攻击，它是指在A和B通信的同时，有第三方C处于信道的中间，可以完全 
　　　　听到A与B通信的消息，并可拦截，替换和添加这些消息。 
　　　　
　　　　1 SSL可以允许多种密钥交换算法，而有些算法，如DH，没有证书的概念，这样A便无法验证B的公钥 
　　　　和身份的真实性，从而C可以轻易的冒充，用自己的密钥与双方通信，从而窃听到别人谈话的内容。 
　　　　而为了防止middle in the middle攻击，应该采用有证书的密钥交换算法。 
　　　　2 有了证书以后，如果C用自己的证书替换掉原有的证书之后，A的浏览器会弹出一个警告框进行警告，但又有多少人会注意这个警告呢？ 
　　　　3 由于美国密码出口的限制，IE，netscape等浏览器所支持的加密强度是很弱的，如果只采用浏览器自带的加密功能的话，理论上存在被破解可能。 

　　　　八 代理 

　　　　下面探讨一下SSL的代理是怎样工作的(可参见[6])。这可能与你开始想的不太一样：） 
　　　　当在浏览器里设置了https的代理，而且在浏览器里输入了https://www.example.com之后， 
　　　　浏览器会与proxy建立tcp链接，然后向其发出   
　　


基于SSL / TLS的已知攻击
虽然SSL / TLS协议在理论上提供了高水平的安全，其实际实现可能容易受到攻击的几种类型。在众多的攻击行为中，有两个值得特别注意：
Man in the middle (MITM) attacks中间人（的MITM）攻击
在这种类型的攻击，入侵者截获正在发送，如客户端和服务器之间，通过伪造的DNS回复或通过执行ARP改变方向。然后，它会模拟客户端向服务器发送，反之亦然。在这次攻击中，用户的浏览器并没有直接连接到目标服务器，而是给入侵者主机，模拟Web浏览器，基本上作为一个代理。
有好的和坏的管理员谁愿抵御这种袭击的消息。好消息是警告用户的Web浏览器时，Web服务器的身份无法核实，这可能表明有可能人在- the - middle攻击通过显示一个警告信息窗口。坏消息是，在现实生活中，用户往往忽略这些警告。因此，如果用户的Web浏览器接收到SSL的Web身份不能被选中，我们只能依靠用户的教育和信任，他们不会按“继续”按钮，如果这样的警告信息已显示的网站的连接。
Brute-force attack on the session key蛮力攻击的会话密钥
这种攻击可以知道入侵者时执行，也可以承担明确的文字是在SSL / TLS会话，如（如“的GET / HTTP/1.0的”），发送的一部分，入侵者可以窃听本届会议（例如由使用tcpdump的 ， 虚无或其他工具）。然后，入侵者可以利用一切可能的加密密钥的文本承担一部分，试图找到在原来加密的SSL / TLS运行。一旦这种情况发生已经发现，这是用来加密此消息的一部分可以用来解密的，原来的加密的SSL / TLS的其它流量的关键。
好消息是，必须检查键的最大数是2 ^ 128当128位对称加密技术已被使用今天，这被认为是强大到足以保护多年字面上几十会议。然而，由于CPU的实力壮大，我们每年不能真正预测多久128位对称密钥将被视为是安全的，特别是对于大型超级计算机黑客访问。
在出口级的密码套件（40位，并在一些扩展56位密码）等强力攻击可以成功地在一个合理的执行情况之间的时间 - 有时在数天甚至数上可用depending的CPU。如果在你的国家的出口法规允许使用强密码，一个一定要使用它，而不是出口级密码套件。
.除了上述两种类型的攻击，还有其他一些潜在的漏洞，包括算法回滚攻击，攻击时机，流量分析，Bleinchenbacher的攻击等。.那些“有兴趣了解他们可以找到更多信息和大卫布鲁斯瓦格纳的文件分析了SSL 3.0协议 “（PDF文档），以及对被发现在许多其他文件可以公开的网际网路 。
Typical SSL/TLS implementation mistakes典型的SSL / TLS实现错误
最大的错误，可在执行SSL / TLS的与该Web服务器的证书由CA签名不是由网页浏览器信任的。换句话说，CA的证书是没有安装在Web浏览器。这使得人在- the - middle攻击很容易执行，因为用户没有核实身份的Web服务器方式。
.为了避免这个问题，重要的是要确保签名者的证书（通常，受信任的CA）是在用户的Web浏览器安装。如果本地CA签署了Web服务器的证书中使用，那么我们必须确保所有客户的所有需要​​访问Web浏览器有当地CA的证书已安装。同样的规则适用于自签名的证书
　　　　1 SSL可以允许多种密钥交换算法，而有些算法，如DH，没有证书的概念，这样A便无法验证B的公钥 
　　　　和身份的真实性，从而C可以轻易的冒充，用自己的密钥与双方通信，从而窃听到别人谈话的内容。 
　　　　而为了防止middle in the middle攻击，应该采用有证书的密钥交换算法。 
　　　　2 有了证书以后，如果C用自己的证书替换掉原有的证书之后，A的浏览器会弹出一个警告框进行警告，但又有多少人会注意这个警告呢？ 
　　　　3 由于美国密码出口的限制，IE，netscape等浏览器所支持的加密强度是很弱的，如果只采用浏览器自带的加密功能的话，理论上存在被破解可能。 
证书签署一个不知道的网页浏览器的CA证书
否则会导致同样的问题上面，即Web客户端将无法与Web服务器进行身份验证 - 这再次使SSL / TLS连接容易受到中间人攻击的人。在这种情况下，用户可能习惯于看到一个警告信息，说证书已过期，然后可能不会注意到，如果它是假证书。
　　　脆弱的OpenSSL和Apache版本
　　这是非常重要的始终运行的OpenSSL和Apache的最新版本程序员在编写错误，如没有这些几乎是不可能的较大块的代码，所以我们应该始终使用上述软件的最新稳定版本。理论上的最新版本包含更少的安全漏洞比以前的版本（包括发现和未尚未发现）。
　　Ar验收的SSL 2.0，匿名身份验证（aNULL）和密码由Web服务器（空）
　　正如前面所讨论的，支持的加密套件匿名身份验证或加密不需要使用应禁用。否则，有一个客户端可以将谈判的参数，可以大大降低连接的安全级别被骗的风险。基于这个原因，我们应该禁用的SSLv2.0协议和使用TLSv1.0或SSLv3.0改用。
　　Use of weak encryption使用弱加密
　　早期的SSL实现，只能够使用对称加密，由于美国政府限制的40位密钥。不幸的是，数据由40位加密的对称密钥解密，现在可以在一个相对较短的时间内，基于这个原因，40位和56位密钥不应再使用。大多数现代Web浏览器支持对称加密的128位密钥，这是目前最小的与SSL / TLS的使用重点推荐的长度。
　　Improper use of a Network Intruder Detection System (NIDS)不当使用网络入侵检测系统（NIDS）
　　重要的是要强调，除非NIDS的是解密SSL流量（如通过Web服务器的私钥使用）的能力是根本无法检测到Web上的应用程序攻击。为了检测最终破门而入，我们必须要么使用一个的HIDS（基于主机的入侵检测系统），或将在一个SSL / TLS的交通正在清晰文本，如之间的SSL，NIDS的发送部分的反向代理和Web服务器的农场。否则，我们可能无法检测到，除了对拒绝服务网络服务器上执行，任何攻击。
　　Allowing access not only via SSL, but also via non-encrypted protocols (HTTP)允许通过SSL访问不仅是，而且还通过非加密协议（HTTP）
　　设置SSL / TLS和开放端口443/tcp到Web服务器本身，意味着什么，如果用户仍可以访问通过非加密的HTTP端口80/tcp网站上。因此，我们必须仔细检查受保护的内容可以不通过非加密的HTTP或其他协议（包括FTP，桑巴和NFS等）进行访问。
　　Vulnerable client machines易受攻击的客户端机
　　当我们在Apache的Web服务器安全的重点，我们可以很容易地忘记了客户机的安全性。如果他们受到损害，对SSL / TLS是作出妥协，以及安全。在这种情况下，入侵者可以做，因为他们与客户的主机，比如，在Web浏览器证书的更换，安装键盘记录器，修改/ etc / hosts来的Web请求重定向到伪造的Web服务器，或什至窃取客户端证书，如果他们，他们已被标记作为“出口”。
　　因此，如果客户机是根据我国的行政领域，我们需要非常小心他们的安全。启用个人防火墙，防病毒/反间谍软件，并自动打开Windows更新应该是绝对的最低限度。最重要的是，Web浏览器的版本应始终保持最新状态。
　　委员会还建议，一个适用于下列选项（与SSL / TLS）来在Web浏览器配置：
　　checking for a publisher's certificate revocation should be enabled在出版社的证书吊销检查应启用
　　checking for any server certificate revocation should be enabled任何服务器证书吊销检查应启用
　　encrypted server pages should not be stored in the cache加密服务器的页面不应该存储在高速缓存
　　the use of SSLv2.0 should be disabled, and only TLSv1.0 and SSLv3.0 should remain enabled对SSLv2.0使用应该被禁用，只有TLSv1.0和SSLv3.0应该保持启用
　　the displaying of warnings about invalid web servers certificates should be enabled约Web服务器证书无效的警告显示应启用
　　Using the same Session IDs / cookies for SSL and HTTP使用SSL和HTTP的相同会话ID / cookies
　　这是可能有一个Apache的配置，接受HTTP和HTTPS请求在同一服务器上，如信息网站通过HTTP访问，以及交易的一部分，通过HTTPS访问。在这种情况下，我们必须在我们的Web应用程序非常不使用这两种协议相同的会话ID /cookies小心。否则，入侵者可以嗅出Web服务器之间的HTTP流量和受害者，可以尝试使用会话ID来获得授权的网络应用程序的一部分通过SSL。
Conclusion结论
本文专门讨论关闭配置与SSL / TLS的支持Apache 2.0的系列文章。据介绍如何设置SSL / TLS协议，以实现最大的安全性和最佳的性能。它也已展示了如何创建和吊销证书，以及如何在实践中使用它们。
虽然该系列已覆盖了SSL的Web服务器，包括创建，安装使用和吊销证书，公钥基础设施最重要的方面，我们没有排气有关PKI的主题。相反，只有真正的PKI基础知识已提交。话题感兴趣的读者进一步阅读对于这一点，鼓励采取创建文件的外观在PKIX工作组 ，或OpenCA PKI的开发项目 ，后者是一个相当强大和开放源码证书颁发机构。


 相关链接 
 “TLS协议，版本1.0”： http://ietf.org/rfc/rfc2246.txt?number=2246  “3.0规范”： http://wp.netscape.com/eng/ssl3/  Apache Web服务器项目： http://httpd.apache.org  OpenSSL项目： http://www.openssl.org  OpenCA项目： http://www.openca.org  mod_ssl的网站： http://www.modssl.org  加固Apache 2步：分步： http://www.securityfocus.com/infocus/1786  PKIX工作组： http://www.ietf.org/html.charters/pkix-charter.html  “协议分析的SSL 3.0”： http://www.schneier.com/paper-ssl-revised.pdf  “有限状态分析的SSL 3.0”： http://verify.stanford.edu/uli/secur/usenix/usenix.html  “无线应用2.0安全”： http://www.sans.org/rr/whitepapers/wireless/159.php 
 样本的Apache配置文件： httpd.conf中  示例启动脚本： apache.sh  OpenSSL设定档的范例： openssl.cnf中