Let's Encrypt 在檢查 CAA 時出包

Let's Encrypt 發現在檢查 CAA 的程式碼有問題,發了說明:「2020.02.29 CAA Rechecking Bug」,以及預定的處理方式:「Revoking certain certificates on March 4」。

問題是當一個 certificate request 包含了 N 個 domain 時,本來的 CAA 檢查應該要對這 N 個檢查,但程式寫成只會抓一個,然後檢查了 N 次:

The bug: when a certificate request contained N domain names that needed CAA rechecking, Boulder would pick one domain name and check it N times. What this means in practice is that if a subscriber validated a domain name at time X, and the CAA records for that domain at time X allowed Let’s Encrypt issuance, that subscriber would be able to issue a certificate containing that domain name until X+30 days, even if someone later installed CAA records on that domain name that prohibit issuance by Let’s Encrypt.

2020/02/29 發現的,就程式碼的部屬時間,發現應該從去年 2019/07/25 開始就有這個 bug:

We confirmed the bug at 2020-02-29 03:08 UTC, and halted issuance at 03:10. We deployed a fix at 05:22 UTC and then re-enabled issuance.

Our preliminary investigation suggests the bug was introduced on 2019-07-25. We will conduct a more detailed investigation and provide a postmortem when it is complete.

然後決定要 revoke 這些可能會有問題的 SSL certificate,大約佔現有還有效的 SSL certificate 的 2.6%,大約三百萬筆:

Q: How many certificates are affected?
A: 2.6%. That is 3,048,289 currently-valid certificates are affected, out of ~116 million overall active Let’s Encrypt certificates. Of the affected certificates, about 1 million are duplicates of other affected certificates, in the sense of covering the same set of domain names.

在「Check whether a host's certificate needs replacement」這邊可以偵測線上使用的 SSL certificate 是否受到影響。

另外在「Download affected certificate serials for 2020.02.29 CAA Rechecking Incident」這邊可以抓到所有受到影響,預定要 revoke 的 SSL certificate 的序號。關於取得序號的方式,官方也有提供 CLI 的指令可以操作確認,對於有很多網域名稱需要確認的人可以用這組指令編寫程式判斷:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial\ Number | tr -d :

照目前的描述,如果申請時只有一個 domain 應該是不會中這個問題,再來是最壞的情況大概會維持三個月 (網站主人沒管他,等到時間到了自動 renew)。

Firefox 在美國將預設開啟 DNS over HTTPS

看到 Mozilla 在「Firefox continues push to bring DNS over HTTPS by default for US users」這邊的公告,另外也可以參考 Hacker News 上的討論:「Mozilla’s DNS over HTTPs (blog.mozilla.org)」。

這次的改變是將美國的 Firefox 使用者自動啟用 DNS over HTTPS (DoH),而預設是丟給 Cloudflare

By default, this change will send your encrypted DNS requests to Cloudflare.

這個作法非常粗暴而且侵犯使用者的隱私。

  • 對於進階而且有在跟重大消息的使用者,他們如果不信任 Cloudflare 的話,會主動關掉 DoH 的選項。
  • 但對於一般使用者,他們不知道這件事情,而他們本來也不會預期他們上網的 hostname 部份會被 Cloudflare 知道。

相較於 Google Chrome 是確認你現在用的 DNS 是不是在有支援 DoH 的清單內,如果是的話就會切過去使用 DoH,但不會因此改變 DNS provider,也就是不會有突然冒出來的第三者知道你瀏覽的網站。

來繼續看...

Google Chrome 也要打開 DoH

Google Chrome 也要支援 DNS over HTTPS (DoH) 了,不過 Google 的作法比 Firefox 軟 (大概這種東西都有經過反壟斷法的評估?),會先判斷系統的 DNS 是否在支援 DoH 的清單內,在不改變 DNS 服務商的情況下,從本來的 UDP 查詢變成 DoH 查詢:「Experimenting with same-provider DNS-over-HTTPS upgrade」。

清單可以從「DNS over HTTPS (aka DoH)」這邊看到,除了 Google 自己外,也有 Cloudflare 與其他支援 DoH 的 DNS 服務商。

這個功能會從 Chrome 78 生效 (現在 stable 與 beta 都還是 77):

We are aiming for an experiment in Chrome 78 (branch cut: Sept 5th; estimated Stable: Oct 22nd) followed by a launch if everything goes well.

OpenBSD 關掉 Firefox 預設的 DoH (DNS over HTTPS)

OpenBSD 決定關閉 Firefox 預設的 DoH (DNS over HTTPS):「DoH disabled by default in Firefox」。

原因是 OpenBSD 的人認為,DoH 本身 ok,但是預設導去 Cloudflare 不 ok:

Disable DoH by default. While encrypting DNS might be a good thing, sending all DNS traffic to Cloudflare by default is not a good idea. Applications should respect OS configured settings. The DoH settings still can be overriden if needed. ok landry@ job@

我覺得這槍開的很好 XD

Amazon Route 53 增加了即時的 Query 數量資訊

AWSRoute 53 增加了 Query 數量的資訊 (加到 CloudWatch 內):「Amazon Route 53 Now Publishes Query Volume Metrics for Public Hosted Zones」。

下午的時候連進去看沒看到,回家後想起來 Route 53 是全球性服務,切到 us-east-1 上就看到了...

算是很基本的功能,這樣可以很方便的看一下使用情況,然後就可以透過這些資料調整 TTL,有些為了要快速切換的可以設短一點,有些不太變動但 query 量很大的則是要設長一點...

iOS 13 與 macOS 10.15 對憑證的限制

Slack 上看到同事丟出來的,關於之後要推出的 iOS 13 與 macOS 10.15 會對憑證限制的項目:「Requirements for trusted certificates in iOS 13 and macOS 10.15」。

主要是把不安全的演算法淘汰掉 (RSA 小於 2048 bits,以及 SHA-1 類的 hash algorithm),這兩個部份相關的新聞應該不少,沒有什麼太大問題:

TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.

TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.

然後是要求憑證使用 SAN (Subject Alternative Name),舊的標準 CN (CommonName) 將不會再被信任。

如果是公開簽發的憑證應該都沒問題 (像是 Let's Encrypt,或是花錢買的那些),主要的問題應該會出現在自己建立的憑證,網路上蠻多舊資料還是產生 CN...

TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.

另外是 2019/7/1 之後發出的憑證,有額外兩個規範要注意,第一個是強制要透過 EKU 指定 id-kp-serverAuth,這是出自 RFC 5280

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.

再來是時間的限制,接下來的憑證最長只認得 825 天 (大約 27 個月多一些),以前都惡搞 -days 3650,現在得兩年簽一次了:

TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

整體看起來主要是影響自己簽的部份...

Stripe 遇到 AWS 上 DNS Resolver 的限制

當量夠大就會遇到各種限制...

這次 Stripe 在描述 trouble shooting 的過程:「The secret life of DNS packets: investigating complex networks」。

其中一個頗有趣的架構是他們在每台主機上都有跑 Unbound,然後導去中央的 DNS Resolver,再決定導去 Consul 或是 AWS 的 DNS Resolver:

Unbound runs locally on every host as well as on the DNS servers.

然後他們發現偶而會有大量的 SERVFAIL

接下來就是各種找問題的過程 (像是用 tcpdump 看情況,然後用 iptables 統計一些數字),最後發現是卡在 AWS 的 DNS Resolver 在 60 秒內只回應了 61,385 packets,換算差不多是 1,023 packets/sec,這數字看起來就很雷:

During one of the 60-second collection periods the DNS server sent 257,430 packets to the VPC resolver. The VPC resolver replied back with only 61,385 packets, which averages to 1,023 packets per second. We realized we may be hitting the AWS limit for how much traffic can be sent to a VPC resolver, which is 1,024 packets per second per interface. Our next step was to establish better visibility in our cluster to validate our hypothesis.

在官方文件「Using DNS with Your VPC」這邊看到對應的說明:

Each Amazon EC2 instance limits the number of packets that can be sent to the Amazon-provided DNS server to a maximum of 1024 packets per second per network interface. This limit cannot be increased. The number of DNS queries per second supported by the Amazon-provided DNS server varies by the type of query, the size of response, and the protocol in use. For more information and recommendations for a scalable DNS architecture, see the Hybrid Cloud DNS Solutions for Amazon VPC whitepaper.

iptables 看到的量則是:

找到問題後,後面就是要找方法解決了... 他們給了一個只能算是不會有什麼副作用的 workaround,不過也的確想不到太好的解法。

因為是查詢 10.0.0.0/8 網段反解產生大量的查詢,所以就在各 server 上的 Unbound 上指定這個網段直接問 AWS 的 DNS Resolver,不需要往中央的 DNS Resolver 問,這樣在這個場景就不會遇到 1024 packets/sec 問題了 XDDD

擋廣告的 Pi-hole

Pi-hole 最近愈來愈紅的一個計畫,技術上是透過 DNS 把不想要的網域名稱擋掉,通常就是擋掉各種 tracking 與廣告系統。

因為是透過 DNS 擋,當然沒有像 uBlock Origin 直接 parse 網頁內容來的有效,但對於方便性來說則是大勝,只需要在網路設備上設一次,所有的裝置都可以用到。

剛剛看到「How a Single Raspberry Pi made my Home Network Faster」這篇,可以看到 Pi-hole 有不錯的介面可以看 (讓你自我感覺良好?XD):

文章作者跑了一個月後,也直言還是有些東西會壞掉,需要設定一些白名單讓他動:

Review after 1 month in operation
The Pi-Hole has been running for 1 month now on my home network. I have had to whitelist 1 or 2 URLs which was blocking a reset of an Alexa which had an issue, and a video conferencing system had all sorts of tracking and metrics built in which were causing some havoc until I whitelisted them. Otherwise, the Pi has been chugging along at 8% memory utilization, and the network is considerably faster when surfing the web.

對於手癢自己玩應該還可以,拿到辦公室的話應該會有不少東西掛掉... (不過文章作者好像想這樣做)

Cloudflare 打算再推出 VPN 服務

去年在四月一日推出 1.1.1.1 服務的 Cloudflare 打算更進一步保護連線內容,提供 Wrap 服務 (就是 VPN):「Introducing Warp: Fixing Mobile Internet Performance and Security」。

不過這樣在 privacy 上的保護就變弱了,因為 Cloudflare 手上就拿到更多流量資訊可以交叉比對... 大概會申請起來放著在外面用,而不會平常就開著。

申請是透過 app 申請,Android 的在「1.1.1.1: Faster & Safer Internet」這邊,而 iOS 的在「1.1.1.1: Faster Internet」這邊。

目前申請後需看到排隊的編號,像是這樣:

RFC8482 廢掉 DNS 查詢的 ANY query 了...

看到 Cloudflare 的「RFC8482 - Saying goodbye to ANY」這篇,裡面提到 RFC8482 廢掉了 ANY 查詢:「Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY」。

The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.

對 Cloudflare 的痛點主要在於營運上的困難,因為 ANY 回應的 UDP packet size 很大,很容易造成放大攻擊:

把拒絕 ANY 查詢變成標準後,讓 DNS provider 手上多了一把武器可以用。