# Protocol Security

> 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

- **Type:** Skill
- **Install:** `agentstack add skill-shieldnet-360-secure-vibe-protocol-security`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [ShieldNet-360](https://agentstack.voostack.com/s/shieldnet-360)
- **Installs:** 0
- **Category:** [Databases](https://agentstack.voostack.com/c/databases)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [ShieldNet-360](https://github.com/ShieldNet-360)
- **Source:** https://github.com/ShieldNet-360/secure-vibe/tree/main/dist/agent-skills/.agents/skills/protocol-security

## Install

```sh
agentstack add skill-shieldnet-360-secure-vibe-protocol-security
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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](https://github.com/ShieldNet-360)
- **Source:** [ShieldNet-360/secure-vibe](https://github.com/ShieldNet-360/secure-vibe)
- **License:** MIT

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** yes
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-shieldnet-360-secure-vibe-protocol-security
- Seller: https://agentstack.voostack.com/s/shieldnet-360
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.