使用了https後，還有必要對數據進行簽名來確保數據沒有被篡改嗎？

01-18

看到很多開放API中（X寶，X信，X東等等），即便請求要求強制使用https了，但是還要對數據進行md5簽名(X東使用MD5 X寶使用RSA)，有的甚至多次簽名(X信)。
1、有這個必要嗎？
2、這樣做是為了解決什麼問題呢？
3、這樣做著的有效嗎？
個人覺得這個簽名機制並不存在保密性，如果web中使用，只要抓一下js就可以知道簽名機制並且偽造請求了。

PS1：這裡的簽名指的是對所傳的數據內容+時間戳+key 進行排列組合之後進行加密生成的字元串。這個字元串將會隨著所傳的數據內容一併發送到伺服器。之後服務對數據內容進行同樣的方式簽名來保證數據沒有被篡改過。
PS2:不討論具體的加密技術(RSA,AES,MD5)，只想了解這樣的簽名究竟是為了結局什麼問題？以及如何更有效的使用這種方法。

簽名是什麼意思

不是叫「散列」么

首先明確一點，我們常說的SSL/TLS加密是傳輸層加密，如果SSL/TLS加密服務與HTTP伺服器位於一台物理伺服器上，那SSL/TLS可以提供客戶端到伺服器端的安全（End To End Security）。

Client ---HTTPS---（HTTP Server + SSL）

而現實情況卻往往不是以上的部署方式，而是採用負載均衡（Load Balance）設備先終結客戶端的SSL/TLS會話，負載均衡設備然後再與HTTP伺服器之間採用明文傳輸(HTTP)，即使這一段傳輸位於內部安全域，它依然是一個安全隱患。

Client ---HTTPS---Load Balance ---HTTP---HTTP Server

為了保證端對端的絕對安全，我們需要在應用層增添安全保障，即保證用戶數據不被篡改，這裡就用到了題主所描述的HMAC（Keyed Hash Message Authentication Code） ，關於HMAC很難翻譯成中文，如果翻譯成加密的哈希演算法，事實上並沒有加密哈希；也不是簽名，簽名只用於非對稱的數字證書籤名，所以還是不要翻譯了，大家知道HMAC是為了保證用戶的數據不被篡改就可以了。

來看看題主提到的HMAC

很顯然這個HMAC位於應用層（附在HTTP報文末尾），所以無論SSL與HTTP伺服器一體還是分離，HMAC都可以保證端對端的數據完整性保護（數據不被篡改）。

題主提到的HMAC有三個輸入參數：

用戶數據

時間戳

Key

前兩者會伴隨HTTP到達伺服器，這個key 卻不會，如果一起傳輸，就沒有任何意義了，第三方可以篡改用戶數據，然後重新計算HMAC。

這個key 只有客戶端（用戶）與伺服器端知曉，扮演這個key 角色最好人選就是賬戶密碼，

客戶端/伺服器端分別將賬戶密碼為輸入參數，計算出Hash，這個Hash應該是一樣的，然後就可以做為Key了。

由於Key只有客戶端/伺服器知曉，任何篡改數據的企圖都會被發現，用戶數據不被篡改，用戶的交易就是安全的。

一句話總結陳詞：HMAC是應用層採用的手段來保護數據安全，SSL/TLS是傳輸層保護數據的機密與數據安全。

必須有啊，https僅僅保證了單詞傳輸過程可靠，但是如果一個中間病毒既當真是伺服器的客戶端，又修改內容作為服務端向客戶端發送數據呢

先說結論：簽名是對傳輸內容進行簽名，屬於應用層防護。https主要用於傳輸通道的防護。

1、有必要的。

2、解決的問題參考後面描述

3、能力有限，不知道是否絕對有效，是否存在漏洞。但這個過程是說的通的，避免的中途篡改參數的可能。起碼在雙層保護下難得極高。

淘寶開放的api，對於簽名說的很清楚。只要是防止API調用過程中被篡改。

其簽名對象是API調用用的參數，把參數按一定規則拼接成字串，在進行再進行HMAC或MD5。此過程中需要提供app 的secret。再經過hex轉換為16進位。

生產簽名後，該值會隨著API介面調用的GET或POST，附加在調用參數後面，提交給TOP伺服器。

TOP伺服器可以根據簽名來判斷GET或POST包含的參數是否被篡改。

其實在使用了https之後，確實就能保證客戶端到伺服器的傳輸數據不會被篡改了。但是為什麼還要加上md5的驗證嗎，其實不單單是第二次的驗證可以保證更高的安全性。還有一個原因是，伺服器可以驗證你傳過來的信息遵循了我們的規範，如果驗簽通不過，那麼伺服器端就認為這一次請求不合要求，接下去的業務也沒必要進行下去了。

HTTPS這裡（在一定程度上）保障數據在傳輸過程中的完整性和保密性，就是保證你客戶端到伺服器之間這段。但是不保證請求內容的合法性，比如我閑著沒事幹偽造請求發給伺服器，比如我閑著沒事幹重放一個請求給伺服器，這些問題 HTTPS 幫不了你。

關於這個多一層校驗題主覺得沒意義的事情，這個就像是不談劑量談毒性一樣。雖然從根本上來說等於是開放給所有人看的，但是這無疑是加入了一道門檻，而且JS可以混淆，這道門檻還不低，第二點就是當你看懂了這個校驗的演算法了之後，服務商可以換方法，這樣你之前費心看懂的又沒用了。換句話說，題主我相信你應該試圖解過鄰居的無線密碼，我是不是可以說反正這網路是公開的，總歸可以被人破解，那我索性就不上密碼了，這肯定是不對的，這是一道門檻，而且一段時間我可以換一次，讓你之前的工作失去意義。

需要，https的有效範圍一般局限於外網或者說證書所在伺服器，有可能你的伺服器不是一台，你的數據包在內網的伺服器之間會有轉發，這個時候就是明文了，再者，一般金融項目都會和銀聯或者支付寶合作，銀聯會讓你用它的公鑰來加密數據或者用md5來防止數據被篡改，具體視數據重要性，因為銀聯不會信任你的安全保障機制

這個MD5里的值是數據內容+時間戳+一個key

HTTPS確保了信息的機密性

而這個md5值里的key應該也是機密的，不知道用的是什麼，難道是ssl 生成的對稱key？

如果是這樣的話，個人覺得，是否這個md5不僅僅能確保數據的一致性，也同時避免了有人錄製了包，之後再次發送，造成double spend

因為此時時間已經不同，而key的存在保證攻擊者不能偽造這個md5

只是一個想法，期待大神露面。

看情況，雖然說大部分情況下是沒有必要的。

比如，很多商業軟體採用了web註冊機制，把lic內容提交給webservice這個過程就是ssl的。那還要保護lic內容的真偽呢，於是lic內容里就有授權信息+授權的hash。這個hash的目的就是類似於題主的md5問題了。

md5計算占不了多少消耗，都是多加點計算節點的事。但是多加一層驗證保護的是數據。

需要呀，我記得kali linux中一個工具都可以破解https的內容，也可以偽造數字簽證。有個博客有記載的。幾個月了之前看的了，記不太清楚了