💾 Archived View for rawtext.club › ~sloum › geminilist › 006888.gmi captured on 2024-02-05 at 10:54:55. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Malicious Links

Jonathan McHugh indieterminacy at libre.brussels

Sat Jul 10 16:54:54 BST 2021

- - - - - - - - - - - - - - - - - - -

Thanks for an informative post.

Just one point of concern:

In the UK term 'nonce' was a perjorative term - its mercifully left the everyday lexicon. Just as the term 'fag' used to mean an 'old lady who picks up sticks', language moves on.

While I understand that it has a cryptographic definition, is it possible to have/use another term than 'nonces'?

Having grown up watching the satirical series, Brass Eye, the following could be featured as a comedy monologue:```A nonce introduces randomness, and sometimes time-stamping, into communications so that the application can verify the user. This added uniqueness makes it impossible for hackers to use prior communications to impersonate the legitimate parties for nefarious purposes.```

====================Jonathan McHughindieterminacy at libre.brussels

July 10, 2021 2:57 PM, "nervuri" <nervuri at disroot.org> wrote:

On Fri, 2021-07-09, nothien at uber.space wrote:

What does the Gemini community think? How big of a problem is this?

Are there any other feasible workarounds? Which major (and minor) sites

are affected? Does this call for some sort of change in protocol?

See previous discussions:

gemini://gemini.circumlunar.space/~/fgaz/posts/2020-06-15-csrf-in-gemini/

- https://lists.orbitalfox.eu/archives/gemini/2020/001698.html

gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/a-vision-for-gemini-applications.gmi

- https://lists.orbitalfox.eu/archives/gemini/2020/001747.html

Takeaways:

Server-side: mandate client certs for requests with non-trivial

consequences and use nonces (CSRF tokens) to be extra-safe (see the

first link).

Client-side: never use a client certificate when following a link from

outside the client certificate's scope, as defined in section 4.3 of the

spec. This rule could be added to the spec itself. Here's how the

scope is defined:

A client certificate which is generated or loaded in response to such a

status code has its scope bound to the same hostname as the request URL

and to all paths below the path of the request URL path. E.g. if a

request for gemini://example.com/foo returns status 60 and the user

chooses to generate a new client certificate in response to this, that

same certificate should be used for subsequent requests to

gemini://example.com/foo, gemini://example.com/foo/bar/,

gemini://example.com/foo/bar/baz, etc.,

Another client-side takeaway: consider Solderpunk's idea of a

"containerised" client, exemplified in [1].

Such client-side precautions should cover most cases of CSRF, except, to

quote Solderpunk:

It is not foolproof - it cannot protect against application-internal

CSRF attacks, e.g. some kind of multi-user application where one user

can post text/gemini content which is rendered by another user of the

same application.

Nonces (CSRF tokens) should be used in such instances.

[1] https://lists.orbitalfox.eu/archives/gemini/2020/001771.html