nginx 1.10.2

之前在「谈谈 Nginx 的 HTTP/2 POST Bug」這邊提到了 nginx 的一個 bug:「當 HTTP/2 的第一個 request 是 POST 時連線會失敗」的問題,這個問題在 mainline 版本的 1.11.0 解決了,但 stable 版一直沒有出新版 back-porting 回來。

而剛剛看到 1.10.2 將 http2_body_preread_size 從 mainline 版本弄回來解決了:「[nginx-announce] nginx-1.10.2」。

*) Change: HTTP/2 clients can now start sending request body
   immediately; the "http2_body_preread_size" directive controls size of
   the buffer used before nginx will start reading client request body.

然後剛剛發現 Ondřej Surý 老大分別弄出了 nginx (stable 版本) 與 nginx-mainline (mainline 版本) 的 PPA,所以也可以考慮可以直接換到 mainline 上?這樣也是個方法...

把所有 HTTP 網站的 JavaScript 都關閉

一直以為 Google Chrome[*.] 只能用在開頭,剛剛測了才發現可以用在中間,所以就用這樣的方式擋下 HTTP 網站的 JavaScript:

http://[*.]

這樣就可以減少 HTTP request 被 hijack 插入 javascript 的問題...

CloudFlare 把 HTTPS Everywhere 的清單拿到 CDN 上用所推出的產品...

這個產品就如同標題所說的方式而已,做起來不難,只是一直沒人做就是了:「How we brought HTTPS Everywhere to the cloud (part 1)」。

傳統的作法是直接硬幹下去換掉,或是用 header 讓瀏覽器主動轉過去:

A naive way to do this would be to just rewrite http:// links to https:// or let browsers do that with Upgrade-Insecure-Requests directive.

但這有必須有兩個假設成立才可以:

  • Each single HTTP sub-resource is also available via HTTPS.
  • It's available at the exact same domain and path after protocol upgrade (more often than you might think that's not the case).

而 HTTPS Everywhere 則是用人力確認了哪些網站可以這樣玩。CloudFlare 利用這份清單改寫程式碼裡面的 HTTP 連結,僅可能將 HTTP 資源換成 HTTPS。算是還不錯的方式...

之後有可能再推出對 HTTP images 與 HTTP assets 的 proxy cache?

HPKP 遇到的阻礙

關於 HPKP,可以參考「HTTP Public Key Pinning 介绍」這篇介紹,寫得很清楚。

HPKP 是解決 CA 架構錯發憑證的方案 (無論是無意或是故意),像是最近吵的比較熱的 WoSign 發出 GitHub 的憑證的問題就可以用 HPKP 解。

原理上來說,就是在 HTTP header 裡面指出這個站台所允許的 Root CA 有哪些。所以跟 HSTS 一樣是走 Trust On First Use 架構,當 client 第一次連上的時候會記下資訊,之後就可以使用這個資訊來驗證。

但 HPKP 與 HSTS 不同的地方在於,HSTS 只是個 Yes/No 問題 (i.e. 是否強迫使用 HTTPS),而且通常 migrate 上去後就不會拔掉。

但 HPKP 則是要指定 Root CA,這代表不能隨便換一家簽。當你用的那家 Root CA 出包時就苦了... (就像 WoSign 免費憑證的問題)

這使得 HPKP 的實作成本過高,而且得到效益太低,另外也因為替代的方案有不少 (像是 Certificate Transparency),導致 HPKP 根本沒什麼人用:「Is HTTP Public Key Pinning Dead?」。

在 comment 有人直接拉出來統計,使用的比率反而在下降:

From my stats looking to the Alexa 1K top websites from 2015-07-26 to 2016-07-31 the number of websites NOT using HPKP increase from 99.47% to 99.58% which means almost nothing.

不過我覺得算是平行發展吧,這些驗證的技術都不怎麼衝突... HPKP 解決問題的方法非常的技術面,而 Certificate Transparency 還是走稽核路線讓 Root CA 回報每一個發出的 Certificate...

Google Chrome 56 將會對 HTTP 網站標示「Not secure」

Google Chrome 宣佈從 56 版開始,將會對 HTTP 網站標示「Not secure」:「Moving towards a more secure web」,這是 Google 給的解釋圖片:

另外還更進一步規劃之後的圖示,標成紅色警示:

藉由這樣的表現來更大力推動 HTTPS 化。

Mozilla 在考慮移除 WoSign 的 CA Root

雖然平常早就把 WoSign 移除信任,但在「Mozilla考虑对沃通CA采取行动」這邊看到有趣的消息,翻了一下 Gervase Markham 發表的原文還蠻精彩的:「Incidents involving the CA WoSign」。

第一次事件 (Incident 0) 是在 2015/04/23,攻擊者只要能夠證明他能控制某個 TCP port,就會發出 certificate:

On or around April 23rd, 2015, WoSign's certificate issuance system for their free certificates allowed the applicant to choose any port for validation. Once validation had been completed, WoSign would issue certificates for that domain. A researcher was able to obtain a certificate for a university by opening a high-numbered port (>50,000) and getting WoSign to use that port for validation of control.

設計不良造成的資安事件總是會發生。重點在於 Google 知道,但 Mozilla 完全不知道:(我講得很保守是因為這個句子在 thread 後面被澄清解釋的更慘,參考後文)

This problem was reported to Google, and thence to WoSign and resolved. Mozilla only became aware of it recently.

更嚴重的是,這次的事件在 WoSign 的稽核上沒有出現:

* This misissuance incident did not turn up on WoSign's subsequent BR audit[1].

第二次事件 (Incident 1) 是在 2015 年六月,也是資安設計的問題,當你可以拿到 WoSign 所指定的 subdomain 控制權後,你就可以拿到 parent domain 的 certificate,而這次甚至被拿到 GitHub 全系列的 certificate:

The reporter proved the problem in two ways. They accidentally discovered it when trying to get a certificate for med.ucf.edu and mistakenly also applied for www.ucf.edu, which was approved. They then confirmed the problem by using their control of theiraccount.github.com/theiraccount.github.io to get a cert for github.com, github.io, and www.github.io.

嗯,也沒通報:

* This misissuance incident was not reported to Mozilla by WoSign as it should have been (see above).

嗯,稽核也沒出來:

* This misissuance incident did not turn up on WoSign's subsequent BR audit[1].

嗯,被拿到的 domain (ucf.edu) 也沒 revoke:(可以從「crt.sh | 29647048」這邊看到)

They reported this to WoSign, giving only the Github certificate as an example. That cert was revoked and the vulnerability was fixed. However recently, they got in touch with Google to note that the ucf.edu cert still had not been revoked almost a year later.

第三次事件 (Incident 2) 則是在 2016 年七月,由於現在大多數的瀏覽器都會對 2016 後簽出的 SHA-1 憑證直接標示為不安全,而 WoSign 的 API 提供造假,讓簽名日期 (notBefore) 簽在 2015/12/20:

Using the value "1" led to a certificate which had a notBefore date (usage start date) of 20th December 2015, and which was signed using the SHA-1 checksum algorithm.

嗯,然後否認造假:

* WoSign deny that their code backdated the certificates in order to avoid browser-based restrictions - they say "this date is the day we stop to use this code"[4]. If that is true, it is not clear to us how StartCom came to deploy WoSign code that WoSign itself had abandoned.

嗯,然後還是沒有回報給 Mozilla:

* This misissuance incident was not reported to Mozilla by WoSign as it should have been.

稽核報告應該是因為這太新,還沒開始做?

另外在 thread 討論時,Google 的 Ryan Sleevi 澄清的更慘:

Clarification: In none of these incidents was Google notified proactively by WoSign. Instead, Google received communication from internal or external researchers regarding these issues, either prior to resolution or much later after the fact, and subsequently contacted WoSign regarding them.

It was only when Google found out recently that other programs were NOT notified, proactively, as had been expected, that Google shared the details it was aware of regarding various CA incidents, including those of WoSign, mentioned in this thread.

也就是說,是 Google 主動發現這些問題,並且通報 WoSign。後來過了許久發現 WoSign 沒有照規定通報其他 CA Root 管理單位 (以這邊來說是 Mozilla),於是 Google 決定主動通報其他單位,然後大~爆~炸~

在密碼學理論裡,CA 架構是靠著稽核建立信任的,這次的事情又再次證實這個問題 (但目前沒有其他好的機制可以做)。來猜測下場的話,我的預期是會像拔掉 CNNIC 的作法拔掉信任,但針對之前發出的 certificate 設為白名單 (直到過期):

OpenSSL 1.1.0

看到「OpenSSL 1.1.0 released」這篇得知大家期待已久的 OpenSSL 1.1.0 出了,在 1.1.0 的重要新功能中,對 ChaCha20 + Poly1305 的支援算是大家等很久的:

  • Support for ChaCha20 and Poly1305 added to libcrypto and libssl

由於 RC4 已經被證明不安全,OpenSSL 內變成沒有堪用的 stream cipher,這邊總算要補上來了...

另外兩個也頗有趣的:

  • Support for scrypt algorithm
  • Support for X25519

多了些東西...

SWEET32:攻 Blowfish 與 3DES

最新的攻擊算是實戰類的攻擊,理論基礎以前都已經知道了,只是沒有人實際「完成」。算是近期少數直接對演算法的攻擊,而這些演算法剛好還是被用在 TLSOpenVPN 上,所以嚴重性比較高:「SWEET32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN」。

攻擊的條件是 block cipher 的 block size,而非 key length,所以就算是 256 bits 的 Blowfish 也一樣也受到影響。

這次順利打下 Blowfish3DES。這兩個 cipher 的 block size 都是 64 bits,所以對於 birthday attack 來說只要 232 就可以搞定:

This problem is well-known by cryptographers, who always require keys to be changed well before 2n/2 blocks. However it is often minimized by practitioners because the attacks require known plaintext, and reveal only little information. Indeed, standard bodies only recommend to change the key just before 2n/2 blocks, and many implementations don't enforce any limit on the use of a key.

在 OpenVPN 打 Blowfish 的部份 (Blowfish 是 OpenVPN 預設的 cipher):

In our demo, it took 18.6 hours and 705 GB, and we successfully recovered the 16-byte authentication token.

以及 HTTPS 打 3DES 的部份 (為了相容性問題):

Experimentally, we have recovered a two-block cookie from an HTTPS trace of only 610 GB, captured in 30.5 hours.

都是有可能的等級。也該來拔掉對 IE8 的支援了... orz

前陣子在 Black Hat 上發表的 HEIST 攻擊 (對 HTTPS 的攻擊)

又是一個對 HTTPS 的攻擊:「HEIST attack on SSL/TLS can grab personal info, Black Hat」、「New attack steals SSNs, e-mail addresses, and more from HTTPS pages」。

一樣是 Compression 產生的 side-channel attack,只是這次是結合 TCP window size 的攻擊。投影片可以在「HTTP Encrypted Information can be Stolen through TCP-windows (PDF)」這邊看到。

這次的攻擊只需要在瀏覽器上插入 HTTP 產生 HTTPS 的流量,然後從旁邊看 HTTPS 連線的 TCP packet 就可以了,而且對 HTTP/2 也很有效:

而且很不幸的,目前沒有太好的解法,因為所有的攻擊手法都是照著使用者無法發現的路徑進行的 @_@

對於使用者,大量使用 HTTPS (像是 HTTPS Everywhere 這樣的套件),能夠降低政府單位與 ISP 將 javascript 插入 HTTP 連線,產生 HTTPS 的行為。

而對於網站端來說,全站都隨機產生不同長度的 HTTP header 可能是個增加破解難度的方式 (而且不會太難做,可以透過 apache module 或是 nginx module 做到),但還是可以被統計方法再推算出來。

不知道有沒有辦法只對 HTTPS 開 javascript,雖然攻擊者還是可以用 <img> 攻擊...

也許以後 HTTP/3 之類的協定會有一區是不壓縮只加密的,避開這類 compression-based attack @_@

Netflix 對 sendfile() 在 TLS 情況下的加速

Netflix 對於寫了一篇關於隱私保護的技術細節:「Protecting Netflix Viewing Privacy at Scale」。

其中講到 2012 年的 Netflix Open Connect 中的 Open Connect Appliance (OCA,放伺服器到 ISP 機房的計畫) 只有單台伺服器 8Gbps,到現在 2016 可以達到 90Gbps:

As we mentioned in a recent company blog post, since the beginning of the Open Connect program we have significantly increased the efficiency of our OCAs - from delivering 8 Gbps of throughput from a single server in 2012 to over 90 Gbps from a single server in 2016.

早期的 Netflix 走 sendfile() 將影片丟出去,這在 kernel space 處理,所以很有效率:

當影片本身改走 HTTPS (TLS) 時,其中一個遇到的效能問題是導致 sendfile() 無法使用,而必須在 userland space 加密後改走回傳統的 write() 架構,這對於效能影響很大:

所以他們就讓 kernel 支援 AES 系列加密 (包括 AES-GCM 與 AES-CBC),效能的提昇大約是 30%:

Our changes in both the BoringSSL and ISA-L test situations significantly increased both CPU utilization and bandwidth over baseline - increasing performance by up to 30%, depending on the OCA hardware version.

文章開頭也有提到選 AES-GCM 與 AES-CBC 的一些來龍去脈,主要是 AES-GCM 的安全強度比較好,另外考慮到舊的 client 不支援 AES-GCM 時會使用 AES-CBC:

We evaluated available and applicable ciphers and decided to primarily use the Advanced Encryption Standard (AES) cipher in Galois/Counter Mode (GCM), available starting in TLS 1.2. We chose AES-CGM over the Cipher Block Chaining (CBC) method, which comes at a higher computational cost. The AES-GCM cipher algorithm encrypts and authenticates the message simultaneously - as opposed to AES-CBC, which requires an additional pass over the data to generate keyed-hash message authentication code (HMAC). CBC can still be used as a fallback for clients that cannot support the preferred method.

另外 OCA 機器本身也都夠新,支援 AES-NI 指令集,效能上不是太大的問題:

All revisions of Open Connect Appliances also have Intel CPUs that support AES-NI, the extension to the x86 instruction set designed to improve encryption and decryption performance. We needed to determine the best implementation of AES-GCM with the AES-NI instruction set, so we investigated alternatives to OpenSSL, including BoringSSL and the Intel Intelligent Storage Acceleration Library (ISA-L).

不過在「Netflix Open Connect Appliance Deployment Guide」(26 July 2016 版) 這份文件裡看起來還是用多條 10Gbps 透過 LACP 接上去:

You must be able to provision 2-4 x 10 Gbps ethernet ports in a LACP LAG per OCA. The exact quantity depends on the OCA type.

可能是下一版準備要上 40Gbps 或 100Gbps 的準備...?