97c70 - 1y
I'm working on improving routing on Coracle, and ran into the issue of deep-linking creating attack vectors for malicious links. To a certain extent, this is unavoidable, people can always direct someone to a bad event or link unless there's no navigation at all. I'm more concerned about attackers being able to inject a malicious relay into Coracle, for example https://coracle.social/notes?relays=wss://my-evil-relay.com in order to phish someone's pubkey and correlate their identity. How bad is this? I'm inclined to leave relay deep-linking out. But then relays are a resource in their own right, so I don't know if it's possible. Maybe ask for user approval before connecting to any relay not in their own relay list? This would cover malicious relay injection via NIP 65 as well.
Boston Wine @bostonwine - 1y
Love the “ask for approval” approach. Maybe include a warning/disclaimer. User choice is always the best play 🤙
captjack 🏴☠️✨💜 @captjack - 1y
#multiplexer
Some, but metadata won't solve this problem if clients act automatically
Possibly, but I doubt any clients do that currently.
7cc32 - 1y
In regards to this.. being a nos2x approve single signatures only maxi.. I've noticed I can no longer use this method for two reasons: it wants to decrypt my DMs, it wants to sign http auth messages (for relays that I am not a user on).. so it's an endless stream of nos2x. That being said, I don't mind it connecting to any relay necessary, as asking for approval would likely lead to a similar situation of endless approval..
Yeah, I'm aware of that. It's unfortunate, but necessary in order to do work in the background. Maybe at some point I can improve the UX for control freaks like you 😉 For relay approval, I would likely keep a list of approved relays (and default to using those) so you wouldn't have to approve the same relay multiple times.
Malicious in the sense of surveillance/phishing. So say someone sends you an email with a link pointing to `/notes?relays=wss://bad-relay.com/myemailinbase64`, you click on it and your client auto-signs an AUTH challenge, bingo bongo they have correlated your email/pubkey. Basically an injection attack. As it happens, nostr:nprofile1qqs8hhhhhc3dmrje73squpz255ape7t448w86f7ltqemca7m0p99spgpp4mhxue69uhkummn9ekx7mqprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqythwumn8ghj7enfd36x2u3wdehhxarj9emkjmn9keq8hx pointed out that this is already possible using nprofile/nevent 😬
I'm not sure this is a real issue, but it does highlight the fact that if you combine 1. user-generated content and 2. arbitrary server connections you drastically increase your attack service area nostr:nevent1qqszceqdtteqgm8xj6r0u4ly82grs6mzmwdtq3mk4lzzp2jus8vju9qpz3mhxue69uhhyetvv9ujuerpd46hxtnfdu90gza2
Coracle does (this needs to be improved)
If the relay knows your pubkey they know your contacts. It's probably not hard to infer who you are from your filters, in most cases probably trivial, but client fingerprinting could also be implemented.
Yes, I like that a lot. I think I saw a new extension recently that took this approach
Coracle auto-authenticates with relays, which requires a signature. Maybe I'll disable that by default.
daniele @dtonon - 1y
I think that asking when a relay is unknown is an effective strategy, that doesn't ruin the UX. You can always check the already approved relays first and try to fetch the note from them, this would slow down the loading a bit, but it makes the process completely transparent for a good amount of notes/profiles.
Really interesting brainstorming by nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn on a possible privacy attack vector on nostr. Nostr is different and so are the security paradigms, therefore we have to think outside the box to find every possible vulnerability. nostr:nevent1qqs0xmg7s8xeeq94u7fjrelm7qj503z2trzjyyl0gp0fqfupgm40veqpz3mhxue69uhhyetvv9ujumn0wd68ytnzvupzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqvzqqqqqqy9djts8
It's pretty simple, basically just a challenge string that has to be signed in a particular way — no expiration or anything, because a relay can invalidate the session whenever they feel like it. In the future, I think it would be cool to authenticate with pubkeys other than your own (for example a single purpose pubkey exclusively used for holding a badge awarded by the relay admin). Lots of interesting possibilities. https://github.com/nostr-protocol/nips/blob/master/42.md
Yep, because nos2x and manual-approve mode on Alby spam the user with signing requests
Exactly, ultimately I agree that granular control is the target, this is just a UX stopgap
Mazin @mazin - 1y
Given the increased surveillance risk of automatically AUTHing to any relay that asks, this should be a relay specific toggle, something you can turn on/off for each relay. The nostr.land relays are serving optional auths on connect only so they can track REQs by pubkey. People should be careful and only AUTH when there is a reason…
I’m not saying relays can’t track you today, they absolutely can. It’s just about how easy you make it. You could make it more difficult by rotating your IP and only sending events through a proxy, etc etc. AUTHing every user on connect (for no practical read-access reason) just makes it much, much easier.
I’m not sure exactly what signatures you’re concerned about but NIP-42 AUTH comes with a challenge string so each signing request is unique (if that is relevant to your issue).
