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


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

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

    HTTPS Everywhere

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

     

    抓包如下:

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

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

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

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

     

    HTTPS 为什么安全

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

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

     

    HTTPS 普及之难

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

    证书开销

    首先是证书价格问题,不少个人用户在看到价格之后,会产生“配置 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 的访问速度。如果什么优化都不做,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 加密部署。

     

    推荐阅读:

    不是 HTTPS 拖慢网站速度,而是优化做的不够优秀
     
    HTTPS 到底加密了什么?
  • 相关阅读:
    微软开源全新的文档生成工具DocFX
    .NET平台微服务项目汇集
    谷歌发布的首款基于HTTP/2和protobuf的RPC框架:GRPC
    Microsoft开源跨平台的序列化库——Bond
    Oracle job procedure
    Windows10
    移动端Reactive Native轮播组件
    PHP完整环境搭建
    Webpack 入门
    git 提交
  • 原文地址:https://www.cnblogs.com/upyun/p/10382737.html
Copyright © 2020-2023  润新知