๐Ÿ’พ Archived View for bbs.geminispace.org โ€บ u โ€บ drh3xx โ€บ 13253 captured on 2024-02-05 at 12:17:26. Gemini links have been rewritten to link to archived content

View Raw

More Information

โžก๏ธ Next capture (2024-03-21)

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

Comment by ๐Ÿ drh3xx

Re: "Encryption is a hell"

In: s/Gemini

Could always support optional DNS verification of cert thumbprint similar to ssh key validation either with the same RR type or yet another TXT entry?

๐Ÿ drh3xx

2023-12-30 ยท 5 weeks ago

3 Later Comments โ†“

๐Ÿ Addison ยท Dec 30 at 19:48:

If your threat model requires you to account for a highly malicious ISP that tampers with Gemini traffic, then you have bigger problems that Gemini can't solve for you.

๐Ÿ€ gritty ยท Dec 30 at 20:22:

I agree with the sentiments here - we have some encryption but it's not perfect, and we're not doing online banking here, so I think TOFU is good enough for this space.

๐Ÿš€ numb3r_station ยท Jan 02 at 00:13:

you could use a tor hidden service and asks users to bookmarks the page if this is a concern.

Original Post

๐ŸŒ’ s/Gemini

Encryption is a hell โ€” Gemini encription is somewhat unusual. It relies on TOFU (trust on first use) principle. Suppose my provider is a jackass and he is implementing a MitM attack on all gemini connections, then my gemini program will not notice and all gemini capsules from this network perspective will be compromised. And if I use VPN after that, I will get warnings about certificate change. Than I have to guess where MitM attack was happened? Is it my provider messing with that, or is it a...

๐Ÿ’ฌ nikhotmsk ยท 7 comments ยท 2023-12-30 ยท 5 weeks ago