CloudFlare 對 Go 上面加解密系統的改善

CloudFlare 發佈了自己版本的 Go,修改了其中的 crypto subsystem:「Go crypto: bridging the performance gap」。

文章花了不少篇幅介紹 AEAD (Authenticated Encryption with Associated Data),而目前 CloudFlare 支援的是 AES-GCM 與 ChaCha20-Poly1305,也是兩大主流,分別佔了 60% 與 10% 的 HTTPS 流量:

As such today more than 60% of our client facing traffic is encrypted with AES-GCM, and about 10% is encrypted with ChaCha20-Poly1305.

CloudFlare 提供的改進使得速度快很多,並且有考慮到 side-channel attack 的問題:

Both implementations are constant-time and side-channel protected.

                         CloudFlare          Go 1.4.2        Speedup
AES-128-GCM           2,138.4 MB/sec          91.4 MB/sec     23.4X

P256 operations:
Base Multiply           26,249 ns/op        737,363 ns/op     28.1X
Multiply/ECDH comp     110,003 ns/op      1,995,365 ns/op     18.1X
Generate Key/ECDH gen   31,824 ns/op        753,174 ns/op     23.7X
ECDSA Sign              48,741 ns/op      1,015,006 ns/op     20.8X
ECDSA Verify           146,991 ns/op      3,086,282 ns/op     21.0X

RSA2048:
Sign                 3,733,747 ns/op      7,979,705 ns/op      2.1X
Sign 3-prime         1,973,009 ns/op      5,035,561 ns/op      2.6X

AES-GCM 與 EC 的改善主要是利用 CPU 指令集加速:

[T]herefore we created assembly implementations of Elliptic Curves and AES-GCM for Go on the amd64 architecture, supporting the AES and CLMUL NI to bring performance up to par with the OpenSSL implementation we use for Universal SSL.

不過 RSA 的部份雖然幅度也不小 (比起 AES 與 EC 的部份是不大,不過純就數字來看,快了一倍多也不少),不過沒提到怎麼改善,只稍微帶過:

In addition the fork includes small improvements to Go's RSA implementation.

Mozilla 對非 HTTPS 站台的抵制

Mozilla Security Blog 上 Richard Barnes (Firefox Security Lead) 宣佈對非 HTTPS 站台的抵制政策。規劃在之後的 Firefox 新功能限定在 HTTPS 網站上:「Deprecating Non-Secure HTTP」。

詳細的日期還沒有確定,但預定分成兩個階段:

  1. Setting a date after which all new features will be available only to secure websites
  2. Gradually phasing out access to browser features for non-secure websites, especially features that pose risks to users’ security and privacy.

在「Deprecating Non-Secure HTTP (PDF)」這邊有 FAQ 可以參考。

Mozilla 移除 e-Guven CA Certificate

因為稽核過期失效,Mozilla 決定移除 e-Guven 的 Root CA:「Removing e-Guven CA Certificate」,對應的 Bugzilla 連結出自「Remove E-Guven root certificate from NSS」:

Issuer Field:
CN = e-Guven Kok Elektronik Sertifika Hizmet Saglayicisi
O = Elektronik Bilgi Guvenligi A.S.
C = TR

SHA-1 Fingerprint: DD:E1:D2:A9:01:80:2E:1D:87:5E:84:B3:80:7E:4B:B1:FD:99:41:34

Google Chrome 裡面也有引入這個 root CA,過幾天應該會被提出來處理:

Google 對 GitHub 先前遭受 GFW 的 DDoS 攻擊的分析

Google Online Security 分析了前陣子 GitHub 被 DDoS 攻擊的行為:「A Javascript-based DDoS Attack as seen by Safe Browsing」。

透過 GoogleSafe Browsing,針對 baidu.com 這個網域的 injection 情況分析:

可以看得出來分成多個不同階段攻擊。其中 AWSCloudFront 承受了不小的壓力,不過畢竟是商用水準的 CDN,沒那麼容易垮掉。後來則是攻擊 GitHub 造成影響而上了新聞。

最終還是繼續推廣 TLS,可以避免中間被 injection 攻擊:

Had the entire web already moved to encrypted traffic via TLS, such an injection attack would not have been possible.

SSL Labs 對 RC4 的退役計畫

SSL Labs 的「SSL Server Test」是個經常被拿來檢測 SSL/TLS 相關設定的服務。

這兩天公佈了對 RC4 的退役計畫:「SSL Labs RC4 Deprecation Plan」。

分成兩個階段進行。

第一個階段會在五月啟用,對於因為需要支援舊的 client 而針對 SSLv3/TLSv1 + RC4 組合的,會給予 B 評價。而全面支援 RC4 的 (包括 TLSv1.1+) 則會給予 C 評價。

到了第二階段 (暫定九月),全面支援 RC4 的將會給予最低的 F 評價。

iOS 8 的 DoS 攻擊:強制無限重開機

Twitter 上看到別人 retweet 的新聞:

RSA Conference 發表的 0-day exploit:「iOS 8 Vulnerability Lets Hackers Crash Any iPhone and iPad Within Wi-Fi Range」。

Adi Sharabani and Yair Amit of Mobile security firm Skycure presented their latest research, titled "No iOS Zone", at the RSA security conference in San Francisco on Tuesday.

示範影片:

起因自 iOS 對惡意 SSL certificate 的處理會造成重開機:

All an attacker need to do is create a malicious wireless network that uses the Wi-Fi connection in order to manipulate SSL certificates sent to iOS handsets.

目前最好的解法是關閉無線網路:

Another best measure is to simply avoid the free wireless networks you find in the street providing public Internet access.

Mozilla 提供了 SSL/TLS 設定懶人包

MozillaMozilla SSL Configuration Generator 提供了各種 server side 的設定:

以及不同等級的設定 (Modern、Intermediate、Old),另外還有 HSTS 的選項可以選擇。

對於 security 的東西我不是很喜歡用 generator (因為我覺得既然是資安相關的東西,要盡可能知道每個細節),但算是一種推廣吧,看了一下設定也都還算合理...

CA/Browser Forum 討論網域認證與 CNNIC 的事情

兩個禮拜前 CA/Browser Forum 的會議記錄,討論了網域認證以及 CNNIC 的事情:「Minutes of CA-Browser Forum Meeting – 2 April 2015」。

由於 US-CERT 的關切,看起來「認證」這件事情 CA/Browser Forum 暫時不會有改善了:

The consensus was that US-CERT was incorrect in saying the email method of domain confirmation presents a vulnerability, that no changes were required, and that the Forum did not need to make any formal response to the US-CERT advisory.

另外是 CNNIC 的事情,也表達「甘我屁事」:

CNNIC sub-CA issue: The members discussed the recent CNNIC sub-CA issue, and noted that Google had recently published its response. Gerv stated that Mozilla was about to publish its response, which would be similar to the Google response. There was consensus that the Forum did not need to take any action.

很官僚的會議結論...

Google 的 QUIC 擴大實驗

QUIC (Quick UDP Internet Connections) 是 Google 發明的協定,主要是希望改善 TCP + TLS 的反應速度,目前是用來加速 Google Chrome 與 Google server 之間的連線。

與 SPDY 或 HTTP/2 不同的地方在於使用了 UDP,這降低了 TCP packet loss 造成的壅塞現象,以及 TCP 3-way handshake 的成本,而這兩點在行動平台上都特別明顯。

依照最新的說法,目前 Google Chrome 連到 Google server 大約有一半的連線會走 QUIC:「A QUIC update on Google’s experimental transport」。

Today, roughly half of all requests from Chrome to Google servers are served over QUIC and we’re continuing to ramp up QUIC traffic, eventually making it the default transport from Google clients — both Chrome and mobile apps — to Google servers.

而在 YouTube 的改善也很大:

These benefits are even more apparent for video services like YouTube. Users report 30% fewer rebuffers when watching videos over QUIC. This means less time spent staring at the spinner and more time watching videos.

由於效果不錯,他們打算要換更多...

PCI DSS 的更新:PCI DSS 3.1

PCI DSS 3.1 出了:「PCI COUNCIL PUBLISHES REVISION TO PCI DATA SECURITY STANDARD — PCI DSS 3.1 and supporting guidance helps organizations address vulnerabilities within SSL protocol that put payment data at risk; PA-DSS revision to follow —」(PDF)。

與 3.0 相比,修正了 SSL 與 TLS 的安全性問題。分成兩大塊討論,對於新的系統:

  • 禁止使用 SSL 與早期的 TLS (包括了 TLS 1.0 與 TLS 1.1 的某些設定)。

而對於舊的系統:

  • 在 2016 年 6 月 30 日後,禁止使用 SSL 與早期的 TLS。
  • 在這之前,不符合上述條件的設備必須修正到可以防禦已知的 SSL 與 TLS 問題。
  • 對於 POS (Point-of-sale) 與 POI (Point-of-interaction) 系統則是例外處理:確認可以防禦已知 SSL 與 TLS 問題的話,期限後仍然可以使用。