HIGH poodle attackcockroachdb

Poodle Attack in Cockroachdb

How the POODLE Attack Manifests in CockroachDB

The POODLE attack (CVE-2014-3566) exploits the SSLv3 protocol’s use of CBC‑mode cipher suites and a padding oracle to decrypt HTTPS traffic. Although CockroachDB primarily serves its SQL wire protocol, it also exposes an HTTP‑based admin UI and status endpoints (default port 8080). If a CockroachDB node is configured to allow SSLv3 fallback or does not enforce a minimum TLS version, an attacker can force a downgrade to SSLv3 and then perform the POODLE padding‑oracle attack against any HTTP endpoint that the node serves.

In the CockroachDB codebase the TLS configuration lives in pkg/util/tls/tls.go. The function LoadTLSCertificates builds a *tls.Config that is passed to the HTTP server (net/http.Server) and to the gRPC listeners used for inter‑node communication. When the operator does not explicitly set MinVersion, the Go TLS library defaults to accepting SSLv3 (tls.VersionSSL30).

Example of a vulnerable configuration (as might appear in a custom wrapper or when the operator manually edits the generated TLS config):

cfg := &tls.Config{
    Certificates: []tls.Certificate{cert},
    // Intentionally left zero – permits SSLv3
    MinVersion:   0,
}

With MinVersion zero, a network attacker can trigger a version‑rollback handshake, causing the server to negotiate SSLv3 and then leverage the padding oracle to decrypt session cookies, authentication tokens, or any other data sent over the HTTP admin UI.

CockroachDB‑Specific Detection — Using middleBrick

middleBrick performs unauthenticated, black‑box testing of the target’s HTTP surface. When pointed at a CockroachDB admin UI (e.g., https://db‑example.com:8080), it:

  • Attempts a TLS handshake with SSLv3 forced via the TLS_FALLBACK_SCSV mechanism.
  • Checks whether the server completes the handshake and returns a successful HTTP response.
  • If SSLv3 is accepted, middleBrick then sends a series of crafted CBC‑mode payloads to verify the presence of a padding oracle (the classic POODLE test).
  • The finding is reported under the "Encryption" category with a severity of "high" and includes the exact TLS version observed.

Example CLI usage:

middlebrick scan https://db-example.com:8080

The resulting JSON output contains a field similar to:

{
  "checks": [
    {
      "name": "SSLv3 POODLE Vulnerability",
      "severity": "high",
      "description": "Server accepts SSLv3 and is vulnerable to the POODLE padding‑oracle attack (CVE-2014-3566).",
      "remediation": "Enforce TLS 1.2 or higher; disable SSLv3 fallback."
    }
  ]
}

Because middleBrick needs no agents or credentials, it can be run from a developer’s laptop, a CI pipeline, or the middleBrick Dashboard to continuously verify that CockroachDB nodes are not exposing SSLv3.

CockroachDB‑Specific Remediation — Native Configuration

Fixing the POODLE risk in CockroachDB involves ensuring that TLS 1.2 (or higher) is the minimum version accepted by the node’s HTTP and gRPC listeners. CockroachDB provides both command‑line flags and cluster settings to enforce this.

1. Enforce TLS version at startup

When launching a node, specify the --tls-version flag (available since v21.2) to set the minimum TLS version:

cockroach start \
  --certs-dir=${HOME}/cockroach-certs \
  --host=db-node1.internal \
  --http-addr=db-node1.internal:8080 \
  --tls-version=1.2

This flag translates internally to setting MinVersion: tls.VersionTLS12 in the *tls.Config used by both the HTTP server and the intra‑node gRPC connections.

2. Adjust via cluster setting (runtime)

If nodes are already running, you can update the minimum TLS version without restarting:

SET CLUSTER SETTING server.tls_min_version = 'TLS1.2';

To be explicit about disabling SSLv3, you can also set the maximum version (optional):

SET CLUSTER SETTING server.tls_max_version = 'TLS1.3';

3. Verify the configuration

After applying the change, run middleBrick again:

middlebrick scan https://db-node1.internal:8080

The scan should now report that SSLv3 is rejected and the POODLE check passes.

Note: middleBrick only detects and reports the issue; it does not modify the CockroachDB configuration. The remediation steps above must be applied by the operator using CockroachDB’s native flags or SQL cluster settings.

Frequently Asked Questions

Does enabling --tls-version=1.2 also secure the internal node‑to‑node Raft traffic?
Yes. The --tls-version flag (or the server.tls_min_version cluster setting) is applied to the gRPC listeners used for Raft replication, so inter‑node traffic is also forced to TLS 1.2 or higher, preventing POODLE against those channels as well.
If I run CockroachDB with insecure mode (<code>--insecure</code>), am I still at risk for POODLE?
When --insecure is used, CockroachDB does not use TLS at all for either client or node communication, so the POODLE attack (which targets TLS/SSL) does not apply. However, all traffic is then unencrypted and exposed to eavesdropping, which is a far more severe risk; you should avoid --insecure in any production environment.