PKCS12 password exposed in verbose logs via URL query parameter #20

New issue

Open

opened 2026-04-29 23:31:22 +02:00 by heiko · 2 comments

heiko commented

2026-04-29 23:31:22 +02:00

Owner

Summary

The PKCS12 bundle password is sent as a URL query parameter (?pass=<password>). While the TLS connection protects it in transit, the full URL (including the password) is logged when verbose mode is enabled:

Server (cmd/cert-proxy-server/serve.go:20): shared.Verbose("Serving url=%v...", req.URL, ...)
Client (cmd/cert-proxy-client/cert/cert.go:175): shared.Verbose("Requesting %s ...", item.remote.URL, ...)

Additionally, any reverse proxy or load balancer in front of the server would log the password in access logs.

Exploitation Scenario

An operator enables -verbose in production for debugging. Log output is captured by a log aggregator (journald, syslog, ELK). An attacker with log access obtains the PKCS12 password. Combined with access to a backup containing the .pfx bundle, they extract the private key.

Recommended Fix

Transmit the password in a request header (e.g., X-PKCS12-Pass) instead of a query parameter. Headers are not logged by default in most proxies and are not part of req.URL.String().

Alternatively, redact the pass query parameter in verbose log output before printing.

## Summary The PKCS12 bundle password is sent as a URL query parameter (`?pass=<password>`). While the TLS connection protects it in transit, the full URL (including the password) is logged when verbose mode is enabled: - **Server** (`cmd/cert-proxy-server/serve.go:20`): `shared.Verbose("Serving url=%v...", req.URL, ...)` - **Client** (`cmd/cert-proxy-client/cert/cert.go:175`): `shared.Verbose("Requesting %s ...", item.remote.URL, ...)` Additionally, any reverse proxy or load balancer in front of the server would log the password in access logs. ## Exploitation Scenario An operator enables `-verbose` in production for debugging. Log output is captured by a log aggregator (journald, syslog, ELK). An attacker with log access obtains the PKCS12 password. Combined with access to a backup containing the `.pfx` bundle, they extract the private key. ## Recommended Fix Transmit the password in a request header (e.g., `X-PKCS12-Pass`) instead of a query parameter. Headers are not logged by default in most proxies and are not part of `req.URL.String()`. Alternatively, redact the `pass` query parameter in verbose log output before printing.

heiko added the

security

label

2026-04-29 23:31:22 +02:00

heiko referenced this issue from a commit

2026-04-29 23:48:22 +02:00

docs: update Known Issues and file permissions in README

heiko commented

2026-05-17 23:12:41 +02:00

Author

Owner

Security review (2026-05-17) confirms and extends this finding.

Additional reference: the password is injected into the URL at build time in :

remote: tt(`{{.Proxy}}/v1/bundle/{{.Domain}}?format=PKCS12{{with .Pass}}&pass={{.}}{{end}}&...`),

This means item.remote.URL already contains the plaintext password before the verbose log call at line 180. The server-side exposure at serve.go:20 is symmetric — req.URL also carries the full query string in verbose output.

Security review (2026-05-17) confirms and extends this finding. Additional reference: the password is injected into the URL at build time in : ```go remote: tt(`{{.Proxy}}/v1/bundle/{{.Domain}}?format=PKCS12{{with .Pass}}&pass={{.}}{{end}}&...`), ``` This means `item.remote.URL` already contains the plaintext password before the verbose log call at line 180. The server-side exposure at `serve.go:20` is symmetric — `req.URL` also carries the full query string in verbose output.

heiko commented

2026-05-22 11:38:22 +02:00

Author

Owner

AI attribution comment added per repository instruction for this open issue.\n\n(co)authored by ai:gpt-5-codex