Of course that tag was to validate that the client actually talks to the relay DIRECTLY.

Reply to this note

Please Login to reply.

Discussion

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 connected to .

Relay: Hello . Yes is me.

And then the relay know who the client was, and allows some certain events to be retrieved.