摘要：比如加密算法但是加密也存在局限性，需要定期維護(hù)。當(dāng)然聰明的你可能會(huì)說，那我就使用非對(duì)稱加密算法，比如好了。所以本次結(jié)合了和來實(shí)現(xiàn)我們的數(shù)據(jù)傳輸。發(fā)送方接收到請(qǐng)求返回結(jié)果后，通過約定的方式對(duì)返回結(jié)果進(jìn)行處理，以供后續(xù)使用。

最近公司需要通過公網(wǎng)與其它平臺(tái)完成接口對(duì)接，但是基于開發(fā)時(shí)間和其它因素的考慮，本次對(duì)接無法采用https協(xié)議實(shí)現(xiàn)。既然不能用https協(xié)議，那就退而求其次采用http協(xié)議吧！

那么問題來了！在對(duì)接的過程中我們需要對(duì)如下問題進(jìn)行相關(guān)的考慮：

1、敏感信息的不可見性

　　使用http協(xié)議傳輸數(shù)據(jù)很容易被抓包監(jiān)聽傳輸內(nèi)容，如果這些數(shù)據(jù)中存在敏感信息的話，風(fēng)險(xiǎn)太大了。因此我們需要對(duì)我們的傳輸數(shù)據(jù)進(jìn)行一定的加密處理，即使數(shù)據(jù)被預(yù)期接收方之外的其它不法分子攔截，也無法輕易的破譯此次請(qǐng)求的傳輸內(nèi)容！最簡單的方案就是對(duì)傳輸數(shù)據(jù)使用Base64方法轉(zhuǎn)碼，使得數(shù)據(jù)具備一定的不可讀性。當(dāng)然啦，這種方案實(shí)際上是不可取的，因?yàn)锽ase64方案太容易被識(shí)別然后解密了。比較常見的做法是，發(fā)送方和接收方彼此約定密鑰，發(fā)送方發(fā)送時(shí)用密鑰對(duì)數(shù)據(jù)加密，接收方用密鑰對(duì)數(shù)據(jù)解密。比如AES128加密算法？但是AES128加密也存在局限性，需要定期維護(hù)。就算你認(rèn)為你這方的內(nèi)部人員是可信的，你也無法無法保證對(duì)方的密鑰不會(huì)泄漏吧。當(dāng)然聰明的你可能會(huì)說，那我就使用非對(duì)稱加密算法，比如RSA好了。好像是沒啥問題？但是如果數(shù)據(jù)量比較大的話，RSA加密方法對(duì)服務(wù)器的壓力也是很大的。。所以本次結(jié)合了AES和RSA來實(shí)現(xiàn)我們的數(shù)據(jù)傳輸。

2、防止數(shù)據(jù)被篡改

　　用簽名！用簽名！用簽名！重要的事情說三遍？例如：當(dāng)數(shù)據(jù)被封裝好后，我們可以用md5算法計(jì)算出待傳輸數(shù)據(jù)的摘要字符串作為簽名。當(dāng)服務(wù)器接受到數(shù)據(jù)后，同樣使用md5對(duì)數(shù)據(jù)做摘要，同請(qǐng)求報(bào)文中的簽名作比較，若不一致則說明該http請(qǐng)求數(shù)據(jù)已被篡改。但僅僅使用md5對(duì)數(shù)據(jù)作摘要就夠了嗎？萬一攻擊方發(fā)現(xiàn)了數(shù)據(jù)簽名是用md5做的，攻擊方只需要對(duì)已篡改的數(shù)據(jù)再做一次md5，同時(shí)更新請(qǐng)求中的簽名即可。因此如何生成可靠的簽名也需要我們仔細(xì)的斟酌。有幾點(diǎn)我覺得是需要注意的：1、無法輕易的根據(jù)簽名推反推出當(dāng)前簽名所采用的算法；2、簽名算法的復(fù)雜性、可靠性；3、不要直接對(duì)傳輸數(shù)據(jù)作簽名，可以先對(duì)請(qǐng)求數(shù)據(jù)作摘要，再使用加密算法生成簽名，既可以提升效率也在一定程度上提高了安全性。

3、http請(qǐng)求的真實(shí)性

　　有很多方案可以保證http請(qǐng)求的真實(shí)性。比如使用token來進(jìn)行身份驗(yàn)證，可以借鑒微信的身份驗(yàn)證方案或者jwt實(shí)現(xiàn)。本次我們只做了簡單的處理，在http請(qǐng)求頭中設(shè)置了一個(gè)時(shí)間戳，當(dāng)服務(wù)器接收到數(shù)據(jù)后，會(huì)取出http請(qǐng)求中的時(shí)間戳，同時(shí)與服務(wù)器當(dāng)前時(shí)間作比較。若時(shí)間間隔過大，則認(rèn)為該請(qǐng)求是不真實(shí)的，直接拒絕并返回！

上面簡單的介紹了http傳輸敏感數(shù)據(jù)需要注意的地方，本方案具體實(shí)現(xiàn)思路如下圖所示：

發(fā)送方需要干的事

1、生成簽名

構(gòu)造傳輸對(duì)象，并將傳輸對(duì)象轉(zhuǎn)換成json字符串

　　　　 本次接口傳輸采用rest模式作為標(biāo)準(zhǔn)，先構(gòu)造待傳輸對(duì)象。構(gòu)造完成后借用Google的Gson包來將對(duì)象轉(zhuǎn)換成json字符串。

使用md5算法生成json字符串摘要

使用RSA公鑰對(duì)摘要字符串作加密處理，生成簽名

2、加密請(qǐng)求報(bào)文
　　發(fā)送方創(chuàng)建一個(gè)http請(qǐng)求時(shí)，需要?jiǎng)討B(tài)的生成一個(gè)AESKey，同時(shí)使用該AESKey對(duì)請(qǐng)求數(shù)據(jù)作加密處理。為什么每次請(qǐng)求都需要生成一個(gè)新的AESKey呢？主要還是為了防止數(shù)據(jù)泄漏。如果固定使用相同的Key，萬一Key被發(fā)送方內(nèi)部人員泄漏了，其實(shí)也對(duì)發(fā)送數(shù)據(jù)的加密也就沒有意義了。

3、加密AES密鑰
　　在http請(qǐng)求傳遞數(shù)據(jù)時(shí)，AES密鑰也會(huì)被同樣傳遞過去。為了保證AES密鑰的安全性，我們采用RSA公鑰對(duì)AES密鑰作加密處理。處理完后會(huì)放到Http請(qǐng)求頭的Authencation字段中。

4、構(gòu)造http請(qǐng)求

將第一步生成的簽名放到http請(qǐng)求頭中的Authencation字段中

將加密后的AES密鑰放到http請(qǐng)求頭中的SecurityKey字段中

將該請(qǐng)求創(chuàng)建時(shí)間放到http請(qǐng)求頭中的TimesTamp字段中

將第二步生成的加密報(bào)文放到http body中

5、處理http請(qǐng)求結(jié)果
　　在此之前，請(qǐng)求方和發(fā)送方需要約定返回結(jié)果的加密方式。發(fā)送方接收到http請(qǐng)求返回結(jié)果后，通過約定的方式對(duì)返回結(jié)果進(jìn)行處理，以供后續(xù)使用。這里我們僅簡單的約定接收方使用接收到的AES密鑰對(duì)返回?cái)?shù)據(jù)作加密后返回即可。

接收方需要干的事

1、請(qǐng)求的真實(shí)性校驗(yàn)
　　獲取http請(qǐng)求頭中的TimesTamp字段，同時(shí)與系統(tǒng)時(shí)間作比較。如果請(qǐng)求時(shí)間與當(dāng)前系統(tǒng)時(shí)間間隔在五分鐘之內(nèi)，則認(rèn)為請(qǐng)求是真實(shí)的，反之則認(rèn)為請(qǐng)求是非法的。

2、獲取AES密鑰
　　從http請(qǐng)求中的SecurtiyKey獲取被加密的AES密鑰，使用RSA密鑰對(duì)其解密，獲取可供使用的AES密鑰

3、獲取請(qǐng)求報(bào)文
　　從httpbody中獲取請(qǐng)求報(bào)文，使用上面第二步生成的AES密鑰解密請(qǐng)求報(bào)文

4、驗(yàn)簽

對(duì)第三步生成的請(qǐng)求報(bào)文作md5摘要生成md5Str

獲取http請(qǐng)求頭中的Authencation字符串，接著使用接收方保存的RSA密鑰對(duì)其作解密處理獲取rsaDecryptStr

比較md5Str和rsaDecryptStr是否一致，若一致則驗(yàn)簽通過

5、業(yè)務(wù)處理
　　使用第三步得到的請(qǐng)求報(bào)文進(jìn)行業(yè)務(wù)處理

6、返回處理結(jié)果
　　使用第二步獲取到的AES密鑰對(duì)返回結(jié)果作加密處理并返回

總結(jié)
　　本次http請(qǐng)求傳輸敏感數(shù)據(jù)方案的實(shí)現(xiàn)，上面做了詳細(xì)的介紹。另外多提一下。在接收方進(jìn)行驗(yàn)簽的時(shí)候，我們可以定義一個(gè)過濾器來過濾指定http請(qǐng)求。在過濾器中完成驗(yàn)簽的工作，以避免在業(yè)務(wù)處理代碼中摻雜驗(yàn)簽代碼！同時(shí)使用過濾器也可以對(duì)請(qǐng)求返回結(jié)果進(jìn)行加工處理，在這里就是用AES密鑰加密返回結(jié)果啦！