-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Private keys leaked in logs #6267
Comments
Please upgrade to the latest code and try again first. Maybe it's already fixed. |
hi @dextercd, I checked the haproxy.sh part, and you are right, we probably need to replace the "_debug" helper by "_secure_debug" to fix this. Since we need to pass the private key on the socat command, we could probably do a sed on the "BEGIN PRIVATE KEY" header when doing an insecure debug so we could still see the commands sent to HAProxy. Maybe this filtering could be done in acme.sh _debug function directly, so any new contributor don't make this mistake. @Neilpang what do you think? |
It was reported in issue acmesh-official#6267 that the private key was leaked when using the DEPLOY_HAPROXY_HOT_UPDATE=yes feature. Indeed, the debugging code which sends commands to HAProxy was using _debug even when passing the private key. This patch fixes the issue by using _secure_debug when doing that.
It was reported in issue acmesh-official#6267 that the private key was leaked when using the DEPLOY_HAPROXY_HOT_UPDATE=yes feature. Indeed, the debugging code which sends commands to HAProxy was using _debug even when passing the private key. This patch fixes the issue by using _secure_debug when doing that.
I made the pull request to fix the problem in haproxy.sh. |
Hey there,
When you open an issue on this project, a comment from GitHub actions tells you to provide logs with
--debug 2
set. However, sometimes these logs contain private keys. This means that people occasionally post the private keys for their publicly trusted certificates.Here are some instances where this has happened:
#6165
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIMs4tSuTqBFPsTwVDvPmU2+9zfprjRTn/p9EaQWWvkJNoAoGCCqGSM49
AwEHoUQDQgAE8ngffyDE+hIUoNz1umHlWG/CuY1TqpSDRrZYvHyfOkKdnH/mrYUa
gZr+O1fNQWWaN8BKHe6nkOcAD8mMTG14uw==
-----END EC PRIVATE KEY-----
Certificate: https://crt.sh/?id=16142264126
#5004 (comment)
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIBhqGS/2Ucnoe+weM2oTNWlQbmCG6tr5hwiQDMxS0gShoAoGCCqGSM49
AwEHoUQDQgAEZ1B5WYmbpfFOMG+9FUrc0/y0TiXffNUe5YcUWuVgNz57aab8+Pyh
CBf92/cbkwZQbHgip7hjghwflTjuAqVMfQ==
-----END EC PRIVATE KEY-----
Certificate: https://crt.sh/?id=13108850004
#4788 (comment)
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIKqkk1rZcu4/tD+fYh6SrLX8QBzWyIpRyUhJkgItok6YoAoGCCqGSM49
AwEHoUQDQgAEj7fUB56An+/SwBPDwKm0+c2Jx4VPhak5YMMGYUr76vY+Ky8KYPg5
pJrhobIEtMkTLzltcjGGFmB62kuRK6NJsw==
-----END EC PRIVATE KEY-----
Certificate: https://crt.sh/?id=10532645172
None of these keys are currently being used. The certificates have either expired or been revoked. But this could definitely happen again in the future with valid certificates.
While it's up to each individual to make sure they're not sharing logs/files with important secrets, I think tools like
acme.sh
should also avoid logging this information, especially by default (e.g., it should require an opt-in flag like--output-insecure
).My suggestions:
--output-insecure
_post()
logs the request bodyThe text was updated successfully, but these errors were encountered: