Skip to main content

🛡️ Google HTTPS or SSL Proxy Load Balancer permits SSL policies with weak cipher suites🟢⚪

  • Contextual name: 🛡️ HTTPS or SSL Proxy Load Balancer permits SSL policies with weak cipher suites🟢⚪
  • ID: /ce/ca/google/load-balancing/load-balancer-ssl-policies-cipher-suites
  • Tags:
  • Policy Type: COMPLIANCE_POLICY
  • Policy Categories: SECURITY

Similar Policies​

Description​

Open File

Description​

Secure Sockets Layer (SSL) policies determine what port Transport Layer Security (TLS) features clients are permitted to use when connecting to load balancers. To prevent usage of insecure features, SSL policies should use (a) at least TLS 1.2 with the MODERN profile; or (b) the RESTRICTED profile, because it effectively requires clients to use TLS 1.2 regardless of the chosen minimum TLS version; or (3) a CUSTOM profile that does not support any of the following features:

TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

Rationale​

Load balancers are used to efficiently distribute traffic across multiple servers. Both SSL proxy and HTTPS load balancers are external load balancers, meaning they distribute traffic from the Internet to a GCP network. GCP customers can configure load balancer SSL policies with a minimum TLS version (1.0, 1.1, or 1.2) that clients can use to establish a connection, along with a profile (Compatible, Modern, Restricted, or Custom) that specifies permissible cipher suites. To comply with users using outdated protocols, GCP load balancers can be configured to permit insecure cipher suites. In fact, the GCP default SSL policy uses a minimum TLS version of 1.0 and a Compatible profile, which allows the widest range of insecure cipher suites. As a result, it is easy for customers to configure a load balancer without even knowing that they are permitting outdated cipher suites.

... see more

Remediation​

Open File

Remediation​

From Google Cloud Console​

If the TargetSSLProxy or TargetHttpsProxy does not have an SSL policy configured, create a new SSL policy. Otherwise, modify the existing insecure policy.

  1. Navigate to the SSL Policies page by visiting: https://console.cloud.google.com/net-security/sslpolicies

  2. Click on the name of the insecure policy to go to its SSL policy details page.

  3. Click EDIT.

  4. Set Minimum TLS version to TLS 1.2.

  5. Set Profile to Modern or Restricted.

  6. Alternatively, if teh user selects the profile Custom, make sure that the following features are disabled:

         TLS_RSA_WITH_AES_128_GCM_SHA256
         TLS_RSA_WITH_AES_256_GCM_SHA384
         TLS_RSA_WITH_AES_128_CBC_SHA
         TLS_RSA_WITH_AES_256_CBC_SHA
         TLS_RSA_WITH_3DES_EDE_CBC_SHA

From Google Cloud CLI​

  1. For each insecure SSL policy, update it to use secure cyphers:

         gcloud compute ssl-policies update NAME [--profile COMPATIBLE|MODERN|RESTRICTED|CUSTOM] --min-tls-version 1.2 [--custom-features FEATURES]

... see more

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 CIS GCP v1.2.0 → 💼 3.9 Ensure no HTTPS or SSL proxy load balancers permit SSL policies with weak cipher suites - Level 1 (Manual)1no data
💼 CIS GCP v1.3.0 → 💼 3.9 Ensure No HTTPS or SSL Proxy Load Balancers Permit SSL Policies With Weak Cipher Suites - Level 1 (Manual)1no data
💼 CIS GCP v2.0.0 → 💼 3.9 Ensure No HTTPS or SSL Proxy Load Balancers Permit SSL Policies With Weak Cipher Suites - Level 1 (Manual)1no data
💼 CIS GCP v3.0.0 → 💼 3.9 Ensure No HTTPS or SSL Proxy Load Balancers Permit SSL Policies With Weak Cipher Suites - Level 1 (Manual)1no data
💼 Cloudaware Framework → 💼 Data Encryption44no data
💼 ISO/IEC 27001:2013 → 💼 A.14.1.3 Protecting application services transactions1015no data
💼 NIST CSF v1.1 → 💼 DE.CM-1: The network is monitored to detect potential cybersecurity events1863no data
💼 NIST CSF v1.1 → 💼 PR.AC-5: Network integrity is protected (e.g., network segregation, network segmentation)1044no data
💼 NIST CSF v1.1 → 💼 PR.DS-2: Data-in-transit is protected1653no data
💼 NIST CSF v1.1 → 💼 PR.DS-5: Protections against data leaks are implemented4791no data
💼 NIST CSF v1.1 → 💼 PR.DS-6: Integrity checking mechanisms are used to verify software, firmware, and information integrity2227no data
💼 NIST CSF v1.1 → 💼 PR.PT-4: Communications and control networks are protected1044no data
💼 NIST CSF v2.0 → 💼 DE.CM-01: Networks and network services are monitored to find potentially adverse events145no data
💼 NIST CSF v2.0 → 💼 DE.CM-09: Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events142no data
💼 NIST CSF v2.0 → 💼 PR.AA-06: Physical access to assets is managed, monitored, and enforced commensurate with risk44no data
💼 NIST CSF v2.0 → 💼 PR.DS-01: The confidentiality, integrity, and availability of data-at-rest are protected148no data
💼 NIST CSF v2.0 → 💼 PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected125no data
💼 NIST CSF v2.0 → 💼 PR.DS-10: The confidentiality, integrity, and availability of data-in-use are protected142no data
💼 NIST CSF v2.0 → 💼 PR.IR-01: Networks and environments are protected from unauthorized logical access and usage95no data
💼 NIST SP 800-53 Revision 4 → 💼 SC-7 BOUNDARY PROTECTION23531no data
💼 PCI DSS v3.2.1 → 💼 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.1822no data
💼 PCI DSS v4.0.1 → 💼 4.2.1 Strong cryptography and security protocols are implemented to safeguard PAN during transmission over open, public networks.222no data
💼 PCI DSS v4.0 → 💼 4.2.1 Strong cryptography and security protocols are implemented to safeguard PAN during transmission over open, public networks.2922no data