Identify source of TLS 1.0 or TLS 1.1 connections to oceansmap s3 bucket

[nguyandy]

Need to figure out where these TLS 1.0/1.1 requests are coming from so we can make updates where needed.

S3 bucket: https://s3.console.aws.amazon.com/s3/buckets/oceansmap

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.

As of June 28, 2023, we have begun deploying updates to the TLS configuration for all AWS API endpoints to a minimum of version TLS 1.2 even if you still have connections using these versions. These deployments will complete by no later than December 31, 2023. This update removes the ability to use TLS versions 1.0 and 1.1 with all AWS APIs in all AWS Regions [1].

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 per the documented this Knowledge Center article [7]

Connections details will be in the following format:
Region | Bucket name(s) | APIAction | TLSVersion | NumCalls | UserAgent
us-east-1 | oceansmap | REST.GET.BUCKET | TLSv1 | 1 | []

[pavaniankam92]

I have followed the AWS step to check whether any client using s3 bucket connecting through TLSV1 or TLSv1.1

• There are no calls made to s3 using TLSv1 or TLSv1.0 From last 14 months, which suggest none of the client is using Old TLSv1 protocol to connect S3.
• TLS1,0 and TLSv1.1 query together with TLSv1.2 to demonstrate the query is working fine (as we are getting good number of calls for TLS V1.2)
• Also, there are no violations in AWS Health dashboard, AWS also check for non -complaint TLS calls and will be displayed in Health dashboard.

Next steps
If we feel that these findings are still valid, then we can plan to apply strict bucket policy to only allow TLSv1.2 requests to S3 Bucket by adding new configs in bucket policy. I would though need permissions to configure this policy, but we need to see if any applications might break if for some reason there are still any clients accessing TLSv1 &1.1.
Please review. @nguyandy

[nguyandy]

Thanks for looking into this @pavaniankam92

Great that we haven't picked up any TLSv1.0/1.1 calls, I wonder if the alert from AWS is just a false alarm.
Since we haven't seen any TLSv1.0/1.1 requests, I think it would relatively be safe to enforce strict bucket policy.

We do have lots of projects in the wild that are accessing the oceansmap s3 bucket. Instead of checking to see if any applications break, can I assume that rejected calls are logged so that we are able to track down problematic sites?

[pavaniankam92]

@nguyandy Yes rejected calls should be logged as well. As we know that there are no calls being made on TLS 1.0/1.1 , can we go ahead and implement/enforce bucket policy with TLS 1.2? Please let me know and we would need to see if there can be a downtime to set this up and i will also come up with a roll back if there are any issues.

[nguyandy]

Let's do it, preferably in the evening.
Can we setup alerts if we get a call being made on TLS 1.0/1.1?

[pavaniankam92]

Yes, alerts can be configured but I will need to explore the CloudTrail monitoring.

[pavaniankam92]

Currently testing the cloudtrail logs monitoring through cloudwatch alarms, Used TLS v1.2 for testing alarms , if this works for TLS v1.2 then will put alarms for tLSv1.0 an d1.1 and through these alarms we will be notified through email for any TLS v1,0 and v1.1 calls.

https://us-east-1.console.aws.amazon.com/cloudwatch/home?region=us-east-1#alarmsV2:alarm/TLSV1CheckAlarm?

[pavaniankam92]

I have implemented the CloudWatch alarms for TLS v1.0 and TLS v1.1.
Next action item is to disable TLS v1.0 and TLS v1.1 from oceansmap bucket policy.