AWS AmazonS3 high security documentation change
Summary
Significantly restructured SSE-C documentation to discourage its use, added deprecation timeline, emphasized security limitations, and redirected to alternative encryption methods.
Security assessment
The changes explicitly highlight security risks of SSE-C including key management vulnerabilities ('if you lose the encryption key, you lose the object'), HTTPS enforcement requirements, and inability to share keys securely. The documentation now warns about SSE-C's incompatibility with AWS services and explicitly states it will be disabled by default in 2026, indicating security concerns.
Diff
diff --git a/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.md b/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.md index 0885f63b8..0ee3ce343 100644 --- a//AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.md +++ b//AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.md @@ -5 +5 @@ -SSE-C overviewRequiring and restricting SSE-CPresigned URLs and SSE-CSpecifying SSE-C +Considerations before using SSE-C @@ -9 +9 @@ SSE-C overviewRequiring and restricting SSE-CPresigned URLs and SSE-CSpecifying -Server-side encryption is about protecting data at rest. Server-side encryption encrypts only the object data, not the object metadata. By using server-side encryption with customer-provided keys (SSE-C), you can store your data encrypted with your own encryption keys. With the encryption key that you provide as part of your request, Amazon S3 manages data encryption as it writes to disks and data decryption when you access your objects. Therefore, you don't need to maintain any code to perform data encryption and decryption. The only thing that you need to do is manage the encryption keys that you provide. +Server-side encryption is about protecting data at rest. Server-side encryption encrypts only the object data, not the object metadata. You can use server-side encryption with customer-provided keys (SSE-C) in your general purpose buckets to encrypt your data with your own encryption keys. With the encryption key that you provide as part of your request, Amazon S3 manages data encryption as it writes to disks and data decryption when you access your objects. Therefore, you don't need to maintain any code to perform data encryption and decryption. The only thing that you need to do is manage the encryption keys that you provide. @@ -11,21 +11 @@ Server-side encryption is about protecting data at rest. Server-side encryption -When you upload an object, Amazon S3 uses the encryption key that you provide to apply AES-256 encryption to your data. Amazon S3 then removes the encryption key from memory. When you retrieve an object, you must provide the same encryption key as part of your request. Amazon S3 first verifies that the encryption key that you provided matches, and then it decrypts the object before returning the object data to you. - -There are no additional charges for using SSE-C. However, requests to configure and use SSE-C incur standard Amazon S3 request charges. For information about pricing, see [Amazon S3 pricing](https://aws.amazon.com/s3/pricing/). - -###### Note - -Amazon S3 does not store the encryption key that you provide. Instead, it stores a randomly salted Hash-based Message Authentication Code (HMAC) value of the encryption key to validate future requests. The salted HMAC value cannot be used to derive the value of the encryption key or to decrypt the contents of the encrypted object. That means if you lose the encryption key, you lose the object. - -S3 Replication supports objects that are encrypted with SSE-C. For more information about replicating encrypted objects, see [Replicating encrypted objects (SSE-S3, SSE-KMS, DSSE-KMS, SSE-C)](./replication-config-for-kms-objects.html). - -For more information about SSE-C, see the following topics. - -###### Topics - - * SSE-C overview - - * Requiring and restricting SSE-C - - * Presigned URLs and SSE-C - - * Specifying server-side encryption with customer-provided keys (SSE-C) +Most modern use cases in Amazon S3 no longer use SSE-C because it lacks the flexibility of server-side encryption with Amazon S3 managed keys (SSE-S3) or server-side encryption with AWS KMS keys (SSE-KMS). SSE-C's requirement to provide the encryption key each time you interact with your SSE-C encrypted data makes it impractical to share your SSE-C key with other users, roles, or AWS services who read data from your S3 buckets in order to operate on your data. Due to the widespread support for SSE-KMS across AWS, most modern workloads do not use SSE-C encryption because it lacks the flexibility of SSE-KMS. To learn more about SSE-KMS, see [Using server-side encryption with AWS KMS keys (SSE-KMS)](./UsingKMSEncryption.html). @@ -32,0 +13 @@ For more information about SSE-C, see the following topics. +If you want to prevent SSE-C encryption from being used for objects written to your bucket, you can block SSE-C encryption when changing your bucket's default encryption configuration. When SSE-C is blocked for a general purpose bucket, any `PutObject`, `CopyObject`, `PostObject`, Multipart Upload or replication requests that specify SSE-C encryption will be rejected with an `HTTP 403 AccessDenied` error. To learn more about blocking SSE-C, see [Blocking or unblocking SSE-C for a general purpose bucket](./blocking-unblocking-s3-c-encryption-gpb.html). @@ -34,7 +15 @@ For more information about SSE-C, see the following topics. - - -## SSE-C overview - -This section provides an overview of SSE-C. When using SSE-C, keep the following considerations in mind. - - * You must use HTTPS. +There are no additional charges for using SSE-C. However, requests to configure and use SSE-C incur standard Amazon S3 request charges. For information about pricing, see [Amazon S3 pricing](https://aws.amazon.com/s3/pricing/). @@ -44 +19 @@ This section provides an overview of SSE-C. When using SSE-C, keep the following -Amazon S3 rejects any requests made over HTTP when using SSE-C. For security considerations, we recommend that you consider any key that you erroneously send over HTTP to be compromised. Discard the key and rotate as appropriate. +Starting in April 2026, AWS will disable server-side encryption with customer-provided keys (SSE-C) for all new buckets. In addition, SSE-C encryption will be disabled for all existing buckets in AWS accounts that do not have any SSE-C encrypted data. With these changes, the few applications that need SSE-C encryption must deliberately enable the use SSE-C via the [PutBucketEncryption](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketEncryption.html) API after creating the bucket. In these cases, you might need to update automation scripts, CloudFormation templates, or other infrastructure configuration tools to configure these settings. For more information, see the [AWS Storage Blog post](https://aws.amazon.com/blogs/storage/advanced-notice-amazon-s3-to-disable-the-use-of-sse-c-encryption-by-default-for-all-new-buckets-and-select-existing-buckets-in-april-2026/). @@ -46 +21 @@ Amazon S3 rejects any requests made over HTTP when using SSE-C. For security con - * The entity tag (ETag) in the response is not the MD5 hash of the object data. +## Considerations before using SSE-C @@ -48 +23 @@ Amazon S3 rejects any requests made over HTTP when using SSE-C. For security con - * You manage a mapping of which encryption key was used to encrypt which object. Amazon S3 does not store encryption keys. You are responsible for tracking which encryption key you provided for which object. + * S3 never stores the encryption key when you use SSE-C. You must supply the encryption key every time you want anyone to download your SSE-C encrypted data from S3. @@ -50 +25 @@ Amazon S3 rejects any requests made over HTTP when using SSE-C. For security con - * If your bucket is versioning-enabled, each object version that you upload by using this feature can have its own encryption key. You are responsible for tracking which encryption key was used for which object version. + * You manage a mapping of which encryption key was used to encrypt which object. You are responsible for tracking which encryption key you provided for which object. That also means if you lose the encryption key, you lose the object. @@ -54,80 +29 @@ Amazon S3 rejects any requests made over HTTP when using SSE-C. For security con -###### Warning - -If you lose the encryption key, any `GET` request for an object without its encryption key fails, and you lose the object. - - - - -## Requiring and restricting SSE-C - -To require SSE-C for all objects in a particular Amazon S3 bucket, you can use a bucket policy. - -For example, the following bucket policy denies upload object (`s3:PutObject`) permissions for all requests that don't include the `x-amz-server-side-encryption-customer-algorithm` header requesting SSE-C. - -JSON - - -**** - - - - { - "Version":"2012-10-17", - "Id": "PutObjectPolicy", - "Statement": [ - { - "Sid": "RequireSSECObjectUploads", - "Effect": "Deny", - "Principal": "*", - "Action": "s3:PutObject", - "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", - "Condition": { - "Null": { - "s3:x-amz-server-side-encryption-customer-algorithm": "true" - } - } - } - ] - } - - -You can also use a policy to restrict server-side encryption of all objects in a particular Amazon S3 bucket. For example, the following bucket policy denies the upload object (`s3:PutObject`) permission to everyone if the request includes the `x-amz-server-side-encryption-customer-algorithm` header requesting SSE-C. - -JSON - - -**** - - - - { - "Version":"2012-10-17", - "Id": "PutObjectPolicy", - "Statement": [ - { - "Sid": "RestrictSSECObjectUploads", - "Effect": "Deny", - "Principal": "*", - "Action": "s3:PutObject", - "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", - "Condition": { - "Null": { - "s3:x-amz-server-side-encryption-customer-algorithm": "false" - } - } - } - ] - } - - -###### Important - -If you use a bucket policy to require SSE-C on `s3:PutObject`, you must include the `x-amz-server-side-encryption-customer-algorithm` header in all multipart upload requests (CreateMultipartUpload, UploadPart, and CompleteMultipartUpload). - -## Presigned URLs and SSE-C - -You can generate a presigned URL that can be used for operations such as uploading a new object, retrieving an existing object, or retrieving object metadata. Presigned URLs support SSE-C as follows: - - * When creating a presigned URL, you must specify the algorithm by using the `x-amz-server-side-encryption-customer-algorithm` header in the signature calculation. - - * When using the presigned URL to upload a new object, retrieve an existing object, or retrieve only object metadata, you must provide all the encryption headers in your client application's request. + * This design can make it difficult to share your SSE-C key with other users, roles, or AWS services you to operate on your data. Due to the widespread support for SSE-KMS across AWS, most modern workloads do not use SSE-C because it lacks the flexibility of SSE-KMS. To learn more about SSE-KMS, see [Using server-side encryption with AWS KMS keys (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html). @@ -135 +31 @@ You can generate a presigned URL that can be used for operations such as uploadi -###### Note + * This means that objects encrypted with SSE-C cannot be natively decrypted by AWS managed services. @@ -137 +33 @@ You can generate a presigned URL that can be used for operations such as uploadi -For non-SSE-C objects, you can generate a presigned URL and directly paste that URL into a browser to access the data. + * You must use HTTPS when specifying SSE-C headers on your requests. @@ -139 +35 @@ For non-SSE-C objects, you can generate a presigned URL and directly paste that -However, you cannot do this for SSE-C objects, because in addition to the presigned URL, you also must include HTTP headers that are specific to SSE-C objects. Therefore, you can use presigned URLs for SSE-C objects only programmatically. + * Amazon S3 rejects any requests made over HTTP when using SSE-C. For security considerations, we recommend that you consider any key that you erroneously send over HTTP to be compromised. Discard the key and rotate as appropriate. @@ -140,0 +37 @@ However, you cannot do this for SSE-C objects, because in addition to the presig + * If your bucket is versioning-enabled, each object version that you upload can have its own encryption key. You are responsible for tracking which encryption key was used for which object version. @@ -141,0 +39 @@ However, you cannot do this for SSE-C objects, because in addition to the presig + * SSE-C is not supported in the Amazon S3 Console. You cannot use the Amazon S3 console to upload an object and specify SSE-C encryption. You also cannot use the console to update (for example, change the storage class or add metadata) an existing object stored using SSE-C. @@ -144 +41,0 @@ However, you cannot do this for SSE-C objects, because in addition to the presig -For more information about presigned URLs, see [Download and upload objects with presigned URLs](./using-presigned-url.html). @@ -146 +42,0 @@ For more information about presigned URLs, see [Download and upload objects with -## Specifying server-side encryption with customer-provided keys (SSE-C) @@ -148,367 +44 @@ For more information about presigned URLs, see [Download and upload objects with -At the time of object creation with the REST API, you can specify server-side encryption with customer-provided keys (SSE-C). When you use SSE-C, you must provide encryption key information using the following request headers. - -Name | Description ----|--- -`x-amz-server-side-encryption-customer-algorithm` | Use this header to specify the encryption algorithm. The header value must be `AES256`. -`x-amz-server-side-encryption-customer-key` | Use this header to provide the 256-bit, base64-encoded encryption key for Amazon S3 to use to encrypt or decrypt your data. -`x-amz-server-side-encryption-customer-key-MD5` | Use this header to provide the base64-encoded 128-bit MD5 digest of the encryption key according to [RFC 1321](http://tools.ietf.org/html/rfc1321). Amazon S3 uses this header for a message integrity check to ensure that the encryption key was transmitted without error. - -You can use AWS SDK wrapper libraries to add these headers to your request. If you need to, you can make the Amazon S3 REST API calls directly in your application. - -###### Note - -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. - -#### Amazon S3 rest APIs that support SSE-C - -The following Amazon S3 APIs support server-side encryption with customer-provided encryption keys (SSE-C). - - * **GET operation** – When retrieving objects using the GET API (see [GET Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGET.html)), you can specify the request headers. - - * **HEAD operation** – To retrieve object metadata using the HEAD API (see [HEAD Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectHEAD.html)), you can specify these request headers. - - * **PUT operation** – When uploading data using the PUT Object API (see [PUT Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html)), you can specify these request headers. - - * **Multipart Upload** – When uploading large objects using the multipart upload API, you can specify these headers. You specify these headers in the initiate request (see [Initiate Multipart Upload](https://docs.aws.amazon.com/AmazonS3/latest/API/mpUploadInitiate.html)) and each subsequent part upload request (see [Upload Part](https://docs.aws.amazon.com/AmazonS3/latest/API/mpUploadUploadPart.html) or [Upload Part - Copy](https://docs.aws.amazon.com/AmazonS3/latest/API/mpUploadUploadPartCopy.html)). For each part upload request, the encryption information must be the same as what you provided in the initiate multipart upload request. - - * **POST operation** – When using a POST operation to upload an object (see [POST Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPOST.html)), instead of the request headers, you provide the same information in the form fields. - - * **Copy operation** – When you copy an object (see [PUT Object - Copy](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html)), you have both a source object and a target object: - - * If you want the target object encrypted using server-side encryption with AWS managed keys, you must provide the `x-amz-server-side-encryption` request header. - - * If you want the target object encrypted using SSE-C, you must provide encryption information using the three headers described in the preceding table. - - * If the source object is encrypted using SSE-C, you must provide encryption key information using the following headers so that Amazon S3 can decrypt the object for copying. - -Name | Description ----|--- -`x-amz-copy-source-server-side-encryption-customer-algorithm` | Include this header to specify the algorithm Amazon S3 should use to decrypt the source object. This value must be `AES256`. -`x-amz-copy-source-server-side-encryption-customer-key` | Include this header to provide the base64-encoded encryption key for Amazon S3 to use to decrypt the source object. This encryption key must be the one that you provided Amazon S3 when you created the source object. Otherwise, Amazon S3 cannot decrypt the object. -`x-amz-copy-source-server-side-encryption-customer-key-MD5` | Include this header to provide the base64-encoded 128-bit MD5 digest of the encryption key according to [RFC 1321](http://tools.ietf.org/html/rfc1321). - - -