Hello! There are soon to be some changes to my Gemini software's TLS support. I am rewriting both to use BearSSL instead of OpenSSL, and making some refinements while I'm at it. Some of these will affect end-users. Naturally, when you pull down the code again, you'll have to install BearSSL's development package. BearSSL is not yet widely available: https://repology.org/project/bearssl/versions But your distro will probably add it if you ask nicely. Additionally, the format of known_hosts is changing. The hashes are the same, but we're no longer using the expiration time. Server operators are advised to generate long-lived certificates - a few hundred years should do the trick. In order to avoid breaking compatibility with any software which reads our known hosts file at ~/.local/share/gemini/known_hosts, we're moving it to our private directory at ~/.local/share/gmni/. The software will tolerate the old format, so you can copy your known_hosts file over, or you can simply start fresh and re-trust hosts as you encounter them in geminispace. Many breaking changes have been made to libgmni, and a few more may be in store. If you're a downstream user, you'll have to make some changes, and prepare for more in the foreseeable future. The plan is to abstract most, if not all, of the TLS details away from library users entirely. With the completion of this API work, and the addition of client-side certificate support in the near future, I will be tagging gmni 1.0. gmnisrv has not yet been migrated to BearSSL, and it's not a high priority for me right now, but I intend to put in the work before calling it 1.0 (patches welcome if you want to help). I have already changed the default certificate expiration to the far future, so if you're up to date, when your certificates roll over next you'll get a long-lived cert.
As a genuine question, may I ask why you chose BearSSL to switch to? I understand why OpenSSL is...not a wonderful library to put it kindly, but BearSSL has the worst TLS 1.3 support out of any of the major libraries, and TLS 1.3 is more important for Gemini than most other applications of TLS considering how insecure client certificates are in TLS 1.2, plus the fact that TLS 1.2 is only "reluctantly" allowed in Gemini and "TLS 1.3 or higher may be specced [once TLS libraries get better 1.3 support]," which most libraries other than BearSSL have. I just have concerns about future compatibility. BearSSL hasn't had a new release since 2018 and that it's averaged well under 0.3 commits per month for the past three years, which isn't giving me hope that the six print pages of to-do for TLS 1.3 support will ever be completed. ~nytpu : in particular, certificates are sent in the clear in TLS 1.2. https://tools.ietf.org/html/rfc5246#section-7.4.6 : https://www.bearssl.org/changelog.html : https://bearssl.org/gitweb/?p=BearSSL;a=log : https://www.bearssl.org/tls13.html -- Alex // nytpu email@example.com GPG Key: https://www.nytpu.com/files/pubkey.asc Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B https://useplaintext.email/
I'm open to recommendations for other small, C implementations of TLS. On Thu Mar 4, 2021 at 6:12 PM EST, Alex // nytpu wrote: > I just have concerns about future compatibility. BearSSL hasn't had a > new release since 2018 and that it's averaged well under 0.3 commits > per month for the past three years, which isn't giving me hope that > the six print pages of to-do for TLS 1.3 support will ever be > completed. That pace doesn't really bother me.