HiNet 宣佈年底關閉 Proxy 服務

HiNet 宣佈今年年底將要關閉 Proxy 服務了,也就是 proxy.hinet.net:80 這組:「HiNet Proxy 終止服務公告」。

現在愈來愈多網站都走 HTTPS 的情況下,Proxy 服務能帶來的好處愈來愈少了... 大概只剩下出國的優先權比較高 (因為變成機房 IP 連出國)。

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 這樣設計... 不知道後續會有什麼樣的變化。

在 Amazon Aurora 利用 ProxySQL 的讀寫分離提昇效能

Percona 的「Leveraging ProxySQL with AWS Aurora to Improve Performance, Or How ProxySQL Out-performs Native Aurora Cluster Endpoints」這篇有夠長的,其實就是發現 AWSAmazon Aurora 只使用 Cluster Endpoint 無法壓榨出所有效能,只有當你讀寫分離拆開 Cluster endpoint 與 Reader endpoint 時才能提昇效能。主要是在推銷 ProxySQL 啦,其他的軟體應該也能達到類似的效果...

然後這張怪怪的,應該是 copy & paste 上去的關係?

因為事後再疊 ProxySQL 進去不會太困難,一般還是建議先直接用服務本身提供的 endpoint (少了一層要維護的設備),等到有遇到效能問題時再來看是卡在哪邊,如果是 R/W split 可以解決的,才用 ProxySQL 或是其他軟體來解...

imgproxy:自動處理圖片的工具

看到「imgproxy: Resize your images instantly and securely」這篇文章,介紹「DarthSim/imgproxy」這個專案,想起很久以前的同事在 PIXNET 弄的 *.pimg.tw 系列服務...

imgproxy 可以 resizing,也可以 croping,然後也支援 signature token 機制,感覺是每個大一點的站台都會自己刻一次的服務 XD

整個專案以 Golang 為主,效能應該是不錯... 不過一般前面還是會放 cache 機制 (像是 CDN 之類的服務),而不會把 loading 直接打進來,避免同樣的圖片一直重複計算。

Heimdall Data:自動 Cache RDBMS 資料增加效能

看到 AWS 的「Automating SQL Caching for Amazon ElastiCache and Amazon RDS」這篇裡面介紹了 Heimdall Data – SQL caching and performance optimization 這個產品。

從官網的介紹也可以看出來是另外疊一層 proxy,但自動幫你處理 cache invalidation 的問題:

But what makes Heimdall Data unique in industry is its auto-cache AND auto-invalidation capability. Our machine learning algorithms determine what queries to cache while invalidating to ensure maximum performance and data integrity.

看起來支援了四個蠻常見的 RDBMS:

Heimdall Data supports most all relational database (e.g. MySQL, Postgres, Amazon RDS, Oracle, SQL Server, MariaDB).

看起來是一個花錢直接買效能的方案... 不過 cache invalidation 的部分不知道要怎麼跨機器做,在 FAQ 沒看到 cluster 情況下會怎麼解決。

Web Cache Deception Attack

在「How (Not) to Control Your CDN」這邊看到了「Web Cache Deception Attack」這個攻擊方式。

攻擊的手法是利用網站會把 /user/personal-info/foo.css/user/personal-info 視為一樣的內容時,配合 CDN 或是 reverse proxy server 會把 .css 設定無差異 cache 時,就可以在 cache server (cache edge) 取得使用者的敏感資料。

這主要是 url routing 的條件放太寬造成的。

另外 Mark Nottingham 還建議 cache 應該在 origin server 上控制,而非在 CDN 上設定。也就是說,在 origin server 上送出 Cache-Control,讓 CDN 或是 reverse proxy server 使用這個值來判斷 cache。

Dropbox 在全球建機房加速...

Dropbox 為了加速傳輸,在全球到處建機房降低 latency:「Infrastructure Update: Pushing the edges of our global performance」。

就他們測試發現,透過 proxy server 降低 latency 的效果很不錯:

We’ve tested and applied this configuration in various markets in Europe and Asia. In France, for example, median download speeds are 40% faster after introducing proxy servers, while median upload speeds are approximately 90% faster. In Japan, median download speeds have doubled, while median upload speeds are three times as fast.

亞洲區是效能增加最多的...

大量破解 Facebook 帳號的方法

Facebook 安全設計上的問題造成的重大漏洞:「Hacker reveals How He Could have Hacked Multiple Facebook Accounts」。

攻擊者先用很多 proxy 去打出哪些 id 是有效的:

Gurkirat first collected valid Facebook IDs by making queries to Facebook Graph API starting with 100,000,000,000,000, since Facebook IDs are generally 15-digit long and then visited www.facebook.com/[ID] with a valid ID number in place of [ID].

這樣他就順利打出兩百萬個帳號:

Once entered, the URL automatically redirected and changed the Facebook ID to the user's username. In this way, first, he was able to make a list of 2 Million valid Facebook usernames.

接下對這些帳號發出重設密碼的需求,並且開始亂猜六碼數字 (也是透過大量的 proxy):

Then using a script, hundreds of proxies and random user-agents, Gurkirat automatically initiated the password reset requests for those 2 million users, each assigned a 6-digit password reset code, thus consuming the complete 6-digit range.

然後就打出一票來了:

最大的問題在於六碼數字的強度不夠,但 Facebook 看起來沒打算改...

舊 bug 新名字:httpoxy

依照慣例,security issue 都會取個名字,這次叫做 httpoxy:「A CGI application vulnerability for PHP, Go, Python and others」。

事情發生在兩個命名變數上的衝突:

  • RFC 3875 (The Common Gateway Interface (CGI) Version 1.1) 定義了 CGI 環境會把 Header 裡的 Proxy 欄位放到環境變數裡的 HTTP_PROXY
  • 而很多程式會拿環境變數裡的 HTTP_PROXY 當作 proxy 設定。

這件事情 2001 年在 libwww-perl 就有發生過 (並且修正),curl 也發生過 (然後修正),2012 年在 Ruby 的 Net::HTTP 也發生過 (也修正了)。

然後在 2016 年還是被發現有很多應用程式會中獎... 這頭好痛啊 :o

Amazon S3 推出加速功能

Amazon S3 推出了新的加速功能,並且向更多地區提供 AWS Import/Export Snowball 服務:「AWS Storage Update – Amazon S3 Transfer Acceleration + Larger Snowballs in More Regions」。

其中的 Amazon S3 Transfer Acceleration 只要把本來的 BUCKET_NAME.s3.amazonaws.com 或是帶有地區的 BUCKET_NAME.s3-region.amazonaws.com 變成 BUCKET_NAME.s3-accelerate.amazonaws.com 就可以了,他會透過 CloudFront 的節點做 proxy,並且透過 AWS 內部最佳化過的網路傳輸。

由於這是定位為 Amazon S3 的服務,而實際測試後也確認不會有 cache:他的目的在於降低 latency 而加速,而不是 cache 加速,所以大量 GET 相同內容的部份應該還是用 CloudFront 會比較好。

再來是費用的部份增加相當多,第一筆要收的是 CloudFront 的費用,再來才是計算 Transfer Acceleration 的費用:

Transfer Acceleration pricing is in addition to Data Transfer pricing.

從 Internet 進 CloudFront 再進 Amazon S3 的要收 USD$0.04/GB (透過在美國、歐洲或是日本的 CloudFront 節點) 或 USD$0.08/GB (透過其他 CloudFront 節點)。

另外要收的是從 Amazon S3 一路傳到 Internet 的部份,USD$0.04/GB。如果是傳到其他 AWS region 的話,也是 USD$0.04/GB。

不過他有效能保證條款 (雖然掌控全不在自己),AWS 會持續監控有沒有比較快,如果沒有的話系統會 bypass 回原來的 Amazon S3:

Each time you use Transfer Acceleration to upload an object, we will check whether Transfer Acceleration is likely to be faster than a regular Amazon S3 transfer. If we determine that Transfer Acceleration is not likely to be faster than a regular Amazon S3 transfer of the same object to the same destination AWS region, we will not charge for that use of Transfer Acceleration for that transfer, and may bypass the Transfer Acceleration system for that upload.

我本來以為會是在 DNS 層 bypass 回本來的 region,結果發現是 307 redirect 重導回 Amazon S3 上,效能上應該還是會差一些...

可以看出這個架構的特性主要還是用在上傳的部份,而且用在網路不穩定的環境下很重要 (像是電信網路上的行動裝置),因為 latency 的減少會對於 packet loss 造成的 retry 有很大的幫助。

下載的部份應該會比本來 Amazon S3 快 (因為 Amazon 本身會加速),但由於沒有 cache,除非有特殊需求,不然建議不要這樣規劃。

另外一個是 AWS Import/Export Snowball 推出的新硬體,以及新區域。

新硬體是 80TB 的版本,本來只有 50TB 的版本:

The original Snowball appliances had a capacity of 50 terabytes. Today we are launching a newer appliance with 80 terabytes of capacity.

而新區域包括了 AWS GovCloud (US)、US West (Northern California)、Europe (Ireland) 以及 Asia Pacific (Sydney) 這三區:

Today we are making Snowball available in four new Regions: AWS GovCloud (US), US West (Northern California), Europe (Ireland), and Asia Pacific (Sydney). We expect to make Snowball available in the remaining AWS Regions in the coming year.

其中 80TB 版本只在這三區生效,其他區可以選擇 50TB 或是 80TB 版本:

If you are transferring data in or out of the US East (Northern Virginia), US West (Oregon), US West (Northern California), or AWS GovCloud (US) Regions using Snowball you can choose the desired capacity. If you are transferring data in or out of the Europe (Ireland) or Asia Pacific (Sydney) Regions, you will use the 80 terabyte appliance.

日本還是沒進場...