[Dxspider-support] Forgeries

[IZ2LSC]

Rudy,
following your example:
//
1/ Cluster A has defined SSID N2WQ-1 with FQDN cluster.n2wq.com as partner
2/ Cluster A receives a telnet connection request and the other party
claims it is N2WQ-1
3/ Cluster A resolves the FQDN for N2WQ-1 to IP
4/ If the connection request from whoever claims to be N2WQ-1 originates
from the resolved FQDN, the connection is accepted and partner handshake
sequence begins
5/ Otherwise Cluster A drops the connection.
//

Now suppose that you are the sysop of Cluster A and I'm the bad guy
managing N2WQ-1.
Once I get your trust, I start flooding using N2WQ-1 as an intermediate
node. Consider that as sysop of N2WQ-1 I can easily modify this node to
accept everything, even forged spots.
And you as Cluster A sysop you are fully convinced that N2WQ-1 is trusted
so maybe the flooding is injected by someone else downward connected to
N2WQ-1.
And actually this is exactly what is happening today. We have an entry
point and we are not able to identify it.
What we lack, and I already raised this point months ago, is an
effective way to track the path of each spot to get close to the source.
Something like AS-PATH in BGP or Via header in SIP.

73s

Andrea

-->


On Wed, Mar 12, 2025 at 2:20 AM Rudy Bakalov via Dxspider-support <
dxspider-support at tobit.co.uk> wrote:

> 1/ Cluster A has defined SSID N2WQ-1 with FQDN cluster.n2wq.com as
> partner
> 2/ Cluster A receives a telnet connection request and the other party
> claims it is N2WQ-1
> 3/ Cluster A resolves the FQDN for N2WQ-1 to IP
> 4/ If the connection request from whoever claims to be N2WQ-1 originates
> from the resolved FQDN, the connection is accepted and partner handshake
> sequence begins
> 5/ Otherwise Cluster A drops the connection.
>
> The FQDN acts like a shared key. It doesn’t need to be secret. Simple and
> elegant.
>
> Rudy N2WQ
>
> Sent using a tiny keyboard.  Please excuse brevity, typos, or
> inappropriate autocorrect.
>
>
> On Mar 11, 2025, at 6:43 PM, Dirk Koopman via Dxspider-support <
> dxspider-support at tobit.co.uk> wrote:
>
> 
> There is no auth scheme that I can think of right now that does not
> involve some kind of secret sharing between nodes. If we are going to go
> down that road then we may as well just do the job properly and start to
> use PKI SSL connections with each node connection pair giving each other a
> PKI pair. We *may* be able to share the public keys around but we will need
> to fiddle about with client PKI certs because each side needs to verify the
> other. But that will result in a separate network of nodes that will trust
> each. Then we will get the howls of protest about all those juicy "missing"
> spots from outside this new (more) secure network.
>
> More knowledgeable information to square this circle gratefully received
> (offline please).
>
> Dirk
>
> On 10/03/2025 19:12, Christopher Schlegel via Dxspider-support wrote:
>
> Nevermind. Theory, was not well thought out and I keep hitting
> roadblocks...
>
> Chris, WI3W
>
> On Mon, Mar 10, 2025, 10:06 Christopher Schlegel <sutehk.cs at gmail.com>
> wrote:
>
>> Dirk,
>>
>> How hard would it be to implement a hashed check into the PC92 protocol.
>> I.e. I log into WI3W-2, receive a randomly generated number/string used to
>> verify tx/rx between the user and node. Kind of like pub/priv keys but only
>> to generate the check. As long as the check is valid keep the connection,
>> if not, boot it.
>>
>> Or, something similar. Spot validation? I'd expect CPU processing to tick
>> up a little, but most machines in use should not choke.
>>
>> 73,
>>
>> Chris, WI3W
>>
>> On Mon, Mar 10, 2025, 09:45 Mike McCarthy, W1NR via Dxspider-support <
>> dxspider-support at tobit.co.uk> wrote:
>>
>>> A small number of nodes, yes, but with about 1/4 of the total users of
>>> the global cluster network. VE7CC-1 alone has over 800 on any given day.
>>>
>>> On 3/10/2025 8:29 AM, Dirk Koopman via Dxspider-support wrote:
>>>
>>> > Which means that input from the CCluster/ARCluster system would
>>> > disappear as they are still using the same protocol as we are and
>>> > therefore just as untrusted as anyone else. Their big advantage is
>>> that
>>> > there are a relatively small group of nodes with an author (or other
>>>
>>> --
>>> 73 de Mike, W1NR
>>>
>>> THAT was the equation. EXISTENCE!... SURVIVAL... must cancel out...
>>> programming!
>>>
>>> - Ruk -
>>>
>>>
>>> _______________________________________________
>>> Dxspider-support mailing list
>>> Dxspider-support at tobit.co.uk
>>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>>
>>
> _______________________________________________
> Dxspider-support mailing listDxspider-support at tobit.co.ukhttps://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250312/12578282/attachment-0003.htm>