Home » Computer » Network » Archive by category "WWW" (Page 4)

以 Google Chrome 的情況分析各種 script 的利弊與使用時機

在「Script Scheduling in Chrome」這邊看到關於各種 <script> 的時機,主要是以 Google Chrome 環境為主。作者在文章裡面有提到「Scheduling Scripts Intuitively and Performantly」這份文件,並且將最上面的表格取出來,光是這張表就給了不少想法:

文件裡面有更多細節可以看,而且有些討論其實是在思考要怎麼修改 spec 讓網站更容易設 script priority...

CloudFront 在台北的第二個 PoP

Twitter 上看到了 Amazon CloudFront 宣佈了台北的第二個 PoP:

這個也是喊好久了,從去年就有消息一直到現在... 這樣台灣多了一個 backup,比較不會導去香港或是日本了。不過新 PoP 的代碼找不到,試著找 tsatpe 以及後面接數字,還是只有找到 tpe50,不知道是不是後來不露出代碼了...

廣告的 SDK 因為走 HTTP 傳輸而洩漏大量資料...

廣告走 HTTP 而且還帶了一堆敏感資訊,算是最近討論蠻熱烈的問題:「Leaking ads」。

而且還分析找出有哪些是超大的廣告 unencrypted domain,像是這樣:

不過裡面一堆都不熟悉的廣告業者,反倒是聯想的網域被抓出來了:

不過行動裝置上能控制的東西太少了... 裝廣告阻擋程式比較實際,iOS 上不 JB 應該是只有 VPN 的方案,而 Android 上的方案應該就比較多了,除了 VPN 以外有 /etc/hosts 甚至是 firewall solution。

Google Chrome 67 將可以在 DevTools 裡看到 SCT 的內容

Twitter 上看到 Google Chrome 67 (下一個版本) 的 DevTools 將會顯示憑證上的 Certificate Transparency 資訊:

現在要看這個資訊比較麻煩,之後可以在瀏覽器裡直接讀就會簡單一些了...

話說回來,Let's Encrypt 上個月也支援 SCT 了:「Engineering deep dive: Encoding of SCTs in certificates」,不過目前只能先用 command line 工具看... 我拉了 Let's Encrypt 官方網站的 certificate 可以看到 (Let's Encrypt 那篇文章裡的範例),但我自己 blog 的 certificate (序號 04ef0022ed7d5417f1ccbc011acf7fea9830) 看起來是在 Let's Encrypt 支援 SCT 之前申請的,沒看到 SCT 資訊... 要等下一次的 renew 了。

nginx 穩定版 1.14.0 出版

Twitter 上看到 nginx 穩定版 1.14.0 出了:

CHANGES-1.14 可以看到 1.12 到 1.14 中間多了哪些功能,我比較注意的是:

  • 引入了 TLS 1.3 關鍵字。(因為還沒進 Standard Track,不能直接說支援了...)
  • 支援 HTTP/2 Push。
  • 引入 gRPC 相關的功能。

看看 Ubuntu 18.04 會不會直接上這個版本,另外就是等 PPA 了...

HTTPS Everywhere 改變更新 Ruleset 機制,變成定時更新...

HTTPS Everywhere 是我很喜歡的一個套件,裡面有 Ruleset,會將 Ruleset 表內認定有支援 HTTPS 網站的 HTTP request 都改成 HTTPS,這可以降低被攔截的風險。像是網站雖然有 HSTS 但第一次連線時走 HTTP 的情況,以及網站本身有支援 HTTPS 但沒有設定 HSTS 時,在網址列上誤打 HTTP 版本的情況。

先前版本的 Ruleset 是隨著軟體更新時,包在軟體內一起更新。這樣的缺點是更新速度比較慢,但好處是不需要伺服器端,而且隱私性也比較高。而現在 EFF 決定還是要推出線上更新的版本,以加速 Ruleset 更新的速度:「HTTPS Everywhere Introduces New Feature: Continual Ruleset Updates」。

We've modified the extension to periodically check in with EFF to see if a new list is available.

而頻寬的部份由 Fastly 贊助:

If you haven't already, please install and contribute to HTTPS Everywhere, and consider donating to EFF to support our work!

如果對這點有疑慮的,也還是可以關掉 auto updater 避免洩漏資訊給 EFF 或是 Fastly。

TWCA 不在 Java Trust Store 裡...

SSL Labs 上翻資料的時候發現看到台灣有些網站的 SSL 憑證在 Java Trust Store 內是不會取得信任授權的,但其他的都支援,像是這樣:

翻了幾個後發現都是 TWCA 的,在其他家都是這樣授權出來的 (Mozilla/Apple/Android/Windows):(TWCA Root Certification Authority -> ) TWCA Global Root CA -> TWCA Secure SSL Certification Authority -> Final,也就是 TWCA 的兩個 Root CA 都在 trust store 內,走任何一條授權都可以拉出來。

印象中之前應該都是支援的... 先前是 cross sign 嗎?@_@

Cloudflare 推出 Argo Tunnel

Cloudflare 推出了 Argo Tunnel,可以將內部網路與 Cloudflare 之間打通:「Argo Tunnel: A Private Link to the Public Internet」。

Cloudflare 在去年推出了 Wrap (可以參考「Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443」這篇),這次其實只是改名:

During the beta period, Argo Tunnel went under a different name: Warp. While we liked Warp as a name, as soon as we realized that it made sense to bundle Warp with Argo, we wanted it to be under the Argo product name. Plus, a tunnel is what the product is so it's more descriptive.

看起來沒有什麼新的玩意... 純粹改名字 :o

Cloudflare 推出在 HTTPS 下的壓縮機制

在 TLS (HTTPS) 環境下基本上都不能開壓縮,主要是為了避免 secret token 會因為 dictionary 的可預測性而被取出,像是 CRIMEBREACHTIMEHEIST (沒完結過...),而因為全面關閉壓縮,對於效能的影響很大。

Cloudflare 就試著去找方法,是否可以維持壓縮,但又不會洩漏 secret token 的方式,於是就有了這篇:「A Solution to Compression Oracles on the Web」。

重點在於 Our Solution 這段的開頭:

We decided to use selective compression, compressing only non-secret parts of a page, in order to stop the extraction of secret information from a page.

透過 regex 判斷那些東西屬於 secret token,然後對這些資料例外處理不要壓縮,而其他的部份就可以維持壓縮。這樣傳輸量仍然可以大幅下降,但不透漏 secret token。然後因為這個想法其實很特別,沒有被實證過,所以成立了 Challenge Site 讓大家打:

We have set up the challenge website compression.website with protection, and a clone of the site compression.website/unsafe without it. The page is a simple form with a per-client CSRF designed to emulate common CSRF protection. Using the example attack presented with the library we have shown that we are able to extract the CSRF from the size of request responses in the unprotected variant but we have not been able to extract it on the protected site. We welcome attempts to extract the CSRF without access to the unencrypted response.

這個方向如果可行的話,應該會有人發展一些標準讓 compression algorithm 不用猜哪些是 secret token,這樣一來就更能確保因為漏判而造成的 leaking...

Archives