翻牆軟體 GoAgent 的安全風險

GoAgent 導入公開私鑰根證書的問題

GoAgent 在啟動時會嘗試在系統中導入一個根證書來避免訪問 HTTPS 網站時的證書報警，但在默認情況下所導入證書的私鑰是公開的。因為私鑰公開，任何人可以作為 ｢GoAgent CA｣ 來簽發任何網站的證書。即使在 GoAgent 沒有啟動甚至卸載的情況下，這個公鑰仍會遺留在系統中。在有些系統中，GoAgent 所導入的根證書不僅被 GoAgent 默認使用的瀏覽器信任，其他的瀏覽器也可能會信任這一根證書，從而受到這一問題的影響。

GoAgent 所導入的這一公開私鑰根證書的指紋是：

SHA1 Fingerprint=AB:70:2C:DF:18:EB:E8:B4:38:C5:28:69:CD:4A:5D:EF:48:B4:0E:33
MD5 Fingerprint=56:B1:20:86:1B:0A:B0:61:38:00:1B:C3:67:CF:0C:CC

包含這一 ｢GoAgent CA｣ 證書以其私鑰（文件中 -----BEGIN RSA PRIVATE KEY----- 位置）的文件 URL 為：

https://github.com/goagent/goagent/blob/c4386808ea943e2ebed25f1e5264943354e3f9cb/local/CA.crt

根據版本信息，這一證書和私鑰從 2011 年 6 月甚至更早的時間以來一直保持不變。

https://github.com/goagent/goagent/blob/fa9959e577395e48a477fd5495afbc2363a51baa/local/CA.key

GoAgent 主要包含兩個部分：一個在用戶計算機上運行的本地代理程序 proxy.py，以及一個在 GAE 上運行的遠程代理程序 gae.py。

https://github.com/goagent/goagent/blob/c4386808ea943e2ebed25f1e5264943354e3f9cb/local/proxy.py
https://github.com/goagent/goagent/blob/c4386808ea943e2ebed25f1e5264943354e3f9cb/server/gae/gae.py

安裝時，用戶需要上傳 gae.py 到 GAE。用戶瀏覽器通過設置一個本地代理將 HTTP/HTTPS 請求轉發到 proxy.py，再由 proxy.py 和 gae.py 進行通信。

默認情況下，GoAgent 在啟動時試圖導入上述 GoAgent CA 證書。具體的代碼為 proxy.py 中的 CertUtil.import_ca：

https://github.com/goagent/goagent/blob/c4386808ea943e2ebed25f1e5264943354e3f9cb/local/proxy.py#L337

這個函數會根據用戶作業系統通過不同的方式嘗試導入證書，在某些情況下會需要管理員 （root/administrator）許可權。在 Windows 下，這個函數會調用 CertAddEncodedCertificateToStore 這一 API。在 OS X 下，會嘗試執行系統命令

security find-certificate -a -c "GoAgent" | grep "GoAgent" >/dev/null || security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" "pwd/CA.crt"

在 Ubuntu 下，會拷貝證書文件到 /usr/local/share/ca-certificates 然後執行 update-ca-certificates。在其他 GNU/Linux 發行版中，會嘗試執行以下命令更改 NSS 資料庫：

certutil -L -d sql:$HOME/.pki/nssdb | grep "GoAgent" || certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "GoAgent" -i "pwd/CA.crt"

由於 Firefox 採用了不同的方式存儲證書，這一自動安裝過程不會導入 GoAgent CA 證書到 Firefox 中。但是 GoAgent 的安裝指南和 FAQ 中說明了如何手動導入這一證書：

https://code.google.com/p/goagent/wiki/InstallGuide
https://code.google.com/p/goagent/wiki/FAQ

這一證書隨後被 proxy.py 用來作為 HTTPS 中間人來避免瀏覽器在訪問 HTTPS 網站時出現報警。GoAgent 的工作原理如下：首先 proxy.py 將瀏覽器的 HTTP 請求進行編碼並轉發給 gae.py，gae.py 完成收到的請求然後將結果進行編碼後返回給 proxy.py，最後 proxy.py 將結果轉發給瀏覽器來完成 ｢翻牆｣ 過程。由於 GAE 的限制 （免費 app 無法使用 socket 介面），對於 HTTPS 請求，proxy.py 無法進行透明轉發，只能作為中間人先和瀏覽器完成連接，然後獲得其中的明文請求以後在轉發給 gae.py。當收到 CONNECT 請求（這意味著瀏覽器正在瀏覽一個 HTTPS 網站）， proxy.py 首先利用 GoAgent CA 簽發一個假的證書來和瀏覽器完成握手，從用戶的角度，所有的 HTTPS 網站的證書都是由事先導入的 ｢GoAgent CA｣ 認證的，所以不會報警。有些瀏覽器會對少數網站的證書進行特別的檢查（Certificate Pinning），這種情況下 "GoAgent CA｣ 所簽發的證書可能會觸發證書不安全的報警。GoAgent 的這種工作方式導致 HTTPS 不再是瀏覽器到網站的端到端安全通信，而變成了 proxy.py 到 GAE，以及 GAE 到網站兩段獨立的 HTTPS 連接，GAE 能夠看到請求和應答的明文。

GoAgent 沒有進行正確的 TLS 驗証，存在中間人攻擊的風險

默認情況下，GoAgent 會通過 HTTPS 來保護本地 proxy.py 和 GAE 伺服器上 的 gae.py 之間的通信 （在配置文件 proxy.ini 中相關的設置默認為 gae.mode=https）。但是同樣在默認情況下，GoAgent 不會要求對 GAE 伺服器的證書進行驗証（gae.validate=0），這導致本地 proxy.py 和 App Engine 伺服器之間的通信存在 HTTPS 中間人攻擊的風險。此外， gae.validate 配置項同樣控制 App Engine 上的 gae.py 是否對網站伺服器的證書進行驗証，默認配置下這一配置為 0 導致 gae.py 也不會對網站證書進行驗証，使得 gae.py 和網站之間的通信同樣存在 HTTPS 中間人攻擊的風險

即使修改配置啟用證書驗証（gae.validate=1），GoAgent 對 App Engine 伺服器證書的驗証也並不嚴格：在 proxy.py 中只是對證書的 organizationName 進行了粗略的檢查（是否為 ｢Google ｣ 開頭），而沒有對主機名（hostname）進行匹配。

https://github.com/goagent/goagent/blob/c4386808ea943e2ebed25f1e5264943354e3f9cb/local/proxy.py#L1623

將配置改為 gae.validate=1 同時會啟用 gae.py 段對網站伺服器證書的驗証，這部分的事先沒有明顯的問題。

https://github.com/goagent/goagent/blob/c4386808ea943e2ebed25f1e5264943354e3f9cb/server/gae/gae.py#L184

GoAgent 還提供了一個可選功能，通過 RC4 和一個共享密鑰來對 proxy.py 和 gae.py 之間的數據進行進一步的混淆。啟用這一功能需要在 proxy.ini 中設置 gae.password，以及 gae.options=rc4，並在 gae.py 中設置 __password__ 變數。

https://github.com/goagent/goagent/blob/c4386808ea943e2ebed25f1e5264943354e3f9cb/server/gae/gae.py#L5

但是，這裡的 RC4 加密只能起到一個簡單的混淆作用，無法在不啟用 HTTPS 的情況下利用這一功能來防止中間人攻擊。GoAgent 中的 RC4 無法實現數據的機密性，因為密碼本身會通過一個 G-password 頭在 proxy.py 和 gae.py 中傳送，而且在兩段通信中會使用同樣的密碼流（keystream），導致攻擊者很容易通過密文的 XOR 操作來獲得 XOR 過的明文（見流密碼的重用問題，Stream Cipher Key Reuse），進而得到明文。在這裡 RC4 只能起到防止其他 GoAgent 用戶共享服務端流量的目的，無法提供更多的保護來防止網路攻擊。

如何防止風險

確認在 proxy.ini 中設置了 gae.mode=https （默認），並且啟用了證書驗証 gae.validate=1（非默認）。這樣的設定基本上能夠防止 proxy.py 和 GAE 伺服器，以及 GAE 伺服器和網站伺服器之間的 HTTPS 中間人攻擊。由於 proxy.py 中沒有對證書的主機名進行嚴格匹配，proxy.py 和 GAE 伺服器 的通信仍存在（相對較小的）風險，如果有人能夠申請到 organizationName 欄位以 ｢Google ｣ 開頭的證書，仍然能夠成功進行HTTPS 中間人攻擊。