💾 Archived View for rawtext.club › ~sloum › geminilist › 000467.gmi captured on 2020-10-31 at 01:36:07. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Regarding `gemini://` over NaCL (replacing TLS)

Bradley D. Thornton Bradley at NorthTech.US
Mon Mar 2 08:36:33 GMT 2020
- - - - - - - - - - - - - - - - - - - ```



On 3/1/2020 4:18 PM, Sean Conner wrote:
> 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. I
> do have a few questions about the code as I'm looking over it.  Prepare for
> lots of questions.  I had them for solderpunk as well.
> 
> 1) I assume the 32-bit length is sent bigendian (if I understand the
> argument to struct.pack() and struct.unpack() correctly---I'm not a Python
> programmer).  Why big endian?  99% of all computers on the Internet today is
> little endian (x86) so it seems to me that sending it little endian would be
> better.  [1][2]
> 
> 2) As I feared, this requires a more complicated implementation.  solderpunk
> wanted a protocol that could be implemented quickly and while TLS might be a
> bad protocol, it at least has the feature of being widely available and
> largly transparent if done correctly (like libtls, part of LibreSSL, does).


um.... <smile>, Sean I have to call attention here to the fact that suchan implementation of security isn't actually as simple as you portray inthat statement, lolz...

For example, just a couple of days ago you touted the libtls that you[were able to] took advantage of, as a result of developing GLV-1.12556being written in Lua ;)

In fact, you posted a tiny snippet of text showing how simple it was (inthat language), lending in part, to the simplicity of a Gemini serverbeing possible as a result of a weekend coding and beer session.

On the other hand, I recall quite clearly, Michaels encyclopediclamentations on the vagaries of attempting to acheive successful resultsin Python, with regards to TLS and client/transient certs, due to thehorrendous state of Python libs in that regard :)

Just sayin', yes, it's trivial because you chose (whether by design orinadvertantly) a framework upon which to support TLS, while in practice,the implementation for others isn't necessarily so straight-forward ;)


>   In fact, that's part of why HTTPS was so successful---it doesn't change
> the HTTP protocol at all.  It just slips in between TCP and HTTP and is
> transparent to both.


Again, you chose something other than Python3 to do this with :)


>   I know that given the self-sign certificate nature of Gemini decreases
> security a bit (TOFU and all that), not *all* Gemini servers are using
> self-signed certificates.  There's at least two that I know of that use
> actual signed certificates (from Let's Encrypt), and for my own server, I


My servers are among those :)


>   What's still missing from your proof-of-concept though, is support for
> client certificates.  Yes, you have the "transient" stuff working, but for
> my Gemini server, I have a second that is unavailable unless you have a
> signed certificate from me.  Send in a certificate request, I generate the
> certificate and send that back, and you can access the sooperseecret portion
> of my site [3] (no one has done that yet; then again, I haven't exactly
> advertised that I would do that either).

That's really kewl, but it brings to mind the notion (at least to me),that we may be painting ourselves into a corner by specifying a methodof encryption in canon that precludes the possibility for allowing othermethods, emerging or otherwise, that might *date* the Gemini protocol'sutility moving forward.

Question: Isn't it (even if non-trivial) possible, to account for othermethods of encryption by the listening daemon, some servers being ableto secure communications by one or another method if the upcomingclients can also support those technologies?

I'm just thinking that security is a moving, and mostly reactive, ratherthan proactive target, but allowing for the adoption, in a proactiveway, for the inclusion of developing encryption methods might be a goodthing to ensure that something like Gemini isn't relegated to theboneyard when earlier methods two decades and more are eventuallydeprecated (Like true SSL was).


>   I'm still going over your code, but I'm not sure I can run it.  For one, I

I have no idea whether Ciprian's proof of concept can translate intoviable solutions, but I'm confident that if anyone can competentlyevaluate the pros and cons of what he's suggesting - it is you my friend :)


-- Bradley D. ThorntonManager Network Serviceshttp://NorthTech.USTEL: +1.310.421.8268