PostgreSQL SSL 支持

默認(rèn)情況下，PostgreSQL將不會執(zhí)行服務(wù)器證書的任何驗證。這意味著可以在不被客戶端知曉的情況下偽造服務(wù)器身份（例如通過修改一個 DNS 記錄或者接管服務(wù)器的 IP 地址）。為了阻止哄騙，客戶端必須能夠通過一條信任鏈驗證服務(wù)器的身份。信任鏈可以這樣建立：在一臺計算機上放置一個根（自簽名的）證書機構(gòu)（CA）的證書并且在另一臺計算機上放置一個由根證書 簽發(fā) 的葉子證書。還可以使用一種“中間”證書，它由根證書簽發(fā)并且可以簽發(fā)葉子證書。

為了允許客戶端驗證服務(wù)器的身份，在客戶端上放置一份根證書并且在服務(wù)器上放置由根證書簽發(fā)的葉子證書。為了允許服務(wù)器驗證客戶端的身份，在服務(wù)器上放置一份根證書并且在客戶端上放置由根證書簽發(fā)的葉子證書。也可以使用一個或者更多個中間證書（通常與葉子證書存在一起）來將葉子證書鏈接到根證書。

一旦信任鏈被建立起來，客戶端有兩種方法驗證服務(wù)器發(fā)過來的葉子證書。如果參數(shù)sslmode被設(shè)置為verify-ca，libpq將通過檢查該證書是否鏈接到存儲在客戶端上的根證書來驗證服務(wù)器。如果sslmode被設(shè)置為verify-full，libpq還將驗證服務(wù)器的主機名匹配存儲在服務(wù)器證書中的名稱。如果服務(wù)器證書無法被驗證，則SSL連接將失敗。在大部分對安全性很敏感的環(huán)境中，推薦使用 verify-full。

在verify-full模式中，主機名被拿來與證書的主體別名屬性 匹配，或者在不存在類型dNSName的主體別名時與通用名稱屬性匹配。 如果證書的名稱屬性以一個星號（*）開始，這個星號將被 視作一個通配符，它將匹配所有除了句點（.） 之外的字符。這意味著該證書將不會匹配子域。如果連接是使用一個 IP 地址而不是一個主機名創(chuàng)建的，該 IP 地址將被匹配（不做任何 DNS 查找）。

要允許服務(wù)器證書驗證，必須將一個或者更多個根證書放置在用戶主目錄下的~/.postgresql/root.crt文件中（在Microsoft Windows上該文件名為%APPDATA%\postgresql\root.crt）。如果需要把服務(wù)器發(fā)來的證書鏈鏈接到存儲在客戶端的根證書，還應(yīng)該將中間證書加到該文件中。

如果文件~/.postgresql/root.crl存在（微軟 Windows 上的%APPDATA%\postgresql\root.crl），證書撤銷列表（CRL）項也會被檢查。

根證書文件和 CRL 的位置可以通過設(shè)置連接參數(shù)sslrootcert和sslcrl或環(huán)境變量PGSSLROOTCERT和PGSSLCRL改變。

如果服務(wù)器嘗試通過請求客戶端的葉子證書來驗證客戶端的身份，libpq將發(fā)送用戶主目錄下文件~/.postgresql/postgresql.crt中存儲的證書。該證書必須鏈接到該服務(wù)器信任的根證書。也必須存在一個匹配的私鑰文件~/.postgresql/postgresql.key。該私鑰文件不能允許全部用戶或者組用戶的任何訪問，可以通過命令 chmod 0600 ~/.postgresql/postgresql.key實現(xiàn)。在微軟 Windows 上這些文件被命名為%APPDATA%\postgresql\postgresql.crt和%APPDATA%\postgresql\postgresql.key，不會有特別的權(quán)限檢查，因為該目錄已經(jīng)被假定為安全。證書和密鑰文件的位置可以使用連接參數(shù) sslcert和sslkey或者環(huán)境變量PGSSLCERT和PGSSLKEY覆蓋。

postgresql.crt中的第一個證書必須是客戶端的證書，因為它必須匹配客戶端的私鑰。可以選擇將“中間”證書追加到該文件 — 這樣做避免了在服務(wù)器上存放中間證書的要求（ssl_ca_file）。

證書和密鑰可能是 PEM 或 ASN.1 DER 格式。

密鑰可以以明文存儲，也可以使用OpenSSL支持的任何算法(例如AES-128)使用密碼進(jìn)行加密。 如果密鑰是加密存儲的，那么可以在sslpassword連接選項中提供密碼。 如果提供了加密密鑰，而且sslpassword選項不存在或為空，如果TTY可用，那么OpenSSL將交互式地以 Enter PEM pass phrase:提示輸入密碼。 應(yīng)用程序可以越過客戶端證書提示和sslpassword參數(shù)的處理，通過提供它們自己的密鑰密碼回調(diào);參見PQsetSSLKeyPassHook_OpenSSL。

創(chuàng)建證書的指令請參考第 18.9.5 節(jié)。

sslmode參數(shù)的不同值提供了不同級別的保護(hù)。SSL 能夠針對三類攻擊提供保護(hù)：

對于一個已知的SSL-secured連接，在連接被建立之前，SSL 使用必須被配置在客戶端和服務(wù)器之上。如果只在服務(wù)器上配置，客戶端在知道服務(wù)器要求高安全性之前可能會結(jié)束發(fā)送敏感信息（例如口令）。在 libpq 中，要確保連接安全，可以設(shè)置sslmode參數(shù)為verify-full或verify-ca并且為系統(tǒng)提供一個根證書用來驗證。這類似于使用一個 https URL進(jìn)行加密網(wǎng)頁瀏覽。

一旦服務(wù)器已經(jīng)被認(rèn)證，客戶端可以傳遞敏感數(shù)據(jù)。這意味著直到這一點，客戶端都不需要知道是否證書將被用于認(rèn)證，這樣只需要在服務(wù)器配置中指定就比較安全。

所有SSL選項都帶來了加密和密鑰交換的負(fù)荷，因此必須在性能和安全性之間做出平衡。表 33.1不同sslmode值所保護(hù)的風(fēng)險，以及它們是怎樣看待安全性和負(fù)荷的。

verify-ca和verify-full之間的區(qū)別取決于根CA的策略。如果使用了一個公共CA，verify-ca允許連接到那些可能已經(jīng)被其他人注冊到該 CA的服務(wù)器。在這種情況下，總是應(yīng)該使用verify-full。如果使用了一個本地CA或者甚至是一個自簽名的證書，使用verify-ca常常就可以提供足夠的保護(hù)。

sslmode的默認(rèn)值是prefer。如表中所示，這在安全性的角度來說沒有意義，并且它只承諾可能的性能負(fù)荷。提供它作為默認(rèn)值只是為了向后兼容，并且我們不推薦在安全部署中使用它。

表 33.2總結(jié)了與客戶端 SSL 設(shè)置相關(guān)的文件。

如果你的應(yīng)用初始化libssl或libcrypto庫以及帶有SSL支持的libpq， 你應(yīng)該調(diào)用 PQinitOpenSSL來告訴 libpq：libssl或libcrypto庫已經(jīng)被你的應(yīng)用初始化，這樣libpq將不會也去初始化那些庫。