Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции FTSC_PUBLIC
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции FTSC_PUBLIC с датами от 13 Sep 13 18:57:24 до 01 Apr 24 01:17:44, всего сообщений: 7124
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 5150 из 7124 ====================================== FTSC_PUBLIC =
От   : Ozz Nixon                        1:1/123            09 Mar 20 05:16:41
Кому : Joachim Probst                                      09 Mar 20 05:16:41
Тема : Two changes to BinkP inquiry...
FGHI : area://FTSC_PUBLIC?msgid=1:1/123.0+5E65CECF
На   : area://FTSC_PUBLIC?msgid=2:240/6309+5e637427
= Кодировка сообщения определена как: ASCII ==================================
Ответ: area://FTSC_PUBLIC?msgid=2:240/6309+5e6a6358
==============================================================================
>*.req files follow the FTS-0006.002 guideline of file requests. That file
>format is supporting passwords. Each line in the *.req file starts with the
>filename of the requested file and may be followed by a blank, an exclamation
>mark and the password.
 
M_NUL OPT MD5-CRAM-<string> was introduced to produce a more secure
protocol over insecure sessions. The HMAC repliy from the originator
makes it next to impossible for MTM packet snooping like you have
mentioned to monitor how a protocol is working (which only happens over
insecure sessions), thus your *.REQ file with its antiquated !pwd would
allow MTM attacks to see a password in plain text. My concept avoids
this, as the M_REQ password on a HMAC session cannot be "replayed", it
was only valid for that session.
 
Having multiple handshakes on a single port, I understand can muddy the
water, however, the companies I have worked for, getting more than one
protocol port open on the front-end firewall is a challenge let along
security compliance requirements for auditing the need for multiple
ports.
 
I have successfully communicated with a FroDo 2.33ml using the
**EMSIREQ<crc16> header before my M_NUL OPT MD5-CRAM string, and still
receive my BinkP mail also. So, it does not seem to "break" either
protocol ~ and simplifies the nodelist to just say <domain>, and BINKP
or EMSI, or whatever else may still be in operation. Ports can trigger
off the BINKP, EMSI, CM, HO, flags. And the ITA, ITB, ITN strings for
the BinkP only environments that may or may not be running a BBS.
 
We have implemented the M_REQ string on 6 systems and as of 0000 GMT
today, I have released the next Alpha round of my software to those 6,
and 10+ systems are scheduled to go inline this week ~ if I see a
problem, I will note it here, however, so far so good. ;-)
 
Thank you for your eyes/thoguhts!
Ozz
--- Legacy/X FTN Tosser/JAM v1-Alpha6
* Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.042309 секунды