HTTPS的工作过程

1.HTTPS协议原理

1.1HTTPS协议的由来

HTTP在传输网络数据的时候是明文传输的,信息容易被窃听甚至篡改,因此他是一个不安全的协议(但效率高)。在如今的网络环境中,数据安全是很重要的(比如支付密码又或者各种私密信息等)因此,为了解决这一安全问题HTTPS由此诞生。HTTPS(Hyper Test Transfer Protocol Secure)在HTTP的基础上加入了SSL/TLS加密机制,通过对传输数据的加密,来确保数据传输过程中的安全性,从而降低信息被窃听和篡改的风险,进而确保用户数据的安全,他是目前网络上应用最广泛和安全的协议。

臭名昭著的"运营商劫持"

下载一个"天天动听"

未被劫持的效果,点击下载按钮,就会弹出天天动听的下载链接

已被劫持的效果,点击下载按钮就会弹出QQ浏览器的下载链接

由于我们通过网络传输数据的任何数据包都会经过运营商的网络设备(路由器,交换机等),那么运营商的网络设备就可以解析出你的数据内容,并进行篡改。

很明显这背后存在某种交易~~ 这时候加密就是一种重要的手段

1.2怎么样才能做到传输安全

首先,网络传输的数据要具有安全性,要保证数据安全,最核心的要点就是"加密",

黑客领域的攻防都是"相对" 的概念~~对抗过程~~

但是可以做到,即使数据被黑客拿到了,他也解析不了、无法篡改~~也能起到安全的效果~~

加密来做到~~
你加密的数据,理论上来说,也有可能被黑客破解~~

加密的成本很低,破解的成本很高~~

只要破解的成本,超出了要保护数据本身的价值,就是安全的!!
加密对称:加密和解密,使用的是同一个密钥。
非对称加密:加密和解密,使用的是两个密钥 这两个密钥,k1和k2是成对的,可以使用k1来加密,此时就是k2解密;也可以使用k2来加密,此时就是k1解密。

这个特性的背后有一系列的数学原理~~

两个密钥,就可以一个公开出去,称为"公钥",另一个自己保存好,称为"私钥"(手里只有一把的话,是无法知道另一把是啥的)。

1.3HTTP和HTTPS的选择

上述说HTTP是明文传输数据的,即HTTP不会对数据进行保护(加密/解密)那么另一种意思也就是说:HTTP在传输数据时,会做的事情比较少,因此他的效率相比于HTTPS是高的。

因此,一般情况下,如果网络环境比较安全,比如在公司的内网中传输数据,可能会优先使用HTTP以此来提高数据传输的效率和降低传输延迟。另一种就是对数据机密性和完整性比较高的要求时,就会优先使用HTTPS协议,来确保数据在传输的过程中安全。

总而言之,HTTP和HTTPS的选择要根据环境而定。

2.HTTPS工作过程

只要针对HTTPS的数据进行解密了,就能够得到HTTP格式数据。

1.1中所述的运营商劫持,无论是修改referer还是修改返回的链接(body),本质上都是明文传输惹的祸。这是就需要引入加密,对上诉传输数据进行保护~~ 主要是针对header和body进行加密~

加密的方式有很多,但整体可以分成两大类:对称密文非对称密文

2.1引入对称加密

通过对称加密的方式,针对传输的数据进行加密操作。

1.对称加密的时候,客户端和服务器需要使用同一个密钥。

2.不同的客户端,需要使用不同的密钥。

(如果所有客户端的密钥都相同,加密如同虚设,黑客很容易拿到密钥)

这就意味着每个客户端连接服务器的时候,都需要自己生成一个随机的密钥,并且把这个密钥告知服务器,(也不应定是客户端生成,服务器也行,也是需要告诉客户端的)

这就是问题的关键!!!密钥需要传输给对方的,一旦黑客拿到了这个密钥,意味着加密操作就无意义了~~

这里我们需要考虑,针对咱们的密钥,也进行密文传输~~

假设使用对称加密,引入key2针对key进行加密,意味着需要把++key2++也传输给服务器,服务器才能解密拿到key~~ (但是key2还是可能被黑客拿到~~)

2.2引入非对称加密

使用非对称加密,主要目的就是为了对对称加密进行加密,确保对称密钥的安全性~~

不能使用非对称加密,针对后续传输的各种header body等进行加密,而是只能使用非对称加密去加密对称密钥~~(非对称加密的加密解密成本(消耗CPU资源)钥远远高于对称加密)

少来少去的用点都可以,如果大规模使用,就难以承担了~~

此处就让服务器持有私钥(只有服务器知道)客户端持有公钥(黑客也能知道)

客户端就可以使用公钥,对已生成的对称密钥进行加密~~
黑客虽然手里有公钥,但是密文需要通过私钥才能进行解密,私钥黑客拿不到~~

黑客就无法对这个数据解密,也就不能拿到888888对称密钥了~~

只要888888安全到达服务器,后续服务器和客户端之间就可以使用888888作为对称加密的密钥,此时黑客就无法破解后续的数据了~~

此处的公钥 私钥也可以这样理解

有些老的住房有信箱

你手里有信箱钥匙(私钥),邮递员手里有锁头(公钥)~~
**流程:**服务器生成一对非对称密钥,私钥服务器自己持有,公钥则可以告知任何的客户端。

客户端在连接上服务器之后,就需要先从服务器这边拿到公钥(公钥本身就可以公开出去,不需要加密传输)客户端生成对称密钥,拿着公钥对 对称密钥进行加密。

此时就可以把加密后的密文进行传输了,由于想要解密,必须通过私钥,而私钥只有服务器自己知道,此时这样的加密数据就可以比较安全的到达服务器了

服务器通过私钥解密之后得到了对称密钥,接下来和客户端之间的通信就通过对称加密来完成了。

此时黑客拿到的是一个key加密后的结果,此时黑客要是想要解密,需要知道pri,而pri私钥只要服务器自己知道,黑客拿不到。(黑客监听中间的通信数据,要比黑入服务器这边容易一些,如果都能黑进服务器了,大概就可以直接拖数据库了,用户信息都被拿到了)

SSL内部完成工作,使用HTTPS的时候,底层也是TCP,先进行TCP三次握手,TCP连接打通之后,就要进行SSL的握手了(交换密钥的过程)后面才是真正传输业务数据(完整HTTP的请求响应了)

2.3仍然存在问题

上述操作,仍然存在重大的安全漏洞,黑客仍然是有办法获取到对称密钥key的~ 中间人攻击

针对上述问题,如何解决?

最关键的一点,客户端拿到公钥的时候,要能有办法验证,这个公钥是否是真的,而不是黑客伪造的。要求服务器这边要提供一个"证书"

证书是一个结构化的数据(里面包含很多属性,最终以字符串的形式提供)

证书中会包含一些列的信息。

比如,服务器主域名,公钥,证书有效期.......

证书是搭建服务器的人,要从第三方的公正机构进行申请的~~(申请的时候当然要提交材料,人家审核)

2.4证书

证书验证过程~

证书:

服务器的域名....

证书的有效时间......

服务器的公钥.......

公证机构的信息.....

...................

++证书的签名.....++

||

颁布证书的公正机构 会在发布证书的时候,给这个证书计算出一个校验和

然后公证机构使用自己的私钥(和服务器的私钥无关)针对校验和进行加密,此时就得到了证书的签名。
此处所谓的"签名"本质上是一个经过加密的校验和!! 把证书中其他的字段通过一系列的算法(CRC,MD5等)得到一个较短的字符串 ==> 校验和 如果两份数据内容一样,此时的校验和就一定是相同的;如果校验和不同,两份数据的内容则一定不同(逆否命题)

客户端拿到证书以后,主要做两件事:

1.按照同样的校验和算法,把证书的其他字段都重新算一遍,得到校验和1;

2.使用系统中内置的公证机构公钥,对证书的签名进行解密,得到校验和2;

此时,就可以对比,看这俩校验和是否一致!!

如果一致,说明证书是没有被修改过的,就是原版证书。

如果过不一致,说明证书被别人篡改过了(比如黑客如果替换了自己的公钥,此时算出来的校验码就一定改变)

此时客户端就能识别出来了!!

黑客无法修改证书中的内容!!

**1.**如果黑客直接修改公钥,不能改签名。

此时客户端校验和是一定不一样的,就识别出来了

2.如果黑客修改公钥,也尝试重新生成签名~~

如果黑客不知道公证机构的私钥,所以黑客无法重新生成加密签名~~

如果黑客拿自己的私钥加密呢??客户端这边拿着公证机构的公钥也会解密失败~~

上述操作就把黑客篡改证书的行为给堵死了

3.黑客能不能自己也去公证机构申请个证书??然后把自己的证书替换掉服务器的证书呢??

还是不行

域名是唯一的!!黑客申请的证书的域名,和服务器的域名肯定不同!!

客户端拿到证书之后,一看到域名都不一样,直接就知道证书是假冒的,都不用校验和了

当然,上述的讨论过程,所谓的安全,也不是绝对安全的,上述的安全本质上都是基于非对称加密体系,非对称加密体系,也不是无懈可击的,只不过破解这样的加密体系,需要的计算量非常大,超出了现有计算机的算力上限!!

当然以后随着算力的提升,尤其是量子计算机崛起,我们的算力又会大幅度的提升,对象有点密码学体系就会造成重大冲击~~

相关推荐
光明编码使者22 分钟前
WebSocket 与 Server-Sent Events (SSE) 的对比与应用
网络·websocket·网络协议
文中金域22 分钟前
websocket 服务 pinia 全局配置
网络·websocket·网络协议·vue
p-knowledge1 小时前
容器设计模式:Sidecar
网络协议·设计模式·rpc
玩电脑的辣条哥2 小时前
语音识别失败 chrome下获取浏览器录音功能,因为安全性问题,需要在localhost或127.0.0.1或https下才能获取权限
前端·chrome·https
earthzhang20212 小时前
《深入浅出HTTPS》读书笔记(19):密钥
开发语言·网络协议·算法·https·1024程序员节
PandaCave2 小时前
了解https原理,对称加密/非对称加密原理,浏览器与服务器加密的进化过程,https做了些什么
服务器·网络·https·密码学
Qfuuu4 小时前
Linux Posix API与网络协议栈知识总结
linux·网络协议
catoop5 小时前
使用 acme.sh 签发和自动续期 ssl https 证书
https·ssl
我真不会起名字啊5 小时前
RPC远程服务调用详解和gRPC简介
网络·网络协议·rpc
码上一元5 小时前
RPC 服务与 gRPC 的入门案例
网络·网络协议·rpc·grpc