Home » Posts tagged "cloudflare"

保護 TLS 的 Hostname

看到「Encrypted Server Name Indication for TLS 1.3」這個,由 FastlyCloudflareApple 的人聯手推出的 draft,想要保護 TLS 連線一開始明文傳輸的 hostname 部分。看起來是透過 DNS 發佈 public key,然後使用者用這把 public key 保護 hostname 的部分...

而 DNS 的部分可以透過 DNS over TLS 或是 DNS over HTTPS 來保護,這樣讓 ISP 沒有任何資訊可以看到 hostname,把暴露的資訊再降低...

來繼續關注這個技術...

用 Stubby 在 Ubuntu 上跑 DNS over TLS

透過 DNS over TLS 會損失一些效能 (我用 VDSL 的光世代測試,大約是從 10ms 變成 40ms),但可以讓 ISP 看不到你查詢什麼,對於隱私有很大的幫助... 而先前是一直在看 Ubuntu 上的 Unbound 什麼時候會有 1.8.0+ 的版本可以用 (支援 DNS-over-TLS),但一直沒看到,結果在「How to Protect Your DNS Privacy on Ubuntu 18.04 with DNS over TLS」這邊看到 Stubby 這個軟體。

Stubby 在 Ubuntu 18.04 上可以直接裝,但在 Ubuntu 16.04 上需要透過 PPA 裝,我是透過「DNS Utils : James Newell」這個安裝的,裝好後 /etc/stubby/stubby.yml 檔裡 upstream_recursive_servers 的設定改成:

upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"

就可以走 port 853 的 DNS over TLS 了,而 Stubby 預設會聽 127.0.0.1::1 的 port 53,所以把 /etc/resolv.conf 或是 NetworkManager 的設定改成 127.0.0.1 就可以了。

目前這樣設看起來沒辦法擋 MITM attack (偽造 SSL certificate),Stubby 看起來只能用 tls_pubkey_pinset 鎖住,但實在不愛這個方法 (因為 Cloudflare 有可能會換成其他的 SSL certificate),之後看看有沒有可以吃 Root CA 架構的認證再來調整...

Cloudflare 提供的 DNS Resolver 服務拓展到 Tor 上

Cloudflare 宣佈 DNS Resolver 提供 Tor 的版本,讓使用者可以在不暴露自己的 IP address 的情況下,使用 Cloudflare 提供的 DNS Resolver 服務:「Introducing DNS Resolver for Tor」。

不過沒看懂,如果使用者想要透過 Tor 保護自己的話,本來就可以透過 Tor 存取 1.1.1.11.0.0.1 甚至是其他家有提供 DNS-over-TLS 或是 DNS-over-HTTPS 的服務了?(像是 Google8.8.8.8)

好像找不到什麼使用的理由...

用 GitHub + Netlify + Cloudflare 管理靜態網站...

最近 GitHub Pages 支援 HTTPS (透過 Let's Encrypt,參考「GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務」這篇),但測了一下不是我想要的效果,就找了一下網路上的資源,結果有找到還算可以的方案...

  • 先把網站放在 GitHub 上。(不需要設定 GitHub Pages)
  • 然後用 Netlify 變成網站並且開啟 HTTPS。(可以選擇使用系統內提供的 Let's Encrypt,會透過 http-01 認證。如果因為 DNS 還沒生效的話也沒關係,可以之後再開。)
  • 然後用 Cloudflare 管理 DNS 的部份 (主要是因為他的 root domain 可以設 CNAME,一般會提到的 ALIAS 就是指這個)。

這樣整個靜態服務都不用自己管理,而且有蠻多 header 可以設定,其中與 GitHub Pages 最主要的差異是 Netlify 支援 301/302 redirect。而關於 Netlify 的設定範例 (簡單的),可以參考我在 GitHub 上的 git.tw repository。

然後 Netlify 上可以自己設定 header,當設定 HSTS 之後,SSL Labs 的跑分也可以到 A+。

整包目前看起來唯一的限制是 Netlify 的 125k requests/month (平均下來大約 4k requests/day),不過只拿來做 redirect 應該還好...

PS:如果有人要推薦其他的組合也歡迎...

Cloudflare 的 jpegtran 在 ARM 上面的表現

Cloudflare 花了不少力氣在 ARM 的伺服器上 (可以參考「Cloudflare 用 ARM 當伺服器的進展...」,或是更早的「Cloudflare 測試 ARM 新的伺服器」這篇),最近在 ARM 上發現 jpegtran 的效能不是太好,花了不少力氣最佳化,發現有意外收穫:「NEON is the new black: fast JPEG optimization on ARM server」。

他們設的低標是讓每個 core 的效能大約在 Xeon 的 50%,但發現只有 26% 左右的效能:

Ideally we want to have the ARM performing at or above 50% of the Xeon performance per core. This would make sure we have no performance regressions, and net performance gain, since the ARM CPUs have double the core count as our current 2 socket setup.

In this case, however, I was disappointed to discover an almost 4X slowdown.

而他就想到這些圖形運算的程式應該早就在使用各種 SIMD 指令集加速,於是作者就想到,把 SSE 的最佳化部份 porting 到 ARM 上面的 NEON 說不定會有很大的幫助:

Not one to despair, I figured out that applying the same optimizations I did for Intel would be trivial. Surely the NEON instructions map neatly to the SSE instructions I used before?

而 porting 完後重新測試發現達到了 66% 的效能,已經超過本來的目標... 另外在批次處理中,也比 Xeon 快了:

繼續發研究時又發現 NEON 有一些在 SSE 沒有的指令 (沒有相似功能),也許能提供更進一步的加速:

While going over the ARMv8 NEON instruction set, I found several unique instructions, that have no equivalent in SSE.

如果再把這些指令實做出來,會發現單 core 的效能已經到 Xeon 的 83%,而批次的速度又提昇了不少:

最後是整台伺服器都跑滿時的測試,會發現整台的效能差不多 (其實 ARM 的版本還贏一些),但吃電量不到一半,而就算只拿他們常態在跑的 4 workers 來看 (應該是為了 latency 問題),用電效率來到 6.5 倍:

With the new implementation Centriq outperforms the Xeon at batch reduction for every number of workers. We usually run Polish with four workers, for which Centriq is now 1.3 times faster while also 6.5 times more power efficient.

這篇在提醒之後在 ARM 上寫最佳化時,不要只從 SSE porting 到 NEON,要多看一下有沒有其他指令集是有幫助的...

Cloudflare 推出 Spectrum:65535 個 TCP Port 都可以轉的 Proxy...

Cloudflare 推出了 Spectrum,文章標題提到的 65533 應該是指 80 & 443 以外其他的 port:「Introducing Spectrum: Extending Cloudflare To 65,533 More Ports」。

然後因為 TCP proxy 不像 HTTP proxy 與 WebSocket proxy 可以靠 Host header 資訊判斷,在 TCP proxy 需要獨占 IP address 使用 (i.e. 一個 IP address 只能給一個客戶用),而因為 IPv4 address 不夠的關係,這個功能只開放給 Enterprise 客戶用:

Today we are introducing Spectrum, which brings Cloudflare’s security and acceleration to the whole spectrum of TCP ports and protocols for our Enterprise customers.

雖然現在限定在 Enterprise 客戶,但 Cloudflare 還是希望看看有沒有其他想法,目前提出來的選項包括了開放 IPv6 address 給所有人用,或是變成獨立付費項目:

Why just Enterprise? While HTTP can use the Host header to identify services, TCP relies on each service having a unique IP address in order to identify it. Since IPv4 addresses are endangered, it’s quite expensive for us to delegate an IP per application and we needed to limit use. We’re actively thinking about ways to bring Spectrum to everyone. One idea is to offer IPv6-only Spectrum to non-Enterprise customers. Another idea is let anyone use Spectrum but pay for the IPv4 address. We’re not sure yet, but if you prefer one to the other, feel free to comment and let us know.

類似的產品應該是 clean pipe 類的服務,但一般 clean pipe 是透過 routing 重導清洗流量,而非像 Cloudflare 這樣設計... 不知道後續會有什麼樣的變化。

Cloudflare 推出 Argo Tunnel

Cloudflare 推出了 Argo Tunnel,可以將內部網路與 Cloudflare 之間打通:「Argo Tunnel: A Private Link to the Public Internet」。

Cloudflare 在去年推出了 Wrap (可以參考「Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443」這篇),這次其實只是改名:

During the beta period, Argo Tunnel went under a different name: Warp. While we liked Warp as a name, as soon as we realized that it made sense to bundle Warp with Argo, we wanted it to be under the Argo product name. Plus, a tunnel is what the product is so it's more descriptive.

看起來沒有什麼新的玩意... 純粹改名字 :o

Cloudflare 推出在 HTTPS 下的壓縮機制

在 TLS (HTTPS) 環境下基本上都不能開壓縮,主要是為了避免 secret token 會因為 dictionary 的可預測性而被取出,像是 CRIMEBREACHTIMEHEIST (沒完結過...),而因為全面關閉壓縮,對於效能的影響很大。

Cloudflare 就試著去找方法,是否可以維持壓縮,但又不會洩漏 secret token 的方式,於是就有了這篇:「A Solution to Compression Oracles on the Web」。

重點在於 Our Solution 這段的開頭:

We decided to use selective compression, compressing only non-secret parts of a page, in order to stop the extraction of secret information from a page.

透過 regex 判斷那些東西屬於 secret token,然後對這些資料例外處理不要壓縮,而其他的部份就可以維持壓縮。這樣傳輸量仍然可以大幅下降,但不透漏 secret token。然後因為這個想法其實很特別,沒有被實證過,所以成立了 Challenge Site 讓大家打:

We have set up the challenge website compression.website with protection, and a clone of the site compression.website/unsafe without it. The page is a simple form with a per-client CSRF designed to emulate common CSRF protection. Using the example attack presented with the library we have shown that we are able to extract the CSRF from the size of request responses in the unprotected variant but we have not been able to extract it on the protected site. We welcome attempts to extract the CSRF without access to the unencrypted response.

這個方向如果可行的話,應該會有人發展一些標準讓 compression algorithm 不用猜哪些是 secret token,這樣一來就更能確保因為漏判而造成的 leaking...

Cloudflare 推出 1.1.1.1 的 DNS Resolver 服務

Cloudflare 推出了 1.1.1.1 上的 DNS Resolver 服務:「Announcing 1.1.1.1: the fastest, privacy-first consumer DNS service」,主打項目是隱私以及效能。

然後因為這個 IP 的特殊性,上面有不少奇怪的流量... 而 Cloudflare 跟 APNIC 交換條件後取得這個 IP address 的使用權 (然後 anycast 發出去):

APNIC's research group held the IP addresses 1.1.1.1 and 1.0.0.1. While the addresses were valid, so many people had entered them into various random systems that they were continuously overwhelmed by a flood of garbage traffic. APNIC wanted to study this garbage traffic but any time they'd tried to announce the IPs, the flood would overwhelm any conventional network.

We talked to the APNIC team about how we wanted to create a privacy-first, extremely fast DNS system. They thought it was a laudable goal. We offered Cloudflare's network to receive and study the garbage traffic in exchange for being able to offer a DNS resolver on the memorable IPs. And, with that, 1.1.1.1 was born.

Cloudflare 做了效能比較表 (與 Google Public DNSOpenDNS 比較),可以看到平均速度快不少:

在台灣的話,HiNet 非固定制 (也就是 PPPoE 連線的使用者) 連到 8.8.8.8 有奇怪的 latency:

可以比較同一台機器對 168.95.1.1 的反應速度:

不過如果你是 HiNet 固定制 (固 2 或是固 6 IP 那種,不透過 PPPoE,直接設定 IP address 使用 bridge mode 連線的使用者),兩者的 latency 就差不多,不知道是 Google 還是 HiNet 的架構造成的。

另外比較奇怪的一點是在文章最後面提到的 https://1.1.1.1/,理論上不會發 IP-based 的 SSL certificate 才對?不知道 CEO 老大是有什麼誤解... XD

Visit https://1.1.1.1/ from any device to get started with the Internet's fastest, privacy-first DNS service.

Update:查了資料發現是可以發的,只是大多數的 CA 沒有提供而已...

Cloudflare 的 CT Dashboard

Cloudflare 發表了他們的 CT (Certificate Transparency) Dashboard:「Introducing Certificate Transparency and Nimbus」。前面的篇幅解釋 CT 是什麼,以及為什麼要存在,另外也大略解釋了一下 Google 要求要帶有 SCT (signed certificate timestamp) 的新規定 (基於 Browser 方,也就是 Google Chrome 的立場)。

再來就是講 Cloudflare 推出的 Dashboard,也就是 Merkle Town。這個網站提供了網頁操作界面,讓大家可以了解現在 certificate 的情況。

點了 Current 後,可以看到 Let's Encrypt 的比率相當高,但 Comodo 的量不算差 (以收費的情況來說),再來是 DigiCert

話說回來,當所有的 SSL certificate 都需要 SCT 後,相當於一般人就能夠很精確的統計市占率了,商業的憑證公司應該不是很開心... (當初 EV 也有類似的問題,不過現在 DV 已經被 Let's Encrypt 打趴了...)

Archives