浅谈HTTPS🔐

速冻鱼
543 阅读8分钟

大家好，我是速冻鱼🐟，一条水系前端💦，喜欢花里胡哨💐，持续沙雕🌲
欢迎小伙伴们加我微信：sudongyuer拉你进群
关注我的公众号:前端速冻鱼一起进步，期待与大家共同成长🥂

阅读本文 📖

什么是HTTPS

什么是SSL/TLS

对称加密

非对称加密

数字签名

数字证书

前言 🌵

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

知识点 📒

什么是HTTPS

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

什么是安全性

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

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

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

image-20220109153736178

对称加密

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

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

image-20220109153940382

非对称加密

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

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

混合加密

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

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

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

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

img

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

摘要算法

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

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

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

image-20220109155947550

数字签名

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

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

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

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

下图就是签名和验签名

image-20220109165630601

数字证书和 CA

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

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

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

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

image-20220109173645708

TLS 握手过程

img

总结 🍁

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

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

参考文献 📚

  • 《网络是怎样连接的》
  • 《图解TCP/IP》
  • 《图解HTTP》
  • 《计算机网络自顶向下》
  • 小林哥的图解计算机网络
  • 《透视HTTP协议》

结束语 🌞

那么我的浅谈HTTPS🔐就结束了，文章的目的其实很简单，就是对日常工作的总结和输出，输出一些觉得对大家有用的东西，菜不菜不重要，但是热爱🔥，希望大家能够喜欢我的文章，我真的很用心在写，也希望通过文章认识更多志同道合的朋友，如果你也喜欢折腾，欢迎加我好友，一起沙雕，一起进步。

github🤖:sudongyu

个人博客👨‍💻:速冻鱼blog

vx👦:sudongyuer

写在最后

伙伴们，如果喜欢我的口水话给🐟🐟点一个赞👍或者关注➕都是对我最大的支持。

avatar
文章
阅读
粉丝