CWE-295: TLS certificate verification disabled in Redis client (hardcoded InsecureSkipVerify: true)

[LeoWSY-hashblue]

Summary

The built-in Redis client in core/stores/redis/ hardcodes InsecureSkipVerify: true whenever TLS is enabled. Users who set tls: true get encryption but no certificate validation — and there is no way to override this or provide a CA certificate.

Details

redisclientmanager.go:26-39:

func getClient(r *Redis) (*red.Client, error) {
    val, err := clientManager.GetResource(r.Addr, func() (io.Closer, error) {
        var tlsConfig *tls.Config
        if r.tls {
            tlsConfig = &tls.Config{
                InsecureSkipVerify: true,   // hardcoded, no override
            }
        }
        store := red.NewClient(&red.Options{
            Addr:         r.Addr,
            Password:     r.Pass,           // Redis password — unverified TLS
            TLSConfig:    tlsConfig,
            ...
        })

The same pattern exists in redisclustermanager.go:25-26 for Redis Cluster. The r.tls field is a boolean with no way to set InsecureSkipVerify: false or pass a custom tls.Config.

Impact

Redis credentials (r.Pass) and all cached data (sessions, rate limit counters, distributed locks, business cache) are transmitted over a connection that silently accepts any self-signed certificate. A network-adjacent attacker can capture Redis passwords and intercept/tamper with cache entries.

Remediation

Add a TLSConfig *tls.Config field to the Redis struct so users can provide CA certificates:

if r.tls {
    tlsConfig = r.TLSConfig
    if tlsConfig == nil {
        tlsConfig = &tls.Config{}  // Go secure defaults
    }
}

Full report available on request.