Security Overview
FRP Auto Deploy separates FRP tunnel authentication from management-plane trust. Keeping those responsibilities separate is important when troubleshooting or reviewing risk.
Security model at a glance
The FRP token is not an Enrollment Code, Bootstrap Ticket, or management API credential.
Trust establishment
Enrollment and signed client management use verified HTTPS. There is no supported production plain-HTTP fallback.
FRP tunnel plane
- Direct mode uses FRP native TLS for control.
- Enterprise single-443 carries FRP control over WSS.
- The FRP token authenticates the tunnel.
- Published service traffic is forwarded through FRP after the proxy is registered.
Persistent management identity
After enrollment, the client keeps a persistent ECDSA P-256 management identity. The private key stays on the client.
Signed management requests bind request data to freshness/replay protections such as timestamp/nonce handling so stale or replayed requests can be rejected.
Zero-Touch credential properties
A Bootstrap Ticket is designed to be:
- high entropy
- short-lived
- first-machine bound
- single-use after successful enrollment
- hashed at rest on the server
- sensitive until used, expired, or revoked
Do not paste generated bootstrap commands into public issue trackers, public chat, analytics, or long-lived logs.
Secrets to protect
Security boundaries
The product does not claim to protect secrets from a fully compromised root account on the server or client.
Fail closed
Conditions such as unknown identity, invalid signatures, CA mismatch, corrupted registry state, or ambiguous client selectors should fail rather than silently guess.
Do not “fix” trust failures by using curl -k, disabling TLS verification, using plain HTTP enrollment, or copying secrets between clients.
Related pages