阅读本文 📖

什么是HTTPS

什么是SSL/TLS

对称加密

非对称加密

数字签名

数字证书

前言 🌵

由于群里又个小伙伴在访问TypeScript官网时，被嵌入的广告信息，进而牵扯出来HTTPS，以及数字签名以及数字证书的问题，本文就来做一个梳理

知识点 📒

什么是HTTPS

由于 HTTP 天生“明文”的特点，整个传输过程完全透明，任何人都能够在链路中截获、修改或者伪造请求 / 响应报文，数据不具有可信性。

什么是安全性

• 机密性 (将消息加密)
• 完整性（保证消息没有被添油加醋）
• 身份认证（保证消息的来源）
• 不可否认（保证消息的行为，不能抵赖）

HTTPS 和 HTTP的不同就是 新的协议名 ‘’https‘，默认端口443 再加上以上的安全性就是https了

S在于 https是 over SSL/TLS  http over TCP/IP

对称加密

就是 客户端和服务端拿着同一个🔑，加密和解密都使用这把🔑。

“对称加密”很好理解，就是指加密和解密时使用的密钥都是同一个，是“对称”的。只要保证了密钥的安全，那整个通信过程就可以说具有了机密性。

非对称加密

有两把钥匙，一把公钥，一把私钥

• 与对称加密最大的不同就是单向性，使用公钥加密，只能私钥解密，私钥加密 公钥解密
• 非对称密码主要解决密钥交换问题，我们的https采用的是混合加密的方式，先使用非对称加密加密私钥，再使用私钥进行数据加密解密
• 非对称加密算法用的比较多的是RSA、ECDHE

混合加密

TLS 里使用的混合加密方式，其实说穿了也很简单：

在通信刚开始的时候使用非对称算法，比如 RSA、ECDHE，首先解决密钥交换的问题。

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

对方拿到密文后用私钥解密，取出会话密钥。这样，双方就实现了对称密钥的安全交换，后续就不再使用非对称加密，全都使用对称加密。

这样混合加密就解决了对称加密算法的密钥交换问题，而且安全和性能兼顾，完美地实现了机密性。

摘要算法

实现完整性的手段主要是摘要算法（Digest Algorithm），也就是常说的散列函数、哈希函数（Hash Function）

人话就是你吃了1千克的黄金，烧融化了还是有1千克，如果中间有人加了杂物，那么质量就变了，也就是哈希不一致。

摘要算法主要就是验证数据的完整性

数字签名

加密算法和摘要算法结合，我们的通信算是比较安全了，但是还有个问题就是端到端的安全问题。黑客既可以伪装🥸成客户端，又可以为伪装成服务端。如何证明身份呢🆔？没错，这个东西就是非对称加密里的“私钥”，使用私钥再加上摘要算法，就能够实现“数字签名”，同时实现“身份认证”和“不可否认”。

数字签名的原理其实很简单，就是把公钥私钥的用法反过来，之前是公钥加密、私钥解密，现在是私钥加密、公钥解密。

但又因为非对称加密效率太低，所以私钥只加密原文的摘要，这样运算量就小的多，而且得到的数字签名也很小，方便保管和传输。

签名和公钥一样完全公开，任何人都可以获取。但这个签名只有用私钥对应的公钥才能解开，拿到摘要后，再比对原文验证完整性，就可以像签署文件一样证明消息确实是你发的。

下图就是签名和验签名

数字证书和 CA

到现在，综合使用对称加密、非对称加密和摘要算法，我们已经实现了安全的四大特性，是不是已经完美了呢？不是的，我们需要三个东西(公钥、数字签名、原文)有一个是真实的，我们就可以验证数据的真伪。这里就是“公钥的信任”问题。因为谁都可以发布公钥，我们还缺少防止黑客伪造公钥的手段，也就是说，怎么来判断这个公钥就是你或者你要访问网站的公钥呢？

CA机构(Certificate Authority，证书认证机构)，是一个权威机构，相当于网络中大家公认的公安局，由它来颁发我们网站的数字证书，证书里面就包含我们网站的个人信息以及我们网站的公钥🔑。

当然这个证书也可以被黑客篡改，那么如何验证数字证书的真实性和完整性呢，同样在颁发证书的时候，由CA机构的私钥给数字证书签名，我们操作系统和浏览器都内置了各大CA机构的根证书(记录了可以信赖的CA机构及其公钥匙)来验证证书的真实性。

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

TLS 握手过程

总结 🍁

为什么要使用各种各样的加密策略？

↓ 对称加密（有密钥交换的问题） ↓ 非对称加密（基于复杂的数学难题，运行速度很慢） ↓ 混合加密（怎么保证完整性？不被修改？） ↓ 摘要算法（无法保证是用户自己） ↓ 数字签名（公钥怎么保证安全正确的？） ↓ 数字证书、CA

证书验证过程：

服务器握手时会返回的证书链，然后浏览器就可以使用信任的根证书（根公钥）解析证书链的根证书得到一级证书的公钥+摘要验签，然后拿一级证书的公钥解密一级证书拿到二级证书的公钥和摘要验签，再然后拿二级证书的公钥解密二级证书得到服务器的公钥和摘要验签，验证过程就结束了。

TLS的握手过程：

第一阶段：C/S两端共享Client Random、Server Random 和 Server Params信息 客户端--->服务器： 客户端的版本号、支持的密码套件，还有一个随机数（Client Random）

服务端--->客户端： 客户端的版本号、选择的客户端列表的密码套件如：TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、随机数随机数（Server Random）

服务端--->客户端： 服务端证书（Server Certificate）

服务端--->客户端： 发送Server Key Exchange类型的请求，携带椭圆曲线的公钥（Server Params）用以实现密钥交换算法，另附私钥签名

服务端--->客户端： 发送完毕

第二阶段：证书验证

前验条件：客户端证书链逐级验证、证书公钥验证签名，服务端身份验证成功（证书合法）

客户端--->服务端 发送Client Key Exchange类型的请求，携带椭圆曲线的公钥（Client Params）用以实现秘钥交换算法

第三阶段：主密钥生成(用它可以扩展其他密钥，暂且可以理解成会话密钥)

客户端、服务端分别使用Client Params、Server Params通过ECDHE算法计算出随机值pre-master，然后用 Client Random、Server Random 和 Pre-Master三个值作为原材料，用PRF伪随机数函数（利用密码套件的摘要算法再次强化结果 值maser secert的随机性）计算出主密钥Master Secret，

主密钥并不是会话秘钥，还会再用PRF扩展出更多的密钥，比如客户端发送用的会话密钥（client_write_key）、服务器发送用的会话密钥（server_write_key）

客户端--->服务端: 客户端发一个“Change Cipher Spec”，然后再发一个“Finished”消息，把之前所有发送的数据做个摘要，再加密一下，让服务器做个验证.

服务端--->客户端： 服务器也是同样的操作，发“Change Cipher Spec”和“Finished”消息，双方都验证加密解密 OK，握手正式结束.