当 “HTTP” 先生遇上“S”小姐

情人节的晚上,天空中淅淅沥沥的下着带有些寒意的小雨。HTTP 先生孤零零的坐在咖啡厅中,对着面前的电脑发呆。他有意的屏蔽掉了周边情侣们的窃窃私语,这对单身的他来说是狗粮,也是一阵阵伤害。这时,咖啡厅的门被打开了,风姿绰约的“S”小姐出现在 HTTP 先生的眼中。当 HTTP 先生遇见 S 小姐,会产生怎样的化学反应呢?

HTTP (超文本传输协议)是目前互联网应用最广泛的协议,伴随着人们网络安全意识的加强,HTTP“S” 被越来越多地采纳。不论是访问一些购物网站,或是登录一些博客、论坛等,我们都被 HTTPS 保护着,甚至 Google Chrome、Firefox 等主流浏览器已经将所有基于 HTTP 的站点都标记为不安全。

HTTPS Everywhere

为什么 HTTP 是不安全的?我们先来简单看下 HTTP 访问过程。

01.jpg

抓包如下:

02.jpg

如上图所示,HTTP 请求过程中,客户端与服务器之间没有任何身份确认的过程,数据全部明文传输,“裸奔”在互联网上,所以很容易遭到黑客的攻击,如下:

03.jpg

可以看到,客户端发出的请求很容易被黑客截获,如果此时黑客冒充服务器,则其可返回任意信息给客户端,而不被客户端察觉,所以我们经常会听到一词“劫持”。

试想下,你正在进行一次在线付款操作,你需要输入银行卡号、密码等信息,然后这些信息会经过网络发送到银行系统,“一切数据”都是明文传输的,而恰好有人正在进行网络抓包,他解开你的数据包,然后偷窃你的所有信息。这会对你的财产安全构成了直接威胁。除了财产不安全以外,你的隐私也无法得到保证,什么时候浏览什么了网站,这些都容易被他人所嗅探到。

因此,可以说是 HTTPS 的使用是互联网发展的必然趋势,我们需要这样一种手段来保障我们个人的财产安全,隐私安全。不论是在上网做什么,我们都希望我们的足迹能够被保护起来,不轻易地被不怀好意的人感知到。因此 HTTPS 应该应用在全部的上网场景之中,HTTPS everywhere!

HTTPS 为什么安全

04.jpg

通过上图我们就可以了解到,相比 HTTP,HTTPS 传输更加安全。

  • 所有信息都是加密传播,黑客无法窃听。
  • 具有校验机制,一旦被篡改,通信双方会立刻发现。
  • 配备身份证书,防止身份被冒充。

HTTPS 普及之难

按说上网更加安全,这并没有什么不好的,然而 HTTPS 的推广却存在着一些障碍,比如 SSL 证书的价格问题、建立安全通信链路所带来的额外开销等。

证书开销

05.jpg

首先是证书价格问题,不少个人用户在看到价格之后,会产生“配置 HTTPS 是否值得”,“证书之间的价格相差如此之大我该如何选择”等疑问。这可能会使客户在了解 HTTPS 带来的好处之前,就直接打消配置 HTTPS 的念头。其实针对个人博客或者小网站,又拍云就提供 Let’s Encrypt 和 Symantec 的两款免费证书。 OV、EV 证书更建议企业采用,为网站提供更全面的安全保障。

服务器资源消耗

HTTPS,即 HTTP Over TLS,建立一条安全通信链路,需要经历一次 SSL/TLS 握手,在握手阶段,双方(客户端和服务器)会采用非对称加密的方式进行密钥协商,例如现在最流行的 RSA 算法和临时椭圆曲线算法,密钥协商的目的是计算出一个称为 “pre master” 的串,用以构建出最终的加密密钥,这个加密密钥用于对称加密,即双方进行数据传输时使用。非对称加密最大的缺陷是其计算的复杂度,这些复杂的数学计算,往往会消耗一定的 CPU 资源。不过不用担心,这消耗主要体现在服务端,例如又拍云 CDN 边缘的服务器每秒需要处理数以万计的 HTTPS 请求,这对服务器的硬件资源是一个极大的考验。

另外,这里的消耗主要来自于握手时候的消耗,建好连接之后就不太耗了。

那么采用 HTTPS 后,到底会多用多少服务器资源?

2010年1月 Gmail 切换到完全使用 HTTPS, 前端处理 SSL 机器的CPU 负荷增加不超过1%,每个连接的内存消耗少于20KB,网络流量增加少于2%。由于 Gmail 应该是使用N台服务器分布式处理,所以CPU 负荷的数据并不具有太多的参考意义,每个连接内存消耗和网络流量数据有参考意义。这篇文章中还列出了单核每秒大概处理 1500 次握手(针对1024-bit 的 RSA),这个数据很有参考意义,具体信息来源:ImperialViolet(https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html)。

访问速度

繁重的计算和多次交互天然的影响了 HTTPS 的访问速度。如果什么优化都不做,HTTPS 会明显慢很多。如果做过常规优化,但是不针对 HTTPS 做优化,这种情况下测试的结果是 0.2-0.4 秒耗时的增加。如果是没有优化过的站点,慢 1 秒都不是梦。

所以,不是慢,是没有优化。

说到优化,为了能够让HTTPS更好更快的普及,工程师们设计出了不少针对性的优化点。

例如针对 SSL/TLS 握手的开销,引入了 SSL Session 和 TLS Session Tickets 的机制,用以复用会话,减少握手带来的开销;又拍云 CDN 全网支持 HTTP/2 和 TLS 1.3 特性,HTTP/2 带来了巨大的速度提升,具有诸如服务器推送,标头压缩和并行请求等功能。而 TLS 1.3 通过移除有安全隐患的加密算法来提高安全性,通过简化握手,减少延迟并提高性能。

针对 SSL/TLS 握手会消耗大量的 CPU 资源,各厂商都在探索利用硬件(例如 Intel 提供的 Quick Assistant Technology)进行加速的道路;

针对证书昂贵的问题,又拍云联合 Symantec、GeoTrust、TrustAsia、Let’s Encrypt 推出付费和免费 SSL 证书申请与管理一站式服务,无需繁杂流程,一键申请,自主部署,轻松实现网站与 Web 应用的 HTTPS 加密部署。

未经允许不得转载(声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎发送邮件至:net-net@foxmail.com进行举报,并提供相关证据,工作人员会在10个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。):策信智库资讯网 » 当 “HTTP” 先生遇上“S”小姐

赞 (0)