Missing Tls in Chi with Cockroachdb

When a Chi application connects to CockroachDB without Transport Layer Security (TLS), credentials, queries, and result sets traverse the network in plaintext. This exposes the database to eavesdropping and tampering, and it bypasses CockroachDB’s native TLS enforcement options. In many deployments, developers disable or omit TLS configuration during local development or rapid prototyping, intending to enable it later. Because Chi is a lightweight, idiomatic router for Go, it is common to wire handlers directly to database clients without enforcing secure transport, inadvertently leaving the database connection open.

Without TLS, an attacker who can observe or inject traffic between the application and the database can perform classic network-layer attacks. For example, connection strings, usernames, and passwords may be captured, and unencrypted query results might reveal sensitive business data. Because CockroachDB supports TLS with server certificates and optional client certificate authentication, failing to enable these mechanisms means the database cannot verify the identity of clients, and clients cannot verify the identity of the server. This lack of mutual authentication opens the door to man-in-the-middle attacks, where an attacker could impersonate the database server and harvest data or inject malicious responses.

The combination of Chi’s flexible handler composition and CockroachDB’s distributed, horizontally scalable architecture amplifies the risk: applications often scale horizontally, introducing more network paths where unencrypted traffic can be intercepted. Moreover, if the application uses a shared database connection pool configured without TLS, every service instance becomes a potential leakage point. middleBrick’s scans detect unencrypted database connections and missing TLS enforcement as part of its Data Exposure and Encryption checks, highlighting the absence of transport-layer protections before deployment. Remediation requires enabling TLS on both the CockroachDB server and the Chi application, ensuring certificates are properly provisioned and validated.

To secure the connection between Chi and CockroachDB, enable TLS on the database server and configure the Go SQL driver to use TLS with proper certificates. Below is a concrete, working example using the standard pq driver (now succeeded by cockroachdb/postgres) with TLS settings. This approach ensures the driver uses the server’s certificate authority to verify the server identity, and optionally presents a client certificate for mutual authentication.

// tls_config.go
package main

import (
    "crypto/tls"
    "crypto/x509"
    "io/ioutil"
    "os"

    "github.com/jackc/pgx/v4/stdlib"
    "github.com/labstack/echo/v4"
    "github.com/labstack/echo/v4/middleware"
    "database/sql"
)

func createSecureDBPool(caCertPath, clientCertPath, clientKeyPath, connString string) (*sql.DB, error) {
    // Load CA certificate
    caCert, err := ioutil.ReadFile(caCertPath)
    if err != nil {
        return nil, err
    }
    caCertPool := x509.NewCertPool()
    caCertPool.AppendCertsFromPEM(caCert)

    // Optionally load client certificate and key for mutual TLS
    var cert tls.Certificate
    if clientCertPath != "" && clientKeyPath != "" {
        cert, err = tls.LoadX509KeyPair(clientCertPath, clientKeyPath)
        if err != nil {
            return nil, err
        }
    }

    tlsConfig := &tls.Config{
        RootCAs:      caCertPool,
        Certificates: []tls.Certificate{cert},
        MinVersion:   tls.VersionTLS12,
    }
    tlsConfig.BuildNameToCertificate()

    // Configure pgx driver to use TLS
    pgxConfig, err := stdlib.ParseConfig(connString)
    if err != nil {
        return nil, err
    }
    pgxConfig.TLSConfig = tlsConfig
    db := sql.Open("pgx", pgxConfig)

    // Verify the connection is secure
    if err := db.Ping(); err != nil {
        return nil, err
    }
    return db, nil
}

// main.go
func main() {
    db, err := createSecureDBPool(
        "certs/ca.crt",
        "certs/client.crt",
        "certs/client.key",
        "postgresql://myuser:mypass@cockroachdb-host:26257/mydb?sslmode=verify-full",
    )
    if err != nil {
        panic(err)
    }
    defer db.Close()

    e := echo.New()
    e.Use(middleware.Logger())
    e.Use(middleware.Recover())

    e.GET("/profile/:id", func(c echo.Context) error {
        var username string
        row := db.QueryRow("SELECT username FROM users WHERE id = $1", c.Param("id"))
        if err := row.Scan(&username); err != nil {
            return c.String(500, "internal error")
        }
        return c.JSON(map[string]string{"username": username})
    })

    e.Logger.Fatal(e.Start(":8080"))
}

Key points in this setup:

• sslmode=verify-full ensures the server certificate is validated against the provided CA, preventing man-in-the-middle attacks.
• Mutual TLS is optional but recommended for high-security environments; client certificates are loaded only when paths are provided.
• Chi routes remain unchanged, but the underlying *sql.DB instance passed to handlers uses a secure connection pool.

For deployments without client certificates, you can simplify by setting sslmode=require and providing only the CA certificate. However, verify-full is preferred because it validates the server hostname against the certificate, aligning with best practices for secure database connectivity. middleBrick’s scans can verify that your application’s connection strings and TLS configurations meet these standards by running scans against your endpoint and reviewing the Encryption and Data Exposure findings.