HTTP向HTTPS演化的过程

Posted 2021-04-26 Java患者

HTTP的访问形式

        HTTP它出现的比较早，现在已经有HTTP/2.0了，但是使用最普遍的还是HTTP/1.1。

HTTP是无状态的

        HTTP协议是基于TCP之上的协议，定义了我们客户端和服务端文件的传输方式。如在一个HTTP请求过程，会带有request和response，他们都有一定的规范。HTTP是一个无状态的，每次请求的处理是独立的，不依赖其他请求，我们通过服务端技术Cookie和Session技术实现它的状态，从而满足我们业务场景的请求。

HTTP的缺陷

        HtTP很多的缺陷，如通过HTTP进行通信时候，请求信息request和响应信息response是可以被拦截掉的，如果是被黑客拿到这些信息，他们就可以进行很多操作，本质来说它的通信也是明文传输。

HTTP与HTTPS的区别

        HTTS是TCP与HTTP之间加一个SSL。想要了解HTTP和HTTPS的区别，我们最重要的还是要去了解什么是SSL。我们现在使用的版本大多是TLS。

什么是SSL

        SSL(Secure Sockets Layer 安全套接层)，是为网络通信提供安全及数据完整性的一种安全协议。SSL在传输层与应用层之间对网络连接进行加密，防止数据传输过程中被篡改。‍我们现在使用的版本大多是TLS，他是SSL续任者。

对称加密与非对称加密

• 对称加密：加密和解密都是使用到同一个密钥。它存在一个问题，假设客户端传输一个密文，并把密钥也携带过去，那么在传输过程中，只要传输的密钥被拿到，那么对于密文来说一样是透明的。

• 非对称加密：有公钥和私钥的概念，通过公钥加密的数据可以用私钥解密，通过私钥加密的数据可以用公钥解密。每一个客户端都有自己的公钥，而私钥放在服务端上，这样它可以解决我们对称加密存在的问题。
  

协商密钥过程

非对称加密中，我们需要一个协商密钥过程，让每一个客户端拿到不同的公钥，并且保证在交互的情况下才知道用什么算法。

在传统的模式下存在一个问题，客户端向服务端发起一个请求公钥的请求，在返回公钥给客户端的过程中，公钥被中间人篡改了，后续的客户端每一次请求都会用这个假的公钥加密，而中间人可以拦截到这个请求，解密后并篡改数据，用真的公钥加密再发送给服务端。

因为协商的过程一定存在，那么怎么去解决问题呢？我们不可能把公钥直接传给客户端，而是将加密后的公钥传给客户端，这样公钥就不被其他人篡改，那么又要让客户端知道去如何解密被加密后的公钥，这是一个循环的问题。

为了解决上述的问题，引入了第三方机构。服务端发给客户端的公钥先使用第三方机构的公钥加密后发给第三方机构，第三方机构用它自己的私钥解密在一次加密，并返回给服务器，这就是数字证书。

由于客户端拿到的数据证书都可以使用第三方机构的公钥进行解密，那么如果中间人以正规的渠道获取属于它的数字证书，这个时候他可以替换服务端给客户端的数字证书，对于客户端来说还是不知道真假。

HTTPS的处理方式

我们协商里，客户端如何去识别数字证书的合法性？我们的数据证书必须要有一些信息，让客户端知道这个数字证书是对于服务端的，而不中间人。客户端可以去请求第三方辨别。

但是通常情况下客户端可以内置一些第三机构的数字证书和公钥（在设置里面），利用这些可以去验证发服务端过来的数据证书去识别数字证书的合法性。

如果验通过了，浏览器得到公钥了，这个公钥后会加密一个浏览器随机生成的数据作为对称加密，并传给服务端。服务器使用私钥解密，根据3个随机数生成会话密钥，返回给浏览器。

这就是我们客户端对服务端验证的过程，它用到了对称加密，非对称加密，随机数（生成会话密钥）。由于使用非对称加密在数据加密解密过程需要消耗一定时间，降低了数据传输效率。所以在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。这就是HTTPS的原理。

查看