NIC of India 簽發 Google 的 certificate

Google 昨天發出的公告,發現 NIC of India 發出了幾張 Google 網域的 SSL 憑證:「Maintaining digital certificate security」。

NIC of India 所取得的憑證權限是 India CCA 所發出的 Intermediate CA 權限。而目前 India CCA 只在 Microsoft Root Store 上面有使用,所以會受到影響的範圍是 Windows 上的 IE 以及應用程式,而因為 Google Chrome 有白名單保護,至少在 Google 的網域裡面是不受到直接傷害...

事情還在調查 (還在戳湯圓?),歷史總是不斷地重演...

最佳化 nginx 的 TLS Time to First Byte (TTTFB)

在「Optimizing NGINX TLS Time To First Byte (TTTFB)」這篇文章裡在討論要如何讓 nginx 的 TLS Time to First Byte (TTTFB) 盡可能短。

可以看到文章裡面用到兩個方法,一個是修改 nginx 的程式碼縮小 TLS record size。我對是覺得頗危險,尤其是作者的改法不知道有什麼 side-effect... (要注意 nginx 裡面直接拿 NGX_SSL_BUFSIZEBIO_set_write_buffer_size 使用,這代表有可能還有其他的地方也是這樣搞?)

第二個方法是開啟 TLS False Start,目前主流的瀏覽器都陸陸續續支援了。

這是文章作者的測試:

可以看到時間減少的相當多。

現在是期望作者這篇文章的測試可以讓 patch 合併回 mainstream 後再用,這樣有比較多人 audit...

Amazon CloudFront 的新增功能

Amazon CloudFront 新增了 Whitelist Header 的功能:「Deliver Custom Content With CloudFront」。

如同在 post 裡說明的:

If you choose the Whitelist option, each header that you add to the list becomes part of the cache key for the URLs associated with the distribution.

有點像是 HTTP 協定裡 Vary 想要解決的問題,只是做在 CDN 這端。這個功能蠻多 CDN 都有,AWS 總算補上了...

這次除了可以針對 custom HTTP header 處理外,CloudFront 還做了不少事情:

  • Mobile Device Detection
  • Geo-Targeting
  • Multi-Site Hosting
  • Protocol Detection
  • CORS (Cross Origin Resource Sharing)

前兩項還蠻有意義的,這代表會有人幫你更新資料。而 CloudFront 總算是支援 CORS 了...

Google 也 fork 一個 OpenSSL 出來了... (BoringSSL?)

Google 也跳下去 fork 一個 OpenSSL 出來了,這次的主力是放在 Android 以及 Chrome 上:「BoringSSL」。

BoringSSL 是暫時性的名稱,不過在「boringssl - Git at Google」這邊已經用這個名稱了...

另外一個重要的說明是 license 的部份:

We have already relicensed some of our prior contributions to OpenSSL under an ISC license at their request and completely new code that we write will also be so licensed.

將會改用 ISC license

GlobalSign 提供 Open Source 專案免費的 SSL Certificate

GlobalSign 提供 Open Source 專案免費的 SSL Certificate:「Free SSL Certificate for Open Source Projects」。

不過看了看需求還蠻龜毛的,不如自己花個 USD$10/year 還比較方便。如果不在意時間成本的話就申請吧,我猜實際上也不會有多少專案申請...

Google 在 Chrome 內的 PGP:End-to-End

Google 前天發表了 Chrome 裡面的 PGP 實做套件:「Making end-to-end encryption easier to use」。

目前只放出了 source code,並沒有在 Chrome Web Store 上架,這點在網站上就直接說明了,他們目前認為目前沒有被足夠的人檢查過,所以請不要傳到 Chrome Web Store 上:

Since this is source, I could just build this and submit it to the Chrome Web Store

Please don’t do this.

The End-To-End team takes its responsibility to provide solid crypto very seriously, and we don’t want at-risk groups that may not be technically sophisticated — journalists, human-rights workers, et al — to rely on End-To-End until we feel it’s ready. Prematurely making End-To-End available could have very serious real world ramifications.

One of the reasons we are doing this source code release is precisely so that the community as a whole can help us make sure that we haven’t overlooked anything in our implementation of End-To-End.

Once we feel that End-To-End is ready, we will release it via the Chrome Web Store ourselves.

而為了鼓勵大家去找問題,雖然這是很新的軟體,但已經將 End-to-End 直接納入 Vulnerability Reward Program 裡:

And we mean it: our Vulnerability Reward Program offers financial awards for finding security bugs in Google code, including End-to-End.

不過傳統的方法還是會更可靠一些,畢竟 JavaScript 沒辦法很仔細控制記憶體內容,在放掉的記憶體空間內可能會包含某些未加密的資訊,甚至是 private key 的資訊。

OpenSSL 安全通報連發...

熱騰騰的「OpenSSL Security Advisory [05 Jun 2014]」:

  • SSL/TLS MITM vulnerability (CVE-2014-0224)
  • DTLS recursion flaw (CVE-2014-0221)
  • DTLS invalid fragment vulnerability (CVE-2014-0195)
  • SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198)
  • SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298)
  • Anonymous ECDH denial of service (CVE-2014-3470)

這太熱鬧了,第一個 security issue 可以在 MITM 的情況下,強迫選用比較差的 cipher:

An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers.

第三個則有可能直接爆破執行程式碼:

A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server.

接下來幾天對 SA 來說又是無止盡的升級地獄...

CVE-2014-0476:掃 Rootkit 的程式變成 Rootkit?

Twitter 上看到居然用這張圖:

CVE-2014-0476 比較完整的說明可以看 Red Hat 的 Bugzilla 上給的說明:「Bug 1104455 – CVE-2014-0476 chkrootkit: local privilege escalation」。

阿彌陀佛...

Defensive BASH Programming

2012 年的老文章了,不確定是 Zite 上看到,還是 Hacker News Daily 上看到的:「Defensive BASH Programming」。

不是給初學者看的文件,而是寫給對 shell script 有一定基礎的人。針對要怎麼樣才能寫出容易維護,而且問題又少的 code 所提出來的準則,但也未必適用於每一個人 (或是團體)。

這篇文章的好處是有說明為什麼這樣規範,重點在吸收這些想法。