Missing Tls in Django with Cockroachdb

When a Django application connects to CockroachDB without Transport Layer Security (TLS), credentials, queries, and result sets traverse the network in plaintext. This exposes the application to network-level interception, credential theft, and data manipulation. middleBrick detects Missing TLS as a distinct finding because unencrypted database channels bypass authentication and authorization protections, regardless of how robust Django’s own security settings are.

In a typical deployment, Django’s database configuration in settings.py specifies connection parameters. If OPTIONS does not enforce TLS (e.g., missing 'sslmode': 'require'), the TCP connection to CockroachDB’s port remains unencrypted. CockroachDB, by default, may accept plaintext connections unless cluster certificates are enforced. An attacker who can observe or inject traffic between Django and the database can capture usernames, passwords, and sensitive data. This aligns with OWASP API Top 10’s vulnerability category related to insecure communication, and it can map to findings such as Data Exposure and Encryption in a middleBrick scan.

Moreover, Missing TLS amplifies risks like BOLA/IDOR and BFLA/Privilege Escalation when unauthorized network access exists. Even if the API endpoint itself is protected, an unprotected database channel allows lateral movement. middleBrick’s 12 checks run in parallel, and Missing TLS is flagged alongside Authentication and Encryption checks to highlight the chain of weaknesses. In CI/CD workflows, the GitHub Action can fail a build if the risk score drops below a defined threshold, encouraging teams to enforce TLS before deployment.

To secure Django applications connecting to CockroachDB, enforce TLS by configuring SSL options in the database settings and ensuring the server certificates are available and validated.

1. Configure Django to require TLS

Update settings.py to include SSL connection parameters. Use 'sslmode': 'verify-full' to enforce encryption and validate the server certificate against a trusted CA. This prevents man-in-the-middle attacks and ensures the identity of the CockroachDB server.

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'mydatabase',
        'USER': 'myuser',
        'PASSWORD': 'strongpassword',
        'HOST': 'cockroachdb.example.com',
        'PORT': '26257',
        'OPTIONS': {
            'sslmode': 'verify-full',
            'sslrootcert': '/path/to/ca.pem',
            'sslcert': '/path/to/client.pem',
            'sslkey': '/path/to/client.key',
        },
    }
}

The sslrootcert points to the CA certificate that signed the CockroachDB server certificate. The sslcert and sslkey provide client certificate authentication if mutual TLS is required. Using verify-full ensures the hostname matches the certificate, which is critical for preventing spoofing.

2. CockroachDB certificate and cluster configuration

On the CockroachDB side, generate and distribute certificates appropriately. For a secure cluster, use the cockroach cert command to create CA, node, and client certificates. When starting the nodes, specify the certificate and key files. For Django to authenticate the server, the CA certificate must be distributed to the application.

Example CockroachDB start command for a node (illustrative, not executed via Django):

cockroach start --certs-dir=certs --store=node1

To test connectivity with TLS from the Django environment, you can use a script that mimics the database driver’s behavior:

import psycopg2

conn = psycopg2.connect(
    dbname='mydatabase',
    user='myuser',
    password='strongpassword',
    host='cockroachdb.example.com',
    port='26257',
    sslmode='verify-full',
    sslrootcert='/path/to/ca.pem',
)
cur = conn.cursor()
cur.execute('SELECT 1')
print(cur.fetchone())
cur.close()
conn.close()

This snippet confirms that the TLS handshake succeeds and the application can securely communicate with CockroachDB. If the certificates are missing or mismatched, the connection will fail, which is preferable to silent plaintext transmission.

3. Operational practices

Store certificate paths securely and manage them using secrets management tools. Avoid hardcoding credentials in settings; use environment variables or a secrets manager and reference them in settings.py. Rotate certificates regularly and monitor for expiration. middleBrick’s continuous monitoring (Pro plan) can alert you when TLS configurations drift or when unencrypted endpoints are detected during scans.