最新的 Firefox 56 對 AES-GCM 效能的改善

昨天釋出的 Firefox 56 對於 AES-GCM 在老電腦上改善了不少效能:「Improving AES-GCM Performance」。

首先是 Firefox 自己的數據分析,可以看到 AES-GCM 佔目前加密連線裡的大宗,再來是 AES-CBC:

先以 Linux 64bits 環境的數據來看,Firefox 56 的 NSS 3.32 大幅改善了老電腦的效能 (不支援 AES-NI 硬體加解密的 CPU,甚至是不支援 PCLMUL 的 CPU,以及不支援 AVX 的 CPU):

在 Linux 32bits 環境上則是連預設值大幅改善,不過用的人應該少很多了:

Windows 下則是因為 64bits 或是 32bits 都有足夠的使用者,所以平常就花了不少力氣。但也可以看出對於老電腦的速度提升:

Mac (64bits only) 算是這次比較大的提升,連新電腦的預設值都大幅變快:

加上之後陸續的改善 (尤其是下一版 Firefox 57 的 Project Quantum),這幾版應該會拉出不少效能...

Tor 在考慮使用 Rust 改寫

不過也不確定是不是愚人節消息就是了:「[tor-dev] Tor in a safer language: Network team update from Amsterdam」。

Tor 考慮使用 Rust 改寫,目前已經完成的部份,以及接下來的規劃:

What has already been done:
- Rust in Tor build
- Putting together environment setup instructions and a (very small) initial draft for coding standards
- Initial work to identify good candidates for migration (not tightly interdependent)

What we think are next steps:
- Define conventions for the API boundary between Rust and C
- Add a non-trivial Rust API and deploy with a flag to optionally use (to test support with a safe fallback)
- Learn from similar projects
- Add automated tooling for Rust, such as linting and testing

目前看到後續的討論只有「[tor-dev] Tor in a safer language: Network team update from Amsterdam」這篇,也許等全世界的 4/1 都過了之後再回來確認吧...

GitHub 允許員工在閒暇時間使用公司設備創作他們自己的東西

看到「GitHub now lets its workers keep the IP when they use company resources for personal projects」這則新聞,GitHub 正式的條款在「Balanced Employee IP Agreement (BEIPA)」這邊可以看到。

如同報導所提到的,只要不與工作內容相關 (或競爭),員工都可以保留權利:

This allows its employees to use company equipment to work on personal projects in their free time, which can occur during work hours, without fear of being sued for the IP. As long as the work isn’t related to GitHub’s own “existing or prospective” products and services, the employee owns it.

V8 對 for-in 的最佳化

V8 引擎的人對 for-in 的最佳化寫了一篇解釋「Fast For-In in V8」,比較直接的結果就是維基百科Facebook 都變快了:

For example, in early 2016 Facebook spent roughly 7% of its total JavaScript time during startup in the implementation of for-in itself. On Wikipedia this number was even higher at around 8%.

可以看得出來是挑比較大的來改,而下一版的 Google Chrome (57) 將會對 for-in 會到另外一個極致:

The most important for-in helpers are at position 5 and 17, accounting for an average of 0.7% percent of the total time spent in scripting on a website. In Chrome 57 ForInEnumerate has dropped to 0.2% of the total time and ForInFilter is below the measuring threshold due to a fast path written in assembler.

主要是因為 spec 對 for-in 的定義寫得很模糊,所以就有很多實作的空間可以調整:

When we look at the spec-text of for-in, it’s written in an unexpectedly fuzzy way,which is observable across different implementations.

Cloudbleed:Cloudflare 這次的安全問題

Cloudflare 把完整的時間軸與影響範圍都列出來了:「Incident report on memory leak caused by Cloudflare parser bug」。

出自於 2/18 時 GoogleTavis Ormandy 直接在 Twitter 上找 Cloudflare 的人:

Google 的 Project Zero 上的資料:「cloudflare: Cloudflare Reverse Proxies are Dumping Uninitialized Memory」。

起因在於 bug 造成有時候會送出不應該送的東西,可能包含了敏感資料:

It turned out that in some unusual circumstances, which I’ll detail below, our edge servers were running past the end of a buffer and returning memory that contained private information such as HTTP cookies, authentication tokens, HTTP POST bodies, and other sensitive data.

不過這邊不包括 SSL 的 key,主要是因為隔離開了:

For the avoidance of doubt, Cloudflare customer SSL private keys were not leaked. Cloudflare has always terminated SSL connections through an isolated instance of NGINX that was not affected by this bug.

不過由於這些敏感資料甚至還被 Google 收進 search engine,算是相當的嚴重,所以不只是 Cloudflare 得修好這個問題,還得跟眾多的 search engine 合作將這些資料移除:

Because of the seriousness of such a bug, a cross-functional team from software engineering, infosec and operations formed in San Francisco and London to fully understand the underlying cause, to understand the effect of the memory leakage, and to work with Google and other search engines to remove any cached HTTP responses.

bug 影響的時間從 2016/09/22 開始:

2016-09-22 Automatic HTTP Rewrites enabled
2017-01-30 Server-Side Excludes migrated to new parser
2017-02-13 Email Obfuscation partially migrated to new parser
2017-02-18 Google reports problem to Cloudflare and leak is stopped

而以 2/13 到 2/18 的流量反推估算,大約是 0.00003% 的 request 會可能產生這樣的問題:

The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage (that’s about 0.00003% of requests).

不過不得不說 Tavis Ormandy 真的很硬,在沒有 source code 以及 Cloudflare 幫助的情況下直接打出可重製的步驟:

I worked with cloudflare over the weekend to help clean up where I could. I've verified that the original reproduction steps I sent cloudflare no longer work.

事發後完整的時間軸:

2017-02-18 0011 Tweet from Tavis Ormandy asking for Cloudflare contact information
2017-02-18 0032 Cloudflare receives details of bug from Google
2017-02-18 0040 Cross functional team assembles in San Francisco
2017-02-18 0119 Email Obfuscation disabled worldwide
2017-02-18 0122 London team joins
2017-02-18 0424 Automatic HTTPS Rewrites disabled worldwide
2017-02-18 0722 Patch implementing kill switch for cf-html parser deployed worldwide
2017-02-20 2159 SAFE_CHAR fix deployed globally
2017-02-21 1803 Automatic HTTPS Rewrites, Server-Side Excludes and Email Obfuscation re-enabled worldwide

另外在「List of Sites possibly affected by Cloudflare's #Cloudbleed HTTPS Traffic Leak」這邊有人整理出受影響的大站台有哪些 (小站台就沒列上去了)。

Akamai 阻擋 DDoS 能力的上限

這應該是最近在看 DDoS 事件中比較重要的新聞了,從這次的事件知道 Akamai 沒有能力擋下某種 620Gbps 以上的 DDoS 攻擊,而這是攻擊者已經有能力「示範」出來的量:「Akamai kicked journalist Brian Krebs' site off its servers after he was hit by a 'record' cyberattack」。

The assault has flooded Krebs' site with more than 620 gigabits per second of traffic — nearly double what Akamai has seen in the past.

然後現在 Krebs on Security 的整個站台都轉移到 GoogleProject Shield 計畫上了,接下來就是時間的考驗了:「The Democratization of Censorship」。

GitHub 又多了許多功能...

GitHub 上個禮拜推出了不少功能出來:「A whole new GitHub Universe: announcing new tools, forums, and features」。

功能多了不少,但比較亮眼的主要是 Project 的功能,界面上有點像 Trello

操作上也可以看到,一個 repository 可以開很多 project,然後在裡面移來移去:

With Projects, you can manage work directly from your GitHub repositories. Create cards from Pull Requests, Issues or Notes and organize them into custom columns, whether it’s "In-progress", "Done", "Never going to happen" or any other framework your team uses. Drag and drop the cards inside a column to prioritize them or move them from one column to another as your work progresses.

唔... 這樣好用不少 :o

在核輻射避難所建的資料中心

Nuclear Fallout Shelter 照字面翻是核放射塵碉堡,意思上算是可以對抗輻射塵的防空洞,用 Google Translate 翻出來是「核輻射避難所」,感覺也頗貼切的啦...

而 C14 project 則是 Online.net 在巴黎的核輻射避難所建立 data center 的玩意:「C14 story - Part 1 Meet Our Nuclear Fallout Shelter

在地下 26 公尺,如果一層樓三米的話,大約是已經是地下八樓到九樓的位置了:

Starting in October 2016, you will be able to store all your critical C14 data in our fallout shelter, located 26 meters underground in Paris, France.

整個計畫在 2012 年從法國政府買下來,然後開始重建:

In 2011, the French state, owner of the building, decided to move the Ponts et Chaussées' central laboratory in the Parisian suburb and started to dismantle the building.

The Ponts et Chaussées' central laboratory buildings were revamped and divided in multiple bundles to be sold and transformed in multi-unit housing. The main building and the shelter were sold separately via a public invitation to tender. Online landed the deal in September 2012 with the project to build a Datacenter. The project’s codename is DC4.

接近完工的照片看起來好棒啊:

看起來這是一系列的故事,到時候應該會有不少照片可以看...

Debian 提供 Tor Hidden Service 更新 Apt

DebianTor Project 都宣佈了這個消息,兩邊的稿子都一樣:「Debian and Tor Services available as Onion Services」、「Debian and Tor Services available as Onion Services」。

站台列表在 https://onion.debian.org/ 這邊可以看到,當你有安裝 apt-transport-tor 時,可以透過 Tor 更新:

deb tor+http://vwakviie2ienjx6t.onion/debian jessie main
deb tor+http://vwakviie2ienjx6t.onion/debian jessie-updates main
deb tor+http://sgvtcaew4bxjd7ln.onion/debian-security jessie/updates main

Tor Hidden Service 本身就有一定的安全強度,而透過 APT 抓 Debian 套件的安全性還有 GnuPG 驗證把關,這樣看起來頗不賴...

讓 Tor 的流量變大也是讓 Tor 的隱私性變得更好的一種方法 (因為目前看到新的攻擊都是靠分析 traffic pattern,所以流量變大有機會讓雜訊變多一些)。

不知道 Ubuntu 有沒有機會也上一份...

Google 將 Raspberry Pi 3 加到 AOSP 裡

GoogleAOSP 裡加入對 Raspberry Pi 3 的支援:「Google to bring official Android support to the Raspberry Pi 3」,repository 可以在「device/pifoundation/rpi3/」這邊看到,目前是空的,不過這讓大家就有很多想像了:

For now, the Pi 3 device tree is empty with only the comment "initial empty repository" accompanying it. The repository should soon start to fill with code, though.

感覺對 Raspberry Pi 注入了不少活力... (以及估值 XDDD)