理解HTTPS及配置Django+HTTPS开发环境 _HTTPS

HTTP的弊端及HTTPS的由来众所周知HTTP协议是以TCP协议为基石诞生的一个用于传输Web内容的一个网络协议,在"网络分层模型"中属于"应用层协议"的一种.那么在这里我们并不研究该协议标准本身,而是从安全角度去探究使用该协议传输数据本身存在的安全问题:

(1)、通信使用明文(不加密),内容可能被窃听;
(2)、不验证通信方的身份,因此可能遭遇伪装;
(3)、无法证明报文的完整行,所以可能被篡改.

为了解决HTTP协议存在的安全性问题,上世纪90年代由网景(NetScape)公司设计了SSL(Secure Sockets Layer)协议——"安全套接层"协议.经过多年发展SSL在互联网上广泛应用,标准化后名称改为TLS(Transport Layer Security)——"传输层安全"协议.

文章插图

【理解HTTPS及配置Django+HTTPS开发环境】所谓的HTTPS即是"HTTP+SSL/TLS"的结合使用而已.解决的是HTTP协议数据传输的安全性问题——在HTTP协议层和TCP传输层之间加入"安全层",使得应用层数据报经过加密后再传输,保证数据在传输过程中的完整性.
那么,SSL/TLS在数据传输过程中是如何实现加密保证数据完整性的呢?在此,我们需要再进一步探讨该协议的加密逻辑.
加密算法有两种,分别是"对称加密"和"非对称加密".(本文不对密码学中的加密算法的实现做探讨,仅解释加密原理).
对称加密关于"对称加密",可以理解成一种"互逆"的数学运算(对比单向加密它是一种可逆的加密算法).也就是说有加密,就可以解密,但是不管是加密还是解密的过程中,必须有一个至关重要的称之为"密钥"的东西参与运算.

文章插图

对称加密最大的特点就在于加密和解密使用"相同的"密钥.那么关键问题来了——客户端和服务器交互使用共同的"密钥"来加密通信,这就需要服务器将密钥传输给客户端,但是如此操作又如何才能够保证密钥在传输过程中的安全性呢?如果密钥在传输过程中遭遇第三方拦截,那就意味着双端通信之于第三方而言和明文通信没有区别了.也就是说对称加密并不适用于密钥需要网络传输的应用场景.
由此,诞生了"非对称加密".
非对称加密所谓的"非对称加密"就是加密和解密使用的密钥是不同的,双端通信各自产生公钥和私钥匙,并交换双端的公钥用于通信加密.如下图所示,当服务器把公钥交给客户端,客户端在通信时使用公钥对数据进行加密处理,即使公钥在传输过程中遭遇第三方拦截,由于解密的密钥始终存储在服务端并不会对外公开,所以拦截方仅用一个公钥是无法解密数据的.

文章插图

但是上述应用场景仍然存在一定的被窃听的风险.也就是说,作为窃听者,在拦截服务器响应给客户端的公钥后,伪造服务端身份,给客户端响应窃听者的公钥.此后客户端使用窃听者的公钥加密数据,窃听者在拦截数据消息后,利用自己的私钥进行解密,得到明文数据后篡改数据,然后在使用服务器公钥加密数据和服务器通信.整个通信的过程中,客户端都无法察觉自己通信的对端到底是窃听者还是服务器.
观察下图中的图示模型,假设通信过程已被窃听.那么问题到底出在哪里?