HTTPS 的通信加解密过程，证书为什么更安全？

Posted 2023-03-30 Hogwarts测试开发

经典面试题

• HTTPS 的通信加解密过程，证书为什么更安全？

考察点

• 《计算机网络》相关知识

• 了解 HTTPS 协议加解密的过程

• 了解数字证书认证的过程

技术点

• 对称加密和非对称加密

• HTTPS 协议的加解密过程

• 数字证书认证过程

对称加密和非对称加密

• 对称加密：加密和解密用的是同样的密钥。

• 非对称加密：加密和解密使用不同的密钥。使用一对密钥，公钥（public key）是每个人都能拿到公开的，私钥（private key）只有自己知道。

数字证书

数字证书是一种网络上证明持有者身份的文件，同时还包含有公钥。数字证书在 SSL/TLS 传输过程中扮演身份认证和密钥分发的功能。

服务端将公钥发给数字证书认证机构进行安全认证并对公钥进行数字签名，完成后公钥和签名组合成数字证书。在和客户端通信时，服务端将数字证书发给客户端，客户端通过第三方安全认证机构发布的公钥（一般会在浏览器开发时，内置在浏览器中）对数字证书上的签名进行验证，假如验证通过，则能证明该服务器的公钥的机构是真实有效的数字证书认证机构，该服务器发过来的公钥是值得信赖的。

数字证书包括了加密后服务器的公钥、权威机构的信息、服务器域名，还有经过 CA 私钥签名之后的证书内容（经过先通过Hash函数计算得到证书数字摘要，然后用权威机构私钥加密数字摘要得到数字签名)，签名计算方法以及证书对应的域名。

image988×475 38.4 KB

HTTPS 协议的加解密过程

HTTPS 使用了混合加密的方式，也就是结合非对称加密和对称加密技术。

客户端使用对称加密生成密钥对传输数据进行加密，然后使用非对称加密的公钥再对秘钥进行加密，所以网络上传输的数据是被秘钥加密的密文和用公钥加密后的秘密秘钥，因此即使被黑客截取，由于没有私钥，无法获取到加密明文的秘钥，便无法获取到明文数据。

image878×585 76 KB

• ClientHello：首先客户端发起 HTTPS 请求，然后连接到服务端的 443 端口。客户端会把 SSL/TLS 版本、客户端的随机数、加密组件（cipher suites）列表、支持的压缩方法等等都一起传给服务端。

• ServerHello：服务端表示收到信息，并且会根据 ClientHello 选择好 SSL/TLS 版本和加密组件，并且把选择好的版本组件以及服务端的随机数发送给客户端。

• Certificate：接下来服务端会把包含公钥的数字证书也发送给客户端。采用 HTTPS 协议的服务器必须要有一套数字证书，可以自己制作，也可以向 CA 组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。数字证书包括了括了加密后服务器的公钥、权威机构的信息、服务器域名，还有经过CA私钥签名之后的证书内容，签名计算方法以及证书对应的域名等信息。

• ServerHelloDone：通知客户端，最初阶段的握手协商完成了。

• 验证数字证书：客户端的 SSL/TLS 来完成数字证书验证，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值 pre_master。

• ClientKeyExchange：通过客户端随机数、服务端随机数和刚生成的 pre_master 生成会话密钥，这个会话密钥是对称加密密钥。只要安全发送给服务端，后面就可以使用这个会话密钥加密信息、解密信息了。要安全的发送这个会话密钥，需要使用服务端发送过来的公开密钥把它加密一下。

• ChangeCipherSpec：把加密过的会话密钥发送给服务端

• Finished：告诉服务后，后面发送的信息都会使用会话密钥加密了。如果验证失败，这次握手就失败了，关闭。

• 服务端验证会话密钥：服务端用私钥解密后，得到了客户端传过来的会话密钥。

• ChangeCipherSpec：告诉客户端，会话密钥已经收到，从现在起所有我发的信息都会使用会话密钥尽心加密了！

• Finished：我的信息发送完毕了。

答案总结

问题：HTTPS 的通信加解密过程，证书为什么更安全？

1. HTTPS 的通信加解密过程基本是客户端先向服务端提出通信请求；然后服务端把包含了公钥的数字证书发给客户端；客户端拿到数字证书后先验证证书的可靠性，验证通过后生成对称加密的会话密钥，并把会话密钥使用服务端的公钥进行加密后发给服务端；服务端收到加密后的会话密钥后，使用私钥解密，得到会话密钥；然后双方使用会话密钥加密通信信息，收到信息后同样适用会话密钥进行解密即可。

2. 数字证书可以让服务器向浏览器证明自己的身份避免被假冒，并且可以安全的把公钥传给浏览器，所以使用数字证书可以更加安全。

加解密与HTTPS

您好，我是湘王，这是我的51CTO博客，欢迎您来，欢迎您再来～

---

随着成本的下降，主流网站都已经开始使用HTTPS了。但有了可信机构颁发的证书，网站就真的绝对安全了吗？以之前出现过的上大学被冒名顶替的事件为例，如果个人信息被「抓包」怎么办？

看过前面技术博客的小伙伴可能还记得，HTTPS的整体过程分为证书验证和数据传输阶段：

1、证书验证阶段

1）、浏览器发起HTTPS请求

2）、服务端返回HTTPS证书

3）、客户端验证证书是否合法，如果不合法则提示告警

2、数据传输阶段

1）、当证书验证合法后，在本地生成随机数

2）、通过公钥加密随机数，并把加密后的随机数传输到服务端

3）、服务端通过私钥对随机数进行解密

4）、服务端通过传入的随机数构造对称加密算法，对返回结果内容进行加密后传输

因为非对称加解密效率很低，而实际应用场景中端与端之间通常有大量的交互。所以，在HTTPS的场景中只有服务端保存了私钥，因此只能实现单向的加解密，所以内容传输要采用对称加密算法。

如果没有证书颁发机构，就会出现经典的「中间人攻击」：

这和冒名顶替上大学如出一辙：

1、本地请求被劫持（如DNS劫持等），所有请求被发送到中间人的服务器

2、中间人服务器返回中间人自己的证书

3、客户端创建随机数，通过中间人证书的公钥对随机数加密后传送给中间人，然后凭随机数构造对称加密对传输内容进行加密传输

4、中间人因为拥有客户端的随机数，可以通过对称加密算法进行内容解密

5、中间人以客户端的请求内容再向正规网站发起请求

6、因为中间人与服务器的通信过程是合法的，正规网站通过建立的安全通道返回加密后的数据

7、中间人凭借与正规网站建立的对称加密算法对内容进行解密

8、中间人通过与客户端建立的对称加密算法对正规内容返回的数据进行加密传输

9、客户端通过与中间人建立的对称加密算法对返回结果数据进行解密

之所以出现这种状况，是因为：

1、客户端不知道自己的信息被拦截了

2、客户端完全无法验证证书的真假

所以，用了HTTPS一样会被抓包，HTTPS无法防止被抓包，只能防止用户在不知情的状态下通信被监听。

如果用户主动信任网站，那么数据一样会被「中间人」窃取。

尽管HTTPS仍然不够安全，但它至少比HTTP啥都不穿裸奔还是要强一些的。所以下面就来演示一下怎么给SpringBoot添加HTTPS服务。

先创建证书：

keytool -genkey -alias https -keyalg RSA -keysize 2048 -keystore key.p12 -validity 90

再修改SpringBoot的配置，在application.properties配置文件中加上：

server.ssl.key-store=/Users/bear/key.p12

server.ssl.key-store-password=123456

server.ssl.key-store-type=PKCS12

server.ssl.key-alias=https

然后启动SpringBoot服务。通过Postman访问，发现报错：

Bad Request

This combination of host and port requires TLS.

先导出公钥：

openssl pkcs12 -in key.p12 -clcerts -out public_key.pem

再导出私钥：

openssl pkcs12 -in key.p12 -nodes -out private_key.pem

然后再修改Postman配置：

再次运行Postman测试，功能正常实现。

---

感谢您的大驾光临！咨询技术、产品、运营和管理相关问题，请关注后留言。欢迎骚扰，不胜荣幸～

​