HTTPS_SSL加密(HTTP终)

简介: HTTPS_SSL加密(HTTP终)

HTTPS

我们刚刚学完HTTP,咋有来了一个HTTPS呀,这和HTTP有啥关系么?

image.png

我们知道HTTP是用户层协议,是由业界大佬编写的协议模板供我们使用,我们来看看 HTTP存在的问题!


当我们客户端用户要下载一个天天动听app时,因为我们网络传输数据要经过很多中间设备,其中就肯定要经过运营商设备,毕竟这些网络设施都是由他们搞的!当你的http请求通过他们的设备时,他们就可以拿到你的请求,你本来是想下载天天动听的,他就给你返回了一个QQ浏览器,挣你流量,恰烂钱!

我们如何避免这个信息暴露问题呢?

我们知道这里最大的问题就是除了服务器和客户端中间网络传输设备都可以读取到里面的数据内容,就好比传纸条!

我们可以对数据加密!

SSL/TLS

我们就将HTTP进行了升级,引入了SSL加密层!这就是我们的HTTPS!

加密方式:

1.对称加密!

2.非对称加密!


对称加密

如何对数据进行加密呢?


明文: 就是我将我们的数据不进行任何处理直接传输!

密文: 密文通过某种加密方式(密钥)将明文进行加密后传输!

密钥: 通过这里的密钥可以将明文和密文进行转换!


我们可以联系实际生活,这里的密钥就相当于钥匙,通过钥匙我们的客户端和服务器都可以对锁进行解锁操作!


我们的HTTP也是通过这里的密钥进行加密!

对称加密就是通过一个密钥将数据报进行加密操作,然后客户端话服务器通过这个共有的秘钥可以对数据报进行加密和解密!

image.png

这里通过将密钥,双方共享,服务器和客户端就可以都数据报进行加密解密操作!


密钥传输

image.png

现在又有一个问题就是我们的秘钥也是需要进行网络传输的,也就会被中间有些设备拿到!中间设备拿到后,也可以对数据进行解密操作,所以白加密了!


还有就是这里密钥肯定要每一台客户端拥有不一样的密钥,然后将密钥给服务器!如果大家共用一个密钥的话,你想知道密钥开一台客户端就好了!

非对称加密

对称加密存在的问题就是密钥会被其他设备拿到!

我们可不可以对密钥进行加密就解决了这个问题!

这时就引入了非对称加密方式!!

非对称加密就是套娃!我们再给密钥加上一把锁!


这里就引入了私钥和公钥:


公钥:服务器和客户端大家共享的密钥,通过这个密钥可以对对称密钥进行加密!

私钥:只有自己知道的密钥,通过这个密钥可以对对称密钥进行解密操作!

这里我们的公钥,服务器和客户端都会生成一个公钥,然后将公钥发出去,然后大家都拿到了这个公钥,然后私钥留着!然后当服务器和客户端生成一个对称密钥后,会将该对称密钥用这个公钥进行加密后发送,然后我们拿到数据报和加密后的对称密钥后,通过私钥对已经加密后的对称密钥进行解密,拿到对称密钥,然后通过对称密钥对数据报进行解密操作!


可能看完有点头大,就类似一个信箱,我们给邮递员一把锁(公钥),然后邮递员将信(对称密钥)放入信箱后,将信箱锁上(通过公钥对对称密钥进行加密),然后用户通过钥匙(私钥)将信拿到!

image.png


我们一开始将公钥发出去,如果要进行对称密钥传输,就应该事先通过公钥对对称密钥进行加密后再进行传输!而这时中间设备拿到加密后的对称密钥和公钥也无济于事!公钥只能用来加密操作,不能解密!

然后我们的另一方拿到加密后的对称密钥后通过自己私有的私钥对对称密钥进行解密!然后就可以对数据报文进行解密操作了!


重点就是: 公钥(发出去)只能对对称密钥进行加密,私钥自己留着,用来对对称密钥解密!


难道这样就安全了嘛?如果有中间设备自己搞个公钥和私钥冒充会怎么样?

image.png



上面的过程就是中间人攻击,就是被黑客入侵的网络设备,会自己生成假冒公钥和私钥,黑客收到服务器发来的公钥后保存,将自己的公钥发个客户端,然后客户端将对称密钥用黑客的公钥加密,发个黑客,黑客通过自己的私钥解密,然后通过服务器的公钥进行加密发给服务器,如假包换!!!


中间人攻击如何解决呢?


这里存在的问题就是我们无法知道公钥到底是冒充的还是真的!

只要我们可以确定公钥的真实性,就可以解决这个问题!

我们联系实际生活,我们是如何确定一个人的身份呢?

我们可以通过这个人的身份证!

身份证可以造假,就想公钥可以冒充一样,但是我们可以通过身份证在公安区登记的信息,就可以知道这个身份证的真实性!

所以我们这里也是如此,我们引入了第三平台,通过这个第三平台给的证书,就可以保证这里公钥的真实性!

image.png

我们通过这个公证机构就可以避免中间人攻击了

当创建一个服务器后就去这个公证机构登记(类似人一出生就去登记信息),然后将这个公钥数据放在这个证书里发送(类似身份证),客户端拿到证书后去公证机构验明身份!然后再使用加密操作!

这里天天访问公证机构有点繁琐,使用在操作系统内部就有这个公证机构的认证方式,就可以进行本地认证!

目录
相关文章
|
19天前
|
缓存 网络协议 算法
(二)Java网络编程之爆肝HTTP、HTTPS、TLS协议及对称与非对称加密原理!
作为一名程序员,尤其是Java程序员,那必须得了解并掌握HTTP/HTTPS相关知识。因为在如今计算机网络通信中,HTTP协议的作用功不可没,无论是日常上网追剧、冲���、亦或是接口开发、调用等,必然存在HTTP的“影子”在内。尤其对于WEB开发者而言,HTTP几乎是每天会打交道的东西。
45 10
|
3天前
|
安全 Nacos 数据安全/隐私保护
【技术干货】破解Nacos安全隐患:连接用户名与密码明文传输!掌握HTTPS、JWT与OAuth2.0加密秘籍,打造坚不可摧的微服务注册与配置中心!从原理到实践,全方位解析如何构建安全防护体系,让您从此告别数据泄露风险!
【8月更文挑战第15天】Nacos是一款广受好评的微服务注册与配置中心,但其连接用户名和密码的明文传输成为安全隐患。本文探讨加密策略提升安全性。首先介绍明文传输风险,随后对比三种加密方案:HTTPS简化数据保护;JWT令牌减少凭证传输,适配分布式环境;OAuth2.0增强安全,支持多授权模式。每种方案各有千秋,开发者需根据具体需求选择最佳实践,确保服务安全稳定运行。
16 0
|
4天前
|
安全 网络协议 搜索推荐
http和https分别是什么?区别是什么?
http和https分别是什么?区别是什么?
9 0
|
5天前
|
SQL 安全 Java
驱动程序无法通过使用安全套接字层(SSL)加密与 SQL Server 建立安全连接。错误:“The server selected protocol version TLS10 is not accepted by client
驱动程序无法通过使用安全套接字层(SSL)加密与 SQL Server 建立安全连接。错误:“The server selected protocol version TLS10 is not accepted by client
34 0
|
10天前
|
运维 安全 网络协议
运维.索引引擎ElasticSearch.记录一个小异常:received plaintext http traffic on an https channel
运维.索引引擎ElasticSearch.记录一个小异常:received plaintext http traffic on an https channel
27 0
|
11天前
|
安全 网络安全 数据安全/隐私保护
[flask]使用mTLS双向加密认证http通信
[flask]使用mTLS双向加密认证http通信
|
11天前
|
网络协议 应用服务中间件 Go
[golang]使用mTLS双向加密认证http通信
[golang]使用mTLS双向加密认证http通信
|
17天前
|
Java Android开发 UED
安卓scheme_url调端:如果手机上多个app都注册了 http或者https 的 intent。 调端的时候,调起哪个app呢?
当多个Android应用注册了相同的URL Scheme(如http或https)时,系统会在尝试打开这类链接时展示一个选择对话框,让用户挑选偏好应用。若用户选择“始终”使用某个应用,则后续相同链接将直接由该应用处理,无需再次选择。本文以App A与App B为例,展示了如何在`AndroidManifest.xml`中配置对http与https的支持,并提供了从其他应用发起调用的示例代码。此外,还讨论了如何在系统设置中管理这些默认应用选择,以及建议开发者为避免冲突应注册更独特的Scheme。
|
Web App开发 存储 前端开发
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html><head><meta http-equiv="Cont
      前段时间公司hadoop集群宕机,发现是namenode磁盘满了, 清理出部分空间后,重启集群时,重启失败。 又发现集群Secondary namenode 服务也恰恰坏掉,导致所有的操作log持续写入edits.new 文件,等集群宕机的时候文件大小已经达到了丧心病狂的70G+..重启集群报错 加载edits文件失败。
887 0
|
Web App开发 前端开发
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html><head><meta http-equiv="Cont
异步通信 对于BS(Browser-Server 浏览器)架构,很多情景下server的处理时间较长。 如果浏览器发送请求后,保持跟server的连接,等待server响应,那么一方面会对用户的体验有负面影响; 另一方面,很有可能会由于超时,提示用户服务请求失败。
751 0