Username/password authentication strategy

[Alex Schroeder]

On Sun, 2020-07-19 at 21:26 +0200, Peter Vernigorov wrote:
> I am trying to implement a simple authentication for my Gemini site,
> and was planning to use a client certificate CN field to pass
> username:password pair to server. However, upon reading closely about
> the TLS handshake -
> https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake
> -
> it seems that the client (just like the server) certificate is sent
> before the ChangeCipherSpec record, i.e. insecure. That means to me
> that the CN field would be passed before the TLS session is started
> and therefore not suitable as an authentication medium. Is that
> correct?

Well, my experience is that you tell the server that you want to verify
peer certificates (which is typically off for servers); then the client
sends you a server that won't validate if you do nothing else: you have
to overwrite the default validation code and return True for
everything. Then your code gets the client certificate and now you can
do the real validation in your app instead of on the TLS layer.

Here's a long blog post:
https://alexschroeder.ch/wiki/2020-07-13_Client_Certificates_and_IO%3a%3aSocket%3a%3aSSL_(Perl)

Here's where I tell my server that I want to verify peers (client
certificates) and that I will provide my own verification code:
https://alexschroeder.ch/cgit/gemini-wiki/tree/gemini-wiki#n758

Here's the verification code for the TLS library which accepts
anything:
https://alexschroeder.ch/cgit/gemini-wiki/tree/gemini-wiki#n775

Here's some example code that does actual validation, requests a client
certificate if none is available, etc:
https://alexschroeder.ch/cgit/gemini-wiki/about/#client-certificates

Good luck!

And yes, I'm using more traditional access tokens for my wiki per
default. 😄