Our website is running Sharetribe Go. We are hosting our production environment in AWS EC2, with database on RDS and images on S3.
Recently we received this email from AWS:
We have identified TLS 1.0 or TLS 1.1 connections to Amazon Simple Storage Service (Amazon S3) objects hosted in your account, which must be immediately updated for these connections to maintain their access to your S3 objects. Please update your client software as soon as possible to use TLS 1.2 or higher to avoid an availability impact. We recommend considering the time needed to verify your changes in a staging environment before introducing them into production.
Is this something we have to do within our Linux server environment? Or we have to update the Sharetribe code? Anybody with insights?
We are getting the same message on all our accounts:
Hello,
We are reaching out because there are TLS 1.0 or TLS 1.1 connections to Amazon Simple Storage Service (Amazon S3) objects hosted in your account. As AWS is updating the TLS configuration for all AWS API endpoints to a minimum of version TLS 1.2 [1], you must take action as soon as possible for these connections to maintain their access to your S3 objects.
What actions can I take to maintain access?
To avoid potential interruption, you must update all client software accessing your Amazon S3 objects using TLS 1.0 or 1.1, to use TLS 1.2 or higher. If you are unable or would prefer to not update all impacted clients, we recommend replacing direct client access to the S3 objects with use of a proxy, such as an Amazon CloudFront distribution. This will allow clients to access your S3 objects via Amazon CloudFront using any TLS version you choose to allow. Amazon CloudFront will forward the calls to your S3 objects using TLS 1.2 or higher. For more guidance for how to setup your CloudFront distribution to front your S3 object access, please review this Knowledge Center article [2].
How can I determine the client(s) I need to update?
We have provided the affected S3 bucket(s) in your account following this messaging. In order to gather additional information about the affected objects and user agents performing these calls, we recommend enabling Amazon CloudTrail data events on the affected S3 bucket(s) [3] [4]. The information contained in the S3 data events will help you pinpoint your client software that is responsible for using TLS 1.0 or TLS 1.1, so you may update it accordingly. Additionally, our related AWS Security blog post [1] provides information on how you may use TLS information in the CloudTrail tlsDetails field. Please note there is an associated cost for enabling CloudTrail data events, please see the CloudTrail pricing page for more detail [5]. Another alternative is to use Amazon S3 server-access logs, see the S3 Logging options page for more details and pricing information [6].
How can I enforce connections to my bucket(s) be over TLSv1.2 and above?
As a best practice, and to prepare for our enforcement of TLS 1.2 or higher, we recommend you proactively enforce a minimum of TLS 1.2 directly on all of your shared S3 bucket(s). You may do this by applying a bucket policy with the s3:TlsVersion condition key as documented in this Knowledge Center article [7]
If you need further guidance or assistance, please contact AWS Support [8] or your Technical Account Manager.
Please see the following for S3 buckets in which object-level calls were made over TLS 1.0 or TLS 1.1 connections between April 24, 2023 and May 05, 2023 (the UserAgent may be truncated due to a limit in the number of characters that can be displayed):
As far as I understand the notification, this is related to calls from old browsers (images uploaded directly to S3 from the browser, or old browsers downloading some public object).
What this means is that some old browsers may stop working and not loading resources from your marketplace website. This is not related to the code in Go, and is purely connected to your hosting service.
In the hosted version of Sharetribe Go, TLS v1.1 and earlier were dropped long ago (we’ve only accepted 1.2+ for a while and we haven’t heard any complaints or reports from our customers. So, it is likely that this won’t create any issue for your users, too.
One thing you could do already would be to enforce this on your S3 bucket(s), by denying access over TLS <1.2. If you hear from your users that they experience some challenges when browsing, you could then advise them to upgrade to a recent browser or browser version, or find alternative ways to support them.
Thanks for the insights Thomas. How long ago do you mean by “long time ago”. Because our PJ branched out from ST code around 2019.
So basically we don’t have to update ST code, and we can enforce TLS>=1.2 in S3 buckets, but that’s optional, right?
Our own schedule on this, with the hosted version of Sharetribe Go, does not matter at all as, indeed, this doesn’t connect to any code change. This is something dependent on your own hosting service and settings.
You don’t have to enforce TLS >= 1.2, no. But AWS will do it soon. Doing it already by yourself is a great way to notice potential impacts already, and have enough time to react and decide on an alternative if that proves key for your users. Our experience is that this shouldn’t have any serious impact.