網絡傳輸安全
默認情況下pg服務端和客戶端之間的數據傳輸是明文傳輸，有一定的安全隱患。pg中可以使用ssl進行安全的tcp/ip連接，以密文的形式進行數據的安全傳輸。
這個特性要求在客戶端和服務器都安裝OpenSSL，並且在編譯pg的時候打開這個支持，使用openssl指令生成私鑰和證書，用來對數據加解密
注意在編譯安裝pg的時候需要添加--with-openssl參數，讓pg支持ssl認證方式
./configure --with-openssl
--如果沒有加上--with-openssl參數，在打開ssl配置，啟動pg的時候會報錯
SSL is not supported by this build
使用opsnessl生成密鑰和證書
--生成一個有效期365天的簡單自簽名證書，將bhost.yourdomain.com替換為服務器的主機名
openssl req -new -x509 -days 365 -nodes -text -out server.crt \
Ceyout server.key -subj "/CN=dbhost.yourdomain.com"
--然后執行：
chmod og-rwx server.key
配置postgres.conf和pg_hba.conf文件
--修改postgres.conf
ssl=on
ssl_cert_file='server.crt'
ssl_key_file='server.key'
--修改pg_hba.conf，新增ssl認證連接規則
hostssl all all 0.0.0.0/0 md5
重啟數據庫,ssl生效
[postgres@localhost ~]$ psql -Usa postgres -h localhost
Password for user sa:
psql (11.1)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select pg_backend_pid(), ssl_is_used(), ssl_version(), ssl_cipher();
pg_backend_pid | ssl_is_used | ssl_version | ssl_cipher
----------------+-------------+-------------+-----------------------------
12401 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384
(1 row)
- 驗證傳輸加密
1.--創建t_ssl測試表
postgres=# create table t_ssl(id int);
CREATE TABLE
postgres=# insert into t_ssl select generate_series(1,100);
INSERT 0 100
2.--在客戶端用psql遠程連接數據庫（如果抓包后再連接會把這個信息也抓進去）
psql -Usa postgres -p 6543 -h ip
3.--在服務器端使用tcpdump抓取數據包
[root@localhost opt]# tcpdump host ip -w /home/opt/ssl.cap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
4.--在客戶端使用psql執行命令
select * from t_ssl limit 10;
5.--使用wireshark工具對抓取的包解析
0000 00 50 56 86 d3 fd 00 0c 29 c8 7d 95 08 00 45 00 .PV.....).}...E.
0010 00 74 5e 01 40 00 40 06 63 a1 ac 19 10 44 ac 19 .t^.@.@.c....D..
0020 10 6b 8b 2c 19 8f 68 de d1 97 c9 c2 2a 9b 80 18 .k.,..h.....*...
0030 00 b3 2a 11 00 00 01 01 08 0a 63 01 30 c1 9a 61 ..*.......c.0..a
0040 6c 16 17 03 03 00 3b dd ae 8c 9b 38 9b 7d 02 9f l.....;....8.}..
0050 68 1a 42 05 91 11 42 4d 95 d0 e4 1b db d4 b9 46 h.B...BM.......F
0060 7c fa fd 71 3d 70 f6 0b ea bb ab 5f 16 1c 89 b2 |..q=p....._....
0070 c3 79 50 28 bf 52 93 c8 17 88 ec 35 f7 53 b2 7f .yP(.R.....5.S..
0080 a2 9a
6.--如果不使用openssl進行數據加密抓包的話，傳輸的sql會被抓取到
0000 00 50 56 86 d3 fd 00 0c 29 c8 7d 95 08 00 45 00 .PV.....).}...E.
0010 00 57 b5 0c 40 00 40 06 0c b3 ac 19 10 44 ac 19 .W..@.@......D..
0020 10 6b 8a fa 19 8f e3 33 04 75 b9 1a 0d 9f 80 18 .k.....3.u......
0030 00 7b 87 09 00 00 01 01 08 0a 62 f9 bc 8b 9a 5a .{........b....Z
0040 7f ee 51 00 00 00 22 73 65 6c 65 63 74 20 2a 20 ..Q..."select *
0050 66 72 6f 6d 20 74 5f 73 73 6c 20 6c 69 6d 69 74 from t_ssl limit
0060 20 31 30 3b 00 10;.
SSL雙向認證和SSL單向認證的區別
雙向認證 SSL 協議要求服務器和用戶雙方都有證書。單向認證 SSL 協議不需要客戶擁有CA證書，服務器端不會驗證客戶證書，以及在協商對稱密碼方案，對稱通話密鑰時，服務器發送給客戶的是沒有加過密的(這並不影響 SSL 過程的安全性)密碼方案。這樣，雙方具體的通訊內容，都是加過密的數據，如果有第三方攻擊，獲得的只是加密的數據，第三方要獲得有用的信息，就需要對加密的數據進行解密，這時候的安全就依賴於密碼方案的安全。而幸運的是，目前所用的密碼方案，只要通訊密鑰長度足夠的長，就足夠的安全。這也是我們強調要求使用128位加密通訊的原因。
一般Web應用都是采用SSL單向認證的，原因很簡單，用戶數目廣泛，且無需在通訊層對用戶身份進行驗證，一般都在應用邏輯層來保證用戶的合法登入。但如果是企業應用對接，情況就不一樣，可能會要求對客戶端(相對而言)做身份驗證。這時就需要做SSL雙向認證。
由於單向認證和雙向認證的區別僅在於創建連接階段，數據的傳輸均為加密的，因此客戶端與PG服務端的連接采取SSL單向認證即可，即僅在PG Server端配置SSL證書