ahhhh... yeah that could be a problem if your client is only thinking it is talking to one relay
well, it could be fixed with an extra tag maybe... only the challenge is really important
it would be great to have a full proxying relay like this that does auth because you can't access your DMs or use paid relays without auth
i'd be happy to consult with you about making a NIP for proxying where the signed response can be different to the relay asking for it
I do not think this could be solved easily with new nip / modification on nips.
i have made a proposal to relax the requirement of the matching relay tag, as it's actually irrelevant anyway
with this accepted and relays changed to this the problem doesn't require any action by clients to make your project able to do auth proxying without making the user's nsec more vulnerable
I disagree with the proposal. Relays do this in order to only allow certain kind of events to be retrieved to specific users only.
Doing the otherwise will obviously break it is purpose to become secure.
I would say it is not due to it is security, rather than privacy itself.
the auth request (challenge) is sent from a relay to the client, this value is meaningless to anyone else
only the client can sign it, and anything else in the message is irrelevant
nobody can sign with the valid public key and challenge except the holder of the private key, so why does the relay address matter?
i already got one ack on this proposal and i am pretty confident the rest will ack also
and it solves the problem that makes your project more or less useless if you care about not exposing your nsec to remote attackers to hardware not in your direct physical control
this will mean that you can add one small feature to your project where it forwards AUTH messages back and forth to the relays, it only needs to keep track of the challenge and relay address so it forwards the auth response to the relay that will recognise it (and btw, typically these live for only 20 seconds at best).
I am still disagree with this proposal anyway.
https://github.com/nostr-protocol/nips/issues/1013#issuecomment-1921424702
And if you want to solve this problem just because of my project bostr, We do not need to change the current NIP. That proposal is stupid.
The fix is basically just implement nsecbunker for handling NIP-42 in bostr. However i do not have plan to do it anyway as people is still rarely using nsecbunker feature.
no, i want to change the nip42 because i think it's an irrelevant feature and constriction of the thing and i have been dreaming of nostr proxies since like 3 months
so i don't know why you are saying this is a bad thing
do you have a reason based on cryptography and network security theory why it's important to send a challenge and then require that be constrained by some arbitrary government registered address?
Relay spoofing.
Aside of revealing who are people talking to with PMs, it also breaks paid relays.
so you mean a replay attack, send a challenge without this
ok, then i am gonna revise this because the second problem is that the challenge should have this in the string or relay spoofing
in most challenge/response auth protocols you actually sign ONLY on the challenge string
in this nip42 you sign on a heap of other things, it's not relevant, there is no reason why the relay tag has to be there, at all.
Of course that tag was to validate that the client actually talks to the relay DIRECTLY.
Faked / sniffer: Auth please
Client:
Upstream relay to faked: The client AUTH response is not even having a match URL as mine. Ignoring.
i've amended my proposal to add the relay address to the challenge and to giftrap the response so that the MITM doesn't see the response signature
The effective one is still on hostname validation. Even we do with giftwrapping, Raw event (encrypted message content) will still be seen anyway.
*sigh*
the message should not just have a challenge but a challenge pubkey, and then the response can be encrypted, and it can be done over a proxy
TLS has been broken several times before, it's not immune to various kinds of MITM and side channel attacks, and enabling proxy relays opens up a heap of options for relay services
What do you want to encrypt?
The challenge message?
It won't work anyway.
If you try to encrypt the entire event JSON, You are making things harder than nostr promised.
What NIP-42 actually does is basically this:
Relay: Who are you?
Client: I am
Relay: Hello
And then the relay know who the client was, and allows some certain events to be retrieved.
