Home » Posts tagged "cloudflare" (Page 8)

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 很上班時間用的網站的感覺?

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

免費的 CDN 資源

在「A List of Free Public CDNs for Web Developers」這篇文章裡面列出了網路上免費的 CDN 資源。

可以看到 MaxCDN (jsDelivrOSSCDNjQuery CDN) 與 CloudFlare (cdnjs) 都投資了不少在其中。不過 MaxCDN 的部份都沒有拿出亞洲 PoP 來用,速度還是慢了不少...

對於有使用各種套件的人,可以在這邊的列表上找一找,除了可以節省自己機器的頻寬負擔外,另外用 CDN 也有機會與其他人共用 cache 而加速...

CloudFlare 支援 WebSockets

CloudFlare 的官方 blog 上的公告:「CloudFlare Now Supports WebSockets」。

於是 CloudFlare 自豪的 DDoS 防護服務也涵蓋到 WebSockets 了:

The ability to protect and accelerate WebSockets has been one of our most requested features.

裡面其實還提到一些 CDN + WebSockets 的技術問題 (像是 port 的數量),有興趣的可以再仔細看 :o

Archives