[TOC]
介绍
HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer 或 Hypertext Transfer Protocol Secure，超文本传输安全协议），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。 它是一个URI scheme（抽象标识符体系），句法类同http :体系。用于安全的HTTP数据传输。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。
基础知识
非对称加密
加密使用的密钥和解密使用的密钥是不相同的，分别称为：公钥、私钥，公钥和算法都是公开的，私钥是保密的。非对称加密算法性能较低，但是安全性超强，由于其加密特性，非对称加密算法能加密的数据长度也是有限的。 例如：RSA、DSA、ECDSA、 DH、ECDHE。
既可以用公钥加密私钥解密（传输敏感信息场景），也可以用私钥加密公钥解密（用户认证场景）
例如
非对称加密利用成对的两个秘钥：K1 和 K2。小红用其中一个加密文本，小明可 以用另一个解密文本。比如，小红用 K1 加密，小明用 K2 解密：
小红 : C = E(M, K1)
小明 : M = D(C, K2)
这样一来，双方中的一方（比如小红）可以生成 K1和K2，然后把其中一个秘钥 （比如K1）私藏，称为私钥；另一个（比如K2）公开，称为公钥。另一 方（比如小明）得到公钥之后，双方就可以通信。
因为加密和解密的 秘钥值不一样, 所以是不可逆吧
RSA 算法：该算法的命名以三位科学家的姓氏缩写组合得来，在计算机网络世界，一直是最广为使用的 “非对称加密算法”。
ECC 是非对称加密里的 “后起之秀”，它基于 “椭圆曲线离散对数” 的数学难题，使用特定的曲线方程和基点生成公钥和私钥，子算法 ECDHE 用于密钥交换，ECDSA 用于数字签名。
对称加密
有流式、分组两种，加密和解密都是使用的同一个密钥。 例如：DES、AES-GCM、ChaCha20-Poly1305等。
因为加密和解密的 秘钥值是一样的, 所以也是可逆
证书
证书是用来认证公钥持有者的身份的电子文档，防止第三方进行冒充。一个证书中包含了公钥、持有者信息、证明证书内容有效的签名以及证书有效期，还有一些其他额外信息。操作系统、浏览器本身会预装一些它们信任的根证书，如果其中有该CA机构的根证书，那就可以拿到它对应的可信公钥了。
实际上证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推，我们把它叫做信任链或数字证书链，也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。
CA
CA就是签发电子证书的实体。
数字签名
数字签名技术是将摘要信息用发送者的私钥加密 (CA的私钥)，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。 数字签名是个加密的过程，数字签名验证是个解密的过程。 普通数字签名算法有RSA、ElGamal、Fiat-Shamir、Guillou- Quisquarter、Schnorr、Ong-Schnorr-Shamir数字签名算法、Des/DSA,椭圆曲线数字签名算法和有限自动机数字签名算法等。
HTTPS使用CA证书的传输方式就是使用了数字签名，非对称加密，对称加密等混合加密技术。
所以上面用私钥加密, 就是用的CA证书的私钥
CA数字签名的做法:
- 小红把自己的公钥和ID（身份证号码，或者域名）合为身份证申请（certificate signing request，CSR），小红把CSR发给一个信任的人小亮。（被称为 certificate authority，CA）
- 小亮用自己的私钥加密小红的 CSR，得到的密文被称为数字签名（digital signature）。
- 小亮把 signature 和 CSR 的明文合在一起称为 CA签署的身份证（CA signed certificate，CRT），发给小红。
每当其他人（比如小明）找小红聊天（建立HTTPS连接）的时候，小红出示自己的小亮签署的身份证。 拿到这个身份证的人，只要小明是相信小亮的——在自己机器上安装了小亮的身份证，就可以从小亮的身份证中的CSR里提取小亮的公钥；
然后用小亮的公钥解密小红的身份证中小亮的signature，得到一个小红的CSR； 如果这个CSR’和小红身份证中的CSR明文一致，则说明“这个小红的身份证是小亮确认过并且签名的”。
HTTPS的协议栈层级
SSL/TLS协议严格的说位于OSI-7层模型传输层(TCP, UDP)协议之上、应用层之下的会话层。
如上图所示 HTTPS 相比 HTTP 多了一层 SSL/TLS
SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。
TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从 3.1 开始被 IETF 标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。TLS 1.3 改动会比较大，目前还在草案阶段，目前使用最广泛的是TLS 1.1、TLS 1.2。
现在不会直接使用SSL协议了, 只是TLS的前身是SSL,且大家习惯了, 所以才会说https的协议是SSL
TLS协议是一个分层协议，本身可以分为上下两层：
- 下层为TLS记录层协议（record layer protocal)
- 上层为TLS握手层协议（handshake layer protocal)
TLS协议的组成如下：
HTTPS交互消息
说明(四次挥手)：
- 浏览器向服务器发送随机数 client_random，TLS 版本和供筛选的加密套件列表。
- 服务器接收到，立即返回 服务端随机数server_random，以及双方都支持的加密套件 以及数字证书 (证书中附带公钥 Public key certificate)。
- 浏览器接收，先验证数字证书。若通过，接着使用加密套件的密钥协商算法 RSA 算法生成另一个随机数 pre_random，并且用证书里的公钥加密，传给服务器。
- 服务器用私钥解密这个被加密后的 pre_random
现在浏览器和服务器都拥有三样相同的凭证：client_random、server_random 和 pre_random。两者都用筛好的加密套件中的加密方法混合这三个随机数，生成数据传输的密钥。
所以: HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。
HTTPS是先进行TCP三次握手，再进行TLS四次握手 , 但如果是TLS1.3版本,可以TCP和TLS握手同时进行, 因为TCP的第三次握手时已经安全,可以携带数据了 (如果是TLS1.3 只需要两次握手)
HTTPS的握手
TLS 主要的两种握手方式，分别为：RSA 握手、DH 握手。再以 DH 握手 为基础继续演进优化，推出更安全、性能更佳的 TLS1.3 版本握手方式
RSA握手 (TLS1.1/1.2)
具体流程如下：
- 浏览器向服务器发送随机数 client_random，TLS 版本和供筛选的加密套件列表。
- 服务器接收到，立即返回 server_random，确认好双方都支持的加密套件 以及数字证书 (证书中附带公钥 Public key certificate)。
- 浏览器接收，先验证数字证书。若通过，接着使用加密套件的密钥协商算法 RSA 算法生成另一个随机数 pre_random，并且用证书里的公钥加密，传给服务器。
- 服务器用私钥解密这个被加密后的 pre_random
现在浏览器和服务器都拥有三样相同的凭证：client_random、server_random 和 pre_random。两者都用筛好的加密套件中的加密方法混合这三个随机数，生成最终的密钥。最后，浏览器和服务器使用相同的密钥进行通信，即使用 对称加密。
DH 握手(TLS1.2)
具体流程如下:
- 浏览器向服务器发送随机数 client_random，TLS 版本和供筛选的加密套件列表。
- 服务器接收到后，确认好双方都支持的加密套件以及数字证书 (证书中附带公钥)。同时服务器利用私钥将 client_random，server_random，server_params 签名，生成服务器签名。然后将签名和 server_params 以及 server_random发送给客户端。 这里的 server_params 为 DH 算法所需参数。
- 浏览器接收，先验证数字证书和 签名。若通过，将 client_params 传递给服务器。这里的 client_params 为 DH 算法所需参数。
- 现在客户端和服务器都有 client_params、server_params 两个参数，因 ECDHE 计算基于 “椭圆曲线离散对数”，通过这两个 DH 参数就能计算出 pre_random。
得益于算法机制, 第三个随机数不需要通过网络传输, 安全性更高
DH 密钥交换协议
DH 密钥交换协议，Diffile-Hellman key Exchange，简称 DH 或 DHE 。它可以让双方在完全没有对方任何预先信息的条件下通过一个不安全的信道创建一个密钥。 k这个秘钥值可以通过不同的参数求证而得
其安全性是和RSA是一样的，其安全性依赖于大数因数分解，所以提高安全性只能靠增加位数来保证，这样就涉及大量的乘法运算。性能比较低下。
为了解决上述DH的问题，引入了ECC椭圆曲线，进而进化为 ECDHE 算法
TLS1.3 握手
TLS1.3 废除了原有的部分不安全的加密算法，其中甚至包括 RSA 算法。基于ECC(椭圆曲线算法)
RSA 算法的废除不仅因为已经有大能将其破解，同时还缺少 前向安全性。
流程梳理：
- 浏览器向服务器发送 client_params，client_random，TLS 版本和供筛选的加密套件列表。
- 服务器返回：server_random、server_params、TLS 版本、确定的加密套件方法以及证书。浏览器接收，先验证数字证书和签名。现在双方都有 client_params、server_params，可以根据 ECDHE 计算出 pre_random 了。
最后，集齐三个参数，生成最终秘钥。
如你所见，TLS1.3 客户端和服务器之间只需要一次往返就完成 (TLS1.2 需要两次往返来完成握手)，即 1-RTT 握手。
RTT : Round-Trip Time – 往返延时, 表示从发送端发送数据开始，到发送端收到来自接收端的确认
前向安全性: 指的是长期使用的主密钥泄漏不会导致过去的会话密钥泄漏。前向安全能够保护过去进行的通讯不受密码或密钥在未来暴露的威胁
RSA 没有向前安全性，也就是需要每次的对称加密密钥的传递都是基于 公钥加密，服务端私钥解密。如果服务端的私钥丢失了，那几年前的通信数据都有可能被解密。所以这是极度不安全的，私钥的地位太重了，如果每次的加解密都是临时生成的密码来解决安全性，才不会对私钥的安全性有如此强的依赖。
TLS过程（DH 非对称加密） - 简书 (jianshu.com)
证书链
在Chrome上随便打开一个https的网站 https://fmall.gree.com/distributionh5 ，我们会发现在地址栏的左侧有个绿色的小锁，点击这个小锁，然后就可以查看这个网站的证书信息。查看证书信息如下：
除了HTTPS使用的 gree.com 证书，向上还有两级证书，证书有3类：
- end-user ：gree.com 包含用来加密传输数据的公钥的证书，是HTTPS中使用的证书
- intermediates：CA用来认证公钥持有者身份的证书，即确认HTTPS使用的end-user证书是属于gree.com的证书。这类intermediates证书甚至可以有很多级。
- root：用来认证intermediates证书是合法证书的证书。
简单来说，end-user证书上面几级证书都是为了保证end-user证书未被篡改，保证是CA签发的合法证书，进而保证end-user证书中的公钥未被篡改。
CA组织
除了end-user之外，证书被分为root Certificates和intermediates Certificates。相应地，CA也分了两种类型：root CAs 和 intermediates CAs。首先，CA的组织结构是一个树结构，一个root CAs下面包含多个intermediates CAs，而intermediates又可以包含多个intermediates CAs。root CAs 和 intermediates CAs都可以颁发证书给用户，颁发的证书分别是root Certificates和intermediates Certificates，最终用户用来认证公钥的证书则被称为end-user Certificates。
因为证书有 root 和 intermediates两种, 所以CA组织也有两种, 而且intermediates间也可以颁发
certificates(证书)
我们使用end-user certificates来确保加密传输数据的公钥(public key)不被篡改，而又如何确保end-user certificates的合法性呢？这个认证过程跟公钥的认证过程类似，首先获取颁布end-user certificates的CA的证书，然后验证end-user certificates的signature。
就是套娃一样, 用end-user要保证数据安全, 用intermediate是来保证end-user的安全, 用root来保证intermediates的安全, 这样就形成了证书链
一般来说，root CAs不会直接颁布end-user certificates的，而是授权给多个二级CA，而二级CA又可以授权给多个三级CA，这些中间的CA就是intermediates CAs，它们才会颁布end-user certificates。
为什么需要证书链这么麻烦的流程？
Root CA为什么不直接版本证书，而是要搞那么多中间层级呢？找了一下，godaddy官方给了一个答案，为了确保root certificates的绝对安全性，https://sg.godaddy.com/en/help/what-is-an-intermediate-certificate-868 ，将根证书隔离地越严格越好。有点像设计模式中的最少知道原则
了解了这个证书体系之后，才明白为什么百度/google这种公司也需要向第三方购买签名证书了，自签root证书推广起来非常困难，这也导致目前的证书市场基本上被 Symantec(VeriSign/GeoTrust) / Comodo / GoDaddy 垄断。百度使用的是Versign，google使用的是GeoTrust。目前HTTPS的推广已经不可避免，也已经有一些公益组织开始提供免费、自动化、开放的证书签发服务，例如：Let’s Encrypt 。详细使用可以参考 入门指南 - Let’s Encrypt - 免费的SSL/TLS证书 (letsencrypt.org)
总结
Q&A
中间人攻击是什么
CA颁发证书就是解决了中间人攻击.
假设没有CA证书, 客户端和服务端直接连接交互,流程如下:
- 服务器为每个客户端生成一个公钥，将公钥发送给客户端；
- 客户端选择一个加密算法，然后用公钥加密以后发送给服务器；
- 服务器收到这个公钥加密后的算法以后拿自己的私钥解密，然后就知道这个加密算法是哪个了。今后就一直用这个算法通信；
但如果有人, 在客户端和服务端做个拦截, 所有的交互都经过中间人, 从第一步开始就冒充了服务端, 把中间人的公钥给客户端, 这样中间人就可以代替服务端与客户端交互, 或者篡改数据后转发给服务端, 这就是中间人攻击
为什么数据传输是用对称加密？
首先：非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的。
用了 HTTPS 会被抓包吗？
HTTPS 的数据是加密的，常规下抓包工具代理请求后抓到的包内容是加密状态，无法直接查看。
但是，正如前文所说，浏览器只会提示安全风险，如果用户授权仍然可以继续访问网站，完成请求。因此，只要客户端是我们自己的终端，我们授权的情况下，便可以组建中间人网络，而抓包工具便是作为中间人的代理。通常 HTTPS 抓包工具的使用方法是会生成一个证书，用户需要手动把证书安装到客户端中，然后终端发起的所有请求通过该证书完成与抓包工具的交互，然后抓包工具再转发请求到服务器，最后把服务器返回的结果在控制台输出后再返回给终端，从而完成整个请求的闭环。
既然 HTTPS 不能防抓包，那 HTTPS 有什么意义？
HTTPS 可以防止用户在不知情的情况下通信链路被监听，对于主动授信的抓包操作是不提供防护的，因为这个场景用户是已经对风险知情。要防止被抓包，需要采用应用级的安全防护，例如采用私有的对称加密，同时做好移动端的防反编译加固，防止本地算法被破解。
HTTPS必须在每次请求中都要先在SSL/TLS层进行握手传输密钥吗？
这也是我当时的困惑之一，显然每次请求都经历一次密钥传输过程非常耗时，那怎么达到只传输一次呢？靠“session”。
服务器会为每个浏览器（或客户端软件）维护一个session ID，在TSL握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了！
HTTPS协议原理和流程分析 - 腾讯云开发者社区-腾讯云 (tencent.com)
你知道，HTTPS用的是对称加密还是非对称加密？ - 知乎 (zhihu.com)
HTTPS用的是对称加密还是非对称加密？ - Rogn - 博客园 (cnblogs.com)
数字签名是什么？ - 阮一峰的网络日志 (ruanyifeng.com)
证书链-Digital Certificates - 简书 (jianshu.com)
Java调用https服务报错unable to find valid certification path to requested target的解决方法_wolf的技术博客_51CTO博客
HTTPS加密（握手）过程 - 简书 (jianshu.com)
给面试官上一课：HTTPS是先进行TCP三次握手，再进行TLS四次握手 - 知乎 (zhihu.com)