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 客户端收到服务端响应后会做以下⼏件事
3.1 验证证书的合法性
颁发证书的机构是否合法与是否过期，证书中包含的⽹站地址是否与正在访问的地址⼀致等
证书验证通过后，在浏览器的地址栏会加上⼀把⼩锁(每家浏览器验证通过后的提⽰不⼀样不做讨论)
3.2 ⽣成随机密码
如果证书验证通过，或者⽤户接受了不授信的证书，此时浏览器会⽣成⼀串随机数，然后⽤证书中的公钥加密。

3.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的请求，你就算拦截到了那也是加密的数据，没有任何意义。

那有⽅法解决吗？答案是肯定的！接下来就来个实例教程，教⼤家如何查看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再转发到⽬标服务器
注意：在家中的路由器中有线与⽆线通常不在⼀个⽹段，会导致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。

另外⼀定要注意不要随便安装不确定的的根证书，以免带来不必要的损失。

写这篇⽂章时，已经进⼊我的春节假期，⽽我也已经踏上了回家的⽕车，⼤家有疑问可以在评论中回复，如有错误之处还望⼤家能指出，以免误导他⼈
提前祝⼤家新年快乐！
如果您觉得本⽂让您有所收获，不妨点下赞，为我的付出，给⼀点点回报！
如果您觉得本⼈也有点意思，不妨点个观注，⼤家⼀起谈技术，谈⼈⽣！
以下为参考资料
https原理
SSL证书
https⼯作原理
Https 原理。