Tag: fastly

HashiCorp 家的軟體看起來都支援 APT repository 了

以前 HashiCorp 家的軟體大多都是自己下載 binary 後放到 /usr/bin 或是 /usr/local/bin 下使用，剛剛翻了一下 Nomad 與 Vault，看起來都支援 APT repository 了：「https://apt.releases.hashicorp.com」；另外也有 RPM repository：「https://rpm.releases.hashicorp.com」。

這樣下個禮拜分享會的投影片也要改一改了...

另外看了一下架構，從錯誤訊息觀察，看起來後面是 Amazon S3，前面是 Fastly 的 CDN。

日本囯土地理院提供的日本地圖圖資

查資料的時候發現日本的囯土地理院有開放使用日本的地圖圖資：「地理院タイル一覧」。

圖資放在 cyberjapandata.gsi.go.jp 這個網址上，前面掛 Fastly 的 CDN：

;; ANSWER SECTION:
cyberjapandata.gsi.go.jp. 300   IN      CNAME   d.sni.global.fastly.net.
d.sni.global.fastly.net. 30     IN      A       199.232.46.133

抓個鶯谷園的點出來看：

然後可以看到非常多不同的資料，像是「1928年頃」、「活断層図（都市圏活断層図）」、「明治期の低湿地」、「磁気図2010.0年値」，另外針對比較大的災難也有提供一些區域圖，像是「平成25年7月17日からの大雨 山口地方「須佐地区」正射画像（2013年7月31日撮影）」。

另外因為 url 形式是 https://cyberjapandata.gsi.go.jp/xyz/std/{z}/{x}/{y}.png 這種格式，可以直接用 Leaflet 這類 library 吃進去...

Fastly 服務掛掉的事件

在 Hacker News 上看到「Summary of June 8 outage (fastly.com)」這邊的討論，連結是 Fastly 官方先發布的說明：「Summary of June 8 outage」。

其中提到了是因為客戶的某些設定造成的：

10:27 Fastly Engineering identified the customer configuration

另外特別提到了 Fastly 的 WebAssembly 與 Compute@Edge，看起來應該就是這邊炸鍋：

Broadly, this means fully leveraging the isolation capabilities of WebAssembly and Compute@Edge to build greater resiliency from the ground up. We’ll continue to update our community as we make progress toward this goal.

我猜基本的資源保護機制應該有上 (像是在程式裡面自己 call 自己之類的，Fork bomb 之類的)，可能是這兩個東西互串的某些部份沒有保護到，就一路把資源吃完炸掉。

看起來後續會有比較完整的報告，到時候再來看看會透露出多少東西...

QUIC 成為標準，從 RFC 8999 到 RFC 9002

前幾天的新聞了，這兩天 Fastly 與 Cloudflare 也都發文章出來了，QUIC 成為標準：「QUIC is now RFC 9000」、「QUIC Version 1 is live on Cloudflare」。

主要是這兩家都發稿宣傳他們的平台都支援 QUIC 了，接下來可以等一些測試報告，看看在 web 這種已經有不少複雜的 workaround 機制下，TCP BBR 環境的 HTTP/2 跟 QUIC 環境會有多少差異... 記得 QUIC 也是 BBR-based 的演算法。

在 QUIC 下的 https 協定會走 443/udp，如果防火牆是預設阻擋所有連線，然後逐條開放的話，需要另外開這組設定。

另外就是等 nginx 支援了，在「NGINX QUIC Preview」這邊有些資料，然後「">nginx-quic: log」裡面可以看到東西，裡面不少 commit 只是跟 nginx 本家同步而已，不過還是可以看到一些跟 QUIC 有關的...

Backblaze 與 Fastly 合作

Twitter 上看到的消息，Backblaze 與 Fastly，免除 Origin 到 CDN 這段的流量費用：

新聞稿是「Set Your Content Free With Fastly and Backblaze B2」這篇：

Our new collaboration with Fastly, a global edge cloud platform and CDN, offers an integrated solution that will let you store and serve rich media files seamlessly, free from the lock-in fees and functionality of closed “goliath” cloud storage platforms, and all with free egress from Backblaze B2 Cloud Storage to Fastly.

不過這不是第一家提供這樣的方案，在 2018 年的時候就有跟 Cloudflare 合作，免除了 Origin 端到 CDN 端這段費用：「Backblaze 與 Cloudflare 合作，免除傳輸費用」。

Fastly 觀察到因 COVID-19 產生的流量上升資料

因為 COVID-19 的關係，可以預期網路的流量一定會大幅提昇，但實際上是多少總是需要一些數據才能想像...

剛剛看到 Fastly 放出了他們觀察到因為 COVID-19 而產生的流量變化：「How COVID-19 is affecting internet performance」。

從 2020 年二月與三月相比，可以看到許多區域的流量都有大幅成長，尤其是重災區的義大利與英國，不過這邊沒有給與 2019 三月的比較 (YoY)：

另外是這些流量成長的種類，可以看到 streaming、數位媒體與教育類的流量大幅成長：

在網路速度的部份，可以看到大多數的地區是下降的，但加州沒什麼影響，而日本反而是上升的，應該可以解讀為這兩個地區平常就有夠多的容量，所以真的有爆量而用到的時候反而不會是瓶頸？

接下來幾個月應該會更嚴峻...

保護 TLS 的 Hostname

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

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

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

GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務

以往在 GitHub 上如果要使用 HTTPS 只能使用 *.github.io 網域，現在 GitHub 宣佈透過 Let's Encrypt 的服務支援了：「Custom domains on GitHub Pages gain support for HTTPS」：

We have partnered with the certificate authority Let’s Encrypt on this project. As supporters of Let’s Encrypt’s mission to make the web more secure for everyone, we’ve officially become Silver-level sponsors of the initiative.

不過目前只支援 CNAME record (標準) 或是 ALIAS record 的方式 (非標準，也稱為 ANAME，有些 DNS provider 有支援，主要用在網域本身 (i.e. root domain) 無法使用 CNAME)。

如果是使用 A record，則是需要更新 IP 位置：

If you are using A records, you must update your site’s DNS records with new IP addresses. Please see our guide to setting up your custom domain with Pages and update any A records you might have set.

另外也提供 HTTP 轉 HTTPS 的選項：

以前 HTTPS 還得自己弄伺服器處理，現在可以直接往 GitHub 上丟了...

另外用查出來的 IP 看了一下架構，IP 是 Fastly 的，所以應該是跟 Fastly 合作，但不確定是 Fastly 自己搞定 Let's Encrypt 的憑證，或是 Fastly 提供 Port 80/443 的 TCP Proxy？

HTTPS Everywhere 改變更新 Ruleset 機制，變成定時更新...

HTTPS Everywhere 是我很喜歡的一個套件，裡面有 Ruleset，會將 Ruleset 表內認定有支援 HTTPS 網站的 HTTP request 都改成 HTTPS，這可以降低被攔截的風險。像是網站雖然有 HSTS 但第一次連線時走 HTTP 的情況，以及網站本身有支援 HTTPS 但沒有設定 HSTS 時，在網址列上誤打 HTTP 版本的情況。

先前版本的 Ruleset 是隨著軟體更新時，包在軟體內一起更新。這樣的缺點是更新速度比較慢，但好處是不需要伺服器端，而且隱私性也比較高。而現在 EFF 決定還是要推出線上更新的版本，以加速 Ruleset 更新的速度：「HTTPS Everywhere Introduces New Feature: Continual Ruleset Updates」。

We've modified the extension to periodically check in with EFF to see if a new list is available.

而頻寬的部份由 Fastly 贊助：

If you haven't already, please install and contribute to HTTPS Everywhere, and consider donating to EFF to support our work!

如果對這點有疑慮的，也還是可以關掉 auto updater 避免洩漏資訊給 EFF 或是 Fastly。

CircleCI 的隱私問題

作者看 CircleCI 網站時發現的問題：「CircleCI trusts 8 analytics companies with your source code and API tokens」。

CircleCI 網站引用了這八個網站的 javascript：

  • Pusher
  • Intercom
  • Launch Darkly
  • Amplitude
  • Appcues
  • Quora (??)
  • elev.io
  • Optimizely

有些有很明顯目的而且也夠大，但有些就沒聽過了... 不過照 BuiltWith 上分析的資料「circleci.com Technology Profile」，遠超過這些啊 XDDD

可以看到 GitHub 站上只引用了 Facebook (不過這是哪邊出現的啊？)，另外因為使用 Fastly 的 CDN 服務，所以 Fastly 也是屬於 GitHub 的信任名單；這兩家都算夠大的 vendor：「github.com Technology Profile」。

而 Travis CI 則是 Google Analytics 與 Fastly，也是兩家夠大的 vendor：「travis-ci.com Technology Profile」。

所以對於很注重這資安方面的人，應該還算是有選擇...