Bleichenbacher Attack in Gorilla Mux with Cockroachdb

A Bleichenbacher attack is a chosen-ciphertext attack against RSA encryption that exploits error messages returned during padding validation to gradually decrypt ciphertext without the key. When a Go service uses Gorilla Mux for routing and CockroachDB as the data store, the combination can unintentionally expose behavior that aids an attacker if cryptographic operations and database interactions are not carefully separated.

In this stack, a typical vulnerable pattern is using RSA-OAEP or PKCS#1 v1.5 to encrypt a session token or API key, storing the ciphertext or a derived lookup key in CockroachDB, and then returning different HTTP status codes or timing behavior depending on whether decryption or decryption-plus-lookup succeeds. For example, a login or token-introspection handler might query CockroachDB using a decrypted user identifier; if the decryption fails early due to bad padding, the handler may respond with 400 or 404, whereas a successful decryption that yields no matching row in CockroachDB returns 401, and a successful match returns 200. These distinct responses give an attacker feedback about the validity of the ciphertext, enabling Bleichenbacher’s adaptive chosen-ciphertext process to recover the plaintext over many requests.

Gorilla Mux does not enforce any cryptographic protocol; it simply routes requests to handlers. If a handler performs RSA decryption before validating input and before speaking to CockroachDB, and then leaks the outcome through status code or timing differences, the routing layer becomes an implicit part of the attack surface. CockroachDB itself does not introduce the vulnerability, but its behavior — such as consistent error codes for missing rows and measurable query latency — can stabilize the timing characteristics an attacker relies on. Even secondary metadata like request IDs or trace headers stored in CockroachDB can give an attacker additional observable side channels when combined with repeated decryption attempts.

Consider a token verification endpoint defined with Gorilla Mux where the path parameter contains an encrypted user identifier:

// Vulnerable pattern: decryption before validation and DB lookup
func verifyTokenHandler(w http.ResponseWriter, r *http.Request) {
    vars := mux.Vars(r)
    encToken := vars["token"]
    cipher, err := base64.StdEncoding.DecodeString(encToken)
    if err != nil {
        http.Error(w, "invalid token", http.StatusBadRequest)
        return
    }
    privKey := loadPrivateKey()
    plaintext, err := rsa.DecryptOAEP(sha256.New(), rand.Reader, privKey, cipher, nil)
    if err != nil {
        // Distinguishing error type can leak padding vs other failures
        http.Error(w, "decryption failed", http.StatusUnauthorized)
        return
    }
    userID := string(plaintext)
    var dbUserID string
    err = dbRowQuery(cockroachDB, "SELECT id FROM users WHERE id = $1", userID).Scan(&dbUserID)
    if err != nil {
        if errors.Is(err, sql.ErrNoRows) {
            http.Error(w, "user not found", http.StatusUnauthorized)
        } else {
            http.Error(w, "server error", http.StatusInternalServerError)
        }
        return
    }
    // successful verification
}

An attacker can submit modified ciphertexts and observe whether the response is 401 (decryption succeeded, user not in CockroachDB) versus 400/403 (bad ciphertext or decryption error), gradually learning the plaintext. Timing differences between a missing CockroachDB row and a decryption error can further refine the signal. The fix is to ensure constant-time behavior and uniform error responses regardless of decryption or DB outcome, and to avoid routing decisions that depend on the decrypted content before validation.

Remediation centers on decoupling cryptographic validation from database lookup and ensuring that all paths that reach CockroachDB do so with valid, already-validated input. Use constant-time comparisons where applicable and return the same generic error for any failure before the query to CockroachDB.

1) Validate and normalize input before any cryptographic operation, and use a constant-time decryption pattern where possible. Do not branch on decryption errors in a way that reveals which stage failed.

2) Perform the database query with a blinded or fixed key material when feasible, or ensure that the query path and error handling are identical regardless of decryption success.

3) Use context timeouts and prepared statements to reduce timing variability and avoid leaking query behavior to the network.

Here is a hardened version of the previous handler using Gorilla Mux and CockroachDB:

// Secure pattern: constant-time approach, uniform errors, prepared statement
func verifyTokenHandler(db *sql.DB, privKey *rsa.PrivateKey) http.HandlerFunc {
    // Prepare statement once for reuse (helps with performance and consistent behavior)
    stmt, err := db.Prepare(context.Background(), "SELECT id FROM users WHERE id = $1")
    if err != nil {
        // handle setup error at startup
        log.Fatalf("prepare statement: %v", err)
    }
    return func(w http.ResponseWriter, r *http.Request) {
        vars := mux.Vars(r)
        encToken := vars["token"]
        cipher, err := base64.StdEncoding.DecodeString(encToken)
        if err != nil {
            // Do not reveal why base64 failed
            http.Error(w, "invalid request", http.StatusUnauthorized)
            return
        }
        // Use a fixed-length buffer to avoid leaking length via timing
        plaintext := make([]byte, 32) // adjust to expected userID length
        n, err := rsa.DecryptOAEP(sha256.New(), rand.Reader, privKey, cipher, nil)
        if err != nil || n == 0 {
            // Treat decryption failure and empty output identically
            n = 0
            plaintext[0] = 0 // ensure deterministic empty-like content
        }
        userID := string(plaintext[:n])
        var dbUserID string
        // Use context with timeout to bound query duration
        ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second)
        defer cancel()
        row := stmt.QueryRowContext(ctx, userID)
        err = row.Scan(&dbUserID)
        // Always return the same status for any failure before/after DB lookup
        if err != nil {
            http.Error(w, "invalid token