世界报道:加解密与HTTPS(6)

2023-01-08 19:22:45 来源:51CTO博客

您好,我是湘王,这是我的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测试,功能正常实现。


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

标签: 加密算法 冒名顶替 数据传输

上一篇:nginx 代理转发 传递真实 ip 地址
下一篇:世界讯息:如何利用filebeat把不同服务器上的log4j日志传输到同一台ELK服务器