幹壞事是進步最大的原動力
因為前一篇「Symantec 系列的 SSL Certificate 陸續開始失效...」的關係，當時是針對 針對 .tw 結尾的站台，用 OpenSSL 掃了一份 issuer= 下來，剛好可以拿來翻一下有誰換去 Let's Encrypt 了...
蝦皮的主站台直接都用 Let's Encrypt 了：
host=shopee.tw issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 host=www.shopee.tw issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
然後在「SSL Server Test: shopee.tw (Powered by Qualys SSL Labs)」這邊可以看到是 wildcard，而且是多個 wildcard 合併一張...
如果把 Let's Encrypt 自動化，省下來最多的通常都不是憑證費用，而是 renew 時請款流程的人力成本與忘記 renew 時的出包成本... XD
先前就有提到 Chrome 與 Firefox 因為 Symantec 的信任問題太大，都有打算終止信任 Symantec 的憑證了，而其他瀏覽器也都有陸陸續續公佈了類似的計畫，大家的時間表都抓差得不多...
最近接近當時各家瀏覽器規劃的終止信任日，而在使用開發版本的 Chrome 與 Firefox 開始連不上一些網站了。我自己是走 beta channel 所以還沒中，不過好像也快了...
我拿了「Umbrella Popularity List」這邊提供的前一百萬網站測，以 .tw 結尾的網站看起來就只剩下兩個還沒換了：
在蘋果的網站上有清單可以翻：「Information for website operators about distrusting Symantec certificate authorities」。
看到 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」，這也熬了一年啊... 支援後會就有很多軟體可以直接套用了，可以來期待了。
Let's Encrypt 宣佈他們的憑證被所有主流瀏覽器直接支援了，也就是都在各平台的 trusted store 內了：「Let's Encrypt Root Trusted By All Major Root Programs」，看起來這次加入的是 Microsoft 的產品：
As of the end of July 2018, the Let’s Encrypt root, ISRG Root X1, is directly trusted by Microsoft products. Our root is now trusted by all major root programs, including Microsoft, Google, Apple, Mozilla, Oracle, and Blackberry.
先前是靠 IdenTrust 的 cross signing 讓各瀏覽器信任，在「Chain of Trust」這邊有圖說明：
另外查了一下 cross signing 的資訊，以 Let's Encrypt Authority X3 這張的 cross signing 可以看到 cross sign 簽了五年，到 2021 年：(憑證可以從 letsencryptauthorityx3.pem.txt 這邊取得，用 openssl x509 -in letsencryptauthorityx3.pem.txt -text 看到)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
Validity
Not Before: Oct 6 15:43:55 2016 GMT
Not After : Oct 6 15:43:55 2021 GMT
Subject: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
這樣約滿不知道會不會續簽...
很久前看過 SSHFPT record，當時支援度不高就忘記了... 剛剛在 Cloudflare 的這篇「Additional Record Types Available with Cloudflare DNS」看到發現 OpenSSH 很久前就有支援了...
用法是 VerifyHostKeyDNS 這個 option，像是 ssh -o "VerifyHostKeyDNS=yes" -o "StrictHostKeyChecking=yes" hostname 這樣的指令，對於 ~/.ssh/known_hosts 裡沒有的機器，在第一次連線的時候會去查 DNS record，如果沒有查到的話就會中斷。
產生 SSHFP record 的方式則是可以參考「How do I generate SSHFP records?」這篇，也就是直接用 sshkey-gen -r [hostname]，程式就會去讀 /etc/ssh/ 下的資料產生了。
Twitter 上看到 WireGuard 被收進 Linux Kernel 了，等 review 完後就就會正式納入了... 而且 Linus 給的評價還蠻高的：
It is official. wireguard vpn is now part of upstream linux kernel and here is what Linus said about it. pic.twitter.com/FwxKi7fzX8
— nixCraft (@nixcraft) August 3, 2018
找了一下起源是「[PATCH v1 3/3] net: WireGuard secure network tunnel」這邊，而 Twitter 上面引用的是「Re: [GIT] Networking」這篇...
在「subfinder – 找子網域的工具」這邊看到的，專案是用 Golang 寫的，需要 Golang 1.10+ 才能裝... 這類工具在 PT 找入口時還蠻好用的。
裝完後馬上跑個熱門的 ./subfinder -d teamkp.tw 可以看到不多：
Total 4 Unique subdomains found for teamkp.tw .teamkp.tw donate.teamkp.tw www.donate.teamkp.tw www.teamkp.tw
加上 -v 則可以看到來源。
看到「Encrypted Server Name Indication for TLS 1.3」這個，由 Fastly、Cloudflare、Apple 的人聯手推出的 draft，想要保護 TLS 連線一開始明文傳輸的 hostname 部分。看起來是透過 DNS 發佈 public key，然後使用者用這把 public key 保護 hostname 的部分...
而 DNS 的部分可以透過 DNS over TLS 或是 DNS over HTTPS 來保護，這樣讓 ISP 沒有任何資訊可以看到 hostname，把暴露的資訊再降低...
來繼續關注這個技術...
透過 DNS over TLS 會損失一些效能 (我用 VDSL 的光世代測試，大約是從 10ms 變成 40ms)，但可以讓 ISP 看不到你查詢什麼，對於隱私有很大的幫助... 而先前是一直在看 Ubuntu 上的 Unbound 什麼時候會有 1.8.0+ 的版本可以用 (支援 DNS-over-TLS)，但一直沒看到，結果在「How to Protect Your DNS Privacy on Ubuntu 18.04 with DNS over TLS」這邊看到 Stubby 這個軟體。
Stubby 在 Ubuntu 18.04 上可以直接裝，但在 Ubuntu 16.04 上需要透過 PPA 裝，我是透過「DNS Utils : James Newell」這個安裝的，裝好後 /etc/stubby/stubby.yml 檔裡 upstream_recursive_servers 的設定改成：
upstream_recursive_servers:
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
- address_data: 1.0.0.1
tls_auth_name: "cloudflare-dns.com"就可以走 port 853 的 DNS over TLS 了，而 Stubby 預設會聽 127.0.0.1 與 ::1 的 port 53，所以把 /etc/resolv.conf 或是 NetworkManager 的設定改成 127.0.0.1 就可以了。
目前這樣設看起來沒辦法擋 MITM attack (偽造 SSL certificate)，Stubby 看起來只能用 tls_pubkey_pinset 鎖住，但實在不愛這個方法 (因為 Cloudflare 有可能會換成其他的 SSL certificate)，之後看看有沒有可以吃 Root CA 架構的認證再來調整...
這幾天在弄備援跳板機，不想弄在日本 (latency)，所以就想到 Google Cloud Platform (GCP) 在台灣有機房，而 Compute Engine 有 f1-micro，類似 AWS 裡 EC2 提供的 t2.nano 的機器。而這兩天玩了玩，大概有些事情值得記錄起來。
CPU 相關的部份：
t2 系列可以透過 API 或是在 web console 看到 CPU credit 剩下多少，GCE 沒找到在哪邊可以看。t2 系列在 CPU credit 用完後是變慢運行，除非你打開 T2 Unlimited 同意 AWS 多收錢。而 GCE 的則是沒得選，相當於一定要開 T2 Unlimited。f1-micro 是 0.2 vCPU，但我在上面跑 Ubuntu 18.04，平常沒事就已經是 15% 左右。這數字比預期的高不少，還在找是什麼原因...
網路相關的部份：
其他的部份：
gp2 便宜不少來看看一個月會有多少帳單產生吧...