💾 Archived View for rawtext.club › ~sloum › geminilist › 002287.gmi captured on 2020-09-24 at 03:13:31. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Peter Vernigorov pitr.vern at gmail.com
Mon Jul 20 22:27:00 BST 2020
- - - - - - - - - - - - - - - - - - -
Hey Kevin,
Yes this solution sounds good, pin is passed as part of query string.Username is still visible outside tls session of course.
But I think the bigger problem is that now I need to store usernames, pins,all of user’s cert fingerprints and their first seen and last seen dates, Iwould need to build an interface to delete old/lost fingerprints, etc.Compare that to basic auth in http, which while might not be pretty,involves very little code to implement: check username/password hashagainst ones in db on every request (in a before filter if frameworksupports it) and I’m done.
By the way, your solution is very similar to how client ssh usually works,one would login using username/password into a new server or from a newclient, and then add their client certificate to ~/.authorized_keys. So faryours is the best solution, but I wonder if there’s a simpler, more elegantway.
On Mon, Jul 20, 2020 at 16:50 Kevin Sangeelee <kevin at susa.net> wrote:
I see this as the same issue that exists for clients - without a trusted
CA, there's nothing to stop me masquerading as anyone else, other than the
certificate (e.g. fingerprint) pinning, so I believe the process absolutely
needs a (one-time) login prompt to pin the certificate - I can't see a way
to avoid it.
Your question made me think about what would be the minimum steps required
to implement client TOFU with PIN or password verification, and the code
below is my take on what I think has to happen. Note the code is only meant
as a concise way to discuss the process.
So, for example, a request to a private resource, such as: -
gemini://susa.net/cgi-bin/private.sh?articleId=1234
Might be handled something like this: -
$ cat private.sh
#!/bin/bash
# If we have no client certificate, request one.
if [[ "${TLS_CLIENT_HASH}" == "" ]]; then
echo -ne "60 CLIENT CERTIFICATE REQUIRED\r\n"
elif [[ $(grep "${TLS_CLIENT_HASH}" /tmp/${REMOTE_USER}_sigs) == "" ]];
then
# We've never seen this user's client hash, so challenge for a PIN
# (we could store this current URL for onward forwarding)
echo -ne "30 /cgi-bin/login.sh\r\n"
else
echo -ne "20 text/gemini\r\n"
echo "This is the prize inside the protected resource!"
fi
I think a redirect to a login process is unavoidable, because any
originating request might have its own query_string, yet we're going to
need one for the password prompt response. So the login.sh would be our
one-time verification to pin the certificate to a CN based user-id.
$ cat login
#!/bin/bash
# If we have no client certificate, request one.
if [[ "${TLS_CLIENT_HASH}" == "" ]]; then
echo -ne "60 CLIENT CERTIFICATE REQUIRED\r\n"
exit
fi
# If the certificate has no CN, then reject it
if [[ "${REMOTE_USER}" == "" ]]; then
echo -ne "20 text/gemini\r\n"
echo "Your CN can't be used as a user-id!"
exit
fi
# We have a client certificate, is it already authorised?
if [[ $(grep "${TLS_CLIENT_HASH}" /tmp/${REMOTE_USER}_sigs) != "" ]]; then
echo -ne "20 text/gemini\r\n"
echo "You are already authorised!"
exit
fi
# We have a certificate and a valid user-id (CN), so either prompt for
# a PIN, or verify PIN if we've been given a QUERY_STRING.
# Grep the remote user's line from the passwd file (format CN:PIN)
PWD_ENTRY=$(grep "^${REMOTE_USER}:" login_passwd)
# Strip the CN value and separator, leaving the PIN
MY_PIN="${PWD_ENTRY#${REMOTE_USER}:}"
# Check for our PIN in the query string (which may be empty)
if [[ "${QUERY_STRING}" == "${MY_PIN}" ]]; then
echo -ne "20 text/gemini\r\n"
echo "Your PIN checks out, ${REMOTE_USER}!"
echo "${TLS_CLIENT_HASH}"
/tmp/${REMOTE_USER}_sigs
echo "Your hash has been stored in '/tmp/${REMOTE_USER}_sigs'"
exit
fi
echo -ne "11 Please enter your PIN, ${REMOTE_USER}\r\n"
On Sun, 19 Jul 2020 at 20:26, Peter Vernigorov <pitr.vern at gmail.com>
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?
Another alternative to implement username/password type authentication
in Gemini would be the sensitive input status code, but then I would
have 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 both
users and client/server devs, has anyone found a simple way to
implement username/password type authentication systems? To be fair, I
have attempted to use client short-/long-lived client certificates as
per recommendation in Gemini protocol specification; however, if
access to the same "account" from multiple devices and being able to
survive certificate loss without permanently losing access is my
account are requirements, this authentication method quickly becomes a
mess. For example, think about how one would go about getting access
to their astrobotany plant on a new device. This is why I ended up
going back to username/password authentication, but having
difficulties making sure that everything is secure. In need of
help/suggestions/ideas, thanks.
-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200720/5bda12bc/attachment-0001.htm>