On Mon, 2023-08-28 at 15:14 -0500, Chris Adams wrote: > Once upon a time, Richard Hughes <hughsient@xxxxxxxxx> said: > > On Mon, 28 Aug 2023 at 16:27, Leon Fauster via devel > > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > whats the benefit of this "self-signed TLS certificate" (as it does > > > not provide any "security")? Is this stub for something later ... ? > > > > It's a good question. It provides encryption (so client A can provide > > the file to client B without client C being aware what's being sent) > > Without identification though, it doesn't do that, because there's no > way for client B to know it is really talking to client A - it could be > talking to client C with a man-in-the-middle attack and a different > self-signed cert pretending to be client A. It helps dealing with passive attacks, but not with active attacks. It could be improved by using TOFU, so that the window of impersonation is small, but requires clients to cache an association and then has weird failure modes to be dealt with if one of the actors get re-imaged or changes the cert for any reason. Richard, given your files are all independently integrity checked, you should probably not use a TLS connection, because it will be flagged up pretty rapidly if it is using a self-singed cert anyway. This thing works only within the same LAN, therefore already "within" a firewall so it does not need to cross any boundary for which encryption matters enough. Finally if an enterprise says TLS is a must you could give an option to use TLS if said enterprise provides the certs (they will probably disable the service anyway otherwise). There is one more option you could entertain, and that is to use a "well know" pre-shared key instead of certificates for authentication, will be faster, and will give you the "fake-secure" TLS tunnel without the self-signed cert headache I think ... (not endorsing this option, just mentioning it). HTH, Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
