谈HTTPS中间人攻击与证书校验（一）

1、前言

    随着安全的普及，https通讯应用愈加普遍，可是因为对https不熟悉致使开发人员频繁错误的使用https，例如最多见的是未校验https证书从而致使“中间人攻击”，而且因为修复方案也一直是个坑，致使修复这个问题时踩各类坑，故谨以此文简单的介绍相关问题。

    本文第一节主要讲述https的握手过程，第二节主要讲述常见的“https中间人攻击”场景，第三节主要介绍证书校验修复方案，各位看官可根据本身口味浏览。

2、HTTPS握手过程

    首先来看下https的工做原理，上图大体介绍了https的握手流程，后续咱们经过抓包看下每一个握手包到底干了些什么神奇的事。

    注：本文全部内容以TLS_RSA_WITH_AES_128_CBC_SHA加密组件做为基础进行说明，其余加密组件以及TLS版本会存在必定差别，例如TLS1.3针对移动客户端有了很大的改动，如今的ECDHE等密钥交换算法与RSA做为密钥交换算法也彻底不同，因此有些地方和你们实际操做会存在必定出入。

1.TCP三次握手

    我访问的支付宝的官网www.alipay.com抓取的数据。

2.Client Hello

     TLS的版本号和随机数random_c：这个是用来生成最后加密密钥的因子之一，它包含两部分，时间戳和随机数 session-id：用来标识会话，第一次握手时为空，若是之前创建过，能够直接带过去从而避免彻底握手 Cipher Suites加密组件列表：浏览器所支持的加密算法的清单客户端支持的加密签名算法的列表，让服务器进行选择 扩展字段：好比密码交换算法的参数、请求主机的名字，用于单ip多域名的状况指定域名。

3.Sever Hello

    随机数rando_s，这个是用来生成最后加密密钥的因子之一，包含两部分，时间戳和随机数 32字节的SID，在咱们想要从新链接到该站点的时候能够避免一整套握手过程。 在客户端提供的加密组件中，服务器选择了TLS_RSA_WITH_AES_128_CBC_SHA组件。

4.Certificate

    证书是https里很是重要的主体，可用来识别对方是否可信，以及用其公钥作密钥交换。能够看见证书里面包含证书的颁发者，证书的使用者，证书的公钥，颁发者的签名等信息。其中Issuer Name是签发此证书的CA名称,用来指定签发证书的CA的可识别的惟一名称(DN, Distinguished Name)，用于证书链的认证，这样经过各级实体证书的验证，逐渐上溯到链的终止点，便可信任的根CA，若是到达终点在本身的信任列表内未发现可信任的CA则认为此证书不可信。

    验证证书链的时候，用上一级的公钥对证书里的签名进行解密，还原对应的摘要值，再使用证书信息计算证书的摘要值，最后经过对比两个摘要值是否相等，若是不相等则认为该证书不可信，若是相等则认为该级证书链正确，以此类推对整个证书链进行校验。

   二级机构的证书。

   支付宝官网签名证书。

    不只仅进行证书链的校验，此时还会进行另外一个协议即Online Certificate Status Protocol, 该协议为证书状态在线查询协议，一个实时查询证书是否吊销的方式，客户端发送证书的信息并请求查询，服务器返回正常、吊销或未知中的任何一个状态，这个查询地址会附在证书中供客户端使用。

5.Server Hello Done

    这是一个零字节信息，用于告诉客户端整个server hello过程已经结束。

6.ClientKeyExchange

    客户端在验证证书有效以后发送ClientKeyExchange消息，ClientKeyExchange消息中，会设置48字节的premaster secret（由于的TLS版本的缘由，这里没有显示premaster），经过密钥交换算法加密发送premaster secret的值，例如经过 RSA公钥加密premaster secret的获得Encrypted PreMaster传给服务端。PreMaster前两个字节是TLS的版本号，该版本号字段是用来防止版本回退攻击的。

    从握手包到目前为止，已经出现了三个随机数(客户端的random_c，服务端的random_s，premaster secret)，使用这三个随机数以及必定的算法便可得到对称加密AES的加密主密钥Master-key，主密钥的生成很是的精妙。

7.Change Cipher Spec

    发送一个不加密的信息，浏览器使用该信息通知服务器后续的通讯都采用协商的通讯密钥和加密算法进行加密通讯。

8.Encrypted Handshake Message

    验证加密算法的有效性，结合以前全部通讯参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，而后发送给服务器用于数据与握手验证，经过验证说明加密算法有效。

9.Change_cipher_spec

    Encrypted Handshake Message经过验证以后，服务器一样发送 change_cipher_spec 以通知客户端后续的通讯都采用协商的密钥与算法进行加密通讯。

10.Encrypted Handshake Message

    一样的，服务端也会发送一个Encrypted Handshake Message供客户端验证加密算法有效性。

11.Application Data

    通过一大串的的计算以后，终于一切就绪，后续传输的数据可经过主密钥master key进行加密传输，加密数据查看图中的Encrypted Apploication Data字段数据，至此https的一次完整握手以及数据加密传输终于完成。

    https里还有不少可优化而且不少精妙的设计，例如为了防止常常进行完整的https握手影响性能，因而经过sessionid来避免同一个客户端重复完成握手，可是又因为sessionid消耗的内存性能比较大，因而又出现了new session ticket，若是客户端代表它支持Session Ticket而且服务端也支持，那么在TLS握手的最后一步服务器将包含一个“New Session Ticket”信息，其中包含了一个加密通讯所须要的信息，这些数据采用一个只有服务器知道的密钥进行加密。这个Session Ticket由客户端进行存储，并能够在随后的一次会话中添加到 ClientHello消息的SessionTicket扩展中。虽然全部的会话信息都只存储在客户端上，可是因为密钥只有服务器知道，因此Session Ticket仍然是安全的，所以这不只避免了性能消耗还保证了会话的安全性。

    最后咱们可使用openssl命令来直观的看下https握手的流程：