[JavaEE初阶]HTTPS-SSL传输过程中的加密

HTTPS=HTTP+S(SSL/TLS)

SSL也是一个应用层协议,专门负责加密

之前我们说过的运营商劫持就是一个传输过程的网络安全问题

  • 之所以运营商能劫持,是因为在HTTP中,数据都是"明文"传输的(谁都能看到)
  • 解决方法:把数据继续加密,通过密文来传输
  • 明文->加密->密文
  • 密文->解密->明文

例如洋务运动中,恭亲王奕䜣通过密文给老佛爷传信

  • 左边是明文,右边是密文
  • 这张带窟窿的纸,在加密和解密的过程中起到了重要作用->密钥
    HTTPS加密和解密关键在于密钥

密钥的两种方式:

  • 对称密钥:加密和解密使用同一个密钥
  • 非对称密钥:加密使用一个密钥A,解密使用另一个密钥B(密钥A和B之间存在关联关系,但很难猜出来)

非对称密钥:

  • 把其中一个密钥公开出去->"公钥"(谁都能知道)
  • 把另一个密钥自己保存好->"私钥"(谁都不能告诉)
  • 如果用公钥加密,那就要用私钥解密
  • 如果用私钥加密,那就要用公钥解密

HTTPS工作原理:

long long ago~网络上的数据是明文传输的:

引入对称加密(对称密钥)

客户端和服务器最开始通信的时候,就需要一方生成唯一的密钥,再通过网络传输给另一方(要注意的是:密钥本身是明文传输的)

密钥具体是个啥形式?

  • 可以认为是一个很长字符串
  • 有二进制形式的也有文本的,要看具体的加密算法->形式是可以灵活调整的

假设客户端生成对称密钥:

由此可见,我们就需要对密钥进行加密

  • 如果仍然使用对称加密的方式->生成一个对称密钥key2 来对key进行加密->key就可以密文传输给服务器了
  • 但是key2还是得传给服务器呀,难道搞一个key3来对key2进行加密吗???
  • 无论套多少层,总有一层需要明文传输
    因此我们就引入了非对称加密.

非对称加密:

就是为了解决密钥传输的安全性问题

公钥是一把锁,私钥是对应的钥匙:

你以为这就万无一失了???

->NO! 上述方案存在严重漏洞!

有人说,全部使用非对称加密不行吗?

  • 对称加密,运算速度快,开销小,适合对大量数据进行加密
  • 非对称加密,运算速度慢,开销大->加密小数据还行,加密大量数据会非常耗时~

私钥和公钥的生成:

  • 数学上,针对两个非常大的素数做乘积->很容易
  • 但是根据乘积 解出这两个大素数->很难
  • 这两个大素数就是这一对公钥私钥

至于后续如何,且听下回分解~

END✿✿ヽ(°▽°)ノ✿

相关推荐
AlfredZhao2 天前
生产环境里,为什么不建议把普通端口直接暴露到公网?
linux·https·443·80
Avan_菜菜7 天前
FRP 内网穿透完整实战:从 HTTP 映射到 HTTPS 自签代理
运维·nginx·https
程序员mine13 天前
HTTPS-TLS加密与证书完全指南(中)
网络协议·https·ssl
程序员mine13 天前
HTTPS-TLS加密与证书完全指南(上)
网络协议·https
我登哥MVP13 天前
SpringCloud Alibaba 核心组件解析:服务链路追踪
java·spring boot·后端·spring·spring cloud·java-ee·maven
程序员mine13 天前
HTTPS-TLS加密与证书完全指南(下)
网络协议·http·https
Cc_Debugger13 天前
开发环境使用https配置
javascript·vue.js·https
我命由我1234513 天前
Jetpack Room - Room 查询返回列表无需判空、LIKE 关键字
android·java·开发语言·java-ee·android jetpack·android-studio·android runtime
Hadoop_Liang13 天前
Kubernetes 应用 HTTPS 安全访问配置实践
https·kubernetes
开发者联盟league13 天前
pnpm install报错ERR_SSL_PACKET_LENGTH_TOO_LONG问题解决
网络·网络协议·ssl