💾 Archived View for rawtext.club › ~sloum › geminilist › 002279.gmi captured on 2020-10-31 at 14:26:32. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Peter Vernigorov pitr.vern at gmail.com
Sun Jul 19 20:26:03 BST 2020
- - - - - - - - - - - - - - - - - - -
I am trying to implement a simple authentication for my Gemini site,and was planning to use a client certificate CN field to passusername:password pair to server. However, upon reading closely aboutthe TLS handshake -https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake -it seems that the client (just like the server) certificate is sentbefore the ChangeCipherSpec record, i.e. insecure. That means to methat the CN field would be passed before the TLS session is startedand therefore not suitable as an authentication medium. Is thatcorrect?
Another alternative to implement username/password type authenticationin Gemini would be the sensitive input status code, but then I wouldhave to store a list of certificate fingerprint and username pairs,greatly complicating the system.
Given that Gemini protocol strives to be minimal/low-cost for bothusers and client/server devs, has anyone found a simple way toimplement username/password type authentication systems? To be fair, Ihave attempted to use client short-/long-lived client certificates asper recommendation in Gemini protocol specification; however, ifaccess to the same "account" from multiple devices and being able tosurvive certificate loss without permanently losing access is myaccount are requirements, this authentication method quickly becomes amess. For example, think about how one would go about getting accessto their astrobotany plant on a new device. This is why I ended upgoing back to username/password authentication, but havingdifficulties making sure that everything is secure. In need ofhelp/suggestions/ideas, thanks.