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, and I'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 to make using TLS simple to use, and hard to use incorrectly. Since my prerred language is Lua, it was a simple matter to wrap up libtls for use in Lua and a moderate amount of work to get it working within a network event driver. I happen to agree with the OpenBSD guys that *using* crypto is too hard. I'm just sad that libtls doesn't seem to get much use. But it could be that 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? I don't know, I haven't looked into it. But to remind you, I'm not the one who developed the Gemini protocol. -spc
---
Previous in thread (6 of 18): 🗣️ Ciprian Dorin Craciun (ciprian.craciun (a) gmail.com)
Next in thread (8 of 18): 🗣️ Sean Conner (sean (a) conman.org)