HTTPS原理以及HTTPS中间人攻击

Aug 16, 2017 SSL
Share on:

https简介

http(Hyper Text Transfer Protocol)超文本传输协议是一种用于分布式、协作式和超媒体信息系统的应用层协议,它是TCP/IP的上层协议,同时它也是万维网(万维网不等同于互联网,它只是基于互联网的一个服务)的数据通信的基础.

http协议是客户端浏览器与其他程序或Web服务器之间交互的应用层通讯协议.但它也有一个致命的缺点:http协议是明文传输协议,在传输信息的过程中并没有进行任何加密,通信的双方也没有任何的认证,这是非常不安全的,如果在通信过程中被中间人进行劫持、监听、篡改,会造成个人隐私泄露等严重的安全问题.

https就是用于解决这样的安全问题的,它的全称为Hypertext Transfer Protocol Secure,它在http的基础上添加了SSL(安全套接字层)层来保证传输数据的安全问题.

https提供了端对端的加密,而且不仅对数据进行了加密,还对数据完整性提供了保护.不过在讲解https的加密方式之前,我们需要先了解一下加密算法.

  1. 对称加密 对称加密的基本思想是: 通信双方使用同一个密钥(或者是两个可以简单地互相推算的密钥)来对明文进行加密与解密.
常见的对称加密算法有DES、3DES、AES、Blowfish、IDEA、RC5、RC6.


对称加密看起来很美好,但是密钥要怎么发送过去呢?如果直接发送过去,被中间人截获了密钥岂不是白费工夫.</li> 

  * 非对称加密
    
    非对称加密也叫公开密钥加密,它使用了两个密钥,一个为公钥,一个为私钥,当一个用作于加密的时候,另一个则用作解密.
    
    这两个密钥就算被其他人知道了其中一个也不能凭借它计算出另一个密钥,所以可以公开其中一个密钥(也就是公钥),不公开的密钥为私钥.


    如果服务器想发送消息给客户端,只需要用客户端的公钥加密,然后客户端用它自己的私钥进行解密.
    
    常见的非对称加密算法有RSA、DSA、ECDSA、 DH、ECDHE.
    
    我们以DH算法为例,了解一下非对称加密的魅力.


对称加密与非对称加密结合使用的方法虽然能够保证了通信过程的安全,但也引发了如下问题:

  * 客户端要如何获取到服务器的公钥?
  * 如果公钥在发送过程被中间人拦截,然后中间人发送自己的公钥给客户端,客户端该如何确认?

解决方法依是通过一个权威的CA(Certificate Authority)证书中心,

* * *

## CA (Certificate Authority证书颁发机构)

它来负责颁发证书（声明这个公钥确实是服务端的）,这个证书包含了如下等内容:

  * 证书的发布机构.
  * 证书的有效期
  * 公钥
  * 证书所有人
  * 数字签名

数字签名是用来验证数据完整性的，首先将公钥与个人信息用一个Hash算法生成一个消息摘要，Hash算法是不可逆的，且只要内容发生变化，那生成的消息摘要将会截然不同。然后CA再用它的私钥对消息摘要加密，最终形成数字签名。还把原始信息和数据签名合并，形成一个全新的东西，叫做“数字证书”


当客户端接收到证书时,只需要用同样的Hash算法再次生成一个消息摘要,然后用CA的公钥对证书进行解密,之后再对比两个消息摘要就能知道数据有没有被篡改过了.


那么CA的公钥又要从哪里来呢？这似乎陷入了一个鸡生蛋,蛋生鸡的悖论，其实CA也有证书来证明自己，而且CA证书的信用体系就像一棵树的结构，上层节点是信用高的CA同时它也会对底层的CA做信用背书，操作系统／浏览器中会内置一些顶层的CA的证书，相当于你自动信任了他们。这样通过各级实体证书的验证，逐渐上溯到链的终止点，即可信任的根CA，如果到达终点在自己的信任列表内未发现可信任的CA则认为此证书不可信。


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

* * *

## Https的交互过程


  1. 浏览器对服务器发送了一次请求，包含协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。
  2. 服务器确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。
  3. 浏览器确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给服务器。
  4. 服务器使用自己的私钥，获取浏览器发来的随机数（即Premaster secret）。
  5. 服务器和浏览器根据约定的加密方法，使用前面的三个随机数，生成&#8221;对话密钥&#8221;（session key），用来加密接下来的整个对话过程。

* * *

## HTTPS中间人攻击

中间人攻击，即所谓的Man-in-the-middle attack(MITM)，顾名思义，就是攻击者插入到原本直接通信的双方，让双方以为还在直接跟对方通讯，但实际上双方的通信对方已变成了中间人，信息已经是被中间人获取或篡改。

  1. SSL证书欺骗攻击 
    此类攻击较为简单常见。首先通过ARP欺骗、DNS劫持甚至网关劫持等等，将客户端的访问重定向到攻击者的机器，让客户端机器与攻击者机器建立HTTPS连接（使用伪造证书），而攻击者机器再跟服务端连接。这样用户在客户端看到的是相同域名的网站，但浏览器会提示证书不可信，用户不点击继续浏览就能避免被劫持的。所以这是最简单的攻击方式，也是最容易识别的攻击方式。

防范措施：
钓鱼类攻击，App直接调用系统API创建的HTTPS连接（NSURLConnection）一般不会受到影响，只使用默认的系统校验，只要系统之前没有信任相关的伪造证书，校验就直接失败，不会SSL握手成功；但如果是使用WebView浏览网页，需要在UIWebView中加入较强的授权校验，禁止用户在校验失败的情况下继续访问。

      * SSL剥离攻击（SSLStrip）
        
        SSL剥离，即将HTTPS连接降级到HTTP连接。假如客户端直接访问HTTPS的URL，攻击者是没办法直接进行降级的，因为HTTPS与HTTP虽然都是TCP连接，但HTTPS在传输HTTP数据之前，需要在进行了SSL握手，并协商传输密钥用来后续的加密传输；假如客户端与攻击者进行SSL握手，而攻击者无法提供可信任的证书来让客户端验证通过进行连接，所以客户端的系统会判断为SSL握手失败，断开连接。
        
        该攻击方式主要是利用用户并不会每次都直接在浏览器上输入https://xxx.xxx.com来访问网站，或者有些网站并非全网HTTPS，而是只在需要进行敏感数据传输时才使用HTTPS的漏洞。中间人攻击者在劫持了客户端与服务端的HTTP会话后，将HTTP页面里面所有的https://超链接都换成http://，用户在点击相应的链接时，是使用HTTP协议来进行访问；这样，就算服务器对相应的URL只支持HTTPS链接，但中间人一样可以和服务建立HTTPS连接之后，将数据使用HTTP协议转发给客户端，实现会话劫持。
        
        这种攻击手段更让人难以提防，因为它使用HTTP，不会让浏览器出现HTTPS证书不可信的警告，而且用户很少会去看浏览器上的URL是https://还是http://。特别是App的WebView中，应用一般会把URL隐藏掉，用户根本无法直接查看到URL出现异常。

防范措施：
该种攻击方式同样无法劫持App内的HTTPS连接会话，因为App中传入请求的URL参数是固定带有https://的；但在WebView中打开网页同样需要注意，在非全网HTTPS的网站，建议对WebView中打开的URL做检查，检查应该使用https://的URL是否被篡改为http://；也建议服务端在配置HTTPS服务时，加上“HTTP Strict Transport Security”配置项。

    ## 防范HTTPS中间人攻击
    
      * 不要随意连入公共场合内的WiFi，或者使用未知代理服务器
      * 不要安装不可信或突然出现的描述文件，信任伪造的证书；（如某12306，在正规渠道下载系统以及浏览器）
      * App内部需对服务器证书进行单独的对比校验，确认证书不是伪造的；
        
          * 查看证书是否过期
          * 服务器证书上的域名是否和服务器的实际域名相匹配
          * 校验证书链
          * 打包证书校验
    
    ## 参考
    
    https://sylvanassun.github.io/2017/08/06/2017-08-06-DigestHttps  
    http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html
    
    <blockquote data-secret="eb58oFTjLn" class="wp-embedded-content">
      <p>
        <a href="http://www.evil0x.com/posts/26569.html">浅析HTTPS中间人攻击与证书校验</a>
      </p>
    </blockquote>
    

    http://oncenote.com/2014/10/21/Security-1-HTTPS/  
    http://oncenote.com/2015/09/16/Security-2-HTTPS2/
闽ICP备12003472号-7