Sessions are necessary in Gemini for: multi variable input, user
creation, login and interaction, captchas and other anti-bot features
required to accept meaningful input from visitors, and other crucial
features of a website.

There are two viable ways to create client sessions in Gemini:

1. By requesting a client certificate and using the TLS hash of it.
2. By storing the session id in the URL directly.

If you have never heard about #1: Gemini has a special feature that
prompts the user in the browser to send or create a personal identifier
(either temporary or permanent). The user just has to press one or two
buttons to proceed. It is basically identical to creating a cookie. You
can then identify that user from your CGI script via the TLS hash
variable and store/retrieve session data from some database.

If you have never though of #2: Using redirect rules of your Gemini
server, you can also create sessions this way:

http://example.com/session-JBOQtGmWhED6L6Dfp7l1Hf/application

This URL is offered like any other and it does not require the user to
click through any dialogues.

CSRF is a very primitive kind of attack. For example on the page
gemini://eviljoe.net/ the website owner can trick you to open a link on
an external page that invokes an action, for example:

gemini://astrobotany.mozz.us/app/killplant

If you had an authenticated account there, this would kill your
Tamagotchi on that site. This is why CSRF tokens are used in HTTP
applications. If the Astrobotany app required the TLS hash to be present
in the URL, ideally encoded in base62, like so:

gemini://astrobotany.mozz.us/app/killplant#JBOQtGmWhED6L6Dfp7l1Hf

Then it would be impossible for an attacker to invoke that action.

CSRF attacks only become really powerful if links are loaded in the
background. And exactly this will happen with Gemini in the future, when
browsers might develop more crawler-alike features that are in line with
the protocol specifications. The first thing that will happen is image
URLs being shown as images directly (already present in some ebook
readers). One step further, all media data, maybe CSV tables, possibly
mini-previews of all URLs if hovered like on Wikipedia. Without changing
the nature of Gemini, clients will seek to enrich the experience as much
as reasonable and possible.

It is obvious then that using client certificates present a security
risk that needs to be addressed today. And that temporary certificates
only yield disadvantages compared to storing a session-token directly in
the URL as shown in #2. It stands to reason then how useful client
certificates in Gemini really are for permanent authentication, compared
to user passwords, and if one might not want to avoid them all together.

Best regards,

Cyrus

In comp.infosystems.gemini, you wrote:
> CSRF is a very primitive kind of attack. For example on the page
> gemini://eviljoe.net/ the website owner can trick you to open a link on
> an external page that invokes an action [...]
> It is obvious then that using client certificates present a security
> risk that needs to be addressed today.

This was discussed before, and the conclusion at least some of us
reached is that it should be addressed in clients by preventing any
certificate from being applied to requests generated by such
"cross-site" links (unless the user explicitly says it should).

We have a neat way to determine what should count as a "cross-site"
link: as explained in the gemini spec, each client certificate in use is
associated with a "scope", a subtree of URLs where it will be used. So
a certificate which is in use at URL1 should also be used in a request
to URL2 generated by following a link from URL1 if and only if URL2 is
in the scope of that certificate. In all other cases, no certificate
should be used at URL2 without explicit user consent.