SSL/TLS 1.2过程:Client端如何验证服务端证书?

快速回顾非对称加密和对称加密

首先快速说一下非对称加密和对称加密。非对称加密,就是有一个公钥和私钥(成对存在)。

公钥对一段文本A加密得到文本B,只有对应的私钥能对B解密得到A。

私钥对一段文本C加密得到文本D,只有对应的公钥能对D解密得到C。

也就是一个密钥加密,只能用另一个密钥解密。不能用本身或者其他任何密钥解密。

对称加密则是另一种方式,一个密钥M对一段文本E加密得到文本F,只能由这个密钥M对文本F解密得到E。

快速回顾https

然后 https = http + SSL/TLS

SSL/TLS就是保证安全性,保证发送请求的时候不被第三方攻击。

前置知识

1、TLS主要是验证服务端是安全的

2、TLS证书安装在服务端,服务端有一对公钥和私钥

3、公钥全部人可见,私钥只有自己可见

4、除非双向认证,否则只有客户端验证服务端的身份

SSL/TLS 1.2过程

TLS/SSL过程:

1、客户端发送 ClientHello

2、服务端响应 ServerHello

3、服务端主动发送证书 (SSL证书,安装于服务端)

4、服务端发送ServerHelloDone

5、客户端验证服务端的SSL证书

(验证证书是重要的一步,后续会主要讲这个。主要目的就是为了验证服务端是经过CA机构认证的 ,并且正确 拿到服务端的公钥 )。

6、客户端生成一个密钥M,拿到服务端证书里带的服务端的公钥,加密M得到M1

7、客户端发送 ClientKeyExchange: 就是把M1发给服务端

8、服务端拿到M1,用服务端的私钥解密M1得到M:只有服务端能拿到这个M1

9、双方根据M生成主密钥S1和会话密钥S2:注意此时只有客户端和服务端知道S1和S2,其他人都不知道

10、客户端发送 ChangeCipherSpec 和 Finished

11、服务器响应 ChangeCipherSpec 和 Finished

12、确认完毕,后面都用S2对称加密文本。发的时候S2加密,解的时候S2解密。

这样为什么安全?

因为第5步,客户端正确拿到了服务端的公钥;公钥就是明文的,所有人都能拿到。

服务端的公钥加密的文本只能被服务端解密(只有服务端有对应私钥),所以可以发送一些信息给服务端。比如第8步的M1。

证书长啥样?

服务端证书:

复制代码
-----BEGIN CERTIFICATE-----
*PS:以下信息都会被base64编码*
**服务端公钥**:C11
**数字签名**:xxx
**其他信息**:这里可以一笔带过,比如服务端名称,域名,颁发机构等
-----END CERTIFICATE-----

公钥:重要,一定要正确。

数字签名:重要,这个数字签名能保证这个证书是被CA机构认证过的,公钥是真的。

不然不法分子伪造一个证书,然后你拿到一个假的公钥,那么后续的发送消息都要被不法分子盗了。

CA机构

简单理解就是一些很权威的机构,能够给别人的证书加上数字签名。证书有了这个数字签名,这个证书就是被认证的证书,那么服务端就是被信任的。

CA机构怎么给别人的证书加上数字签名

CA机构也有证书。其中有一个是根证书,是被信任的证书,它被安装在操作系统中。大概操作系统开发者实地走访找到CA机构,并且拿到了根证书。

如上所述,根证书上有CA的C1,和它的数字签名。

根证书这个数字签名是它自己给自己签名的,叫做自签名证书。

CA机构有一个私钥C0,只有CA机构自己知道。

给某个证书签名步骤:

1、拿到这个证书的公钥C11和其他信息

2、计算 Hash (公钥C11 + 其他信息) = 一串hash后的结果A

3、用C0给A加密,得到A1。A1就是这个数字签名

为啥说有了签名就能验证服务端的确是被真正的CA机构认证过的呢?

看下一个

客户端如何验证服务端的SSL证书

上面说到,A1就是数字签名。客户端也安装了CA机构的证书,根证书,所以也有CA机构的公钥C0。

客户端验证服务端证书步骤:

1、客户端拿到证书,并且拿到里面的服务端公钥C11和数字签名A1,以及其他信息

2、客户端用C1给A1解密,会得到A

3、客户端计算 Hash (公钥C11 + 其他信息) = 一串hash后的结果B

4、验证A == B,一旦A和B相等,说明了 服务端公钥C11 + 其他信息 都是正确的

验证没问题后,说明C11正确。这也是TLS认证的第5步,主要目的是拿到正确的服务端公钥。拿到后就能开始按照上面第6步以后通信了。

什么是中间CA

CA机构有一个权威的根证书。用这个根证书给某个CA1证书签名。那么这个CA1证书也是可信赖的了。然后CA1也可以用上面的方法给服务端签名,当然也可以给CA2签名。

CA1,CA2都是中间CA。根CA给CA1签名,CA1给CA2签名,CA2给CA3签名,等等。最后一个CAn给服务端签名。CA1,CA2... CAn都是中间证书。

验证步骤就变成了,先用CAn验证服务端有没有问题,再用CA(N-1)验证CAn对不对,最后用根CA验证CA1是不是对的。一步步往上回溯。

最顶层的就是之前说的根证书。中间的都是中间CA证书。最底层的是服务端证书,也就是叶证书。

只要能回溯到根证书,那么这个验证就是通过的。

有了中间CA,一般的证书长这样:

复制代码
-----BEGIN CERTIFICATE-----
<base64加密后的叶证书内容>
叶证书公钥:xx
叶证书数字签名:xxxx
其他信息:xxxxx
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<中间证书内容>
-----END CERTIFICATE-----

可信任证书

上面说到根证书是被信任的。其实也可以把中间CA证书放入电脑的信任列表里。这样回溯到这个中间CA就可以了。也就是能根据叶证书,中间证书慢慢回溯到某一个被信任的证书就可以了。

所以,对于内部系统,其实可以自己给自己的服务端生成一个证书(主要就是公钥和私钥),然后把它放入信任列表里。或者自己生成一个CA证书,把它放入信任列表里。

因为根CA是自签名证书。所以可以自己内部也生成一个自签名证书,把它放入信任列表里,充当CA根证书,并且用这个CA根证书给自己内部的服务都加上签名,就不会有SSL问题。其实也是安全的,因为这个根证书是自己造的,那么公钥肯定是可信任的。

相关推荐
用户962377954481 天前
DVWA 靶场实验报告 (High Level)
安全
数据智能老司机1 天前
用于进攻性网络安全的智能体 AI——在 n8n 中构建你的第一个 AI 工作流
人工智能·安全·agent
数据智能老司机1 天前
用于进攻性网络安全的智能体 AI——智能体 AI 入门
人工智能·安全·agent
用户962377954481 天前
DVWA 靶场实验报告 (Medium Level)
安全
red1giant_star1 天前
S2-067 漏洞复现:Struts2 S2-067 文件上传路径穿越漏洞
安全
用户962377954481 天前
DVWA Weak Session IDs High 的 Cookie dvwaSession 为什么刷新不出来?
安全
小时前端1 天前
HTTPS 页面加载 HTTP 脚本被拦?同源代理来救场
前端·https
cipher3 天前
ERC-4626 通胀攻击:DeFi 金库的"捐款陷阱"
前端·后端·安全
一次旅行6 天前
网络安全总结
安全·web安全
red1giant_star6 天前
手把手教你用Vulhub复现ecshop collection_list-sqli漏洞(附完整POC)
安全