Alex Schroeder alex at gnu.org
Sun Jul 19 21:03:41 BST 2020
- - - - - - - - - - - - - - - - - - -
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 verifypeer certificates (which is typically off for servers); then the clientsends you a server that won't validate if you do nothing else: you haveto overwrite the default validation code and return True foreverything. Then your code gets the client certificate and now you cando 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 (clientcertificates) 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 acceptsanything:https://alexschroeder.ch/cgit/gemini-wiki/tree/gemini-wiki#n775
Here's some example code that does actual validation, requests a clientcertificate 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 perdefault. 😄