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% 的流量其實是有被過濾的?

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 手上多了一把武器可以用。

在 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 改過去...

Cloudflare 發表 Logpush,把 log 傳出來

Cloudflare 推出了 Logpush,可以把 log 傳到 Amazon S3 或是 Google Cloud Storage 上 (目前就支援這兩個):「Logpush: the Easy Way to Get Your Logs to Your Cloud Storage」,目前是 enterprise 方案可以用:

Today, we’re excited to announce a new way to get your logs: Logpush, a tool for uploading your logs to your cloud storage provider, such as Amazon S3 or Google Cloud Storage. It’s now available in Early Access for Enterprise domains.

Logpush currently works with Amazon S3 and Google Cloud Storage, two of the most popular cloud storage providers.

以往是自己拉,需要考慮 HA 問題 (兩台小機器就可以了,機器成本是還好,但維護成本頗高),現在則是可以讓 Cloudflare 主動推上來...

我大多數的建議是 log 儘量留 (包括各種系統的 log 與 http access log)。主要是因為儲存成本一直下降 (S3 的 1TB 才 USD$23/month,如果使用 Glacier 會低到 USD$4/month),而且 log 在壓縮後會變小很多 (經常會有重複的字)。

最傳統的 AWStats 就可以看到不少資訊,如果是透過 IP address 與 User-agent,交叉配合其他 event data 就可以讓很多 machine learning 演算法取得的資訊更豐富。

開始把一堆網域轉到 Cloudflare 上...

看到「Cloudflare Registrar at three months」這篇文章,然後前幾天剛好也有其他人提到轉到 Cloudflare 的事情,就把手上的網域也轉一轉...

轉過來最主要的原因還是價錢,另外也是因為都掛進 Cloudflare 了,直接把註冊商掛在 Cloudflare 上有很多設定會比較簡單。

批次轉移界面做的還不錯,系統會先把帳號內的網域都列出來,然後依照註冊商歸類後給你填 auth code,之後開始轉就會收到確認信,確認後就都過去了。不過還是有些沒收到確認信,不知道是不是等五天...

另外一個是信用卡的部份,元大的 JCB 刷不過 (不過元大的系統擋很凶似乎是用這張的人都知道了...),改用富邦的 VISA 一刷下去就過了,但是轉 n 個網域就產生了 n 筆交易,然後就接到銀行的關切電話了...

雖然支援了 246 個 tld,但目前 *.tw 還不能轉,先把其他的轉過來了...

HTTP Archive 分析 CDN 的使用情況...

Twitter 上看到 HTTP Archive 分析各家 CDN 的使用情況,給了一個蠻意外的結果,可以看到 Cloudflare 的佔比相當高:

進去看一下分析的方式,是拿 Google Chrome 提供的資料來再進一步分析:

As of December 15th 2018, the HTTP Archive is crawling the full list of desktop origins from the Chrome User Experience (CrUX) Report for the desktop crawls (mobile will be added as of January 1, 2019). The URL list used is the latest available at the time of the crawl (November 2018 in this case).

這應該是出自「Chrome User Experience Report」這邊:

The Chrome User Experience Report is powered by real user measurement of key user experience metrics across the public web, aggregated from users who have opted-in to syncing their browsing history, have not set up a Sync passphrase, and have usage statistic reporting enabled.

由於有條件限制,可以預期會有偏差,不過以目前 Google Chrome 的市占率來說,應該是有意義的資料。而這份資料跑出來的數據看到 Cloudflare 的影響力遠遠超過其他 CDN 讓人頗意外...

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 會有狀況了。

Cloudflare 的 Firewall Rules

Cloudflare 發表了 Firewall Rules,讓使用者可以直接在 Cloudflare 的網站上設定 edge 要擋下或是放行哪些連線:「Announcing Firewall Rules」。

除了可以透過點選的方式設定外,也可以直接編輯條件式:

算是讓使用者更簡單的設定 (而且可以針對這些條件最佳化引擎),不然 Cloudflare 提供的 Worker 其實也可以做類似的事情...

Cloudflare 的 Workers KV

Cloudflare 推出了 Workers KV 服務:「Building With Workers KV, a Fast Distributed Key-Value Store」。

是個 key-value 結構服務 (全球性,eventually consistent,約 10 秒的同步時間),key 的限制是 2KB,value 是 64KB,一個 namespace 最多 10 億筆資料。

讀取可以到 100k+ read/s,但寫入是 1 write/s/key,可以看出來主要是為了讀取資料而設計的。

現有的 worker ($5/month) 會送一些量,包括 1GB 的空間與一千萬次的讀取:

Your $5 monthly Workers compute minimum includes 1 GB of KV storage and up to 10 million KV reads. If you use less than the 10 million included Worker requests now, you can use KV without paying a single cent more.

超過的部份另外再收:

Beyond the minimums, Workers KV is billed at $0.50 per GB-month of additional storage and $0.50 per million additional KV reads.

這樣好像整個 blog 的基本功能都可以直接在上面跑了... 而搜尋靠外部服務,圖片與影音也可以靠外部空間協助?

Cloudflare 成為域名註冊商...

Cloudflare 的老大 Matthew Prince 在自家 blog 上宣佈 Cloudflare 成為域名註冊商:「Introducing Cloudflare Registrar: Domain Registration You Can Love」。

原因是嫌其他家的安全性不夠,所以自己搞了一個把自家的域名都搬進去。現在則是提供服務開放讓大家用。

可以看到 cloudflare.com 用一陣子了:

   Domain Name: CLOUDFLARE.COM
   Registry Domain ID: 1542998887_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.cloudflare.com
   Registrar URL: http://www.cloudflare.com
   Updated Date: 2017-05-24T17:44:01Z
   Creation Date: 2009-02-17T22:07:54Z
   Registry Expiry Date: 2024-02-17T22:07:54Z
   Registrar: CloudFlare, Inc.
   Registrar IANA ID: 1910

不過 AmazonGoogle 也都有弄,未必一定要用 Cloudflare 的就是了:

   Registrar: Amazon Registrar, Inc.
   Registrar IANA ID: 468
   Registrar Abuse Contact Email: registrar-abuse@amazon.com
   Registrar Abuse Contact Phone: +1.2062661000
   Registrar: Google Inc.
   Registrar IANA ID: 895
   Registrar Abuse Contact Email: registrar-abuse@google.com
   Registrar Abuse Contact Phone: +1.8772376466