Category: CDN

polyfill.io 被放 malicious code 的事件

台灣的圈子蠻多人是從「請儘速遠離 cdn.polyfill.io 之惡意程式碼淺析」這邊看到的，一些 code 相關的分析部分可以移駕過去看。裡面提到的 GitHub 上面 alitonium 所寫的 comment 蠻值得讀一下 (第一次點的時候會出現 GitHub 的警告，再點一次應該就會跳到正確的 comment 上)。

polyfill.js 算是老專案了，從 https://github.com/polyfillpolyfill/polyfill-service/graphs/contributors 這邊可以看到是 2013 年開始有記錄，主要是針對舊的瀏覽器 (像是 IE11)，透過 javascript 的方式補上對應的功能。

現在的瀏覽器都是一直在更新，大多數的情況不太需要 polyfill 了，但畢竟很多舊的案子還在用，在這次 domain 被中國公司拿走後，Cloudflare 在今年 2024/2/29 就有先寫一篇算是預警的文章了：「polyfill.io now available on cdnjs: reduce your supply chain risk」，不過這種事情都是還沒發生前大家不會有太多重視，接下來就是 GitHub 上面的討論，然後是真的被動手加 malicious code 進去後，有人發現的討論。

後續大家都被迫要開始處理這件事情，GitHub 的作法看起來沒什麼問題：先標注 malicious repository 但是還是讓人可以進去翻歷史資料與討論。

不過 Cloudflare 這邊動作有點大，直接主動幫 CDN 客戶過濾了：「Automatically replacing polyfill.io links with Cloudflare’s mirror for a safer Internet」，這篇在 Hacker News 上也有討論：「Cloudflare automatically fixes Polyfill.io for free sites (cloudflare.com)」。

這個「越界」有點多，這應該也是直接讓 CEO Matthew Prince 出來掛文章作者的原因。這次 Cloudflare 主動做的事情包括了將免費的客戶預設開啟過濾，而付費的客戶則不會主動開啟，但提供一鍵開關：

Any website on the free plan has this feature automatically activated now. Websites on any paid plan can turn on this feature with a single click.

另外也允許所有客戶關掉這個保護：

All customers can turn off the feature at any time.

所以後續就會有另外一條大支線討論：在使用者沒有事前同意的情況下，以「安全」為名主動更改使用者頁面上的東西，這件事情是不是可以接受？如果以「安全」為名可以接受，為什麼是免費的先動，付費的卻不動？雖然我猜 Cloudflare 會裝死到底就是了...

Route 53 Resolver DNS Firewall 的 chain 處理

在「Stop the CNAME chain struggle: Simplified management with Route 53 Resolver DNS Firewall」這邊看到的新功能。

說實話... 我早就忘記 Route 53 Resolver DNS Firewall 這個產品了，我查資料才發現我在 2021 年的時候寫過：「AWS 推出 Amazon Route 53 Resolver DNS Firewall」。

這個產品的用途是避免透過 DNS 將敏感資訊打出去，不過先前的產品的條件很死，遇到 CNAME 或是 DNAME 的情況，你必須事先把可能後續的 record 也放進白名單才行，所以如果遇到類似於 X (Twitter) 用的 pbs.twimg.com 的情況就很麻煩了：

;; ANSWER SECTION:
pbs.twimg.com.          300     IN      CNAME   cs196.wac.edgecastcdn.net.
cs196.wac.edgecastcdn.net. 3409 IN      CNAME   cs2-wac.apr-8315.edgecastdns.net.
cs2-wac.apr-8315.edgecastdns.net. 110 IN CNAME  cs2-wac-us.8315.ecdns.net.
cs2-wac-us.8315.ecdns.net. 110  IN      CNAME   cs45.wac.edgecastcdn.net.
cs45.wac.edgecastcdn.net. 725   IN      A       117.18.237.70

理想上是你放行 pbs.twimg.com 就好，但因為 CNAME 的關係，你可能會需要多放行 *.edgecastcdn.net 以及 *.ecdns.net。

可是這是第三方的服務，你無法控制對方怎麼切換 (沒有 API contract 的概念)，像是有時候他會跳到 Fastly：

;; ANSWER SECTION:
pbs.twimg.com.          290     IN      CNAME   dualstack.twimg.twitter.map.fastly.net.
dualstack.twimg.twitter.map.fastly.net. 290 IN A 151.101.40.159

如果之後又跑出 Akamai 或是 CloudFront 的話就沒完沒了。

另外一種常見的情況是第三方的 API endpoint，對方有可能有多個不同的點做 DR 切換，有可能 CNAME 到 AWS 的 ELB 或是 GCP 的 Cloud Load balancing 上。

所以為了「保險」，這個方式通常都是開整個 CDN 的服務，但這麼一來攻擊者可以透過租用這些服務 (像是 *.cloudfront.net)，搭配一些其他比較鬆的 rule 鑽出來。

這次的這個功能有點 stateful firewall 的概念，第一個啟動的 record 是被放行的，那 CNAME 或是 DNAME 延伸出來的 record 也跟著放行，這樣算是補強了這個問題...

Common Media Client Data (CMCD)

從 Amazon CloudFront 的公告看到的東西：「Amazon CloudFront now supports Common Media Client Data (CMCD) fields in real-time logs」。

CMCD (Common Media Client Data) 是一個私有的 log format，可以讓 client 透過 HTTP(S) header 回報狀態，所以 AWS 這邊有提到你可以設定讓 CloudFront 記錄下來，然後透過其他軟體分析：

Previously, CloudFront logged CMCD parameters as part of the full query string log field, or the HTTP headers log field. Now, you can simply select to include specific CMCD parameters in your real-time logs and save on compute needed to search and extract the CMCD key-value pairs, and reduce the data set for your log analysis.

現在 CloudFront 則是支援判讀做一些處理：

Starting today, you can enable Common Media Client Data (CMCD) fields in your CloudFront real-time logs. You can select key client-side performance parameters and CloudFront delivery performance parameters in the same log record. This can help you correlate variations in Quality of Experience (QoE) for your viewers to CloudFront performance at the granularity of single viewer sessions, simplifying the troubleshooting of QoE issues that impact your viewers engagement.

看了一下就是定義一些欄位，用 JSON 包起來後讓 client 打回伺服器端，可以利用這些資訊動態從伺服器端調整策略，而不像以前主要的調整策略都放在 client 端。

CloudFront 端出 Embedded Points of Presence

看到 CloudFront 的產品新聞稿：「Amazon CloudFront announces availability of Embedded Points of Presence」，AWS 在 CloudFront 上端出了 Embedded Points of Presence 服務，看名字就是更彈性的 CDN PoP，不過想知道更細節的東西得去看 FAQs 的部分...

從這段可以看到應該是 AWS 的 appliance，然後放到實體機房裡面提供服務：

These embedded POPs are owned and operated by Amazon and deployed in the last mile of the ISP/MNO networks to avoid capacity bottlenecks in congested networks that connect end viewers to content sources, improving performance.

比較特別的消息是，這個不會額外收費：

Q. Is there a separate charge for using embedded POPs?
No, there is no additional charge for using CloudFront embedded POPs.

另外這個服務會是 opt-in 選擇加入，但不需要額外設定 distribution，而且 CloudFront 會針對有 opt-in 的 distribution 自動混搭：

Embedded POPs are an opt-in capability intended for the delivery of large scale cacheable traffic. Please contact your AWS sales representative to evaluate if embedded POPs are suitable for your workloads.

No, you do not need to create a new distribution specifically for embedded POPs. If your workload is eligible, CloudFront will enable embedded POPs for your existing distribution upon request.

You don't have to choose between CloudFront embedded POPs or CloudFront POPs for content delivery. Once your CloudFront distribution is enabled for embedded POPs, CloudFront's routing system dynamically utilizes both CloudFront POPs and embedded POPs to deliver content, ensuring optimal performance for end users.

下一章「Compliance」的部分有提到 embedded POPs 是不包括在 PCI DSS、HIPAA 以及 SOC 這些 compliance 的，所以也可以回頭看到在提到推薦掛上來的內容，有避開掉敏感服務，主要是以大家都會看到一樣的內容的東西為主：

Embedded POPs are custom built to deliver large scale live-streaming events, video-on-demand (VOD), and game downloads.

看起來有點像是 Netflix 的 Open Connect 或是 Google 的 GGC，讓 ISP 或是 MNO 可以放 cache service 降低對外消耗的流量。

這應該會回到老問題，ISP/MNO 當然是希望 CloudFront 花錢放機器進來，不會是 ISP/MNO 自己申請放，這不是技術問題而是商業問題...

雲端的流量費用

在「Cloud Egress Costs (getdeploying.com)」這邊看到的文章，原文在「Cloud Egress Costs」這邊，主要是整理了表格出來可以快速了解不同雲端的流量費用差異，裡面不是單純 VPS 比較，而是各類的服務都拿出來比，像是 storage 類的以及 CDN 類的都有放進來...

Backblaze 的頻寬費用算法頗有趣，每個月給資料量的三倍大小當作免費頻寬，沒記錯的話因為 Cloudflare 是 Backblaze 的 partner，兩邊的傳輸費用不計費，如果資料是可以公開的，可以透過這個方式接出來；如果真的得走一般的流量輸出，收費是 US$0.01/GB (所以換算後是 US$10/TB)。

三家常被擺在一起的 VPS (Linode、DigitalOcean、Vultr) 的頻寬也都是 US$10/TB。

以前沒注意到的是 OVH Cloud 與 Scaleway 的頻寬費用居然是免費的？另外 Hetzner 雖然要收費但也很低？有機會好像該玩看看，看一下品質如何？

Vultr 推出了自己的 CDN

Vultr 推出了自己的 CDN：「Vultr CDN: Revolutionizing Content Delivery with Global Reach and Unbeatable Price-to-Performance」。

畢竟手上也有很多機房了，這算是弄個加值服務賣... 不過對於量小的人就不太划算了，有基本開銷 US$10/mo (看起來不可抵使用的量)，然後再加上頻寬費：

亞洲區的點主要還是比較傳統的點... 其中日本的東京與大阪以及新加坡都是 US$0.03/GB，韓國的首爾則是 US$0.05/GB；歐美看起來是 US$0.01/GB。

目前還在 beta，可以觀望看看...

Hacker News 目前搬上 Cloudflare

Hacker News 前陣子似乎是因為被打而轉移到 Cloudflare 上：

;; ANSWER SECTION:
news.ycombinator.com.   1       IN      CNAME   news.ycombinator.com.cdn.cloudflare.net.
news.ycombinator.com.cdn.cloudflare.net. 300 IN A 172.67.5.232
news.ycombinator.com.cdn.cloudflare.net. 300 IN A 104.22.6.236
news.ycombinator.com.cdn.cloudflare.net. 300 IN A 104.22.7.236

另外可以參考「Site report for http://news.ycombinator.com」這邊的記錄，我另外備份一份放在 archive.today 上：「Site report for http://news.ycombinator.com」。

可以看到先前是指到 209.216.230.240，然後今年 (2024) 年初的時候似乎是因為 DDoS 的關係，在骨幹上被 blackhole 掉，後來就轉到 Cloudflare 上了。

一個比較意外的是看到報告說是 FreeBSD，等之後切回去再來研究看看？

Cloudflare 的 WAF 在科技類的網站容易誤判，像是「Ask HN: Does Cloudflare block HN comments if you have code blocks in a reply?」這邊就遇到了，可以在留言裡面看到大家在研究要怎麼繞 WAF XDDD

等到切回去應該就會恢復，不過還在 Cloudflare 上的這陣子應該會繼續看到抱怨...

CloudFront 支援 4096-bit RSA 的 SSL/TLS certificate 了

CloudFront 總算支援 4096-bit 的 RSA SSL/TLS certificate 了：「Amazon CloudFront now supports 4096-bit RSA TLS certificates」。

翻了一下 AWS ACM，看起來是 2020 年以前就支援 4096-bit RSA SSL/TLS certificate 了，CloudFront 晚蠻多的...

另外查了一下目前的強度，NSA 給出 2048-bit RSA 對到 112-bit strength，而 3072-bit RSA 對到 128-bit strength；至於 4096-bit RSA，目前是估算大約在 140-bit strength，有點微妙的數字。

看起來主要應該是給 compliance 需求使用的，有些舊的 library 未必支援 ECC 類的演算法，還是得透過拉高 RSA key size 來增加安全性。

arXiv 上了 Fastly CDN

看到 arXiv 宣佈上了 Fastly 的 CDN：「Faster arXiv with Fastly」。

翻了一下 arxiv.org 的 DNS record，可以看到現在是這樣：

;; ANSWER SECTION:
arxiv.org.              10      IN      A       151.101.131.42
arxiv.org.              10      IN      A       151.101.3.42
arxiv.org.              10      IN      A       151.101.67.42
arxiv.org.              10      IN      A       151.101.195.42

用 mtr 測試，看起來 HiNet 過去的 routing 還是進到新加坡。

不過 static.arxiv.org 是在 CloudFront 上：

;; ANSWER SECTION:
static.arxiv.org.       3600    IN      CNAME   daa2ks08y5ls.cloudfront.net.
daa2ks08y5ls.cloudfront.net. 60 IN      A       13.35.35.100
daa2ks08y5ls.cloudfront.net. 60 IN      A       13.35.35.29
daa2ks08y5ls.cloudfront.net. 60 IN      A       13.35.35.88
daa2ks08y5ls.cloudfront.net. 60 IN      A       13.35.35.127

依照官方的說明看起來還在換，只是不知道已經在 CloudFront 上的 (像是上面提到的 static.arxiv.org) 會不會換過去：

That includes our home page, listings, abstracts, and papers — both PDF and HTML (more on that soon).