• binkd crypt

    From Warpslide@21:3/110 to All on Fri Dec 29 21:01:28 2023
    Hi All,

    I have binkd up & running and just noticed that I'm not sending CRYPT on the OPT line. I'm sending out:

    OPT EXTCMD GZ BZ2

    I've compiled binkd with:

    ./configure --with-perl --with-af-force --with-zlib --with-bzip2

    $ binkd -vv
    Binkd 1.1a-115 (Dec 29 2023 20:00:08/Linux)
    Compilation flags: gcc, zlib, bzlib2, perl, af_force.
    Facilities: fts5004 ipv6

    Is there something else I need to add when compiling or is there something I need to add to binkd.conf to enable crypt?


    Jay

    ... We dressed up as almonds for Halloween. Everyone thought we were nuts
    --- GoldED+/LNX 1.1.5-b20231112
    * Origin: Northern Realms (21:3/110)
  • From deon@21:2/116 to Warpslide on Sat Dec 30 15:37:13 2023
    Re: binkd crypt
    By: Warpslide to All on Fri Dec 29 2023 09:01 pm

    Howdy,

    I have binkd up & running and just noticed that I'm not sending CRYPT on the OPT line. I'm sending out:

    OPT EXTCMD GZ BZ2
    Is there something else I need to add when compiling or is there something I need to add to binkd.conf to enable crypt?

    If this is the same binkd - it looks like it is using crypt with clrghouz...

    [2023-12-30 00:00:02] production.INFO: PB-:+ M_NUL [SYS Northern Realms Hub] {"pid":41730}
    [2023-12-30 00:00:02] production.INFO: PB-:+ M_NUL [ZYZ Warpslide] {"pid":41730}
    [2023-12-30 00:00:02] production.INFO: PB-:+ M_NUL [LOC Binbrook, Ontario, Canada] {"pid":41730}
    [2023-12-30 00:00:02] production.INFO: PB-:+ M_NUL [NDL 115200,TCP,BINKP,BINKPS,PING,TRACE,IPV6] {"pid":41730}
    [2023-12-30 00:00:02] production.INFO: PB-:+ M_NUL [TIME Fri, 29 Dec 2023 08:00:02 -0500] {"pid":41730}
    [2023-12-30 00:00:02] production.INFO: PB-:+ M_NUL [VER binkd/1.1a-115/Linux binkp/1.1] {"pid":41730}
    [2023-12-30 00:00:02] production.INFO: PB-:- Got AKA [21:3/110@fsxnet] {"pid":41730}
    [2023-12-30 00:00:02] production.INFO: PB-:+ M_NUL [OPT NDA EXTCMD CRYPT GZ] {"pid":41730}
    [2023-12-30 00:00:02] production.INFO: PB-:- Remote wants NO DUPES ASYMMETRIC mode {"pid":41730}
    [2023-12-30 00:00:02] production.INFO: PB-:- Remote wants CRYPT mode {"pid":41730}
    [2023-12-30 00:00:02] production.INFO: PB-:- Remote wants GZ compression {"pid":41730}


    ...ëîåï
    --- SBBSecho 3.20-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)
  • From Andrew Leary@21:4/105 to Warpslide on Sat Dec 30 01:27:03 2023
    Hello Warpslide!

    29 Dec 23 21:01, you wrote to all:

    I have binkd up & running and just noticed that I'm not sending CRYPT
    on the OPT line. I'm sending out:

    OPT EXTCMD GZ BZ2

    I've compiled binkd with:

    ./configure --with-perl --with-af-force --with-zlib --with-bzip2

    $ binkd -vv
    Binkd 1.1a-115 (Dec 29 2023 20:00:08/Linux)
    Compilation flags: gcc, zlib, bzlib2, perl, af_force.
    Facilities: fts5004 ipv6

    Is there something else I need to add when compiling or is there
    something I need to add to binkd.conf to enable crypt?

    It should be automatically enabled if you have a session password defined for the node you are connecting to.

    Andrew

    --- GoldED+/LNX 1.1.5-b20230826
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (21:4/105)
  • From Warpslide@21:3/110 to deon on Sat Dec 30 04:46:16 2023
    On Saturday December 30 2023, deon said the following...

    I have binkd up & running and just noticed that I'm not sending
    CRYPT on the OPT line. I'm sending out:

    OPT EXTCMD GZ BZ2

    Is there something else I need to add when compiling or is there
    something I need to add to binkd.conf to enable crypt?

    If this is the same binkd - it looks like it is using crypt with clrghouz...

    So it is! I was using a test point with Mystic before, but using/setting up binkd on my laptop now shows the CRYPT option:

    - 04:41 [10568] VER binkd/1.1a-115/Linux binkp/1.1
    + 04:41 [10568] addr: 1:229/664@fidonet (n/a or busy)
    + 04:41 [10568] addr: 1:229/0@fidonet (n/a or busy)
    + 04:41 [10568] addr: 1:12/0@fidonet (n/a or busy)
    + 04:41 [10568] addr: 618:500/23@micronet (n/a or busy)
    + 04:41 [10568] addr: 21:3/110@fsxnet
    + 04:41 [10568] addr: 1337:3/126@tqwnet (n/a or busy)
    - 04:41 [10568] TRF 0 0
    + 04:41 [10568] Remote has 0b of mail and 0b of files for us
    - 04:41 [10568] OPT EXTCMD CRYPT GZ BZ2
    + 04:41 [10568] Remote supports EXTCMD mode
    + 04:41 [10568] Remote requests CRYPT mode
    + 04:41 [10568] Remote supports GZ mode
    + 04:41 [10568] Remote supports BZ2 mode
    + 04:41 [10568] pwd protected session (MD5)
    - 04:41 [10568] session in CRYPT mode

    Thanks for checking on that for me, appreciated.


    Jay

    ... Somebody stole all my lamps. I couldn't be more de-lighted!
    --- GoldED+/LNX 1.1.5-b20231112
    * Origin: Northern Realms (21:3/110)
  • From Al@21:4/106 to Warpslide on Sat Dec 30 01:57:10 2023
    Is there something else I need to add when compiling or is there something I need to add to binkd.conf to enable crypt?

    Not all mailers support CRYPT. The mailer in BBBS doesn't and I'm not sure about Mystic.

    --- BBBS/Li6 v4.10 Toy-6
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From tenser@21:1/101 to Al on Mon Jan 1 12:30:02 2024
    On 30 Dec 2023 at 01:57a, Al pondered and said...

    Is there something else I need to add when compiling or is there somethi need to add to binkd.conf to enable crypt?

    Not all mailers support CRYPT. The mailer in BBBS doesn't and I'm not
    sure about Mystic.

    Binkp's crypt option is pretty weak; a much stronger
    alternative would be binkp over TLS. Even better would
    be scraping binkp entirely, but I think that's unlikely.

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Al@21:4/106 to tenser on Sun Dec 31 17:50:44 2023
    Not all mailers support CRYPT. The mailer in BBBS doesn't and I'm not
    sure about Mystic.

    Binkp's crypt option is pretty weak;

    Yes, in it's day it was great but time marches on.

    a much stronger alternative would be binkp over TLS.

    That is actually possible. I think Mystic and Synchronet make that quite easy to do. Binkd can do it to with a little trickery.

    Even better would be scraping binkp entirely, but I think that's unlikely.

    Binkp is the main thing protocol we have today. Like so many fido protocols I think we'd do things differently today but we carry on.. :)

    --- BBBS/Li6 v4.10 Toy-6
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From NuSkooler@21:1/121 to Al on Mon Jan 1 11:30:17 2024

    On Sunday, December 31st Al was heard saying...
    That is actually possible. I think Mystic and Synchronet make that quite easy to do. Binkd can do it to with a little trickery.

    You can essentially do it with any system in which you can put a TLS terminating proxy in the middle. Problem is, it doesn't matter at all when you're talking to a bunch of other non-encrypted systems, so there isn't really much of a point IMO.

    --
    |08 â–  |12NuSkooler |06// |12Xibalba |08- |07"|06The place of fear|07"
    |08 â–  |03xibalba|08.|03vip |08(|0344510|08/|03telnet|08, |0344511|08/|03ssh|08)
    |08 â–  |03ENiGMA 1/2 WHQ |08| |03Phenom |08| |0367 |08| |03iMPURE |08| |03ACiDic
    --- ENiGMA 1/2 v0.0.14-beta (linux; x64; 18.18.2)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
  • From esc@21:4/173 to Al on Mon Jan 1 10:18:54 2024
    That is actually possible. I think Mystic and Synchronet make that quite easy to do. Binkd can do it to with a little trickery.

    Interesting - do you know where this is documented? I'd love to give it a read.

    --- Mystic BBS v1.12 A49 2023/02/26 (Linux/64)
    * Origin: m O N T E R E Y b B S . c O M (21:4/173)
  • From Jay Harris@21:3/110 to esc on Mon Jan 1 15:16:36 2024
    On Monday January 01 2024, esc said the following...

    That is actually possible. I think Mystic and Synchronet make
    that quite easy to do. Binkd can do it to with a little trickery.

    Interesting - do you know where this is documented? I'd love to give
    it a read.

    I'm not sure about Synchronet.

    For Mystic run mystic -cfg and go to Servers -> Configure Servers -> BINKP.

    Set the SSL Port to 24553, set Allow StartTLS to Yes and then restart mis.

    For any links that support it you can set the BINKP Server Type from Normal to Direct SSL or StartTLS.

    I have BinkD configured here with an nginx proxy thanks to instructions that Oli posted in the FSX_CRY echo (MSGID: 21:1/151 5ddd6d52) back in November 2019. (Search for MSGID: 21:4/106 5e040d16 for instructions for outgoing connections as well.)


    Jay

    ... I want to be cremated as it is my last hope for a smoking hot body
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: Northern Realms (21:3/110)
  • From Al@21:4/106 to NuSkooler on Mon Jan 1 18:30:42 2024
    On Sunday, December 31st Al was heard saying...
    That is actually possible. I think Mystic and Synchronet make that quite
    easy to do. Binkd can do it to with a little trickery.

    You can essentially do it with any system in which you can put a TLS terminating proxy in the middle. Problem is, it doesn't matter at all when you're talking to a bunch of other non-encrypted systems, so there isn't really much of a point IMO.

    I brought this up in the BINKD echo a few years ago thinking we could make this a default behaviour, or at least make it easier to impliment.

    The replies I got were largely against the idea.

    --- BBBS/Li6 v4.10 Toy-6
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From Al@21:4/106 to esc on Mon Jan 1 18:37:40 2024
    That is actually possible. I think Mystic and Synchronet make that quite
    easy to do. Binkd can do it to with a little trickery.

    Interesting - do you know where this is documented? I'd love to give it a read.

    In Mystic you can start a listener on port 24553 (by default). You can also set nodes you are polling to poll securely.

    In Synchronet you can start a binkps listener on port 24553 (default) in the services.ini and much like Mystic set your polls to use binkps in echocfg.

    In both cases it depends on the remote nodes having those listeners up and running.

    The Synchronet wiki likely has good information about that and I would think the Mystic wiki also.

    --- BBBS/Li6 v4.10 Toy-6
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From esc@21:4/173 to Al on Mon Jan 1 22:11:26 2024
    In Mystic you can start a listener on port 24553 (by default). You can also set nodes you are polling to poll securely.

    Ah, yep, thanks :) was tracking the Mystic & Synchronet capability, was more interested in binkd being configured to use it.

    --- Mystic BBS v1.12 A49 2023/02/26 (Linux/64)
    * Origin: m O N T E R E Y b B S . c O M (21:4/173)
  • From Al@21:4/106 to esc on Tue Jan 2 01:11:10 2024
    In Mystic you can start a listener on port 24553 (by default). You can
    also set nodes you are polling to poll securely.

    Ah, yep, thanks :) was tracking the Mystic & Synchronet capability, was more interested in binkd being configured to use it.

    Binkd is a bit more involved. You need a webserver to listen on 24553 and have it pass traffic to your bink port if successful.

    I did this just as a test following Oli's instructions in the FSX_CRY area and it worked well.

    --- BBBS/Li6 v4.10 Toy-6
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From esc@21:4/173 to Al on Tue Jan 2 02:05:58 2024
    I did this just as a test following Oli's instructions in the FSX_CRY
    area and it worked well.

    Sweet. I found Oli's posts and took some notes. Gonna give this a whirl when I move from Mystic to binkd. Thanks!

    --- Mystic BBS v1.12 A49 2023/02/26 (Linux/64)
    * Origin: m O N T E R E Y b B S . c O M (21:4/173)
  • From tenser@21:1/101 to NuSkooler on Wed Jan 3 03:03:24 2024
    On 01 Jan 2024 at 11:30a, NuSkooler pondered and said...

    On Sunday, December 31st Al was heard saying...
    That is actually possible. I think Mystic and Synchronet make that qu easy to do. Binkd can do it to with a little trickery.

    You can essentially do it with any system in which you can put a TLS terminating proxy in the middle. Problem is, it doesn't matter at all
    when you're talking to a bunch of other non-encrypted systems, so there isn't really much of a point IMO.

    Oh, I don't know: incremental progress towards security as a
    goal may be slow, but is still progress, no?

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From esc@21:4/173 to tenser on Tue Jan 2 13:49:41 2024
    You can essentially do it with any system in which you can put a TLS terminating proxy in the middle. Problem is, it doesn't matter at all when you're talking to a bunch of other non-encrypted systems, so the isn't really much of a point IMO.

    Oh, I don't know: incremental progress towards security as a
    goal may be slow, but is still progress, no?

    Y'know, I always thought an FTN that was locked down to encrypted comms only would be kinda neat. Like, each node uses TLS, and the sysops of each BBS have to vet the users to give access to the conferences for that net. On top of that, maybe there could be a requirement that for the user to access the confs (in addition to security level) they'd need to be connected via SSH or secure websocket. Could be neat...

    But also there could be someone accidentally misconfiguring something somewhere and burping a bunch of messages from one net into another. Or someone could gate everything to their Synchronet web message base. Any number of things. :P So I guess for this net to work, it'd have to be small.

    Anyway it's an interesting thought exercise.

    --- Mystic BBS v1.12 A49 2023/02/26 (Linux/64)
    * Origin: m O N T E R E Y b B S . c O M (21:4/173)
  • From apam@21:1/182 to esc on Wed Jan 3 09:35:10 2024
    But also there could be someone accidentally misconfiguring something somewhere and burping a bunch of messages from one net into another. Or someone could gate everything to their Synchronet web message base. Any number of things. :P So I guess for this net to work, it'd have to be small.


    I think security would mainly be useful for protecting session passwords and netmail. Echomail isn't private anyway, so if people burped a bunch of echomail, it doesn't really matter.

    Also, if people don't log in to SSH, check their netmail, and someone eavesdrops, it's their own fault - the system would only show them their netmail anyway, so other peoples netmail would still be secure.

    On the otherhand, if you wanted to make an exclusive net, then I guess you'd have to make sure those you invite to the net weren't the sort to burp echomail.

    Andrew
    --- Noddy git-2b8b935
    * Origin: Smuggler's Cove - scove.talismanbbs.com:2323 (21:1/182)
  • From NuSkooler@21:1/121 to Al on Tue Jan 2 19:26:22 2024

    On Monday, January 1st Al muttered...
    I brought this up in the BINKD echo a few years ago thinking we could make this a default behaviour, or at least make it easier to impliment.

    I think the main issue is older software and setups with true retro hardware -- it's just not really viable to even perform TLS on that old hardware.

    For a true encrypted exprerience, we need a new protocol that is *always* encrypted. Of course you can't stop people from exporting to non-encrypted areas though, but it's a start.

    --
    |08 â–  |12NuSkooler |06// |12Xibalba |08- |07"|06The place of fear|07"
    |08 â–  |03xibalba|08.|03vip |08(|0344510|08/|03telnet|08, |0344511|08/|03ssh|08)
    |08 â–  |03ENiGMA 1/2 WHQ |08| |03Phenom |08| |0367 |08| |03iMPURE |08| |03ACiDic
    --- ENiGMA 1/2 v0.0.14-beta (linux; x64; 18.18.2)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
  • From NuSkooler@21:1/121 to tenser on Tue Jan 2 19:27:57 2024

    tenser around Wednesday, January 3rd...
    Oh, I don't know: incremental progress towards security as a goal may be slow, but is still progress, no?

    I'd argue that it's just a false sense of security, which can be worse than none.

    If we were to implement a *new* protocol that is always encrypted, that would be a better start -- only policy can prevent people from exposing the messages elsewhere though + old setups will inherently be left out.






    --
    |08 â–  |12NuSkooler |06// |12Xibalba |08- |07"|06The place of fear|07"
    |08 â–  |03xibalba|08.|03vip |08(|0344510|08/|03telnet|08, |0344511|08/|03ssh|08)
    |08 â–  |03ENiGMA 1/2 WHQ |08| |03Phenom |08| |0367 |08| |03iMPURE |08| |03ACiDic
    --- ENiGMA 1/2 v0.0.14-beta (linux; x64; 18.18.2)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
  • From deon@21:2/116 to esc on Wed Jan 3 20:04:45 2024
    Re: Re: binkd crypt
    By: esc to tenser on Tue Jan 02 2024 01:49 pm

    Howdy,

    Y'know, I always thought an FTN that was locked down to encrypted comms only would be kinda neat. Like, each node uses TLS, and the sysops of each BBS have to vet the users to give access to the conferences for that net. On top of that, maybe there could be a requirement that for the user to access the confs (in addition to security level) they'd need to be connected via SSH or secure websocket. Could be neat...

    I think it can be done even easier than that.

    ZeroTier is one option - its kinda like a VPN. One thing I like about it, is that the ZT network can also have firewall rules - so you can limit folks to well known ports.

    Access to the network needs to be approved by who ever is the network owner. (I ran it here in FSX for a bit, and its running in TQW).

    I also like it, because script kiddies could be gone, if you only enable access to your system via ZT - and every body "in" the net is known...

    (Still doesnt get over the problem of somebody dual homing out to the internet though.)


    ...ëîåï
    --- SBBSecho 3.20-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)
  • From Al@21:4/106 to NuSkooler on Wed Jan 3 02:10:50 2024
    On Monday, January 1st Al muttered...
    I brought this up in the BINKD echo a few years ago thinking we could
    make this a default behaviour, or at least make it easier to impliment.

    I think the main issue is older software and setups with true retro hardware - it's just not really viable to even perform TLS on that old hardware.

    I'm not saying we should drop binkp or any protocol, it works so lets use it.

    I'm saying we could also support binkps and use it when it's available if we want to do that.

    For a true encrypted exprerience, we need a new protocol that is *always* encrypted. Of course you can't stop people from exporting to non-encrypted areas though, but it's a start.

    I am only thinking of the binkp server. I would like to operate my node as simply and as securely as possible and make it easy for all nodes to do that.

    When you say a "true encrypted experience" are you speaking of BBSing as a whole, encrypt the entire process of user login read/post/reply and everything that follows?

    That would be a fairly big goal, but also probably doable today if we took a fresh approach. That approach would change everything. We'd have to leave behind the older software and setups you speak of. This is the big challenge of FTN networks. We have always tried to move things forward in a backward
    compatible way, for good reasons.

    I don't see any reason not to do that and build things for today, today.

    The BBS and FTN world is very retro and I doubt that anyone wants to lose that, or our old friends running old software or setups.

    I would like to see binkps become more of a standard and be easily available to use by nodes who can use it. I think most eveyone could use it.

    --- BBBS/Li6 v4.10 Toy-6
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From tenser@21:1/101 to NuSkooler on Thu Jan 4 03:51:53 2024
    On 02 Jan 2024 at 07:27p, NuSkooler pondered and said...

    tenser around Wednesday, January 3rd...
    Oh, I don't know: incremental progress towards security as a goal may slow, but is still progress, no?

    I'd argue that it's just a false sense of security, which can be worse than none.

    Perhaps. It wouldn't protect against any number of other
    attack vectors, but neither would a new protocol. On the
    other hand, if binkp regularly ran over TLS-protected
    connections, it would be (largely) immune to passive sniffing.

    Not that that matters much; I doubt the greater BBS community
    is passing any traffic that _requires_ it.

    If we were to implement a *new* protocol that is always encrypted, that would be a better start -- only policy can prevent people from exposing the messages elsewhere though + old setups will inherently be left out.

    A way around that would be a proxy at the edge of that system's
    local network that handles encryption. It's not completely
    end-to-end, but does it need to be?

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Avon@21:1/101 to apam on Wed Jan 17 20:30:44 2024
    On 03 Jan 2024 at 09:35a, apam pondered and said...

    On the otherhand, if you wanted to make an exclusive net, then I guess you'd have to make sure those you invite to the net weren't the sort to burp echomail.

    sounds like me when I eat curry :)

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From NuSkooler@21:1/121 to Avon on Wed Jan 17 09:06:54 2024

    On Thursday, January 18th Avon said...
    sounds like me when I eat curry :)

    lol!

    --
    |08 â–  |12NuSkooler |06// |12Xibalba |08- |07"|06The place of fear|07"
    |08 â–  |03xibalba|08.|03vip |08(|0344510|08/|03telnet|08, |0344511|08/|03ssh|08)
    |08 â–  |03ENiGMA 1/2 WHQ |08| |03Phenom |08| |0367 |08| |03iMPURE |08| |03ACiDic
    --- ENiGMA 1/2 v0.0.14-beta (linux; x64; 18.18.2)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
  • From Avon@21:1/101 to NuSkooler on Thu Jan 18 13:11:57 2024
    On 17 Jan 2024 at 09:06a, NuSkooler pondered and said...

    sounds like me when I eat curry :)

    lol!

    sorry for that mental image... well mostly sorry :)

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)