二月初發表了在 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 平台，且必須手動執行才可移除。僅供參考。

一月底開始，一些朋友開始討論 Firefox 3.6 中，將置入 CNNIC 的 CA 憑證。這件事情是去年年底，CNNIC 對 Firefox 申報納入 CNNIC 的憑證 (#476766)，目前已於 3.6 版中內建 CNNIC 憑證。

目前此事已經在 Mozilla Security Policy mailing list 公開討論，在華人網路社群也引起一陣騷動。像是 AutoProxy 等社群都提出 CNNIC CA：最最最嚴重安全警告！。在原提案 #476766 中亦有人整理了一些客觀事實。

不過根據我主觀的看法，奉勸所有人盡快移除 CNNIC 相關的 CA 憑證！CNNIC 就是中國網際網路絡信息中心，是一個中國的非營利組織，提供中國網際網路的網域名稱、網段管理。

CA 憑證對於瀏覽器使用者而言，可以用來辨識特定網域是否為合法組織，部份瀏覽器功能甚至依據有否憑證，對網頁開啟進階存取權限。前提是 CA 維持善良管理人義務，嚴格管理所核發的憑證、簽章。

CNNIC 過去最大的爭議即是曾經發布過中文上網官方版軟體，名為提供中文網址導引服務，實質則包含流氓軟體的功能，主要功能是一般輔助上網軟體，但核心卻用 rootkit 技術讓你無法刪除，與木馬/病毒程式一般。雖說這只是一項前科，但是中國政府持續拿著民族主義、國家安全為藉口，實施數種網路管制，甚至滲透國外企業、政府網路，根本是合法的網路流氓。而 CNNIC 背後支持的政府組織是中華人民共和國工業和信息化部、中國科學院、中國科學院計算機網絡信息中心 等中國政府組織。很難說，哪一天 CNNIC 不會被控制作為攻擊工具之一。

除了 CNNIC 自行發布的 CA Cert Root 外，其實 CNNIC 也已經取得 Entrust.net 所發布的次級憑證。建議所有台灣政府單位，一律移除 CNNIC 相關憑證。

若你覺得此事關係重大，可以以投票方式附議 Bug 542689 – Please Remove “CNNIC ROOT” root certificate from NSS，提高該問題的被重視程度。

跳板風險

其實 Mozilla 先前也曾經遭遇過亂搞的安全憑證公司。原則上，任何人要申請特定網域的簽章，必須提供書面資料，證明你是該網域的擁有者。因為 SSL 憑證一個主要功能是防止釣魚網站欺騙一般消費者，若使用假冒的憑證，使用者很容易就發現網址異常。

若安全憑證公司絲毫不做基本的驗證，任何人都可以申請想仿冒的網域，然後以中間人攻擊 (MITM) 詐騙你交出個人資料。想像，你收到一封 PCHOME 的廣告，連到一個假的網站，這個網站提供了完美的 SSL 憑證，瀏覽器沒有提示你任何異常，除非你刻意去點選確認簽章，否則很自然就會上當。

Mozilla 的事件起因，是有人回報一安全憑證公司透過廣告郵件推銷新的服務。但這個憑證公司的服務卻允許你隨意購買任一網址的簽章，於是你可以購買並假冒任何網站。Eddy Nigg 寫了一份詳盡的說明，當時並做了一個驗證概念的 Mozilla.com 憑證。在事情曝光後，Mozilla 已撤除這組組憑證了。

移除 CA 憑證

驗證方法是開啟 CNNIC 的網址衛士 (使用 Entrust.net) 或 CNNIC 的 ENUM 試驗平台 (使用 CNNIC Root Cert)。若你的瀏覽器絲毫不給警告的就讓你存取，你的系統即已安裝 CNNIC 憑證。

2010-02-23 更新請使用  CertAlert 與 CA Untrustworthy 等工具來移除或警示可疑憑證。

在 GNU/Linux Debian, Ubuntu 上，系統保持一份共用的 CA 憑證，許多網頁工具如 Firefox, curl, wget, Chrome 均共用同一組設定。因此最簡便的方法便是關閉系統上有問題的憑證。

作法是以 root 在終端機內重新設定以下指令

# dpkg-reconfigure ca-certificates

找到 mozilla/Entrust.net_Secure_Server_CA.crt 一列，反選取之，選擇確認即可。或者直接編輯 /etc/ca-certificates.conf，一樣找到此行後，於該行開頭加入驚嘆號 (!)，然後重新以 root 執行一次 update-ca-certificates.

另外，你也得到瀏覽器手動刪除原已匯入之憑證。注意，若該筆憑證下方有多筆簽章，你必須刪除全部簽章。見圖

按下 Delete, 重新啟動 Firefox，如此即可移除相關的 CA 憑證，其他瀏覽器需比照辦理。你若使用其他作業系統，請參考 Felix Yan 所整理之 從「受信任的根證書」裡趕走CNNIC。

以下補充說明 (20100203):

許多網友認為，即使系統有此憑證，也不至於影響系統。

事實是，若有此憑證，你將被剝奪警覺的能力，像是痛得知覺消失一樣。當攻擊事件發生時，唯一可以主動提示你的 SSL 機制也可能失效。在中國網路長城的「內部網路」，網址被攔截、轉換是很平常的事件，即使你在網外，也可能在網站轉址攻擊事件或大規模網頁綁架轉址發生時，變成受害者。

除了網址之外，這份憑證也可用於不同的連線服務加密認證。我並不想因為系統上存有一份無須有的 SSL 憑證，造成我日常認為經加密而安全的 SMTP/IMAP/IM 「可能」偷偷地遭到攔截、擷取資料。而我卻一無所知。

更新 (2010-02-23)

請使用  CertAlert 與 CA Untrustworthy 等工具來移除或警示可疑憑證。

若 Firefox 開發延伸套件時，應該會知道 Firefox 對於外掛並沒有安全防護機制的，只要你能裝進系統，大約就可以使用所有的元件或存取系統資源。延伸套件被視為可信賴的軟體，開發者應負起各延伸套件的安全性。

對此，Firefox 在 Java Script 開發環境的安全設計主要分為賦權與未賦權的兩種安全模式。賦權的環境中，軟體可以存取所有的 XPCOM，沒有任何限制，於是它可以讀取或修改使用者的歷史紀錄、Cookie 等，甚至存取所有系統檔案。而 non-privileged 則僅提供限制嚴格的 HTML DOM API 權限，Script 的存取也依照其網址與網域名稱給予嚴格限制，避免 XSS 或本地檔案讀取等安全問題發生。

無論是外部的網頁，或者是 XUL 軟體，都是使用 XML/HTML/Java Script/CSS 來撰寫，因此概念上都是由 Window 載入 XML 文件，並透過 Java Script 來存取 DOM API。

開發延伸套件時，凡是在 XUL Overlays 或 XPCOM Components 中的程式碼，都是給予完全的存取權限。而從外部網頁載入的內容，應該給於其未賦權的權限。這種安全模式的設計，乃是防止網頁上的程式可以任意存取系統資源，是一道安全保護牆。

由於 Mozilla 社群並未對安全模式定義名詞，這裡暫區分稱呼如下兩種安全模式

• Web content document (non-privileged)

• Chrome document (privileged)

各個程式的安全模式可依照該載入網址作區別，例如 chrome:// 有完全權限、http://example.com 則可存取 example.com、file:/// 則可存取本地檔案。

你也可在利用 PrivilegeManager  詢問使用者後存取 XPCOM 或者讓 XMLHttpRequest 跨網域存取。除了預設依照網址判斷外，開發者可以設計不同的內容使用安全模式，開發者可以決定直接載入網路資料後在 Chrome Document 中執行，或者利用 type=”content” 之方式使其載為 web content document.

但是剪下貼上是一個開發者都會犯的錯誤，最常見的錯誤之一就是直接把外面抓回來的資料，用 innerHTML 直接塞進 chrome document 中。有時候資料中會含有一些 java script，雖然 <script /> 中的語法不會被執行，但是 <img onerror=”alert(‘xss’)”> 這種程式碼還是會被觸發，外部資料中夾帶程式碼的狀況還是相當多，因此凡是處理外部連結都要小心。

Security Assessment 的 Roberto Suggi Liverani 與 Nick Freeman 在上個月初於印度舉辦的 SecurityByte & OWASP AppSec Conference 中，與今年年中的 DefCon 17，發表了幾個 Mozilla 上的零時差漏洞。根據他們的文章與簡報，最常見的就是如 RSS Feeds 中的 <description> 的程式碼會被觸發執行、或者像是 FireFTP 1.1.4 以下的版本，會執行伺服器上的歡迎頁面。或者是熱門的 ScribeFire 3.4.3 以下版本，會以 chrome document 執行 <img onLoad=”alert(‘xss’)”>。

避免這些錯誤的方法之一是盡量使用 DOM manipulation methods 來塞入內容。在 Security best practices in extensions 一文中，講解了數個開發安全延伸套件的方法與注意事項，像是無論如何得執行他人的 Script，那就用 evalInSandbox 來執行。

另外你若得在兩種安全模式間互傳資料，正確的作法應該是盡量利用 DOM Event.

剛讀到這篇 Component Directory Lockdown 新聞時，乍看標題誤以為 Firefox 3.6 中所有的 XPCOM components 都將被閹掉、無法使用了。認真讀了火狐人肉盾牌 (Human Shield) Johnathan Nightingale 的公告、以及 Vladimir Vukićević 的詳盡說明，知道關掉的是官方自動載入 Firefox 安裝目錄下的 components 目錄。

其實是為了一些惡搞軟體所下的限制，特別是在 Windows 平台上。許多 Windows 使用者都會安裝一些防毒軟體、輔助工具等等，許多 Windows 上的工具軟體常便宜行事，會偷偷在 Firefox/components 目錄下塞入自己的 XPCOM 元件，藉此置入功能到 Firefox 中。在 Firefox 的設計中，這些 XPCOM 元件都會依照其宣告被自動載入、執行。

問題在於不少軟體的作法都是射後不理，軟體公司常常依照特定版本的 Firefox 開發其 XPCOM 元件，安裝時強制安裝該元件檔案到 Firefox 的 components 目錄，然後就不管了。隨著時間演進，使用者可能會升級 Firefox，結果這些非官方的 XPCOM 元件未被升級，造成相容性問題而使整個瀏覽器當掉。

XPCOM 是設計來接取一些基本的系統資源、或與其他函式庫介接，若是 API 版本不合，不小心會造成當機、安全漏洞或系統損毀。特別是 XPCOM 不同於 Extension，在瀏覽器一執行時就會載入，也不作版本驗證。對於使用者而言，也無法像擴充套件一樣，透過設定介面關掉或移除有問題的外掛。於是使用者很容易就怪罪這個瀏覽器不穩定。

於是，在 Firefox 3.6 中，將只載入寫在 components.list 的官方元件。一般開發者若想使用 XPCOM 元件，應該使用包裝成 extension 的形式，讓系統自動安裝，詳細的技術細節請參考 Mozilla 開發網站。

若想利用 HTML 5 開發一些多媒體程式的網站，你大概會需要一個本地檔案處理的 API 來儲存影片、圖檔等。同時你大概也會希望創作一種類似桌面系統的使用經驗，讓使用者可以直接從原生作業系統拖拉檔案到你的 Web Apps 中。而檔案塞進網頁程式後，又可以製作成縮圖，讓使用者透過網頁介面進行管理。

這些功能在 Google Gears 0.5.21.0 皆已經實做，包含了支援 Bolb, Blob Builder、Drag & Drop support 與 Image thumbnailing。

除了 Google Gears 的實做以外，其實從 Gecko 1.9.2 後在 Firefox 3.6 與 Fennec 1.0 也支援了這些直接利用 Java Script 進行檔案處理的功能。於是你可以利用 Java Script 刻一個的檔案瀏覽器工具，拿 FileList 來接受使用者拖拉進瀏覽器或自選的檔案列表，用 FileReader 作一些簡單的處理，像是把圖片丟進 Canvas 讓使用者改一改後，再傳到網路上伺服器存放等。依據安全性考量，你自然不能直接拿 File Reader 來讀系統檔案，File Reader 的參數都必須是使用者自行選擇帶入的 File 型別才可以。如此便可避免拿 Java Script 作壞事的機會。

Mozilla 的 Arun Ranganathan 已提交 File API 一案至 W3C 供獨立審核。其他關於 HTML5 的 API 請見我的 blog，或參考 Mozilla 的 HTML5 support in Mozilla。

關於 Web Typography。過去，你若想讓網頁上出現多樣性的字型與排版，往往得將文字作成圖片或 Flash 來顯示。如此一來常常使網頁失去文字複製、搜尋引擎最佳化 (SEO) 的功能，一個網頁製作再精美，但卻沒有人可找來閱讀的話，也是徒勞無用的。

於是你想使用瀏覽器預設的功能，但又不想屈就於有限的作業系統內建字型，這該怎麼辦？你或許會利用像是 sIFR, FLIR, Typeface.js 或 Cufón 等替代方案。

以 sIFR (Scalable Inman Flash Replacement) 來講，sIFR 是利用 Java Script 與 Flash 動態的替換瀏覽器上的文字，字型則來自網頁設計者預先從系統中設定欲使用的字型於 Flash 中。

而 Cufón 概念亦差不多，不過作法是先將字型外型轉成 Java Script/JSON 格式，實際使用時再利用 HTML5 Canvas 繪出字型。Cufón 的作法所生成的 Java Script 雖比所用的 Truetype 字型小，但其實檔案大小也頗大，BCSEEATI 試驗了一分割字型方式，可有效降低傳輸量，但需把字型計算工作轉移到伺服器端。

Cufón 的一項缺點是，用了 Canvas 來繪圖，結果造成使用者無法點選文字。關於這個問題，TypeSelect 與 Typeface.js 用 span tag 解決的選字的問題。這些作法都頗討厭，因為你要求瀏覽器為了美觀顯示，多做了圖形運算或重複塞了一圖一字就為了美觀跟可選字。

若是可以讓瀏覽器直接依字型繪字不是很好嗎？在 Firefox 3.5 (Gecko 1.9.1) 後，Firefox 開始支援了 CSS 的@font-face 語法。於是，你有機會可以用 font-family 來指定一些擺在網路上 TrueType 或 OpenType 字型，直接讓流覽器繪出美麗的文字 (中文版: 顛覆網路 35 天 (4b): 以 @font-face 使用你喜歡的字體 by BobChao)。 文泉驛的雲字體計劃便是應用 CSS 更換字型的例子之一。

但是對於字型廠商來說，並不樂見讓你隨意在網路上使用 TrueType 或 OpenType 字型。主要的原因就是版權濫用，同樣的一套字型很可能會被大量複製。另外，對於瀏覽器開發者而言，納入 DRM 控制網頁用字型顯然是與網路傳統背道而馳。對使用者而言，這兩種格式都太大，會浪費相當頻寬下載所需字型。

就頻寬的問題而言，其中一種解決方式如 Microsoft 所倡議的 Embedded OpenType (EOT)，解決方案是以工具掃瞄網頁，並從字型檔中抽出網頁所需的字型。這樣的確可以降低頻寬使用，但是總覺的每次都要產生特定的字型檔實在有點太麻煩。

比較好的作法或許使利用壓縮的機制來降低傳輸量。Mozilla 的 Jonathan Kew 於是提議了一種新的規格 ZOT，基本上就是 OpenType 的壓縮，但壓縮的是 SFNT 字型檔中的獨立表格。這種格式的好處是有效壓縮字型檔大小，在 Web Open Font Format for Firefox 3.6 一文中提到，此格式可將 3.1MB 的 TTF 字型檔壓縮成 1MB 左右。另外一個好處是由於 table 獨立壓縮，因此像是記憶體容量較小的行動裝置，可以下載字型後依照 cmap 表格找到相對應的字型，依照需求再逐一解縮壓，可解省些系統支援。

另外一個需求會是版權的問題，Jonathan Kew 倡議 ZOT 時，同時有人為了字型供應商的需求做了 .webfont 格式。基本上的用意是希望能夠在字型中夾帶一些 metadata，使供應商可以追蹤網站所使用字型是否符合版權，但是不加以 DRM 保護。這個提議已經得到一些字型供應商的支持。

這些規格加起來就是 WOFF File Format 在新釋出的 Firefox 3.6 中，預定支援 Web Open Font Format (WOFF) 之格式。ars technica 有一篇詳盡的報導 Web Open Font Format backed by Mozilla, type foundries，介紹了 WOFF 中的一些規格演繹與技術說明。在 after Firefox 3.6 – new font control features for designers 一文中有相當精彩的字型應用展示，如利用網頁字型重現傳統印刷字等。

目前此規格已經在 W3 的 Web Fonts Working Group Charter 中，目前只有 Firefox 支援 WOFF，接下來要便看其他的瀏覽器是否願意支持此規格了。可於 www-font 郵遞論壇追蹤最新的進展。

2009-12-02 後記: John Boardley 的 Web fonts. Where are we? 亦相當有參考價值。簡體中文翻譯請見關於 Web 字體：現狀與未來。