💾 Archived View for bbs.geminispace.org › s › misfin › 1662 captured on 2023-09-08 at 17:02:36. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-07-22)
-=-=-=-=-=-=-
Greetings, maybe I oversaw this in the spec, but if a client connects with a TOFU / self-signed certificate for chuck@norris.com is there any verification done to ensure that the client is not spoofing the sender address?
I could think of something like a back-connection to a kind of "misfin MX" record (well SRV record would be perfect for that) and checking if the presented client certificate is signed by the norris.com server certificate.
2023-06-07 · 3 months ago
If I am correct, a malicious client can connet to a Misfin server and claim chuck@norris.com - the server will accept the message, assuming it is legit, without verification of the sender, and just store the TOFU/self-signed certificate.
In addition, once the real chuck@norris.com tries to send a message to that Misfin server, the server will respond with "You are a liar" because the malicious sender was first and the server stored the cert of the malicious sender in its cert cache.
Is this the case or did I miss something?
2023-06-08 · 3 months ago
Looking closely at the spec these scenarios are somewhat accounted for, but some of it is going to be implementation defined.
First, the spec strongly encourages individual client certs to be signed by the server hosting that mailbox. These signatures should be checked, although I'm sure that will be implementation dependent.
Second, as part of verifying a client cert using Tofu the server can send an empty message to that mailbox and check the returned fingerprint in the response against the calculated fingerprint for the certificate that has been presented. If those fingerprints match, then it is almost impossible for it to have been spoofed.
As it is now, any cert is considered ok since and verification of an identity would have to include the client cert hash to be meaningful. if a TUFO-like thing is used, I would not know how to invalidate a client hash and accept a new one.
actually the spec says you can it any way you like, it may do a callback to the sending server to get the cert and verify that it is the same, not sure if that is practical
Yes, the call back to the sender's server is what I was referring to before. The meta portion of the status is supposed to be the hash of the client certificate for the receiver, so it's easy to check the client certificate that is presented when getting an incoming message.
If this is the first time seeing that certificate, the server sends a blank message to that mailbox, and this gets the fingerprint in the return code. If something goes wrong in that transaction, like the mailbox doesn't exist, then the original incoming message is rejected. If the transaction succeeds but the hash does not match, then the identity is being spoofed.
There is a potential flaw in this scheme for getting the user's hash, and since I don't want to type it all back in again I'll direct you to this other conversation where I elaborate on it a bit.
— bbs.geminispace.org/s/discuss/1679
Thanks @jeang3nie for your clarifications and that there still is work to be done on cert verification (empty message loop etc.)