HTTPS握手过程

HTTPS 原理

  • HTTPS
    • HTTPS是身披SSL外壳的HTTP。HTTPS是一种通过计算机网络进行安全通信的传输协议,经由HTTP进行通信,利用SSL/TLS建立全信道,加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证,同时保护交换数据的隐私与完整性。
    • SSL 技术最初是由浏览器开发商网景通信公司率先倡导的,开发过 SSL3.0 之前的版本。目前主导权已转移到 IETF(InternetEngineering Task Force,Internet 工程任务组)的手中。
    • TSL 是以 SSL 为原型开发的协议,有时会统一称该协议为 SSL。当前主流的版本是 SSL3.0 和 TLS1.0。
  • 加密方案
    • 对称加密
      • 加密双方使用同一密钥进行加密解密
    • 非对称加密
      • 分为公钥和私钥
      • 公钥和私钥成对出现
      • 用公钥加密的数据只有对应私钥可以解密
      • 用私钥加密的数据只有对应公钥可以解密
      • 公钥一般用于加密和验证签名
      • 私钥一般用于解密和进行数字签名
  • SSL握手过程
    • 握手过程图img

      1. 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 指定版本,加密组件列表(所使用的加密算法以及密钥长度等)
      1. 服务端发送 Server Hello 给客户端。服务端从客户端给出的ssl版本以及加密算法等信息,返回加密算法,这个加密算法一定是client发送给server加密算法的子集。
      1. 服务器发送 Certificate 报文,其中包含带有服务端公钥的证书。
      • 证书可以由服务端自行制作,或者使用第三方权威机构(CA)颁发的证书。但是自己制作的证书需要客户端验证才可以用。这套证书其实就是一对公钥和私钥。传送证书,这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间、服务端的公钥,第三方证书认证机构(CA)的签名,服务端的域名信息等内容。
      1. 服务器发动 Server Hello Done 的报文通知客户端,最初阶段的SSL握手协商结束。
      1. SSL第一次握手结束之后,客户端解析证书(客户端的TLS完成),如果证书有问题,就发出警告。拿到服务端的公钥。以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-mastersecret (预主密钥)的随机密码串。该报文已用步骤 3 中的公钥进行加密。
      1. 客户端发送 Change Cipher Spec 报文,该报文会提示服务器,在此报文之后的通信会采用 Pre-master secret 密钥加密。
      1. 客户端发送 Finshed 报文。该报文包含连接至今的全部报文的校验值。此次握手是否成功,要以服务端是否可以正确解析该报文作为判定标准。
      1. 服务端同样发送 Change Cipher Spec 报文
      1. 服务端同样发送 Finshed 报文
      1. 服务端和客户端的 Finshed 报文交换文笔后,SSL 连接就算建立完成了。从此处开始,进行应用层的协议,即发送HTTP请求。
  • SSL握手中密钥的交换关键点
      1. 假设传输双方 A 为客户端,B 为服务端
      1. 最终的传输是以对称加密来传输信息的,而对称加密所用的密钥是非对称加密握手获得的
      1. B要把自己的公钥传给A,但是为了防止被中间人篡改,所以找到了CA,一般情况下B把自己的域名在CA处进行认证,然后由CA颁发一个证书,里面含有已经生成好了的公钥和私钥。
      1. A的浏览器里面已经内置了CA机构的公钥,所以用这个公钥可以从证书中解出B的公钥
      1. 然后A把最终要使用的对称加密密钥,用公钥加密传给B
      1. B收到后,就可以用对称加密进行传输了
  • HTTPS传输过程中的一些问题
    • 怎么保证保证服务器给客户端下发的公钥是真正的公钥,而不是中间人伪造的公钥呢?
      • CA证书
    • 如何保证证书不被篡改?
      • 首先,CA机构的公钥是人尽皆知的,中间人可以解密这个证书,拿到B的公钥。但是他无法把自己的公钥替换成B的制作证书,因为制作证书需要CA机构的私钥,中间人肯定是没有的。所以CA机构的存在是防止中间人伪造服务端的公钥。
    • 数字证书的内容
      • 包括了加密后服务器的公钥、权威机构的信息、服务器域名,还有经过CA私钥签名之后的证书内容(经过先通过Hash函数计算得到证书数字摘要,然后用权威机构私钥加密数字摘要得到数字签名),签名计算方法以及证书对应的域名。
    • 验证证书安全性过程
        1. 当客户端收到这个证书之后,使用本地配置的权威机构的公钥对证书进行解密得到服务端的公钥和证书的数字签名,数字签名经过CA公钥解密得到证书信息摘要。
        1. 然后证书签名的方法计算一下当前证书的信息摘要,与收到的信息摘要作对比,如果一样,表示证书一定是服务器下发的,没有被中间人篡改过。因为中间人虽然有权威机构的公钥,能够解析证书内容并篡改,但是篡改完成之后中间人需要将证书重新加密,但是中间人没有权威机构的私钥,无法加密,强行加密只会导致客户端无法解密,如果中间人强行乱修改证书,就会导致证书内容和证书签名不匹配。
    • 缺点
      • HTTPS网络成本消耗较高
      • 服务端和客户端都需要进行额外的计算
  • 既然HTTPS很安全,那么网络抓包软件(Charles)如何抓到https请求的包的?
    • 伪造证书
    • Charles作为一个“中间人代理”,当浏览器和服务器通信时,Charles接收服务器的证书,但动态生成一张证书发送给浏览器,也就是说Charles作为中间代理在浏览器和服务器之间通信,所以通信的数据可以被Charles拦截并解密。由于Charles更改了证书,浏览器校验不通过会给出安全警告,必须安装Charles的证书后才能进行正常访问。
    • 最关键的点,Charles能伪造证书的前提是,客户端主动在自己的机器上安装证书。
  • 参考资料

最后修改于 2020-08-19

知识共享许可协议
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
- 目录 -