一、前言
随着安全的普及，https通信应用越发广泛，但是由于对https不熟悉导致开发人员频繁错误的使用https，例如最常见的是未校验https证书从而导致“中间人攻击”，并且由于修复方案也一直是个坑，导致修复这个问题时踩各种坑，故谨以此文简单的介绍相关问题。
本文第一节主要讲述https的握手过程，第二节主要讲述常见的“https中间人攻击”场景，第三节主要介绍证书校验修复方案，各位看官可根据自己口味浏览。
二、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则认为此证书不可信。
验证证书链的时候，用上一级的公钥对证书里的签名进行解密，还原对应的摘要值，再使用证书信息计算证书的摘要值，最后通过对比两个摘要值是否相等，如果不相等则认为该证书不可信，如果相等则认为该级证书链正确，以此类推对整个证书链进行校验。
二级机构的证书。
三、中间人攻击
https握手过程的证书校验环节就是为了识别证书的有效性唯一性等等，所以严格意义上来说https下不存在中间人攻击，存在中间人攻击的前提条件是没有严格的对证书进行校验，或者人为的信任伪造证书，下面一起看下几种常见的https“中间人攻击”场景。
1.证书未校验
由于客户端没有做任何的证书校验，所以此时随意一张证书都可以进行中间人攻击，可以使用burp里的这个模块进行中间人攻击。
通过浏览器查看实际的https证书，是一个自签名的伪造证书。
2.部分校验
做了部分校验，例如在证书校验过程中只做了证书域名是否匹配的校验，可以使用burp的如下模块生成任意域名的伪造证书进行中间人攻击。
实际生成的证书效果，如果只做了域名、证书是否过期等校验可轻松进行中间人攻击(由于chrome是做了证书校验的所以会提示证书不可信任)。
