HTTPS协议、TLS协议、证书认证过程解析
一、HTTPS 协议
HTTPS协议其实就是HTTP over TSL，TSL(Transport Layer Security) 传输层安全协议是https协议的核心。
TSL可以理解为SSL (Secure Socket Layer)安全套接字层的后续版本。
TSL握手协议如下图所示
（注：图片来源于google图片）
在建立TCP连接后，开始建立TLS连接。下面抓包分析TLS握手过程，抓包图片来源于传输层安全协议抓包分析之SSL/TLS (自己没抓到这么完整的包，只能搬运过来了，摔)
(1) client端发起握手请求，会向服务器发送一个ClientHello消息，该消息包括其所支持的SSL/TLS版本、Cipher Suite加密算法列表（告知服务器自己支持哪些加密算法）、sessionID、随机数等内容。
(2) 服务器收到请求后会向client端发送ServerHello消息，其中包括：
SSL/TLS版本；
session ID，因为是首次连接会新生成一个session id发给client；
Cipher Suite，sever端从Client Hello消息中的Cipher Suite加密算法列表中选择使用的加密算法；
Radmon 随机数。
(3) 经过ServerHello消息确定TLS协议版本和选择加密算法之后，就可以开始发送证书给client端了。证书中包含公钥、签名、证书机构等信息。
(4) 服务器向client发送ServerKeyExchange消息，消息中包含了服务器这边的EC Diffie-Hellman算法相关参数。此消息一般只在选择使用DHE 和DH_anon等加密算法组合时才会由服务器发出。
(5) server端发送ServerHelloDone消息，表明服务器端握手消息已经发送完成了。
(6) client端收到server发来的证书，会去验证证书，当认为证书可信之后，会向server发送ClientKeyExchange消息，消息中包含客户端这边的EC Diffie-Hellman算法相关参数，然后服务器和客户端都可根据接收到的对方参数和自身参数运算出Premaster secret，为生成会话密钥做准备。
(7) 此时client端和server端都可以根据之前通信内容计算出Master Secret（加密传输所使用的对称加密秘钥），client端通过发送此消息告知server端开始使用加密方式发送消息。
(8) 客户端使用之前握手过程中获得的服务器随机数、客户端随机数、Premaster secret计算生成会话密钥master secret，然后使用该会话密钥加密之前所有收发握手消息的Hash和MAC值，发送给服务器，以验证加密通信是否可用。服务器将使用相同的方法生成相同的会话密钥以解密此消息，校验其中的Hash和MAC值。
(9) 服务器发送ChangeCipherSpec消息，通知客户端此消息以后服务器会以加密方式发送数据。
(10) sever端使用会话密钥加密（生成方式与客户端相同，使用握手过程中获得的服务器随机数、客户端随机数、Premaster secret计算生成）之前所有收发握手消息的Hash和MAC值，发送给客户端去校验。若客户端服务器都校验成功，握手阶段完成，双方将按照SSL记录协议的规范使用协商生成的会话密钥加密发送数据。
二、session ID的复用
根据rfc5246，client和server建立TLS握手过程如下所示：
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 1. Message flow for a full handshake
* Indicates optional or situation-dependent messages that are not always sent.
client在向server发送ClientHello消息的时候，会传送Session ID给server端，server端收到session Id后会去session缓存中查找是否有相同值。如果找到相同值，则server直接发送一个具有相同session ID的ServerHello消息给client端（此时不必新建Session ID），然后双方各发一次ChangeCipherSpec消息后直接进入Finished消息互发阶段，具体如下图所示：
Client Server
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Figure 2. Message flow for an abbreviated handshake
client和server通过缓存Session ID可以快速建立TLS握手，但是这么做也有一些弊端，例如：1）负载均衡中，多机之间往往没有同步 Session 信息，如果客户端两次请求没有落在同一台机器上就无法找到匹配的信息；2）服务端存储 Session ID 对应的信息不好控制失效时间，太短起不到作用，太长又占用服务端大量资源。而 Session Ticket（会话记录单）可以解决这些问题，Session Ticket 是用只有服务端知道的安全密钥加密过的会话信息，最终保存在浏览器端。浏览器如果在 ClientHello 时带上了 Session Ticket，只要服务器能成功解密就可以完成快速握手。
三、数字证书的验证
client端收到server端发过来的证书，首先必须要做的事验证证书是否可信。如何验证证书是否可信呢？为了解决这个问题，我们先来了解下证书的组成
从这里面我们能看到证书包含以下内容：
(1) Validity也即有效期，有效期包含生效时间和失效时间，是一个时间区间；
(2) 公钥信息Subject Public Key Info，包括公钥的加密算法和公钥内容；
(3) Fingerprints信息，fingerprints用于验证证书的完整性，也就是说确保证书没有被修改过。 其原理就是在发布证书时，发布者根据指纹算法(此处证书使用了SHA-1和SHA-256算法)计算整个证书的hash值(指纹)并和证书放在一起，client在打开证书时，自己也根据指纹算法计算一下证书的hash值(指纹)，如果和刚开始的值相同，则说明证书未被修改过；如果hash值不一致，则表明证书内容被篡改过；
(4) 证书的签名Certificate Signature Value和Certificate Signature Algorithm，对证书签名所使用的Hash算法和Hash值；
(5) 签发该证书的CA机构Issuer；
(6) 该证书是签发给哪个组织/公司信息Subject；
(7) 证书版本Version、证书序列号Serial Number以及Extensions扩展信息等。
如上图所示，为签名过程和client端验证过程。中间方框为一个数字证书，在制作数字证书时，会将证书中的部分内容进行一次Hash得到一个Hash值，然后证书认证机构简称CA会使用私钥将该Hash值加密为Certificate Signature。
当证书发送给Client端之后，Client端首先会使用同样的Hash算法获得一个证书的hash值H1。通常浏览器和操作系统中集成了CA机构的公钥信息，浏览器收到证书后可以使用这些公钥解密Certificate Signature内容，得到一个hash值H2。
比较H1和H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。
自己通过openssl生成的自签发证书只是使用自己的私钥去加密上图左侧计算出的Hash Value，这个时候client端得到server端发过来的证书之后，仍然会尝试使用浏览器或系统内置的CA机构的公钥去解密，解密出来的hash值H2当然不可能与H1相同，因此浏览器认为该证书不受信任。但是如果我们选择相信该证书并且继续访问该web，访问并不会出现任何问题，这是因为证书中的公钥并未加密，使用该公钥也确实能和server端的私钥进行TLS握手。
四、证书信任链
在证书认证过程中还存在一个证书信任链的问题，因为我们从CA机构申请到的证书基本不可能是根证书签发。还是以百度的证书为例，如下图所示，百度证书层级为三层，认证过程如下：
(1) 当client端访问baidu.com的时候，baidu的server会将baidu.com证书发送给client端。
(2) client端的操作系统或者浏览器中内置了根证书，但是client端收到baidu.com这个证书后，发现这个证书不是根证书签发，无法根据本地已有的根证书中的公钥去验证baidu.com证书是否可信。
于是client端根据baidu.com证书中的Issuer找到该证书的颁发机构GlobalSign Organization Validation CA - SHA256 - G2，去CA请求baidu.com证书的颁发机构GlobalSign Organization Validation CA - SHA256 - G2的证书。
(3) 请求到证书后发现GlobalSign Organization Validation CA - SHA256 - G2证书是由根证书签发，而本地刚好有根证书，于是可以利用根证书中的公钥去验证（验证方法见上一节）GlobalSign Organization Validation CA - SHA256 - G2证书，发现验证通过，于是信任GlobalSign Organization Validation CA - SHA256 - G2证书。
(4) GlobalSign Organization Validation CA - SHA256 - G2证书被信任后，可以使用GlobalSign Organization Validation CA - SHA256 - G2证书中的公钥去验证baidu.com证书的可信性。验证通过，于是信任baidu.com证书。
在这四个步骤中，最开始client端只信任根证书GlobalSign Root CA证书的，然后GlobalSign Root CA证书信任GlobalSign Organization Validation CA - SHA256 - G2证书，而GlobalSign Organization Validation CA - SHA256 - G2证书又信任baidu.com证书，于是client端也信任baidu.com证书。这样的一个过程就构成了一条信任链路，整个证书信任链验证流程如下图所示。
五、非对称加解密
非对称加密包含一个密钥对：公钥和私钥。公钥可以公开，私钥必须安全保存。
如上图所示，数据可以被公钥加密，加密后的数据只有持有私钥才能进行解密。同理私钥加密的数据，也只有对应的公钥才能解密。
建立HTTPS连接以后，client（浏览器）已经获得server段的公钥，并且经过TLS协议在握手过程中协商出一个只有双方知道的对称密钥，在后续的数据传输过程中都将使用该密钥进行数据加密传输。因为公钥是公开的，可以下发给所有client端的，这个时候即使其他拥有公钥的client端截获到server端发给client端的消息，也无法仅仅凭借公钥去解密这个消息，因为这个消息加密密钥是由client和server通过相同算法计算出来，并且添加了随机数，理论上这个对称密钥只有client和server才能知道。
参考文档：
https://tools.ietf.org/html/rfc5246#page-6
http://www.freebuf.com/articles/network/116497.html
https://imququ.com/post/optimize-tls-handshake.html
http://blog.csdn.net/wzzvictory/article/details/9015155
posted on 2017-11-08 22:52 snowater 阅读(27776) 评论(4) 编辑 收藏 举报
