# 31.18\. SSL 支持 PostgreSQL本機支持使用SSL連接對客戶端/服務器通訊進行加密， 以增強安全性。參閱[Section 17.9](#calibre_link-657)獲取服務器端SSL功能的細節。 libpq讀取全系統OpenSSL配置文件， 默認情況下，文件命名為`openssl.cnf`并且存放在`openssl version -d` 報告的目錄中。此默認可以通過設置環境變量`OPENSSL_CONF`為所需配置文件的名稱來重寫。 ## 31.18.1\. 服務器證書的客戶端驗證 缺省，PostgreSQL不會執行任何服務器證書驗證。 這就意味著可以在客戶端沒有察覺的情況下騙過服務認證（如，通過修改一個DNS記錄或接管服務IP地址）。 為了避免這種情況，必須使用SSL證書認證。 如果`sslmode`參數設置為`verify-ca`， libpq將通過檢查受信任的證書頒發機構的證書鏈(CA)來驗證服務是可信任的。 如果`sslmode`設置為`verify-full`， libpq_也_會通過驗證服務主機名匹配認證來認為服務是可信任的。 如果服務驗證不能被通過，那么SSL連接會失敗。在大多數對安全要求較高的環境中， 建議使用`verify-full`。 在`verify-full`模式下，認證的`cn`(Common Name)屬性與主機名進行匹配。 如果`cn`以`*`開始，會被看做是一個通配符，并且會匹配_除了_ 點（`.`）之外的所有字符。這就意味著認證不會匹配子域名。 如果是使用IP而不是主機名進行連接，會進行IP匹配檢查（不會做DNS檢查）。 為了允許服務器認證通過，一個或多個信任的CA認證必須放在用戶的home目錄下的 `~/.postgresql/root.crt`文件中。Windows下的文件名是`%APPDATA%\postgresql\root.crt`。 如果存在`~/.postgresql/root.crl`文件（Windows下是 `%APPDATA%\postgresql\root.crl`文件），同樣也會檢查證書吊銷列表（CRL）。 root認證文件和CRL的位置可以通過設置`sslrootcert`和`sslcrl`連接參數， 或`PGSSLROOTCERT`和`PGSSLCRL`環境變量進行修改。 > **Note:** 為了與早期PostgreSQL版本兼容，如果存在一個根CA文件，`sslmode`=`require` 的行為將和`verify-ca`表現的相同，意味著服務器證書是經過CA驗證的。 不建議依賴于這個行為，需要證書驗證的應用應該總是使用`verify-ca` 或`verify-full`。 ## 31.18.2\. 客戶端證書 如果服務器要求一個信任的客戶端認證，libpq將發送存儲在用戶home目錄中 `~/.postgresql/postgresql.crt`文件中的證書。該證書必須由服務器信任的證書認證 （CA）之一簽名。同時也必須出示一個匹配的私鑰文件 `~/.postgresql/postgresql.key`。私鑰文件不允許任何對世界或組的訪問； 通過`chmod 0600 ~/.postgresql/postgresql.key`命令可以實現。 在Windows上，這個文件是`%APPDATA%\postgresql\postgresql.crt` 和`%APPDATA%\postgresql\postgresql.key`，同時沒有特定的權限檢查， 因為目錄被認為是安全的。證書和key文件的位置可以通過`sslcert`和`sslkey`連接參數， 或`PGSSLCERT`和`PGSSLKEY`環境變量進行覆蓋重寫。 在一些情況下，客戶端認證可能會被一個"intermediate"的證書認證來簽名， 而不是一個能直接被服務信任的。為了使用一個這種認證，向`postgresql.crt` 文件追加證書簽字權，并且直到"root"都可以被服務器信任。 root認證應該被包含在任何一種情況（`postgresql.crt`包含多個認證）下。 需要注意的是，`root.crt`列出了最高級別的CA， 認為對簽名服務證書來說是可信任的。原則上，不需要列出簽名客戶端認證的CA， 盡管在大多數情況下，CA仍會被認為對服務器認證是可信任的。 ## 31.18.3\. 在不同的模式提供保護 `sslmode`參數的不同值提供了不同的保護級別。SSL可以為三種攻擊提供保護： Eavesdropping（竊聽） 如果一個第三方可以在客戶端與服務器端之間檢查網絡通信，那么它就能讀取兩邊的連接信息 （包括用戶名和密碼）以及傳遞的數據。對此，SSL通過加密進行防護。 裁判(MITM) 如果客戶端和服務器端進行傳遞數據的時候，第三方可以對其進行修改，那么他就能偽裝成服務器， 然后查看或修改數據（_即使是加密的_）。第三方接著可以向原始服務器發出連接信息和數據， 最終造成無法防護這種攻擊。這種攻擊常用的載體有DNS中毒或IP綁架， 即客戶端被定向到預期之外的不同的服務器。同樣還有幾種其他的方法也能做到這種攻擊。 SSL通過服務器到客戶端的證書驗證來阻止這種攻擊。 Impersonation（模擬） 如果第三方可以偽裝成一個認證了的客戶端，那么它就能輕松訪問到它本來不能訪問的數據。 典型的，如不安全的密鑰管理，就會造成這種情況。SSL 通過客戶端認證來阻止這種情況，即確保只有知道有效認證的人員才能訪問連接服務器。 對于一個被稱為安全的連接來說，進行連接之前，必須在_客戶端和服務器端都_進行SSL配置。 如果只在服務器端進行配置，在它知道服務器端需要高級認證之前不會發送敏感信息（如密碼等）。 在libpq中，可以通過將`sslmode`參數設置為`verify-full`或`verify-ca` 來確保安全連接，并且為系統提供一個root認證以進行安全認證。類似于使用`https` 和URL進行加密網頁瀏覽。 一旦服務器已經認證，客戶端就可以發送敏感信息。這就意味著直到這一刻，客戶端都不需要知道， 是否認證需要證書，只在服務器配置，對其安全地指定。 所有以加密和密鑰交換方式得SSL選項都會產生開銷，因此在性能和安全之間需要進行一個權衡。 [Table 31-1](#calibre_link-2107)說明不同`sslmode`值的安全風險， 以及關于安全和開銷所做出的聲明： **Table 31-1\. SSL 模式說明** | `sslmode` | 竊聽保護 | MITM保護 | 聲明 | | --- | --- | --- | --- | | `disable` | 否 | 否 | 我不關心安全，我不想來支付加密的開銷。 | | `allow` | 可能 | 否 | 我不關心安全性，但我會支付的加密開銷，如果服務器的堅持的話。 | | `prefer` | 可能 | 否 | 我不關心加密，但我想支付加密開銷，如果服務器支持它。 | | `require` | 是 | 否 | 我希望我的數據加密，我接受開銷。我相信該網絡將確保我始終連接到我想要的服務器。 | | `verify-ca` | 是 | `取決于CA`的政策 | 我希望我的數據加密，我接受開銷。我想要確保我連接到了一個我信任的服務器。 | | `verify-full` | 是 | 是 | 我希望我的數據加密，我接受開銷。我想要確保我連接到了一個我信任的服務器， 并且是我指定的那個服務器。 | `verify-ca`和`verify-full`之間的不同是根據root CA的政策。 如果使用的是一個公用CA，`verify-ca`允許那些帶有CA 注冊的客戶端對服務器進行連接訪問。在這種情況下，應該使用`verify-full`。 如果使用的是一個本地CA，甚至是一個自簽名證書， 使用`verify-ca`通常會提供充分的保護。 `sslmode`缺省值是`prefer`。如在表中說明的那樣， 從安全角度來看這樣做是沒有意義的，并且如果可能的話，它只承諾性能的開銷。 它僅提供了缺省向后兼容性，在安全部署中不建議使用。 ## 31.18.4\. SSL 客戶端文件的使用 [Table 31-2](#calibre_link-2108)總結了與客戶端SSL設置相關的文件。 **Table 31-2\. libpq/客戶端SSL文件的使用** | 文件 | 內容 | 影響 | | --- | --- | --- | | `~/.postgresql/postgresql.crt` | 客戶端證書 | 服務器要求的 | | `~/.postgresql/postgresql.key` | 客戶端的私鑰 | 證明由所有者發送的客戶端證書，并不表示證書擁有者是值得信賴的 | | `~/.postgresql/root.crt` | 受信任的證書頒發機構 | 檢查服務器證書是由受信任的證書機關簽署。 | | `~/.postgresql/root.crl` | 證書頒發機構吊銷證書 | 服務器證書必須不在這個名單 | ## 31.18.5\. SSL 庫初始化 如果應用程序初始化`libssl`和/或`libssl`庫以及libpq 編譯為支持SSL，應該調用`PQinitOpenSSL`來告訴libpq 說`libssl`和/或`libcrypto`庫已經被應用程序初始化了， 因此libpq將不會再初始化這些庫。參閱 [http://h71000.www7.hp.com/doc/83final/BA554_90007/ch04.html](http://h71000.www7.hp.com/doc/83final/BA554_90007/ch04.html) 獲取關于SSL API的詳細信息。 `PQinitOpenSSL` 允許應用程序選擇安全庫初始化。 ``` void PQinitOpenSSL(int do_ssl, int do_crypto); ``` 當`do_ssl`為非0時，在第一次打開一個數據庫連接之前，libpq 將初始化OpenSSL庫。當`do_crypto`為非0時，`libcrypto` 庫將被初始化。缺省(如果`PQinitOpenSSL`沒有被調用)，兩個庫都會被初始化。 如果沒有編譯SSL支持，會提供該函數，但不會做任何事情。 如果應用程序使用并初始化OpenSSL，或其底層`libcrypto`庫， 那么在第一次打開一個數據庫連接之前，_必須_調用這個函數（帶有適當0值的參數）。 同樣要確保在打開一個數據庫連接之前做過初始化。 `PQinitSSL` 允許應用程序選擇初始化哪個安全庫。 ``` void PQinitSSL(int do_ssl); ``` 此功能相當于`PQinitOpenSSL(do_ssl, do_ssl)`。 它的應用是足夠的同時初始化或都不初始化OpenSSL和`libcrypto`。 `PQinitSSL`在PostgreSQL 8.0就已經出現了， 而`PQinitOpenSSL`是在PostgreSQL 8.4添加進來的。 所以對老版本的libpq的使用，`PQinitSSL`是對應用程序的不錯的選擇。