浅谈关于HTTPS中间人攻击与证书校验那些事

编者注:随着安全的普及,https通信应用越发广泛,但是由于对https不熟悉导致开发人员频繁错误的使用https建站,例如最常见的是未校验https证书从而导致“中间人攻击”,并且由于修复方案也一直是个坑,导致修复这个问题时踩各种坑,故谨以此文简单的介绍相关问题。本文主要讲述网站优化https的握手过程,第二节主要讲述常见的“https中间人攻击”场景,第三节主要介绍证书校验修复方案,各位看官可根据自己口味浏览。

一、HTTPS握手过程

wKioL1jQ0TDSCF9YAAOqkzFkO04037.jpg

    首先来看下https的工作原理,上图大致介绍了https的握手流程,后续我们通过抓包看下每个握手包到底干了些什么神奇的事。

    注:本文所有内容以TLS_RSA_WITH_AES_128_CBC_SHA加密组件作为基础进行说明,其他加密组件以及TLS版本会存在一定差异,例如TLS1. 3 针对移动客户端有了很大的改动,现在的ECDHE等密钥交换算法与RSA作为密钥交换算法也完全不一样,所以有些地方和大家实际操作会存在一定出入。

1.TCP三次握手

    我访问的支付宝的官网抓取的数据。

wKiom1jQ0gqyHDw3AAIbuOpSblw910.jpg

2.Client Hello

wKiom1jQ3UHzO_kBAAFSTy1NKhE603.png

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

3.Sever Hello

wKiom1jQ1vSjB4rkAAEniwyCJJc540.png

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

4.Certificate

wKioL1jQ19LC5P1rAAFRYccKCTs243.png

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

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

wKioL1jQ2HfgI-EJAAHv9sesa5w340.jpg

   二级机构的证书。

wKioL1jQ2YWDc5YmAABPF3Cf72U600.png

二、中间人攻击

    https握手过程的证书校验环节就是为了识别证书的有效性唯一性等等,所以严格意义上来说https下不存在中间人攻击,存在中间人攻击的前提条件是没有严格的对证书进行校验,或者人为的信任伪造证书,下面一起看下几种常见的https“中间人攻击”场景。

1.证书未校验

    由于客户端没有做任何的证书校验,所以此时随意一张证书都可以进行中间人攻击,可以使用burp里的这个模块进行中间人攻击。

wKiom1jQ4r6hr1TIAAFmXIM3NGk336.jpg

    通过浏览器查看实际的https证书,是一个自签名的伪造证书。

wKioL1jQ4wLgdrFbAAHNqwQQY3k355.jpg

2.部分校验

  做了部分校验,例如在证书校验过程中只做了证书域名是否匹配的校验,可以使用burp的如下模块生成任意域名的伪造证书进行中间人攻击。

wKioL1jQ4zfAxNX2AAF0fUR50IE281.jpg

    实际生成的证书效果,如果只做了域名、证书是否过期等校验可轻松进行中间人攻击(由于chrome是做了证书校验的所以会提示证书不可信任)。

文章转自网络