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

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

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)。這點倒是頗有趣...

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

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

Mozilla 跟 Google 都宣佈了 TLS 1.0 與 TLS 1.1 的退役計畫

UpdateApple 也宣佈了,時間點跟大家都差不多:「Deprecation of Legacy TLS 1.0 and 1.1 Versions」。

Mozilla 宣佈了「Removing Old Versions of TLS」,而 Google 也宣佈了「Modernizing Transport Security」,兩篇都是講自家瀏覽器 TLS 1.0 與 TLS 1.1 的退役時程。

Mozilla 這邊的計畫是 2020 年三月移除:

In March of 2020, Firefox will disable support for TLS 1.0 and TLS 1.1.

Google 這邊的計畫則是 Chrome 81 移除,換算成時間會從 2020 年一月開始影響到 canary channel,到 release channel 應該跟 Firefox 差不多時間:

In line with these industry standards, Google Chrome will deprecate TLS 1.0 and TLS 1.1 in Chrome 72. Sites using these versions will begin to see deprecation warnings in the DevTools console in that release. TLS 1.0 and 1.1 will be disabled altogether in Chrome 81. This will affect users on early release channels starting January 2020.

差不多試從現在開始的一年半。

雖然這是講瀏覽器端的支援,但如果伺服器想要只支援 TLS 1.2+ 的話,就得考慮一下舊 client 支援的情況了。

桌機影響會比較小 (升級比較方便,替代方案也比較多),而行動平台看起來需要 Android 4.4+、iOS 7+,就要看各網站或是服務的族群了...

讓 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。(用 OpenSSLs_client -connect x.y.z:636 與 ldapsearch 測過)

要找問題的話,ldapsearch 有 -v (verbose) 與 -d 9 (debug) 可以看連線過程的細節,拿著錯誤訊息去餵搜尋引擎會有不少幫助...

在找資料時發現網路上有不少文件教大家直接在 client 端的 /etc/ldap/ldap.conf 修改 TLS_REQCERT 的值,從預設的 demand 改成 allow (或是 never),但這樣將強制檢查的條件改弱,安全性反而降低了。比較好的方式還是修正 server 端的錯誤設定。

SMTP 的強加密連線機制

RFC 8461 成為正式標準 (Standards Track),描述 Mail server 到 mail server 之間的強加密連線機制:「SMTP MTA Strict Transport Security (MTA-STS)」。

Policy 設定的方法有好幾種:

第一種是透過 _mta-stsTXT record 設定,這點通常會配合 DNSSEC 確保 DNS 的查詢沒有被改。

第二種是透過 HTTPS 在某個特定的 host (mta-sts) 取得 policy 檔案。像是對 example.com 的資料會從 https://mta-sts.example.com/.well-known/mta-sts.txt 取得。

第三種是透過 HTTPS 的 certificate 裡面帶 mta-sts 資訊出來。

不只有 DNS 可以設定,使得整個架構變得有點複雜...

Google Chrome 70 在測試移除 EV SSL 的名稱標籤...

Twitter 上看到的:

不知道是什麼背景決定做這個實驗... 盯一下這個消息的後續發展 @_@

國內使用 Let's Encrypt 的商業網站...

因為前一篇「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

Symantec 系列的 SSL Certificate 陸續開始失效...

先前就有提到 ChromeFirefox 因為 Symantec 的信任問題太大,都有打算終止信任 Symantec 的憑證了,而其他瀏覽器也都有陸陸續續公佈了類似的計畫,大家的時間表都抓差得不多...

最近接近當時各家瀏覽器規劃的終止信任日,而在使用開發版本的 Chrome 與 Firefox 開始連不上一些網站了。我自己是走 beta channel 所以還沒中,不過好像也快了...

我拿了「Umbrella Popularity List」這邊提供的前一百萬網站測,以 .tw 結尾的網站看起來就只剩下兩個還沒換了:

在蘋果的網站上有清單可以翻:「Information for website operators about distrusting Symantec certificate authorities」。