[Dxspider-support] Forgeries
Dirk Koopman
djk at tobit.co.uk
Mon Mar 10 12:29:49 GMT 2025
On 07/03/2025 20:34, IZ2LSC via Dxspider-support wrote:
> I see a lot of naivety in your messages. Or maybe you don't understand
> the true nature of the problem. The various checks of the authenticity
> of the spots (i.e whitelist), cannot be based on the information
> contained in it (for example the source node, ip address, and so on),
> because all this information can be forged at will by the attacker.
>
The basic problem is that we have an open system that tries to emulate
(with several improvements) a MS-DOS program based on two floppy disks
that was around in the 1990s. It has been clear to me for some time that
we have reached the limit of what is possible with the protocol as it
stands today. The issue is that the "important" (user focused) parts of
the protocol can be easily forged and it appears that a number of
actors, over the past few years, have decided to do just that. And I
agree that $senderverify does not provide a complete solution. It is, at
best, a bandaid.
So, what to do? Firstly the only stuff that is truly easy to spoof -
effectively - is the non-PC9x protocol stuff. Which these days means
spots (PC11, PC61) and user data (PC41). The PC9x protocol stuff is much
less easy to spoof as it is very closely time sensitive. It is
conceivably possible interfere with a closely connected node, but it
would require both accurate timing and protocol input that is plausible
enough to convince the receiving node. It cannot be done reactively as
"out of time" PC9x sentences will just be dropped. My instant thought
would be to implement (say) the PC91 spot protocol that has the same
information as a PC61, albeit in a slightly different order (annoyingly
for me). It *could* be a PC93 variant, but in either case I will have to
work out (from the PC18) which spot sentence version to use. Which
potentially creates a new level of pain for me to make sure that every
previous version of (insert name of node software here) still works as
before.
Or we could throw most of the protocol away - start again - with
something else that has some kind of more rigorous validation in place.
Oh, and a set of truly trusted node partners that can't send crap in the
first place. And, this really sticks in my craw, it would probably have
to be "closed source".
Or we can close completely to "non-trusted" node partners and
unregistered(passworded) users.
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
systems) that can control who gets the software and then joins their
network. There also seems to be a degree of day to day oversight that I
cannot emulate. As DXSpider has 500+ instances out there, that cat is
not only out of the bag, but has bred generations of kittens all over
the world. As usual, I appear to (literally) be the author of my own
(and your) misfortune.
73 Dirk G1TLH
More information about the Dxspider-support
mailing list