AWS 宣佈 CloudFront 在非洲的第一個節點開在南非的約翰尼斯堡 (Johannesburg)：「Amazon CloudFront Expands into Africa with new Edge Location in Johannesburg and first Edge Location in Bangalore」。
這樣各大洲都有點了...
Tag: cdn
Home » Posts tagged "cdn"
CloudFront 在東京開到第八個點了...
看到 Amazon CloudFront 宣佈在東京開到第八個點了：「Amazon CloudFront launches eighth Edge location in Tokyo, Japan」。
Amazon CloudFront announces the addition of an eighth Edge location in Tokyo, Japan. The addition of another Edge location continues to expand CloudFront's capacity in the region, allowing us to serve increased volumes of web traffic.
這個成長速度有點驚人，一月才加了兩個，現在又要再加一個... 不過大阪還是維持一個。
Bootstrap 的 CDN 從 MaxCDN 換到 StackPath (Highwinds) 了...
最近在寫網頁時發現 Bootstrap 的網站上給的 CDN 網址改了，從本來用的 maxcdn.bootstrapcdn.com (MaxCDN) 變成 stackpath.bootstrapcdn.com (StackPath，本來的 Highwinds)。
而且看起來跟 MaxCDN 的合作已經全部停了，現在 maxcdn.bootstrapcdn.com 也是指到 StackPath 上。
翻了 Wayback Machine 上的記錄，看起來是在 20180409045017 與 20180410051321 這之間換的，也就是大約是在 2018/04/10 前後換的。不知道後面的交易是什麼...
可以參考 K 社的 SmokePing 資料「SmokePing Latency Page for netdna.bootstrapcdn.com (NetDNA, Bootstrap)」：
可以看到 HiNet 走的點的latency 比之前好不少...
Microsoft 啟用自己的 CDN 了...
在朋友的 tweet 裡看到微軟啟用自己的 Azure CDN 了，先前應該是提供 Akamai 與 EdgeCast 的服務：「Announcing Microsoft's own Content Delivery Network」。
看圖似乎是有台灣的點，不過我找不到可以測試 traceroute 的 endpoint，頁面上用的圖還是 EdgeCast 的啊 XDDD
;; ANSWER SECTION: azurecomcdn.azureedge.net. 1604 IN CNAME azurecomcdn.ec.azureedge.net. azurecomcdn.ec.azureedge.net. 3404 IN CNAME cs9.wpc.v0cdn.net. cs9.wpc.v0cdn.net. 3404 IN A 117.18.232.200
然後公測期間優惠價 50%：
Azure Content Delivery Network Standard from Verizon (S1) and Akamai (S2) and Microsoft (S3)*
*S3 is currently in public preview. CDN rates will be 50% of the stated price during this period.
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
Arecords, 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？
CloudFront 在台北的第二個 PoP
Twitter 上看到了 Amazon CloudFront 宣佈了台北的第二個 PoP：
Amazon CloudFront announces 2 new Edge Locations, adding a second location in Taipei & a third location in Singapore. https://t.co/pU5gDbJWBT pic.twitter.com/9U4ZLBSXmk
— Amazon Web Services (@awscloud) April 25, 2018
這個也是喊好久了，從去年就有消息一直到現在... 這樣台灣多了一個 backup，比較不會導去香港或是日本了。不過新 PoP 的代碼找不到，試著找 tsa 與 tpe 以及後面接數字，還是只有找到 tpe50，不知道是不是後來不露出代碼了...
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 這樣設計... 不知道後續會有什麼樣的變化。
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。
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 的可預測性而被取出，像是 CRIME、BREACH、TIME、HEIST (沒完結過...)，而因為全面關閉壓縮，對於效能的影響很大。
而 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...