💾 Archived View for rawtext.club › ~sloum › geminilist › 000465.gmi captured on 2020-09-24 at 02:33:06. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Sean Conner sean at conman.org
Mon Mar 2 00:18:42 GMT 2020
- - - - - - - - - - - - - - - - - - - ``` It was thus said that the Great Ciprian Dorin Craciun once stated: > So I've taken Sean Conner advice and implemented a proof-of-concept > client and server (only the protocol, transport and crypto part, not > the actual file serving) in Python by replacing TLS with NaCL / > `libsodium`. Wow. For that I thank you. Now there's something to actually look at. Ido have a few questions about the code as I'm looking over it. Prepare forlots of questions. I had them for solderpunk as well. 1) I assume the 32-bit length is sent bigendian (if I understand theargument to struct.pack() and struct.unpack() correctly---I'm not a Pythonprogrammer). Why big endian? 99% of all computers on the Internet today islittle endian (x86) so it seems to me that sending it little endian would bebetter. [1][2] 2) As I feared, this requires a more complicated implementation. solderpunkwanted a protocol that could be implemented quickly and while TLS might be abad protocol, it at least has the feature of being widely available andlargly transparent if done correctly (like libtls, part of LibreSSL, does). It handles not only the crypo portion, but the framing of data (invisibly tothe rest of the application). To tell the truth, I don't know the actualbytes of the TLS portion of the protcol as that is handled for me. In fact, that's part of why HTTPS was so successful---it doesn't changethe HTTP protocol at all. It just slips in between TCP and HTTP and istransparent to both. [ snip ] > I hope I haven't made too many mistakes, and I hope this is useful as > a proof-of-concept that one could replace TLS for such simpler > protocols, I know that given the self-sign certificate nature of Gemini decreasessecurity a bit (TOFU and all that), not *all* Gemini servers are usingself-signed certificates. There's at least two that I know of that useactual signed certificates (from Let's Encrypt), and for my own server, Iuse a signed certificate from my own CA (technically, the certificate isn'tself-signed, but the CA is self-certificed). With a signed certificate, youget *some* assurance that the server you are talking to is the server youexpect to be talking to, but it's still, technically, subject to a MITMattack (either at the corporate level, or at the state level---it's way lesslikely to come from some random hacker). What's still missing from your proof-of-concept though, is support forclient certificates. Yes, you have the "transient" stuff working, but formy Gemini server, I have a second that is unavailable unless you have asigned certificate from me. Send in a certificate request, I generate thecertificate and send that back, and you can access the sooperseecret portionof my site [3] (no one has done that yet; then again, I haven't exactlyadvertised that I would do that either). This way, I can control who has access to what on my Gemini server in amostly stateless way (I don't have to maintain a database of userids andpasswords, just pass out certificates which can be revoked if needed, andwill expire after a period of my choosing). Yes, that complicated *my* end,and may complicate a client that wants to support that, but it doesn'tcomplicate the *protocol* at all---TLS provides all the machinery for that. I'm still going over your code, but I'm not sure I can run it. For one, Idon't know which version of Python (I know there are major differencesbetween 2 and 3 and I think I only have 2.something---I don't program inPython) and I don't have libsodium install (but I do have NaCL). But again,I thank you for doing this work and giving us something tangible to look atand run. -spc [1] Okay, I happen to agree with the big endian choice, but that's because I'm biased---binary based Internet protocols are all big endian, and I have a soft spot for the Motorola CPUs of past. I've never been a fan of little endian personally. [2] I'm also asking to reflect back to you the same argument you presented with using CRLF. Your big endian choice seems to be "because that's how all Internet protocols do it". [3] gemini://gemini.conman.org/conman-labs-private/