当前位置: 首页 > 后端技术 > PHP

网络协议13-HTTPS协议:无尽的加密之路

时间:2023-03-30 05:44:00 PHP

系列文章传送门:网络协议1-网络协议概述2-IP是怎么来的,为什么消失了?网络协议3-从物理层到MAC层网络协议4-交换机和VLAN:办公室太复杂,我要回学校了网络协议5-ICMP和ping:问路的童子军网络协议6-路由协议:敢问路在何方?NetworkProtocol7-UDPProtocol:一个好人可以在城市玩NetworkProtocol8-TCPProtocol(Part1):如果一个人是坏人,他必须遵循一个套路DeepNetworkProtocol9-TCPProtocol(Part2):Clear而不是被误解网络协议10-Socket编程(上):实践是检验真理的唯一标准网络协议11-Socket编程(下):眼见为实,耳闻为虚网络协议12-HTTP协议:常用但不简单它依然伴随着互联网,陪伴着我们风风雨雨将近二十年。现在有很多新的协议试图取代它来解决性能、效率等问题,但它仍然可以靠“多年的爱”来生存。但近年来,由于致命的安全问题,不得不升级为HTTPS。以我们点外卖为例。我们订购的数据包被黑客截获,然后在服务器回复之前给你发了一条假消息:“好的,你该付款了,请带上你的银行卡号和密码。”,这时候,如果你真的把卡号和密码发给他,那你的钱包就真的有危险了。为了解决这些问题,我们给HTTP引入了加密,变成了HTTPS。不要以为HTTPS是一个新的协议,它其实是:HTTPS=HTTP+SSL层这里SSL层的主要工作就是加密。加密方式一般分为对称加密和非对称加密两种。对于这两种加密算法,对称加密的效率和性能要比非对称加密高很多,所以在交互场景中经常使用对称加密。对称加密在对称加密算法中,加密和解密的密钥是相同的。即加密和解密使用同一个密钥。因此,用户一定要做好保密工作,不能让第三方知道。假设你和第三方约定了一个密钥A,你发送请求的时候用A加密,外卖网站也用A解密,这样即使黑客拦截了你的请求,但是没有正确的密钥,仍然无法破解。看起来是解决黑客问题的好方法。但是这里还有一个问题,你和外卖网站怎么约定这个key呢?如果这个密钥在互联网上传输,它必须用B密钥加密。否则,如果A被黑客获取了,你的交互还是不安全的。此外,您如何同意B?所以只能线下传输。线下传播,看过《肖申克的救赎》的博主应该知道,安迪越狱前约了瑞德,让他去取一个写着住所的信封。那我们和外卖网站也可以用这种风骚的操作,偷偷约定好时间地点,给你一张纸条,上面有你们两个的钥匙,然后用这个钥匙点餐在互联网上。停,停,上面的操作简直不敢相信。如果最初的互联网发展成这样,我相信它活不了多久。相信你也发现了,只有对称加密才会陷入密钥安全问题的死循环。这时候就需要非对称加密了。非对称加密在非对称加密中,加密和解密过程中使用了两个不同的密钥。一个是公钥,一个是没有人会给出的私钥。用公钥加密的信息只能用私钥解密,用私钥加密的信息只能用公钥解密。在外卖点餐过程中,非对称加密的私钥由外卖网站保存,不会在线传输,保证了私钥的私密性。相应的公钥可以在互联网上自由传播。只要外卖网站给你这个公钥,你就可以安全通信了。我们来看看点外卖的流程。我们用公钥加密,说“我要豆浆和油条”。黑客在中途截获了数据包,但他没有私钥,无法解密数据,所以可以顺利到达外卖网站。外卖网站用私钥解密消息,然后回复:“我知道了,你可以支付,把卡号和密码给我。”整个过程好像很安全,再也不怕黑客了。不过,也不要太乐观,你的银行卡是安全的,但外卖网站还是有危险的。黑客拥有外卖网站的公钥,可以模拟发送消息“我要订外卖”。为了解决这个问题,似乎一对公钥和私钥是不够的。客户端还需要有自己的公钥和私钥,客户端也需要把自己的公钥给外卖网站。这样,客户端向外卖网站发送信息时,使用外卖网站的公钥加密,外卖网站向客户端发送消息时,使用客户端的公钥。这样,即使黑客试图模拟客户端获取一些信息,或者中途拦截回复信息,但由于没有私钥,仍然无法打开这些信息。说了这么多,相信大家也发现了非对称加密也会有同样的问题。如何把非对称加密的公钥给对方?这时候有两种可行的方式,一种是放到公网地址让对方下载,另一种是建立连接的时候传给对方。两种方法都有同样的问题。作为一名普通网民,你如何认定别人给你的公钥是对方的,而不是被黑客冒充的呢?你应该知道每个人都可以创建自己的公钥和私钥。创建过程如下:#bash//创建私钥:opensslgenrsa-outhttpsprivate.key1024//根据私钥获取公钥opensslrsa-inhttpsprivate.key-pubout-outhttpspublic.pemHTTPScertificate可以看到,通过工具,我们可以很容易的创建公钥和私钥,所以黑客也可以创建。我们如何知道外卖网站发送的公钥是否真实?外卖网站呢?这时候就需要第三方机构来充当中间人。这就像我们的户口本。大家可以打印出来说是真的户口簿,但是去用的时候,人们只认得是公安局盖章的户口簿。这种由权威机构颁发的证书称为证书(Certificate)。HTTPS证书应该包含以下内容:公钥:这个最重要;owner:说明证件属于谁,就像户口本上的姓名和身份证号一样,证明户口本是你的;发证机构:看看你的户口本上有没有某某公安局?证书有效期:这个和我们身份证的有效期是同一个意思。说完了证书的内容,就该进入下一步了,如何获取证书呢?就好比给家里添了一个小公馆,去哪里登记?去公安局恐怕大家都知道。相应的,HTTPS也有一个组织负责颁发证书,我们称之为CA(CertificateAuthrity)。可以通过以下命令生成证书:opensslreq-keyhttpsprivate.key-new-outhttpscertificate.req将这个请求发送给CA,CA会在证书上“盖章”,我们称之为签名算法。这个签名是用CA的私钥签发的,保证签名不能被伪造。签名算法是这样的:一般是对信息进行Hash计算,得到一个Hash值。这个过程是不可逆的,也就是说无法通过哈希值还原出原始的信息内容。信息发出时,将上面得到的Hash加密,作为签名与信息一起发送。CA对一个整数进行签名的命令是:opensslx509-req-inhttpscertificate.req-CAcacertificate-pem-CAkeycaprivate.key这个命令会返回Signatureok,httpscertificate.pem就是有符号的整数。CA用自己的私钥对外卖网站的公钥进行签名,相当于对外卖网站进行了背书,形成了外卖网站的证书。我们可以通过以下命令查看证书的内容:opensslx509-inhttpscertificate.pem-noout-text证书会显示如下内容:lssuer:证书颁发者;主题:证书颁发给谁;有效期:证书有效期;public-key:公钥内容;SinatureAlgorithm:签名算法这样,当我们访问外卖网站时,得到的不再是公钥,而是一个整数。此证书包含颁发组织的CA。你只需要用这个CA的公钥就可以解密外卖网站证书的签名。如果解密成功且哈希值正确,则说明外卖网站的公钥是真实可信的。在整个上述过程中,有一个前提是CA是可信的。但是我们如何确定CA的公钥是正确的呢?就像有人在一个偏远的乡村设立了一个假的公安局(应该没有人这样做),我们怎么知道公安局是不是假的?那么我们就会想,我去县公安局确认当地公安局的信息。没错,CA也是这样做的。CA的公钥也需要一个比较好的CA来签名,然后形成CA的公钥。要知道一个CA的证书是否可靠,就看CA的上级证书的公钥能否解密CA的签名。就这样追根溯源,直到几个世界知名的CA,我们称之为RootCA,做最后的背书。正是通过这种层层信用背书的形式,保证了非对称加密模式的运行。另外还有一种证书叫做Self-SignedCertificate,就是自己签名。这给人一种“我就是我,不一样的烟花,信不信由你”的感觉。感兴趣的博主可以自行搜索了解。HTTPS的工作模式上面提到了对称加密和非对称加密的原理。我们知道,非对称加密的性能远不如对称加密。那么在HTTP中,两者能否结合呢?例如,公钥和私钥主要用于传输对称加密的密钥,真正双方大量数据的通信都是通过对称加密进行的。是的,HTTPS协议的思路就是这样的。如下图所示:图比较长。整个过程的最终目标是生成后续通信过程中使用的对称密钥和约定的加密算法。整体流程如下:客户端以明文形式发送TLS版本信息、密码套件候选列表、压缩算法候选列表等信息,同时发送一个随机数,用于协商对称密钥时使用(你好,我要点外卖,但你要对我点的东西保密,这是我的密码组列表,还有一个随机数A,你留着);服务器返回一个ServerHello报文,告诉客户端服务器选择使用的协议版本、密码套件、压缩算法等,还有一个随机数B,用于后续的密钥协商(你好,保密性是没问题,按照套路2,我也给你一个随机数B,你留着);服务器给客户端证书;客户端使用来自其受信任的CA仓库的CA证书中的公钥来解密服务器发送的证书。解密成功,说明外卖网站是可信的。在这个解密过程中,客户端可以不断的回溯CA,CA的CA,CA的CA,直到得到一个可信的CA;证书被验证可信后,客户端计算生成一个随机数Pre-master,发送给ClientKeyExchange,用证书中的公钥加密后发送给服务器;此时,客户端和服务端都拥有了三个随机数,分别是:A、B、Pre-master。通过这三个随机数,客户端和服务端可以生成相同的对称密钥。约定好对称密钥和加密算法,加密通信就可以采用对称加密的形式进行。除了后续通信中的密钥验证过程外,HTTP协议中还会有很多过程。但是,上述过程只包括HTTPS的单向认证,即客户端验证服务器的证书,这也是最常见的场景。但是,在对通信安全要求比较严格的情况下,也可以启用双向认证,双方可以验证对方的证书。通过上面的整个过程,我们可以看出,HTTPS协议并不是一个新的协议,它只是HTTP协议和一些加密算法的结合,以保证通信的安全。虽然上面介绍的非对称加密方式现在看起来已经很完美无解了,但是以后谁知道呢?俗话说“道高路高,法高十尺”,加密安全之路永无止境。总结加密分为对称加密和非对称加密。对称加密效率高,但存在密钥传输问题;非对称加密可以解决密钥传输问题,但效率较低。非对称加密需要证书和权限来验证公钥的合法性。HTTPS是一种结合了对称加密和非对称加密算法的HTTP协议。既保证了传输安全,又保证了传输效率。参考:百度百科-htps入门;刘超-趣谈网络协议系列;