Hello g00r00!
I have done some more current testing with BBBS and Mystic regarding echo >security. In the test situation I had the following system arrangement:
Feed Hub Downlink
------------------------------------------------------------------------
AKA: 1:261/38 1:282/1032 1:14/5 >Software: BBBS v4.10 Toy-3 Mystic v1.12-A33 BinkD 1.0.5-pre5/Hpt
If I originate a message on the hub Mystic system and send it to the feed >system.
The mail packet is received and processed without error. But, if I originate a >message on the downlink system and send it thru the hub system to the feed >system. Then the feed system will reject the packet as a security violation.
A snippet of the feed's processing logs indicate the following:
170616 01:30 Processing packet 0974724d.pkt from 1:282/1032.0, 541 bytes. >170616 01:30 Processing packet 098b0d9f.pkt from 1:282/1032.0, 773 bytes. >170616 01:30 Secure violation: 1:14/5.0 in FIDOTEST
One packet had a reply that originated on the hub system and the second packet >had a reply that originated on the Downlink system. Both messages were replies >to a message in the FIDOTEST echo. BBBS only rejected the message that >originated
on the Downlink system.
Jeff
--- GoldED+/LNX 1.1.5-b20161221 / Mystic v1.12-A33 (Linux/64)
* Origin: The OuijaBoard Too - Anoka. MN (21:1/128)
Here are my findings, and they are the same they were last time we did this. >Feel free to pass this along to anyone on the BBBS side who is familiar with >the issue and technical enough to understand it:
I created a 3 node network all of Mystic BBS so that packets could be >identified through all steps. The network topology is as follows:
MAIN HUB Address=55:5/1
OTHER HUB Address=55:5/2 sends to 55:5/1 and feeds 55:5/5
NODE Address=55:5/5 sends to 55:5/2
So the flow is that a message on 55:5/5 gets sent to 55:5/2 and then pushed >through to 55:5/1. PKT files were captured at each stage of the transfer and >checked for validity. All packet headers are correct throughout:
1) PKT headers originating from 55:5/5 to 55:5/2 has the correct origin and
destination addresses (from 55:5/5 and to 55:5/2). Messages within the
packet correctly originate from 55:5/5 and destination to 55:5/2
2) PKT headers originating from 55:5/2 to 55:5/1 has the correct origin and
destination addresses (from 55:5/2 to 55:5/2). Messages within the packet
correctly originate from 55:5/5 (the address of the message origin as per
Fido standard FTS-0001) and correctly destinate to 55:5/1
Maybe BBBS is checking the FROM address of actual messages and expecting them >to be the address of the downlink? This is not correct as they contain the >address of the actual message origin (for reasons such as replying by netmail).
This is directly addressed in FidoNet standards documentation FTS-0001:
"Due to routing, the origin and destination net and node of a packet
are often quite different from those of the messages within it, nor
need the origin and destination nets and nodes of the messages within
a packet be homogeneous."
In conclusion, Mystic's PKT files in this scenario have no warnings or
issues with any other tossers, and comparisons to the FTS documentation
shows no invalid data, nor does any known packet viewer software report
any issues (**).
I can setup other tossers and compare PKTs in the same situation as well, but >the bottom line is that it may be up to the BBBS side to take some >responsibility and look into this as well...
It's been over a year now and no one has found an issue on the Mystic side, and
the bottom line is I cannot fix what I cannot identify as broken. If someone >on the BBBS team could clarify exactly what BBBS is finding wrong, that may be >helpful in moving forward as well.
(**)
Packets were captured and viewed at each node, and verified accurate by
using INSPECTA, PKTVIEW, and PKTDUMP. All viewers correctly identified the >2+ packet without error, and all show the correct addressing.
--- Mystic BBS v1.12 A34 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
I think it sees the msgid field and balks there. That's what the logs she >sent me see to indicate.
I think Janis did reach out to jeff and the bbbs author. Maybe we can run >this to ground. My question would be: why is this only an issue in Mystic? >Not saying it's mystics fault, but rather, if all other bbs software follows >correct protocols why is this
Janis sticks by her guns that all others work with no issues and i know for >sure at least Marc Lewis sends mail through her.
Again not saying it's mys, asking why that's contained to Mystic. That's what >doesn't make sense.
On 08:54 16/06 , g00r00 wrote:
Here are my findings, and they are the same they were last time we did this. >>Feel free to pass this along to anyone on the BBBS side who is familiar with >>the issue and technical enough to understand it:
I created a 3 node network all of Mystic BBS so that packets could be >>identified through all steps. The network topology is as follows:
MAIN HUB Address=55:5/1
OTHER HUB Address=55:5/2 sends to 55:5/1 and feeds 55:5/5
NODE Address=55:5/5 sends to 55:5/2
So the flow is that a message on 55:5/5 gets sent to 55:5/2 and then pushed >>through to 55:5/1. PKT files were captured at each stage of the transfer and >>checked for validity. All packet headers are correct throughout:
1) PKT headers originating from 55:5/5 to 55:5/2 has the correct origin and >> destination addresses (from 55:5/5 and to 55:5/2). Messages within the
packet correctly originate from 55:5/5 and destination to 55:5/2
2) PKT headers originating from 55:5/2 to 55:5/1 has the correct origin and >> destination addresses (from 55:5/2 to 55:5/2). Messages within the packet >> correctly originate from 55:5/5 (the address of the message origin as per >> Fido standard FTS-0001) and correctly destinate to 55:5/1
Maybe BBBS is checking the FROM address of actual messages and expecting them >>to be the address of the downlink? This is not correct as they contain the >>address of the actual message origin (for reasons such as replying by >netmail).
This is directly addressed in FidoNet standards documentation FTS-0001:
"Due to routing, the origin and destination net and node of a packet
are often quite different from those of the messages within it, nor
need the origin and destination nets and nodes of the messages within
a packet be homogeneous."
In conclusion, Mystic's PKT files in this scenario have no warnings or >>issues with any other tossers, and comparisons to the FTS documentation >>shows no invalid data, nor does any known packet viewer software report
any issues (**).
I can setup other tossers and compare PKTs in the same situation as well, but >>the bottom line is that it may be up to the BBBS side to take some >>responsibility and look into this as well...
It's been over a year now and no one has found an issue on the Mystic side, >and
the bottom line is I cannot fix what I cannot identify as broken. If someone >>on the BBBS team could clarify exactly what BBBS is finding wrong, that may be
helpful in moving forward as well.
(**)
Packets were captured and viewed at each node, and verified accurate by >>using INSPECTA, PKTVIEW, and PKTDUMP. All viewers correctly identified the >>2+ packet without error, and all show the correct addressing.
--- Mystic BBS v1.12 A34 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
--
yrNews Usenet Reader for iOS
http://appstore.com/yrNewsUsenetReader
--- Mystic BBS/NNTP v1.12 A33 (Linux/64)
* Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (21:1/107)
I think it sees the msgid field and balks there. That's what the logs she sent me see to indicate.
Again not saying it's mys, asking why that's contained to Mystic. That's what doesn't make sense.
I may be able to band-aid Mystic so that it works, but I can't even do that unless I know what BBBS is trying to do during that security check.
(Also if it IS looking at the message from and to addresses, I've shown
in the FidoNet Standards documentation that it is wrong of BBBS to do
so).
I think it sees the msgid field and balks there. That's what the logs she sent me see to indicate.
I wouldn't suspect a MSGID would have any play in this. Can I see the log?
Again not saying it's mys, asking why that's contained to Mystic. That's what doesn't make sense.
Her logic behind why its Mystic's fault doesn't carry a lot of weight. fsxNet >alone has like 120 systems with probably just about every software combination >you can think of. If Mystic were broken, then some of those 120 systems would >also be giving errors, yet none of them do. The error only occurs with BBBS.
Point your BBS at anything that isn't BBBS and your mail will transfer fine!
If she thinks its Mystic I am completely open to that, but someone needs to >show what its doing wrong so that I can fix it. Just saying its Mystic without
any real explanation will resolve nothing. Anyway...
We need to know what BBBS is checking during tossing that results in that >message, and then we need to know what its expecting to find. This is >hopefully something the author could answer with very little effort.
I may be able to band-aid Mystic so that it works, but I can't even do that >unless I know what BBBS is trying to do during that security check.
(Also if it IS looking at the message from and to addresses, I've shown in >the FidoNet Standards documentation that it is wrong of BBBS to do so).
--- Mystic BBS v1.12 A34 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
On 06/16/17, g00r00 pondered and said...
I may be able to band-aid Mystic so that it works, but I can't even do that unless I know what BBBS is trying to do during that security check.
(Also if it IS looking at the message from and to addresses, I've shown in the FidoNet Standards documentation that it is wrong of BBBS to do so).
Pat on the back from me... I think you're doing all you can to engage in this >issue and work with a few folks here that are also working to provide >informed telemetry to help solve things (shoutout to Jeff).... so yep, I hope >the BBBS author can also come to the party and shine some light on things.
With respect to fsxNet there are a bunch of nodes running Mystic and all >sorts of other systems talking to them too and I have not seen any reports of >this kind of issue outside BBBS.
Best, Paul
--- Mystic BBS v1.12 A33 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)
On 06/16/17, g00r00 pondered and said...
Pat on the back from me... I think you're doing all you can to engage
in this issue and work with a few folks here that are also working to provide informed telemetry to help solve things (shoutout to Jeff)....
so yep, I hope the BBBS author can also come to the party and shine
some light on things.
With respect to fsxNet there are a bunch of nodes running Mystic and
all sorts of other systems talking to them too and I have not seen any reports of this kind of issue outside BBBS.
Point your BBS at anything that isn't BBBS and your mail will transfer fine!
| Sysop: | sneaky |
|---|---|
| Location: | Ashburton,NZ |
| Users: | 31 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 131:41:56 |
| Calls: | 2,073 |
| Files: | 11,136 |
| Messages: | 947,522 |