• possible CRYPT bug with no session password

    From mark lewis@VERT to all on Fri Jun 14 01:44:20 2019
    i think we've stumbled upon a bug when interacting with binkd and no session level password...

    i have a connection with a node that sends this when my binkd connects out to them...

    OPT CRAM-MD5-411eaac235d14fa531bd059150ddac9e CRYPT
    [...]
    VER BinkIT/2.17,JSBinkP/1.114,sbbs3.17c/Linux binkp/1.1

    my binkd reports this...

    rerror: Password mismatch


    when they connect inbound, they are sending this...

    OPT CRYPT
    [...]
    VER BinkIT/2.17,JSBinkP/1.114,sbbs3.17c/Linux binkp/1.1

    my binkd reports this...

    unexpected password digest from the remote


    there is only a tic password set in echocfg... no other passwords are set between the two systems...

    i tried setting -nomd on their node line but since they are requesting CRYPT, we cannot talk... binkd does not have, that i can find, an option to turn off CRYPT per node... i'm aware that binkit.js is v2.25 and binkp.js v1.118 and there has been some recent work done in this area of the code...

    with the above versions, i'm thinking that we're missing something since we seem to be setting CRYPT even when there is no session level password defined... i don't know if having that node update to the latest binkp.js and/or binkit.js will fix this particular problem with requesting CRYPT when there is no session level password set, though...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... I am curious, Do all Microsoft programmers do drugs?
    ---
    * Origin: (1:3634/12.73)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to mark lewis on Fri Jun 14 02:34:53 2019
    Re: possible CRYPT bug with no session password
    By: mark lewis to all on Thu Jun 13 2019 09:44 pm


    i think we've stumbled upon a bug when interacting with binkd and no

    session
    level password...

    i have a connection with a node that sends this when my binkd connects

    out
    to them...

    OPT CRAM-MD5-411eaac235d14fa531bd059150ddac9e CRYPT
    [...]
    VER BinkIT/2.17,JSBinkP/1.114,sbbs3.17c/Linux binkp/1.1

    my binkd reports this...

    rerror: Password mismatch


    when they connect inbound, they are sending this...

    OPT CRYPT
    [...]
    VER BinkIT/2.17,JSBinkP/1.114,sbbs3.17c/Linux binkp/1.1

    That means the remote BinkIT system has a session password configured for your node. From binkp.js 1.114 ('-' is the same as a blank/no password):

    if (password !== '-')
    this.sendCmd(this.command.M_NUL, "OPT CRYPT");

    my binkd reports this...

    unexpected password digest from the remote


    there is only a tic password set in echocfg... no other passwords are


    set
    between the two systems...

    How do you know? according to the information you provided, it certainly seems the remote system has a session password configured.

    i tried setting -nomd on their node line but since they are requesting CRYPT, we cannot talk... binkd does not have, that i can find, an option to turn off CRYPT per node...

    Setting a blank password in BinkIT will stop the CRYPT option for outbound connections. The only way to disable it for inbound connections is the new global plain-text-only option.

    i'm aware that binkit.js is v2.25 and binkp.js
    v1.118 and there has been some recent work done in this area of the code...
    All about disabling CRAM-MD5 and encryption because my uplink was having issues that couldn't be easily debugged when those features were used.

    with the above versions, i'm thinking that we're missing something since we seem to be setting CRYPT even when there is no session level password defined...

    I don't think so.

    i don't know if having that node update to the latest binkp.js
    and/or binkit.js will fix this particular problem with requesting CRYPT when there is no session level password set, though...

    Shouldn't make any difference in that regard (for outbound connections from BinkIT).

    digital man

    Synchronet "Real Fact" #8:
    Synchronet was originally intended as a replacement for WWIV BBS software. Norco, CA WX: 59.8°F, 88.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From mark lewis@VERT to Digital Man on Fri Jun 14 14:47:04 2019
    On 2019 Jun 13 22:34:52, you wrote to me:

    when they connect inbound, they are sending this...

    OPT CRYPT
    [...]
    VER BinkIT/2.17,JSBinkP/1.114,sbbs3.17c/Linux binkp/1.1

    That means the remote BinkIT system has a session password configured for your node. From binkp.js 1.114 ('-' is the same as a blank/no password):

    if (!this.plain_auth_only && password !== '-')
    this.sendCmd(this.command.M_NUL, "OPT CRYPT");

    are you saying that if there is no session level password, we should have a '-'
    in the session password field in echocfg??

    i actually had nothing in the password field in my echocfg and then also in my binkd.conf... i've since added a '-' to my binkd.conf after reviewing my old configuration from my dead/defnuct system...

    there is only a tic password set in echocfg... no other passwords are
    set between the two systems...

    How do you know? according to the information you provided, it certainly seems the remote system has a session password configured.

    they posted me a copy of my entry in their sbbsecho.ini file... it looked exactly like the one i have for them...

    ----->8 snip 8<-----
    [node:XXXXXXXXXXXXXXXXXX]
    Name = XXXXXXXXXXXX
    Comment =
    Archive = None
    PacketType = 2+
    PacketPwd =
    AreaFix = false
    AreaFixPwd =
    SessionPwd =
    TicFilePwd = XXXXXXXX
    Inbox =
    Outbox =
    Passive = false
    Direct = true
    Notify = false
    Keys =
    Status = Normal
    LocalAddress = XXXXXXXXXXXX
    GroupHub =
    BinkpHost =
    BinkpPort = 24554
    BinkpPoll = false
    BinkpPlainAuthOnly = false
    BinkpAllowPlainAuth = true
    BinkpAllowPlainText = true
    BinkpSourceAddress = XXXXXXXXXXXXXXXXX
    ----->8 snip 8<-----

    i tried setting -nomd on their node line but since they are requesting
    CRYPT, we cannot talk... binkd does not have, that i can find, an option
    to turn off CRYPT per node...

    Setting a blank password in BinkIT will stop the CRYPT option for outbound connections. The only way to disable it for inbound connections is the new global plain-text-only option.

    ahhh, ok... i wasn't sure how that worked... granted, i've not been into the code in several weeks...

    i'm aware that binkit.js is v2.25 and binkp.js v1.118 and there has
    been some recent work done in this area of the code...

    All about disabling CRAM-MD5 and encryption because my uplink was
    having issues that couldn't be easily debugged when those features
    were used.

    i know that feeling... especially when CRYPT is used and the conversation is encrypted so you can't tell what's being sent/received when capturing the raw network packets...

    with the above versions, i'm thinking that we're missing something
    since we seem to be setting CRYPT even when there is no session level
    password defined...

    I don't think so.

    i don't understand what's happening, then...

    i don't know if having that node update to the latest binkp.js and/or
    binkit.js will fix this particular problem with requesting CRYPT when
    there is no session level password set, though...

    Shouldn't make any difference in that regard (for outbound connections from BinkIT).

    hummm...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... !edis gnorw eht morf siht ta gnikool era uoY
    ---
    * Origin: (1:3634/12.73)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From mark lewis@VERT to Digital Man on Fri Jun 14 16:12:24 2019
    On 2019 Jun 14 10:47:04, I wrote to you:

    That means the remote BinkIT system has a session password configured
    for your node. From binkp.js 1.114 ('-' is the same as a blank/no
    password):

    if (!this.plain_auth_only && password !== '-')
    this.sendCmd(this.command.M_NUL, "OPT CRYPT");

    are you saying that if there is no session level password, we should have
    a
    '-' in the session password field in echocfg??

    of course that was wrong but if one was put in there, it should work the same... i've glanced over the code and i note that if the password is undefined, it is set to '-'... is it possible that maybe the password is not just undefined but it is blank?

    if (password === undefined)
    password = '-';
    if (password === '-')
    this.require_md5 = false;

    should

    this.wont_crypt = true;
    this.require_crypt = false;

    be set up there where "this.require_md5 = false" is set instead of being set further down? then checking additional values would prevent "OPT CRYPT" from being sent as well??

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... I am celibate by choice - not mine, mind you.
    ---
    * Origin: (1:3634/12.73)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to mark lewis on Fri Jun 14 17:42:07 2019
    Re: possible CRYPT bug with no session password
    By: mark lewis to Digital Man on Fri Jun 14 2019 10:47 am


    On 2019 Jun 13 22:34:52, you wrote to me:

    when they connect inbound, they are sending this...

    OPT CRYPT
    [...]
    VER BinkIT/2.17,JSBinkP/1.114,sbbs3.17c/Linux binkp/1.1

    That means the remote BinkIT system has a session password configured for your node. From binkp.js 1.114 ('-' is the same as a blank/no password):

    if (!this.plain_auth_only && password !== '-')
    this.sendCmd(this.command.M_NUL, "OPT CRYPT");

    are you saying that if there is no session level password, we should have a '-' in the session password field in echocfg??

    No. The BinkP protocol processes a blank password as '-' and the binkit/binkp script automatically converts blank passwords to '-' and compares as such.

    i actually had nothing in the password field in my echocfg

    That would be correct.

    and then also in
    my binkd.conf... i've since added a '-' to my binkd.conf after reviewing my old configuration from my dead/defnuct system...

    binkd requires the '-' if you have other fields following the password.

    there is only a tic password set in echocfg... no other passwords are
    set between the two systems...

    How do you know? according to the information you provided, it certainly seems the remote system has a session password configured.

    they posted me a copy of my entry in their sbbsecho.ini file... it looked exactly like the one i have for them...

    ----->8 snip 8<-----
    [node:XXXXXXXXXXXXXXXXXX]
    Name = XXXXXXXXXXXX
    Comment =
    Archive = None
    PacketType = 2+
    PacketPwd =
    AreaFix = false
    AreaFixPwd =
    SessionPwd =
    TicFilePwd = XXXXXXXX
    Inbox =
    Outbox =
    Passive = false
    Direct = true
    Notify = false
    Keys =
    Status = Normal
    LocalAddress = XXXXXXXXXXXX
    GroupHub =
    BinkpHost =
    BinkpPort = 24554
    BinkpPoll = false
    BinkpPlainAuthOnly = false
    BinkpAllowPlainAuth = true
    BinkpAllowPlainText = true
    BinkpSourceAddress = XXXXXXXXXXXXXXXXX

    Perhaps they made a copy/past error.

    ----->8 snip 8<-----

    i tried setting -nomd on their node line but since they are requesting
    CRYPT, we cannot talk... binkd does not have, that i can find, an option
    to turn off CRYPT per node...

    Setting a blank password in BinkIT will stop the CRYPT option for outbound connections. The only way to disable it for inbound connections is the new global plain-text-only option.

    ahhh, ok... i wasn't sure how that worked... granted, i've not been into the code in several weeks...

    i'm aware that binkit.js is v2.25 and binkp.js v1.118 and there has
    been some recent work done in this area of the code...

    All about disabling CRAM-MD5 and encryption because my uplink was having issues that couldn't be easily debugged when those features
    were used.

    i know that feeling... especially when CRYPT is used and the conversation is encrypted so you can't tell what's being sent/received when capturing the raw network packets...

    with the above versions, i'm thinking that we're missing something
    since we seem to be setting CRYPT even when there is no session level
    password defined...

    I don't think so.

    i don't understand what's happening, then...

    i don't know if having that node update to the latest binkp.js and/or
    binkit.js will fix this particular problem with requesting CRYPT when
    there is no session level password set, though...

    Shouldn't make any difference in that regard (for outbound connections from BinkIT).

    hummm...

    Uh huh.

    digital man

    This Is Spinal Tap quote #16:
    David St. Hubbins: I believe virtually everything I read...
    Norco, CA WX: 72.2°F, 59.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to mark lewis on Fri Jun 14 17:50:11 2019
    Re: possible CRYPT bug with no session password
    By: mark lewis to Digital Man on Fri Jun 14 2019 12:12 pm


    On 2019 Jun 14 10:47:04, I wrote to you:

    That means the remote BinkIT system has a session password configured
    for your node. From binkp.js 1.114 ('-' is the same as a blank/no
    password):

    if (!this.plain_auth_only && password !== '-')
    this.sendCmd(this.command.M_NUL, "OPT CRYPT");

    are you saying that if there is no session level password, we should have
    a
    '-' in the session password field in echocfg??

    of course that was wrong but if one was put in there, it should work the same... i've glanced over the code and i note that if the password is undefined, it is set to '-'... is it possible that maybe the password is not just undefined but it is blank?

    Yes, I think that's exactly what's happening:
    this.node[sec].pass = f.iniGetValue(section, 'SessionPwd', '');

    This line (from fidocfg.js) would set the password to a blank string by default (not undefined).


    if (password === undefined)
    password = '-';
    if (password === '-')
    this.require_md5 = false;

    should

    this.wont_crypt = true;
    this.require_crypt = false;

    be set up there where "this.require_md5 = false" is set instead of being set further down? then checking additional values would prevent "OPT CRYPT" from being sent as well??

    No, I think that part is right. Just because you don't *require* CRAM-MD5 doesn't mean you won't allow it (and to allow it, you must send the OPT CRYPT msg).

    The blank vs. undefined password thing does seem like a problem though.

    digital man

    This Is Spinal Tap quote #9:
    David St. Hubbins: I mean, it's not your job to be as confused as Nigel.
    Norco, CA WX: 73.0°F, 59.0% humidity, 3 mph ENE wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to mark lewis on Fri Jun 14 18:15:52 2019
    Re: possible CRYPT bug with no session password
    By: Digital Man to mark lewis on Fri Jun 14 2019 01:50 pm

    Re: possible CRYPT bug with no session password
    By: mark lewis to Digital Man on Fri Jun 14 2019 12:12 pm


    On 2019 Jun 14 10:47:04, I wrote to you:

    That means the remote BinkIT system has a session password configured
    for your node. From binkp.js 1.114 ('-' is the same as a blank/no
    password):

    if (!this.plain_auth_only && password !== '-')
    this.sendCmd(this.command.M_NUL, "OPT CRYPT");

    are you saying that if there is no session level password, we should have
    a
    '-' in the session password field in echocfg??

    of course that was wrong but if one was put in there, it should work the same... i've glanced over the code and i note that if the password is undefined, it is set to '-'... is it possible that maybe the password is not just undefined but it is blank?

    Yes, I think that's exactly what's happening:
    this.node[sec].pass = f.iniGetValue(section, 'SessionPwd', '');

    This line (from fidocfg.js) would set the password to a blank string by default (not undefined).

    Should be fixed now. Thanks for the bug report,

    digital man

    Synchronet "Real Fact" #15:
    SBBSecho was introduced (replacing SBBSFIDO) for Synchronet v2 in 1994.
    Norco, CA WX: 73.3°F, 59.0% humidity, 9 mph NE wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Dumas Walker@VERT/CAPCITY2 to DIGITAL MAN on Fri Jun 14 21:14:00 2019
    How do you know? according to the information you provided, it certainly seems >he remote system has a session password configured.

    Uuuummmm.... he took my word for it as I showed him some of the fields I am showing you now. :)

    [node:1:3634/12@fidonet]
    Name =
    Comment =
    Archive =
    PacketType = 2+
    PacketPwd =
    AreaFix = true
    AreaFixPwd =
    SessionPwd =
    TicFilePwd = password (also tried with this field BLANK)
    Inbox =
    Outbox =
    Passive = false
    Direct = true
    Notify = false
    Keys = FIDO
    Status = Normal
    GroupHub =
    BinkpHost = sestar.synchro.net
    BinkpPort = 24554
    BinkpPoll = true
    BinkpAllowPlainAuth = true
    BinkpAllowPlainText = true
    BinkpPlainAuthOnly = false
    BinkpSourceAddress =

    I checked and this is the only entry for his node in my sbbsecho.ini file.

    Thanks!

    ---
    ■ SLMR 2.1a ■ Nothing is so smiple that it can't get screwed up.
    ■ Synchronet ■ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP
  • From Digital Man@VERT to Dumas Walker on Fri Jun 14 20:50:10 2019
    Re: possible CRYPT bug with n
    By: Dumas Walker to DIGITAL MAN on Fri Jun 14 2019 05:14 pm

    How do you know? according to the information you provided, it certainly seems >he remote system has a session password configured.

    Uuuummmm.... he took my word for it as I showed him some of the fields I am showing you now. :)

    [node:1:3634/12@fidonet]
    Name =
    Comment =
    Archive =
    PacketType = 2+
    PacketPwd =
    AreaFix = true
    AreaFixPwd =
    SessionPwd =
    TicFilePwd = password (also tried with this field BLANK)
    Inbox =
    Outbox =
    Passive = false
    Direct = true
    Notify = false
    Keys = FIDO
    Status = Normal
    GroupHub =
    BinkpHost = sestar.synchro.net
    BinkpPort = 24554
    BinkpPoll = true
    BinkpAllowPlainAuth = true
    BinkpAllowPlainText = true
    BinkpPlainAuthOnly = false
    BinkpSourceAddress =

    I checked and this is the only entry for his node in my sbbsecho.ini file.

    Thanks. Get the latest exec/binkit.js and load/binkp.js from CVS and see if that fixes you up.

    digital man

    Synchronet "Real Fact" #28:
    Rob Swindell's first computer was a Commodore VIC-20 (1980).
    Norco, CA WX: 75.3°F, 58.0% humidity, 6 mph NE wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From mark lewis@VERT to Digital Man on Sat Jun 15 15:19:36 2019
    On 2019 Jun 14 13:42:06, you wrote to me:

    are you saying that if there is no session level password, we should
    have a '-' in the session password field in echocfg??

    No. The BinkP protocol processes a blank password as '-' and the binkit/binkp script automatically converts blank passwords to '-' and compares as such.

    yeah, i saw that later...

    i actually had nothing in the password field in my echocfg

    That would be correct.

    ok...

    and then also in
    my binkd.conf... i've since added a '-' to my binkd.conf after reviewing
    my old configuration from my dead/defnuct system...

    binkd requires the '-' if you have other fields following the password.

    right... i do not have any additional fields after the password field in my conf file... i put the '-' in anyway, just in case but it made no difference...
    i'm now waiting on the remote to put an actual session level password in their echocfg so we can see if that fixes the problem...

    Perhaps they made a copy/past error.

    it is possible ;)

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Anything free is worth what you pay for it.
    ---
    * Origin: (1:3634/12.73)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From mark lewis@VERT to Digital Man on Sat Jun 15 15:23:36 2019
    On 2019 Jun 14 13:50:10, you wrote to me:

    of course that was wrong but if one was put in there, it should work the
    same... i've glanced over the code and i note that if the password is
    undefined, it is set to '-'... is it possible that maybe the password is
    not just undefined but it is blank?

    Yes, I think that's exactly what's happening:
    this.node[sec].pass = f.iniGetValue(section, 'SessionPwd', '');

    This line (from fidocfg.js) would set the password to a blank string by default (not undefined).

    ahhhhhhhh...

    be set up there where "this.require_md5 = false" is set instead of being
    set further down? then checking additional values would prevent "OPT
    CRYPT" from being sent as well??

    No, I think that part is right. Just because you don't *require* CRAM-MD5 doesn't mean you won't allow it (and to allow it, you must send the OPT CRYPT msg).

    ummm, what? to allow CRAM-MD5 you must also send CRYPT? i don't see that... to have/allow CRYPT, you have to do CRAM-MD5, yes... maybe i'm reading that wrongly?

    The blank vs. undefined password thing does seem like a problem
    though.

    it is something to play with... [time passes] hehehe, i see you've already prodded cvs with some updates... we'll see what we can do about checking them out... i'll have to see if i can get the operator of that other system to update his .js files...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... One Tequila, Two Tequila, Three Tequila, Floor
    ---
    * Origin: (1:3634/12.73)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From mark lewis@VERT to Digital Man on Sat Jun 15 15:28:28 2019
    On 2019 Jun 14 14:15:52, you wrote to me:

    This line (from fidocfg.js) would set the password to a blank string by
    default (not undefined).

    Should be fixed now. Thanks for the bug report,

    you're quite welcome :)

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... He recently graduated from the Boone's Farm School of Wine!
    ---
    * Origin: (1:3634/12.73)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to mark lewis on Sat Jun 15 21:11:39 2019
    Re: possible CRYPT bug with no session password
    By: mark lewis to Digital Man on Sat Jun 15 2019 11:23 am


    On 2019 Jun 14 13:50:10, you wrote to me:

    of course that was wrong but if one was put in there, it should work the
    same... i've glanced over the code and i note that if the password is
    undefined, it is set to '-'... is it possible that maybe the password is
    not just undefined but it is blank?

    Yes, I think that's exactly what's happening:
    this.node[sec].pass = f.iniGetValue(section, 'SessionPwd', '');

    This line (from fidocfg.js) would set the password to a blank string by default (not undefined).

    ahhhhhhhh...

    be set up there where "this.require_md5 = false" is set instead of being
    set further down? then checking additional values would prevent "OPT
    CRYPT" from being sent as well??

    No, I think that part is right. Just because you don't *require* CRAM-MD5 doesn't mean you won't allow it (and to allow it, you must send the OPT CRYPT msg).

    ummm, what? to allow CRAM-MD5 you must also send CRYPT? i don't see that... to have/allow CRYPT, you have to do CRAM-MD5, yes... maybe i'm reading that wrongly?

    There's no configuration setting in echofg/sbbsecho.ini which enables support for CRAM-MD5 authentication (outbound) and disables support for encryption. A setting could be added but, since you can already disable both encryption and CRAM-MD5 (together), I'm not sure there's a need.

    digital man

    Synchronet/BBS Terminology Definition #9:
    BSO = Binkley Style Outbound
    Norco, CA WX: 76.7°F, 58.0% humidity, 11 mph ESE wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From mark lewis@VERT to Digital Man on Sun Jun 16 14:23:48 2019
    On 2019 Jun 15 17:11:38, you wrote to me:

    ummm, what? to allow CRAM-MD5 you must also send CRYPT? i don't see
    that... to have/allow CRYPT, you have to do CRAM-MD5, yes... maybe i'm
    reading that wrongly?

    There's no configuration setting in echofg/sbbsecho.ini which enables support for CRAM-MD5 authentication (outbound) and disables support
    for encryption. A setting could be added but, since you can already disable both encryption and CRAM-MD5 (together), I'm not sure there's
    a need.

    i'm not sure, either... i like the idea of using CRAM-MD5 for the authentication exchange...

    CRYPTing the entire conversation is not really necessary but some like that, too... i guess they're transiting CC numbers, state secrets or similar...

    while they are coupled together in that CRYPT needs CRAM-MD5 to have a secure transaction, one should not have to run CRYPT if they don't want to...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... The only way round is through. - Robert Frost
    ---
    * Origin: (1:3634/12.73)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to mark lewis on Sun Jun 16 18:30:54 2019
    Re: possible CRYPT bug with no session password
    By: mark lewis to Digital Man on Sun Jun 16 2019 10:23 am


    On 2019 Jun 15 17:11:38, you wrote to me:

    ummm, what? to allow CRAM-MD5 you must also send CRYPT? i don't see
    that... to have/allow CRYPT, you have to do CRAM-MD5, yes... maybe i'm
    reading that wrongly?

    There's no configuration setting in echofg/sbbsecho.ini which enables support for CRAM-MD5 authentication (outbound) and disables support
    for encryption. A setting could be added but, since you can already disable both encryption and CRAM-MD5 (together), I'm not sure there's
    a need.

    i'm not sure, either...

    If/when someone wants it, I'll add it to the todo list. :-)

    digital man

    Synchronet "Real Fact" #33:
    The Synchronet web user interface was contributed by Robert Couture, Runemaster.
    Norco, CA WX: 77.5°F, 60.0% humidity, 8 mph E wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From mark lewis@VERT to Digital Man on Sun Jun 16 23:56:58 2019
    On 2019 Jun 16 14:30:54, you wrote to me:

    support for CRAM-MD5 authentication (outbound) and disables support
    for encryption. A setting could be added but, since you can already
    disable both encryption and CRAM-MD5 (together), I'm not sure
    there's
    a need.

    i'm not sure, either...

    If/when someone wants it, I'll add it to the todo list. :-)

    please? thank you :)

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Since we're both going to Hell anyway, maybe we should carpool?
    ---
    * Origin: (1:3634/12.73)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Dumas Walker@VERT/CAPCITY2 to DIGITAL MAN on Sun Jun 16 23:43:00 2019
    Thanks. Get the latest exec/binkit.js and load/binkp.js from CVS and see if tha
    fixes you up.

    OK, I did a wget/rename on both of those. We will see what happens.
    Thanks!!!

    ---
    ■ SLMR 2.1a ■ Unable to locate Coffee -- Operator Halted!
    ■ Synchronet ■ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP
  • From mark lewis@VERT to DIGITAL MAN on Mon Jun 17 11:46:24 2019
    On 2019 Jun 16 19:43:00, Dumas Walker wrote to you:
    Thanks. Get the latest exec/binkit.js and load/binkp.js from CVS and see
    if tha fixes you up.

    OK, I did a wget/rename on both of those. We will see what happens.

    it is working between our systems now... thanks for the fix! :)

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... I may be dumb, but I'm not THAT stupid! ;*)
    ---
    * Origin: (1:3634/12.73)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net