How to use SSE-S3 on Amazon S3? - security

Question

I want to enable SSE-S3 on Amazon S3. I click properties and check the encryption box for AES-256. It says encrypting, then done. But I can still read the files without providing a key, and when I check properties again, it shows the radio buttons unchecked. Did I do this correctly? Is it encrypted? So confusing.

Answer 1

You're looking at a view of a bucket in the S3 console that shows more than one file, or shows only one file but that file isn't selected. The radio buttons allow you to set all items you select to the values you select in the radio buttons, but the radio buttons remain blank whenever multiple files are shown, because they're only there to let you make a change -- not to show you the values of existing object.
Click on an individual file and view its properties and you'll see that the file is stored with server-side-encryption = AES256.
Yes, you can download the file without needing to decrypt it, because this feature is server-side encryption of data at rest -- the files are encrypted by S3 prior to storage on the physical media that S3 runs on. This is often done for compliance purposes, where regulatory restrictions or other contractual obligations require that data to be encrypted at rest.
The encryption keys are stored, separately from the object by S3, and are managed by S3. In fact, the encryption keys are actually stored, encrypted, by S3. (They generate a key for each object, and store that key in an encrypted form, using a master key).
Decryption of the encrypted data requires no effort on your part. When you GET an encrypted object, we fetch and decrypt the key, and then use it to decrypt your data.
https://aws.amazon.com/blogs/aws/new-amazon-s3-server-side-encryption/
For data in transit, S3 encrypts that whenever you use HTTPS.
Different than the feature that's available in the console, S3 also supports server-side AES-256 encryption with keys you manage. In this scenario, called SSE-C, you still aren't responsible for the actual encryption/decryption, because S3 still does that for you. The difference is that S3 doesn't store the key, and you have to present the key to S3 with a GET request in order for S3 to fetch the object, decrypt it, and return it to you. If you don't provide the correct key, S3 won't bother to return the object -- not even in encrypted form. S3 knows whether you've sent the right key with a GET request, because S3 stores a salted HMAC of the key along with the object, for validation of the key you send when you try to fetch the object, later.
This capability -- where you manage your own keys -- requires HTTPS (otherwise you'd be sending your encryption key accross the Internet unencrypted) and is only accessible through the API, not the console.
You cannot use the Amazon S3 console to upload an object and request SSE-C. You also cannot use the console to update (for example, change the storage class or add metadata) an existing object stored using SSE-C.
http://docs.aws.amazon.com/AmazonS3/latest/dev/ServerSideEncryptionCustomerKeys.html
And, of course, this method -- with customer-managed keys -- is particularly dangerous if you don't have a solid key-management infrastructure, because if you lose the key you used to upload a file, that file is, for all practical purposes, lost.