## 網路傳輸安全 預設情況下pg服務端和客戶端之間的資料傳輸是明文傳輸，有一定的安全隱患。pg中可以使用ssl進行安全的tcp/ip連線，以密文的形式進行資料的安全傳輸。 這個特性要求在客戶端和伺服器都安裝OpenSSL，並且在編譯pg的時候開啟這個支援，使用openssl指令生成私鑰和證書，用來對資料加解密 注意在編譯安裝pg的時候需要新增--with-openssl引數，讓pg支援ssl認證方式 ```sql ./configure --with-openssl --如果沒有加上--with-openssl引數，在開啟ssl配置，啟動pg的時候會報錯 SSL is not supported by this build ``` 使用opsnessl生成金鑰和證書 ```sql --生成一個有效期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檔案 ```sql --修改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生效 ```sql [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) ``` - 驗證傳輸加密 ```sql 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^.@[email protected].. 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..@[email protected].. 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證書 [參考文件](https://my.oschina.net/tianbing/blog