Google 與 Cloudflare 測試 Post-Quantum 演算法的成果

這幾年量子電腦的進展不斷有突破,雖然到對於攻擊現有的密碼學看起來還有一段時間,但總是得先開始研究對量子電腦有抵抗性的演算法...

其中 Google Chrome 的團隊與 Cloudflare 的團隊手上都有夠大的產品,兩個團隊合作測試的結果在學界與業界都還蠻重視的:「Real-world measurements of structured-lattices and supersingular isogenies in TLS」、「The TLS Post-Quantum Experiment」。

Google Chrome 這邊是使用了 Canary 與 Dev 兩個 channel,有控制組與兩個新的演算法:

Google Chrome installs, on Dev and Canary channels, and on all platforms except iOS, were randomly assigned to one of three groups: control (30%), CECPQ2 (30%), or CECPQ2b (30%). (A random ten percent of installs did not take part in the experiment so the numbers only add up to 90.)

這兩個演算法有優點也有缺點。一個是 key 比較小,但運算起來比較慢 (SIKE,CECPQ2b);另外一個是 key 比較大,但是運算比較快 (HRSS,CECPQ2):

For our experiment, we chose two algorithms: isogeny-based SIKE and lattice-based HRSS. The former has short key sizes (~330 bytes) but has a high computational cost; the latter has larger key sizes (~1100 bytes), but is a few orders of magnitude faster.

We enabled both CECPQ2 (HRSS + X25519) and CECPQ2b (SIKE/p434 + X25519) key-agreement algorithms on all TLS-terminating edge servers.

感覺還是會繼續嘗試,因為這兩個演算法的缺點都還是有點致命...

Startpage 被廣告公司收購

Hacker News 上看到 Reddit 上的消息 (看起來有陣子了):「Startpage is now owned by an advertising company」。

Startpage 算是之前有在用的 default search engine,但發現有很多 bug 後就不太用了。目前還是先設 DuckDuckGo,然後在需要的時候用之前寫的 press-g-to-google-duckduckgo 切到 Google 去找...

DuckDuckGo 還是有搜尋品質的問題...

Google Chrome 要藉由拆開 HTTP Cache 提昇隱私

在「Prepare For Fewer Cache Hits As Chrome Partitions Their HTTP Cache」這邊看到的,Google Chrome 打算要拆開 HTTP Cache 以提昇安全性與隱私性。

有 cache 跟沒有 cache 可以從讀取時間猜測出來,這樣就可以知道瀏覽器是否有這個特定 url 的 cache。

在原文的作者所給的例子沒有這麼明顯,這邊舉個實際一點的例子來說好了... 我想要知道你有沒有看過 zonble 的「返校」這篇文章,我就拿這篇文章裡面特有的資源來判斷。

以這篇文章來說,我可以選擇第一張圖片的網址 https://i0.wp.com/c1.staticflickr.com/1/603/31746363443_3c4f33ab18_n.jpg?resize=320%2C200&ssl=1 這個 url 來判斷讀取時間,藉此我就可以反推你有沒有看過這篇文章,達到攻擊隱私的效果。

解決的方法就是作者文章裡所提到的方法,把 HTTP cache 依照不同的網站而分開 (在 Safari 已經支援這個功能,而 Firefox 正在研究中)。

當然這樣做應該會對流量有些影響,但考慮到這些日子有很多新技術可以增加下載速度,這個功能應該是還能做...

Chrome 將不會在 HTTPS 頁面上載入 HTTP 資源...

現在 Google Chrome 的穩定版是 77,到了十二月會推出的 79 的時候,就會有一連串的避免 HTTPS 頁面使用 HTTP 資源的措施:「No More Mixed Messages About HTTPS」。

首先是 79 的時候會有新的界面,讓使用者可以修改阻擋類的設定。

到了 80 的時候會試著將 HTTP 的影音 <audio><video> 升級到 HTTPS 連線,如果 HTTPS 讀不到的話就當作讀取失敗。但圖片 <img> 的部份則是會讀進來,只是安全性上會顯示 Not Secure。

到了 81 就是這系列的最終階段,包括 <img> 也會一使用 80 時影音的邏輯,沒辦法在 HTTPS 上讀到就當作讀取失敗。

Google Chrome 也要打開 DoH

Google Chrome 也要支援 DNS over HTTPS (DoH) 了,不過 Google 的作法比 Firefox 軟 (大概這種東西都有經過反壟斷法的評估?),會先判斷系統的 DNS 是否在支援 DoH 的清單內,在不改變 DNS 服務商的情況下,從本來的 UDP 查詢變成 DoH 查詢:「Experimenting with same-provider DNS-over-HTTPS upgrade」。

清單可以從「DNS over HTTPS (aka DoH)」這邊看到,除了 Google 自己外,也有 Cloudflare 與其他支援 DoH 的 DNS 服務商。

這個功能會從 Chrome 78 生效 (現在 stable 與 beta 都還是 77):

We are aiming for an experiment in Chrome 78 (branch cut: Sept 5th; estimated Stable: Oct 22nd) followed by a launch if everything goes well.

OpenBSD 關掉 Firefox 預設的 DoH (DNS over HTTPS)

OpenBSD 決定關閉 Firefox 預設的 DoH (DNS over HTTPS):「DoH disabled by default in Firefox」。

原因是 OpenBSD 的人認為,DoH 本身 ok,但是預設導去 Cloudflare 不 ok:

Disable DoH by default. While encrypting DNS might be a good thing, sending all DNS traffic to Cloudflare by default is not a good idea. Applications should respect OS configured settings. The DoH settings still can be overriden if needed. ok landry@ job@

我覺得這槍開的很好 XD

透過 Avast 防毒軟體蒐集資料的 Jumpshot

看到「Less than Half of Google Searches Now Result in a Click」這篇,在說明 Google 的搜尋結果頁面內的行為大幅偏頗 Google 自家服務的問題,這個問題最近幾個禮拜開始紅了起來...

但另外一點值得注意的是裡面提到 Jumpshot 這個服務可以分析使用者的頁面以及行為這件事情...

在 2013 年 Avast 買下 Jumpshot:「AVAST Software Acquires Jumpshot to Work Magic Against Slow PC Performance」,當時的目標是效能:

Having served as PC tech consultants to their friends and family, their goal was to build a product to help less tech-savvy PC users optimize and tune up their PC performance, cleaning it from unpleasant toolbars and junk software.

但在 2015 年的時候就可以看到 Avast 在他們自家的論壇上有說明,Avast 會收資料丟進 Jumpshot:「Avast and Jumpshot」。

These aggregated results are the only thing that Avast makes available to Jumpshot customers and end users.

而藉由這些資料而提供服務。

Apple 對 Tracking 機制的宣言 (宣戰)

Apple 透過 WebKit 的 blog 公佈了對 tracking 技術的宣言 (或者說「宣戰」):「Announcing the WebKit Tracking Prevention Policy」,完整的文件在「WebKit Tracking Prevention Policy」可以看到。

相關的報導可以參考「Apple will soon treat online web tracking the same as a security vulnerability」。這篇會這樣下標題主要是這點:

We treat circumvention of shipping anti-tracking measures with the same seriousness as exploitation of security vulnerabilities.

不過技術上還是很困難,現在在瀏覽氣上有太多方式可以被拿來追蹤分析。

另外也不用認為蘋果是什麼善類,他只是不太靠廣告賺錢,所以會決定站出來把隱私保護當產品在推銷,哪天有什麼奇怪的特例跑出來的時候也不用太意外...

Amazon SES 過 HIPAA 了

因為 Amazon SES 算是很基本的服務,一直以為 AWS 早就把 Amazon SES 過 HIPAA 了,剛剛看到 AWS 的公告 Amazon SES 過了 HIPAA 才發現並不是這樣:「Amazon SES Achieves HIPAA Eligibility」。

Anyway,這次是所有區域的 SES 都過了:

Amazon SES is now a HIPAA Eligible Service. HIPAA eligibility applies to all AWS Regions where Amazon SES is available.

然後翻了一下市場的情況,看起來 SendGridMailChimp 也沒過,但 Mailgun 有過... 所以是本來就有方案可以用。