Tag Archives: tls

Gmail 宣佈支援 MTA-STS

Gmail 宣佈支援 MTA-STS:「Gmail making email more secure with MTA-STS standard」。這邊提到的 MTA-STS 是透過某些設定,讓 SMTP 送信時強制使用 TLS 的機制,可以參考「SMTP 的強加密連線機制」這篇。

可以看到有 TXT,也有 .well-known 檔案:

;; ANSWER SECTION:
_mta-sts.gmail.com.     300     IN      TXT     "v=STSv1; id=20171114T070707;"

$ curl https://mta-sts.gmail.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: gmail-smtp-in.l.google.com
mx: *.gmail-smtp-in.l.google.com
max_age: 86400

如果要自己設定的話可以參考 Google 提供的「About MTA-STS and TLS Reporting」這篇,不過目前中文版文件還沒有更新,請切到英文版...

Amazon CloudFront 要增加自訂網域名稱需要先過認證...

大概猜得到原因,總算是把這塊做下去了...

AWS 宣佈 CloudFront 增加自訂網域名稱需要先過認證才能啟用:「Amazon CloudFront enhances the security for adding alternate domain names to a distribution」,也就是把自己的 domain name 掛到 CloudFront 上需要先認證過。

這邊的認證需要用公開被信任的 SSL Certificate,而大多數人應該會直接拿 AWS 提供的 ACM 來用:

With this change, when you add an alternate domain name using the AWS Management Console or the CloudFront API, you will now need to attach a certificate to the distribution to confirm that you have authorized rights to use the alternate domain name. The certificate must be valid and come from a publicly trusted Certificate Authority like AWS Certificate Manager which provides public SSL/TLS certificates for free.

申請 ACM 也需要確認身分,印象中沒記錯的話是透過 DNS 或是 e-mail 認證。

會有這個改變是因為有一個 DDoS 的攻擊手法可以「造成困擾」。在沒有認證就可以增加網域名稱的情況下 (假設是 assets.gslin.com),AWS 需要把不同帳號設定同一組 domain name (assets.gslin.com) 的 IP address 分開,這樣才能確保安全性。而 IPv4 address 是有限的,用很多帳號申請就有機會讓真正的 assets.gslin.com 擁有人想要用的時候沒有資源可以用。

其實在 Route53 也有類似的問題,但因為是個雞生蛋蛋生雞的問題,就更不好解決了,在 DNS 還沒設定好之前要怎麼確認身分是一個更頭痛的問題... e-mail 認證可能是一個方法,但流程上就多了不少步驟。

Cloudflare 試著分析哪些 HTTPS 連線被攔胡過濾

這邊講的應該是在 client 端裝了 root certificate 後,網路上的 middle box 就有能力解開 HTTPS 連線看內容,再 proxy 連出去的方式:「Monsters in the Middleboxes: Introducing Two New Tools for Detecting HTTPS Interception」,對於有設定 Pinning 的 HTTPS 應該會因為偵測到 certificate 被換掉而不會被監聽,但大多數的應用程式應該沒做這個保護。

對應的公開網站是 MALCOLM,為「Measuring Active Listeners, Connection Observers, and Legitimate Monitors」的縮寫。

Cloudflare 用了幾個方法去分析,像是 User-agent 與 OS 跟支援的 cipher 對不起來的情況就可以猜測是 middle box 的監聽。另外也可以看到 Cloudflare 分析了 middle box 的廠牌,可以看到 Blue Coat 應該是目前的大品牌 (但這邊有統計偏差,限制在可以被偵測出來的品牌)。

其實整體看起來不算低耶... 光是可以確認的部分,整個 Cloudflare 網路上有 10%~20% 的流量其實是有被過濾的?

ACME,RFC 8555

這邊講的是因為 Let's Encrypt 所發明的 ACME 協定,可以協助自動化發憑證的協定。

剛剛看到「Automatic Certificate Management Environment (ACME)」這個頁面,上面標 PROPOSED STANDARD,但點進去的 txt 檔開頭則是 Standards Track 了:

Internet Engineering Task Force (IETF)                         R. Barnes
Request for Comments: 8555                                         Cisco
Category: Standards Track                             J. Hoffman-Andrews
ISSN: 2070-1721                                                      EFF
                                                             D. McCarney
                                                           Let's Encrypt
                                                               J. Kasten
                                                  University of Michigan
                                                              March 2019

不知道是不是兩邊不同步 (或是我對流程有誤會?),但這有一個標準文件可以參考了...

在 Mac 上跑 DNS-over-TLS

主要是參考「Configuring DNS-over-TLS on macOS」這篇的方法做的:

brew install knot-resolver
echo "policy.add(policy.all(policy.TLS_FORWARD({{'1.1.1.1', hostname='1.1.1.1'}})))" | tee -a /usr/local/etc/kresd/config
sudo brew services restart knot-resolver

然後 127.0.0.1 就有 DNS resolver 可以用了,接下來就是把系統的 DNS 改過去...

NLB 也可以幫忙處理 TLS 了...

AWS 推出的新功能,讓 NLB (network load balancer) 可以直接做完 SSL offload:「New – TLS Termination for Network Load Balancers」。

而且 NLB 可以保留 source ip,不需要在 web server 上處理特殊的 header (像是 X-Forwarded-For 這類的 HTTP header)。這點倒是頗有趣...

Google Public DNS 也提供 DNS over TLS 服務

Google Public DNS (也就是 8.8.8.88.8.4.4) 也提供 DNS over TLS 了:「Google Public DNS now supports DNS-over-TLS」。

DNS over TLS 可以保護使用者端到 DNS Resolver 端的傳輸過程,包括了安全性與隱私都有幫助 (降低 ISP 從中可以做的事情)。

不過應該還是會繼續用 Cloudflare 提供的 1.1.1.1,latency 低一些 (也快一些) 而且降低 Google 可以取得的資料。

所以要開始開發 CECPQ2 了...

CECPQ1Google 在研究對抗量子電腦的演算法,作為測試用的演算法,曾經在 Google Chrome 的 54 beta 版 (2016 年) 存活過一段時間,最近又開始在開發新一代的演算法 CECPQ2 了,這次會是基於 TLS 1.3 上測試:「CECPQ2」。

CECPQ2 will be moving slowly: It depends on TLS 1.3 and, as mentioned, 1.3 is taking a while. The larger messages may take some time to deploy if we hit middlebox- or server-compatibility issues. Also the messages are currently too large to include in QUIC. But working though these problems now is a lot of the reason for doing CECPQ2—to ensure that post-quantum TLS remains feasible.

目前對抗量子電腦的演算法好像都跟 Lattice 有關,找時間來補一下基礎理論... @_@

Cloudflare 同時支援 TLS 1.2 與 TLS 1.3 的過程

Cloudflare 算是很早就參與 TLS 1.3 發展的廠商。在參與過程中他們希望讓支援 TLS 1.3 draft 的瀏覽器可以開始使用 TLS 1.3 draft,但又不希望因為 draft 頻繁修改而導致本來的使用者受到影響,所以就找了方法讓兩者並存:「Know your SCM_RIGHTS」。

這個方法就是 SCM_RIGHTS,可以讓另外一個 process 存取自己的 file description。

You can use UNIX-domain sockets to pass file descriptors between applications, and like everything else in UNIX connections are files.

所以他們的作法就是先讀取 TLS 裡 Client Hello 的資料,如果裡面有看到想要使用 TLS 1.3 的訊息,就透過前面提到的 SCM_RIGHTS 丟進 Golang 寫的程式跑:

We let OpenSSL read the “Client Hello” message from an established TCP connection. If the “Client Hello” indicated TLS version 1.3, we would use SCM_RIGHTS to send it to the Go process. The Go process would in turn try to parse the rest of the “Client Hello”, if it were successful it would proceed with TLS 1.3 connection, and upon failure it would give the file descriptor back to OpenSSL, to handle regularly.

這樣本來的 stack 就只要修改一小段程式碼,將當時還很頻繁修改的 TLS 1.3 draft 丟到另外一個 process 跑,就比較不用擔心本來的 stack 會有狀況了。

升級 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 後就好的情況...

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