Comment by 🚀 clseibold
Re: "Until the Misfin protocol is developed (I have found at…"
@ps Client certs are used for identity verification when *sending*, not receiving. It allows you to send from *any* device anywhere. It's not that different from having a client cert over gemini to post on BBS, but then BBS sends messages to your special email server when you receive messages (if BBS ever had such a thing). That is effectively what misfin is.
TLS is used to encrypt over the wire. There is no method of encrypting on the server's storage.
You could implement misfin over a different network protocol if you can use x509 client certificates. An example of this would be Quic, which does have a way to use x509 certs, iirc.
Also, you don't want something like nex for misfin - otherwise it would send messages over tcp directly in plaintext, which is prone to man-in-the-middle-attacks, and people can snoop your messages, which is not a thing you generally want. You want some form of encryption, with x509 certs, in whichever low-level protocol allows for this (Tor? Quic, TLS, etc.)
And just to be clear, misfin is not exactly like email. When you send a misfin mail to someone, you send it *directly* to their server, not to your server that then routes to their server. That's why the client certs are a thing.
🚀 clseibold [🛂 Code of Conduct rule 1 violations]
2025-06-26 · 10 months ago
4 Later Comments ↓
👻 ps [OP] · 2025-06-26 at 07:32:
@clseibold, in my case, there is no one in the middle because I'm using an encrypted tunnel interface, but I still MUST use TLS to interact with the destination, which is already owned by the recipient.
🚀 clseibold [🛂] · 2025-06-27 at 01:46:
@ps Right, that's because the protocol doesn't specify anything for tunnels that already have encrption. With quic, you can use x509 certs in quic itself, and so the protocol doesn't need to specify anything really to work over quic. But if we're dealing with tunnels or other encryption methods, then the spec would have to specify how x509 client certs are dealt with.
It's just easier to define your protocol to work over TLS or Quic, or other wire protocols that use x509 certs, though.
Btw, a lot of people are generally overestimating the weight of TLS 1.3 and Quic, imo. They are both very lightweight, afaik.
🚀 clseibold [🛂] · 2025-06-27 at 01:53:
@ps Also, here's a page about why Tor sites would still use HTTPS instead of just HTTP: https://onionservices.torproject.org/research/proposals/usability/certificates/
A lot of this also pretty much applies to other networks, like i2p and yggdrasil, imo.
🚀 clseibold [🛂] · 2025-06-27 at 01:57:
@ps One more thing. In misfin, mailbox certificates actually don't need to be stored on the misfin server. You can crate a certificate signing request (CSR) to the misfin server on mailbox creation, and the private key of the mailbox cert never has to leave a person's local computer.
Nobody does it this way *because* there's no GUI misfin clients, lmao. So our "misfin clients" are implemented on the misfin server atm using a Gemini client (basically the equivalent of webmail, but for Gemini; e.g., skylab, or in my misfin-server, or @gemalaya's misfin server). These "Geminimail" misfin clients have to be able to send using a mailbox's private key, and so that's the only reason you would store your misfin mailbox private key on a misfin server.
Hopefully this makes sense.
Original Post
Until the Misfin protocol is developed (I have found at least three editions), I would like to raise the question about the TLS requirement for all connections. In short, the main point is described here: [gemini link] Personally, I'm using encrypted IPv6 mesh networks like Yggdrasil, and I really don't want any external TLS layer. Maybe it's time to care about now than later?)