銀行文件傳輸的方法

來了網易快一年了，第一次接觸與合作方的文件傳輸方面的需求，這裏稍微整理一下整個流程紀要，以免遺忘~

如果有不恰當的地方，還請指教~

傳輸方法

1. 生成N個業務文件，並對每個文件的內容採用AES進行加密；
2. 生成OkFile.txt文件，記錄N個文件對應的行數以及大小，AES加密；（僅用於對每個文件進行粗略的校驗）
3. 將N個業務文件和OKFile文件進行壓縮打包爲tar.gz文件；
4. 對tar.gz文件求md5碼，生成md5文件；（防止第三方篡改某個文件的內容，供合作方驗證文件完整性）
5. 將tar.gz文件和md5文件傳送給合作方；（合作方在收到文件後，會採用相同算法對tar.gz文件求md5碼，並比對md5值是否相同，如果相同，說明文件完整性沒問題）
6. 如何傳輸？== 複用前人的方法，將需要傳輸的文件放在SFTP服務器上，對方定時拉取SFTP服務器上的文件；（注意賬號的讀寫權限）

這裏爲什麼採用了sftp而不是用https傳輸呢？下面對這兩部分協議進行調研，但是感覺還是沒有get到心中的點上，後續有時間繼續研究~

https還是sftp？

對於文件的傳輸，我們更加關心的是傳輸文件的大小以及安全性問題；對於性能方面的考慮，可能沒有那麼重要。

安全性上來說，https和sftp協議都是安全的傳輸協議，https = http + ssl，sftp是基於ssh的安全文件傳輸協議；

性能上來說，https協議的傳輸速度可能比sftp速度更快；

參考HTTPS or SFTP – which is best?這篇博文，最後有說到，對於一些普通的用戶，如果僅僅是要下載文件的功能，那麼https是更好的選擇（這裏是從用戶體驗考慮）；然而，如果涉及傳輸的文件比較複雜，比較大，那麼請採用sftp協議。

SFTP安全性？

sftp的安全性是由ssh協議進行保證，因此只需要弄懂ssh協議的安全性原理就ok了。

ssh協議目的是實現安全的遠程登錄或其他網絡安全服務，根源還是採用了非對稱加密和對稱加密的算法實現，但是卻無法解決中間人攻擊的問題。https是通過ca證書解決，那麼ssh是如何解決的呢？

1. 基於口令的認證

   由於ssh的publish key和private key都是自己生成的，沒辦法進行公證，只能通過client自己對公鑰進行確認。因此，在第一次登錄某臺server時，系統中會出現如下提示信息：
   
   這裏採用主機密鑰指紋（MD5）而不是直接採用主機密鑰，是因爲主機密鑰的key過長（採用rsa算法生成的公鑰有024位），不易比較，因此對公鑰進行hash生成一個128位的指紋。

   點擊 接受並保存 後，就表示該server已經被確認，並且會追加到client的known_hosts文件中。後續會用該公鑰對密鑰進行加密傳輸給server，此時server就能夠安全的拿到對稱加密的密鑰了，後面對數據的加密也是採用對稱加密的密鑰進行。

2. 基於公鑰的認證

   公鑰不同於上面的口令認證，不需要輸入密碼，而是需要用戶手動將client的公鑰添加到server端的authorized_key中。這樣用戶發送請求給server端時，server首先生成隨機數R，並用client的公鑰對其加密，得到pubKey®，返回給客戶端；客戶端拿到數據後，用私鑰解密，得到R，並用MD5對R和sessionKey生成摘要信息，將摘要信息傳輸給server，server同樣用MD5對R和sessionKey生成摘要，對比兩個摘要信息，完整認證過程。

由上面的兩種方法認證過程可知，ssh協議還是非常安全的，也能在一定程度上防止中間人攻擊。爲什麼說是一定程度上呢？因爲ssh協議的安全認證過程的前提是第一次連接認證的時候，不會被中間人攻擊，那麼client就會把指紋存放在本地的known_hosts文件中，以後的通訊就會通過known_hosts文件中的內容進行驗證。但是，如何中間人攻擊出現在第一次連接認證的時候，那麼安全性就無法得到保證了。

參考https://www.jianshu.com/p/33461b619d53