https
# https
HTTPS （英文：HyperText Transfer Protocol Secure）超文本传输安全协议
HTTPS = HTTP + SSL/TLS
详解：https://segmentfault.com/a/1190000011675421 (opens new window)
明文、密文、密码、密钥、对称加密、非对称加密、摘要、数字签名、数字证书
# HTTPS 建立连接过程
- 客户端发起 https 连接到服务器端
浏览器去到 DNS 服务器获取此 url 对应的 ip，然后客户端连接上服务端的 443 端口，将此请求发送给到服务端，此时客户端同时将自己支持的加密算法带给服务端；
- 服务器端发送证书给客户端
服务器发送一个 SSL 证书给客户端
证书中包括了数字证书包含的内容：1、证书颁发机构；2、使用机构；3、公钥；4、有效期；5、签名算法；6、指纹算法；7、指纹。
- 客户端验证服务端发来的证书（通过浏览器内置的厂商根证书等手段校验）
（1）验证证书：客户端验证收到的证书，包括发布机构是否合法、过期，证书中包含的网址是否与当前访问网址一致等等。
（2）生成随机数：（此随机数就是后面用的对称加密的密钥）
（3）生成握手信息：用证书中的签名 hash 算法取握手信息的 hash 值，然后用生成的随机数将握手信息和握手信息的 hash 值进行加密，然后用公钥将随机数进行加密后，一起发送给服务端。其中计算握手信息的 hash 值，目的是为了保证传回到服务端的握手信息没有被篡改。
- 服务端接收随机数加密的信息，并解密得到随机数，验证握手信息是否被篡改。
服务端收到客户端传回来的用随机数加密的信息后，先用私钥解密随机数，然后用解密得到的随机数解密握手信息，获取握手信息和握手信息的 hash 值，计算自己发送的握手信息的 hash 值，与客户端传回来的进行对比验证。
如果验证无误，同样使用随机字符串加密握手信息和握手信息 hash 值发回给到客户端
- 客户端验证服务端发送回来的握手信息，完成握手
客户端收到服务端发送过来的握手信息后，用开始自己生成的随机数进行解密，验证被随机数加密的握手信息和握手信息 hash 值。验证无误后，握手过程就完成了
- 随后客户端和服务端就使用对称密钥进行信息传输
参考：https://blog.csdn.net/qq_24601199/article/details/104362401 (opens new window)
# 握手次数
当客户端想要通过 HTTPS 请求访问服务端时，整个过程需要经过 7 次握手并消耗 9 倍的延迟。
TCP 协议 — 通信双方通过三次握手建立 TCP 连接
TLS 协议 — 通信双方通过四次握手建立 TLS 连接
参考：https://draveness.me/whys-the-design-https-latency/ (opens new window)
# 数字证书与认证中心
CA 是 Certificate Authority 的缩写，也叫“证书授权中心”
CA 证书，顾名思义，就是 CA 颁发的证书。
数字证书包含信息：
证书信息：过期时间和序列号
所有者信息：姓名等
所有者公钥
证书认证中心 CA。当服务端要把公钥发送给客户端时，不是直接发送公钥，而是先把公钥发送给 CA，CA 根据公钥生成一份「证书」给到服务端，服务端将证书给客户端。客户端拿到证书后去 CA 验证证书的合法性，确保证书是服务端下发的。
CA 就类似于「公证处」，也是一台服务器，它自己本身也有一套密钥对。它的工作就是根据服务端的公钥生成证书，然后帮助客户端来验证证书的合法性。
CA 机构在生成证书的时候就使用了“数字签名”，保证了证书的完整性
原理：CA 机构使用 Hash 算法得到证书明文信息的“信息摘要”，然后使用自己的私钥对“信息摘要”加密，生成数字签名一同放在数字证书中；当客户端收到服务器发送的证书时，可以通过证书中的 Hash 算法对证书信息签名得到“信息摘要”，然后使用 CA 机构的公钥对原证书中的签名信息解密，如果解密后的“信息摘要”和自签名得到的一致，则说明没问题。（CA 机构一般都是权威性的，所以通常它的公钥都是内置在客户端系统中的）
CA 被冒充怎么办？
使用「根证书」和「CA 信任链」
给 CA 也颁发证书，那这个证书由谁来颁发呢？自然是 CA 的上一级 CA 了。CA 的上一级 CA 如何保证安全？那就 CA 的上一级 CA 的上一级 CA 给它办法证书了。最终就会形成一个证书信用链
参考：HTTPS 中 CA 证书的签发及使用过程 https://www.cnblogs.com/xdyixia/p/11610102.html (opens new window)
参考：HTTPS 加密传输与 CA 证书 https://www.cnblogs.com/k5210202/p/13342208.html (opens new window)
# 数字证书签发和验证流程
CA 签发证书的过程：
首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值；
然后 CA 会使用自己的私钥将该 Hash 值加密，生成 Certificate Signature，也就是 CA 对证书做了签名；
最后将 Certificate Signature 添加在文件证书上，形成数字证书；
客户端校验服务端的数字证书的过程：
首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1；
通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容，得到一个 Hash 值 H2 ；
最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。
# SSL/TLS
SSL（Secure Socket Layer）是安全套接层
TLS（Transport Layer Security）是传输层安全协议
最新版本的 TLS（Transport Layer Security，传输层安全协议）是 IETF（Internet Engineering Task Force，Internet 工程任务组）制定的一种新的协议，它建立在 SSL 3.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。
TLS 与 SSL3.0 在加密算法上不同，但是在我们理解 HTTPS 的过程中，我们可以把 SSL 和 TLS 看做是同一个协议。
TLS 主要采取的是 RSA(非对称加密)与 AES(对称加密)结合的加密方式。先通过 RSA 交互 AES 的密钥，然后通过 AES 进行报文加密和解密。
不使用 SSL/TLS 的 HTTP 通信，就是不加密的通信。所有信息明文传播的三大风险：
窃听风险（eavesdropping）：第三方可以获知通信内容。
篡改风险（tampering）：第三方可以修改通信内容。
冒充风险（pretending）：第三方可以冒充他人身份参与通信
SSL/TLS 协议：
数据完整性：所有信息都是加密传播，第三方无法窃听。(对称加密+非对称加密)
数据隐私性：具有校验机制，一旦被篡改，通信双方会立刻发现。(数字签名)
身份校验：配备身份证书，防止身份被冒充。(数字签名)
SSL/TLS 的功能实现主要依赖于三类基本算法：散列函数 、对称加密和非对称加密，
其利用非对称加密实现身份认证和密钥协商，
对称加密算法采用协商的密钥对数据加密，
基于散列函数验证信息的完整性。
SSL/TLS 需要四次握手的过程：
客户端向服务端所有证书。
服务端发送证书。
客户端验证证书，提取公钥，发送对称加密的密钥。
服务端收到密钥，响应 OK。
参考：图解 SSL/TLS 协议 http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html (opens new window)
SSL 的慢分两种：
- 通信慢
和使用 HTTP 相比， 网络负载可能会变慢 2 到 100 倍。 除去和 TCP 连接、 发送 HTTP 请求 • 响应以外， 还必须进行 SSL 通信，因此整体上处理通信量不可避免会增加；
- 处理速度慢
由于 SSL 必须进行加密处理，要大量消耗 CPU 及内存等资源， 导致处理速度变慢。在服务器和客户端都需要进行加密和解密的运算处理。 因此从结果上讲， 比起 HTTP 会更多地消耗服务器和客户端的硬件资源， 导致负载增强。
# 数据签名
数字签名是个加密的过程，数字签名验证是个解密的过程。
签名就是在信息的后面再加上一段内容（信息经过 hash 后的值），可以证明信息没有被修改过。hash 值一般都会加密后（也就是签名）再和信息一起发送，以保证这个 hash 值不被修改。
数字签名必须保证以下三点：
报文鉴别——接收者能够核实发送者对报文的签名；
报文的完整性——接收者不能伪造对报文的签名或更改报文内容。
不可否认——发送者事后不能抵赖对报文的签名；
数字签名解决的核心问题是：确保收到的文件没有被更改。
参考：https://www.cnblogs.com/itps/p/12359865.html (opens new window)
# https 问题汇总
# http 和 https 区别
1、https 协议需要到 CA 申请证书，一般免费证书较少，因而需要一定费用。
2、http 是超文本传输协议，信息是明文传输，https 则是具有安全性的 ssl/tls 加密传输协议。
3、http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
4、http 的连接很简单，是无状态的；HTTPS 协议是由 SSL/TLS+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 http 协议安全。
- HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS 除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
参考：https://www.cnblogs.com/heluan/p/8620312.html (opens new window)
# https 非对称加密过程
① 证书验证阶段
- 浏览器发起 HTTPS 请求
- 服务端返回 HTTPS 证书
- 客户端验证证书是否合法，如果不合法则提示告警
② 数据传输阶段
- 当证书验证合法后，在本地生成随机数
- 通过公钥加密随机数，并把加密后的随机数传输到服务端
- 服务端通过私钥对随机数进行解密
- 服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输
# 为什么 https 可以防中间人攻击
数字证书和 CA 证书认证中心
# https 有几次握手
# 为什么抓包 Https 可以看到明文
HTTPS 数据只是在传输时进行了加密，而抓包工具是接收到数据后再重新加密转发，所以抓包工具抓到的 HTTPS 包可以直接看到明文；
参考：为什么用抓包工具看 HTTPS 包是明文的 (opens new window)