手機上用 FPGA 的想法...

在「Apps with hardware: enabling run-time architectural customization in smart phones」這邊看到去年就有論文在討論在手機上使用 FPGA 的想法...

的確現在 FPGA 的價錢其實是蠻平價的了... 除了透過 GPU 加速外,FPGA 聽起來也是個不錯的方向 @_@

最直接的例子就是 AES 運算來看,可以看到比現在最快的實做快了半個數量級,大約三倍?(跟支援硬體加速的 OpenSSL 比,看格子大約是半格,也就是 100.5,約 3.16 倍)。

而如果是純軟體的應用,有些會差到四個數量級... (萬?)

OpenSSL 1.1.1 將支援 TLS 1.3

OpenSSL 的文章「Using TLS1.3 With OpenSSL」提到了:

The forthcoming OpenSSL 1.1.1 release will include support for TLSv1.3.

另外也提到了 TLS 1.3 的標準是 blocker,在 TLS 1.3 沒出來前不會出 OpenSSL 1.1.1:

OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is finalised.

OpenSSL 實做的 TLS 1.3 支援了這些 cipher:

  • TLS13-AES-256-GCM-SHA384
  • TLS13-CHACHA20-POLY1305-SHA256
  • TLS13-AES-128-GCM-SHA256
  • TLS13-AES-128-CCM-8-SHA256
  • TLS13-AES-128-CCM-SHA256

GCM 的部份不算意外,比較特別的是包括了 ChaCha20Poly1305 (喊很久了),另外包括了 CCM mode 的實做...

OpenSSL 將轉為 Apache 2.0 License

OpenSSL 最近打算把原本的 license 換成 Apache License, Version 2.0:「Licensing Update」。

主要的原因是希望相容於現有大多數的 open source project:

OpenSSL Re-licensing to Apache License v. 2.0 To Encourage Broader Use with Other FOSS Projects and Products

但這非常詭異啊,舊的 license 最大的問題就是與 GPLv2 不相容,而預定要換的 AL 2.0 也還是不相容啊,搞屁啊。

Alpine Linux 決定將 OpenSSL 換成 LibreSSL

之前看到 Alpine Linux 是從 Docker 這邊看到的,可以弄出還蠻小巧的 image...

前幾天看到他們宣佈打算將 OpenSSL 換掉,換成 LibreSSL:「[alpine-devel] Alpine edge has switched to libressl」。而且理由也講的頗直接,覺得 OpenSSL 的改善速度還是不滿意,而且市場上有其他還不錯的方案可以選:

While OpenSSL is trying to fix the broken code, libressl has simply removed it.

這樣 LibreSSL 又多了生力軍,之前比較大的應該只有 OpenBSD...

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

多了些東西...

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 的準備...?

OpenSSL 的 DSA 被 Side-channel attack 打爆

在「Make Sure DSA Signing Exponentiations Really are Constant-Time」這篇文章裡面,直接透過 end-to-end 的 timing attack 打爆 (也就是透過 internet 觀察攻擊),而不需要在同一台機器上對 cache 之類的區域攻擊:

A unique feature of our work is that we target common cryptographic protocols. Previous works that demonstrate cache-timing key-recovery attack only target the cryptographic primitives, ignoring potential cache noise from the protocol implementation. In contrast, we present end-to-end attacks on two common cryptographic protocols: SSH and TLS. We are, therefore, the first to demonstrate that cache-timing attacks are a threat not only when executing the cryptographic primitives but also in the presence of the cache activity of the whole protocol suite.

而且次數相當的少,就可以 key recovery:

260 SSH-2 handshakes to extract a 1024/160-bit DSA host key from an OpenSSH server, and 580 TLS 1.2 handshakes to extract a 2048/256-bit DSA key from an stunnel server.

CVE 編號為 CVE-2016-2178OpenSSL 全系列 (包括 fork 出去的版本) 與 OpenSSH 只要是 DSA 的實作都中獎...

Google Chrome 51 出版,SPDY 被拔掉,HTTP/2 只支援 ALPN

Google Chrome 剛剛出了 51 版:「Stable Channel Update」。

除了界面的改變外,對效能最主要的改變就是 SPDY 被拔掉,HTTP/2 的 NPN 支援也被拔掉:「Transitioning from SPDY to HTTP/2」:

To better align with Chrome's release cycle, SPDY and NPN support will be removed with the release of Chrome 51.

又有一波 migrate 功夫要做了...

最近的兩個安全性漏洞:OpenSSL、ImageMagick

OpenSSL 的安全性漏洞公告:「OpenSSL Security Advisory [3rd May 2016]」。ImageMagick 的安全性漏洞說明頁:「ImageTragick」。

CVE-2016-2107 是修 Lucky 13 問題時沒修好造成的:

This issue was introduced as part of the fix for Lucky 13 padding attack (CVE-2013-0169). The padding check was rewritten to be in constant time by making sure that always the same bytes are read and compared against either the MAC or padding bytes. But it no longer checked that there was enough data to have both the MAC and padding bytes.

CVE-2016-2108 是組合技,從兩個「看似無害」的安全性問題開始:

This vulnerability is a combination of two bugs, neither of which individually has security impact.

The first bug (mishandling of negative zero integers) was reported to OpenSSL by Huzaifa Sidhpurwala (Red Hat) and independently by Hanno Böck in April 2015. The second issue (mishandling of large universal tags) was found using libFuzzer, and reported on the public issue tracker on March 1st 2016.

然後 Google 的人找出來可以打穿:

The fact that these two issues combined present a security vulnerability was reported by David Benjamin (Google) on March 31st 2016.

另外隔壁棚的 ImageMagick 安全性問題是個慘劇,是個 RCE 等級的,而且 exploit 已經在外面跑了:

One of the vulnerabilities can lead to remote code execution (RCE) if you process user submitted images. The exploit for this vulnerability is being used in the wild.

OpenSSL 1.1.0 的 Release Notes 先放出來了 (現在是 Beta 1)

雖然才 Beta 1,但 OpenSSL 先放出 1.1.0 的 Release Notes 了:「OpenSSL 1.1.0 Series Release Notes」。

有幾個新的功能以及重大的改變,包括了對 ChaCha20Poly1305 的支援,並且把 SSLv2、RC4、所有 40bits 與 56bits 的 cipher 拔掉,然後支援 Certificate Transparency

讓人頗期待... 不知道來不來得及跟上 Ubuntu 16.04