4

When we upload data to S3, is it protected in transit by default (via HTTPS maybe)?

I found this article which, if I understand correctly, states S3 does not use HTTPS:

Amazon Simple Storage Service: You can still use HTTP with Amazon S3 and securely make authenticated requests. The service uses a different secure signing protocol.

Should we in this case protect the data in transit with Client-Side Encryption?

Aditya
  • 1,693
  • 19
  • 27
Ioanna
  • 1,311
  • 2
  • 23
  • 36

2 Answers2

5

Quoting from the Security section of the S3 FAQs:

You can securely upload/download your data to Amazon S3 via SSL endpoints using the HTTPS protocol.

If you're using the https:// endpoint for S3, then your data in transit should be encrypted properly. The quote that you referred to in the question means that it's also possible to access S3 using http:// protocol, in which case the data wouldn't be encrypted in transit. See this related question.

If you were asking specifically about whether AWS CLI encrypts data in transit, then the answer is yes. See this question.

Also, please note that the primary purpose of using client-side encryption would be to encrypt data at rest, and to use an encryption algorithm of your own choosing. If you use client-side encryption but still use the http:// endpoint, your communication over the wire would still be unencrypted, technically speaking, because the cyphertexts being passed over the wire could be extracted by an attacker for analysis.

Update:

  1. If you were asking specifically about AWS Java SDK, the default protocol is again https. Quoting from javadocs for AWS Java SDK:

By default, all service endpoints in all regions use the https protocol. To use http instead, specify it in the ClientConfiguration supplied at construction.

And from the javadocs for ClientConfiguration.getProtocol:

The default configuration is to use HTTPS for all requests for increased security.

  1. Client-side/server-side encryption's primary purpose is to secure data at rest. If anyone was to break open your cloud provider's data center somehow and steal the disks that had your data, you're making it difficult for them to get hold of your data in plaintext by encrypting it either client-side/server-side. Doing it client-side gives you the benefit of having more control on the encryption algorithm with the seemingly additional side-effect of your data not being transmitted in plaintext over the wire. However, the communication channel itself is not encrypted. If you were using a weak encryption algorithm for example, an attacker could still sniff the encrypted data over the wire and decrypt it. Also, it's important to know that using SSL means:
    • You as the client can be sure you're talking to AWS
    • Your communication with AWS is encrypted, so others can't intercept it
    • You have verification that the message received is the same as the message sent

In essence, you definitely want to use SSL irrespective of whether you want to use client-side encryption or not.

Aditya
  • 1,693
  • 19
  • 27
  • Thank you for the details and links, Aditya! I was wondering if AWS uses SSL by default (like for the CLI) also when the AWS API is used (e.g. the Java API). – Ioanna Jun 13 '17 at 07:36
  • I believe the Client-Side Encryption is meant to protect data in transit (it is encrypted *before* being transmitted) and the Server-Side Encryption protects it at rest (stores it encrypted). – Ioanna Jun 13 '17 at 07:37
  • Updated my answer. – Aditya Jun 13 '17 at 14:23
4

The article you cited is obsolete. It was originally written in 2008, and apparently when updated in 2015, some of the outdated information was left in place.

The version refers to the particular algorithm for signing the request. These AWS services have deprecated the older, less-secure methods (signature versions 0 and 1) and will no longer allow them after September 2009.

Indeed, versions 0 and 1 are not supported.

A few AWS services don't support signature version 2:

Amazon Simple Storage Service: You can still use HTTP with Amazon S3 and securely make authenticated requests. The service uses a different secure signing protocol.

This is also inaccurate. S3 supports signature version 2 in all regions where signature version 2 was deployed. Regions launched in 2014 or later do not support V2 at all, they require Signature Version 4, and in those regions, S3 also requires Signature Version 4.

Importantly, though, none of this has anything at all to do with HTTPS.

From the same document:

Most AWS services accept HTTPS requests, including:

...

Amazon Simple Storage Service

Okay, so, let's revisit this line:

The service uses a different secure signing protocol.

This statement is not about encryption, or security of the payload. This is a statement about the secuity of the request authentication and authorization process -- its resistance to forgery and reverse-engineering -- whether or not the request is sent encrypted.

HTTPS is supported by S3, to protect data in transit.

Community
  • 1
  • 1
Michael - sqlbot
  • 169,571
  • 25
  • 353
  • 427
  • 1
    Thank you, Michael, for answering every point in my question, and for pointing out where it made no sense... I'm going to continue with probably another nonsense question: do you know whether HTTPS is used by default when calling the S3 API (e.g. from Java)? Or if not, how it could be enabled? – Ioanna Jun 13 '17 at 07:39