前言
https
交互的的过程算是很安全的,可是稍有不慎,也会被别人利用,中间人攻击就是这样一个手段
下面先回忆下https
,然后找到问题,来理解中间人攻击
https回忆
上一篇文章讲了 https的交互图,如下所示
https在用户端执行的校验策略过程如下所示:
1、如果用户端验证验证策略为默认(AFSSLPinningModeNone
),则从受信任颁发机构且信任的 CA 列表
中去验证,可以理解服务端的单向认证过程,客户端并没有精准的认证手段(没有公钥证书原件)
也有一些中间者使用的是自制证书,即非法证书
,他们通过让用户下载证书并信任,因此从服务器下载的证书如果与其一致则会校验通过(这也是中间人攻击的手段,例如charles抓包https也会让你下载一个证书并信任)
2、可以设置为使用publicKey
去验证(AFSSLPinningModePublicKey
),公钥方式则使用本地证书中的公钥与服务器返回的证书中的公钥进行对比,进行校验,即使服务器更新证书,只要公钥不变,依然能完成校验,否则失败,为客户端和服务端的双向认证过程
3、加入本地证书文件(.cer文件
),使用本地证书校验策略(AFSSLPinningModeCertificate
),使用证书与服务端的SSL证书进行对比校验,证书完全一致则校验成功,可以继续访问,否则取消本次访问,为客户端和服务端的双向认证过程
可以看到2、3都是双向校验的过程,而只有1是单向校验,因此1也是中间人攻击的首选目标
中间人攻击
了解了https之后,再看下面的图,就很容易知道,中间人干了那些事了
下面用语言叙述下客户端、中间人、服务器那点事
1.客户端发起https请求,开始三次握手
,并发送了SSL版本、以及现生成的随机数random—c
2.中间人拦截了客户端发送的内容,自己拿着客户端的内容,发送客户端的信息给服务端,并持有random-c
3.服务端接收到了客户端发来的信息,生成随机数random-s
,与SSL证书(s)
、公钥(s)
发送给客户端(中间人)
4.由于服务端收到的是中间人的信息(ip什么的都是中间人的),中间人收到了服务端发送来的消息,又获得了random-s、SSL证书(s)、公钥(s)
等信息,中间人保存下来,将自己的SSL证书(m)、公钥(m)
,发送给客户端,以此来伪装骗取客户端信任
5.客户端收到了中间人发来的SSL证书(m)、公钥(m)
,由于本地没有持有服务端的证书信息,只能使用默认的证书对比手段,开始到信任的CA证书机构列表对比,发现了和中间人一样的证书,则验证通过(注意:此过程可能中间人的证书就是花钱买的,收到机构认证的证书,或者是用户自己下载了三方证书到本地,且信任了),此时用户已经相信中间是正人君子了(当成服务器本器了,没发现什么问题),然后开始发送自己支持的对称加密方式给服务器
6.客户端发送的信息被中间人拦截,并保存支持的对称加密方式,转交给服务器
7.服务器收到客户端传来的支持的对称加密方式列表
,开始选择最合适的对称加密方式给客户端(中间人)
8.中间人收到服务器传来的加密方式,然后保存下实际的对称加密方式,传递给客户端
9.客户端收到对称加密方式,开始生成随机数pre-master
,与random-c、random-s
共同组成对称加密秘钥(random-c + pre-master + random-s
),然后将pre-master
使用公钥(m)
加密后发送给服务器,准备发送信息
10.中间人拦截到客户端传来的加密后的pre-master
,使用私钥(m)
进行解密,然后保存下来,此时已经同时持有了random-c、pre-master、random-s、对称加密方式、公钥(s)、私钥(m)
,已经可以掌控另外两方了,因此开始使用公钥(s)将pre-master进行加密传递给服务器
11.服务器收到中间人加密后发来的pre-master
,使用私钥(s)
进行解密,获得了pre-master
,此时服务端持有random-c、pre-master、random-s
,将其作为对称加密秘钥
,开始传输信息给客户端(中间人)
12.中间人收到信息后,使用秘钥和对称加密方式进行解密,获得返回的信息,然后将数据返回给客户端,此时返回真假数据就看中间人了,如果返回真数据,只需要将解密好的数据,使用私钥(m)
加密后发送给客户端即可,也可以使用钓鱼的信息通过私钥(m)
加密后发送给客户端
13.客户端收到中间人的信息后,继续进行交互,然而什么也没发现...
14.至此中间人处理完毕,可以尽情监听或者更改双方信息了(如果对方没有进行防篡改验证算法就可以篡改信息,否则会篡改失败,中间人攻击一般用来监听真实信息)
最后
学无止境,欢迎大家一起讨论