加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 创业 > 正文

从起源到发展 详说HTTP从1到3的演变

发布时间:2020-07-22 19:29:50 所属栏目:创业 来源:互联网
导读:访问: 阿里云新用户福利专场 云服务器ECS低至102元/年 天翼云年中上云节 云主机1C2G 92元/年 实名注册送8888元大礼包 本文也无意于深挖 HTTP 中的某一点,这是像 《HTTP 权威指南》或者是 RFC 协议做的事。本文目标是帮助读者理清 HTTP 的演化过程,说说

一般来说 HTTP 从 TCP 三次握手后,便开始了数据传输。由于 HTTP 本身以明文形式来传输数据,并不具备任何数据加密、身份校验的机制。同时下层协议并不对数据安全性、保密性提供保证。所以在网络传输的过程中,任意节点的第三方都可以随意劫持流量、篡改数据或窃取信息。

HTTP 无法确保数据的保密性、完整性和真实性,已经不能适应现代互联网应用的安全需求。

随着 Web 的日益壮大,HTTP 的使用呈巨额增长趋势,对信息安全的需求也愈来愈迫切,SSL(Secure SocketsLayer ,安全套接层)应运而生。

当对于安全需求,首先想到的就是对信息进行加密。SSL ,安全套接层,顾名思义是在 TCP 上提供的安全套接字层。其位于应用层和传输层之间,应用层数据不再直接传递给传输层而是传递给 SSL 层,SSL 层对从应用层收到的数据进行加密,利用数据加密、身份验证和消息完整性验证机制,为网络上数据的传输提供安全性保证。HTTPS 便是指 Hyper Text Transfer Protocol over SecureSocket Layer。

谈到具体实施上,业内通常采用的一般有对称加密和非对称加密。采用何种方式进行加密?如何判断服务器未被篡改?如何传递加密密钥?带着这样的问题,我们来看看 HTTPS 的工作流程。

1、客户端发起 HTTPS 请求

这个没什么好说的,就是用户在浏览器里输入一个 HTTPS 网址,然后连接到 server 的 443 端口。

2、服务端的配置

采用 HTTPS 协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请,区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面(Let‘s Encrypt 就是个不错的选择,免费的 SSL 证书)。

这套证书其实就是一对公钥和私钥,如果对公钥和私钥不太理解,可以想象成一把钥匙和一个锁头,只是全世界只有你一个人有这把钥匙,你可以把锁头给别人,别人可以用这个锁把重要的东西锁起来,然后发给你,因为只有你一个人有这把钥匙,所以只有你才能看到被这把锁锁起来的东西。

3、传送证书

这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间等等。

4、客户端解析证书

这部分工作是有客户端的 TLS 来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警告框,提示证书存在问题。

如果证书没有问题,那么就生成一个随机值,然后用证书对该随机值进行加密,就好像上面说的,把随机值用锁头锁起来,这样除非有钥匙,不然看不到被锁住的内容。

5、传送加密信息

这部分传送的是用证书加密后的随机值,目的就是让服务端得到这个随机值,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6、服务段解密信息

服务端用私钥解密后,得到了客户端传过来的随机值(私钥),然后把内容通过该值进行对称加密,所谓对称加密就是,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然无法获取内容,而正好客户端和服务端都知道这个私钥,所以只要加密算法够彪悍,私钥够复杂,数据就够安全。

7、传输加密后的信息

这部分信息是服务段用私钥加密后的信息,可以在客户端被还原。

8、客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息,于是获取了解密后的内容,整个过程第三方即使监听到了数据,也束手无策。

简单说完了 HTTPS 的工作流程。让我们再将注意力放在 SSL 的演化上。

1994年,Netscape 创建了 SSL 协议的原始规范并逐步发布协议改进版本。1995 年发布 SSL 2.0。1996年,Netscape 和 Paul Kocher 共同设计发布 SSL 3.0 协议,获得互联网广泛认可和支持。因特网工程任务组(IETF)接手负责该协议,并将其重命名为 TLS(传输层安全)协议。

我们看到,SSL 2.0 规范是在 1995 年左右发布的,而 SSL 3.0 是在 1996 年 11 月发布的。有趣的是,SSL 3.0 是在 RFC 6101 [https://tools.ietf.org/html/rfc6101] 中描述的,该 RFC 于 2011 年 8 月发布。它位于历史类别中,该类别通常是被考虑和被丢弃的文档想法,或者是在决定记录它们时已经具有历史意义的协议(根据 IETF [https://www.ietf.org/about/groups/iesg/statements/] 说明)。在这种情况下,有一个描述 SSL 3.0 的 IETF 文档是很有必要的,因为在其可以被用作规范参考。

再来看看,SSL 是如何激发 TLS 的发展的。后者在 1996 年 11 月以 draft-ietf-tls-protocol-00 [https://tools.ietf.org/html/draft-ietf-tls-protocol-00] 宣告开始。它经历了六个草案版本,并于 1999 年初作为 RFC 2246 [https://tools.ietf.org/html/rfc2246] – TLS 1.0 正式发布。

在 1995 和 1999 年间,SSL 和 TLS 协议用于保护互联网上的 HTTP 通信。这作为事实上的标准运行良好。直到 1998 年 1 月,随着 I-D draft-ietf-tls-HTTPs-00 [https://tools.ietf.org/html/draft-ietf-tls-HTTPs-00] 的发布,HTTPS 的正式标准化过程才开始。该工作于 2000 年 5 月以 RFC 2616 – HTTP 上的 TLS 的发布结束。

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读