HTTPS原理解析

HTTPS原理解析

一、前言

在说HTTPS之前先说说什么是HTTP，HTTP就是我们平时浏览网页时使用的一种协议。HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息是非常不安全。为了保证这些隐私数据能够加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。SSL目前的版本是3.0，被IETF（Internet Engineering Task Force）定义在RFC 6101。之后IETF对SSL 3.0进行了升级，于是出现了TLS（Transport Layer Security） 1.0，定义在RFC 2246。实际上我们现在的HTTPS都是用的TLS协议，但是由于SSL出现的时间比较早，并且依旧被现在浏览器所支持，因此SSL依然是HTTPS的代名词，但无论是TLS还是SSL都是上个世纪的事情，SSL最后一个版本是3.0，今后TLS将会继承SSL优良血统继续为我们进行加密服务。目前TLS版本是1.2，定义在RFC 5246中，暂时还没有被广泛的使用。

二、HTTPS验证原理

HTTPS在真正请求数据前，先会与服务有几次握手验证，以证明相互的身份，如下图：

2.1验证流程

注：文中所写的序号与图不对应但流程是对应的

1. 客户端发起一个https请求，把自身支持的一系列Cipher Suite（密钥算法套件，简称Cipher）发送给服务端。
2. 服务端，接收到客户端所有的Cipher后与自身支持的对比，如果不支持则断开连接，反之则会从中选出一种加密算法和HASH算法。以证书的形式返回给客户端，证书中还包含了公钥、颁发机构、网址、失效日期等等。
3. 客户端收到服务端响应后会做以下几件事
   • 验证证书的合法性
     颁发证书的机构是否合法与是否过期，证书中包含的网址地址是否与正在访问的地址一致等。
     证书验证通过后，在浏览器的地址栏会加上一把小锁（每家浏览器验证通过后的提示不一样 不做谈论）
   • 生成随机密码
     如果证书验证通过，或者用户接受了不受信的证书，此时浏览器会生成一串随机数，然后用证书公钥加密
   • HASH握手信息
     用最开始约定好的HASH方式，把握手信息取HASH值，然后用随机数加密“握手消息+握手消息HASH值（签名）”并一起发送给服务端
     在这里之所以要取握手消息的HASH值，主要是把握手消息做一个签名，用于验证握手消息在传输过程中有没有被篡改过。
4. 服务器拿到客户端传来的密文，用自己的私钥来解密握手消息取出随机数密码，再用随机数密码解密握手消息和HASH值，并与传过来的HASH值做对比确认是否一致。
   然后用随机数密码加密一段握手消息（握手消息+握手消息的HASH值）给客户端。
5. 客户端用随机数解密并计算握手消息的HASH，如果与服务器发来的HASH一致，此时握手过程结束，以后所有的通信数据将由浏览器生成的随机数密码并利用对称加密算法进行加密。
   因为这串密钥只有客户端和服务器知道，所以即使中间请求被拦截也是没有办法解密数据的，以此保证了通信的安全。

非对称加密算法：RSA，DSA/DSS 在客户端和服务端相互验证的过程中用的是对称加密。
对称加密算法：AES，RC4，3DES 客户端与服务器相互验证通过后，以随机数作为密钥时，就是对称加密。
HASH算法：MD5，SHA1,SHA256 在确认握手消息没有被篡改过时

2.2 客户端如何进行验证证书的合法性？

1.验证证书是否在有效期内
在服务端返回的证书中包含证书的有效期，可以通过失效日期来验证证书是否过期。
2.验证证书是否被吊销了。
被吊销后的证书是无效的。验证吊销有CRL（证书吊销列表）和OCSP（在线证书检查）两种方法。
证书被吊销后会被记录在CRL中，CA会定期发布CRL。应用程序可以依靠CRL来检查证书是否被吊销了。
CRL有两个缺点，一是有可能会很大，下载很麻烦。针对这种情况有增量CRL这种方案。二是有滞后性，就算证书被吊销了，应用也只能等到发布更新的CRL后才能知道。
增量CRL也能解决一部分问题，但没有彻底解决。OCSP是在线证书检查协议。应用按照标准发送一个请求，对某张证书进行查询，之后服务器返回证书状态。
OCSP可以认为是即时的（实际实现中可能会有一定的延迟），所以没有CRL的缺点。
3.验证证书是否是上级CA签发的。
windows中保留了所有受信任的根证书，浏览器可以查看信任根证书，自然可以验证web服务器的证书。
是不是由这些受信任根证书颁发的或者受信任根证书的二级证书机构颁发的（根证书机构可能会授权给底下的中级证书机构，然后由中级证书机构颁发中级证书）
在验证证书的时候，浏览器会调用系统的证书管理器接口对证书路径中的所有证书一级一级的进行验证，只有路径中所有的证书都是受信的，整个验证的结果才是受信的。

三、手机如何抓取HTTPS的请求数据

当站点由HTTP转成HTTPS后是更安全了，但是有时候要看线上的请求数据解决问题时却麻烦了，因为HTTPS的请求，你就算拦截到了那也是加密的数据，没有任何意义。
首先需要安装FIddler用于拦截请求，和颁发Https证书

3.1 Fiddler根证书导出

按图中操作导出，再将导出的根证书“FiddlerRoot.cer”的后缀名改为“crt” “FiddlerRoot.crt”因为手机没法直接安装cer格式的证书

3.2 证书安装

在本机把证书移到本机IIS中的某个网站的物理目录中，然后在手机浏览器中访问该证书的目录。如：“192.168.0.102:8001/FiddlerRoot.crt”
如图：

此时手机会提示安装根证书，其实安装一个不受信的根证书是非常危险的，如果你安装了某些钓鱼网站或者有危害的根证书，那只要是该根证书下的所有证书都会验证通过，那随便一个钓鱼网站只要安装了该根证书下的证书，都不会有任何警告提示。
很可能让用户有财产损失。所以在安装根证书时，手机系统会要求你输入锁屏密码，以确保是本人操作。
安装过程如下
Fiddler的根证书名字都提示了是不受信的根证书
安装完成

3.3 通过Fiddler抓取手机的HTTPS请求

Fiddler默认侦听的端口是8888，把手机WIFI的HTTP代理设为本机Fiddler的地址如下图。这样手机上所有的请求都会先通过Fiddler，Fiddler再转发到目标服务器

代理也设置好以后便可以开始抓到HTTPS的请求内容了，如图。
Https默认的端口号是443。可以看出红框中的是未装根证书前的请求，加了一把小锁，而且请求记录都是灰色的，而安装证书后请求则一切正常，请求内容也都可以正常看到。

3.4 为什么安装了Fiddler根证书可以看到Https请求内容

要解释这个问题，就需要了解最开始的Https的验证原理了，回顾以下，显示客户端把自己支持的加密方式提交到服务端，然后服务端会返回一个证书。
到这一步问题来了，手机为什么要安装Fiddler的证书的？
第一，因为Fiddler在客户端（手机）发出Https请求时，充当了服务器的角色，需要返回一个证书给客户端，但是Fiddler的证书并不是CA机构颁发的，客户端一验证就知道是假的连接，肯定就断了，那怎么办呢？
那就想办法让客户端信任这个服务端，于是就在客户端安装一个Fiddler的根证书。所以只要是通过Fiddler的Https请求，验证根证书时自然会通过，因为Fiddler的根证书你已经受信了！
第二，现在只是客户端（手机）和Fiddler这个伪服务端的Https验证通过了，还没有真正的服务端去取数据的，此时Fiddler会以客户端的身份与真正服务端再进行一次HTTPS的验证，最后拿到数据后又以服务端的身份与客户端（手机）通信。也就是说在一次请求中数据被两次加解密，一次时手机到Fiddler，另一次是Fiddler到真正的服务端。
整个过程，手机——>Fiddler——>服务器。Fiddler既充当了服务端有充当了客户端，才使得数据能够正常的交互，这个过程中最重要的一环就是手机端安装的根证书！

四、总结

写了这么多，其实也只是把Https的基本流程写清楚了一部分，这其中每一个步骤深入下去都是一本学科，而对于我们而言，能清楚其大致运作流程，做到心中有数据就算可以了。
Https在目前的网络数据安全传输占据着重要地位，目前可能也没有更优的方案来代替Https。另外一定要注意，不要随便安装不确定的根证书，以免带来不必要的损失。