openssl

Home » Posts tagged "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 後就好的情況...

建議想用的人再等一下...

November 5, 2018 Gea-Suan LinComputer, Murmuring, Network, Privacy, Security, Service, SoftwareNo Comment

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

October 8, 2018 Gea-Suan LinComputer, Murmuring, Network, Privacy, Security, Service, SoftwareNo Comment

OpenSSL 1.1.1 出版，TLSv1.3！

OpenSSL 1.1.1 推出了：「OpenSSL 1.1.1 Is Released」。先前在「OpenSSL 1.1.1 將支援 TLS 1.3」這邊有提到 OpenSSL 當時就計畫要等 TLSv1.3 出了才會釋出 1.1.1，結果這一等就是一年多...

這樣後續應該會有人包 PPA 出來讓大家用了...

September 12, 2018 Gea-Suan LinComputer, Library, Murmuring, Privacy, Security, SoftwareNo Comment

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」，這也熬了一年啊... 支援後會就有很多軟體可以直接套用了，可以來期待了。

August 13, 2018 Gea-Suan LinComputer, Library, Murmuring, Network, Privacy, Security, Service, SoftwareNo Comment

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

June 12, 2018 Gea-Suan LinComputer, Murmuring, Network, Service1 Comment

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 而不會出現錯誤訊息，但暫時還不會有效果...