💾 Archived View for rawtext.club › ~sloum › geminilist › 001932.gmi captured on 2020-09-24 at 01:32:53. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Fri Jun 26 14:56:33 BST 2020
- - - - - - - - - - - - - - - - - - -
There are several contributing factors to TLS overhead. Some of it isnetwork based, to do with actually downloading the certificate, anddoing the handshake. Some of it is computation based, to do with thekey exchange calculations. Which is the more important bottleneck willdiffere between applications. In cases where network overhead is moreimportant, getting down the size of the certificate may help.
My AV-98 TOFU database has 103 certificates stored in it. The mean sizeis 1247 bytes - about as large, IIRC, as the average text/geminidocument. 95% of certificates range in size between 704 bytes and 1634bytes.
However, the smallest certificate I have encountered belongs tocozylabs.eu. It is 273 bytes, i.e. 20% of the average! Or, about 1 KiBsmaller than average. That's 1KiB less network traffic for eachrequest to that server compare to a typical server.
cozylabs.eu achieves this feat with a single self-signed ED25519certificate. For folks who want to ditch the CA system and embraceTOFU, this is clearly the way to do it. I will migrategemini.circumlunar.space to this style of certificate in the nearfuture.
Unfortunately making this kind of cert with the `openssl` tool is notas straightforward as other options. The standard library for Go seemsup to the task. I will write a small and simple bulletproof program togenerate these certs next week, and document it well. It will be handynot only for server admins but people who want to generate their ownclient certs for use with clients like Alphonse. Stay tund...
Cheers,Solderpunk