透析HTTPS

前提

近年来,各大公司都在大力推进HTTPS的建设,Google Chorm将非HTTPS的网站例为”不安全“,苹果要求APP中使用HTTPS进行传输通信,微信小程序也要求使用HTTPS协议

ok,那为什么非要做一件事

我们先来看看HTTP

HTTP(Hypertext Transfer Protocol)超文本传输协议,是一种用于分布式,协作式,超媒体信息系统的应用传输协议,可以说HTTP是当代互联网传输的基础

说说为什么会明令禁止

HTTP有一个致命的缺陷,也就是内容是 明文传输 的,没有经过任何的加密,而这些明文经常会通过一些 wifi 路由器 运营商的一系列物理设备节点;

如果在这些节点上被进行监听,传输的内容将会完全暴露

这一攻击手法叫做MITM(Man In The Middle)中间人攻击

转载于敖丙,up主对于安全特别的痴迷,康康他举的例子

可以拿小时候上课传纸条来类比，你坐在教室靠墙的一边，想要传一句「晚上放学操场我等你」给坐在窗边的小红，中间要经过六七个人的传递。虽然你把纸条对折了一下，但是防君子不防小人，中间的所有人都可以很轻易地打开纸条看到你想要说什么。

只是看还好，如果有小刚也喜欢小红，看到你俩马上就要甜甜蜜蜜地回家了，心有不甘，换了一张纸条，改成了「晚上放学你自己回家吧，我要去网吧玩游戏」。

小红看到你要抛弃她自己去玩游戏，非常伤心，开始在纸条上质问「说好的一起回家呢，为什么要去打游戏，哼」。

在小红的纸条传回来的路上，小刚又改了纸条「你玩你的游戏去吧，我要和小刚回家」。

于是，你和小红都倍感伤心，小刚横刀夺爱，而你一头雾水。

哈哈哈,对于这样的横刀夺爱,就是不安全的!!!

回忆几年前的遍地的运营商劫持,当你访问一个本来就很正常的一个网站的时候,但是也页面上却会出现一些莫名其妙的东西,广告啊,跳转,欺骗性的红包啊等,更过分的就是本来你要下载的东西,不知不觉的下载成了其他的东西,这就是被运行商截取HTTP明文的现象

还有各大公司中的[不要连接陌生wifi],也有类似的原因,进行截取明文的例子

so

为了解决HTTP使用明文传输数据不安全的现象,1994年网景公司提出了HTTPS(HyperText Transfer Protocol Secure)超文本传输协议,数据通信仍是HTTP,但是利用了SSL/TLS加密数据包

我这人喜欢”刨祖坟”也就是追究实现原理

HTTPS实现原理

• SSL(Secure Sockets Layer)安全套接层和TLS(Transport Layer Security)传输层安全协议其实是一套东西。

• 工作流程

• 看看HTTPS加解密的流程

  • 
  1. 用户在浏览器发送HTTPS请求(如：https://www.mogu.com/)，默认使用浏览器的443端口进行连接
  2. HTTPS需要使用一套CA数据证书，证书内会附带一个公钥Pub，同时与之对应的私钥Private留在服务器不公开
  3. 服务端收到请求后，返回配置好的包含公钥Pub的证书给客户端
  4. 客户端收到用户返回的证书后，检验合法性，主要是包括是否在有效期内，证书的域名与请求的域名是否匹配，上一级的证书是否有效(递归判断，直到判断到系统内置或浏览器配置好的根证书)，如果不匹配返回HTTPS警告，匹配成功进行下一步
  5. 客户端生成一个用于对称加密的随机Key，并用证书内的公钥Pub进行加密，发送到服务端
  6. 服务端收到随机生成的密钥。使用与公钥配对的密钥进行解密，得到客户端真正想要的随机Key
  7. 服务端使用客户端发送的随机Key对密文进行加密，将密文返回给客户端
  8. 客户端使用随机Key对称解密密文，得到HTTP数据明文
  9. 后续HTTPS请求使用之前交换好的随机Key进行对称加解密

对称加密和非对称加密

1. 对称加密

   1. 对称加密指的是一个密钥。用它可以对一段明文加密，加密之后也就只能用这个密钥进行解密拿到密文，如果双方都持有密钥，且天知地知你知我知，绝对不会有别人知道，那么通信安全自然是可以保证的，但是前提是你的密钥足够强
   • 但是呢，在HTTPS的传输情境下，我们服务端实现不是到客户端是谁，你也不可能在事先不通过互联网去和一个网站的管理员都悄悄的商量哈这个密钥，同时这密钥在互联网传输的过程中，如果被别人监听到，那么我们后续的加密都是无用功

2. 非对称加密

   1. 介绍
      1. 非对称加密有两个密钥，一个是公钥Pub，一个是密钥Private，一般公钥是用来加密的，这个时候传输过来的密文只能通过密钥来进行解密
   2. ok
      1. 我们客户端发起服务请求，之后服务端将公钥发送过去，客户端利用公钥加密好密文，发送到服务端，之后服务端用自己的密钥进行解密
      2. 但是呢，我们服务端要向客户端发送消息，如果要用自己的公钥进行加密发送后，客户端是没有私钥进行解密查看的，如果用私钥进行加密，那客户端可以拿之前的传输过来的公钥进行解密查看，但是之前的公钥就在互联网上进行传输过来，很可能已经有人拿到了，这个非对称也是不能满足的

   注意，严格来讲，私钥并不能用来加密，只能用作签名使用，这是由于密码学中生成公钥私钥时对不同变量的数学要求是不同的，因此公钥私钥抵抗攻击的能力也不同，在实际使用中不可互换。签名的功能在HTTPS里也有用到，下文中会说明。

   • 只有一组公钥私钥只能去保证单程的加解密，那如果我们准备两组公钥私钥呢，是不是就可以解决这个问题
     1. 服务端由非对称的公钥A1，私钥A2；
     2. 客户端由非对称的公钥B1，私钥B2；
     3. 客户端由服务端发起请求，服务端将公钥A1返回给客户端
     4. 浏览器收到公钥A1,将自己保存的公钥B1发送给服务端
     5. 之后浏览器所有向客户端发送的数据，使用公钥B1进行加密客户端可以使用B2进行解密；
     6. 客户端所有向服务端发送的数据，使用公钥A1进行加密，服务端可以使用私钥A2进行解密

ok,此时传输方向的数据都是经过非对称加密，都能保证安全性，那么为什么不采用这种方案呢？

ちょっと待って

最主要的原因是非对称加密耗时要远大于对称加解密，对性能有很大损耗，大家的使用体验很差

so

我们才会最终选用了上文介绍的非对称加密+对称加密的方案，再反过来看一下

1. 服务端有非对称的加密的公钥A1，私钥A2
2. 当客户端发送请求后，我们的服务端将公钥A1返回到客户端
3. 客户端随机生成一个对称加密的密钥K，用公钥A1进行加密发送到服务端
4. 服务端使用A2进行对应的解密，拿到客户端的密钥K，此时就完成了安全的对称密钥交换，解决了对称加密时密钥传输被人窃取的问题
5. 之后双方都可以使用密钥K进行对称加解密

现在看起来是一个完美的方案，但是呢安全吗？？？

CA颁发机构

依然考虑中间人攻击的情况，非对称加密的算法都是公开的，所有人都可以自己生成一对公钥私钥

当服务端向客户端返回公钥A1的同时，中间人可以替换成自己的B1公钥给浏览器

而浏览器此时一无所知，傻乎乎的使用公钥B1加密了密钥发送出去，又被中间人截获，中间人利用自己的私钥B2解密，得到密钥K，在使用服务端的公钥A1进行加密传送给服务端，完成通信链路，而服务端和客户端毫无感知

出现这一问题的核心原因也就是客户端无法确认收到的公钥是不是服务端发来的，为了解决这一问题，也就是引入了一个公信机构，也就是我们CA机构

服务端在使用HTTPS之前，要去经过认证的CA机构去颁发一份数字证书，里面包括了证书持有者，证书有效期，公钥等信息，服务端将证书发送给客户端，客户端进行校验证书身份和要访问的网站身份确实一致后再进行后续的加密操作n

但是呢，如果中间人再聪明一点，之改动了证书的公钥部分，客户端也不能使用证书信息来进行对公钥的正确认证，所以就要采取一些防伪技术

前文提过，在非对称加密中，我们的私钥是用来解密的，公钥是用来加密的，那私钥干的活只有解密吗

其实对于私钥的用处还有数字签名，其实这就是一种防伪技术，只要有人篡改了证书，那么数字签名必然校验失败。具体过程如下

1. CA机构拥有自己的一对公钥和私钥
2. CA在颁发证书时对证书铭文信息进行了哈希
3. 哈希后又利用私钥进行加签

明文数据和数字签名传递给客户端

1. 客户端得到证书，分解成明文部分Text和数字签名Sig1
2. 用CA证书中的公钥进行解签,得到Sig2(由于CA是公信身份，所以会在系统或浏览器中内置CA机构的公钥和证书)
3. 再使用证书中的hash算法对明文部分Text进行哈希后得到H
4. 之后通过计算得到的哈希值T与解签后的Sig2相等的话，表示证书可信，没有被篡改

说实话这里有一点难理解

非对称加密的签名过程是

1. 私钥将一段进行加签，之后将我们的签名部分和消息本身一起发送给对方
2. 收到消息后对签名部分利用公钥验签，如果验签出来的内容和消息本身一致，表明消息没有被篡改

在这个过程中，系统或浏览器中内置的CA机构的证书和公钥成为了至关重要的环节，这也是CA机构公信身份的证明，如果系统或浏览器中没有这个CA机构，那么客户端可以不接受服务端传回的证书，显示HTTPS警告

实际上CA机构的证书是一条信任链，A信任B，B信任C

总结

HTTPS的出发点就是解决HTTP传输信息时被篡改和监听的问题

1. 为了兼容性能和安全，之后加入了对称加密和非对称加密的方案
2. 为了保证公钥在传输的过程中不被篡改，又使用了非对称加密的数字签名功能，借助CA机构和系统根证书的机制，保证了HTTPS证书的公信力

ok，本文参考自敖丙的HTTPS透析

最近呐，经历了好多事情，改变了我好多，让我更加的有信心的迈向大厂的信心!!!