HTTPS 协议:点外卖的过程原来这么麻烦

    技术2023-05-30  26

    用 HTTP 协议,看个新闻还没有问题,但是换到涉及财务交易场景中,就存在很多的安全风险。例如,要下单支付,你发送一个点外卖的请求,这个网路包被截获了,若在服务器恢复你之前,黑客假装自己是外卖网站,然后给你回复一个假消息:“银行卡号,密码”。这时候发过去不就出事了?

    怎么解决这个问题呢?一般的思路就是加密。加密分为两种方式一种是对称加密,一种是非对称加密。

    在对称加密算法中,加密和解密使用的密钥是相同的。也就是说,加密和解密使用的是同一个密码。因此,对称加密算法要保证安全性的话,密钥要做好保密。不能对外公开。

    在非对称加密算法中,加密使用的密钥和解密使用的密钥是不相同的。一把是作为公开的公钥,另一把是作为谁都不能给的私钥。公钥加密的信息,只有私钥才能解密。私钥加密的信息,只有公钥才能解密。

    因为对称加密算法相比非对称加密算法来说,效率要搞很多,性能也好,所以交互的场景下多用对称加密。

    对称加密

    假如你和外码网站约定了一个密钥,发送请求的时候对这个密钥进行加密,外卖网站用同样的密钥进行解密。这样就算中间的黑客获取了你的请求,但是它没有密钥,还是无法破解。

    这看起来比较完美,但是中间有个问题,两个怎么约定这个密钥呢?如果这个密钥在互联网上传输,也是很有可能被截获,一旦截获它黑客可以佯作不知,静静等你们交互,这个时候你们之间互通的任何消息,它都能截获并查看,就等你把卡号和密码发出来。

    我们在谍战剧中常看特工破译密码会有密码本,截获无线电台,通过密码本破译。怎么把密码本给对方呢?只能通过线下传输。

    那如果外卖网站和你偷偷约定时间地点,它给你一个纸条上面写着你们的密钥,然后说以后用这个密钥在网上来订外卖。当然你们接头的时候也会对口号才会给纸条。但是口号也是对称加密密钥,同样存在问题。在互联网中,客户那么多,这样是不现实的。

    非对称加密

    所以,只要是对称加密,就会永远陷入死循环,这时候就需要非对称加密算法接入进来。

    非对称加密的私钥放在外卖网站,不会再互联网上传输,这样就能保证这个密钥的私密性。但是,对应私钥的公钥,是可以再网上随意传播的,只要外卖网站把这个龚涛给你,你们就可以愉快交互了。

    比如你用公钥加密,说:“我要点外卖”,黑客在中间就算截获了这个报文,因为它没有私钥是解不开的,所以这个报文可以顺利到达外卖网站,外卖网站用私钥把这个报文解出来,然后回复:“那给我银行卡和支付密码吧” 。

    当然,回复的这句话,是外卖网站拿私钥加密的,互联网上人人都可以打开。那外卖网站可以拿公钥加密码?当然不能,因为它自己的私钥只有自己知道,谁也解不开。另外,这个过程还有一个问题是,黑客也可以模拟发送 “我要定外卖” 这个过程的,因为它有外卖网站的公钥。

    为了解决这个问题,看来一对公钥私钥是不够的,客户端也需要有自己的公钥和私钥,并且客户端要把自己的公钥,给外卖网站。

    这样,客户端给外卖网站发送的时候,用外卖网站的公钥加密。而外卖网站给客户端发送消息的时候,使用客户端的公钥。这样就算有黑客企图模拟客户端获取一些信息,或者半路截获回复信息,由于他没有私钥,这些信息还是打不开。

    数字证书

    不对称加密会有同样的问题,如何将不对称的公钥传给对方呢?一种是放在一个公网的地址上,不让对方下载;另一种是简历连接的时候传递给对方。

    这两种方法有相同的问题,作为一个普通网民如何鉴别公钥是对的?毕竟每个人都可以创建自己的公钥和私钥。

    这个时候就需要权威部门的介入,就像每个人都可以打印自己简历,说自己是谁,但是又公安局盖章的,就只有户口本才能证明是你,这个由区纳维部门颁发的称为证书。

    整数里由公钥、所有者还有有效期,可以类比户口本。那如何生成证书呢?生成证书需要发送一个证书请求,然后将这个请求发给一个权威机构去认证,这个权威机构就是 CA(Certifcate Authority)。收到后权威机构会给这个证书卡一个章,称为签名算法。如何保证签名是真的权威机构签名呢?这要用到 CA 私钥。

    签名算法大概是这样的:一般是对信息做一个 Hash 计算,得到一个 Hash 值,这个过程是不可逆的,也就是无法通过 Hash 值得到原来的信息内容。在把信息发送出去时,把这个 Hash 值加密后,作为一个签名和信息一起发出去。

    HTTPS 的工作模式

    非对称加密在新能上不如对称加密,那是否能将两者结合?如公钥私钥主要用于传输对称加密的密钥,而真正的双方大数据量的通信都是通过对称加密进行的。这个就是 HTTPS 协议的总体思路。 当登录外卖网站时,由于是 HTTPS,客户端会大宋 Client Hello 消息到服务器,以铭文传输 TLS 版本信息、加密套件候选列表、压缩算法候选列表等信息。灵位,还会由一个随机数,在协商对称密钥的时候使用。

    好比:“我想点外卖,但你要对我的饮食保密。这是我的加密套路,在给你一个随机数,你留着。” 然后外卖网站返回 Server Hello 消息,告诉客户端,服务器选择使用的协议版本、加密套路、压缩算法等,还有一个随机数,用于后续的密钥协商。好比说:“你好,没问题,咱们按套路来,我这个随机数你也留着。”

    然后外卖网站会给你一个服务端的证书,然后说:“Server Hello Done,我这里就这些信息了。” 你当然不相信这个帧数,于是你从自己信任的 CA 仓库中,拿 CA 的证书里面的公钥去解密外卖网站的证书。如果能够成功,则说明外卖网站是可信的。这个过程中,你可能会不断网上追溯CA、CA的CA的CA,反正直到一个授信的 CA,就可以了。

    证书验证完毕之后,觉得这个外卖网站可信,于是客户端产生随机数字 Pre-master,发送 Client Key Exchange,用证书中的公钥加密,再发送给服务器,服务器可以通过私钥解密出来。

    到目前位置,无论是客户端还是服务器,都有了三个随机数,分别是:自己的,对端的,以及刚生成的 Pre-Master 随机数,通过这个三个随机数,可以在客户端和服务端产生相同的对称密钥。有了对称密钥,客户端就可以说:“Change Cipher Spec,咱们以后都采用协商的通信密钥和加密算法进行加密通信了。”

    然后发送一个 Encryted Handshake Message,将自己已经商定好的参数等,采用协商密钥进行加密,发送给服务器用于数据与握手验证。同样,服务器哦也可以发送 Change Cipher Spec,说:“没问题,咱们以后都采用协商的通信密钥和加密算法进行通信了”,并且也发送 Encryted Handshake Message 的消息试试。

    当双发握手结束之后,就可以进行加密传输了。合格过程除了加密解密之外,其他的过程和 HTTP 是一样的。并且上面只包含了 HTTPS 的单向认证,也即客户端验证服务端的证书,是大部分场景,也可以在更加严格安全的情况下,启用双向认证,双方互相验证证书。

    EOF 《趣谈网络协议》笔记

    Processed: 0.013, SQL: 8