HTTPS中间人攻击及防御

HTTPS也不是绝对安全的，在HTTPS握手的过程中，如果实施不当，还是会存在漏洞，很容被中间人攻击；

什么是中间人攻击：

中间人攻击（Man-in-the-middle attack，缩写：MITM）是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容，达到HTTPS攻击的目的。维基百科：

如何进行中间人攻击的呢？

攻击一：SSLSniff

攻击者在网关截获SSL会话，替换服务器公钥证书，将公钥PKey换成自己的公钥PKey，欺骗客户端。客户端使用PKey加密信息并发送会话，中间人用私钥Skey解密客户端返回会话，从而劫持会话。同时，中间人用PKey加密明文会话并返回服务器

过程如下：

Attacker截获了客户端的say hello，可以把publicKey_attacker返回给客户端，取得客户端的信任，至此Attacker与客户端建立了安全连接。
Attacker冒充客户端向服务器发送say hello，至此Attacker与服务器建立了安全连接。

这种攻击会存在一个问题会被感知到，就是Attacker的证书是伪造的不受信任的证书，所以客户端可以确认是否需要真的连接该服务器，不过如果有内鬼的话，伪造的受信任的证书的话，就当我啥也没说；

攻击二：SSLStrip

这种攻击相对于攻击一复杂一点，但是也更加厉害，几乎可以在客户端无感知的情况下实施攻击，并且不需要伪造证书；简单来说就是这样：Attacker在客户端与服务器建立连接时，在Attacker与服务器之间形成HTTPS连接，而在客户端与Attacker之间形成HTTP连接，即将SSL层从原HTTPS连接中“剥离”。这样，既避免了在客户端验证证书时难以避免的弹框问题，又能够劫持HTTP明文数据，并同时保证客户端HTTP数据的传输，达到欺骗服务器与客户端的效果。

过程如下：

用户在浏览器地址栏中输入网址时，多数会采用直接输入网址的方式，而忽略了传输所采用的协议。例如，在登录gmail过程中，大多数用户会直接在地址栏中输入www.gmail.com，向Google服务器发送一个HTTP连接请求，而不是输入https：//www.gmail.com，向服务器发送一个HTTPS连接请求。因此，用户通常接触到HTTPS的方式有两种：一种是 Web上的连接，比如当用户在gmail上输入用户名和密码后，点击的登录键，将用户的用户名和密码以HTTPS的形式POST到服务器。另一种是通过HTTP的302状态。当客户端向gmail提出HTTP连接请求时，gmail服务器会返回一个REDIRECT网址，https：//www.google.com/accounts/ServiceLogin?service=mail...，用户端在接收到这个URL后，将页面重定位到该网页，并请求HTTPS连接。从另外一个角度讲，用户通常是通过HTTP向服务器发起HTTPS连接的。而HTTP本身是以明文的形式对外传送，并不能保证数据的安全。因此，可以考虑通过对HTTP进行劫持，来实现对HTTPS劫持的目的。

客户端向服务器发起HTTP连接请求；
中间人MITM监听客户端与服务器的HTTP数据；
服务器返回给客户端的HTTP数据包被在客户端与服务器之间的中间人截获。中间人解析原HTTP数据包，将其中<a href=”https：//...”>替换成<a href=”http//...”>，将 Location： https：//... 替换成Location：http://..，同时记录下所修改的URL，并保存；
中间人将修改后的HTTP数据发送给客户端；
客户端向服务器发起HTTP连接请求；
中间人计算机解析客户端的HTTP连接请求，并与保存文件相比较。当发现存在有已修改过的HTTP URL时，将其替换成原HTTPS URL，并发送给服务器；
与服务器保持HTTPS连接，回到步骤3；
与客户端保持HTTP连接，回到步骤4。

效果就是： 服务器认为HTTPS是安全的。对于客户端而言，由于中间人MITM与客户端Client之间是HTTP连接，因此并不会对证书进行认证；

当然还有别的攻击方式，这里只着重介绍这两种

如何防御中间人攻击？

中间人攻击是一个（缺乏）相互认证的攻击；由于客户端与服务器之间在SSL握手的过程中缺乏相互认证而造成的漏洞

防御中间人攻击的方案通常基于一下几种技术

公钥基础建设PKI

使用PKI相互认证机制，客户端验证服务器，服务器验证客户端；上述两个例子中都是只验证服务器，这样就造成了SSL握手环节的漏洞，而如果使用相互认证的的话，基本可以

更强力的相互认证
延迟测试

使用复杂加密哈希函数进行计算以造成数十秒的延迟；如果双方通常情况下都要花费20秒来计算，并且整个通讯花费了60秒计算才到达对方，这就能表明存在第三方中间人。

使用其他形式的密钥交换形式

未完待续。。。

HTTPS中间人攻击及防御

HTTPS man-in-the-middle attack and defense