I am after a sanity check to ensure that what I have been asked to investigate is actually achievable.

I am currently building out a Centos7 server, which will be used to deliver files to AWS S3, either via AWS CLI or Boto3 api calls. Externally, this is the only job this server will do.

I have been asked to "ensure that only TLS V1.2 or higher is used" when communicating to AWS.

From my Linux server side, is it at all possible to setup this restriction?


  • You should descrbe how you deliver those files. Then we could answer your questions. Else there are too many possibilities. – Nils Nov 27 '19 at 12:59
  • @Nils , I am using client-level calls via Boto3, specifically client('s3'), specifically using the commands list_objects_v2(Bucket=bucket, Prefix=object_key) and put_object(Bucket=bucket, Body=body, Tagging=tags, ContentMD5=md5_str) – Ash Nov 29 '19 at 3:40
  • @Nils. I am also of the understanding that using `client('s3') defaults to using SSL and latest versions of API. If there is a way to make this call more robust, I am all for it – Ash Nov 29 '19 at 3:47

See issue #3688 in aws-cli GitHub.

The original issue from timwins in October 2018:

PCI DSS requires "strong encryption" for non-console administrative access. This means TLS 1.1 or greater per the PCI SSC guidance. According to the Python documentation (https://docs.python.org/2/library/ssl.html) the server sets the minimum SSL/TLS requirements - I assume with the ssl.wrap_socket parameters and the server certificate. It seems likely the Protocol parameter is set to SSLv23. Is that true? This allows SSLv3 and TLS v1 to be negotiated.

Can this be forced to TLSv1.1 or TLSv1.2 by a client configuration?

Response from JordonPhillips:

The client and server will always negotiate the latest version of TLS. All AWS services support TLS 1.2, so as long as you are using a version of python compiled against a recent version of openssl you should be good. That said there's not currently a way to black list old tls versions, so you will need to make sure that any non-aws endpoints you may be configuring support the latest versions.

JordonPhillips also marked this issue as a feature request in November 2018, so hopefully there might be further development at some future time.

Conclusion by timwins:

Thanks. Then we can tell customers needing to meet PCI DSS compliance that they are responsible for using the most current CLI, or at least version 3.6.0(?) of Python.

It looks like the combination of Python 3.7 or above and OpenSSL 1.1.0g or above will provide a SSLContext.minimum_version that will finally allow programmatically specifying a restriction like "TLS 1.2 or above" in Python in a clean, forward-compatible way.

Before that, it looks like the available options only allowed specifying options like "TLS 1.2 only" which is not ideal if you want an open-ended restriction like "TLS 1.2 or better", potentially allowing the underlying layers to support versions of TLS the aws-cli is not yet specifically aware of.

Maybe this will enable the development of this requested feature in aws-cli?

  • Firstly, sorry if you got notifications for my two previous (now deleted) comments 🙂. So, to paraphrase, I should have no current problems consistently negotiating TLS 1.2 with my current setup. For any future compatibility with newer versions of TLS, it would be dependent on the feature request in the above GitHub issue? Cheers – Ash Nov 14 '19 at 0:21
  • It looks like implementing a minimum TLS level limit in Python 3.6 or below and/or OpenSSL < 1.1.0g would have required trying to establish a connection with each allowed TLS level separately, and so the aws-cli programmers chose to not implement a way to restrict TLS level in configuration, to maintain the ability to automatically use whatever is the latest TLS level supported by the underlying OpenSSL library version. With the versions listed above, it becomes possible to go forward with the feature request and still maintain the ability to automatically use the latest supported TLS level. – telcoM Nov 14 '19 at 6:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.