幹壞事是進步最大的原動力
AWS ACM 推出了 Private CA 服務：「How to host and manage an entire private certificate infrastructure in AWS」。
以前需要 Private CA 的話，會找個地方丟 Root CA 的 key，然後有權限的人可以連到那台機器上跑 OpenSSL 指令生出對應的 SSL certificate，現在 AWS 則是利用 HSM 架構提供服務：
主要是因為 HSM 的關係，安全性會比較好... 另外也因為是 AWS 服務的關係，上面可以看到相關的記錄，相較於以前的作法安全不少。
因為先前從 Homebrew 跳到 MacPorts 了，剛好有機會重新弄 pyenv，結果發現要解決的問題不少...
第一個遇到的是需要的 library 抓不到的問題，找了官方說明「Common build problems」後知道要自己加上一些環境變數讓 compiler 抓。
解決之後發現 pyenv 會自己編一個 openssl 版本給 Python 用，不會裝到系統內，但是又會因為 /usr/local/opt/ 寫不進去而失敗，所以給他一個可以寫入的目錄。
接下來是 zlib 的路徑也不在前面設定的目錄裡而抓不到，所以得想辦法再找出來塞到環境變數內... 也就是「Install failed, "zlib not available" on macOS Mojave #1219」這篇給的方法。
最後是這樣：
sudo mkdir /usr/local/opt; sudo chown "$(id -u):$(id -g)" /usr/local/opt LDFLAGS="-L/usr/local/opt/openssl/lib" CPPFLAGS="-I/usr/local/opt/openssl/include" CFLAGS="-I/usr/local/opt/openssl/include -I$(xcrun --show-sdk-path)/usr/include" pyenv install 3.7.3
裝完後可以發現 /usr/local/opt/ 裡面沒有檔案 (但生了幾個空的目錄出來)，但總算是裝起來了...
先前有提到 Linode 出了 Dedicated 主機：「Linode 推出 Dedicated CPU Instances」，現在找機會測試看看，拿了 Linode 的 Dedicated (4GB) 與 AWS 的 c5.large 比較，同樣都是 2 vCPU 與 4GB RAM。
這邊用了 n-st/nench 與 OpenSSL 的 speed (包括了 aes、md5、rsa、sha1 與 sha256) 測試，我把結果都貼到這邊：「Linode (Dedicated 4GB) v.s. AWS (c5.large)」。
可以看到在 CPU 方面主要的差異是 Linode 用的是 AMD，而 AWS 用的是 Intel，所以就會有蠻多不同的數字表現...
如果仔細看 OpenSSL 的測試數據，可以看到不同演算法的差異還蠻大的，馬上可以想到的應該是硬體加速方式與 cache 架構差異造成的：
如果考慮到價位大約只有 AWS 的一半，應該是還不錯...
在「The Holy Hand Grenade of Antioch」這邊看到 OpenSSL 的版號規則要改變了，變得比較接近 Semantic Version 的架構。
本來是 MAJOR.MINOR.FIX[PATCH] 這樣的形式，之後打算改成 MAJOR.MINOR.PATCH，不過現有的 1.1.1 與 1.0.2 會先維持原來的規則：
The current 1.1.1 and 1.0.2 versioning scheme will remain unchanged.
另外下一個大版本會是 3.0.0，而不是 2.0.0 (被其他計畫用掉了，所以為了避免混淆中獎，就直接跳過去了)：
The current development version (master branch) will be identified as version 3.0.0. The OpenSSL FIPS module currently under development will also follow this versioning scheme. We are skipping the 2.0.0 major version because the previous OpenSSL FIPS module has already used this number.
另外授權也變成 Apache License 2.0 了：
OpenSSL version 3.0.0 will be the first version that we release under the Apache License 2.0. We will not be applying the Apache License to earlier releases of OpenSSL.
我記得 Apache License 2.0 跟 GPLv2 是不相容的... 本來使用 OpenSSL 的軟體為了 OpenSSL 的授權而加的例外條款，這次又要再修嗎...？
我 blog 的 nginx 是用 ondrej 的版本，最近他把套件加上 TLSv1.3 的支援 (主要是 OpenSSL 1.1.1 出了)，但不知道是哪個環節出問題了，現在 TLSv1.3 關不掉 XDDD
而且包起來的 OpenSSL 很奇怪，不管什麼情況都會把 TLSv1.3 的三個 cipher 放進來：
gslin@colo-vultr-1 [~] [17:38] openssl ciphers -v 'xxx' TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
然後 nginx 只設 TLSv1.2 的情況下，用 SSL Labs 的網站掃還是會有 TLSv1.3：
ssl_protocols TLSv1.2;
然後還有遇到改了 cipher 後，跑 pkill -1 nginx 之後 client 端會回報沒有任何 cipher 可以用，直到跑了 service nginx restart 後就好的情況...
建議想用的人再等一下...
OpenLDAP 伺服器可以吃 Let's Encrypt 發的憑證以提供 LDAPS 服務，只是 SSL 設定方法跟其他軟體不太一樣，第一次設會花不少時間...
這邊的檔案目錄是以 Dehydrated 申請 Let's Encrypt 的憑證來設定。官方推薦的 Certbot 應該也有類似的檔案：
TLSCACertificateFile /etc/dehydrated/certs/x.y.z/chain.pem TLSCertificateFile /etc/dehydrated/certs/x.y.z/cert.pem TLSCertificateKeyFile /etc/dehydrated/certs/x.y.z/privkey.pem
這樣不管 Let's Encrypt 拿 Let’s Encrypt Authority X3 (目前的主力憑證) 還是 Let’s Encrypt Authority X4 (備用的憑證) 簽，OpenLDAP 這邊才會串出正確的 certficiate chain。(用 OpenSSL 的 s_client -connect x.y.z:636 與 ldapsearch 測過)
要找問題的話，ldapsearch 有 -v (verbose) 與 -d 9 (debug) 可以看連線過程的細節，拿著錯誤訊息去餵搜尋引擎會有不少幫助...
在找資料時發現網路上有不少文件教大家直接在 client 端的 /etc/ldap/ldap.conf 修改 TLS_REQCERT 的值，從預設的 demand 改成 allow (或是 never)，但這樣將強制檢查的條件改弱，安全性反而降低了。比較好的方式還是修正 server 端的錯誤設定。
OpenSSL 1.1.1 推出了：「OpenSSL 1.1.1 Is Released」。先前在「OpenSSL 1.1.1 將支援 TLS 1.3」這邊有提到 OpenSSL 當時就計畫要等 TLSv1.3 出了才會釋出 1.1.1，結果這一等就是一年多...
這樣後續應該會有人包 PPA 出來讓大家用了...
看到 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」，這也熬了一年啊... 支援後會就有很多軟體可以直接套用了，可以來期待了。
先說結論，綜合網路與 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」。
我這邊看到的情況是這樣。以各家離台灣最近的點來看：
另外第五張的 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 的 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 而不會出現錯誤訊息，但暫時還不會有效果...