I’m looking for guidance regarding a security issue we’re facing with GCP API Gateway.
We’ve set up an API Gateway, but during penetration testing, it was discovered that the gateway is still accepting connections over TLS 1.0 and 1.1. Based on my understanding and review of the documentation, TLS configuration (such as enforcing TLS 1.2 or higher) isn’t exposed for customization in API Gateway – it appears to be fully managed by Google.
Is there any way to restrict or disable older TLS versions (1.0 and 1.1) for API Gateway? Or is this something that can only be addressed by Google internally?
Any suggestions or best practices would be appreciated.
API Gateway is in the process of disallowing older TLS versions (1.0/1.1). New gateways in new locations should already have TLS 1.2+ enforced, existing gateways will be backfilled with the restrictions in the coming weeks. See API Gateway release notes | API Gateway Documentation | Google Cloud
API Gateway endpoints always terminate HTTPS traffic through Google‑managed infrastructure, and the TLS policy is not configurable at the project level. According to the API Gateway and Google Front End (GFE) security documentation, all external HTTPS traffic is served through the same GFE layer that enforces Google’s global TLS policy. GFE currently supports only modern cipher suites and TLS 1.2+ for public endpoints. If your scanner reports TLS 1.0 or 1.1 as accepted, it’s typically reflecting the GFE behavior of returning a handshake rejection rather than a clean block, which some scanners misinterpret as support.
You don’t need to configure anything in API Gateway to disable older TLS versions, and there is no flag or setting to restrict them further. The platform already meets current industry standards for TLS enforcement. If your compliance team requires official confirmation, you can reference the “Google Front End TLS and Cipher Suite Support” and “API Gateway Security Overview” sections in the Cloud documentation, or open a Cloud Support case to obtain a formal attestation for audit purposes.
Thanks for the response. Nevertheless, I used curl and forced the ciphers and the tls version to get an actual connection and just not the scanner response, and I was able to get the content from the portal.
This is about the Integrated Developer Portal (Drupal) hosted on apigee, and not the API Gateway, which does not have this issue.
SSL connection using TLSv1.0 / DES-CBC3-SHA ALPN, server accepted to use http/1.1 < HTTP/1.1 200 OK