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[0], 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[1] and that it's averaged well under 0.3 commits
per month for the past three years[2], which isn't giving me hope that
the six print pages of to-do for TLS 1.3 support[3] will ever be
completed.

~nytpu


[0]: in particular, certificates are sent in the clear in TLS 1.2.
     https://tools.ietf.org/html/rfc5246#section-7.4.6
[1]: https://www.bearssl.org/changelog.html
[2]: https://bearssl.org/gitweb/?p=BearSSL;a=log
[3]: https://www.bearssl.org/tls13.html

-- 
Alex // nytpu
alex@nytpu.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[1] and that it's averaged well under 0.3 commits
> per month for the past three years[2], which isn't giving me hope that
> the six print pages of to-do for TLS 1.3 support[3] will ever be
> completed.

That pace doesn't really bother me.