HTTPS 原理分析
随着
https建站成本的降低（颁发ca证书的权威机构可以颁发免费、低价格的证书），使用https协议的网站用的越来越多。大家都知道使用Https`协议的网站更安全，像ssl应用层，对称加密和非对称加密，证书验证等等，那么问题来了，使用https协议一定就是安全的吗？
带着这个问题，我们来深入探究下https的原理和如何保证安全性的。
https原理
先po一张图，了解下Https在http的基础上做了哪些事？https协议本身并不是一种新的协议，在HTTP跟TCP中间加多了一层加密层TLS/SSL。通常HTTP直接和TCP通信，而HTTPS要先将数据给到TLS/SSL，数据经加密后，再给到 TCP进行传输。
大家可能都听说过 HTTPS 协议之所以是安全的是因为 HTTPS 协议会对传输的数据进行加密，而加密过程是使用了非对称加密实现。但其实，HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。
上面这张图是https通过TSL/SSL加密跟服务器建立tpl连接的过程。简单来说，https建立连接过程主要分为证书验证和数据传输两个过程；
1.证书验证
a. 浏览器发起 HTTPS 请求
b. 服务端返回 HTTPS 证书
c. 客户端验证证书是否合法，如果不合法则提示告警
2.数据传输
a. 当证书验证合法后，在本地生成随机数
b. 通过公钥加密随机数，并把加密后的随机数传输到服务端
c. 服务端通过私钥对随机数进行解密
d. 服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输
e. 客户端通过存在本地的随机数使用公钥对数据进行解密
具体的握手过程具体如下：
- 客户端发送 Client Hello 报文开始SSL通信。请求中包含：客户端支持的SSL版本、加密组件列表（所使用的加密算法和秘钥长度等）。
- 服务端接收到请求后，以 Server Hello应答。应答报文中包含：从客户端提供的支持的SSL版本和加密组件中筛选出的SSL版本和加密组件。
- 之后服务端发送Certificate报文，报文中包含公开秘钥证书。
- 最后服务发送Server Hello Done报文，通知客户端最初阶段的SSL握手协商部分结束。
- 客户端会校验证书通过，创建随机数，并使用证书中提供的公钥对随机数（Pre-master secret）进行加密，并将加密后的随机数通过报文Client Key Exchange报文发送给服务端。
- 接着客户端继续发送Change Cipher Spec报文，告知服务器之后的通信会采用Pre-master secret秘钥进行加密。
- 客户端发送通过秘钥加密的Finish报文。表示握手阶段的客户端部分已经完成。
- 服务端通过客户端传入的随机数构造对称加密算法，同样发送Change Cipher Spec报文，告知客户端之后的通信会使用随机数秘钥进行加密。
- 服务端同样发送Finish报文。
- 客户端和服务器的Finish报文交换完毕后，SSL连接到此建立完成，之后就发起http协议了。
那么问题来了：
Q 1: 为什么数据传输是用对称加密？
首先，非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的；
其次，在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密。
Q 2: 为什么需要 CA 认证机构颁发证书？
HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器，而 HTTPS 协议主要解决的便是网络传输的安全性问题。
首先我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的“中间人攻击”问题；那么什么是中间人攻击呢？
中间人攻击的过程：
- 本地请求被劫持（如DNS劫持等），所有请求均发送到中间人的服务器
- 中间人服务器返回中间人自己的证书（
重点：请看 Q 3） - 客户端创建随机数，通过中间人证书的公钥对随机数加密后传送给中间人，然后凭随机数构造对称加密对传输内容进行加密传输
- 中间人因为拥有客户端的随机数，可以通过对称加密算法进行内容解密
- 中间人以客户端的请求内容再向正规网站发起请求
- 因为中间人与服务器的通信过程是合法的，正规网站通过建立的安全通道返回加密后的数据
- 中间人凭借与正规网站建立的对称加密算法对内容进行解密
- 中间人通过与客户端建立的对称加密算法对正规内容返回的数据进行加密传输
- 客户端通过与中间人建立的对称加密算法对返回结果数据进行解密
中间人攻击，我们假设如果不存在认证机构，则人人都可以制造证书，这就带来了"中间人攻击"问题。简单来说：中间人攻击中，中间人首先伪装成服务端和客户端通信，然后又伪装成客户端和服务端进行通信，这就是为什么我们需要向权威机构申请证书。。。
Q 3: 浏览器是如何确保 CA证书的合法性？
.a:证书包含什么信息？
- 颁发机构信息
- 域名
- 公司信息
- 公钥
- 有效期
- 指纹
- .等等…
b: 证书的合法性依据是什么？
首先，权威机构是要有认证的，不是随便一个机构都有资格颁发证书，不然也不叫做权威机构。另外，证书的可信性基于信任制，权威机构需要对其颁发的证书进行信用背书，只要是权威机构生成的证书，我们就认为是合法的。
所以权威机构会对申请者的信息进行审核，不同等级的权威机构对审核的要求也不一样，于是证书也分为免费的、便宜的和贵的。
c: 浏览器如何验证证书的合法性？
浏览器发起 HTTPS 请求时，服务器会返回网站的 SSL 证书，浏览器需要对证书做以下验证：
- 验证域名、有效期等信息是否正确。证书上都有包含这些信息，比较容易完成验证；
- 判断证书来源是否合法。每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证；
- 判断证书是否被篡改。需要与 CA 服务器进行校验；
- 判断证书是否已吊销。通过CRL（Certificate Revocation List 证书注销列表）和 OCSP（Online Certificate Status Protocol 在线证书状态协议）实现，其中 OCSP 可用于第3步中以减少与 CA 服务器的交互，提高验证效率
以上任意一步都满足的情况下浏览器才认为证书是合法的。
既然证书是公开的，如果要发起中间人攻击，我在官网上下载一份证书作为我的服务器证书，那客户端肯定会认同这个证书是合法的，如何避免这种
证书冒用的情况？
其实这就是非加密对称中公私钥的用处，虽然中间人可以得到证书，但私钥是无法获取的，一份公钥是不可能推算出其对应的私钥，中间人即使拿到证书也无法伪装成合法服务端，因为无法对客户端传入的加密数据进行解密。
Q 4: 只有认证机构可以生成证书吗？
如果需要浏览器不提示安全风险，那只能使用认证机构签发的证书。但浏览器通常只是提示安全风险，并不限制网站不能访问，所以从技术上谁都可以生成证书，只要有证书就可以完成网站的 HTTPS 传输。例如早期的 12306 采用的便是手动安装私有证书的形式实现 HTTPS 访问。
插一句：这就是自己造证书自己用，何必花那钱申请证书。