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

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

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

https工作原理

  1. 客户端发起HTTPS请求
    用户在浏览器里输入一个https网址,然后连接到server的443端口。
  2. 服务端的配置
    采用HTTPS协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面web通信中的SSL加密的公钥证书(受信任的第三方证书颁发机构签名颁发)常见的如
    VeriSignThawte
    GlobalSign
    Symantec
  3. 传送证书
    这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间等等。
  4. 客户端解析证书
    这部分工作是有客户端的TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警告框,提示证书存在问题。如果证书没有问题,那么就生成一个随即值。然后用证书对该随机值进行加密。
  5. 传送加密信息
    这部分传送的是用证书加密后的随机值,目的就是让服务端得到这个随机值,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
  6. 服务段解密信息
    服务端用私钥解密后,得到了客户端传过来的随机值(私钥),然后把内容通过该值进行对称加密。所谓对称加密就是,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然无法获取内容,而正好客户端和服务端都知道这个私钥,所以只要加密算法够彪悍,私钥够复杂,数据就够安全。
  7. 传输加密后的信息
    这部分信息是服务段用私钥加密后的信息,可以在客户端被还原
  8. 客户端解密信息客户端用之前生成的私钥解密服务段传过来的信息,于是获取了解密后的内容。整个过程第三方即使监听到了数据,也束手无策。

大概过程如下
握手——协商加密算法——获得公钥证书——验证公钥证书——交换会话密钥——加密信息传输

加密算法

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

对称加密
对称加密的基本思想是: 通信双方使用同一个密钥(或者是两个可以简单地互相推算的密钥)来对明文进行加密与解密.

常见的对称加密算法有DES、3DES、AES、Blowfish、IDEA、RC5、RC6.

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

非对称加密

非对称加密也叫公开密钥加密,它使用了两个密钥,一个为公钥,一个为私钥,当一个用作于加密的时候,另一个则用作解密.

这两个密钥就算被其他人知道了其中一个也不能凭借它计算出另一个密钥,所以可以公开其中一个密钥(也就是公钥),不公开的密钥为私钥.

如果服务器想发送消息给客户端,只需要用客户端的公钥加密,然后客户端用它自己的私钥进行解密.

常见的非对称加密算法有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常见攻击方式

针对其弱点,常见的https攻击方法有
降级攻击(把高安全级别的加密算法强制降成低安全级别的加密算法)
解密攻击(明文、证书伪造)
协议漏洞、实现方法的漏洞、配置不严格
HTTPS证书查看

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数据包,将其中替换成,将 Location: https://… 替换成Location:http://..,同时记录下所修改的URL,并保存;
中间人将修改后的HTTP数据发送给客户端;
客户端向服务器发起HTTP连接请求;
中间人计算机解析客户端的HTTP连接请求,并与保存文件相比较。当发现存在有已修改过的HTTP URL时,将其替换成原HTTPS URL,并发送给服务器;
与服务器保持HTTPS连接,回到步骤3;
与客户端保持HTTP连接,回到步骤4。
效果就是: 服务器认为HTTPS是安全的。对于客户端而言,由于中间人MITM与客户端Client之间是HTTP连接,因此并不会对证书进行认证;

本文链接:https://blog.blogbins.com/httpsyuan-li-yi-ji-httpszhong-jian-ren-gong-ji/

相关推荐

【新手科普】HTTPS及HTTPS中间人攻击浅析
http://www.sohu.com/a/126447128_472906

HTTPS中间人攻击及防御
HTTPS man-in-the-middle attack and defense
https://elliotsomething.github.io/2016/12/22/HTTPS中间人攻击及防御/

HTTPS原理以及HTTPS中间人攻击
https://ifunbox.top/security-https-and-MITM

打赏

Leave a Reply

Your email address will not be published. Required fields are marked *