Posted on
by

之前曾經介紹過波蘭的 Invisible Things Lab，她們在 2009 年初曾揭露過 Intel Trusted Execution Technology 的安全保護機制缺失。這個月，她們推出了一個新的試驗，Introducing Qubes OS。Qubes OS 是一個利用 Xen, X, Linux 所開發的作業系統。

基本的架構是將各種不同領域的軟體置入 Xen 虛擬機器中，所謂不同領域 (domain)，指的是使用情境 (context)。如你可能有一個工作專用、網路銀行專用、網路小遊戲專用等等不同的領域。在不同的領域中，各個軟體元件都可以被隔開在自己的環境沙箱 (sandbox) 中，包含檔案系統、網路等也是利用 Xen 進行隔離的。也就是 Security by Isolation 的概念，見論文中有詳盡介紹。

至於操作介面，則是利用 X Window System 的 client-server 架構，各個不同的領域的軟體 (X Client)，將圖形化介面投到共用的 X Server。寄說還做了 Secure copy-and-paste 的機制，進而保護了剪貼簿的內容。設計上，他們做了一個 GUId 來處理圖形化問題，且每個 Domain 都有其 X Server，因此也不用怕有人利用 XQueryKeymap 寫 keylogger 來錄密碼。

由於各個軟體都被鎖在獨立的檔案系統、網路中，只透過網路傳送圖形介面。因此你不用擔心因為在網路遊戲中查看一些網站而中毒，因而影響到你的作業系統穩定性或刪改到工作檔案。

這是一個很有趣的嘗試。

不過顯而易見，系統資源相對會使用更多，例如每個 domain (Xen VM)，都會固定佔掉 400M 記憶體 (?)，而每個 domain 中，都需要留置一份自己的相關 userland libraries, programs 等。雖然 Qubes 看起來是用 COW 技術，讓系統盡量共享 Domain-0 中的 userland program. 不過若要新增軟體大概還是會佔掉不少空間。

另外則是由於軟體被安裝到不同的 domain 中，自然 menu/launcher 得重新設計，否則無法找到不同 domain 中的軟體。操作性上可能會弱一點。

Posted on
by

偶爾你會需要刪除特定目錄下的空目錄，一個一個去找顯然不太聰明而且相當費時。

可以簡單的利用  find 來找，兩個參數可用，分別是 -depth 與 -empty。另外你可以加上 -type d 讓它只找目錄，不加的話，它會會連空檔案都找出來。

$ find /tmp -depth -empty -type d

配合 -exec 就可以將這些檔案全部刪掉啦。

$ find /tmp -depth -empty -type d -exec rmdir -v {} \;

這是一篇 Tips。

Posted on
by

緣由

從 2009 年底開始，中國互聯網絡信息中心 (文後簡稱 CNNIC) 為了推動其網址衛士服務，陸續將其根憑證申請納入眾多瀏覽器的 SSL 憑證。目前在 Firefox 3.6 (#476766) 與 Windows IE8 (Windows Root Certificate Program) 瀏覽器系統都已經成為預設憑證。

這件事情，很快的引起華人網路使用社群的騷動。主要原因是 CNNIC 過去的歷史，使其公眾觀感不佳，且 CA 根憑證對於網路安全影響事關重大。

一般網路銀行、網路商店等金流服務，多利用 SSL 來提供安全保護，一是對網路流動資訊加密，二是利用 CA 所發布的憑證來提供基本的網站驗證。而所謂根憑證，就是 CA 用以發放次級憑證給網站，可用來辨識特定網域是否為合法組織。但前提是 CA 維持善良管理人義務，嚴格管理所核發的憑證、簽章。

爭議

而 CNNIC 過去最大的爭議之一，是曾發布中文上網官方版軟體。這個軟體主要功能是網址查詢軟體，但核心卻用 rootkit 技術使人無法刪除，與木馬/病毒程式一般，可算是流氓軟體。在微軟網站上，有詳細的技術分析說明相關問題。

雖說這只是一項前科，不代表 CNNIC 也會濫用成CA 身份來作惡。但中國政府持續拿著民族主義、國家安全為藉口，於中國境內實施數種網路管制，甚至滲透國外企業、政府網路。而 CNNIC 背後支持的政府組織是中華人民共和國工業和信息化部、中國科學院等中國政府組織，很難說，哪一天 CNNIC 不會被控制作為攻擊工具之一。

從技術上的風險來看，若系統有此憑證，使用者將被剝奪警覺的能力。當攻擊事件發生時，唯一可以主動提示你的 SSL 機制也可能失效。在中國網路長城的「內部網路」，網址被攔截、更換是很平常的事件，即使你在網外，也可能在網站轉址攻擊事件或大規模網頁綁架轉址發生時，變成受害者。例如許多網頁常使用外掛的流量追蹤系統，若這些服務被中間人攻擊 (MITM) 所置換，使用者可能毫無警覺的被竊取資料。

除了 CNNIC 自行發布的 CA Cert Root 外，其實 CNNIC 也已經取得 Entrust.net 所發布的次級憑證。因此這個風險已經存在，無論你是否使用新版的瀏覽器。

考量潛在風險與中國政府的威脅，為了確保資料安全，建議所有台灣政府單位與企業，一律移除 CNNIC 相關憑證。

目前此事已經在 Mozilla Security Policy 論壇公開討論，如 AutoProxy 等網路自由倡議社群都提出 CNNIC CA：最最最嚴重安全警告！。若你覺得此事關係重大，可以投票方式附議 Bug 542689，提高該問題的被重視程度。

移除

要確認自己是否可能受害的驗證方法，是用瀏覽器開啟網址衛士 (使用 Entrust.net) 與 ENUM 試驗平台 (使用 CNNIC Root Cert)。若你的瀏覽器絲毫不予警告，你的系統即已安裝 CNNIC 憑證。

依照目前的討論 (#542689, #476766)，Mozilla 社群應採無罪推論原則。也就是說雖 CNNIC 風評不佳，但在它實際作惡前，我們理因相信它無罪。目前已技術上的提議，希望可以降低憑證管理的問題跟風險，但是這些功能恐怕需要點時間才會實踐。

華人開放原碼社群已經針對這個問題為 Firefox 開發了兩個小附加元件。目的都是為了保護或警示使用者。你若是台灣使用者，不使用中國的網路服務，如 163.com 等，可以選擇移除或停用。否則，你也可以安裝輔助軟體，在下載可能危害系統的加密內容時，提供警示。

警示 CNNIC 憑證：Cert Alert
停用 CNNIC 憑證：CA Untrustworthy

在香港開源社群 Benlau、小兔黑黑 的倡議與支持下，筆者與他們開發了 Cert Alert，這個元件的功能是「自動提醒」使用者，網頁中使用了特定 SSL Root CA 的內容。另外 CA Untrustworthy 則由 timdream 所開發，功用是每次開啟 Firefox 時，自動移除或關閉高風險憑證。

這兩套軟體都是開放原碼，原始碼都位於 Github。進一步詳情，請參考筆者 blog 網站。

Posted on
by

二月初發表了在 Linux 上移除 CNNIC 憑證一文後，受到相當多的文章引用與關注。

原文中，提到移除高風險憑證的作法，但其實我相信很多人弄不懂不同平台的作法，也不清楚所謂 NSS 的機制，沒有清除系統憑證，只是試圖移掉 Firefox 中的驗證。所以很多使用者不知道自己是否真的移除，或是以為移除，重新開啟 Firefox 後，因為 NSS 的設計，憑證又自動建入資料庫中。

依照目前的討論 (#542689, #476766)，Mozilla 應該採無罪推論原則。也就是說雖然 CNNIC 的風評不佳，但在它實際作惡前，我們理因相信它無罪。雖然有一些技術上的提議，希望可以降低憑證管理的問題跟風險，但是這些功能恐怕需要點時間才會實踐。

所以，短時間內，使用者還是得自己做一些設定來自保。但是前文步驟又十分繁雜，我們需要給使用者一個比較簡單的操作措施。

在香港朋友 Benlau、小兔黑黑 的倡議與支持下，我們寫了一個小 Firefox 附加元件，稱為 Cert Alert，這個元件的功能是「自動提醒」使用者，網頁中使用了特定 SSL Root CA 的內容。

這個附加元件採 MPL 1.1 授權釋出。你可以於 Firefox 附加元件網站下載安裝。開發者可於 Github 取得完整程式碼或提供建議。

另外一個值得推薦的是 timdream 所開發的 CA Untrustworthy。這個附加元件的功用是每次開啟 Firefox 時，自動移除或關閉高風險憑證。如此，若瀏覽使用高風險憑證網站時，Firefox 就會提醒你這是未受信任網站，你可以依照 Firefox 的憑證驗證機制來允許或關閉網頁。所以你就不用擔心，是否因為沒有完成移除系統憑證而造成安全問題啦。Tim 的 CA Untrustworthy 亦擺於 Github.

銘謝: Littlebtc 提醒 CertAlert 0.0.4 版前之 MITM 問題。
備註: 中國朋友亦開發一 NoCNNIC 工具，可移除 Windows 平台的 NSS database 中 CNNIC 憑證。惟只支持 Windows 平台，且必須手動執行才可移除。僅供參考。

2011-03-27 updated

已更新支援 Firefefox 4.0

Posted on
by

為了某些專案的進度追蹤，改成逐周方式確認。在溝通過程中，發現週數老是對不上，原來大家的週數計算方式都不太一樣。我的紙本行事曆跟電腦行事曆也不太一樣。

原來，計算一週之始有好幾種方法，例如

  • 1/1 日開始一定算第一周。
  • 不管 1/1，從一年的第一個星期天開始算第一周。
  • 不管 1/1，從一年的第一個星期一開始算第一周。

像是波斯灣阿拉伯國家是週六開始算第一周，巴基斯坦跟愛沙尼亞是把 1/7 當作一年開始來計算。即便是上述的幾種方式，在同一個國家內也有不同的偏好阿。像我的行事曆就是 1/1 開始當作第一周，而我的電腦則是把週日開始算為第一周。兩個相較起來就差了一週。

在 Linux 上，其實 en_US 跟 zh_TW 兩種不同的語系設定，開始週數是不同的。en_US 使用的是 1/1 開始那周算第一周，而 zh_TW 則是設定成第一個週一是第一周。用 ncal 看起來像是這樣

$ LC_TIME=en_US.UTF8 ncal -w  1 2009
    January 2009
Mo     5 12 19 26
Tu     6 13 20 27
We     7 14 21 28
Th  1  8 15 22 29
Fr  2  9 16 23 30
Sa  3 10 17 24 31
Su  4 11 18 25
    1  2  3  4  5
$ LC_TIME=zh_TW.UTF8 ncal -w  1 2009
    一月 2009
一     5 12 19 26
二     6 13 20 27
三     7 14 21 28
四  1  8 15 22 29
五  2  9 16 23 30
六  3 10 17 24 31
日  4 11 18 25
   52  1  2  3  4

上述的算法，時常造成同一周被定義兩次，他可能是去年的 53 周，又是今年的第 1 周。這樣很容易造成困擾。

為了避免這種糾紛產生，其實有一份 ISO 8601 定義了週數的算法。ISO 8601 除了制定時間字串的格式之外，也定義了週數的計算方式。規則稍微複雜一點，但是是為了避免一個周被計算兩次。

ISO 8601 的計算方式是

  • 包含第一個週四的算第一周。
  • 包含 1/4 的那一週。
  • 第一週超過四天以上。
  • 12/29 後的第一個週一。

詳細算法請見 ISO Week Date。你在 Linux 上，可以用 date 指令查到以下依照週一、週日、ISO 算法的週數

$ date +"Sunday %U Monday %W ISO %V" -d '2010-01-01'
Sunday 00 Monday 00 ISO 53
$ date +"Sunday %U Monday %W ISO %V" -d '2010-01-03'
Sunday 01 Monday 00 ISO 53
$ date +"Sunday %U Monday %W ISO %V" -d '2010-01-04'
Sunday 01 Monday 01 ISO 01

Posted on
by

很多時候，我們常常在 Google Groups、線上論壇或 Gmail 引用另外一封電子郵件的發言作 Cross-referencing，為了讓後來才參與討論的人快速的找到相關的背景資料。

但是很多時候，要求人家去爬文其實是很難實踐的，因為論壇流量極大，即便告知了標題、作者，很多時候可能還是要翻找很久。另外一個問題是，如果你想引用特定 E-Mail, 只能要別人回去翻閱你以前寄出的信件，這樣對方很難找到原始引據信件。即便你想讓人參閱，你也無法把特定的信變成 hyperlink，公開在網路上讓人點閱。

其實，根據 RFC2392 的定義，每一封電子郵件標頭裡，都藏有一個單一的 Message-ID。每一封信都有，而一些線上郵件軟體如 Gmail，支援搜尋 Message ID，你可以把 Message ID 輸入搜尋欄位，就可以快速找到原始的討論串。在應用上，你也可以代入搜尋網址，如 Gmail 則為

https://mail.google.com/mail/?shva=1#search/[MessageID]

只要給對方這樣的網址，他就可以找到原始的郵件。無論是藏在那一個目錄/標籤中。新式的電子郵件軟體，也可以讓你跨目錄的搜尋 Message Id，有了參照，要找到原始郵件應該比透過標題找來的快。

另外一個在網路上嘴砲溝通時常用的功能，是引用開放論壇的存檔。若你打開郵件翻閱 Header 的話，會看到一些隱藏的資訊。以 Google Groups 為例子，你會看到 X-Thread-Url, X-Message-Url 等。這兩個網址，就是線上網頁版本的存檔。你可利用這兩筆資訊提供給其他人作為引據連結。

其他的一些郵遞論壇工具，也有自己的 Archive URL，不妨開啟來翻閱。現雖有 RFC5064 之定義，但是大家似乎還是各作各的。:-/

Happy Flame War!

這是一篇 Tips.