Protocol Security

Protocol Security

TLS 1.2+, mTLS, certificate validation, HSTS, gRPC channel credentials, WebSocket origin checks

ALWAYS

• Default to TLS 1.3 for new clients and servers; permit TLS 1.2 only for interop with legacy peers. Disable TLS 1.0/1.1, SSLv2/v3.
• Validate the server certificate: chain to a trusted CA, name matches the expected hostname (or SAN), not expired, not revoked (OCSP stapling enabled).
• Enable HSTS on HTTP responses for everything served over HTTPS: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. Add the host to the HSTS preload list once stable.
• Use mutual TLS (mTLS) for service-to-service traffic inside a trust domain (mesh: Istio / Linkerd; standalone: SPIFFE / SPIRE for identity).
• For gRPC clients/servers, use grpc.secure_channel / grpc.SslCredentials / credentials.NewTLS — never insecure_channel in production.
• For WebSocket servers, validate the Origin header against an allowlist and authenticate the handshake (cookies + CSRF token, or a query-string bearer used once at upgrade and re-validated).
• For service-to-service tokens, prefer SPIFFE IDs (spiffe://trust-domain/...) with short-lived workload certs over long-lived API keys.
• Pin the certificate (public key pinning) for high-risk mobile / desktop clients calling back to the operator's own backend.

NEVER

• Disable certificate verification (InsecureSkipVerify: true, verify=False, rejectUnauthorized: false, CURLOPT_SSL_VERIFYPEER=0). The only acceptable use is in a unit test that runs against a localhost ephemeral cert.
• Implement a custom X509TrustManager / HostnameVerifier / URLSessionDelegate / ServerCertificateValidationCallback that unconditionally returns trusted.
• Mix HTTP and HTTPS resources on the same page (mixed content) — modern browsers will block subresources, but APIs are still vulnerable to MITM downgrade.
• Send tokens / passwords over plain HTTP — even on localhost in dev unless the dev environment is documented as not security-relevant.
• Use grpc.insecure_channel(...) in production code.
• Trust the Host / X-Forwarded-Host / Forwarded header without an allowlist; absolute URLs built from Host enable host-header injection and password-reset poisoning.
• Forward incoming Authorization / Cookie headers blindly across origins in your service mesh — re-derive identity from mTLS or a service token.
• Enable TLS renegotiation on clients you control; pin to tls.NoRenegotiation where available.

KNOWN FALSE POSITIVES

• Localhost-only dev servers with self-signed certs and explicit documentation are fine; CI tests against ephemeral CA-signed certs are fine.
• A small number of legacy enterprise integrations require TLS 1.2 with a specific cipher; document the exception and isolate the integration behind a proxy.
• Public read-only endpoints (e.g., status pages) can legitimately serve over HTTP for cacheability, though HTTPS is still preferred.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ShieldNet-360
• Source: ShieldNet-360/secure-vibe
• License: MIT

Install and usage instructions live in the source repository linked above.