CloudFlare 與 Google Cloud Platform 的合作

在「CloudFlare is now a Google Cloud Platform Technology Partner」這邊提到了 CloudFlareGoogle Cloud Platform 的合作,應該只有這段比較重要 (有實質意義):

Also, CloudFlare peers with Google in strategic locations globally, improving response times for Google Cloud Platform services.

也就是會多拉一些 peering 讓 CloudFlare 與 Google Cloud Platform 之間變順?不過更重要的部份,也就是 CloudFlare 對 client (到使用者這端) 之間的品質一直都不太好,大多數人都只是當作免費頻寬在用...

CloudFlare 的 HTTPS 支援 HSTS 設定

CloudFlareHTTPS 支援 HSTS:「Enforce Web Policy with HTTP Strict Transport Security (HSTS)」。

目前可以設 max-ageincludeSubDomains。至於 preload 還在規劃。不算複雜的功能 (加上 HTTP header),不過對於安全性的幫助很大。

不過 origin 好像也可以送,不知道 CloudFlare 會不會濾掉...

CloudFlare 的 Universal SSL

CloudFlare 這幾天的動作頗多:「Universal SSL: Encryption all the way to the origin, for free」。

Universal SSL 要保護的是右邊 CloudFlare 到 Origin Server 這段:現在可以讓 CloudFlare 簽 SSL certificate,而不用到外面買了。

這邊的 SSL certificate 只有 CloudFlare 認得,一般的瀏覽器預設值不會認:

The CloudFlare Origin CA is currently not trusted by browsers, so these certificates should not be used on sites that are not behind CloudFlare.

CloudFlare 宣佈停用 RC4,並且支援 ChaCha20+Poly1305

CloudFlare 同時宣佈了停用 RC4 與支援 ChaCha20+Poly1305 的計畫:「End of the road for RC4」、「Do the ChaCha: better mobile performance with cryptography」。

2014 年年初的時候,CloudFlare 先把 RC4 從 TLS 1.1+ 的連線拿掉,而 2014 年五月時,再把 RC4 搬到 cipherlist 裡優先權最低的,成功的讓 99.9991% 的 request 改用 AES3DES (大約五個 9 ):

而九個月後的現在,CloudFlare 上 RC4 使用的比率則是降到了 0.000002%,反過來說也就是 99.999998% 的等級 (七個 9),也讓 CloudFlare 決定直接停用掉 RC4。

另外一個重大的新進展則是 ChaCha20+Poly1305,兩個都是 Daniel J. Bernstein 的作品。其中 ChaCha20 是 stream cipher,Poly1305 是 MAC。

由於 RC4 已經不夠安全,在行動平台上要夠安全必須使用 AES,但 AES 在 ARM 上面還沒有普及:在 Nexus 6 用的 ARMv7 不支援,是透過 Qualcomm Snapdragon 805 的加掛模組做的,而在低階手機支援度就更不用說了。

Google 大力推動 ChaCha20+Poly1305 的目的,是為了在行動平台上找到一個與 RC4 可以匹敵的速度,而且有著可以超越 AES-GCM 安全性的 cipher+MAC。

在 CloudFlare 採用 ChaCha20+Poly1305 前,Google 是唯一一個在 HTTPS 上大幅採用的單位,而瀏覽器的部份也只有 Google Chrome 有支援。雖然 Firefox 一直有喊著要支援,但這是個雞生蛋蛋生雞的問題,可以看到進度不怎麼快 (Bug 917571 - Support ChaCha20+Poly1305 cipher suites)。

CloudFlare 支援之後,使用 ChaCha20+Poly1305 的 pool 瞬間大了不少。可以看到一上線的使用率不算低,瞬間就有 10% 了:

希望可以推動 Firefox 快一點支援... (這是養大 pool 的下一步)

對付最近 HiNet 到 CloudFlare 不穩定的情況

解法是透過 proxy.hinet.net:80 的 Proxy 服務避開,利用 Proxy 的 IP 出國優先權比較高至少能通。下面說明一下原因。

這可以解決不少網站不順的問題,像是 Stack Overflow 有用到 CloudFlare 的服務。

可以看一般家用的 IP 去 ping (2015/01/22 00:31):

--- www.cloudflare.com.cdn.cloudflare.net ping statistics ---
101 packets transmitted, 63 received, 37% packet loss, time 104589ms
rtt min/avg/max/mdev = 88.208/131.391/227.889/45.322 ms

即使是這個時間,CloudFlare 的品質仍然是爛到爆炸。

另外看這兩張圖,這是在 HiNet 機房端對 www.cloudflare.com.cdn.cloudflare.net 這個網域的 ICMP ping 的 latency 與 packet loss 記錄:

這是機房端的 IP 監控的資料,可以看到 latency 會飄高,但至少將 packet loss 維持在一定程度以下。這也是為什麼 proxy.hinet.net:80 可以避開這個問題。

另外我利用 HiNet 所配發的 PPPoE static IP 測試,也可以避開這個問題,所以 IP 分享器撥號時使用 PPPoE static IP 的方式也可以避開。

jQuery.com 九月的安全事件報告

jQuery.com 在九月時被攻陷的事情的報告出爐了:「jQuery.com September 2014 Security Retrospective」。

除了 ShellShock 的問題外,還包括了不少既有的漏洞沒修,所以最後也不太輕處到底是從哪個洞進來的,不過看起來最像的是 ShellShock?不過報告上沒有發現 CDN 的部份有被攻陷 (code.jquery.com 的部份),所以看起來只有主站受到影響?

而因為受到 DDoS 攻擊,所以把非 CDN 部份的服務丟上 CloudFlare 了,由 CloudFlare 的人贊助 Enterprise 版的服務給 jQuery.com 使用,讓 CloudFlare 幫忙擋掉攻擊的部份...

CloudFlare 的擴張計畫

在 CloudFlare 的「One More Thing: Keyless SSL and CloudFlare's Growing Network」這篇文章裡提到了 CloudFlare 的擴張計畫,其中藍色是已經有的點,而橘色是計畫的點:

雖然是說打算在 12 個月內搞定上面的計畫:

The map above shows all the locations where CloudFlare is actively working to turn up data centers over the next 12 months.

但不知道多久才會把這些點都設完,尤其這是有規劃進入中國大陸的情況?

另外看起來台灣也會有點,不知道會放到哪裡... (以及 routing 會怎麼繞)

CloudFlare 的 Keyless SSL 服務

CloudFlare 有兩篇公告出來:「Announcing Keyless SSL™: All the Benefits of CloudFlare Without Having to Turn Over Your Private SSL Keys」、「Keyless SSL: The Nitty Gritty Technical Details」。前面的一篇偏向公告文 (以及公關稿),而後面的一篇提到了實際運作的方式。

用兩張 Keyless SSL 的 flow 就可以知道差異了,一張是 RSA-based,一張是 DH-based:

把與 private key 相關的運算拆出來,由後方計算完成後再計算出 session key 與 client 溝通。如此一來,雖然速度比較慢,但 private key 管理在客戶自己手上...

HiNet (Colocation) 對 CloudFlare 的速度

昨天才找人做完 CloudFlareSmokePing 資料,今天看到資料的時候覺得還蠻特別,跟一般預想的情況不太一樣...

CloudFlare 在台灣使用的人應該是 Plurkimages.plurk.com (透過 CNAME 指過去,應該是企業付費用戶) 以及一堆 Content Farm。

上面的圖是我們家在 HiNet 三重重新機房端 (203.69.67.x) 對 www.cloudflare.com.cdn.cloudflare.net 做出來的資料,這種 pattern 很上班時間用的網站的感覺?

多觀察幾天看看好了...

CloudFlare 的頻寬成本

CloudFlare 上個月底的時候發了一篇關於頻寬成本的文章:「The Relative Cost of Bandwidth Around the World」。

歐洲是最低的,北美還高出歐洲一些。亞洲與南美是同個等級,大約是歐洲的六倍多,而澳洲是最貴的。

成本跟 transit 以及 peering 的量有關,這是 CloudFlare 提供的數字,只能拿來參考用...