Attention: Please don't respond to this mail, but to the GitHub discussion
mentioned below.
Hello all,
the Cockpit team is currently investigating a redesign of Cockpit's web server,
which becomes slowly but surely more pressing. See [1] for details if you are
interested. A very interesting possibility is to replace much of it with a web
service worker [2], which would allow us to make the architecture dramatically
simpler, more robust, and more secure (see prototype[3]).
The main concern with this approach is that web service workers don't work with
unknown TLS certificates ("secure context"), in particular for the self-signed
certificates that cockpit creates on startup if you didn't supply your own.
I. e. they don't support the usual TOFU model with "click here to accept this
unknown certificate anyway" that browsers show for "normal" web pages in this
case.
So I would like to do a little survey and request for comments about
deprecating or changing the handling of self-signed TLS certs in Cockpit. This
is an annoyingly hard problem: On one hand we really want to build a world
where TLS works and your services are trustworthy (*especially* if you are
typing in your root password as the next thing!), but for many home or even
small business situations even LetsEncrypt etc. is impractical/impossible (no
DNS, etc.). My questions:
* Are you currently accessing Cockpit with the builtin fallback self-signed
certificate?
* If so, would you have a better option like getting a proper cert, or joining
the machine to a FreeIPA domain (which requests a valid cert from the IPA
server), or running Cockpit behind a reverse proxy which already has a
proper certificate? Or using the Cockpit Client flatpak?
If any of these don't work for you, can you describe your situation?
* If the above isn't possible, could you live with running the cockpit web
server on a machine which has proper TLS setup, and connect to your target
machines with SSH?
* As last resort, Cockpit could show an error page (after accepting the
invalid certificate in the browser) which explains the situation and offers
you to download the CA certificate for importing into your browser as
trusted CA. This includes the case that the default self-signed certificate
is not valid for the hostname you are using to connect to cockpit (i.e. not
"localhost" or the server's unqualified host name) - then you need
to regenerate the certificate with the additional name.
This could then be used to actually establish some trust to the certificate,
by something like `ssh remote cockpit-show-cert` which would show you the
fingerprint or similar -- then you have something actually meaningful to
check in the browser.
Would that be acceptable for you?
* Are you working on a different web-based project and already have some
experience
with handling proper certificates?
Notes:
* This only affects remote connections -- if you connect to your own machine
on http://localhost:9090, you can use unencrypted HTTP and service workers
are fine.
* We are aware of and use `sscg` if it's installed (cockpkit-ws.rpm
Recommends: it). We can change the non-sscg fallback to also create a
separate CA and cert, instead of the single self-signed cert. So that's not
a problem, just a bit of work.
Please respond on https://github.com/cockpit-project/cockpit/discussions/21695
to keep the responses in one place -- this annoucement goes to several mailing
lists.
Thank you!
Martin
[1] https://issues.redhat.com/projects/COCKPIT/issues/COCKPIT-1238
[2] https://developer.mozilla.org/de/docs/Web/API/Service_Worker_API
[3] https://issues.redhat.com/browse/COCKPIT-1240
--
_______________________________________________
cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org
To unsubscribe send an email to cockpit-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
