💾 Archived View for rawtext.club › ~sloum › geminilist › 000983.gmi captured on 2020-09-24 at 02:12:07. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Sat May 23 14:28:39 BST 2020
- - - - - - - - - - - - - - - - - - -
Hey folks,
I'm preparing to finally do a 1.0.0 release of AV-98 this weekend andwould appreciate people helping me kick the tyres. Once the release ismade you'll be able to install it with pip, but for now you need toclone the repo:
https://tildegit.org/solderpunk/AV-98/
There's a setup.py in there if you want to install it yourself, but ithas no essential third party dependencies and it's all in a single fileso you can just run av98.py from right where you clone it, easy peasy.
The release is mostly for the sake of easier installation, and foreveryday use you won't notice much new if you are already used to howAV-98 works. But there have been substantial changes to the TLS-sideof things.
Firstly, you can now toggle between two methods of TLS certificatevalidation (AV-98, until now, did no verification whatsoever, anembarrassing reminder of it's "hacked together quickly in response tothe surprise experience of an actual, live Gemini server" legacy).
With `set tls_mode tofu` (the default), you get the TOFU validation modeI initially envisioned for Gemini. When you first visit a server, thereceived certificate is blindly trusted. An SQLite database ismaintained with the fingerprints of trusted certificates, a count of howmany times they've been seen and the dates they were first and mostrecently seen. If you ever subsequently see a different certificate forthat host, you get a warning with details on how often the previous certwas seen and when it is/was due to expire, to inform your decision onwhether or not to accept it.
Note that it's not required, but the TOFU mode works beter if you havethe `cryptography` module installed - certificates won't be blindlyaccepted if they are expired, or not yet valid, or don't have a commonname or subject alternate name matching the expected hostname. Python'sstandard `ssl` module doesn't let you check this for self-signedcertificates (really!).
In TOFU-mode there's a lot of creation of files and directories and thisis largely what I'm hoping to discover bugs in by getting people to trythis out.
With `set tls_mode ca` (which you can stick in an RC file to make yourpermanent setting), AV-98 will do typical CA-based validation using yourplatform's default trusted certificates, and will refuse to acceptself-signed certificates.
For now I'm still wimping out on setting a hard requirement on TLS certvalidation in the spec (which allows whatever the client likes - butclients really should be extremely upfront with users about what theyare doing!). But for my part I am pretty committed to experimentingwith less centralised and less commercial alternatives to the CA systemand I'll probably end up building a lot more options into AV-98's TOFUmode to reduce the risk associated with the initial acceptance. I'mtaking a lot of inspiration and ideas from DNS-based solutions likeDANE, and from projects like Perspectives and Convergence. I'm happy todiscuss them with interested folks.
Secondly, there is now a "client certificate manager" which is accessedvia the `cert` command. Use of client certificates in Gemini iscurrently under-specced and (perhaps as a partial consequence)under-used, and I want to correct this in the near future. So I threwsome stuff together in AV-98 to give us concrete ideas to discuss andtest. None of how this functions is "canonical" yet - I'm embracing thenotion of AV-98 as an experimental client where we test stuff out.
For now, the client certificate manager relies on the `openssl` commandline tool being available to run with `system()`, because this is awhole world of pain less than doing it in Python.
When it receives a 60, 61 or 62 status code, AV-98 will pop up anotification and give the use the option to generate a clientcertificate to use when re-requesting the resource, or to load apreviously generated (non-transient!) certificate from the filesystem.When client certificates are *not* being used, the AV-98
prompt nowappears in a happy, friendly lime green colour. As soon as a clientcertificate is loaded, the prompt becomes a scary deep red and displaysas "AV-98+cert
". If, while a client cert is loaded, you try tonavigate away to a different domain, AV-98 will warn you and give you aY/N dialogue to deactivate the cert before continuing, to avoid"identity leak". If you subsequently navigate back, during the samesession (I mean AV-98 session here, i.e. you haven't exited andrestarted the program), to a domain where you previously used a clientcert, you'll be asked if you want to load it again. You can use the`cert` command to explicitly end a client certificate session any timeyou like.
It's all a bit clunky and explicit for now (although to some extentthat's a good thing because people should be *aware* of how they useclient certs), but it's definitely a huge improvement over previousoptions for occasionally keeping an eye on your astrobotany plant!
I will make a separate more detailed post later about clientcertificates and the things we should think about with regard to them.
That's about it! Thanks to anybody who tests out, bug reports welcomevia email or at https://tildegit.org/solderpunk/AV-98/issues.
Cheers,Solderpunk