Tag: openssl

實際比較 Linode 的 Dedicated 主機與 AWS 的 c5.*

先前有提到 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 架構差異造成的：

  • 在 cipher 類的測試我只測了 AES (目前的主流)，小的 block (16/64/256 bytes) 時 AMD 會輸一些，但大的 block (1024/8192/16384 bytes) 反而會贏不少。
  • 在 hash 類的測試中，跑 MD5 時 Linode 則是輸一些，但 SHA1 反而是贏一些，然後 SHA256 時效能好到爆炸贏了一倍 XDDD
  • 在 public key 類的測試我測了 RSA，則是 Linode 輸的蠻慘的...

如果考慮到價位大約只有 AWS 的一半，應該是還不錯...

OpenSSL 的版號規則打算要改變...

在「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 的授權而加的例外條款，這次又要再修嗎...？

升級 nginx 後關不掉的 TLSv1.3...

我 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 簽的憑證

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 端的錯誤設定。

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 的實做...