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 McHugh
indieterminacy 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


More information about the Gemini mailing list