Skip to content

Fix Open Match Frontend exposing prohibited TLS cipher suites (3DES, CBC, TLS 1.0/1.1) #75

Description

@jpvelasco

Problem

The Open Match Frontend gRPC endpoint (port 50504) exposes weak TLS cipher suites to the internet, including TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_3DES_EDE_CBC_SHA (vulnerable to the Sweet32 attack, CVE-2016-2183). It also accepts TLS 1.0 and TLS 1.1 connections.

The root cause is that Open Match 1.8.1 is compiled with Go 1.21, which includes these ciphers in its default TLS configuration. The Helm chart provides no mechanism to configure cipher suites, and there is no newer Open Match v1 release (the project is no longer actively maintained). The NLB is configured as TCP passthrough, so the Go binary's weak cipher list is directly exposed to the internet.

Confirmed via nmap --script ssl-enum-ciphers against the frontend pod: 3DES is offered on TLS 1.0, 1.1, and 1.2.

Fix

Change the NLB listener from TCP passthrough to TLS termination using the ELBSecurityPolicy-TLS13-1-2-Res-2021-06 security policy. This policy only offers ECDHE+GCM ciphers on TLS 1.2/1.3 (verified via aws elbv2 describe-ssl-policies). The existing cert-manager certificate (open-match-tls-certmanager) will be reused, no new certificate infrastructure needed.

With TLS terminated at the NLB, the scanner handshakes with the NLB's cipher list rather than the Go binary's. The weak ciphers are never exposed to the internet.

Changes:

  • Update configure-open-match-ingress.sh to create the NLB with TLS listener annotations and the existing certificate
  • Remove the ineffective open_match_tls_hardening terraform resource (GODEBUG=tls3des=0 is not recognized by Go 1.21 binaries)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions