SSL简单介绍

这篇是最近看SSL和HTTPS的一个简单性总结，其中内容大部分都是参考网络上的内容，自己归纳整理了下。

SSL介绍

HTTPS介绍

HTTP请求数据工作流程：

l  用户在浏览器中输入网址，并告诉浏览器自己需要那些东西；

l  浏览器解析网址，并将用户需要的东西记录成一张清单；

l  浏览器发送信息给服务器，并附上清单，告诉服务器自己需要那些信息；

l  服务器收到浏览器发送的信息，将对应的信息和清单返回回去；

l  服务器发送信息给浏览器；

l  浏览器拿到信息，并根据清单核对信息；

l  将信息展现给用户。

 

这其中就有个问题，浏览器和服务器都没有验证清单信息的有效性和对方的身份。万一有人在中途将浏览器（服务器）传递给服务器（浏览器）的信息截获下来，然后将信息清单给替换掉，或者直接伪造一个信息请求代替原来的请求发送给服务端这种情况该怎么办。

HTTPS

正是因为HTTP请求有这些安全性的问题，所以HTTPS诞生了。

HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL，而它的大体方式如下：

 

1.    客户端向服务器索要公匙，然后使用公匙加密信息

2.    服务器收到加密后的信息，用自己的私匙解密

公钥密码和算法都是公开的，而私钥则是保密的。加密使用的公钥和解码使用的私钥都是不相同的，因此这是一个 非对称加密 算法。

对称加密和非对称加密

对称加密

对称加密是最快速、最简单的一种加密方式，加密（encryption）与解密（decryption）用的是同样的密钥（secret key）。对称加密有很多种算法，由于它效率很高，所以被广泛使用在很多加密协议的核心当中。

对称加密通常使用的是相对较小的密钥，一般小于256 bit。因为密钥越大，加密越强，但加密与解密的过程越慢。如果你只用1 bit来做这个密钥，那黑客们可以先试着用0来解密，不行的话就再用1解；但如果你的密钥有1 MB大，黑客们可能永远也无法破解，但加密和解密的过程要花费很长的时间。

非对称加密

非对称加密为数据的加密与解密提供了一个非常安全的方法，它使用了一对密钥，公钥（public key）和私钥（private key）。私钥只能由一方安全保管，不能外泄，而公钥则可以发给任何请求它的人。非对称加密使用这对密钥中的一个进行加密，而解密则需要另一个密钥。比如，你向银行请求公钥，银行将公钥发给你，你使用公钥对消息加密，那么只有私钥的持有人--银行才能对你的消息解密。与对称加密不同的是，银行不需要将私钥通过网络发送出去，因此安全性大大提高。

数字证书

因为互联网不安全，公钥也是信息的一部分，也是会有被篡改的风险的。所以引入了互联网权威机构 - CA 机构，又称为证书授权 (Certificate Authority) 机构，浏览器会内置这些"受信任的根证书颁发机构" (即 CA)。

服务端向权威的身份鉴定 CA 机构申请数字证书，CA 机构验证了网站之后，会把网站录入到内部列表，采用 Hash 把服务端的一些相关信息生成摘要，然后 CA 机构用自己的私匙，把服务端的公钥和相关信息一起加密，然后给申请证书的服务端颁发数字证书，用于其他客户端 (比如浏览器) 认证这个网站的公钥。

客户端通过服务端下发的证书，找到对应的 CA，然后向 CA 验证这个证书是否有效，CA 验证通过之后，下发服务端的公钥。

因为 CA 是权威并且可信的，所以客户端 (浏览器) 信任 CA，而 CA 又信任经过认证的服务端，所以客户端 (浏览器) 也信任这个服务端，这就是信任链 (Chain Of Trust)。

而 CA 颁发的数字证书，一般包含这些信息：

简单来说：为了保证公钥是安全的，所以通过数字证书验证公匙。

SSL介绍

SSL(SecureSockets Layer 安全套接层),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。

目前TLS的版本为1.2（也被标示为SSL3.3），被现在主流的浏览器所支持。

SSL协议的三个特性：

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

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

l  完整性：传送的消息包括消息完整性检查。

 

SSL工作原理：

握手协议（Handshake protocol）

记录协议（Record protocol）

警报协议（Alert protocol）

握手协议

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

 

每个握手协议包含以下3个字段
（1）Type：表示10种消息类型之一
（2）Length：表示消息长度字节数
（3）Content：与消息相关的参数

握手协议的4个阶段

 

 

第一阶段建立安全链接的能力

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

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

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

（2）一个用于生成主密钥的随机数。

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

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

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

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

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

（2）一个用于生成主密钥的随机数。

（3）会话ID

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

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

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

（1）SSL版本

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

（3）压缩方法

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

 

第二阶段服务器鉴别与密钥交换

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

（a）证书：服务器将数字证书和到根CA整个链发给客户端，使客户端能用服务器证书中的服务器公钥认证服务器。
（b）服务器密钥交换（可选）：这里视密钥交换算法而定
（c）证书请求：服务端可能会要求客户自身进行验证。
（d）服务器握手完成：第二阶段的结束，第三阶段开始的信号

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

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

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

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

 

第三阶段客户端鉴别与密钥交换

 

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

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

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

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

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

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

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

 

第四阶段完成

到了这一阶段，客户端和服务端都有了三个数据——客户端随机数、服务端随机数、预备主密钥。

然后客户端和服务端按照之前已经约定好的加密方式，生成了“同一把”会话密钥，接下来客户端和服务端的信息传递还是通过HTTP协议来传输，只不过信息的内容都是通过会话密钥的加密处理，只有用同一把密钥来解密，才能够获得其中的内容。

到此，客户端和服务端的握手协议就完成了，双方也建立起了安全的信息传递通道。

 

记录协议

 

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

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

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

记录协议的过程：

 

第一个步骤是分片

每一个使用者想要通过SSL传送的消息都会被切割成最多214B(或者是16364B)大小的分片，接着，可以选择是否执行压缩的步骤。

压缩的过程中，必须是无损失压缩，也就是说解压缩后能够得到原本完整的消息。除此之外，经过压缩后的内容长度不能超过原有长度1024字节以上(当然，我们希望压缩后的数据能够更小，而不是增多。但对于有些长度非常小的分片来说，可能因为压缩算法格式上的要求，压缩过后的结果会比原来数据还长)。在SSLv3(以及TLS的现有版本)，并没有指定压缩算法，所以预设的加算法是null。

第二个步骤是添加MAC（Message Authentication Cores）

消息认证码（带密钥的Hash函数）:密码学中，通信实体双方使用的一种验证机制，保证消息数据完整性的一种工具。构造方法由M.Bellare提出，安全性依赖于Hash函数，故也称带密钥的Hash函数。消息认证码是基于密钥和消息摘要所获得的一个值，可用于数据源发认证和完整性校验。

在发送数据之前，发送方首先使用通信双方协商好的散列函数计算其摘要值。在双方共享的会话密钥作用下，由摘要值获得消息验证码。之后，它和数据一起被发送。接收方收到报文后，首先利用会话密钥还原摘要值，同时利用握手协议里面商量好的散列函数在本地计算所收到的数据上，再生成摘要值，并将这两个数据进行比对。若两者相等，则报文通过认证。

第三步为添加SSL记录报头

这个记录头包含以下的字段。

(1)数据类型(Contenttype)，8位：用来处理这个分片的上层协议。

(2)主要版本号(MajorVersion)，8位：所使用的SSI。协议的主要版本，对于SSI。v3协议来说，这个字段值为3。

(3)次要版本号(MinorVersion)，8位：表示使用的次要版本，对于SSLv3协议来说，这个字段值为0。

(4)压缩后数据长度(Compressedlength)，16位：这个明文分片的长度(假如此分片已经过压缩，则为压缩后的长度)。最大值为(214+2048)B。

 

警告协议

SSL警告协议亦称SSL告警协议、SSL报警协议，是用来为对等实体传递SSL的相关警告。如果在通信过程中某一方发现任何异常，就需要给对方发送一条警示消息通告。

　SSL报警协议报文由严重级别和警告代码两部分组成，如图所示。

SSL报警协议中严重级别分为Fatal和Warning为两种。其中，Fatal级报警即致命级报警，它要求通信双方都要采取紧急措施，并终止会话，如在数据传输过程中，若发现有错误的MAC，双方就需要立即中断会话，同时消除自己缓冲区相应的会话记录；而对Warning级报警即警告级报警的处理，通常是通信双方都只进行日志记录，它对通信过程不造成影响。

　　以下是一些警告信息：

　　(1)unexpected_message：接收了不合适的报文。

　　(2)bad_record_mac：收到了不正确的MAC。

　　(3)decompression_failure：解压缩函数收到不适当的输入。

　　(4)illegal_parameter：握手报文中的一个字段超出范围或与其他字段不兼容。

　　(5)certificate_revoked：证书已经被废弃。

　　(6)bad_certificate：收到的证书是错误的。

　　(7)certificate_expired：证书已经过期。

　　(8)handshake_failer：握手过程失败。

单向认证

Https在建立Socket连接之前，需要进行握手，具体过程如下：

1.    客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。

2.    服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书

3.     客户端使用服务端返回的信息验证服务器的合法性，包括：

o 证书是否过期

o 发型服务器证书的CA是否可靠

o 返回的公钥是否能正确解开返回证书中的数字签名

o 服务器证书上的域名是否和服务器的实际域名相匹配

验证通过后，将继续进行通信，否则，终止通信

4.    客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择

5.    服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。

6.    服务器将选择好的加密方案通过明文方式返回给客户端

7.    客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器

8.    服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，获取对称加密密钥。 
在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。

双向认证

双向认证和单向认证原理基本差不多，只是除了客户端需要认证服务端以外，增加了服务端对客户端的认证，具体过程如下：

1.    客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。

2.    服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书

3.     客户端使用服务端返回的信息验证服务器的合法性，包括：

o 证书是否过期

o 发型服务器证书的CA是否可靠

o 返回的公钥是否能正确解开返回证书中的数字签名

o 服务器证书上的域名是否和服务器的实际域名相匹配

验证通过后，将继续进行通信，否则，终止通信

4.    服务端要求客户端发送客户端的证书，客户端会将自己的证书发送至服务端

5.    验证客户端的证书，通过验证后，会获得客户端的公钥

6.    客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择

7.    服务器端在客户端提供的加密方案中选择加密程度最高的加密方式

8.    将加密方案通过使用之前获取到的公钥进行加密，返回给客户端

9.    客户端收到服务端返回的加密方案密文后，使用自己的私钥进行解密，获取具体加密方式，而后，产生该加密方式的随机码，用作加密过程中的密钥，使用之前从服务端证书中获取到的公钥进行加密后，发送给服务端

10.  服务端收到客户端发送的消息后，使用自己的私钥进行解密，获取对称加密的密钥，在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。