← ClaudeAtlas

protocol-securitylisted

TLS 1.2+, mTLS, certificate validation, HSTS, gRPC channel credentials, WebSocket origin checks — Applies to: when generating HTTP / gRPC / WebSocket / SMTP / database clients & servers; when generating TLS configuration in code or platform config; when generating service-to-service auth
ShieldNet-360/secure-vibe · ★ 3 · API & Backend · score 76
Install: claude install-skill ShieldNet-360/secure-vibe
<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. --> <!-- Do not edit by hand; the source of truth is skills/protocol-security/SKILL.md. --> # 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 mob