找 Google Reader 替代品...

Google Reader 剩下最後兩天,還是要面對現實...

看了一下 Google Reader,裡面有 1100 個 item,剛好趁著這次 shutdown,又到了該砍掉重練的階段了...

免費的服務中,Feedly 會把非 focus 的文章縮起來,而 Digg Reader 找不到 Unread 的地方。go read 找不到地方下 Tag 分類,而 AOL Reader 則是登不進去。

付費的服務中,Feedbin (USD$2/month 或 USD$20/year) 的 preload 做的不好,所以人讀文章的速度沒有 Google Reader 快,NewsBlur (USD$24/year) 則是把功能做的極為花俏,第一眼看下去還不知道要怎麼加 feed...

反正這陣子就四處逃竄吧... 這陣子應該會有很多新的服務跑出來 :o

SSL/TLS 的 Perfect Forward Secrecy...


寫這篇順便測試 MathJax 的效果...

因為 NSA 的惡搞,這陣子 PFS (Perfect Forward Secrecy) 突然被拿出來討論:

在講 PFS 前,得先講 Diffie-Hellman key exchange (D-H)。

D-H 是利用這個等式:

$$(g^a)^b \equiv (g^b)^a \mod p$$

其中 \(p\) 是大質數,而 \(g\) 是 \(p\) 的 primitive root (即不存在任何 \(n < p\) 可以使得 \(g^n \equiv 1 \mod p\))。 而因為當 \(p\) 夠大時,要從 \(g^a \mod p\) 計算 \(a\) 就是離散對數問題,而離散對數問題是已知沒有有效率計算的問題,所以我們會假定當 \(p\) 夠大時,傳輸 \(g^a \mod p\) 是無法用合理資源計算得知 \(a\)。

因此,Alice 與 Bob 就可以產生自己的 private secret \(a\) (Alice) 與 \(b\) (Bob),計算出 \(g^a\) 與 \(g^b\) 後公開傳輸給對方,當 Bob 收到 Alice 提供的 \(g^a\) 時就計算 \((g^a)^b \equiv g^{ab} \mod n\),而 Alice 收到 Bob 提供的 \(g^b\) 後可以計算 \((g^b)^a \equiv g^{ba} \equiv g^{ab} \mod n\)。

而攻擊者只拿到公開的 \(g^a\) 與 \(g^b\) 以及 \(g\),無法計算出 \(g^{ab}\),於是就雙方就建立一組 shared secret 了。

回到 SSL/TLS 的問題上,由於 RSA 加解密的速度並不快,所以 SSL/TLS 是在 RSA 的保護下交換 RC4 或是 AES 所需要的金鑰 (key)。

交換 key 這件事情除了可以直接交換以外,還可以利用 D-H 交換。

D-H 交換可以確保當 RSA key 被破解時還要再破每個 session 的 D-H 所產生出來的 key,而直接交換的話,只要破一把 RSA key 就可以解出所有 traffic 了。

而 PFS 會被提出來,是因為目前消息指出 NSA 其實有在錄下 SSL/TLS 流量,等哪天有機會取得 RSA key 的時候 (無論是硬解,或是其他方式),就有機會能夠一次破一卡車資料... (因為目前大部分的 SSL/TLS 流量都沒有上 PFS)

雖然 PFS 會慢一些,不過已經確認 NSA 打算來搞了,所以還是乖乖加上去吧... @_@

配合 Percona Xtrabackup 的新功能以及對 Percona XtraDB Cluster 初始化的速度...

在「2 new features added to Percona XtraDB Cluster (PXC) since 5.5.31」看到 Percona Xtrabackup 引入新功能後,在 Percona XtraDB Cluster 就能使用這些新功能加快初始化的速度。

首先是 bootstrap-pxc 這個參數:

# use this...
/etc/init.d/mysql bootstrap-pxc
# or...
service mysql bootstrap-pxc

當第一次啟動時需要對 my.cnf 的 hack (啟動完成後就可以改回來) 現在可以在參數直接處理。

另外是對 xbstream 的支援,這聽一陣子了,這邊就不講怎麼用了,原文講得很清楚。不過目前測出來的效果不怎樣啊:

文章作者是說對於小資料沒差,晚點再來看看有沒有對大資料的 benchmark...

在 Percona XtraDB Cluster 裡使用 async replication 時人工 failover 的方式...

在使用 Galera Cluster 時還是可以架設一般的 slave server (Percona XtraDB Cluster 則是 Percona 對 Galera Cluster 的封裝),像是這樣的架構:

其中 node{1,2} 為 cluster,node3 則是傳統的 async replication,來源的 master 為 node1。

當 node1 掛掉時,我們沒辦法自動將 node3 的 master 從 node1 改指到 node2,因為 binlog 的位置不一定正確。

在「Changing an async slave of a PXC cluster to a new Master」則是提供如何人工用最簡單的方式介入。

主要是靠 Galera Cluster 會在 binlog 內寫入 Xid 這個值,這個值可以在 global status 內的 wsrep_last_committed 看到。因為這個值在全 cluster 都是同步的,就可以拿來人工尋找 binlog 位置後手動下 CHANGE MASTER TO,而不用 pt-table-sync 同步修老半天...

而且邏輯被整理出來以後,就有機會寫成程式自動化... 這算是一個不錯的開頭 :p

OWASP's Top 10,2013 版

Slashdot 上看到 OWASP 給出 2013 年的網站安全威脅 Top 10 名單:「OWASP Top 10 2013 Released」。

一如往常,Slashdot 的第一個 comment 還是很經典 XDDD

The offered list of vulnerabilities is in a pdf.

這... XD

在 Wiki 上有一份非 PDF 的版本可以看:「Category:OWASP Top Ten Project」,可以跟「Rails' Insecure Defaults」(副標題「13 Security Gotchas You Should Know About」) 一起看 (不是看 Rails 的問題,是看有哪些攻擊技巧)。

AWS CloudFront 可以用自己的 SSL Certificate 了...

以往 CloudFront 只能用 *.cloudfront.net 當作 SSL domain,但在今天公告的「Custom SSL Domain Names and Root Domain Hosting for Amazon CloudFront」這篇說明內,宣佈可以上傳自己的 SSL certificate 使用了。

目前的價錢是 USD$600/month,不過是以小時計算。即使拋開錢的問題,在 CloudFront 已經支援 SSL 的前提下 (而且因為是 *.cloudfront.net,理論上是 cookie-free domain),技術面上暫時想不到什麼好處... 在 DNS 端自己混合多家 CDN 是個可能的方向?

在 InnoDB 下的 COUNT(*)...

MyISAM 在讀取時不會有其他人可以寫入,所以 COUNT(*) 很容易被處理。而 InnoDB 的 COUNT(*) 在不同的 transaction 裡可能會不一樣,如果硬要處理的話會變得複雜,所以目前 InnoDB 的作法是 scan 一次 (出自「Limits on InnoDB Tables」):

InnoDB does not keep an internal count of rows in a table because concurrent transactions might "see" different numbers of rows at the same time. To process a SELECT COUNT(*) FROM t statement, InnoDB scans an index of the table, which takes some time if the index is not entirely in the buffer pool. If your table does not change often, using the MySQL query cache is a good solution. To get a fast count, you have to use a counter table you create yourself and let your application update it according to the inserts and deletes it does. If an approximate row count is sufficient, SHOW TABLE STATUS can be used. See Section 14.3.14.1, "InnoDB Performance Tuning Tips".

在「Easy SELECT COUNT(*) with split()」這篇提到 InnoDB 下 COUNT(*) 這件事情,當你不需要絕對精確的值時,可以利用 INFORMATION_SCHEMA.TABLES 或是 SHOW TABLE STATUS 的資訊來判斷。