[Dxspider-support] Forgeries

[Dirk Koopman]

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