amazon s3 - Why do we have to specify server-side encryption in the http header? -
this article in aws developer blog describes how generate pre-signed urls s3 files encrypted on server side: https://aws.amazon.com/blogs/developer/generating-amazon-s3-pre-signed-urls-with-sse-kms-part-2/ . part describes how generate url makes sense, article goes on describe how use url in put request, , says that, in addition generated url, 1 must add http request header specifying encryption algorithm. why necessary when encryption algorithm included in url's generation?
// generate pre-signed put url use 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())); i ask in part due curiosity because code has execute put request in case running on different machine 1 generates url. won't go details, it's real hassle make sure header 1 machine generates matches url other machine generates.
i don't know how "clear" justification is, assumption encryption parameters required sent headers in order keep them appearing in logs log query string.
why necessary when encryption algorithm included in url's generation
this aspect easier answer. signed request way of proving system in possession of access-key-secret authorized exact, specific request, down last byte. change anything request included in signature generation, , have invalidated signature, because request differs authorized.
when s3 receives request, looks secret key , local code does... signs request received , checks whether generated signature matches 1 supplied.
a common misconception signed urls generated service, aren't. signed urls generated entirely locally. algorithm not computationally-feasible reverse-engineer, , given request, there 1 possible valid signature.
Comments
Post a Comment