看小电影时,你的网站真的是安全的吗

发布日期:2021-11-01 10:24    点击次数:177

要看一部小电影或浏览一个正常的网站,你必须检查它是否是HTTPS。HTTP可能会被中间人攻击和拦截。以下是HTTPS的详细原理,极其恐怖。

1.HTTP协议。

在谈论HTTPS协议之前,让我们回顾一下HTTP协议的概念。

1.1 http协议介绍。

HTTP协议是一种基于文本的传输协议,位于OSI网络模型的应用层。

HTTP协议通过客户端和服务器端的请求响应进行通信。目前,该协议被RFC2616分为六个独立的协议描述(RFC7230、RFC7231、RFC7232、RFC7233、RFC7234和RFC7235)。通信消息如下:

请求

POSThttp://www.baidu.comHTTP/1.1Host:www.baidu.comConnection:keep-aliveContent-Length:7User-Agent:Mozilla/5.0(WindowsNT10.0;Win64;x64)AppleWebKit/537.36(KHTML,likeGecko)Chrome/71.0.3578.98Safari/537.36wd=HTTP

作出反应

HTTP/1.1200OKConnection:Keep-AliveContent-Encoding:gzipContent-Type:text/html;charset=utf-8Date:Thu,14Feb201907:23:49GMTTransfer-Encoding:chunked...1.2HTTP中间人攻击。

HTTP协议使用起来非常方便,但是有一个致命的缺点:不安全。

我们知道HTTP协议中的消息是以明文传输的,没有任何加密。这会导致什么问题?这里有一个例子:

1.小明在JAVA贴吧发帖,内容是我爱JAVA:

2.被中间人攻击,内容改成了我爱PHP。

3.小明被人群嘲笑(手动狗头)。

可以看出,在HTTP传输过程中,中间人可以看到并修改HTTP通信中的所有请求和响应,因此使用HTTP是非常不安全的。

1.3防止中间人攻击。

这时,可能有人会想,既然内容是明文,我就用对称加密对消息进行加密,这样中间人就看不到明文了,所以变换如下:

1.双方同意加密方法。

2.用AES加密邮件。

看似中间人无法获取明文信息,但实际上,加密方式和密钥在通信过程中仍会以明文形式暴露。如果第一次通信被拦截,密钥会泄露给中间人,中间人仍然可以解密后续通信:

所以,在这种情况下,我们肯定会考虑是否可以加密密钥,以免让中间人看到。答案是肯定的,我们可以用RSA算法实现非对称加密。

当同意加密方法时,服务器生成一对公钥和私钥,服务器将公钥返回给客户端。客户端在本地生成一系列用于对称加密的密钥(AES_KEY),通过服务器发送的公钥进行加密得到(AES_KEY_SECRET),然后返回给服务器,服务器通过私钥对客户端发送的AES_KEY_SECRET进行解密得到AEK_KEY,最后客户端和服务器通过AEK_KEY发送消息。

可以看出,在这种情况下,中间人无法窃取密钥进行AES加密,因此肯定无法解密后续通信。那么这样做绝对安全吗?

所谓道高一尺魔高一尺,中间人想出了新的破解方案来对应这种加密方式。既然拿不到AES_KEY,我就把自己模拟成客户端和服务器的组合。在用户->中间人的过程中,中间人模拟服务器的行为,这样我们就可以得到用户请求的明文,而在中间人->服务器的过程中,中间人模拟客户端的行为,这样我们就可以得到服务器响应的明文,从而进行中间人攻击。

该通信再次被中间人截获,中间人伪造了一对公钥和私钥,并将公钥发送给用户,以窃取客户端生成的AES_KEY。得到AES_KEY后,就可以轻松解密了。

如果中间人为所欲为,难道没有办法惩罚他吗?当然有。接下来,让我们看看HTTPS是如何解决通信安全问题的。

2.HTTPS议定书2.1 https简介

事实上,HTTPS是SSL+HTTP的缩写。当然现在SSL已经基本被TLS取代了,但是我们还是用SSL作为缩写。事实上,SSL协议不仅适用于HTTP协议,也适用于各种应用层协议,如FTP和WebSocket。

实际上,SSL协议与上一节中的非对称加密大致相同。握手过程主要是交换密钥,然后在通信过程中使用对称加密进行通信。大致过程如下:

我刚刚在这里画了一个示意图。实际上,真正的SSL握手会比这个复杂得多,但它的性质是相似的。此外,我们需要关注HTTPS如何防止中间人攻击。

从上图可以观察到,服务器通过SSL证书传输公钥,客户端会对SSL证书进行验证,其中证书认证系统是保证SSL安全的关键。接下来,我们将解释CA身份验证系统,看看它如何防止中间人攻击。

2.2CA认证体系。

在上一节中,我们看到客户端需要验证服务器返回的SSL证书,那么客户端如何验证服务器SSL证书的安全性呢?

权威认证机构。

在ca certificates系统中,所有的证书都是权威机构颁发的,权威机构的CA证书已经内置在操作系统中。我们将这些证书称为ca根证书:

颁发证书。

如果我们的应用服务器想要使用SSL,就需要通过权威的认证机构颁发CA证书。我们将服务器生成的公钥和站点相关信息发送给CA颁发机构,然后CA颁发机构将服务器发送的相关信息与CA颁发机构进行签名,从而获得我们应用服务器的证书。证书会对应生成证书内容的签名,用CA颁发机构的私钥对签名进行加密得到证书指纹,并生成与上级证书的关系链。

下面我们下载百度的证书看看:

可以看到百度是受信于GlobalSignG2,同样的GlobalSignG2是受信于GlobalSignR1,当客户端(浏览器)做证书校验时,会一级一级的向上做检查,直到最后的根证书,如果没有问题说明服务器证书是可以被信任的。可以看出,百度是受global sign 2信任的,同样的global sign 2也是受GlobalSignR1信任的。当客户端(浏览器)检查证书时,它将逐级检查它,直到最终的根证书。如果没有问题,可以信任服务器证书。

如何验证服务器证书?

那么客户端(浏览器)如何检查服务器证书呢?首先,它将通过层次关系找到上级证书,通过上级证书中的公钥解密服务器的证书指纹以获得签名(sign1),然后通过签名算法计算服务器证书的签名(sign2)。通过比较符号1和符号2,如果它们相等,则表示证书没有被篡改或伪造。

有趣的是,用于证书验证的RSA通过用私钥加密证书签名,用公钥解密,巧妙地验证了证书的有效性。这样,通过证书的认证系统,可以避免中间人窃取AES_KEY发起对HTTP通信消息的拦截和修改。

摘要

首先通过攻击HTTP中间人知道HTTP为什么不安全,然后从安全攻防技术进化到HTTPS的原理概括,希望能对HTTPS有更深的了解。

作者:mokeyWie来自:segmentfault.com/a/1190000023936425来源:思否