💾 Archived View for bbs.geminispace.org › u › billsmugs › 3289 captured on 2023-09-08 at 17:44:02. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-07-22)

➡️ Next capture (2023-09-28)

🚧 View Differences

-=-=-=-=-=-=-

Re: "Questions about verification"

Comment in: s/misfin

Thanks for the answers! Caching the message and performing the validation later is an interesting idea I hadn't thought of. I don't think I'll go that far but it could be a good way to prevent bad actors from overloading servers with loads of empty requests.

For the second question I think I was overthinking things and confusing myself. I didn't mean verifying the incoming IP (I agree, the fact that clients can just send messages directly to recipient servers is a plus [1])󱦜 I actually meant to ask whether trusted hosts should be re-verified some/all of the time. I now think that's probably a waste of time (and resources) in most cases (although see below for caveats).

The second part of the question was whether I need to verify a new mailbox from a previously seen host (i.e. check that the fingerprint matches). I think this is worth doing, specifically for the case of stolen certificates.

This is probably rare, but I hope it gets addressed in the 'best practices' document at some point. I think the process for stolen user certificates should be (in order):

If a server certificate is stolen, the server admin should inform all their users to do the above after they generate a new CA (probably by inserting a message directly into user inboxes).

Perhaps periodically re-verifying trusted server CAs and mailbox fingerprints would be a good general strategy to mitigate these concerns?

[1] unless I'm wrong, one downside of this is that you have to be careful when sending a message to someone for the first time (from a given device) while on an untrusted network. Unlike on Gemini, where evil DNS servers 'just' mean you could see incorrect information, with misfin the bad guy has received your message (which could theoretically contain private or sensitive information). They can't reply from that spoofed address (because your server's DNS query can't be tricked in the same way), but it feels like a more serious issue with TOFU and self-signed certs than the corresponding Gemini case.

Obviously, whatever the messaging protocol, they could send you to a fake contact page with a replaced contact address, but this attack is still possible if the victim knows the address by heart or copies it from a known trusted capsule (e.g. their mail server).

📷 billsmugs

2023-07-19 · 7 weeks ago

1 Later Comment

🦀 jeang3nie

Sorry reply now, just for the easy part. Agreed that periodic re-validation is probably a good idea.

Original Post

🌒 s/misfin

Questions about verification — I'm slightly confused by the verification flow on the receiving side for misfin(B). Apologies if some of these questions are already obvious in the spec/best practices/reference examples and I've just missed/misunderstood! I'm specifically trying to implement the case where the server's certificate is a self-signed CA and there may be multiple mailboxes (each with certs signed by that CA). My understanding My understanding of the process, starting from the end of...

💬 billsmugs · 3 comments · 1 like · 2023-07-17 · 8 weeks ago