Home » Posts tagged "time" (Page 3)

Google 的 time.google.com

看到這張圖在講不同 server (service) 如何處理今年的 leap second (UTC 的跨年,台灣時間早上八點),出自 leap smear 這邊:

在很早前就有 time.google.com 這個 domain,但是當時 Google 的人有跳出來說明這個服務不是公開服務 (當時),不保證這個服務的正確性與穩定性:「timeX.google.com provide non standard time」。

不過一個月前公佈出來的 Google Public NTP 服務算是把整個系統搞定了。

其中在 Configuring Clients 這邊直接推薦用 iburst 參數,不愧是家大業大的 Google XDDD:

When the server is unreachable and at each poll interval, send a burst of eight packets instead of the usual one. As long as the server is unreachable, the spacing between packets is about 16s to allow a modem call to complete. Once the server is reachable, the spacing between packets is about 2s. This is designed to speed the initial synchronization acquisition with the server command and s addresses and when ntpd is started with the -q option.

回到原來的 leap smear 的比較圖,可以看出 Google 對 leap second 的解法是往前十二小時與往後十二小時各拉緩衝時間來避開,有些是沒在管,另外有些有種來亂的感覺 XDDD

把 CSC (卡片背面的三碼) 變成 OTP (動態密碼)

把信用卡背面的後三碼 (Card security code) 變成動態密碼,雖然一般只會有三碼,但對於網路消費應該會有不少幫助,不過這樣就不能完全不拿出卡片了...:「This high-tech card is being rolled out by French banks to eliminate fraud」。

產品叫做 MotionCode,會先從法國開始:

Today both Société Générale and Groupe BPCE, two of France’s largest banking groups, are preparing to roll out these cards across all their customers after completing a pilot scheme last year.

然後是波蘭、墨西哥以及英國在規劃:

There are other pilots underway in Poland and Mexico, and Davis is running Oberthur’s UK operation with the hope of getting a pilot or trial started with a UK bank soon.

密碼系統的 Monoculture

這篇文章講到最近密碼系統的現象:「On the Impending Crypto Monoculture」。

目前常在用的密碼系統包括了 RSA、DH、ECDH、ECDSA、SHA-2、AES 這些演算法,而最近這幾年大家在推廣使用的演算法都出自於同一個人手裡,Dan Bernstein,也就是 djb:

A major feature of these changes includes the dropping of traditional encryption algorithms and mechanisms like RSA, DH, ECDH/ECDSA, SHA-2, and AES, for a completely different set of mechanisms, including Curve25519 (designed by Dan Bernstein et al), EdDSA (Bernstein and colleagues), Poly1305 (Bernstein again) and ChaCha20 (by, you guessed it, Bernstein).

這些演算法或是定義,包括了 Curve25519、EdDSA、Poly1305、ChaCha20。而這篇文章試著說明造成這樣情況的背景以及原因,以及這樣會導致什麼問題。

當實際分析時會發現,檯面上沒幾個能用的演算法,而看起來能用的那幾個又有專利 (像是 OCB),不然就是看起來被 NSA 放了一些說明不了的參數 (像是 P-256 Curve)。

然後 djb 弄出來的演算法不只看起來乾淨許多,也直接用數學模型證明安全性。而且他的實作也很理論派,像是還蠻堅持要做到 constant time implementation 以避開各種 side channel attack。

就... 理論很強,又很實戰派的一個人啊,檯面上真的沒幾隻可以打的贏啊 XD

加州在規劃廢除日光節約時間

加州在規劃廢除日光節約時間:「California could drop Daylight Saving Time」。

A California lawmaker has introduced a bill to unshackle the Golden State from the horological chains of Daylight Saving Time.

主要是沒有實質效益,甚至是與當初預期的反效果:

Daylight saving time is observed in about 70 countries worldwide, but its benefits are the subject of much debate. While studies in the 1970s argued that it reduced energy usage, it’s no longer clear that’s the case. A 2011 study in Indiana found that electricity use rose in the state as a result of daylight saving.

Adobe Typekit 對 PageSpeed 的妥協

Adobe Typekit 是個收費的網頁字型服務,為了讓變更可以儘快生效,用了比較短的 cache time:

We use a short cache time for the kit JavaScript so that you can update your kit (for example, adding fonts, or changing the list of allowed domains) and have your changes live in a reasonable amount of time.

但這也造成了不少人抱怨 Google PageSpeed Tools 會扣分,而實際上也的確降低效率 (因為你不需要天天改設定):

Adobe 給了妥協的方案,你可以選擇使用更長的 cache time,從本來的 10 mins 變成 1 week:「Improved caching for kits: Opt for longer cache timeout」。

這個選項使得 Google PageSpeed Tools 不會扣分,也讓效能再更好一些。

AWS 上 MySQL + MHA、Galera Cluster、Amazon RDS for Aurora 的比較

Twitter 上看到的文章,對三套有 High Avaiilability 能力的 MySQL 系統比較:「AWS Aurora Benchmarking - Blast or Splash?」。

測試的項目包括了 MySQL + MHAGalera Cluster 以及 Amazon RDS for Aurora 三種,包括了 failover 的各種速度以及資料庫效能的比較。

測試的結果可以看到 Galera Cluster 有不少優勢,不過我必須說 Galera Cluster 並不好搞,初期要使用的話乾脆用 Aurora 就好,failover 的確是比較慢,而且效能也沒有 Galera Cluster 好,但管理上輕鬆很多啊...

AWS 處理這次的 Leap Second...

2015/06/30 到 2015/07/01 會有 Leap Second (閏秒),而這次 AWS 處理的方法也公告出來了:「Look Before You Leap – The Coming Leap Second and AWS」。

EC2 由於每個 instance 有自己的 clock,所以需要自己實作:如果對閏秒不會有問題的系統就放著,而對閏秒敏感的系統可以自己跑 ntpd 之類的程式校正。

而其他 AWS 的系統會用 24 個小時攤平多出來的閏秒,從 2015/06/30 的中午 12:00:00 開始,到 2015/07/01 的中午 12:00:00 結束 (都是 UTC):

也就是說不會出現 23:59:60 這種時間,而在這 24 小時調整區間內的誤差最多 0.5 秒。

在瀏覽器上面用 JavaScript 進行 Side-channel attack

用 JavaScript 就可以攻擊 L3 cache,進而取得資料:「JavaScript CPU cache snooper tells crooks EVERYTHING you do online」。

論文出自「The Spy in the Sandbox – Practical Cache Attacks in Javascript」(PDF) 這篇。

不需要任何外掛或 exploit,就純粹是利用 cache 反應時間的 side-channel attack。另外由於 AMD 的 cache 架構不同,這次的攻擊實作僅對 Intel 有效:

The Intel cache micro-architecture isinclusive– all elements in the L1 cache must also exist in the L2 and L3 caches. Conversely, if a memory element is evicted fromthe L3 cache, it is also immediately evicted from the L2 and L1 cache. It should be noted that the AMD cachemicro-architecture is exclusive, and thus the attacks described in this report are not immediately applicable tothat platform.

這次的攻擊方法真變態...

最佳化 nginx 的 TLS Time to First Byte (TTTFB)

在「Optimizing NGINX TLS Time To First Byte (TTTFB)」這篇文章裡在討論要如何讓 nginx 的 TLS Time to First Byte (TTTFB) 盡可能短。

可以看到文章裡面用到兩個方法,一個是修改 nginx 的程式碼縮小 TLS record size。我對是覺得頗危險,尤其是作者的改法不知道有什麼 side-effect... (要注意 nginx 裡面直接拿 NGX_SSL_BUFSIZEBIO_set_write_buffer_size 使用,這代表有可能還有其他的地方也是這樣搞?)

第二個方法是開啟 TLS False Start,目前主流的瀏覽器都陸陸續續支援了。

這是文章作者的測試:

可以看到時間減少的相當多。

現在是期望作者這篇文章的測試可以讓 patch 合併回 mainstream 後再用,這樣有比較多人 audit...

Archives