Insecure TLS versions on designsystem.eclipse-foundation.org

From the security ML:

Summary

The server at designsystem.eclipse-foundation.org is configured to support the TLS 1.0 protocol with the cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. This combination is considered weak due to vulnerabilities in both the protocol and the cipher suite.

---

Technical Details

• TLS Version: TLS 1.0
• Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS 1.0 is deprecated and vulnerable to attacks like BEAST. The use of AES in CBC mode is susceptible to padding oracle attacks, and SHA-1 is considered weak and has been deprecated in favor of SHA-256 or stronger hash functions.

---

Risks

• Security Vulnerabilities: Increased risk of data breaches and unauthorized access due to weak encryption.
• Compliance Issues: Potential violations of industry standards and regulations requiring strong encryption.
• Performance Concerns: Possible service interruptions or degraded performance due to the use of outdated protocols and cipher suites.

---

Recommendations

1. Upgrade to TLS 1.2 or Higher: Configure the server to support at least TLS 1.2, as it offers stronger security features and is widely supported.
2. Disable TLS 1.0 and 1.1: Disable support for TLS 1.0 and 1.1 on the server to prevent their use.
3. Configure Strong Cipher Suites: Implement strong cipher suites such as:
   • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
   • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
4. Regularly Review and Update Security Configurations: Periodically audit and update SSL/TLS configurations to align with current security best practices and compliance requirements.

---

Steps to Reproduce

To verify the supported cipher suites for the domain, you can use the following OpenSSL command:

openssl s_client -connect designsystem.eclipse-foundation.org:443 -cipher 'ALL:eNULL' -showcerts

This command will display the certificate and the supported cipher suites. Look for the presence of TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the use of TLS 1.0.

added From_ML vulnerabilityconfirmed labels

Greetings @cguindon could you please take a look at this and other Google Sites websites regarding their security protections like TLS configuration, security headers and HSTS (RFC 6797 compliance)? Thank you!

@tiagolucas — I do have access to the Google Site itself, but I’m not a Google Workspace admin, so I don’t have access to domain configuration settings for these sites.

Could you please add @mward on this ticket? He should be able to help here.

Understood. Assigned this to @mward , had the wrong impression regarding the Google Sites accesses.

I don't see(and cannot find) a way to alter the TLS settings for Google sites.

What I can tell you is that based on it's sharing settings someone needs to be part of our organisation before they can access the site.

Greetings @mward can we please open a ticket at Google support to disable TLSv1 and TLSv1.1 on the aforementioned domains?

I started a support conversation with Google, but don't get your hopes up.

I'm pretty certain I spent 30ish minutes 'talking' to 2 different bots(or reverse centaurs) that failed to understand the request. The last update was that they needed to get (yet another) specialist in the loop to try and resolve this.

Here's the core of Googles followup

Google Sites automatically handle TLS security. Google's infrastructure prioritizes the highest TLS version supported by both the user's browser and Google's servers. This means modern browsers will already use TLS 1.2 or 1.3 when connecting to your sites.

While Google's infrastructure supports older TLS versions (1.0 and 1.1) for broader compatibility, your sites will default to the most secure version available to your users. There are no manual settings within Google Sites to disable specific TLS versions.

So I'm going to close this as 'cantfix'.

Just a note here that a MITM attack is a valid concern for websites allowing TLS 1.0. That answer from Google is not acceptable by today's standards. I don't know how to react.

What I’m understanding is that there isn’t much @mward can do to resolve this. Unless I’m missing something, our only options are to either accept the risk or have the security team recommend that we stop using Google Sites if the risk is deemed too high.

@mbarbero WDYT?

A few things to consider. I’m aware of two Google Sites currently in use:

designsystem.eclipse-foundation.org: My team is actively working with the design team to migrate its content to our Storybook app, as part of an effort to consolidate design and code documentation: eclipsefdn/it/webdev/solstice-assets#471

However, it's not clear to me yet if the design team plan to keep the site when most of the content is migrated or if they plan to keep it for something else.

Staff resource site: This site is still actively used and needed: https://sites.google.com/eclipse-foundation.org/ef-staff-resource-website

That answer from Google is not acceptable by today's standards. I don't know how to react.

I agree, but we will accept the risk for now, especially since @cguindon's team is transitioning to another solution for this site.

@tiagolucas, please respond to the reporter with the following points:

• We acknowledge that this is not a best practice.
• The hosting platform does not allow us to raise the minimum version to current standards.
• We are in the process of migrating the service to a new hosting platform.
• Given the static nature of the site and the absence of any PII, we will not take further security action, as the migration is already underway.

Once done, please re-close the ticket.

I agree, but we will accept the risk for now, especially since @cguindon's team is transitioning to another solution for this site.

As far as I know, there are currently no plans to migrate or deprecate https://sites.google.com/eclipse-foundation.org/ef-staff-resource-website which is another google site.

I'm also not sure if the Marketing team intends to keep designsystem.eclipse-foundation.org active after the transition.

This raises a broader question: should we be telling staff to stop using Google Sites altogether?

I care less about https://sites.google.com/eclipse-foundation.org/ef-staff-resource-website, as it's behind authentication and only accessible to staff as such.

This raises a broader question: should we be telling staff to stop using Google Sites altogether?

Given Google’s current posture, I would discourage its use for static or non-PII content, and outright disallow it for anything more sensitive.

We do have PII content referenced on the staff website; however, at a glance, it looks like all personal data is stored in Google Docs or Sheets, not directly on the site itself.

@tiagolucas — Can you confirm if this vulnerability only affects sites.google.com and doesn’t impact other services like docs.google.com?

Or perhaps it only affect google sites with a custom domains?

@cguindon Your suspicions were completely on target. As far as I can see all the *.google.com domains accept TLSv1 connections.

assigned to @cguindon

assigned to @mward

closed

reopened