Information related to exposure of X-CF-Proxy-Signature for route services
Article ID: 437091
Updated On:
Products
Issue/Introduction
X-CF-Proxy-Signature is an HTTP header added by the Gorouter to requests forwarded to route services. The signature is signed by a Route Services encryption key.
When the Gorouter receives a request with X-CF-Proxy-Signature header, it accepts and forwards the request to the app only if the URL of the request matches the one associated with the token, and the request was received on time. Otherwise, the request is rejected.
This KB article provides security information in the event that X-CF-Proxy-Signature or route-services encryption key has been exposed.
Reference: Route-Services Documentation
Resolution
This KB provides information for an X-CF-Proxy-Signature or Route Services encryption key exposure.
If the currently used Route Services encryption key was exposed (the value there matches the value in credhub or in the router VM's gorouter config), then it should be rotated as that key could be used to generate new X-CF-Proxy-Signature values.
If the only exposed values were X-CF-Proxy-Signature values, they would only have been valid for 60s, so would not be valid and represent an active security concern.
Q&A -
1. Does exposure of an X-CF-Proxy-Signature header value pose any ongoing security risk?
The signature is just a short-lived token that expires after 60 seconds (by default) and does not pose a security risk after 60 second period lapses.
2. Can a captured X-CF-Proxy-Signature header value be reused or replayed without access to the underlying Route Services secret?
A captured signature could technically be replayed, but only within that 60-second window and only against any path or query parameter that falls under the same route mapping.
3. Is rotation of the Route Services secret supported and recommended?
The Route Services secret can be regenerated via credhub, but redeploying it will cause downtime, because support was never implemented for no-downtime rotation of that secret in the tile. Gorouter supports it, so manual bosh deploys could be done to rotate secret without downtime by steps:
- Save the current secret value
- Provide it to gorouter via the router.route_services_secret_decrypt_only property
- Regenerate it in credhub
- Have credhub provide the new value via
.router.route_services_secret.
On the next EAR deploy, you can go back to using ops manager. It will remove the no-longer-used-for-encrpytion router.route_services_secret_decrypt_only value from the manifest, and use credhub's value.
4. Will rotating the secret require changes to Gorouter, Route services, Load balancers, or upstream integrations?
Rotating the secret only affects gorouter and requires an EAR tile re-deploy.
5. Is downtime or traffic disruption expected during rotation?
Depends on whether it was done via bosh directly, or via ops manager. If via ops manager, yes. The impact would be failing route service validation for requests generated on the old gorouter secret that are sent to gorouters that have been updated to the new secret.
6. What mitigation steps are recommended after exposure of X-CF-Proxy-Signature?
No mitigation steps are recommended for exposure of X-CF-Proxy-Signature. The signature expires 60 seconds after the original request for it.
7. Are there best practices for managing or periodically rotating the route-services secret?
Given the lack of no-downtime rotation, we do not provide best practices or recommend rotating it periodically.
Feedback
