抓HTTPS报文分组来分析TLS/SSL协议

追踪TCP流

        TLS/SSL创建在应用层和传输层TCP之间，将到达TCP前的数据都进行加密处理，前面作了那么多的工做，握手密钥协商，数字签名防抵赖等，都是为了保证数据的完整性和机密性。HTTP结合TLS/SSL协议就是HTTPS，若是HTTP消息不交由TLS/SSL协议，一旦流量被截获了，最大的问题就是隐私泄露， 若是咱们在一个没有部署HTTPS的网站上登录咱们的信息，以HTTP流量方式进行发送，因为明文传输的缘由，一旦请求被截获，里面的内容就泄露了。路由选择让这些报文分组通过不少节点设备，在这些节点路由中等待分组转发的报文都有可能被截获而后篡改，虽然TCP可以保证数据正确到达通讯双方处，但不能保证数据是正确的没有被篡改的，对于没有使用TLS/SSL的服务器来讲，只要收到的HTTP请求格式是正确的，就会给予响应。像下面这样状况：

        若是咱们在一个HTTP页面传输数据，例如在一个登录页面，输入本身的用户名和密码并发送给服务器，中途流量被截获了，直接泄露了咱们发送的数据，像上图同样。而若是咱们在部署了HTTPS的网站上登录，由于数据在到达TCP前就交由TLS/SSL协议进行加密，以后再发送，因此中间流量被截获后，看到的也是通过加密的密文：

        能够看到，用户名和密码都是一串乱码。拿DH密钥协商举例，客户端和服务器端通过密钥协商后获得对方的公钥，使用公钥加密后的密文仅对方的私钥能够解出明文，因此即便在流量发送过程当中被截获了，也能保证数据不泄露。

        除了数据未加密的问题外，身份校验也是一个问题，在部署了HTTPS的网站中，CA机构会为其签发一张证书，证书里面包含了一些服务器的关键信息，例如服务器公钥，主机名等，CA机构用本身的RSA私钥对该证书进行签名，浏览器由于对CA机构的信任，一般内嵌CA机构的公钥，在身份校验时，服务器向客户端发送本身的证书，浏览器使用CA公钥验证证书签名，成功后，便可使用里面的服务器公钥进行密钥协商。

        TLS/SSL协议作的东西不少，前面的日志里也总结了大体的步骤，还有各个子协议，子消息和扩展项，接下来抓一下HTTPS流量，看看一个网址从创建链接开始，到会话恢复等各部份内容，分析下整个TLS的处理过程。

捕获HTTPS流量

        首先打开一个HTTPS网页，就拿CSDN首页为例吧，打开网站后，咱们抓取过程当中的HTTPS流量，看看使用TLS协议的网站在客户端（浏览器）和服务器端创建链接过程当中发送交换的各个子消息：

        能够看到，咱们访问一个HTTPS网站时，使用了TLS v1.2版本协议，经历了握手协议过程，

一、 首先由客户端发送Client Hello子消息，而后服务器端回应ServerHello。

二、 接着由服务器（注意看前面，服务器ip为47.95.47.253）发送证书Certificate，Certificate Status扩展供证书吊销状态校验，Server Key Exchange子消息表示进行密钥协商的一部分，例如使用DH密钥协商，服务器须要向客户端发送本身的DH参数和DH公钥，因此经过该子消息来传递。最后发送Server Hello Done。

三、 客户端在收到Server Hello Done后，回应Client Key Exchange进行密钥协商（例如根据服务器发来的DH参数生成客户端DH密钥对，而后经过Client Key Exchange子消息把客户端公钥发送给服务器端，完成密钥协商），Change Cipher Spec子消息表示TLS记录层须要的加密参数都准备好，能够切换链接状态为可读和可写状态。最后的Encrypted Handshake Message子消息就是Finished子消息，用来校验握手消息没有被篡改。

四、 最后是由服务器发送Change Cipher Spec和Encrypted Handshake Message，注意上图中服务器还发送了New Session Ticket，代表了本次会话可使用Session Ticket方式进行会话恢复。待服务器发送完Finished子消息后，接下来的应用层数据均可以进行加密处理了。

Client Hello

        按照前面咱们说过的，Client Hello子消息中包含有客户端支持的密码套件（用于协商），扩展项等，下面查看下Client Hello子消息里的详细内容：

        能够看到，最上面Record Layer：Handshake Protocol，由TLS记录层进行了封装握手协议，握手协议中发送的子消息是Client Hello，里面是客户端支持的最高TLS版本号v1.2，随机数Random，Session ID和支持的密码套件，能够看到支持的妈咪套件由17个，优先支持的是TLS_AES_128_GCM_SHA256（0x1301）。

        往下看还有客户端的扩展项，server_name表示客户端使用了SNI服务器名称指示扩展，告诉服务器请求访问的主机名，让服务器发送相应的证书供校验。session_ticket扩展就是告诉服务器请求使用SessionTicket方式进行会话恢复，第一次创建完整TLS握手时，客户端发送的该扩展是空的，由服务器决定是否支持SessionTicket。status_request扩展也是之前总结过，若是校验证书吊销状态方式使用OCSP在线证书状态协议，那么就是发送该扩展，若是使用OCSP套封，即由服务器来发送OCSP请求，获取响应后，服务器再向客户端发送CertificateStaus子消息，里面包含了证书吊销状态信息。还有一个signed_certificate_timestamp扩展表示支持证书透明度机制，由CA机构或服务器实体提交，Certificate Logs返回一个SCT信息，至关于也是一个票据，客户端再TLS/SSL协议握手阶段获取该SCT信息，证实该证书是通过监控和审计的。

Server Hello

接下来看服务器端回应的Server Hello：

        能够看到，常规的TLS版本号，随机数信息，值得注意的是Session ID为0，代表在本次握手中，服务器端选择了不使用Session ID进行会话恢复，从上面Client Hello和Server Hello中都看到空的session_ticket扩展项，代表服务器端支持也选择使用SessionTicket进行会话恢复，因此弃用了Session ID。

Certificate

        往下走，由服务器端发送Certificate证书供客户端进行校验，从证书信息中咱们能够看到，除了服务器实体证书外，还有一个中间证书：

        第一个证书是咱们的服务器实体证书，也就是CSDN的服务器，commonName=*.csdn.net。证书版本v3，序列号信息，还有使用的证书签名算法为sha256WithRSA。下面的validity标识证书的有效期，从2018-11-07到2020-11-06，还有一个值得注意的重要信息是服务器公钥，subjectPublicKey。第二个证书是中间证书，由GeoTrust RSA CA机构签发，详细信息就不展现出来了，有兴趣的你们能够去抓抓CSDN的首页来看便可。

Certificate extension

        证书中还要注意的是证书扩展项，里面有不少内容，标识该证书的做用，拿服务器实体证书为例，看看里面的扩展项都有哪些：

        证书中有10个扩展项，authorityKeyIdentifier是CA密钥标识符，subjectKeyIdentifier则是使用者密钥标识符，subjectAltName扩展标识了服务器主机名。keyUsage扩展项比较重要，标识该证书的功能，例如digitalSignature：True表示能够进行数字签名，还有extKeyUsage扩展项，用来表示证书的使用场合，红笔圈起部分能够看到该证书能够用来进行服务器端身份校验和客户端身份校验。

        authorityInfoAccess扩展里写有OCSP服务的地址和证书地址，basicConstraints基础约束扩展表示该证书是一张普通证书，不能使用其来签发其余证书。

Server Key Exchange

        使用DH密钥协商方式，服务器端发送DH参数和公钥给客户端，因此须要Server Key Exchange子消息：

        能够看到ECDH（EC Diffie-Hellman）参数服务器公钥Pubkey，Signature签名值是服务器端对该DH参数进行签名。

Client Key Exchange

        客户端收到服务器发送的DH参数和公钥后，使用DH参数生成本身的密钥对，保留私钥，把公钥经过Client Key Exchange发送给服务器端，完成密钥协商：

Change Cipher Spec

        Change Cipher Spec子消息很简单，做用是告诉服务器端，客户端须要的加密参数都准备好了，客户端的TLS记录层协议能够对数据进行加密了，将链接状态由待读状态和待写状态切换为可读状态与可写状态：

Encrypted Handshake Message（Finished）

        本身的密钥块准备好，发送了Change Cipher Spec后，再给对方发送Finished供校验全部的握手消息是没有被篡改的：

上为客户端发送，下为服务器端发送。

捕获会话恢复

        前面说过会话恢复有两种方式，Session ID和Session Ticket两种，这里我以经常使用的Session Ticket方式为例，抓包一下HTTPS流量，看看这Session Ticket恢复方式过程当中都发送了哪些子消息。

        我抓的是简书网站的HTTPS流量，看看第一次创建完整TLS握手的过程：

        能够看到，第一次完整的TL握手，Client Hello和Server Hello（若是服务器支持）子消息中都会带有空的session_ticket扩展项，服务器端最后会发送New Session Ticket子消息，里面保存了本次会话的一些信息：

        例如票据的有效期Lifetime为300秒，即5分钟，服务器端对票据的加密值也在里面。接下来咱们关闭简书网页，再从新打开，看看它是否经过Session Ticket方式进行会话恢复：

        果真，第二次握手使用了简短的握手，由于采用了会话恢复方式，客户端和服务器端不须要从新进行密钥协商，故能够看到在本次握手中，服务器端没有发送Certificate证书供校验，没有发送Server Key Exchange进行密钥协商，没有发送Server Hello Done子消息；客户端也没有发送Client Key Exchange，双方都是直接发送Change Cipher Spec子消息告诉对方本身须要的加密参数已经准备好了，而后发送Finished，会话恢复完成。