- Issue created by @ziyad_vp
- 🇺🇸United States alrueden Madison, Wisconsin
We've gotten a couple emails like this too. Apparently this was announced last summer and the deadline is June 28th, 2023. Here's Amazon's blog post about it.
Does anyone know if the 7.x-3.x branch of this module is sufficient to meet the new TLS requirement? If I understand correctly, newer versions of the AWS SDK should just work with TLS 1.2...but it's not clear to me whether v3.156.0 (where the module is stuck) is good enough.
- 🇺🇸United States cmlara
I don't work on the 7.x branch, and especially not with the AWS SDK 2.x, so I'm unable to say this is 100% accurate. I will note that our 7.x-2.x branch is EOL, it does use a much older version of Guzzle to interface with the server so its possible that its more restrictive than the 3.x version.
Its my understanding that (at least for the AWS SDK 3) the majority of this is controlled by forces outside of Drupal, S3FS, the AWS SDK, and even Guzzle
It is my understanding that its more commonly a function of your server, especially its TLS libraries (openSSL or similar) and what they support, especially in 3.x where the SDK via guzzle normally use fopen() connections which depend upon how PHP is compiled as it is the PHP binary making the connection and handling the TLS session with the Guzzle Client and AWS SDK only seeing the unencrypted data.
The best way to answer this question is, as the AWS blog post calls out, to setup server access logs (if not already done) and review them for connection details. If your deployment supports TLS 1.2 it will already be using it and show up as such in the logs. If your deployment does not support TLS 1.2 this will also show up in the logs allowing you to start investigating your server.