【🍌图文速解🐵】HTTPS中的TLS、数字签名、SSL证书

我们首先要知道 HTTPS = HTTP + SSL/TLS HTTPS 建立连接的过程,先进行 TCP 三次握手,再进行 TLS 四次握手(仅对https)

本文只针对重难点的分析解惑,对于加密过程如何一步步保证安全的剖析,如需查阅完整知识链,可以查看我的知识库哈,面试八股文应有尽有~

TLS的四次握手

在这个阶段,客户端和服务器会进行协商,选择一种加密算法和密钥交换方法。它还包括对服务器证书进行验证,以确保服务器的身份和证书的合法性。

另外注意,TLS是使用非对称加密对称加密相结合来保证传输安全的,至于为什么需要这么做?可以接着看下文的章节

四次握手分别为:

第一次握手:客户端发出请求Client Hello

第二次握手:服务器回应Server Hello
客户端验证证书
第三次握手:客户端回应

第四次握手:服务端回应

这里简单说一下,

第一次握手:客户端向服务器发送ClientHello消息,其中包含支持的TLS版本、加密套件列表和随机数等信息。

第二次握手:服务器收到ClientHello消息后,回复ServerHello消息作为响应。ServerHello消息包含选择的TLS版本、加密套件和服务器生成的随机数,同时可能包含服务器的证书。

我们主要关注客户端验证证书第三次握手,其实可以统称为第三次握手

客户端验证证书

客户端收到服务器回应以后,首先验证服务器证书,验证手段就是执行如下三种检查:

  • 检查证书是否已过期;
  • 检查证书中的域名与实际域名是否一致
  • 检查证书是否是可信机构颁布的

如果,上述过程中有任何一个环节发现问题,那么浏览器就会向访问者显示一个警告,由其选择是否还要继续通信。如果证书受信任,或者是用户接受了不受信的证书,客户端会生成一串新的随机数(Pre-master secret )

第三次握手:客户端回应

注意第三次握手时,开始是 "密钥交换" 的关键 了!也可以说是"安全地"生成相同密钥,不会被中途掉包,密钥交换是以后对称加密的基础!!

此时,客户端现在拥有的随机数:

  • Client random
  • Server random
  • Pre-master secret (客户端生成的随机数,经过公钥加密后传给服务端)

注意:不知道为什么要用公钥加密后再传的,可以看后面非对称加密的"蓝钥匙"的交换过程

第三次握手中,客户端会生成一个随机数作为"Pre-Master Secret ",并使用服务端传过来的公钥进行加密。然后客户端将加密后的"Pre-Master Secret"发送给服务端。

那么在第四次握手时,服务端使用自己的私钥进行解密(公钥加密私钥解密),得到"Pre-Master Secret "。之后,服务端和客户端各自使用相同的三个随机数都计算获得了一个会话密钥"Session Key "。这个会话密钥就是接下来双方进行对称加密解密使用的密钥!

对称加密和非对称加密

两种方法结合,这就是 TSL 加密了!!

以下是简单的呈现形式

对称加密

所谓的对称加密,起归根结底在于加密和解密的密钥是相同的

缺点:由于对称加密的算法是公开的,所以一旦私钥被泄露,那么密文就很容易被破解,所以对称加密的缺点是密钥安全管理困难。

非对称加密

非对称加密其实还有一个叫法是公钥密码加密 ,非对称加密的要点是 公钥加密,私钥解密。

下面是RSA算法的简单呈现:

缺点:非对称加密算法计算效率较低,加密和解密速度较慢

这样非对称加密 后可以让双方都安全的拿到了一把密钥,以后可以进行高效、安全的对称加密了!!这就是TLS所干的事!!

还有什么安全问题?

数字签名

如何确保响应信息的过程中,信息文件不会被篡改?

这就涉及到了 数字签名 ,使用响应正文 + Hash算法 得出的一个摘要 ,再通过私钥加密就是数字签名

假如以下场景,A 是请求方,B 是响应方,C 是拦截方。

这个数字签名的作用是主要就是让A获得 原始摘要 ,后面在其他的安全途径下获取的响应正文(经过TLS加密传输的),利用相同的哈希算法计算得到一个新的摘要,对比两个摘要,就可以知道内容是否被篡改过!

注意:因为哈希算法是单向的,无法逆向推导出原始数据。即使拦截方 C 对摘要重新进行哈希运算,无法得到响应正文的原始内容。

数字证书

如何证明这个公钥就是服务端发过来的呢?而不是别人偷换的公钥?证明我们交流的对象是正确的?

上面简单呈现出来的方法也不一定是安全的,因为没有办法确定得到的公钥就一定是安全的公钥。可能存在一个中间人,截取了对方发给我们的公钥,然后将他自己的公钥发送给我们,当我们使用他的公钥加密后发送的信息,就可以被他用自己的私钥解密。然后他伪装成我们以同样的方法向对方发送信息,这样我们在和一个错误的对象进行交流,然而自己还不知道。为了解决这样的问题,可以使用 数字证书

将公钥交给 CA(Certificate Authority)即颁发数字证书的权威机构。再把该证书放到互联网上,让其他人看见这个公钥才是权威的、正确的。

这样就解决了中途有人把公钥掉包,并且发送假的数字签名,利用了错误的公钥顺利的解密了得到了相同摘要,而自己还不知道

相关推荐
理想不理想v1 分钟前
‌Vue 3相比Vue 2的主要改进‌?
前端·javascript·vue.js·面试
酷酷的阿云11 分钟前
不用ECharts!从0到1徒手撸一个Vue3柱状图
前端·javascript·vue.js
微信:1379712058713 分钟前
web端手机录音
前端
齐 飞19 分钟前
MongoDB笔记01-概念与安装
前端·数据库·笔记·后端·mongodb
神仙别闹36 分钟前
基于tensorflow和flask的本地图片库web图片搜索引擎
前端·flask·tensorflow
sszmvb12341 小时前
测试开发 | 电商业务性能测试: Jmeter 参数化功能实现注册登录的数据驱动
jmeter·面试·职场和发展
测试杂货铺1 小时前
外包干了2年,快要废了。。
自动化测试·软件测试·python·功能测试·测试工具·面试·职场和发展
王佑辉1 小时前
【redis】redis缓存和数据库保证一致性的方案
redis·面试
真忒修斯之船1 小时前
大模型分布式训练并行技术(三)流水线并行
面试·llm·aigc
GIS程序媛—椰子1 小时前
【Vue 全家桶】7、Vue UI组件库(更新中)
前端·vue.js