【网络】https 轻解读

Abstract

TLS、SSL、摘要（digest）、对称/非对称加密、数字签名(signature)、证书(certification)，傻傻分不清楚？为了解 https， 鄙人对以上这几个名词都做了些功课，特此记录一下。

Content

SSL/TLS
密码学

overview
摘要算法/hash算法
对称/非对称加密

签名
证书
SSL四次握手
实践

SSL/TLS

首先，我们来回首一下 SSL/TLS 的演进过程。

• SSL: Secure Sockets Layer
• TSL: Transport Layer Security
• SSL1.0 -> SSL2.0 -> SSL3.0 -> TLS1.0(SSL3.1) -> TLS1.1(SSL3.2) -> TLS1.3(SSL3.3)

密码学

其次，为了解https，先来了解一下密码学。

• Overview
  

• Hash/散列/摘要算法

hash(原始数据）= 一段固定长度的数据摘要

• 对称加密
  

• 非对称加密

- 公私钥对
- 公钥加密的话，只有私钥能解密
- 私钥加密的话，只有公钥能解密

（notes： 顾名思义，私钥只有服务器做保留，公钥发放给客户端。根据这一性质，一般都用公钥做加密，私钥做签名）

签名

根据上文所述，先对一段原文进行散列算法提取定长的数字摘要，再对数字摘要通过私钥加密，即为签名(就是一段密文)。

签名(密文) = 私钥加密(hash(明文))

签名的目的是为了防止数据篡改。在不安全的网络传输环境中，可能会有中间商/黑客拦截请求获取数据并加以修改，解决方法是通常从服务端发送(原文 + 算列算法 + 摘要), 客户端通过(原文 + 算列算法)重新计算出新摘要，两者相同则说明数据并未被篡改，反之亦然（即使数据被拦截，客户端计算的新摘要与源摘要不匹配，客户端也会拒绝）。

证书

证书就是一份数字签名，只不过原始信息包含了服务器域名、地址、公司等信息。

SSL四次握手

了解了上述背景之后，我们来看一下具体服务端和客户端是如何连接的。

（这里细节请大家自行欣赏大佬原文 ==> link here）

根据鄙人理解，最最主要交互信息如下

第一次握手	1.客户端生成随机数A，稍后用于生成"对话密钥"
	2.客户端提供支持的TLS版本
	3.客户端提供支持的加密算法套（摘要算法 + 对称加密 + 非对称加密）
第二次握手	1.服务端生成随机数B，稍后用于生成"对话密钥"
	2.服务端返回支持的TLS版本（如果不一致服务端关闭加密通信）
	3.服务端返回决定的加密算法套（摘要算法 + 对称加密 + 非对称加密）
	4. 服务端返回服务端证书(server.pem)
第三次握手	1.客户端生成随机数C，该随机数用服务器公钥加密，防止被窃听
	2.客户端验证证书
	3.编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送
	4.客户端握手结束通知
第四次握手	1.编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送
	2.服务端握手结束通知

最终的结果则为

对于这么做的目的以及如何四次握手是保证安全的，网上解析繁花似锦。小人取众家之长，以倒推的思路，给予个人如下理解。

Q1.如何实现Https加密传输？

A1. 最终的目的是服务端和客户端采用两者协商好的对称加密算法进行通信

• 首先，对称加密比非对称加密开销小。
• 如果用非对称加密得话，双端均有存一份公私钥对，数据发送方（可以是服务端，也可以是客户端）均需要公钥加密，接收方私钥解密。

Q2. 那么，对称加密效率是满足了，但是如何保证安全性呢？

A2. 确保服务端和客户端生成相同的密钥，这个密钥有且只有双端持有，第三方不知道

• 通过四次握手之后，双端已协商好了要使用的加密套（摘要算法 + 对称加密 + 非对称加密，同时双端均已知上述握手中提到的A、B、C三个随机数，那么用这三个随机数

Q3. 握手的时候随机数和协商的加密算法被中间商拦截，不也可以生成相同密钥仿冒客户端与服务端通信？

A3. 这时就引入了证书，证书包含服务端公钥信息，可对随机数C加密

• 因为是用服务端公钥加密，所以这个随机数只有服务端自己本地的私钥可以解，第三方及时拿到也解不了，这就保证了第三方不可能生成相同的会话密钥。

Q4.第二次握手中，中间第三方拦截了证书，并用自己的私钥伪造一份证书发送给客户端

• 这就导致了一个问题，客户端以为自己在和服务端通信，其实是在和第三方通信。

Q5.如何校验证书？

A5.这时就需要CA根证书对服务端证书校验

• CA(Certification Authority)，全世界官方认证机构，他们的ca根证书在操作系统安装中保留（我理解就是本地自带）

• 用根证书的公钥解密，解不开则说明该证书不是由CA机构签发的，不受信任

• 可以解开得话，证书中应该含有摘要、摘要算法，服务端可以根据证书原文和摘要算法重新hash算出摘要，校验证书是否被篡改