簡單介紹一下我們項目的背景，我們公司是金融公司A，開發的這個系統是一個跟第三方銀行B進行接口調用的系統，每天公司A內部系統會生成一批數據，這些數據包括公司客戶名，身份證號，銀行卡號，扣款金額等信息，會通過HTTP Web API接口調用的方式，把這些數據推送給銀行B端，因爲這些客戶都是簽署了代扣協議的，銀行B端就會從這些人的銀行卡中扣款。最後，銀行會把批量的扣款結果，通過回調我們公司A接口的方式，推回我們公司。
1. 如果使用HTTP協議，肯定會存在安全問題。舉個例子，在A向銀行B發送的數據中，包含用戶張三的應扣款爲20塊錢，使用http的方式傳輸，並且使用的是明文，這些流量在半路被人攔截了，並進行了篡改，張三的應扣款被改爲了5塊錢，到達銀行那端的話，銀行也是無法察覺的。所以不能使用明文傳輸的方式。
2. 爲了保護信息不被篡改，我們進行了改進，將明文變成了密文。採用的是RSA加密的方式。銀行端產生了一對公鑰B跟私鑰B，他們自己保留私鑰B，然後通過證書的形式把公鑰B給我們公司。我們保留自己的私鑰A，然後通過證書的形式把公鑰A給銀行。注意，這時候一共有兩對祕鑰對，分別是銀行的私鑰B跟公鑰B，我們公司A的私鑰A跟公鑰A。在我們自己的服務器上有兩個文件，一個是pfx文件，包含我們自己的私鑰A，另一個是cer文件，包含銀行的公鑰B. 相對的，銀行端服務器也有兩個文件，私鑰B跟公鑰A.
每次我們向銀行發消息的時候，會先用銀行的公鑰B進行加密，然後銀行那端收到消息後會進行解密，用私鑰B進行解密。然後銀行端向我們公司調接口的時候，會用公鑰A進行加密，然後我們這端收到消息後會用私鑰A進行解密。這樣保證了消息傳播的安全。
3. 如果說我們公司自己去製造一個私鑰公鑰並且生成證書比較複雜的話，可以參照HTTPS的過程對項目進行改進。這樣，就只有銀行端具有一對公鑰與私鑰，銀行保留私鑰，然後將公鑰以證書的形式給到我們公司。接下來，如果傳輸一次數據，那麼就不僅僅是一個http請求，而是多次的http請求，需要對我們每一次的API請求進行結構化，即(1)我們公司先發一個請求到銀行，一個http請求，可能只包含一個簡單的文字，比說Start, 告訴銀行端這要發起一個API調用，(2)然後我們公司需要先動態生成一個對稱祕鑰，然後我們使用銀行的公鑰，對這個動態生成的祕鑰進行加密，加密完成後傳給銀行。銀行接受到之後，明白了之後需要用這個祕鑰進行加密解密。這裏之所以是以後用對稱加密，是因爲非對稱加密比較效率低。現在有了可靠的方式傳輸對稱祕鑰，以後就可以用對稱加密傳輸內容了。(3) 我們這邊用對稱加密的祕鑰進行加密，然後傳給銀行端。(4) 銀行端接到消息後，用對稱加密的祕鑰進行解密。(5) 公司端發一個結束的請求給銀行，只包含一個簡單的文件，比如End, 告訴銀行這次請求結束了，你把剛剛發給你的祕鑰刪了吧。(6) 銀行刪祕鑰。準備好下一輪的請求。
其實，這個邏輯更適用於TCP的模式，而不是HTTP。 TCP的話是一個連接，這個使用HTTP的話，會有多次的連接打開關閉。