爲什麼我們必須在http頭中指定服務器端加密？

本文在AWS開發者博客介紹瞭如何生成，將在服務器端進行加密S3文件前簽署的網址：https://aws.amazon.com/blogs/developer/generating-amazon-s3-pre-signed-urls-with-sse-kms-part-2/。描述如何生成url的部分是有道理的，但接下來文章將繼續描述如何在put請求中使用url，並且它說除了生成的url之外，還必須添加到http請求中指定加密算法的頭部。爲什麼在加密算法包含在url代中時這是必要的？爲什麼我們必須在http頭中指定服務器端加密？

// Generate a pre-signed PUT URL for use with SSE-KMS 
GeneratePresignedUrlRequest genreq = new GeneratePresignedUrlRequest(
    myExistingBucket, myKey, HttpMethod.PUT) 
    .withSSEAlgorithm(SSEAlgorithm.KMS.getAlgorithm()); 

... 

HttpPut putreq = new HttpPut(URI.create(puturl.toExternalForm())); 
putreq.addHeader(new BasicHeader(Headers.SERVER_SIDE_ENCRYPTION, 
    SSEAlgorithm.KMS.getAlgorithm()));

我問一部分是由於好奇，也因爲有從生成URL中的一個執行不同的機器上我的情況PUT請求正在運行的代碼。我不會詳細討論，但確保一臺機器生成的標題與另一臺機器生成的url相匹配是一件非常麻煩的事情。

來源

2017-09-12 Christopher Simmons

我不知道該如何辯解「清」是的，但我的假設是，需要加密的參數爲頭，以防止它們出現在該日誌查詢字符串日誌發送。

當加密算法被包含在URL中的一代

這方面是比較容易回答爲什麼這是必要的。經過簽名的請求是一種向系統證明擁有訪問密鑰的人員對這個確切的特定請求進行了授權，直至最後一個字節。更改任何有關被列入簽名生成的請求，並且您已經無效簽名，因爲現在要求從什麼是授權不同。

當S3收到您的請求時，它看起來你的密鑰，並做你的本地代碼做什麼...它簽署收到這個請求，並檢查其產生的簽名是否與您所提供的一個。

一個常見的誤解是，簽署網址由服務產生的，但事實並非如此。簽名的URL完全在本地生成。該算法對於反向工程來說在計算上是不可行的，並且對於任何給定的請求，確切地有1個可能的有效簽名。

來源

2017-09-13 03:17:35

它看起來像關於加密的信息不會被包含在URL presigned。我猜測它包含在GeneratePresignedUrlRequest中的唯一原因是生成一個經過驗證的哈希。在閱讀了關於何時使用url參數和自定義標題的問題之後，我不得不懷疑在這裏使用自定義標題而不是url參數是否有明確的理由。正如原始問題中提到的那樣，必須包含這些頭文件使得使用此API變得困難。如果使用url參數，我不會遇到這個問題。任何意見關於這個問題將不勝感激。

來源

2017-09-12 22:06:51

爲什麼我們必須在http頭中指定服務器端加密？

回答

相關問題