💾 Archived View for gemi.dev › gemini-mailing-list › 000967.gmi captured on 2024-06-16 at 15:13:25. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
In Gemini, the restriction that information can only be sent to a server
by performing a request is considered a feature. However, this can
backfire by removing the need for user interaction, even when it is
absolutely necessary. Below, I provide an example to show why this
feature, combined with the existence of malicious links, can prevent (or
at least hinder) the sole use of TLS certificates in account-based sites
on Gemini.
Consider a website, gemini://example.org, where users can set up
accounts. It uses TLS certificates for authentication and provides
important settings through the Gemini interface. For example, one can
delete their account by visiting a certain URL: perhaps
gemini://example.org/account/delete. Although this makes sense, you may
already begin to understand the problem at hand.
Malicious Gemini pages (or parts thereof) can contain links to such
locations. Depending upon the user's Gemini client configuration, it
may not show them the URL they are going to (e.g. Amfora, I think), and
they may accidentally delete their account at gemini://example.org (or
perform any other action involuntarily) this way.
Note that simple workarounds such as responding by asking the user to
type 'YES' can be avoided trivially, by adding the 'YES' to the query
string in the URL of the malicious link.
One possible workaround is to require the user to provide their password
(through a response 11) for every such action. Presumably, the attacker
doesn't know the user's password, and so cannot craft a URL which would
delete the user's account without interaction from them. Sites would
have to re-state the action being performed within the prompt attached
to the response 11, and give context (so the prompt may look something
like "Are you sure you want to delete the account at
gemini://example.org? Type in your password to continue."). However,
if the user is performing many actions which require password
verification, this is going to get irritating. In addition, it forces
sites into using and storing passwords, even when they use TLS
certificates.
Another workaround is to require the user to provide a randomly
generated string. For example, upon visiting
gemini://example.org/account/delete, the user is requested to type in
some words that were generated at that moment ("correct horse battery
staple") to authorize the action. This removes the need for a password
in addition to the TLS certificate, but forces sites to keep track of
the random words for each user whenever they request such an action
(this functionality will likely have to be implemented by hand, and
there are complications like timeouts to consider). This prevents
attackers from crafting the necessary URL, but once again performing
account-related actions through Gemini would become irritating.
It would also be possible to avoid this issue by using a special URL
format when sensitive input needs to be included. Sites requiring
authorization (even just a 'YES' string) could use the sensitive input
response, and clients would not allow the sensitive input string to be
automatically provided (instead, the user would be required to type it
by hand). This provides a minimal level of necessary user interaction.
Although it still suffers from the repetition problem of the above
workarounds, it seems to reduce the amount of work necessary, and
better share it between server, client, and user. However, it would
necessitate a breaking change in protocol (or, perhaps, a new status
code and convention for 'sensitive query strings').
The reason that HTTP/HTML does not suffer from this problem is twofold.
Firstly, HTML is interactive, and so whenever such an action is
performed, the user can be interactively requested to confirm their
intention. Secondly, when the action is performed directly (e.g. by
using HTTP POST to the relevant URL), the attacker doesn't have access
to the necessary cookies to authorize the action. TLS certificates are
problematic in comparison because they apply for all interactions with
the site, and so automatically authorize any interaction; cookies for a
certain site are only available to the HTML/CSS/JS of that site, and so
the site can interactively verify the user's intention before
authorizing the action. The access control with cookies also avoids the
repetition problem, and allows users to authorize once to perform
multiple actions.
With any of the above workarounds, account management on sites through
Gemini becomes difficult, both for hosters/admins and for users. In
fact, this extends to just about any account-based interaction with any
site; for example, sites where comments can be uploaded are affected,
because a malicious link can cause an unpleasant comment to be
involuntarily submitted.
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?
~nothien
P.S: I'm not sure what ML category this fits into. [spec], maybe?
[tech]? No clue.
Interesting concern. What if a delete process required visiting (sequentially) two links?:
On 9 July 2021 23:25:47 BST, nothien@uber.space wrote: >The reason that HTTP/HTML does not suffer from this problem is twofold. >Firstly, HTML is interactive, and so whenever such an action is >performed, the user can be interactively requested to confirm their >intention. Secondly, when the action is performed directly (e.g. by >using HTTP POST to the relevant URL), the attacker doesn't have access >to the necessary cookies to authorize the action. HTTP does suffer from the same problem - because cookies are sent automatically. To prevent this HTTP requests typically use a "CSRF" token - an extra, random piece of text that is included in forms every time they are generated, and which the server tests against. Gemini could easily use the same approach: the page that generates the "delete your account" link can add a random string in the query string. The server can then tests for the presence of that query string. Because it's generated randomly every time the page is generated, attackers can't guess it. The CSRF token should have a limited life time. :) Alice -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 10 July 2021 11:27:34 BST, Alice <lia@loveisanalogue.info> wrote: >HTTP does suffer from the same problem - because cookies are sent >automatically. I should have added: a recent (ish) addition to the HTTP protocol is the "SameSite" attribute to cookies, which prevents CSRF attacks. However not all browsers currently in circulation support it, so for the time being web developers still need to use CSRF tokens (or not rely on cookies, if using client side JavaScript) :) Alice
nothien@uber.space writes: > In Gemini, the restriction that information can only be sent to a server > by performing a request is considered a feature. However, this can > backfire by removing the need for user interaction, even when it is > absolutely necessary. Below, I provide an example to show why this > feature, combined with the existence of malicious links, can prevent (or > at least hinder) the sole use of TLS certificates in account-based sites > on Gemini. I think having destructive operations (create, update, delete) running over Gemini is probably a mistake to begin with, because it will lead down the path of trying to build yet another application platform on top of yet another document delivery system. They tried that trick in the 90s. Sadly it's still with us, and it's called the WWW. Gemini eliminates a lot of the things that were tacked on to HTTP to help make it useful for applications. There's no distinction between idempotent and not-idempotent operations, no cookies, and so forth. Here's version 0.9 of the HTTP spec: https://www.w3.org/Protocols/HTTP/AsImplemented.html The family resemblance between Gemini and HTTP 0.9 is astonishing. Take HTTP 0.9, evolve it just a smidge, add some features, change some names, mandate TLS, and VOILA, you get Gemini. > Consider a website, gemini://example.org, where users can set up > accounts. It uses TLS certificates for authentication and provides > important settings through the Gemini interface. For example, one can > delete their account by visiting a certain URL: perhaps > gemini://example.org/account/delete. Although this makes sense, you may > already begin to understand the problem at hand. If you have a site that does something more complicated than serve documents and satisfy search requests, that's starting to look a lot like an application. -- Chris Brannon Founder: Blind and Low Vision Unix Users Group (https://blvuug.org/). Personal website: (https://the-brannons.com/) Chat: IRC: teiresias on libera.chat and OFTC, XMPP: chris@chat.number89.net
On Fri, 2021-07-09, nothien@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/ - gemini://gemi.dev/gemini-mailing-list/messages/001698.gmi gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/a-vision-for- gemini-applications.gmi - gemini://gemi.dev/gemini-mailing-list/messages/001747.gmi 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] gemini://gemi.dev/gemini-mailing-list/messages/001771.gmi
One more thing clients could do is be very clear about what link the user is about to access. Most clients are not, particularly (in my experience) AV-98 and Amfora. But this is understandable, as showing the link (at least in terminal-based clients) would often require a prompt - which I want, but it might annoy most people. It could be a setting, though.
Hello, Chris Brannon <chris@the-brannons.com> writes: > nothien@uber.space writes: > >> In Gemini, the restriction that information can only be sent to a server >> by performing a request is considered a feature. However, this can >> backfire by removing the need for user interaction, even when it is >> absolutely necessary. Below, I provide an example to show why this >> feature, combined with the existence of malicious links, can prevent (or >> at least hinder) the sole use of TLS certificates in account-based sites >> on Gemini. > > I think having destructive operations (create, update, delete) running > over Gemini is probably a mistake to begin with, because it will lead > down the path of trying to build yet another application platform on top > of yet another document delivery system. They tried that trick in the > 90s. Sadly it's still with us, and it's called the WWW. Full ACK! ~ew -- Keep it simple!
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@libre.brussels July 10, 2021 2:57 PM, "nervuri" <nervuri@disroot.org> wrote: > On Fri, 2021-07-09, nothien@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/ > - gemini://gemi.dev/gemini-mailing-list/messages/001698.gmi > > gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/a-vision-fo r-gemini-applications.gmi > - gemini://gemi.dev/gemini-mailing-list/messages/001747.gmi > > 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] gemini://gemi.dev/gemini-mailing-list/messages/001771.gmi
Isn't that basically what all applications (that are capable of any state change) do essentially? Build an application layer on top of a protocol? If you remove Gemini, you got TCP and UDP, and then IP. If Gemini permits something but doesn't have it out of the box, people will create another layer. It's natural I believe 🤷♀️ On Sat, 10 Jul 2021, 16:23 ew.gemini 'ew.gemini at nassur.net', <gemproj+ew.gemini=nassur.net@suckless.anonaddy.com> wrote: > This email was sent to gemproj@suckless.anonaddy.com from > ew.gemini@nassur.net and has been forwarded by AnonAddy. > To deactivate this alias copy and paste the url below into your web > browser. > > > https://app.anonaddy.com/deactivate/84c97fb7-dd72-4688-b653-188215324c2a? signature=e4cd6fabb5144657ed72ac3c56cde019ecccfe366af0b08968536f9080c11eba > > ----- > > > Hello, > > Chris Brannon <chris@the-brannons.com> writes: > > > nothien@uber.space writes: > > > >> In Gemini, the restriction that information can only be sent to a server > >> by performing a request is considered a feature. However, this can > >> backfire by removing the need for user interaction, even when it is > >> absolutely necessary. Below, I provide an example to show why this > >> feature, combined with the existence of malicious links, can prevent (or > >> at least hinder) the sole use of TLS certificates in account-based sites > >> on Gemini. > > > > I think having destructive operations (create, update, delete) running > > over Gemini is probably a mistake to begin with, because it will lead > > down the path of trying to build yet another application platform on top > > of yet another document delivery system. They tried that trick in the > > 90s. Sadly it's still with us, and it's called the WWW. > > Full ACK! > > ~ew > > -- > Keep it simple! > > >
Hello, gemproj@suckless.anonaddy.com writes: > Hello, > > Chris Brannon <chris@the-brannons.com> writes: > > > nothien@uber.space writes: > > > >> In Gemini, the restriction that information can only be sent to a server > >> by performing a request is considered a feature. However, this can > >> backfire by removing the need for user interaction, even when it is > >> absolutely necessary. Below, I provide an example to show why this > >> feature, combined with the existence of malicious links, can prevent (or > >> at least hinder) the sole use of TLS certificates in account-based sites > >> on Gemini. > > > > I think having destructive operations (create, update, delete) running > > over Gemini is probably a mistake to begin with, because it will lead > > down the path of trying to build yet another application platform on top > > of yet another document delivery system. They tried that trick in the > > 90s. Sadly it's still with us, and it's called the WWW. > > Full ACK! > > ~ew > > Isn't that basically what all applications (that are capable > of any state change) do essentially? Build an application > layer on top of a protocol? If you remove Gemini, you got TCP > and UDP, and then IP. > > If Gemini permits something but doesn't have it out of the > box, people will create another layer. It's natural I believe > 🤷♀️ As far as I can tell, you can build anything on top of pretty much anything sending and receiving data between two points. However, that does not imply, it is a good idea. gemini the protocol per se is a way to serve file content. Apparently a lot of people think, but how can I make it do X or Y too? And in my not so humble opinion, there are protocols better suited for some or these things. Take "uploading" text. There is sftp or scp at least. It requires an account on the receiving side. Yes, well, imho that's a feature and not a shortcoming. ymmv. Cheers, ~ew -- Keep it simple!
On Sat, 2021-07-10, Jonathan McHugh wrote: > While I understand that it has a cryptographic definition, is it > possible to have/use another term than 'nonces'? I don't know of a good alternative. In any case, Merriam-Webster [1] says that "nonce" is used since the 13th century with the meaning "the one, particular, or present occasion, purpose, or use" - basically the same as in crypto. Urban Dictionary [2] has a 21st century definition: "British slang for pedophile". Rather than killing the word, I think it's better to not allow some new regional slang affect our common use of it. > Having grown up watching the satirical series, Brass Eye... I looked it up and I like it, thanks! [1] https://www.merriam-webster.com/dictionary/nonce [2] https://www.urbandictionary.com/define.php?term=Nonce
On Sun, 11 Jul 2021 at 07:30, ew.gemini <ew.gemini@nassur.net> wrote: Apparently a lot of people think, but how can I make it do X or > Y too? And in my not so humble opinion, there are protocols > better suited for some or these things. Take "uploading" text. > There is sftp or scp at least. It requires an account on the > receiving side. Yes, well, imho that's a feature and not a > shortcoming. ymmv. > I don't think that's a bad thing, speaking for myself here I could immediately see the benefits of Gemini and I wanted to build things using it. Were they a good fit for Gemini? Maybe not, but at its heart text is the simplest of file types. Other protocols like NNTP and SMTP have long had ways of dealing with that. It's not unreasonable that people might expect Gemini to have a way of dealing with multi-line user-submitted text content. I live ~5 miles from one of the poorest areas in the UK. The only devices people are likely to have access to are tablets or cell phones. SFTP is not so much fun on those types of devices or with users from demographics who maybe aren't old enough to remember having to FTP their content to a web server somewhere. If all people want for Gemini is to use other protocols to upload content, that's absolutely fine. I'm not here to bash Gemini. Quite the opposite. People want to add layers on top of Gemini which maybe aren't such a good idea precisely because Gemini has highly desirable features. davx
Well, maybe Gemini browsers should add some of these other protocols so that users can do more, with better-suited things. Devin Prater r.d.t.prater@gmail.com Https://devinprater.flounder.online > On Jul 11, 2021, at 6:49 AM, David Messer <davx8342@gmail.com> wrote: > > > On Sun, 11 Jul 2021 at 07:30, ew.gemini <ew.gemini@nassur.net <mailto:ew.gemini@nassur.net>> wrote: > > Apparently a lot of people think, but how can I make it do X or > Y too? And in my not so humble opinion, there are protocols > better suited for some or these things. Take "uploading" text. > There is sftp or scp at least. It requires an account on the > receiving side. Yes, well, imho that's a feature and not a > shortcoming. ymmv. > > I don't think that's a bad thing, speaking for myself here I could immediately see the benefits of Gemini and I wanted to build things using it. Were they a good fit for Gemini? Maybe not, but at its heart text is the simplest of file types. Other protocols like NNTP and SMTP have long had ways of dealing with that. It's not unreasonable that people might expect Gemini to have a way of dealing with multi-line user-submitted text content. > > I live ~5 miles from one of the poorest areas in the UK. The only devices people are likely to have access to are tablets or cell phones. SFTP is not so much fun on those types of devices or with users from demographics who maybe aren't old enough to remember having to FTP their content to a web server somewhere. > > If all people want for Gemini is to use other protocols to upload content, that's absolutely fine. I'm not here to bash Gemini. Quite the opposite. People want to add layers on top of Gemini which maybe aren't such a good idea precisely because Gemini has highly desirable features. > > davx
Devin Prater <r.d.t.prater@gmail.com> writes: > Well, maybe Gemini browsers should add some of these other protocols so that users can do more, with better-suited things. Yes, i'm not aware of any reason why SFTP[a] functionality has to be presented with a command-line interface like e.g. ftp(1), or a graphical interface like e.g. Filezilla. Once there's a wrapper for SFTP in one's programming language of choice[b] - and SFTP is so well-established that there's more likely to be a wrapper than not - the UX can be oriented towards whichever group of users the dev(s) wish. And the conscious simplicity of Gemini protocol make its easier for different devs to create and maintain clients supporting different demographics. Upthread, ~ew wrote: > Apparently a lot of people think, but how can I make it do X or Y too? And in my not so humble opinion, there are protocols better suited for some or these things. Fwiw, i agree. In this particular case, the fact that SFTP has an implementation in the OpenSSH suite means that the protocol has had many security-conscious people reviewing it and thinking about it - at the very least, far more than any new Gemini-oriented protocol for uploads is likely to have for quite some time. It makes sense to me to leverage a battle-hardened (even if not, of course, flawless) protocol, and find a friendly way of presenting it to non-tech users. Alexis. [a] SFTP rather than SCP because, as the SFTP Wikipedia page notes: > SFTP attempts to be more platform-independent than SCP; with SCP, for instance, the expansion of wildcards specified by the client is up to the server, whereas SFTP's design avoids this problem. While SCP is most frequently implemented on Unix platforms, SFTP servers are commonly available on most platforms. The file transfer is fast in SCP when compared to the SFTP protocol due to the back and forth nature of SFTP protocol. In SFTP, the file transfer can be easily terminated without terminating a session like other mechanisms do. > > SFTP is not FTP run over SSH, but rather a new protocol designed from the ground up by the IETF SECSH working group. It is sometimes confused with Simple File Transfer Protocol. [b] A quick search came up with https://github.com/pkg/sftp for Go, https://docs.rs/ssh2/0.3.2/ssh2/index.html for Rust, https://pypi.org/project/pysftp/ for Python, etc.; though i don't develop in any of those languages, so can't comment on the quality of these wrappers.
Sure, I get all that. I still needed to say it given its ability to illicit harm (careful with that axe Eugene...). Hopefully a less tainted descriptor will emerge. FYI, it was frequently used as a slur against homosexuals - which is where the conflation really caused (potentially indelible) harm. Its not my history to tell and Im not sure this thread needs more introspection on this matter. Enjoy Brass Eye (especially Drugs, Paedophiles and Decline), as well as its precursor, The Day Today. The people behind the series have been successful with many projects. Jonathan McHugh ==================== indieterminacy@libre.brussels July 11, 2021 1:09 PM, "nervuri" <nervuri@disroot.org> wrote: > On Sat, 2021-07-10, Jonathan McHugh wrote: > >> While I understand that it has a cryptographic definition, is it >> possible to have/use another term than 'nonces'? > > I don't know of a good alternative. In any case, Merriam-Webster [1] > says that "nonce" is used since the 13th century with the meaning "the > one, particular, or present occasion, purpose, or use" - basically the > same as in crypto. Urban Dictionary [2] has a 21st century definition: > "British slang for pedophile". Rather than killing the word, I think > it's better to not allow some new regional slang affect our common use > of it. > >> Having grown up watching the satirical series, Brass Eye... > > I looked it up and I like it, thanks! > > [1] https://www.merriam-webster.com/dictionary/nonce > [2] https://www.urbandictionary.com/define.php?term=Nonce
IMO the best workaround would be to have clients ask if it should use a client certificate when it reaches the URL from a cross-origin link or redirect -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Sat, 2021-07-10, nervuri wrote: > 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 we go: https://gitlab.com/gemini-specification/protocol/-/issues/37
On Tue, 2021-07-13, mbays wrote: > "MUST prompt" seems too strong to me. For redirects an explicit prompt > is necessary, but for just following a link into the scope of a new > certificate, I think it is sufficient if the link to be presented in > a way which makes explicit the precise URI and what certificate would be > used for it. (This is how diohsc works currently, and I think it's > fine.) Good point. What we really want is for the user to be clear on "the precise URI and what certificate would be used for it", as you said. I think your client is unique in how it presents the two together. Diohsc [1] looks very interesting, by the way. OK, let's change the wording. How about this: "Before following a URI which is in scope of a client certificate from a page (or via a redirect) outside of that scope, clients MUST display the target URI and what client certificate will be used to connect to it." We may need to go into more detail, though, since: - multiple client certificates can be in the same scope - one scope can be the "parent" of another in the path tree - the rule should apply if *any* URI in the redirect chain is outside of the client cert's scope [1] gemini://gemini.thegonz.net/diohsc/
On Thu, 2021-07-15, mbays wrote: > Better. But I think "display" is still assuming too much about the > client. What about audio-only clients? We could make it "present", but > still we may find that it's too restrictive... what if a client wants to > present only a shortened form of the URI, say without the scheme? Do we > really want to say that it's in contravention of the spec? And so on. "Display" is used throughout the spec. I'm fine with using a more general term like "present", but maybe a separate issue should be opened for replacing all instances of "display". And, yes, I do think clients ought to include the scheme, especially those that support multiple protocols; I don't see this as a blocker. > Really, I don't think this kind of prescriptive text for the details of > how clients should operate belongs in the spec at all. That's what the specification is: prescriptive text for how clients should operate. If the text makes sense, we should add it, and this is a small requirement that brings a big benefit, as with web browsers using SameSite by default. > Perhaps it would make more sense to add some general discussion about > this issue, either to the spec or to best-practices.gmi, saying that > clients should ensure that a client certificate is used only when it's > clear that the user intends it to be, and pointing out these cases where > it might not be clear (links and redirects into the scope of > a certificate). Then let client authors decide how to implement this in > whatever way makes most sense for their particular clients. This would also be good. As I wrote on GitLab, «"MUST" is what I think makes the most sense, as it provides the most protection without any serious downside. But if I'm wrong about that, then taking it down to "SHOULD", or putting it into the best practices document, is still way better than nothing.» So, here's the next iteration of the text: Before following a URI which is in scope of a client certificate from a URI outside of that scope, clients MUST/SHOULD display the target URI and what client certificate would be used to connect to it. Doing this will help protect against Cross-Site Request Forgery (CSRF). It applies to: * following a link on a page * going through one or more redirects We could expand on this with a short explanation of CSRF and maybe an example.
On Fri, 16 Jul 2021 at 09:55, nervuri <nervuri@disroot.org> wrote: > > Before following a URI which is in scope of a client certificate from > a URI outside of that scope, clients MUST/SHOULD display the target > URI and what client certificate would be used to connect to it. > > Doing this will help protect against Cross-Site Request Forgery > (CSRF). It applies to: > * following a link on a page > * going through one or more redirects > How about the following? "A client MUST NOT make a request to a URI in the scope of a client certificate outside the current scope, unless the user explicitly allows the request. The client SHOULD present the full target URI to the user." This solves some of the issues with 'display' and makes the part about user control more clear IMO. Maybe it would be good to mention it's ok to make the request without the client cert? -- -Oliver Simmons (GoodClover)
On Fri, 16 Jul 2021 at 11:45, Oliver Simmons <oliversimmo@gmail.com> wrote: > The client SHOULD present the full target URI to the user. Should say "full target URI and client certificate". -- -Oliver Simmons (GoodClover)
On Fri, 2021-07-16, Oliver Simmons wrote: > How about the following? > > "A client MUST NOT make a request to a URI in the scope of a client > certificate outside the current scope, unless the user explicitly > allows the request. The client SHOULD present the full target URI to > the user." Yes, I think I prefer the "MUST NOT ... unless ..." structure, but after putting this rule in code form [1], I came away wanting a more verbose and precise formulation. It may seem overkill, but I think it's worth it for the sake of clarity: Since each client certificate is bound to a scope, we define cross-scope requests as requests made by interactive clients starting at URI 1 and going to URI 2, where the following conditions are true: * URI 2 is in scope of an active client certificate; * URI 1 is not in that same scope; * the user did not explicitly input URI 2. Such requests can occur when following a link on a page or following one or more redirects. An interactive client MUST NOT use a client certificate when making a cross-scope request, unless the user explicitly allows it after being shown the full target URI and an indication of what client certificate would be used to connect to it. This is to protect against Cross-Scope Request Forgery (CSRF), a type of attack in which the user is tricked into executing unwanted actions in a Gemini application in which they’re currently authenticated - for example by following a redirect from `gemini://malicious.org/kittens.png` to `gemini://gemini.forum/account/delete`. I would add this to the end of section 4.3. I'll leave it at this. When they find the time, Sean or Solderpunk can decide whether to add this and what wording to go with. [1] https://gitlab.com/gemini-specification/protocol/-/issues/37#note_629384688
---