HTTPS介绍

本文将从以下几个方面着手介绍HTTPS
1.为什么需要HTTPS（也即HTTP有哪些缺点）
2.HTTPS的原理通俗讲解
3.HTTPS的通信过程

为什么需要HTTPS

HTTP 主要有这些不足：

• 通信使用明文（不加密），内容可能会被窃听；
• 不验证通信方的身份，因此有可能遭遇伪装；
• 无法证明报文的完整性，所以有可能已遭篡改；

为了解决这些问题，HTTPS顺应而生。

什么是HTTPS

HTTP+ 加密 + 认证 + 完整性保护=HTTPS
可以这么理解，HTTPS是安全版的HTTP，它不是一个新的协议，而是HTTP 加上加密处理（解决HTTP通信使用明文的问题）和认证（解决HTTP不验证通信方的身份问题）以及完整性保护（解决HTTP无法证明报文完整性的问题）后的东西。

--引自《图解HTTP》
HTTPS是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代
替而已。通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披SSL 协议这层外壳的 HTTP。

image.png

知道了HTTPS是个什么玩意儿之后，我们肯定想知道SSL协议是怎么回事？讲SSL之前，我们需要一点铺垫。那就是加密方法，别怕，并不是要讲什么算法之类的。

近代的加密方法中加密算法是公开的，而密钥却是保密的。就比如：制造一把锁的方法是公开的，但是要想解开这把锁得有钥匙（别说可以砸，这触及到我的知识盲区了），这个钥匙就相当于密钥。你虽然知道是什么加密算法，但你没密钥就是没法还原密文。通过这种方式得以保持加密方法的安全性。现在的加密方法一般有两种：对称密钥加密和非对称密钥加密。

• 对称密钥加密：
  加密和解密同用一个密钥的方式称为共享密钥加密，如下图：

  
  
  image.png

存在的问题：如何把密钥安全的发给对方？（如果不发密钥，对方解不了密。发送就有安全风险，而且密钥如果能安全发送，那数据也可以，那还要密钥干啥？所以就很矛盾）另外还要安全的保管接受到的密钥。

• 非对称密钥加密：
  使用两把密钥，一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。如下图：

  
  
  image.png

解释一下这幅图： Alice是发送方，Bob是接收方。Alice（发送发）使用Bob（接收方）的公钥对要发送的明文数据进行加密，通过网络传输给Bob，Bob接收到密文后使用自己的私钥解密得到明文。

那有人会有疑问了？密文和公钥都在网络上传输，肯定也有被监听的风险啊。对，没错，不过根据密文和公钥想还原出明文是非常非常非常非常非常非常困难的。

tips: HTTPS采用混合加密机制
HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密相比，其处理速度要慢。所以应充分利用两者各自的优势，将多种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

当然，非对称密钥加密方式也存在一些问题，就是无法证明公开密钥就是接收方公开的那个密钥，而不是被攻击者调包的密钥。为了解决这个问题，可以使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。这货就相当于是公证处，大家都相信公证处，你说你是张三别人不一定信，它说你是张三别人才能百分百信。

数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。

多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。

HTTPS的通信过程

好了，前置知识已经讲完了。我们回到刚才说要讲的SSL协议上来，HTTPS使用SSL和TLS这两个协议进行安全通信。TLS是以SSL为原型开发的协议，有时会统一称该协议为SSL。

下面看下HTTPS的通信过程，摘自《图解HTTP》

HTTPS通信

这个图有12个步骤，别慌，我先用通俗的话讲一下流程，后面再给出具体的每一步干什么。

通俗版：
客户端向一个需要HTTPS访问的网站发起请求，服务器将证书（包含公钥）发给客户端进行校验，客户端校验成功后，会给服务器发送一个使用公钥加密后的随机串，服务器使用私钥解密这个串，从此服务器使用这个随机串进行对称加密开始和客户端进行通信，客户端拿到消息使用随机串进行解密。

专业版：
步骤 1： 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
步骤 2： 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
步骤 3： 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
步骤 4： 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。
步骤 5： SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
步骤 6： 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。
步骤 7： 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
步骤 8： 服务器同样发送 Change Cipher Spec 报文。
步骤 9： 服务器同样发送 Finished 报文。
步骤 10： 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求。
步骤 11： 应用层协议通信，即发送 HTTP 响应。
步骤 12： 最后由客户端断开连接。断开连接时，发送 close_notify 报文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP的通信。

在以上流程中，应用层发送数据时会附加一种叫做 MAC（Message Authentication Code）的报文摘要。MAC 能够查知报文是否遭到篡改，从而保护报文的完整性。

参考资料：
《图解HTTP》
https://www.cnblogs.com/piperck/p/6132467.html