pg_dump獲取SSL錯誤，似乎超時

Question

我正嘗試使用pg_dump將數據庫下載到本地計算機。我使用的命令是：

pg_dump --host xx.xx.xx.xx --port xxxx --username "xxx" --password --format custom --blobs --verbose --file "testing.db" "xxx" 

當它到達它總是與此錯誤崩潰數據庫傾倒最後一個表：

pg_dump: Dumping the contents of table "versions" failed: PQgetCopyData() failed. 
pg_dump: Error message from server: SSL error: sslv3 alert handshake failure 
pg_dump: The command was: COPY public.xxx (columns) TO stdout; 

我通過SSH連接到這一點的服務器離我下載的服務器更近（我在布里斯班，在舊金山），並且能夠毫無問題地執行pg_dump。所以我知道數據庫服務器沒問題。我懷疑這是一個超時，因爲它在失敗之前進入最後一個表;如果它實際上是一個SSL錯誤，我預計它會提早出現。也就是說，超時發生在每次失敗後不同的時間量（兩個最近的測試分別在1300s和1812s之後失敗）。

歡迎提供關於如何調試的任何提示。

我在OS X 10.8.5上。本地pg_dump是9.2.4，服務器是運行psql 9.1.9的Ubuntu服務器。

Answer 1

這可能是一個SSL renegociation的問題。

請參閱服務器上的此參數（postgresql.conf）和關於舊SSL客戶端庫的相關警告，儘管OS X 10.8看起來比這更新。

從9.1 documentation：

ssl_renegotiation_limit (integer)

Specifies how much data can flow over an SSL-encrypted connection before 
renegotiation of the session keys will take place. 

Renegotiation decreases an attacker's chances of doing cryptanalysis when large amounts of traffic can be examined, but it also carries a large performance penalty. The sum of sent and received traffic is used to check the limit. If this parameter is set to 0, renegotiation is disabled. The default is 512MB.

Note: SSL libraries from before November 2009 are insecure when using SSL renegotiation, due to a vulnerability in the SSL protocol. As a stop-gap fix for this vulnerability, some vendors shipped SSL libraries incapable of doing renegotiation. If any such libraries are in use on the client or server, SSL renegotiation should be disabled.

編輯：

在postgresql.conf更新此參數不需要重新啓動服務器，但/etc/init.d/postgresql reload或service postgresql reload服務器重裝。

值可以也可以在SQL檢查與show ssl_renegotiation_limit;

即使轉儲的大小大於512Mb的小，它可能是發送的數據的量是這樣大，因爲pg_dump壓縮本地數據使用自定義格式時（--format custom）。