https cert pinning / TOFU / making connection to cockpit to be of comparable security level to ssh #21548
JanZerebecki
started this conversation in
Ideas
Replies: 1 comment
-
Thanks @JanZerebecki for your thoughts! Note that the self-signed cert creation is really just a crappy and poor fallback. In "serious" production environments we recommend/expect one of these:
See e.g. https://github.com/cockpit-project/cockpit/wiki/Proxying-Cockpit-over-Apache-with-LetsEncrypt |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Some time ago I was asked to make a quick check what could be done to improve the security of logging into cockpit. Besides passkey support #20389 , I had one other idea. It seems not likely that I will work on this unless demand changes, but wanted to write this down in public.
Currently checking the certificate of the https connection to cockpit is less secure than ssh in the default configuration. (E.g. Normal HTTPS CA system has risk of MITM during even properly implemented domain auth, see section 3.2.2 of https://cabforum.org/working-groups/server/baseline-requirements/documents/ and there are always some CAs that do fail at properly doing even that.) Web browsers have removed support for HTTP Public Key Pinning (HPKP) for good reason. While something comparable can IMHO be built without those problems, I don't have the resources to do a proper implementation in browsers. One idea for that is instead of blocking access on an unwanted cert change to instead partition the state like cookies on that. Combined with not supporting passwords and binding passkeys to only the trusted certs, this would solve the reasons HPKP was discontinued. (It might even be possible to have it default on by defending against more attacks in certificate transparency and combining it with information from DNSSEC to distinguish domain owner change from changes by the same owner.) So maybe a less ambitious version of it is possible to be implemented in a browser addon.
For that it would need to be able to check the cert on a https connection when or after the tls part is opened, but before it is used for sending a http request. I did not yet verify if Firefox provides that functionality to addons.
Maybe we can also come up with a cheaper to implement way to pin the cert to a passkey, e.g. by including the fingerprint in the domain, but is that possible without creating other risks?
One of these ways it might also be possible to make self-signed certs with cockpit more usable, similar to how ssh does TOFU.
(If the addon idea fails, can one make a mutually authenticated tunnel in JavaScript through a connection we do not trust?)
Beta Was this translation helpful? Give feedback.
All reactions