Cloudflare 遞出 S-1

Cloudflare 遞出 Form S-1:「S-1」。TechCrunch 有些整理:「Cloudflare files for initial public offering」。

一樣是燒錢狀態上市,不過相較於其他家燒的速度算是慢的,但成長速度很驚人:

As far as money goes, Cloudflare is — like other early-stage technology companies — losing money. But it’s not losing that much money, and its growth is impressive.

預定在 NYSE 上使用代碼「NET」:

The company will trade on the New York Stock Exchange under the ticker symbol “NET.”

不知道為什麼有種泡沫感...

Cloudflare 提供 Certificate Transparency 的通知服務

Cloudflare 推出了 Certificate Transparency 的通知服務,當有任何新的 SSL certificate 發出時就會通知:「Introducing Certificate Transparency Monitoring」。

基本上就是一組 crawler 去各家記錄挖資料回來:

Business 與 Enterprise 版本的可以設定要通知誰,Free 與 Pro 版本則是固定會通知網域的擁有人 (這邊指的是 Cloudflare 上的):

If you’re on a Business or Enterprise plan, you can tell us who to notify. Instead of emailing the zone owner (which we do for Free and Pro customers), we accept up to 10 email addresses as alert recipients. We do this to avoid overwhelming large teams.

剛剛把掛在上面的 domain 都開起來了,這樣在 Let's Encrypt 自動 renew 的時候應該會收到通知...

另外一個同名的工具則是 2016 年底時 Facebook 推出的 (需要登入才能使用),可以搜尋有哪些 domain:「Certificate Transparency Monitoring」。

Cloudflare 因為 Regular Expression 炸掉的問題

先前 Cloudflare 就有先說明七月二日的 outage 是因為 regular expression 造成的 (ReDoS),不過昨天發的文章更完整了,導致爆炸的 regular expression 都給出來了:「Details of the Cloudflare outage on July 2, 2019」。

ReDoS 不算是新的問題,但卻是不太好避免的問題,因為需要有經驗的工程師 (中過獎的工程師) 才比較容易知道哪些 regular expression 是有問題的... 另外就是有花時間研究 regular expression 演算法的工程師也比較容易避開。

也因次,ReDoS 算是這十年來大家在還的債,各家 framework 都因為這個問題改寫了不少 regular expression。

這次的重點在這串式子導致了 ReDoS:

(?:(?:\"|'|\]|\}|\\|\d|(?:nan|infinity|true|false|null|undefined|symbol|math)|\`|\-|\+)+[)]*;?((?:\s|-|~|!|{}|\|\||\+)*.*(?:.*=.*)))

通常容易中獎的地方就是無限制字元與 * & + 連發的地方,後面這塊 )*.*(?:.*=.*))) 看起來就不太妙,果然在後面的分析也有提到:

The critical part is .*(?:.*=.*).

以前應該是在 Formal language 裡學到的,在課堂裡面其實會學到不少業界常用工具的基礎理論...

Cloudflare 弄了 time.cloudflare.com,不過 latency 沒有很好...

Cloudflare 提供的 NTP service,使用 time.cloudflare.com:「Introducing time.cloudflare.com」。

官方是號稱所有的機房 (應該就包括台北的點):

Now, anyone can get time securely from all our datacenters in 180 cities around the world.

但在 HiNet 下測試可以看到是從東京的點服務:

  2.|-- snuh-3302.hinet.net        0.0%    10    9.5  10.5   9.5  12.7   0.8
  3.|-- tpdt-3022.hinet.net        0.0%    10   11.1  10.8  10.1  11.8   0.3
  4.|-- r4103-s2.tp.hinet.net      0.0%    10   27.2  11.9   9.3  27.2   5.4
  5.|-- r4003-s2.tp.hinet.net      0.0%    10   11.3  10.7   9.5  11.6   0.3
  6.|-- xe-0-0-0-3-6.r02.osakjp02  0.0%    10   47.9  48.7  47.6  49.9   0.6
  7.|-- ae-2.a00.osakjp02.jp.bb.g  0.0%    10   44.9  47.3  42.8  66.4   6.9
  8.|-- ae-20.r03.osakjp02.jp.bb.  0.0%    10   43.7  43.2  42.5  44.7   0.3
  9.|-- 61.120.144.46              0.0%    10   69.6  52.4  48.0  69.6   6.8
 10.|-- 162.159.200.123            0.0%    10   48.3  48.8  47.9  49.3   0.0

如果從 APOL (有線電視) 的點則是透過台灣的機房連線:

  3.|-- 10.251.11.6                0.0%    10   19.8  29.6  11.1  80.2  21.7
  4.|-- 10.251.231.5               0.0%    10   25.3  24.9  16.4  43.6   8.0
  5.|-- 10.251.231.1               0.0%    10    8.7   6.3   3.4   9.1   1.9
  6.|-- 10.251.230.34              0.0%    10    4.6   7.4   2.6  14.5   3.2
  7.|-- 10.251.230.29              0.0%    10    3.0   6.6   3.0  11.9   2.8
  8.|-- 202-178-245-162.cm.static  0.0%    10    4.8   7.3   4.8   9.9   1.4
  9.|-- 192.168.100.14             0.0%    10    7.3   8.0   5.4  11.1   2.0
 10.|-- 192.168.100.9              0.0%    10    8.2   8.0   4.9  11.1   1.7
 11.|-- 203-79-250-65.static.apol  0.0%    10    9.1   9.0   6.4  11.3   1.5
 12.|-- 211.76.96.92               0.0%    10    7.8   8.1   4.3  15.8   3.3
 13.|-- 39-222-163-203-static.tpi  0.0%    10    9.9   9.1   6.7  12.4   1.8
 14.|-- 162.159.200.1              0.0%    10    5.0   7.2   5.0   9.7   1.4

看起來又是有東西沒搞定了...

Cloudflare 提供 IPFS 的 HTTPS Gateway

IPFS Gateway 基本上就是個 Proxy,這次 Cloudflare 直接提供 *.cf-ipfs.com 服務:「Continuing to Improve our IPFS Gateway」。

用把 hash 放進 subdomain 的方式讓我想起當年的 Coral CDN 計畫...

Anyway,我覺得對 IPFS 的幫助還是有限,畢竟本來 IPFS 官方就有提供 Gateway,現在只是一個比較快的 Gateway,能做的功能還是那些...

Cloudflare 改善了同時下載同一個檔案的效率...

在「Live video just got more live: Introducing Concurrent Streaming Acceleration」這邊 Cloudflare 說明他們改善了同時下載同一個 cache-miss 檔案時的效率。

本來的架構在 cache-miss 時,CDN 這端會先取得 exclusive lock,然後到 origin server 抓檔案。如果這時候有其他人也要抓同一個檔案,就會先卡住,避免同時間對 origin server 產生大量連線:

這個架構在一般的情況下其實還 ok,就算是 Windows Update 這種等級的量,畢竟就是一次性的情況而已。但對於現代愈來愈普及的 HTTP(S) streaming 技術來說,因為檔案一直產生,這就會是常常遇到的問題了。

由於 lock 機制增加了不少延遲,所以在使用者端就需要多抓一些緩衝時間才能確保品質,這增加了直播的互動延遲,所以 Cloudflare 改善了這個部分,讓所有人都可以同時下載,而非等到發起的使用者下載完才能下載:

沒有太多意外的,從 Cloudflare 內部數字可以看出來這讓 lock 時間大幅下降,對於使用者來說也大幅降低了 TTFB (time to first byte):

不確定其他家的情況...

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」這邊。

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

將本機開發網站展示給外部看的工具 inlets

要講 inlets 前要先講 ngrok 這個服務。這個服務可以在開發機上主動建立連線到外部伺服器,接著透過這個連線與本機的 web server 溝通,讓外部的客戶可以很方便的進行測試 (通常會開個 Zoom 之類的工具邊討論邊修改),算是 reverse proxy as a service 的服務。

類似機制的服務還有 CloudflareArgo Tunnel,不過產品定位不太一樣。

而 inlets 就是 open source 版本的 ngrok,你只要在外部租一台主機就可以用了。左邊是自己的開發機 (像是 Macbook),右邊則是外部的主機 (租用 VPS):

不過這個跟開發模式也有關...

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