💾 Archived View for rawtext.club › ~sloum › geminilist › 000472.gmi captured on 2020-11-07 at 01:30:57. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2020-09-24)

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

<-- back to the mailing list

Regarding `gemini://` over NaCL (replacing TLS)

Sean Conner sean at conman.org

Mon Mar 2 22:00:47 GMT 2020

- - - - - - - - - - - - - - - - - - - ```

It was thus said that the Great Bradley D. Thornton once stated:
> On 3/1/2020 4:18 PM, Sean Conner wrote:
> 
> 
> 
> 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 such
> an implementation of security isn't actually as simple as you portray in
> that 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.12556
> being written in Lua ;)
> 
> In fact, you posted a tiny snippet of text showing how simple it was (in
> that language), lending in part, to the simplicity of a Gemini server
> being possible as a result of a weekend coding and beer session.
> 
> On the other hand, I recall quite clearly, Michaels encyclopedic
> lamentations on the vagaries of attempting to acheive successful results
> in Python, with regards to TLS and client/transient certs, due to the
> horrendous state of Python libs in that regard :)

  Do you have any links to this?  I don't remember seeing any of that, andI'd be interested in reading it.

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

  By design.  I knew libtls, written by the OpenBSD people, was designed tomake using TLS simple to use, and hard to use incorrectly.  Since my prerredlanguage is Lua, it was a simple matter to wrap up libtls for use in Luaand a moderate amount of work to get it working within a network eventdriver.  I happen to agree with the OpenBSD guys that *using* crypto is toohard.

  I'm just sad that libtls doesn't seem to get much use.  But it could bethat I haven't looked hard enough.  I don't know.  
> Question: Isn't it (even if non-trivial) possible, to account for other
> methods of encryption by the listening daemon, some servers being able
> to secure communications by one or another method if the upcoming
> clients can also support those technologies?

  In general?  Yes.  In practice, with current implementations of TLS?  Idon't know, I haven't looked into it.

  But to remind you, I'm not the one who developed the Gemini protocol.

  -spc