HTTPS概述

HTTPS介绍

HTTPS是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。

HTTPS 把 HTTP 下层的传输协议由 TCP/IP 换成了 SSL/TLS，由HTTP over TCP/IP变成了HTTP over SSL/TLS，让 HTTP 运行在了安全的 SSL/TLS 协议上，收发报文不再使用 Socket API，而是调用专门的安全接口。

什么是SSL/TLS

SSL 即安全套接层（Secure Sockets Layer），在 OSI 模型中处于第 5 层（会话层），由网景公司于 1994 年发明，有 v2 和 v3 两个版本，而 v1 因为有严重的缺陷从未公开过。

SSL 发展到 v3 时已经证明了它自身是一个非常好的安全通信协议，于是互联网工程组 IETF 在 1999 年把它改名为 TLS（传输层安全，Transport Layer Security），正式标准化，版本号从 1.0 重新算起，所以 TLS1.0 实际上就是 SSLv3.1。

到今天 TLS 已经发展出了三个版本，分别是 2006 年的 1.1、2008 年的 1.2 和 2018 年的 1.3。

说到 TLS，就不能不谈到 OpenSSL，它是一个著名的开源密码学程序库和工具包，几乎支持所有公开的加密算法和协议，已经成为了事实上的标准，许多应用软件都会使用它作为底层库来实现 TLS 功能，包括常用的 Web 服务器 Apache、Nginx 等。

TLS的关键技术

对于网络传输，要保证安全，必须保证：
+ 机密性：对数据进行加密，通过密文实现
+ 完整性：指数据在传输过程中没有被窜改，服务器发的是什么，客户端接收的就是什么样的
+ 身份认证：确认对方的真实身份，否则容易被中间人攻击
+ 不可否认：也叫不可抵赖，意思是不能否认已经发生过的行为，如果缺了不可否认，那通信的事务真实性就得不到保证。

可以看到，TLS为保证安全，同时使用了对称加密、非对称加密和消息摘要。不了解的可以点击前置知识链接去看一下。

传输加密

TLS保证传输加密是使用了混合加密，它同时使用了对称加密和非对称加密。

为什么要混合加密呢？我们在谈谈对称加密、非对称加密、消息摘要以及数字签名中提到，非对称加密虽然安全，但加密解密速度较慢，效率较低，而对称加密又需要解决密钥的传输安全性问题，我们称之为 “密钥交换” 问题。于是，我们可以结合这二者，使用非对称加密解决对称加密的“密钥交换”问题。

客户端用随机数产生对称算法使用的“会话密钥”（session key），再用公钥加密。因为会话密钥很短，通常只有 16 字节或 32 字节，所以慢一点也无所谓。

服务端拿到密文之后再用私钥解密，拿到“会话密钥”，作为后续对称加密使用的密钥。

消息摘要

TLS保证消息的完整性则是使用了消息摘要，只要双方在消息后附上它的摘要，就能够保证数据的完整性。当然摘要也得使用混合加密，否则会被黑客修改。

目前 TLS 推荐使用摘要算法的是SHA-2系列（包含SHA224、SHA256、SHA384，分别能够生成 28 字节、32 字节、48 字节的摘要）。

数字签名&CA

数字签名实现了身份认证和不可否认，数字签名又使用了非对称加密和消息摘要技术。我们在谈谈对称加密、非对称加密、消息摘要以及数字签名中介绍过。数字签名就是将消息摘要后的数据再使用私钥加密。

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

当服务端向客户端返回公钥A1的时候，中间人将其替换成自己的公钥B1传送给浏览器。

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

这个时候就需要CA证书了，CA证书证明该公钥确实是来自服务端。服务端在使用HTTPS前，去经过认证的CA机构申请颁发一份数字证书，数字证书里包含有证书持有者、证书有效期、服务端的公钥、CA使用的消息摘要算法等信息，称为明文数据，CA还会将证书的明文数据进行消息摘要，并使用私钥生成数字签名，附在证书内。服务端将证书发送给客户端，客户端校验证书身份和要访问的网站身份确实一致后再进行后续的加密操作。（证书的构成：证书的明文信息+由证书的明文信息和CA的私钥生成的数字签名）

知名的 CA 全世界就那么几家，比如 DigiCert、VeriSign、Entrust、Let’s Encrypt 等，它们签发的证书分 DV、OV、EV 三种，区别在于可信程度。小一点的 CA 可以让大 CA 签名认证，但链条的最后，也就是Root CA，就只能自己证明自己了，这个就叫“自签名证书”（Self-Signed Certificate）或者“根证书”（Root Certificate）。你必须相信，否则整个证书信任链就走不下去了。

有了这个证书体系，操作系统和浏览器都内置了各大 CA 的根证书（包含CA的公钥），上网的时候只要服务器发过来它的证书，就可以验证证书里的签名，顺着证书链（Certificate Chain）一层层地验证，直到找到根证书，就能够确定证书是可信的，从而确定里面的公钥也是可信的。

CA机构颁发证书的过程：

CA机构拥有自己的一对公钥和私钥
CA机构在颁发证书时对证书明文信息进行哈希
将哈希值用私钥进行加签，得到数字签名

服务端将证书明文数据和数字签名组成证书，传递给客户端。 而客户端需要验证证书中的公钥没有被篡改：

客户端得到证书，分解成明文部分Text和数字签名Sig1
用CA机构的公钥进行解密，得到Sig2（由于CA机构是一种公信身份，因此在系统或浏览器中会内置CA机构的证书和公钥信息）
用证书里声明的哈希算法对明文Text部分进行哈希得到H
当自己计算得到的哈希值H与Sig2相等，表示证书可信，没有被篡改

然后客户端就可以信任明文数据中的服务端公钥了。

HTTP通信过程一览

用户在浏览器发起HTTPS请求（如 https://www.mogu.com/），默认使用服务端的443端口进行连接
HTTPS需要使用一套CA数字证书，证书内会附带一个公钥Pub，而与之对应的私钥Private保留在服务端不公开
服务端收到请求，返回配置好的包含公钥Pub的证书给客户端
客户端收到证书，校验合法性，主要包括是否在有效期内、证书的域名与请求的域名是否匹配，上一级证书是否有效（递归判断，直到判断到系统内置或浏览器配置好的根证书），如果不通过，则显示HTTPS警告信息，如果通过则继续
客户端生成一个用于对称加密的随机Key，并用证书内的公钥Pub进行加密，发送给服务端
服务端收到随机Key的密文，使用与公钥Pub配对的私钥Private进行解密，得到客户端真正想发送的随机Key
服务端使用客户端发送过来的随机Key对要传输的HTTP数据进行对称加密，将密文返回客户端；
客户端使用随机Key对称解密密文，得到HTTP数据明文
后续HTTPS请求使用之前交换好的随机Key进行对称加解密

其中用了两次非对称加密，这两次非对称加密是容易把人搞懵的：

第一次是客户端获取证书后，使用CA的公钥解密证书中的数字签名，然后判断证书中的服务端公钥是否可信
第二次是客户端使用服务端公钥对使用随机数生成的对称加密密钥进行加密，然后发给服务端。

原创文章，作者：彭晨涛，如若转载，请注明出处：https://www.codetool.top/article/https%e7%9a%84%e5%8e%9f%e7%90%86-%e6%b7%b7%e5%90%88%e5%8a%a0%e5%af%86%e3%80%81%e6%95%b0%e5%ad%97%e7%ad%be%e5%90%8d%e3%80%81ca/