OpenSSL 1.1.1 推出了：「OpenSSL 1.1.1 Is Released」。先前在「OpenSSL 1.1.1 將支援 TLS 1.3」這邊有提到 OpenSSL 當時就計畫要等 TLSv1.3 出了才會釋出 1.1.1，結果這一等就是一年多...
這樣後續應該會有人包 PPA 出來讓大家用了...
Tag: openssl
Home » Posts tagged "openssl"
RFC 8446：TLS 1.3
看到 RFC 8446 (The Transport Layer Security (TLS) Protocol Version 1.3) 正式推出了，也就是 TLS 1.3 正式成為 IETF 的標準 (Standards Track)。
Cloudflare 寫了一篇文章「A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)」描述了 TLS 1.3 的特點，有興趣的人可以看一看，尤其是 1-RTT 的部份對效能幫助很大 (0-RTT 因為 replay attack 問題，我應該暫時都不會考慮，要等到有一個合理的防禦模型出來)。
另外一個是 OpenSSL 目前最新版是 1.1.0h，當初就決定要等 TLS 1.3 正式成為標準才會出 1.1.1 (參考「OpenSSL 1.1.1 將支援 TLS 1.3」，這也熬了一年啊... 支援後會就有很多軟體可以直接套用了，可以來期待了。
HiNet 與 DigitalOcean、Linode、Vultr 的封包情況
先說結論，綜合網路與 CPU 的情況，我剛好跟下面提到的文章給出相反的選擇 (i.e. 完全不會選 DigitalOcean)。如果是需要 latency 低的品質我會選 Linode 的東京新機房 Tokyo 2，如果不需要 latency 的我會選 Vultr 的 USD$2.5/month 方案 (目前只在邁阿密與紐約有)。
看到「2018/06 台灣 5USD 虛擬主機網路延遲測試」這篇就來推廣一下 SmokePing 這個工具。這個工具可以做很多事情，但最常看到的用途還是做網路品質監控，先前在 K 社的時候就有個做個公開的站台可以看，後來接手的人也繼續維護著 (畢竟看這些圖有種治癒感？)：「smokeping.kkbox.com.tw」。
不過 K 社的 SmokePing 裡面大多數是從固網機房端監控，而固網機房端的 Internet 品質一般來說都會比家用型的好很多，尤其是國際頻寬的部份。所以我也在我家裡用 PPPoE 版本的固定 IP 做了一份：「https://home.gslin.org/smokeping/」，這邊的設定檔放在 GitHub 上的 gslin/smokeping-config.d 上。
而我剛好有把這三家 VPS 的 SmokePing 都做起來：「SmokePing Latency Page for DigitalOcean」、「SmokePing Latency Page for Linode」、「SmokePing Latency Page for Vultr」。
我這邊看到的情況是這樣。以各家離台灣最近的點來看：
- 第一張圖的 DigitalOcean 沒有東京的點，而新加坡的 latency 在這幾個月其實變差不少，現在大約要 90ms (扣掉光世代的 10ms)。
- 第二跟第三張圖的 Linode (分別是 Tokyo 1 與 Tokyo 2) 其實可以看到新機房 Tokyo 2 的 latency 比舊機房 Tokyo 1 還好。
- 第四張圖的 Vultr 則是狀況變化很多，但不管怎麼走，latency 大致上都還是比新加坡好。
另外第五張的 Vultr 則是紐約的點，latency 超高 (畢竟繞了半個地球)，但 packet loss 不高，品質還算穩定。
speedtest-sgp1.digitalocean.com (DigitalOcean Singapore 1)
speedtest.tokyo.linode.com (Linode Tokyo)
speedtest.tokyo2.linode.com (Linode Tokyo 2)
hnd-jp-ping.vultr.com
nj-us-ping.vultr.com
另外是之前有痛到的部份，先前因為需求而需要在 PHP 5.6 上跑 WordPress，真的實際跑起來後發現超慢 (畢竟這兩個要快得想不少辦法)，去找問題後發現 DigitalOcean 機器的 CPU 真的太慢，後來把這組需求搬去 Linode (在 CPU 與網路之間取個合理的平衡點)。
在各家 VPS 上用 Ubuntu 16.04 跑 openssl speed md5 可以看出一些資料：
DigitalOcean：
Doing md5 for 3s on 16 size blocks: 5465798 md5's in 3.00s Doing md5 for 3s on 64 size blocks: 3761125 md5's in 3.00s Doing md5 for 3s on 256 size blocks: 1835218 md5's in 2.99s Doing md5 for 3s on 1024 size blocks: 582162 md5's in 2.96s Doing md5 for 3s on 8192 size blocks: 102995 md5's in 2.97s Doing md5 for 3s on 16384 size blocks: 47177 md5's in 2.99s
Linode：
Doing md5 for 3s on 16 size blocks: 11510700 md5's in 3.00s Doing md5 for 3s on 64 size blocks: 8361353 md5's in 2.99s Doing md5 for 3s on 256 size blocks: 3751929 md5's in 3.00s Doing md5 for 3s on 1024 size blocks: 1169457 md5's in 3.00s Doing md5 for 3s on 8192 size blocks: 157678 md5's in 2.99s Doing md5 for 3s on 16384 size blocks: 78874 md5's in 3.00s
Vultr (這是 USD$2.5/month 的方案)：
Doing md5 for 3s on 16 size blocks: 14929209 md5's in 2.97s Doing md5 for 3s on 64 size blocks: 9479563 md5's in 2.97s Doing md5 for 3s on 256 size blocks: 4237907 md5's in 2.98s Doing md5 for 3s on 1024 size blocks: 1320548 md5's in 2.98s Doing md5 for 3s on 8192 size blocks: 161940 md5's in 2.96s Doing md5 for 3s on 16384 size blocks: 86592 md5's in 2.98s
然後補一個 AWS 的 t2.nano (在還有 CPU credit 可以全速跑的情況下)，不過這不公平，參考用而已：
Doing md5 for 3s on 16 size blocks: 19257426 md5's in 3.00s Doing md5 for 3s on 64 size blocks: 11168752 md5's in 2.99s Doing md5 for 3s on 256 size blocks: 4959879 md5's in 3.00s Doing md5 for 3s on 1024 size blocks: 1518690 md5's in 3.00s Doing md5 for 3s on 8192 size blocks: 203910 md5's in 3.00s Doing md5 for 3s on 16384 size blocks: 102321 md5's in 2.99s
nginx 推出了 1.14.0 的 PPA
nginx 的 PPA (「NGINX Stable : “Nginx” team」這個) 推出了 1.14.0 的版本。
這個版本使用了 OpenSSL 1.1.0，對 cipher 這塊最大的差異主要是包括了 CHACHA20 與 AESCCM 演算法。後者的 CCM 指的是 CCM mode，這是當時 OCB mode 因為專利問題而發展出來的演算法，就目前的效能測試沒有 GCM 好，而且普及率也沒有 GCM 高，放進來應該是當備案 (當 GCM 有狀況時標準裡至少有方案可以選)：
The catalyst for the development of CCM mode was the submission of OCB mode for inclusion in the IEEE 802.11i standard. Opposition was voiced to the inclusion of OCB mode because of a pending patent application on the algorithm. Inclusion of a patented algorithm meant significant licensing complications for implementors of the standard.
真正的重點在於 CHACHA20 的引入，讓 OpenSSL 重新有主流 stream cipher 可以使用了... 上一個主流 stream cipher RC4 被打趴好久了。
不過 TLSv1.3 要等 OpenSSL 1.1.1 才有 (參考「Using TLS1.3 With OpenSSL」這邊的說明)，目前可以在設定檔裡面設 TLSv1.3 而不會出現錯誤訊息，但暫時還不會有效果...
手機上用 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 的部份不算意外，比較特別的是包括了 ChaCha20 與 Poly1305 (喊很久了)，另外包括了 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 的準備...？