Home » Computer » Software » Browser » Archive by category "GoogleChrome" (Page 3)

Chromium 內提案移除 HPKP (HTTP Public Key Pinning)

Twitter 上看到這則 tweet,提到要移除 HPKP (HTTP Public Key Pinning):

blink-dev 上的討論可以參考「Intent To Deprecate And Remove: Public Key Pinning」(就是上面那個連結,只是拉出來)。

這個提案大概可以推敲出理由... 目前的作法必須寫進瀏覽器內,這樣明顯會有 scale 問題,而且這個作法本身就很 workaround,只能保護所謂「高價值」的 domain,而且因為是綁在 Public Key 上,如果 CA 換了 Intermediate Certificate 就有可能會導致檢查過不了。

另外一方面,scale 而且合理的替代方案已經發展出來了。如果瀏覽器會檢查 DNS CAA 資訊 (這個規格可以在 DNS 裡設定有哪些 CA 可以簽這個 domain),就能解這個問題 (加上 DNSSEC 會更加確保驗證過程)。像是這樣:

example.com.    IN      CAA     0 issue "letsencrypt.org"
example.com.    IN      CAA     0 issuewild ";"

不過這個提案本身提到 CT (Certificate Transparency) 怪怪的,因為 CT 無法避免惡意的簽發 (發了以後故意不送 CT):

Finally, remove support for built-in PKP (“static pins”) at a point in the future when Chrome requires Certificate Transparency for all publicly-trusted certificates (not just newly-issued publicly-trusted certificates). (We don’t yet know when this will be.)

但在瀏覽器支援 DNS CAA 可以避免,結果在討論時都沒到 DNS CAA...

另外在 Hacker News 上也有討論:「Public Key Pinning Being Removed from Chrome (groups.google.com)」可以看一下,有個人有提到用 DNS CAA 的方法...

不過印象中這群人對 DNS-based 的方案都不太喜歡,所以也有可能是這樣不考慮在瀏覽器端實作 DNS CAA 吧...

Google Chrome 支援 APNG 了...

翻資料的時候才發現 Google Chrome 從 59 版 (今年六月進 stable channel) 就支援 APNG 了,這樣所有主流瀏覽器只剩下微軟家的 IE 與 Edge 還沒支援了:

找了一下當時的新聞:「Chrome 59 will fully support animated PNGs」,以及對應的 ticket:「Request for enhancement: APNG (animated PNG)」。

APNG 相較於 GIF 多了透明的設計 (GIF 需要拿一個顏色來當作透明),以及更多的色彩,但對於瀏覽器的支援一直都不完整:

The GIF file format has better application and browser support than APNG, but it is limited to 256 colors per frame and supports only index transparency, by mapping one of the palette colors to transparent.

現在這樣讓 GIF 退休的日子又前進了一大步...

Google 打算更廣泛的預設使用 HSTS

Google 宣佈了更廣泛開啟 HSTS 的計畫:「Broadening HSTS to secure more of the Web」。

然後先提到 .foo.dev 的「Google Chrome 將 .dev 設為 HSTS Preload 名單」這件事情:

In 2015 we created the first secure TLD when we added .google to the HSTS preload list, and we are now rolling out HSTS for a larger number of our TLDs, starting with .foo and .dev.

接下來希望拋磚可以引玉:

We hope to make some of these secure TLDs available for registration soon, and would like to see TLD-wide HSTS become the security standard for new TLDs.

Google Chrome 對 Symantec 全系列憑證的不信任計畫

Google Chrome 前陣子整理了一份對 Symantec 憑證的不信任計畫:「Chrome’s Plan to Distrust Symantec Certificates」。

這包括了一卡車的品牌,像是 ThawteVeriSignGeoTrustRapidSSL,不過 Equifax 跟 Symantec 的關係我沒查到...:

Symantec’s PKI business, which operates a series of Certificate Authorities under various brand names, including Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL, had issued numerous certificates that did not comply with the industry-developed CA/Browser Forum Baseline Requirements.

反正整個計畫會在 Google Chrome 70 推出時告一段落 (變成完全不信任),會是 2018/09/13 (預定時間) 與 2018/10/23 (預定時間) 在 beta channel 與 stable channel 上推出。

中間比較重要的時間點是 2018/03/15 (預定時間) 與 2018/04/17 (預定時間),Google Chrome 66 在 beta channel 與 stable channel 上推出,這個版本不會信任 2016/06/01 前發出的憑證:

Chrome 66 released to beta, which will remove trust in Symantec-issued certificates with a not-before date prior to June 1, 2016. As of this date Site Operators must be using either a Symantec-issued TLS server certificate issued on or after June 1, 2016 or a currently valid certificate issued from any other trusted CA as of Chrome 66.
Site Operators that obtained a certificate from Symantec’s old infrastructure after June 1, 2016 are unaffected by Chrome 66 but will need to obtain a new certificate by the Chrome 70 dates described below.

整個計畫的時間軸清楚多了...

偵測 Chrome Headless

作者因為種種原因,想要偵測 Headless 模式的 Google Chrome:「Detecting Chrome Headless」。

之前因為主要是 PhantomJS,有很多地方跟一般的瀏覽器不同,可以利用這些不同的地方來判斷出是不是 PhantomJS:

Until now, one of the most popular headless browser was PhantomJS. Since it is built on the Qt framework, it exhibits many differences compared to most popular browsers. As presented in this post, it is possible to detect it using some browser fingerprinting techniques.

但從 Google Chrome 59 以後因為支援 Headless,使得大多數的判斷的失效:

Since version 59, Google released a headless version of its Chrome browser. Unlike PhantomJS, it is based on a vanilla Chrome, and not on an external framework, making its presence more difficult to detect.

所以作者找了不少方式想要判斷兩者的相異之處... 不過這些方式看起來不太穩定,加上 Firefox 也在準備了,之後只會愈來愈困難吧 :o

Adobe Flash 將在 2020 年 End of Life

Adobe 發出的公告,將在 2020 年中止所有對 Flash 的支援:「Flash & The Future of Interactive Content」。

Specifically, we will stop updating and distributing the Flash Player at the end of 2020 and encourage content creators to migrate any existing Flash content to these new open formats.

然後 GoogleMicrosoft 也來補刀講兩句話:「So long, and thanks for all the Flash」、「Saying goodbye to Flash in Chrome」、「The End of an Era – Next Steps for Adobe Flash」。

Google Chrome 對 WoSign 與 StartCom 的白名單要完全移除了

Twitter 上看到的:

WoSignStartCom 的移除會發生在 61 版,而依照「Final removal of trust in WoSign and StartCom Certificates」這邊的說明,stable 應該會在九月出 61 版而生效:

Based on the Chromium Development Calendar, this change should be visible in the Chrome Dev channel in the coming weeks, the Chrome Beta channel around late July 2017, and will be released to Stable around mid September 2017.

除了 DNS 的 TTL 外,還有瀏覽器本身的 cache time...

在看「Reviewing Fastly’s New Approach To Load Balancing In The Cloud」這篇的時候被提醒:

However, most browsers have implemented their own caching layer that can override the TTL specified by the server. In fact, some browsers cache for 5-10 minutes, which is an eternity when a region or data center fails and you need to route end users to a different location.

我印象中沒那麼長,但也記不起來多長,所以查了一下...

結果 IE 在「How Internet Explorer uses the cache for DNS host entries」直接說三十分鐘 XDDD 這篇文章是 2011 年更新的,所以至少到 IE9 都是對的?

Internet Explorer 4.x and later versions modify how DNS host entries are cached by decreasing the default time-out value to 30 minutes.

Firefox 的值可以從 Mozilla networking preferences 這邊對 network.dnsCacheExpiration 的說明看到是 60 秒。

Google Chrome 沒找到官方的說明...

不過這可以知道當你要換 IP address 時,如果可以讓新舊 IP 都提供服務的話,至少規劃半個小時會比較保險。如果有其他理由而沒辦法同時提供服務的話,至少公告步驟裡要有「重開瀏覽器」這塊。

而作業系統自己的 cache 又是另外要計算進去的事了...

利用手機的 sensor 取得 PIN 碼

把 side-channel information 配合上統計方法就可以達到 74% 的正確率:「Phone Hack Uses Sensors To Steal PINs」。

透過 browser 的 javascript 就可以拉出這些資料,然後利用這些資料去猜你的手機 PIN 碼:

Researchers from U.K.-based Newcastle University created a JavaScript app called PINlogger.js that has the ability to access data generated by the phone’s sensors, including GPS, camera, microphone, accelerometer, magnetometer, proximity, gyroscope, pedometer and NFC protocols.

而且當可以多抓到更多資訊時 (像是第二次輸入) 準確度就更高了:

Using a sample set of 50 PINs, researchers found that their script was able to correctly guess a user’s PIN 74 percent of the time on the first try, which increases to 86 and 94 percent success rates on the second and third attempts.

有些瀏覽器有做一些修正,讓 side-channel information 變少,於是難度變高:

As for Firefox, starting from version 46 (released in April 2016), the browser restricts JavaScript access to motion and orientation sensors. Apple’s Security Updates for iOS 9.3 (released in March 2016), suspended the availability of motion and orientation data when the web view is hidden, according to researchers.

Google 則是沒修:

As for Google, it’s unclear what measures have been taken. “Our concern is confirmed by members in the Google Chromium team, who also believe that the issue remains unresolved,” the report stated. Google did not reply to a request to comment for this report.

這攻擊方式頗不賴... @_@

Archives