Home » 2015 » January

Mozilla 加入 Tor Relay 的行列

Mozilla 宣佈了他們提供硬體與網路,提昇 Tor 的隱私性:「Deploying tor relays」。可以在「Results for mozilla」這邊看到這一波有十二台上線了。

架構上完全獨立於目前的 production 環境 (所有的硬體與網路設備),這是 Mozilla 提供的網路架構說明:

另外關於安全以及隱私性的部份,他們也提供了不少意見與說明。

像是單一組織不應該提供太多 bandwidth,這可以當做是避嫌:

A single organization shouldn’t be running more than 10Gbps of traffic for a middle relay (and 5Gbps for an exit node).

一個 Tor 節點需要兩個月的時候逐漸讓整個網路使用:

A new Tor instance (identified by its private/public key pair) will take time (up to 2 months) to use all its available bandwidth.

目前 Tor 的程式效能限制:

A Tor process (instance) can only push about 400Mbps.

這是 Tor 的安全限制:

A single public IP can only be shared by 2 Tor instances

這是避開防火牆的限制:

Listen on well known ports like 80 or 443

Slack 與 Screenhero

看到 ScreenheroSlack 買下來的消息:「Screenhero joins Slack!」。目前只支援付費方案,不過在公司有在推動並且購買付費版 (Standard),而且使用人數還算多,所以可以拿出來用。

整合是在新聞稿丟出來之前就做完了,單鍵就可以同步帳號。

Ubuntu 桌機上的 Windows XP (在 VirtualBox 裡) 上想裝起來測試發現:

看起來得把 Mac 開起來弄一弄。

不過就同事丟出來的分享心得,看起來解決了之前有些同事反應的問題:

螢幕分享還可以遠端操控
teamviewer可以丟了

不過 TeamViewer 一般還是用在跟外部廠商客戶端的測試吧?倒是可以測試看看 Guest account 可不可以參與 Screenhero,如果可以的話也是不錯的選擇...

Amazon 跨足 Email 市場

大清早就看到「Amazon WorkMail – Managed Email and Calendaring in the AWS Cloud」這個消息。

Amazon WorkMail 的價位是 USD$4/user (50GB 空間),包括了 mail 與 calendar 的功能:

或是加上 Amazon WorkDocs,需要 USD$6/user。

翻了一下 Google Apps for Work,是 USD$6/user (30GB 空間) 以及 USD$10/user (進階功能,加上無限空間)。

不過目前只支援 us-east-1 與 eu-west-1 兩個區域,而且是 Preview 狀態 (表示需要填單申請)。也許先測看看,好用的話就來等 ap-northeast-1?

CVE-2015-0235:讓人爆炸的「glibc gethostbyname buffer overflow」

CVE-2015-0235:glibc gethostbyname buffer overflow 的問題是:

Heap-based buffer overflow in the __nss_hostname_digits_dots function in glibc 2.2, and other 2.x versions before 2.18, allows context-dependent attackers to execute arbitrary code via vectors related to the (1) gethostbyname or (2) gethostbyname2 function, aka "GHOST."

這個洞讓只要有接受外部 hostname 查詢的部份就會中獎 (因為所有程式語言大概都是用這組 function 查詢,除了少部份是使用 DNS 查),再加上幾乎每支程式都會用到 glibc,在更新完後得重開機,於是有一堆機器得重開機更新了...

Ubuntu 12.04 中獎,不過 14.04 混過去了...

OpenSSL 的 ECDH 中,224 bits 速度比 160/192 bits 快的原因

openssl speed ecdh 的時候發現很特別的現象:

Doing 160 bit  ecdh's for 10s: 40865 160-bit ECDH ops in 9.99s
Doing 192 bit  ecdh's for 10s: 34169 192-bit ECDH ops in 9.99s
Doing 224 bit  ecdh's for 10s: 60980 224-bit ECDH ops in 9.99s
Doing 256 bit  ecdh's for 10s: 34298 256-bit ECDH ops in 10.00s
Doing 384 bit  ecdh's for 10s: 9602 384-bit ECDH ops in 10.00s
Doing 521 bit  ecdh's for 10s: 9127 521-bit ECDH ops in 9.99s

原因是 Google 這篇論文的貢獻:「Fast Elliptic Curve Cryptography in OpenSSL」,開頭就提到:

We present a 64-bit optimized implementation of the NIST and SECG-standardized elliptic curve P-224.

而實際成果:

full TLS handshakes using a 1024-bit RSA certificate and ephemeral Elliptic Curve Diffie-Hellman key exchange over P-224 now run at twice the speed of standard OpenSSL, while atomic elliptic curve operations are up to 4 times faster.

OpenSSLCHANGES 也可以看到對應的修改,不只是 NIST-P224 有被改善,其他的 NIST-P256 與 NIST-P521 也都有被改善:

Add optional 64-bit optimized implementations of elliptic curves NIST-P224, NIST-P256, NIST-P521, with constant-time single point multiplication on typical inputs.

頗特別的...

TLS 的效能分析

看到「Is TLS Fast Yet?」這個站台,開宗明義就講了,這不是問題:

TLS has exactly one performance problem: it is not used widely enough.

Everything else can be optimized.

下面的表格分析把對於效能影響的分析寫得很清楚,除了軟體外,還包括了各家 CDN 支援的分析,可以參考一下這邊的分析。

昨天 (2015/01/27) 在高雄 K Square 的投影片

主題「KKBOX Innovation Chat #5 - 利用AWS開發及實作新創公司的基礎資訊建設」的投影片:(Startup IT infrastructure: Developing and Working with AWS)

在準備之前有問了 ericpi (主辦),主要是以 engineer 為主,然後次多的是學生。所以主題上偏技術一點。

而因為主題是 for startup,所以注重的方向與一般公司不太一樣。在舉例上面,主要是以 KKTIX 以及猜猜巧克力為主,對於 KKBOX 的著墨比較少。

現場 Q&A 很踴躍,用了不少時間在 Q&A 上,結果講完跟 ericpi 去吃飯時差點睡在餐桌上,回到家確認沒有緊急的事情就倒下去睡死了。

另外對不起現場聽眾的... 記得講到後面有點累,會發現講到一半「咦,這句中文怪怪的」,就重新再說一次,但好像還是怪怪的... (這代表應該有漏掉沒發現的部份)

Archives