写点什么

增强 HTTP

2014 年 1 月 29 日

之前,我们对 HTTPbis 工作组定义 HTTP2.0 的有关工作进行了报道。最近,工作组主席 Mark Nottingham 谈到了关于围绕协议中安全需求的正在进行的有关工作的影响,他发布了他的个人看法

最近,在互联网协议社区最热门的话题之一是:作为 Edward Snowden 向全世界揭露的无孔不入的隐私监视攻击的响应, HTTP/2 Web 协议的最新版本是否要发布,充斥着请求,鼓励或肯定的争论。

目前 Mark 给出了工作简要回顾,特别是涉及到 SPDY(译者: Google 开发的基于传输控制协议(TCP)的应用层协议)和安全部分:

当 Mike(Belshe)和 Roberto(Peon)给我们带来了 SPDY(“斯诺登”成为一个家喻户晓的名字之前),它的实现要求使用 TLS 进行加密。无论基于实用原因(若其中有什么未知的话,真的很难引入的 HTTP 新版本)还是更高级的理由,都是适用的。

由于当时不要求安全性的用例和强制它存在争议的事实……

[……]规范章节都没有关于这个问题的任何论述 ; 默契是我们使加密或未加密连接的 HTTP /2 成为可能,具体实现将决定支持哪些。

伴随 Snowden 和 XKeyscore 泄露的发生,在 IETF 内部事情发生了重大转折,在柏林的工作组会议上,他们举行了一个额外会议,产生了强烈的共识,使用多种加密方式改善 HTTP 安全性。IETF 内部将在接下来的几个月的会议中进一步讨论:

非常清楚的,我们有个共同目标在 HTTP 增加 TLS 使用,从而防止无孔不入的隐私监视和其他攻击,但这样做的不同的方式引起了很多争论和分歧,我们如何能够最好地实现这一目标,以及什么是适当的折衷。

Mark 说,Chrome 和 Firefox 开发者很多都支持,若是由 TLS 保护,他们只会支持 HTTP/2。他还谈到其他浏览器开发者和安全专家制定他认为最佳方式的情况:

[……] 对于普通网页浏览的情况,HTTP/2 服务器将需要使用 TLS,只要他们想与最广泛的浏览器选择进行交互,就如 Mike 和 Roberto 为 SPDY 所做的事情。重要的是,我们并不一定要求在协议规范本身使用 TLS。

接着 Mark 继续他的建议后的更多细节,一些群体希望有更多的安全性,而另一些人认为 IETF 为所有 HTTP/2 使用强制加密是不恰当的。在这种情况下,IETF 很难给出结论,尤其是在这样的“政治”情景下,Mark 的说法:

它是一个政治决定,不是因为这样做是作为攻击者嫁祸政府,但由于 HTTP 是一个部署的协议,有很多既得利益者,如代理销售商,网络运营商,企业防火墙等。要求 HTTP/2 加密意味着这些利益相关者被剥夺利益。

不过,Mark 认为, 通过保证 HTTP/2 协议的灵活和准确,IETF 和工作组需要对各种选项的利弊进行必要讨论。

例如,在 HTTP 的当前设计中,是否使用加密的决定完全依赖于服务器,用户可以做的唯一事情是观察一个 URL 是为“HTTP”还是“HTTPS”(或者观看锁图标),并决定他们是否能继续冲浪。一个更具平衡的 Web 允许客户也能够决定,给予一些好处吸引服务器来支持加密,比如加密时只支持 HTTP/2,正如 Firefox 和 Chrome 正在做的。

在这种情况下,由浏览器厂商决定而不是取决于标准。下一步是什么?那么有另一个 HTTPbis 工作组会议即将在苏黎世,Mark 已经要求提出解决核心问题的建议:

一些浏览器实施者都表示,并准备为开放互联网的通讯只实现 HTTP/2 over TLS。现在,他们可以只为 https:// 开头 URI 实现 HTTP/2,要求希望使用新的协议来重定向 http:// URI 的网站,可以使用“pin”的升级的 HSTS。因此,我们并不一定指定要求(例如,用 MUST 或 MUST NOT),这要在这些浏览器中使用新的协议的站点将实现上述模式。然而,为提升互操作性,我们可以指导书,甚至规范用于驾驭这个。这个议题专门用于为那种文案收集建议。

这将意味着在 HTTP/ 2 标准不要求 TLS,但浏览器的实现可以这样做。然而,正如 Mark 指出,随后这些在 HTTP/2 中强制 TLS 的浏览器实现,它们可能在让企业代理探测通信时会再感到有压力。如果出现这种情况,重要的是反应以协调的方式处理,遵守了标准的互操作性。Mark 带有提醒含义地总结,尚未作出决定,并且还有时间某些其他产出。此外,工作组始终关心别人听到他们结论的意见。毕竟,由IETF 工作组做出的决定未来很可能会影响到我们许多人。

查看英文原文: Strengthening HTTP


感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2014 年 1 月 29 日 04:051269

评论

发布
暂无评论
发现更多内容

1024!奈学教育致敬程序员3+2战略发布会重磅来袭

奈学教育

1024 奈学教育

1024!奈学教育致敬程序员3+2战略发布会重磅来袭

古月木易

程序员 奈学教育

普通人如何站在时代风口学好AI?这是我看过最好的答案

华为云开发者社区

AI 算法

想自己写框架?不会写Java注解可不行

Java架构师迁哥

【API进阶之路】研发需求突增3倍,测试团队集体闹离职

华为云开发者社区

软件开发 开发 开发测试

Scikit-Learn中的特征排名与递归特征消除

计算机与AI

学习 数据科学 特征选择 降维 scikit-learn

「架构师训练营」第 1 周作业 - 食堂就餐卡系统设计

小黄鱼

极客大学架构师训练营

iOS性能优化 — 二、卡顿监控及处理

iOSer

性能优化 编程语言 监控 ios开发 卡顿

技术都是相通的

小黄鱼

极客大学架构师训练营

技术体系的构成

异想的芦苇

技术 技术管理 研发体系

两个程序员老友的会面

Philips

敏捷开发

一文带你读懂 Swift 社区最新开源的算法库

镜画者

ios swift 算法 apple

发布3个月获得5K Star的Luckysheet - 基于MIT协议的开源电子表格

奇异石榴果

Java 前端 Excel 开源项目 html/css

MyBatis-技术专题-动态SQL

李浩宇/Alex

大数据上手实战!训练营“9营齐开”第二季限时免费报名啦

Apache Flink

大数据

在线EXCEL编辑器-Luckysheet

奇异石榴果

Java 开源 Excel bigtable js

程序员喜欢的 5 款最佳最牛代码比较工具

程序员生活志

编程 工具

网易:Flink + Iceberg 数据湖探索与实践

Apache Flink

flink 数据湖

极客时间架构师训练营第一周学习总结

爱码士

课程总结

一文搞懂ReactNative生命周期的进化

凌宇之蓝

react.js 面试 大前端 React Native

项目吐槽之需求分析二

Geek_XOXO

项目管理 pmp 项目实战

架构师训练营 1 期 - 第五周 - 技术选型

三板斧

极客大学架构师训练营

分布式文件存储数据库 MongoDB

哈喽沃德先生

数据库 nosql mongodb mongo 非关系型数据库

架构师训练营第一周作业

爱码士

架构设计

项目吐槽之需求分析一

Geek_XOXO

项目管理 pmp

不会java的人能不能读《Head First设计模式》?

Nydia

作为一名Java程序员,技术栈的广度深度都不够还想要高薪?请先把这些技术掌握再说。

Java架构之路

Java 程序员 架构 面试 编程语言

LeetCode题解:50. Pow(x, n),暴力法,JavaScript,详细注释

Lee Chen

算法 LeetCode 前端进阶训练营

勾魂!在Github白嫖左程云1470页数据结构与算法+视频

996小迁

Java 架构 面试 面试数据结构与算法

MyBatis-技术专题-拦截器介绍

李浩宇/Alex

为什么说容器的崛起预示着云原生时代到来?

华为云开发者社区

容器 云原生 容器云

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

增强HTTP-InfoQ