菜鸟教程——http和Https、SSL

HTTP：是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。

HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。

HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。简单来说，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。

HTTPS和HTTP的区别主要如下：

1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。

2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。

3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

我们都知道HTTPS能够加密信息，以免敏感信息被第三方获取，所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。

客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤，如图所示。

（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。

（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

（3）客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。

（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。

（5）Web服务器利用自己的私钥解密出会话密钥。

（6）Web服务器利用会话密钥加密与客户端之间的通信。

尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：

（1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；

（2）HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。

（3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

（4）谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。

虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：

（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；

（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；

（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。

（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。

（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

如果需要将网站从http切换到https到底该如何实现呢？

这里需要将页面中所有的链接，例如js，css，等等链接都由http改为https。例如：http://wwwbaiducom改为https://wwwbaiducom

BTW，这里虽然将http切换为了https，还是建议保留http。所以我们在切换的时候可以做http和https的兼容，具体实现方式是，去掉页面链接中的http头部，这样可以自动匹配http头和https头。例如：将http://wwwbaiducom改为//wwwbaiducom。然后当用户从http的入口进入访问页面时，页面就是http，如果用户是从https的入口进入访问页面，页面即使https的。

SSL介绍：

安全套接字（Secure Socket Layer，SSL）协议是Web浏览器与Web服务器之间安全交换信息的协议，提供两个基本的安全服务：鉴别与保密。

SSL是Netscape于1994年开发的，后来成为了世界上最著名的web安全机制，所有主要的浏览器都支持SSL协议。

目前有三个版本：2、3、31，最常用的是第3版，是1995年发布的。

在客户端与服务器间传输的数据是通过使用对称算法（如 DES 或 RC4）进行加密的。公用密钥算法（通常为 RSA）是用来获得加密密钥交换和数字签名的，此算法使用服务器的SSL数字证书中的公用密钥。有了服务器的SSL数字证书，客户端也可以验证服务器的身份。SSL 协议的版本 1 和 2 只提供服务器认证。版本 3 添加了客户端认证，此认证同时需要客户端和服务器的数字证书。

SSL协议的三个特性

① 保密：在握手协议中定义了会话密钥后，所有的消息都被加密。

② 鉴别：可选的客户端认证，和强制的服务器端认证。

③ 完整性：传送的消息包括消息完整性检查（使用MAC）。

SSL的位置

SSL介于应用层和TCP层之间。应用层数据不再直接传递给传输层，而是传递给SSL层，SSL层对从应用层收到的数据进行加密，并增加自己的SSL头。

SSL的工作原理

握手协议（Handshake protocol）

记录协议（Record protocol）

警报协议（Alert protocol）

1、握手协议

握手协议是客户机和服务器用SSL连接通信时使用的第一个子协议，握手协议包括客户机与服务器之间的一系列消息。SSL中最复杂的协议就是握手协议。该协议允许服务器和客户机相互验证，协商加密和MAC算法以及保密密钥，用来保护在SSL记录中发送的数据。握手协议是在应用程序的数据传输之前使用的。

每个握手协议包含以下3个字段

（1）Type：表示10种消息类型之一

（2）Length：表示消息长度字节数

（3）Content：与消息相关的参数

握手协议的4个阶段

11 建立安全能力

SSL握手的第一阶段启动逻辑连接，建立这个连接的安全能力。首先客户机向服务器发出client hello消息并等待服务器响应，随后服务器向客户机返回server hello消息，对client hello消息中的信息进行确认。

Client hello消息包括Version，Random，Session id，Cipher suite，Compression method等信息。

ClientHello 客户发送CilentHello信息，包含如下内容：

（1）客户端可以支持的SSL最高版本号

（2）一个用于生成主秘密的32字节的随机数。（等会介绍主秘密是什么）

（3）一个确定会话的会话ID。

（4）一个客户端可以支持的密码套件列表。

密码套件格式：每个套件都以“SSL”开头，紧跟着的是密钥交换算法。用“With”这个词把密钥交换算法、加密算法、散列算法分开，例如：SSL_DHE_RSA_WITH_DES_CBC_SHA, 表示把DHE_RSA(带有RSA数字签名的暂时Diffie-HellMan)定义为密钥交换算法；把DES_CBC定义为加密算法；把SHA定义为散列算法。

（5）一个客户端可以支持的压缩算法列表。

ServerHello服务器用ServerHello信息应答客户，包括下列内容

（1）一个SSL版本号。取客户端支持的最高版本号和服务端支持的最高版本号中的较低者。

（2）一个用于生成主秘密的32字节的随机数。（客户端一个、服务端一个）

（3）会话ID

（4）从客户端的密码套件列表中选择的一个密码套件

（5）从客户端的压缩方法的列表中选择的压缩方法

这个阶段之后，客户端服务端知道了下列内容：

（1）SSL版本

（2）密钥交换、信息验证和加密算法

（3）压缩方法

（4）有关密钥生成的两个随机数。

12 服务器鉴别与密钥交换

服务器启动SSL握手第2阶段，是本阶段所有消息的唯一发送方，客户机是所有消息的唯一接收方。该阶段分为4步：

（a）证书：服务器将数字证书和到根CA整个链发给客户端，使客户端能用服务器证书中的服务器公钥认证服务器。

（b）服务器密钥交换（可选）：这里视密钥交换算法而定

（c）证书请求：服务端可能会要求客户自身进行验证。

（d）服务器握手完成：第二阶段的结束，第三阶段开始的信号

这里重点介绍一下服务端的验证和密钥交换。这个阶段的前面的（a）证书 和（b）服务器密钥交换是基于密钥交换方法的。而在SSL中密钥交换算法有6种：无效（没有密钥交换）、RSA、匿名Diffie-Hellman、暂时Diffie-Hellman、固定Diffie-Hellman、Fortezza。

在阶段1过程客户端与服务端协商的过程中已经确定使哪种密钥交换算法。

如果协商过程中确定使用RSA交换密钥，那么过程如下图：

这个方法中，服务器在它的第一个信息中，发送了RSA加密/解密公钥证书。不过，因为预备主秘密是由客户端在下一个阶段生成并发送的，所以第二个信息是空的。注意，公钥证书会进行从服务器到客户端的验证。当服务器收到预备主秘密时，它使用私钥进行解密。服务端拥有私钥是一个证据，可以证明服务器是一个它在第一个信息发送的公钥证书中要求的实体。

其他的几种密钥交换算法这里就不介绍了。可以参考Behrouz AForouzan著的《密码学与网络安全》。

13 客户机鉴别与密钥交换：

客户机启动SSL握手第3阶段，是本阶段所有消息的唯一发送方，服务器是所有消息的唯一接收方。该阶段分为3步：

（a）证书（可选）：为了对服务器证明自身，客户要发送一个证书信息，这是可选的，在IIS中可以配置强制客户端证书认证。

（b）客户机密钥交换（Pre-master-secret）：这里客户端将预备主密钥发送给服务端，注意这里会使用服务端的公钥进行加密。

（c）证书验证（可选），对预备秘密和随机数进行签名，证明拥有（a）证书的公钥。

下面也重点介绍一下RSA方式的客户端验证和密钥交换。

这种情况，除非服务器在阶段II明确请求，否则没有证书信息。客户端密钥交换方法包括阶段II收到的由RSA公钥加密的预备主密钥。

阶段III之后，客户要有服务器进行验证，客户和服务器都知道预备主密钥。

14 完成

客户机启动SSL握手第4阶段，使服务器结束。该阶段分为4步，前2个消息来自客户机，后2个消息来自服务器。

15 密钥生成的过程

这样握手协议完成，下面看下什么是预备主密钥，主密钥是怎么生成的。为了保证信息的完整性和机密性，SSL需要有六个加密秘密：四个密钥和两个IV。为了信息的可信性，客户端需要一个密钥（HMAC），为了加密要有一个密钥，为了分组加密要一个IV，服务也是如此。SSL需要的密钥是单向的，不同于那些在其他方向的密钥。如果在一个方向上有攻击，这种攻击在其他方向是没影响的。生成过程如下：

2、记录协议

记录协议在客户机和服务器握手成功后使用，即客户机和服务器鉴别对方和确定安全信息交换使用的算法后，进入SSL记录协议，记录协议向SSL连接提供两个服务：

（1）保密性：使用握手协议定义的秘密密钥实现

（2）完整性：握手协议定义了MAC，用于保证消息完整性

记录协议的过程：

3、警报协议

客户机和服务器发现错误时，向对方发送一个警报消息。如果是致命错误，则算法立即关闭SSL连接，双方还会先删除相关的会话号，秘密和密钥。每个警报消息共2个字节，第1个字节表示错误类型，如果是警报，则值为1，如果是致命错误，则值为2；第2个字节制定实际错误类型。

(1) 加密套件和加密强度检查

安全可靠的加密强度必须大于或等于128位，如果有支持低于128位的算法，则是不安全的，应该关闭这些不安全的算法。

(2) 根证书密钥对安全检查

根据美国国家标准技术研究院(NIST)和微软的要求，根证书密钥对必须大于2048位，因为1024位已经不安全了。

(3) 用户证书密钥对安全检查

用户证书密钥对当然也必须大于或等于2048位。

(4) 不安全加密协议检查

服务器应该关闭不安全的SSL V20加密协议。

SSL 和 TLS 协议可以为通信双方提供识别和认证通道，从而保证通信的机密性和数据完整性。TLS 协议是从Netscape SSL 30协议演变而来的，不过这两种协议并不兼容，SSL 已经被 TLS 取代，所以下文就以 TLS 指代安全层。 TLS 握手是启动 HTTPS 通信的过程，类似于 TCP 建立连接时的三次握手。 在 TLS 握手的过程中，通信双方交换消息以相互验证，相互确认，并确立它们所要使用的加密算法以及会话密钥 (用于对称加密的密钥)。可以说，TLS 握手是 HTTPS 通信的基础部分。

HTTPS是什么相信大家都知道，如果你不知道。。。请关闭此文！！！

HTTP的数据是明文传输的，没有安全性可言。HTTPS是秘文传输，那么HTTPS是怎么实现数据的安全(加密)传输的？那是因为HTTPS比HTTP多了个'S'。 即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

SSL/TLS协议是网络安全通信的重要基石，本文将简单介绍SSL/TLS协议，主要关注SSL/TLS协议的安全性，特别是SSL规范的正确实现。 本系列的文章大体分为几个部分：

1、SSL/TLS简介

2、SSL/TLS协议的基本流程

3、从SSL到TLS

4、SSL/TLS的流行实现库

SSL全称是Secure Sockets Layer，安全套接字层，它是由网景公司(Netscape)设计的主要用于Web的安全传输协议，目的是为网络通信提供机密性、认证性及数据完整性保障。如今，SSL已经成为互联网保密通信的工业标准。

SSL最初的几个版本(SSL 10、SSL20、SSL 30)由网景公司设计和维护，从31版本开始，SSL协议由因特网工程任务小组(IETF)正式接管，并更名为TLS(Transport Layer Security)，发展至今已有TLS 10、TLS11、TLS12这几个版本。

如TLS名字所说，SSL/TLS协议仅保障传输层安全。同时，由于协议自身特性(数字证书机制)，SSL/TLS不能被用于保护多跳(multi-hop)端到端通信，而只能保护点到点通信。

SSL/TLS协议能够提供的安全目标主要包括如下几个：

认证性——借助数字证书认证服务器端和客户端身份，防止身份伪造

机密性——借助加密防止第三方窃听

完整性——借助消息认证码(MAC)保障数据完整性，防止消息篡改

重放保护——通过使用隐式序列号防止重放攻击

为了实现这些安全目标，SSL/TLS协议被设计为一个两阶段协议，分为握手阶段和应用阶段：

握手阶段也称协商阶段，在这一阶段，客户端和服务器端会认证对方身份(依赖于PKI体系，利用数字证书进行身份认证)，并协商通信中使用的安全参数、密码套件以及MasterSecret。后续通信使用的所有密钥都是通过MasterSecret生成。

在握手阶段完成后，进入应用阶段。在应用阶段通信双方使用握手阶段协商好的密钥进行安全通信。

Handshake协议：包括协商安全参数和密码套件、服务器身份认证(客户端身份认证可选)、密钥交换;

ChangeCipherSpec 协议：一条消息表明握手协议已经完成;

Alert 协议：对握手协议中一些异常的错误提醒，分为fatal和warning两个级别，fatal类型的错误会直接中断SSL链接，而warning级别的错误SSL链接仍可继续，只是会给出错误警告;

Record 协议：包括对消息的分段、压缩、消息认证和完整性保护、加密等。

图2、图3都是表示的协议流程，大同小异。可以对比着看加深理解。

每一个SSL/TLS链接都是从握手开始的，握手过程包含一个消息序列，用以协商安全参数、密码套件，进行身份认证以及密钥交换。握手过程中的消息必须严格按照预先定义的顺序发生，否则就会带来潜在的安全威胁。今年顶级安全会议CCS 有文章提出了建立综合状态机来检查SSL链接中消息序列……

21 握手过程中的消息序列

ClientHello：ClientHello通常是握手过程中的第一条消息，用于告知服务器客户端所支持的密码套件种类、最高SSL/TLS协议版本以及压缩算法。

ClientHello中还包含一个随机数，这个随机数由4个字节的当前GMT UNIX时间以及28个随机选择的字节组成，共32字节。该随机数会在密钥生成过程中被使用。

另外，ClientHello中还可能包含客户端支持的TLS扩展。(TLS扩展可以被用来丰富TLS协议的功能或者增强协议的安全性)

ServerHello：服务器接受到ClientHello后，会返回ServerHello。服务器从客户端在ClientHello中提供的密码套件、SSL/TLS版本、压缩算法列表里选择它所支持的项，并把它的选择包含在ServerHello中告知客户端。接下来SSL协议的建立就基于服务器选择的密码套件类型、SSL/TLS协议版本以及压缩算法。

ServerHello中同样会包含一个随机数，同样4+28 字节类型，由服务器生成。

Certificate：客户端和服务器都可以发送证书消息来证明自己的身份，但是通常客户端证书不被使用。 服务器一般在ServerHello后会接一条Certificate消息，Certificate消息中会包含一条证书链，从服务器证书开始，到Certificate authority(CA)或者最新的自签名证书结束。下图形象地描述了证书链：

SSL中使用的证书通常是X509类型证书，X509证书的内容如下表所示：

在用的X509证书包含Version 1和Version 3两种版本，其中v1版本的证书存在安全隐患，同时不支持TLS扩展，被逐渐弃用。现在大多数在用的SSL证书都是V3版本。

同时证书会附带与协商好的密钥交换算法对应的密钥。密钥交换算法以及它们所要求的密钥类型如下表所示。

ServerKeyExchange：该消息仅当以下密钥交换算法被使用时由服务器发出：

RSA_EXPORT(仅当服务器的公钥大于512bit时)、DHE_DSS、DHE_DSS_EXPORT、DHE_RSA、DHE_RSA_EXPORT、DH_anon 使用其它密钥交换算法时，服务器不能发送此消息。

ServerkeyExchange消息会携带这些密钥交换算法所需要的额外参数，以在后续步骤中协商PreMasterSecret。这些参数需要被签过名。

CertificateRequest：这个消息通常在要求认证客户端身份时才会有。消息中包含了证书类型以及可接受的CA列表。

ServerHelloDone：服务器发送这条消息表明服务器部分的密钥交换信息已经发送完了，等待客户端的消息以继续接下来的步骤。这条消息只用作提醒，不包含数据域。

ClientKeyExchange：这条消息包含的数据与所选用的密钥交换算法有关。

如果选择的密钥交换算法是RSA，那么消息包含的参数为用服务器RSA公钥(包含在之前证书中的或者是ServerKeyExchange中的)加密过的PreMasterSecret，它有48个字节，前2个字节表示客户端支持的最高协议版本，后46个字节是随机选择的。

如果选择的密钥交换算法是DH或者DHE，则可能有两种情况：

隐式DH公开值：包含在Certificate消息里;

显示DH公开值：公开值是本消息的一部分。

CertificateVerify：这条消息用来证明客户端拥有之前提交的客户端证书的私钥。

Finished：表明握手阶段结束。这是第一条用协商的算法和密钥保护的消息。

因为是用协商好的密钥加密的消息，它可以用来确认已经协商好的密钥。

同时Finished消息包含一个verify_data域，可以用来校验之前发送和接收的信息。

Verify_data域是一个PRF函数的输出(pseudo-random function)。这个伪随机函数的输入为：(1)两个hash值：一个SHA-1，一个MD5，对之前握手过程中交换的所有消息做哈希;(2)the MasterSecret，由预备主密钥生成;(3)finished_label，如果客户端发送的则是”client finished”，服务器发送的则是”server finished”。关于这个PRF的细节在33节中会具体描述。 此外，Finished 消息不能够在ChangeCipherSpec前发送。

22 不同密钥交换算法对应的握手过程

不同的密钥交换算法对应的握手过程中的消息序列是不同的，相应的实现方式也不同，本节介绍几个常见密钥交换算法对应的握手过程。

TLS-RSA：在这个场景下，PreMasterSecret是由客户端指定的，并用RSA公钥加密发送给服务器。服务器不影响PReMasterSecret的生成。

TLS-DH：基于DH的密钥交换也被称为静态Diffie-Hellman。在这种场景下，可能是双方各自提交一个证书包含DH公开值，或者服务器端提交证书包含DH公开值，客户端在每次会话中选择一个值。协商好的DH值被用作PreMasterSecret。显然证书中的参数是固定的，那么每次链接的PreMasterSecret也是相同的。

TLS-DH不能提供前向安全性。

TLS-DHE：基于DHE的TLS握手中会有ServerKeyExchange消息。握手过程中交换参数的认证通过数字签名来实现，支持的签名算法包括RSA和DSS。DH参数会有它的数字签名一起被包含在ServerKeyExchange中被发送出去。客户端在ClientKeyExchange中返回它的公开DH参数，但没有签名保护。同样协商出来的DH密钥被用作PreMasterSecret。

23 密钥生成

Pseudo-random Function(PRF)：伪随机函数是SSL协议中的一个重要组成部分，它被用来秘密扩展以及生成密钥。在31节讲解Finished消息时已经简单提及PRF，在这里我们详细讨论PRF的工作原理。SSL/TLS协议中的PRF如下图所示：

这个PRF基于两个hash函数：MD5和SHA-1，它有3个输入，一个Secret(比如PreMasterSecret)，一个标志符(比如”client finished”, “server finished”)，还有一个种子值(比如客户端随机数+服务器端随机数)。

Secret在使用时被分为长度相同的两半：S1和S2，分别作为P_MD5和P_SHA-1的输入。

PRF的输出按如下方式处理得到：

P_MD5和P_SHA-1都是扩展函数，用来扩展秘密值以用于密钥生成，它们的计算方式如下：

其中A(0) = seed, A(i) = HMAC hash( secret, A( i −1) )

这个秘密扩展会一直进行直到得到足够多的扩展数据。 Key Derivation：主密钥(MasterSecret)是利用上述PRF从预备主密钥(PreMasterSecret)生成的。每个MasterSecret为48字节，生成方式如下：

得到MasterSecret后，它会被进一步处理最后生成4个不同的密钥和2个初始向量(IV)。处理过程如下：

处理过程一直持续到足够多的输出被生成，然后把输出分为4个key和2个IV：

下图完整阐述了SSL/TLS协议中的密钥生成过程。

本节介绍SSL/TLS协议的版本变迁，不同版本的区别以及安全特性等。

SSL 10由于从来没有被公开过，并且存在严重安全漏洞，我们就不讨论了。

SSL 20：SSL 20于1995年4月被发布。SSL 20中主要存在的问题如下：

MAC不能覆盖填充长度域，攻击者可能利用这点破坏消息完整性;

缺乏握手认证，攻击者可以篡改密码套件列表，诱骗通信双方使用较弱的密码套件;

使用较弱的或有问题的密码算法(如MD5，RC4等)，或者使用不安全的分组模式(如CBC模式);

对于不同的密码学基元使用相同的密钥，违背基本安全常识。

由于以上安全问题，RFC 6176已经明确提出避免使用SSL 20，但是现实生活中还有少量客户端和服务器支持SSL 20

SSL 30：SSL 30引入了一些新的特性和机制解决了很多之前版本存在的漏洞。此外，SSL 30中引入了ChangeCipherSpec子协议。SSL 30向后兼容SSL 20，相对于SSL 20，它的主要改变包括以下几点：

支持更多的密码套件(支持更多的密码算法如DSS，SHA-1)

在握手阶段支持密钥协商(DH和FORTEZZA)

支持密码学参数的重协商

增加了消息压缩选项

MAC能够覆盖填充长度域了，同时MAC可以使用MD5或者SHA-1

不同的密码学基元使用不同的key

Alert子协议能对任何错误给出两种提示：Warning和Fatal

中止链接的时候会用一个close_notify警告通知通信双方

支持证书链，而非单个证书

通过Finished消息认证所有发送和接收的消息

加密了的PreMasterSecret包含当前使用的协议版本，防止协议回滚

TLS 10：TLS 10和SSL 30差别非常小。实际上，TLS 10是SSL 31，在IETF接手后改名为TLS。TLS 10版本是目前使用最广泛的SSL/TLS协议版本。

TLS 10不再支持使用FORTEZZA的密码套件。

TLS 10中MAC被替换成HMAC。

之前提到ChangeCipherSpec消息必须在Finished消息前发送，在TLS 10中，如果消息序列不符合这个要求，会产生FATAL警告并终止链接。

TLS 11：这个版本相比之前改动也很小。最重要的改动是预防了针对CBC分组模式的一些攻击。现在的填充错误变的和非法MAC错误不可区分了，防止攻击者利用可区分错误响应建立解密预言机对密文进行攻击。

在每次加密过程中，使用CBC分组模式时，都需要显示给出IV，而不用再密钥生成时使用PRF生成IV。

此外，TLS 11禁止为适应之前出口限制而使用弱化的密码套件。

TLS 12：这是最新的版本，部署的还比较少。这个版本禁用了PRF中的MD5和SHA-1，而用一个可配置的hash函数取代了它们，这样的修改简化了计算过程。修改后的PRF风格如下：

此外，TLS 12的一个重要变化是支持认证加密模式(支持GCM等)。但是由于一些AEAD(Authenticated Encryption with Associated Data)密码算法要求IV为隐式的，所以IV又恢复到由MasterSecret生成，即TLS 10以前的风格。

TLS 12支持使用GCM、CCM的新密码套件。

同时SSL 20被宣布放弃，不再向后兼容SSL 20

本节简单介绍一下流行的SSL/TLS实现库，SSL协议非常复杂，由开发者自己实现常常会出错，开发者在具体实现SSL协议时通常会依赖于这些密码学库。

41 常见的SSL/TLS 实现

OpenSSL：这是非常流行的开源SSL/TLS实现。

OpenSSLim完全用C语言实现，支持SSL 20/30，TLS 10/11/12以及DTLS 10。

OpenSSL 近年来出现了很多的安全漏洞，比如2014年曝出的著名的Heartbleed漏洞等。

JSSE：这是使用Java实现的，支持SSL 30，TLS 10/11/12

Bouncy Castle：它不仅仅支持SSL/TLS，它是一个完整的密码学库，支持各种密码学算法和协议。不过它仅仅支持TLS 10版本。

Android平台主要使用这个密码学库。

GnuTLS：这是另一个用C语言实现的库，支持SSL 30，TLS 10/11/12以及DTLS 10。主要在Unix世界被使用。同时以各种安全漏洞多而闻名。

NSS：这是最初由网景公司(Netscape)开发的库，支持SSL 20/30，TLS 10/11，现在主要被浏览器和客户端软件使用，比如Firefox使用的就是NSS库，Chrome使用的是一个NSS库的修正版。

下表是一些常见软件以及它们所使用的SSL/TLS实现库的情况：

其它还有一些常用的SSL实现库，如cryptlib、CyaSSL、MatrixSSL、PolarSSL等，由于市场占有率不高，我们这里就不多做介绍了。

42 流行SSL/TLS实现库的安全研究

最近几年曝出的高风险SSL安全漏洞大多跟SSL实现库有关，比如2014年4月曝出的“心脏滴血”漏洞，存在于OpenSSL 101-101f版本中，影响全球近17%的Web服务器;同样是2014年曝出的苹果公司iOS 706版本系统中存在的“gotofail”漏洞，因为程序员的疏忽导致SSL证书校验中的签名校验失效;包括今年曝出的SSL Freak攻击也是由于SSL实现库的安全漏洞导致的攻击，我们研究小组的同学对这个攻击有详细的分析，参见《SSL Freak来袭：如何实施一个具体的SSL Freak攻击》。同时我们还开发了一个基于python的中间人代理攻击框架“风声”对某国内知名电商的服务器进行具体的攻击，并上报了漏洞。

考虑到大量SSL/TLS实现库中存在安全问题，同时这些主流的SSL/TLS实现库对开发者而言使用难度较高，比如有些SSL/TLS实现库要求开发者自己进行随机数生成或密钥管理，让缺乏系统信息安全知识培训的开发者去使用这样高度复杂的密码学库容易产生很多安全问题。我们在这里推荐一些高级密码学库：Google keycazer、NaCl、Cryptlib、GPGME。这些密码学库存在的安全问题较少，同时封装了一些底层的密码学操作，降低了开发者的使用难度。

以上就是本次要介绍的SSL /TLS协议基本知识，后续的文章我们会对一些典型SSL/TLS攻击进行具体介绍。

参考：

1、 http://netsecurity51ctocom/art/201505/476337htm

2、 http://wwwcnblogscom/NathanYang/p/9183300html

3、 https://wwwcnblogscom/bhlsheji/p/4586597html

服务器的瞬时 Diffie-Hellman 公共密钥过弱ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY ，打开详细信息可看到“该错误会在连接到安全 (HTTPS) 服务器时发生。 这意味着服务器正在尝试建立安全连接， 但由于严重的配置错误，连接会很不安全！在这种情况下， 服务器需要进行修复。 为了保护您的隐私， “Google Chrome”不会使用不安全的连接。”

如果换用QQ或其他浏览器同样打不开此网站并得到类似Diffie-Hellman 密钥过弱的错误提示。这由于网站服务器上的SSL加密套件过弱造成的，比较早期版本的浏览器只支持40或56位加密，此类密钥较短的加密算法几前年已经被证实可能被破解，像新版本火狐、谷歌这种对信息安全要求较为严格的浏览器，会主动强制要求网站运营商更新加密套件，以提高网站访问的安全性。如果您只是普通的网上用户需要打开此网站，建议您换用IE、猎豹、Opera浏览器打开网页即可，虽然加密位不强，但总比HTTP网站信息裸奔好很多。

当然，如果您一直习惯用火狐浏览器，您也可以通过安装一个安全插件来修复此强制提升弱临时Diffie-Hellman 密钥问题