Home » Posts tagged "cloudflare" (Page 8)

CloudFlare 加速 zlib library

CloudFlare 大幅改善 zlib,使得速度相較原來的版本快了許多:「Fighting Cancer: The Unexpected Benefit Of Open Sourcing Our Code」。

改變的部份主要是 CPU 指令集的特性,以及 longest-match function 的改善。可以看出不同的測試樣本 (corpus) 在壓縮率沒有變差的情況下,大幅改善了速度。

Calgary corpus

Canterbury corpus

Large corpus

Silesia corpus

速度快非常多,跟 Google 以壓縮率為導向而放出來的 zopfli 剛好是兩個極端:「Google 發表與 zlib/deflate 相容的壓縮程式,再小 5%...」。

CloudFlare 的大阪 PoP

CloudFlare 宣佈在大阪建 PoP,將京阪神 (& 西側),以及名古屋地區納入服務範圍:「Osaka, Japan: CloudFlare's 35th data center」。

人剛好就在大阪,實際測試發現還是有些狀況。手機的部份還是會導到東京交換,住的地方也還是到東京交換。看起來還有不少 DNS resolver 的 IP 資訊要調整。

另外這也使得日本地區有完全異地備援的機制,如果東京機房出問題時可以透過大阪撐著,不需要跑到國外 (應該是香港 PoP)。

CloudFlare 對 Go 上面加解密系統的改善

CloudFlare 發佈了自己版本的 Go,修改了其中的 crypto subsystem:「Go crypto: bridging the performance gap」。

文章花了不少篇幅介紹 AEAD (Authenticated Encryption with Associated Data),而目前 CloudFlare 支援的是 AES-GCM 與 ChaCha20-Poly1305,也是兩大主流,分別佔了 60% 與 10% 的 HTTPS 流量:

As such today more than 60% of our client facing traffic is encrypted with AES-GCM, and about 10% is encrypted with ChaCha20-Poly1305.

CloudFlare 提供的改進使得速度快很多,並且有考慮到 side-channel attack 的問題:

Both implementations are constant-time and side-channel protected.

                         CloudFlare          Go 1.4.2        Speedup
AES-128-GCM           2,138.4 MB/sec          91.4 MB/sec     23.4X

P256 operations:
Base Multiply           26,249 ns/op        737,363 ns/op     28.1X
Multiply/ECDH comp     110,003 ns/op      1,995,365 ns/op     18.1X
Generate Key/ECDH gen   31,824 ns/op        753,174 ns/op     23.7X
ECDSA Sign              48,741 ns/op      1,015,006 ns/op     20.8X
ECDSA Verify           146,991 ns/op      3,086,282 ns/op     21.0X

RSA2048:
Sign                 3,733,747 ns/op      7,979,705 ns/op      2.1X
Sign 3-prime         1,973,009 ns/op      5,035,561 ns/op      2.6X

AES-GCM 與 EC 的改善主要是利用 CPU 指令集加速:

[T]herefore we created assembly implementations of Elliptic Curves and AES-GCM for Go on the amd64 architecture, supporting the AES and CLMUL NI to bring performance up to par with the OpenSSL implementation we use for Universal SSL.

不過 RSA 的部份雖然幅度也不小 (比起 AES 與 EC 的部份是不大,不過純就數字來看,快了一倍多也不少),不過沒提到怎麼改善,只稍微帶過:

In addition the fork includes small improvements to Go's RSA implementation.

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 的 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 幫忙擋掉攻擊的部份...

Archives