• Binkd and TLS

    From Alan Ianson@1:153/757 to All on Wed Dec 11 15:25:12 2019
    Hello All,

    Is it possible to run binkd over TLS?

    I have done this with Mystic (Mystic needs more work in this area) and BinkIT from Synchronet BBS and I'm wondering if this can be done with binkd. The BinkIT implementation seems to be workable in my own testing although more needs to be done.

    If it's possible I'd like to do this with binkd as well but I need guidance and direction.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Tommi Koivula@2:221/1 to Alan Ianson on Thu Dec 12 17:33:40 2019

    11 Dec 19 15:25, Alan Ianson wrote to All:

    Hello All,

    Is it possible to run binkd over TLS?

    I have done this with Mystic (Mystic needs more work in this area) and
    BinkIT
    from Synchronet BBS and I'm wondering if this can be done with binkd. The BinkIT implementation seems to be workable in my own testing although
    more
    needs to be done.

    If it's possible I'd like to do this with binkd as well but I need
    guidance and
    direction.

    I believe I just polled your .2 with binkd via stunnel.

    17:31 [2958] creating a poll for 1:153/757.2@fidonet (`d' flavour)
    17:31 [2958] clientmgr started
    17:31 [2959] call to 1:153/757.2@fidonet
    17:31 [2959] trying localhost [127.0.0.1]:24568...
    17:31 [2959] connected
    17:31 [2959] outgoing session with localhost:24568 [127.0.0.1]
    17:31 [2959] OPT CRAM-MD5-ddcd156c290f8472ed8ce3aba57f07ed CRYPT
    17:31 [2959] Remote requests MD mode
    17:31 [2959] Remote requests CRYPT mode
    17:31 [2959] SYS Equinox BBS
    17:31 [2959] ZYZ Alan Ianson
    17:31 [2959] LOC Penticton, BC Canada
    17:31 [2959] NDL 115200,TCP,BINKP
    17:31 [2959] TIME Thu Dec 12 2019 07:31:57 GMT-0800 (PST)
    17:31 [2959] VER BinkIT/2.28,JSBinkP/1.122,sbbs3.17c/Linux binkp/1.1
    17:31 [2959] addr: 1:153/757.2@fidonet
    17:31 [2959] addr: 21:4/106.1@fsxnet (n/a or busy)
    17:31 [2959] done (to 1:153/757.2@fidonet, OK, S/R: 0/0 (0/0 bytes))
    17:31 [2959] session closed, quitting...
    17:31 [2958] rc(2959)=0
    17:31 [2958] the queue is empty, quitting...

    Ttyl :-),
    Al

    'Tommi

    ---
    * Origin: 2001:470:1f15:cb0:f1d0:2:221:1 (2:221/1)
  • From Tommi Koivula@2:221/360 to Alan Ianson on Thu Dec 12 17:50:06 2019
    Hi Alan.

    12 Dec 19 17:33:40, I wrote to you:

    Is it possible to run binkd over TLS?

    I have done this with Mystic (Mystic needs more work in this area) and BinkIT
    from Synchronet BBS and I'm wondering if this can be done with binkd. The
    BinkIT implementation seems to be workable in my own testing although more
    needs to be done.

    If it's possible I'd like to do this with binkd as well but I need guidance and
    direction.

    I believe I just polled your .2 with binkd via stunnel.

    binkd conf:

    === Cut ===
    node 2:221/6 127.0.0.1:24567
    node 1:153/757.2 127.0.0.1:24568
    node 2:280/464.47 127.0.0.1:24569
    === Cut ===

    stunnel conf:

    === Cut ===
    [6]
    client = yes
    accept = 127.0.0.1:24567
    connect = news.fidonet.fi:24567
    [equinoxbbs.ddns.net]
    client = yes
    accept = 127.0.0.1:24568
    connect = equinoxbbs.ddns.net:24555
    [oli]
    client = yes
    accept = 127.0.0.1:24569
    connect = binkps-test.uk.to:443
    === Cut ===

    I cannot connect oli, but I can connect you and 2:221/6. :)

    'Tommi

    ---
    * Origin: - rbb.fidonet.fi - Finland - (2:221/360)
  • From Tommi Koivula@2:221/360 to Alan Ianson on Thu Dec 12 18:10:08 2019
    Hi Alan.

    12 Dec 19 17:50:06, I wrote to you:

    I cannot connect oli, but I can connect you and 2:221/6. :)

    Well, Poll to Oli works now too.

    === Cut ===
    18:09 [2994] creating a poll for 2:280/464.47@fidonet (`d' flavour)
    18:09 [2994] clientmgr started
    18:09 [2995] call to 2:280/464.47@fidonet
    18:09 [2995] trying 127.0.0.1 [127.0.0.1]:24569...
    18:09 [2995] connected
    18:09 [2995] outgoing session with 127.0.0.1:24569
    18:09 [2995] OPT CRAM-MD5-cff5ba3d1baccec1dc6bd6513abd88ee
    18:09 [2995] Remote requests MD mode
    18:09 [2995] SYS Frederick
    18:09 [2995] ZYZ li
    18:09 [2995] LOC Lummerland
    18:09 [2995] NDL U,ON2:boqbccnwyumttwvh
    18:09 [2995] TIME Thu, 12 Dec 2019 17:09:23 +0100
    18:09 [2995] VER binkd/1.1a-99/Linux binkp/1.1
    18:09 [2995] addr: 2:280/464.47@fidonet
    18:09 [2995] addr: 39:150/200.47@amiganet (n/a or busy)
    18:09 [2995] OPT EXTCMD GZ BZ2
    18:09 [2995] Remote supports EXTCMD mode
    18:09 [2995] Remote supports GZ mode
    18:09 [2995] Remote supports BZ2 mode
    18:09 [2995] done (to 2:280/464.47@fidonet, OK, S/R: 0/0 (0/0 bytes))
    18:09 [2995] session closed, quitting...
    18:09 [2994] rc(2995)=0
    18:09 [2994] the queue is empty, quitting...
    === Cut ===

    'Tommi

    ---
    * Origin: - rbb.fidonet.fi - Finland - (2:221/360)
  • From Dumas Walker@1:2320/105 to TOMMI KOIVULA on Thu Dec 12 18:49:00 2019
    binkd conf:

    Does the node you are attempting to connect to need to have anything
    special set up on their end, or does your end only need to be set up to use stunnel?

    Mike


    * SLMR 2.1a * My other vehicle is a Galaxy Class Starship
    --- SBBSecho 3.10-Linux
    * Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (1:2320/105)
  • From Tommi Koivula@2:221/0 to Dumas Walker on Fri Dec 13 07:12:44 2019

    Does the node you are attempting to connect to need to have anything special set up on their end, or does your end only need to be set up to
    use
    stunnel?

    Of course the server end has to support TLS connections too.

    This is from 2:221/6:

    xinetd.conf:

    service binkps
    {
    port = 24567
    socket_type = stream
    protocol = tcp
    user = root
    wait = no
    disable = no
    type = UNLISTED
    server = /usr/bin/stunnel
    server_args = /etc/stunnel/binkps.conf
    }

    binkps.conf:

    client=no
    cert=/etc/letsencrypt/live/news.fidonet.fi/web.pem
    connect=127.0.0.1:24554

    'Tommi

    ---
    * Origin: smapinntp://rpi.rbb.bbs.fi (2:221/0)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Fri Dec 13 21:02:42 2019
    Hi Tommi,

    On 2019-12-13 07:12:44, you wrote to Dumas Walker:

    binkps.conf:

    client=no
    cert=/etc/letsencrypt/live/news.fidonet.fi/web.pem
    connect=127.0.0.1:24554

    I had to do this slightly different:

    /etc/stunnel # cat binkps.conf
    cert=/etc/letsencrypt/live/vlzn.nl/fullchain.pem key=/etc/letsencrypt/live/vlzn.nl/privkey.pem
    connect=24554

    But it seems to work. Can anyone test my node? TLS/SSL connects to my binkd for node 2:280/464 should go to fido.vlzn.nl:24553

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Tommi Koivula@2:221/6 to Wilfred van Velzen on Fri Dec 13 22:16:42 2019
    Hi Wilfred.

    13 Dec 19 21:02, you wrote to me:

    Hi Tommi,

    On 2019-12-13 07:12:44, you wrote to Dumas Walker:

    binkps.conf:

    client=no
    cert=/etc/letsencrypt/live/news.fidonet.fi/web.pem
    connect=127.0.0.1:24554

    I had to do this slightly different:

    /etc/stunnel # cat binkps.conf cert=/etc/letsencrypt/live/vlzn.nl/fullchain.pem key=/etc/letsencrypt/live/vlzn.nl/privkey.pem
    connect=24554

    Ok. I can live with that. :)

    But it seems to work. Can anyone test my node? TLS/SSL connects to my binkd for node 2:280/464 should go to fido.vlzn.nl:24553

    === Cut ===
    13 Dec 22:15:54 [14318] Substituted * to fido.vlzn.nl. for 2:280/464@fidonet by nodelist
    + 13 Dec 22:15:54 [14318] call to 2:280/464@fidonet
    + 13 Dec 22:15:54 [14318] External command 'openssl s_client -quiet -alpn binkp -connect fido.vlzn.nl:24553' started, pid 14319
    13 Dec 22:15:54 [14318] connected
    + 13 Dec 22:15:54 [14318] outgoing session with fido.vlzn.nl:binkp [fido.vlzn.nl.]
    - 13 Dec 22:15:54 [14318] OPT CRAM-MD5-dc2e895d9937cfd543e2b328118899ee
    + 13 Dec 22:15:54 [14318] Remote requests MD mode
    - 13 Dec 22:15:54 [14318] SYS FMail dev HQ, FKA Amiga O(n|ff)line BBS Lisse (AOBL)
    - 13 Dec 22:15:54 [14318] ZYZ Wilfred van Velzen
    - 13 Dec 22:15:54 [14318] LOC Lisse, Netherlands
    - 13 Dec 22:15:54 [14318] NDL CM,MO,IBN,PING,ENC
    - 13 Dec 22:15:54 [14318] TIME Fri, 13 Dec 2019 21:15:54 +0100
    - 13 Dec 22:15:54 [14318] VER binkd/1.1a-99/Linux binkp/1.1
    + 13 Dec 22:15:54 [14318] addr: 2:280/464@fidonet
    + 13 Dec 22:15:54 [14318] addr: 39:39/0@AmigaNet (n/a or busy)
    - 13 Dec 22:15:54 [14318] OPT EXTCMD GZ BZ2
    + 13 Dec 22:15:54 [14318] Remote supports EXTCMD mode
    + 13 Dec 22:15:54 [14318] Remote supports GZ mode
    + 13 Dec 22:15:54 [14318] Remote supports BZ2 mode
    + 13 Dec 22:15:54 [14318] done (to 2:280/464@fidonet, OK, S/R: 0/0 (0/0 bytes))
    13 Dec 22:15:54 [14318] session closed, quitting...
    13 Dec 22:15:54 [14318] rc(14319)=0
    === Cut ===

    Bye, Wilfred.

    'Tommi

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: nntps://news.fidonet.fi (2:221/6)
  • From Oli@2:280/464.47 to Tommi Koivula on Fri Dec 13 22:23:12 2019
    I cannot connect oli, but I can connect you and 2:221/6. :)

    My Raspberry was offline half of the day.

    Well, Poll to Oli works now too.

    Yeah, first real connection to my Fido point on the Raspberry.


    * Origin: kakistocracy (2:280/464.47)
  • From Oli@2:280/464.47 to Wilfred van Velzen on Fri Dec 13 22:46:44 2019
    But it seems to work. Can anyone test my node? TLS/SSL connects to my binkd for node 2:280/464 should go to fido.vlzn.nl:24553

    It works. I will use it for all connections to your node from now on. Let's see how stable it is (I don't expect any problems).


    * Origin: kakistocracy (2:280/464.47)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Fri Dec 13 21:37:30 2019
    Hi Tommi,

    On 2019-12-13 22:16:42, you wrote to me:

    binkps.conf:

    client=no
    cert=/etc/letsencrypt/live/news.fidonet.fi/web.pem
    connect=127.0.0.1:24554

    I had to do this slightly different:

    /etc/stunnel # cat binkps.conf
    cert=/etc/letsencrypt/live/vlzn.nl/fullchain.pem
    key=/etc/letsencrypt/live/vlzn.nl/privkey.pem
    connect=24554

    Ok. I can live with that. :)

    Those are the files letsencrypt generates by default. Don't you need to specify your (private) key?

    But it seems to work. Can anyone test my node? TLS/SSL connects to my
    binkd for node 2:280/464 should go to fido.vlzn.nl:24553

    === Cut ===
    13 Dec 22:15:54 [14318] Substituted * to fido.vlzn.nl. for 2:280/464@fidonet by nodelist + 13 Dec 22:15:54 [14318] call to 2:280/464@fidonet + 13 Dec 22:15:54 [14318] External command 'openssl s_client -quiet -alpn binkp -connect fido.vlzn.nl:24553' started, pid
    14319
    13 Dec 22:15:54 [14318] connected
    + 13 Dec 22:15:54 [14318] outgoing session with fido.vlzn.nl:binkp

    It works! :-)

    I'm only a bit surprised it came in on IPv4 not like your regular connections on IPv6!?

    2019-12-13T21:15:54.610268+01:00 wilnux5 stunnel: LOG5[5464]: Service [stunnel] accepted connection from 92.222.75.253:38554


    Thanks for testing!


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Oli on Fri Dec 13 23:31:18 2019
    Hi Oli,

    On 2019-12-13 22:46:44, you wrote to me:

    But it seems to work. Can anyone test my node? TLS/SSL connects to my
    binkd for node 2:280/464 should go to fido.vlzn.nl:24553

    It works.

    Thanks for testing! ;)

    I will use it for all connections to your node from now on. Let's see
    how stable it is (I don't expect any problems).

    Me neither: The config is set, so it should survive a reboot; a cronjob is active to renew my letsencrypt certificates...

    But I don't see it's absolute usefullness. Because binkd already encrypts (most) sessions. Only the initial connection setup is unencrypted. But that only contains already public information. Maybe if you live under a really surpressive regime, and you want to hide the fact you are communicating in fidonet? Maybe it helps a bit... But not if they take a closer look, at which IP's you communicate with all the time...


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Alan Ianson@1:153/757 to Wilfred van Velzen on Fri Dec 13 15:31:14 2019
    Hello Wilfred,

    But I don't see it's absolute usefullness. Because binkd already
    encrypts (most) sessions. Only the initial connection setup is unencrypted. But that only contains already public information. Maybe
    if you live under a really surpressive regime, and you want to hide
    the fact you are communicating in fidonet? Maybe it helps a bit... But
    not if they take a closer look, at which IP's you communicate with all
    the time...

    I'm not absolutely sure of all the implications. I prefer binkps for the same reasons I prefer https.

    I just polled your node over binkps and it seemed to work. :)

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Wilfred van Velzen@2:280/464 to Alan Ianson on Sat Dec 14 00:57:16 2019
    Hi Alan,

    On 2019-12-13 15:31:14, you wrote to me:

    But I don't see it's absolute usefullness. Because binkd already
    encrypts (most) sessions. Only the initial connection setup is
    unencrypted. But that only contains already public information. Maybe
    if you live under a really surpressive regime, and you want to hide
    the fact you are communicating in fidonet? Maybe it helps a bit... But
    not if they take a closer look, at which IP's you communicate with all
    the time...

    I'm not absolutely sure of all the implications. I prefer binkps for the same reasons I prefer https.

    You can't compare binkp and http in that regard.

    I just polled your node over binkps and it seemed to work. :)

    Thanks for testing! ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Michiel van der Vlist@2:280/5555 to Wilfred van Velzen on Sat Dec 14 00:44:32 2019
    Hello Wilfred,

    On Friday December 13 2019 23:31, you wrote to Oli:

    But I don't see it's absolute usefullness. Because binkd already
    encrypts (most) sessions. Only the initial connection setup is unencrypted. But that only contains already public information. Maybe
    if you live under a really surpressive regime, and you want to hide
    the fact you are communicating in fidonet? Maybe it helps a bit... But
    not if they take a closer look, at which IP's you communicate with all
    the time...

    It may even have an adverse effect. IMHO for us small fish the best defence against a hostile regime is to stay below the radar. Refrain from being an interesting target, so they don't take that closer look. Using TLS may draw their attention....

    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Alan Ianson@1:153/757 to Wilfred van Velzen on Fri Dec 13 16:16:28 2019
    Hello Wilfred,

    I'm not absolutely sure of all the implications. I prefer binkps
    for the same reasons I prefer https.

    You can't compare binkp and http in that regard.

    Your probably right. I am not a "network" guy and I don't fully follow all the reasons for httpd aside from the obvious, it's encrypted.

    I am happy with binkd and the binkp protocol as is. I don't think my binkp port is under attack and mail & files transfer quickly and efficiently.

    I don't mind taking steps to make sure that doesn't change.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Michiel van der Vlist on Fri Dec 13 16:21:10 2019
    Hello Michiel,

    It may even have an adverse effect. IMHO for us small fish the best defence against a hostile regime is to stay below the radar. Refrain
    from being an interesting target, so they don't take that closer look. Using TLS may draw their attention....

    Security by obscurity is not a good way forward.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Wilfred van Velzen on Fri Dec 13 17:00:44 2019
    Hello Wilfred,

    You can't compare binkp and http in that regard.

    Your probably right. I am not a "network" guy and I don't fully follow
    all the reasons for httpd aside from the obvious, it's encrypted.

    I meant https, not httpd.. :)

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Oli@2:280/464.47 to Wilfred van Velzen on Sat Dec 14 08:24:49 2019
    Hi Alan,

    On 2019-12-13 15:31:14, you wrote to me:

    But I don't see it's absolute usefullness. Because binkd already
    encrypts (most) sessions. Only the initial connection setup is
    unencrypted. But that only contains already public information.
    Maybe if you live under a really surpressive regime, and you
    want to hide the fact you are communicating in fidonet? Maybe it
    helps a bit... But not if they take a closer look, at which IP's
    you communicate with all the time...

    I'm not absolutely sure of all the implications. I prefer binkps
    for the same reasons I prefer https.

    You can't compare binkp and http in that regard.

    Of course you can. Encrypted data transmission over TCP/TLS. Content can be anything.


    * Origin: kakistocracy (2:280/464.47)
  • From Richard Menedetter@2:310/31 to Oli on Sat Dec 14 09:46:10 2019
    Hi Oli!

    14 Dec 2019 08:24, from Oli -> Wilfred van Velzen:

    You can't compare binkp and http in that regard.
    Of course you can. Encrypted data transmission over TCP/TLS.
    Content can be anything.

    I think the above comment was about http vs binkp. (not https vs. binkps)
    The point I think was that http is completely unencrypted, and binkp is usudally encrypted after the first packet exchange.

    CU, Ricsi

    ... Like most endeavors, life is seriously over-advertised and under-funded. --- GoldED+/LNX
    * Origin: You threw out my WHAT? (2:310/31)
  • From Tommi Koivula@2:221/360 to Wilfred van Velzen on Sat Dec 14 10:51:08 2019
    Hi Wilfred.

    13 Dec 19 21:37:30, you wrote to me:

    I had to do this slightly different:

    /etc/stunnel # cat binkps.conf
    cert=/etc/letsencrypt/live/vlzn.nl/fullchain.pem
    key=/etc/letsencrypt/live/vlzn.nl/privkey.pem
    connect=24554

    Ok. I can live with that. :)

    Those are the files letsencrypt generates by default. Don't you need to
    specify your
    (private) key?

    Yes. That "web.pem" of mine contains both. Your way is better, I changed to that. Thanks!

    But it seems to work. Can anyone test my node? TLS/SSL connects to my
    binkd for node 2:280/464 should go to fido.vlzn.nl:24553

    === Cut ===
    13 Dec 22:15:54 [14318] Substituted * to fido.vlzn.nl. for
    2:280/464@fidonet by nodelist + 13 Dec 22:15:54 [14318] call to
    2:280/464@fidonet + 13 Dec 22:15:54 [14318] External command 'openssl
    s_client -quiet -alpn binkp -connect fido.vlzn.nl:24553' started, pid 14319
    13 Dec 22:15:54 [14318] connected
    + 13 Dec 22:15:54 [14318] outgoing session with fido.vlzn.nl:binkp

    It works! :-)

    :-)

    Another stunnel is now up for 2:221/360: rbb.fidonet.fi, port 24567: stunnel in linux, binkd in OS/2. ;)

    I'm only a bit surprised it came in on IPv4 not like your regular connections on IPv6!?

    I wonder why openssl in linux prefers ipv4..?

    'Tommi

    ---
    * Origin: - rbb.fidonet.fi - Finland - (2:221/360)
  • From Wilfred van Velzen@2:280/464 to Michiel van der Vlist on Sat Dec 14 11:06:28 2019
    Hi Michiel,

    On 2019-12-14 00:44:32, you wrote to me:

    But I don't see it's absolute usefullness. Because binkd already
    encrypts (most) sessions. Only the initial connection setup is
    unencrypted. But that only contains already public information. Maybe
    if you live under a really surpressive regime, and you want to hide
    the fact you are communicating in fidonet? Maybe it helps a bit... But
    not if they take a closer look, at which IP's you communicate with all
    the time...

    MvdV> It may even have an adverse effect. IMHO for us small fish the best defence
    MvdV> against a hostile regime is to stay below the radar. Refrain from being an
    MvdV> interesting target, so they don't take that closer look. Using TLS may draw
    MvdV> their attention....

    On the contrary. There are probably bilions of TLS connections every day. Multiple from every device on the net. So a couple of extra don't get noticed at all. On the other hand. A special and encrypted binkp protocol connection stands out.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Oli on Sat Dec 14 11:10:23 2019
    Hi Oli,

    On 2019-12-14 08:24:49, you wrote to me:

    But I don't see it's absolute usefullness. Because binkd already
    encrypts (most) sessions. Only the initial connection setup is
    unencrypted. But that only contains already public information.
    Maybe if you live under a really surpressive regime, and you
    want to hide the fact you are communicating in fidonet? Maybe it
    helps a bit... But not if they take a closer look, at which IP's
    you communicate with all the time...

    I'm not absolutely sure of all the implications. I prefer binkps
    for the same reasons I prefer https.

    You can't compare binkp and http in that regard.

    Of course you can. Encrypted data transmission over TCP/TLS. Content can
    be
    anything.

    I meant http (not https) which isn't encrypted vs binkp which is!

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Richard Menedetter on Sat Dec 14 11:11:54 2019
    Hi Richard,

    On 2019-12-14 09:46:10, you wrote to Oli:

    You can't compare binkp and http in that regard.
    Of course you can. Encrypted data transmission over TCP/TLS.
    Content can be anything.

    I think the above comment was about http vs binkp. (not https vs. binkps) The point I think was that http is completely unencrypted, and binkp is usudally encrypted after the first packet exchange.

    Exactly!

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Sat Dec 14 11:30:32 2019
    Hi Tommi,

    On 2019-12-14 10:51:08, you wrote to me:

    /etc/stunnel # cat binkps.conf
    cert=/etc/letsencrypt/live/vlzn.nl/fullchain.pem
    key=/etc/letsencrypt/live/vlzn.nl/privkey.pem
    connect=24554

    Ok. I can live with that. :)

    Those are the files letsencrypt generates by default. Don't you need
    to specify your (private) key?

    Yes. That "web.pem" of mine contains both.

    Aha.

    Your way is better, I changed to that. Thanks!

    So you don't have to regenerate your web.pem, when your letsencrypt files get updated?

    I'm only a bit surprised it came in on IPv4 not like your regular
    connections on IPv6!?

    I wonder why openssl in linux prefers ipv4..?

    Indeed. Did you try ncat as Oli suggested?

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Michiel van der Vlist@2:280/5555 to Wilfred van Velzen on Sat Dec 14 12:56:04 2019
    Hello Wilfred,

    On Saturday December 14 2019 11:06, you wrote to me:

    MvdV>> It may even have an adverse effect. IMHO for us small fish the
    MvdV>> best defence against a hostile regime is to stay below the
    MvdV>> radar. Refrain from being an interesting target, so they don't
    MvdV>> take that closer look. Using TLS may draw their attention....

    On the contrary. There are probably bilions of TLS connections every
    day. Multiple from every device on the net. So a couple of extra don't
    get noticed at all.

    Hmmm... Law enforcement here keeps insisting that they want backdoors so they can read encrypted whatsapp etc.. But I do not hear them about TLS. So... they may already have backdoor or crack for TLS...

    On the other hand. A special and encrypted binkp protocol connection stands out.

    Point taken.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Tommi Koivula@2:221/360 to Wilfred van Velzen on Sat Dec 14 15:39:14 2019
    Hi Wilfred.

    14 Dec 19 11:30:32, you wrote to me:

    I'm only a bit surprised it came in on IPv4 not like your regular
    connections on IPv6!?

    I wonder why openssl in linux prefers ipv4..?

    Indeed. Did you try ncat as Oli suggested?

    I tried but:

    ncat: unrecognized option '--ssl-alpn'

    'Tommi

    --- Ncat: Version 7.01 ( https://nmap.org/ncat )
    * Origin: - rbb.fidonet.fi - Finland - (2:221/360)
  • From Wilfred van Velzen@2:280/464 to Michiel van der Vlist on Sat Dec 14 15:11:46 2019
    Hi Michiel,

    On 2019-12-14 12:56:04, you wrote to me:

    On the contrary. There are probably bilions of TLS connections every
    day. Multiple from every device on the net. So a couple of extra
    don't get noticed at all.

    MvdV> Hmmm... Law enforcement here keeps insisting that they want backdoors so
    MvdV> they can read encrypted whatsapp etc.. But I do not hear them about TLS.
    MvdV> So... they may already have backdoor or crack for TLS...

    There are some known attacks...


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Sat Dec 14 15:16:02 2019
    Hi Tommi,

    On 2019-12-14 15:39:14, you wrote to me:

    Indeed. Did you try ncat as Oli suggested?

    I tried but:

    ncat: unrecognized option '--ssl-alpn'

    Mine supports is neither, but --ssl (or even better --ssl-verify) should also work. (Then leave out the 'binkp' which is the argument for the --ssl-alpn option.)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Sat Dec 14 15:19:40 2019
    Hi Tommi,

    On 2019-12-14 10:51:08, you wrote to me:

    Another stunnel is now up for 2:221/360: rbb.fidonet.fi, port 24567: stunnel in linux, binkd in OS/2. ;)

    Btw: this works:

    # ncat --ssl rbb.fidonet.fi 24567
    ?.OPT CRAM-MD5-fc157639bd1ba3f3099ca284d35e2aee?
    SYS RBB/2?ZYZ Tommi Koivula?LOC Lake Ylo, Finland?
    NDL IBN,CM?PHN rbb.fidonet.fi?%TIME Sat, 14 Dec 2019 16:18:16 +0200?"VER binkd/1.1a-99.1/OS2 binkp/1.1?3 2:221/0@fidonet 2:221/1@fidonet 2:221/360@fidonet

    This isn't:

    # ncat --ssl-verify rbb.fidonet.fi 24567
    Ncat: Certificate verification error. QUITTING.

    Is your 'rbb' subdomain in your certificate?

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Tommi Koivula@2:221/0 to Wilfred van Velzen on Sat Dec 14 16:27:16 2019
    Wilfred van Velzen - Tommi Koivula :

     WV>>> Indeed. Did you try ncat as Oli suggested?

     TK>> I tried but:

     TK>> ncat: unrecognized option '--ssl-alpn'

    Mine supports is neither, but --ssl (or even better --ssl-verify) should also work. (Then leave out the 'binkp' which is the argument for the --ssl-alpn option.)

    Well, in my other pi (3b+ with ubuntu 18) it works:

    + 16:15 [17609] call to 2:221/6@fidonet
    + 16:15 [17609] External command 'ncat --ssl-alpn binkp news.fidonet.fi
    24567' started, pid 17610
    16:15 [17609] connected
    + 16:15 [17609] outgoing session with news.fidonet.fi:24567
    - 16:15 [17609] OPT CRAM-MD5-fdbdb5f989a83885d9744f31fa224eee
    + 16:15 [17609] Remote requests MD mode
    - 16:15 [17609] SYS mail.fidonet.fi
    - 16:15 [17609] ZYZ Tommi Koivula

    But still the connection is by ipv4. Funny.

    'Tommi

    ---
    * Origin: smapinntp://rpi.rbb.bbs.fi (2:221/0)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Sat Dec 14 15:53:55 2019
    Hi Tommi,

    On 2019-12-14 16:27:16, you wrote to me:

    ncat: unrecognized option '--ssl-alpn'

    Mine supports is neither, but --ssl (or even better --ssl-verify)
    should also work. (Then leave out the 'binkp' which is the argument
    for the --ssl-alpn option.)

    Well, in my other pi (3b+ with ubuntu 18) it works:

    + 16:15 [17609] call to 2:221/6@fidonet
    + 16:15 [17609] External command 'ncat --ssl-alpn binkp news.fidonet.fi 24567' started, pid 17610
    16:15 [17609] connected
    + 16:15 [17609] outgoing session with news.fidonet.fi:24567
    - 16:15 [17609] OPT CRAM-MD5-fdbdb5f989a83885d9744f31fa224eee
    + 16:15 [17609] Remote requests MD mode
    - 16:15 [17609] SYS mail.fidonet.fi
    - 16:15 [17609] ZYZ Tommi Koivula

    But still the connection is by ipv4. Funny.

    I'm getting:

    # date; ncat --ssl news.fidonet.fi 24567
    za dec 14 15:53:37 CET 2019
    Ncat: Connection refused.

    # date; ncat --ssl 2001:41d0:401:3100::1030 24567
    za dec 14 15:55:05 CET 2019
    Ncat: Connection refused.

    # date; ncat --ssl 92.222.75.253 24567
    za dec 14 15:55:20 CET 2019
    ?.OPT CRAM-MD5-96df98185a01b1b27afe1464129b44ee?SYS mail.fidonet.fi?ZYZ Tommi Koivula?LOC EU?%NDL 100M,IBN,IBNS:24567,CM,NNTP,IPv6?%TIME Sat, 14 Dec 2019 16:5
    ...

    So your stunnel doesn't even seem to be listening on IPv6? And my ncat only tries IPv6 if given the hostname, so it seems...


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Tommi Koivula@2:221/360 to Wilfred van Velzen on Sat Dec 14 17:48:44 2019
    Hi Wilfred.

    14 Dec 19 15:19:40, you wrote to me:

    Hi Tommi,

    On 2019-12-14 10:51:08, you wrote to me:

    Another stunnel is now up for 2:221/360: rbb.fidonet.fi, port 24567:
    stunnel in linux, binkd in OS/2. ;)

    Btw: this works:

    # ncat --ssl rbb.fidonet.fi 24567
    ?.OPT CRAM-MD5-fc157639bd1ba3f3099ca284d35e2aee?
    SYS RBB/2?ZYZ Tommi Koivula?LOC Lake Ylo, Finland?
    NDL IBN,CM?PHN rbb.fidonet.fi?%TIME Sat, 14 Dec 2019 16:18:16 +0200?"VER binkd/1.1a-99.1/OS2 binkp/1.1?3 2:221/0@fidonet 2:221/1@fidonet
    2:221/360@fidonet

    This isn't:

    # ncat --ssl-verify rbb.fidonet.fi 24567
    Ncat: Certificate verification error. QUITTING.

    Is your 'rbb' subdomain in your certificate?

    I think not. This dual linux + os/2 thing is a bit weird. :)

    'Tommi

    ---
    * Origin: - rbb.fidonet.fi - Finland - (2:221/360)
  • From Tommi Koivula@2:221/360 to Wilfred van Velzen on Sat Dec 14 17:52:24 2019
    Hi Wilfred.

    14 Dec 19 15:53:54, you wrote to me:

    I'm getting:

    # date; ncat --ssl news.fidonet.fi 24567
    za dec 14 15:53:37 CET 2019
    Ncat: Connection refused.

    # date; ncat --ssl 2001:41d0:401:3100::1030 24567
    za dec 14 15:55:05 CET 2019
    Ncat: Connection refused.

    # date; ncat --ssl 92.222.75.253 24567
    za dec 14 15:55:20 CET 2019
    ?.OPT CRAM-MD5-96df98185a01b1b27afe1464129b44ee?SYS mail.fidonet.fi?ZYZ
    Tommi
    Koivula?LOC EU?%NDL 100M,IBN,IBNS:24567,CM,NNTP,IPv6?%TIME Sat, 14 Dec
    2019 16:5
    ...

    So your stunnel doesn't even seem to be listening on IPv6? And my ncat
    only tries
    IPv6 if given the hostname, so it seems...

    Corrected, added "flags = ipv6" to xinetd conf.

    But it does not explain why my outbound "openssl" is ipv4?

    'Tommi

    ---
    * Origin: - rbb.fidonet.fi - Finland - (2:221/360)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Sat Dec 14 17:11:12 2019
    Hi Tommi,

    On 2019-12-14 17:48:44, you wrote to me:

    # ncat --ssl-verify rbb.fidonet.fi 24567
    Ncat: Certificate verification error. QUITTING.

    Is your 'rbb' subdomain in your certificate?

    I think not. This dual linux + os/2 thing is a bit weird. :)

    When you create your certificate with 'certbot-auto ...' you can add multiple (sub)domains with the -D option...

    (--ssl-verify works for news.fidonet.fi)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Sat Dec 14 17:15:19 2019
    Hi Tommi,

    On 2019-12-14 17:52:24, you wrote to me:

    So your stunnel doesn't even seem to be listening on IPv6? And my
    ncat only tries IPv6 if given the hostname, so it seems...

    Corrected, added "flags = ipv6" to xinetd conf.

    Confirmed:

    # date; ncat --ssl-verify news.fidonet.fi 24567
    za dec 14 17:14:16 CET 2019
    ?.OPT CRAM-MD5-9ebf13b5deb0d0f7db7f5d48de74c1ee?SYS mail.fidonet.fi?ZYZ Tommi Koivula?LOC EU?%NDL 100M,IBN,IBNS:24567,CM,NNTP,IPv6?%TIME Sat, 14 Dec 2019 18:14:16 +0200?"VER binkd/1.1a-99/Linux binkp/1.1

    But it does not explain why my outbound "openssl" is ipv4?

    My ncat does, and 'man openssl' doesn't even mention IPv6. Maybe it's something in your /etc/gai.conf ?

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Tommi Koivula@2:221/0 to Wilfred van Velzen on Sat Dec 14 20:11:54 2019

    Wilfred van Velzen - Tommi Koivula <0@464.280.2> wrote:

    WVVTK>
    WVVTK> WV>> # ncat --ssl-verify rbb.fidonet.fi 24567
    WVVTK> WV>> Ncat: Certificate verification error. QUITTING.
    WVVTK>
    WVVTK> WV>> Is your 'rbb' subdomain in your certificate?
    WVVTK>
    WVVTK> TK> I think not. This dual linux + os/2 thing is a bit weird. :) WVVTK>
    WVVTK> When you create your certificate with 'certbot-auto ...' you can add WVVTK> multiple (sub)domains with the -D option...

    I dont know about certbot-auto, I dont have it. But

    ncat --ssl-verify rbb.fidonet.fi 24567

    should be fine now.

    WVVTK> (--ssl-verify works for news.fidonet.fi)

    :)

    'Tommi

    ---
    * Origin: smapinntp://rpi.rbb.bbs.fi (2:221/0)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Sat Dec 14 20:40:01 2019
    Hi Tommi,

    On 2019-12-14 20:11:54, you wrote to me:

    I dont know about certbot-auto, I dont have it.

    That's the shell script I got from letsencrypt that is doing the work for me...

    But

    ncat --ssl-verify rbb.fidonet.fi 24567

    should be fine now.

    Confirmed.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Tommi Koivula@2:221/0 to Wilfred van Velzen on Sun Dec 15 09:36:20 2019
    On 14.12.2019 17:15, Wilfred van Velzen - Tommi Koivula :

     TK>> But it does not explain why my outbound "openssl" is ipv4?

    My ncat does, and 'man openssl' doesn't even mention IPv6. Maybe it's something in your /etc/gai.conf ?

    Nothing in gai.conf... Only #comments.

    'Tommi

    ---
    * Origin: smapinntp://rpi.rbb.bbs.fi (2:221/0.0)
  • From Michiel van der Vlist@2:280/5555 to Alan Ianson on Sun Dec 15 09:29:28 2019
    Hello Alan,

    On Friday December 13 2019 16:21, you wrote to me:

    It may even have an adverse effect. IMHO for us small fish the
    best defence against a hostile regime is to stay below the radar.
    Refrain from being an interesting target, so they don't take that
    closer look. Using TLS may draw their attention....

    Security by obscurity is not a good way forward.

    That depends. But not using TLS is hardly "obscurity" isn't it?

    I am still puzzled. I appreciate that binkd over TLS may be an interesting challenge from the technical POV. As such I may give it a try myself one day if I figure out how to do it under Windows.

    I can understand why one would use https instead of http when dealing with sensitive information such as bank account numbers etc. But for Fidonet? What are you trying to hide/protect from whom? TLS does not hide the meta data such as what IP communicates with what other IP. Binkd already has encryption on the pkt content level. Plus that 99% of Fidonet is echomail and encryting echomail makes little or no sense. For routed netmail, using encrytion on the transport level does not protect against snooping by sysops en route.

    So other than the pure sensation of a technical challenge, why?


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Alan Ianson@1:153/757 to Michiel van der Vlist on Sun Dec 15 02:15:08 2019
    Hello Michiel,

    That depends. But not using TLS is hardly "obscurity" isn't it?

    We are an obscure group today but not because we use TLS or not.

    I am still puzzled. I appreciate that binkd over TLS may be an
    interesting challenge from the technical POV. As such I may give it a
    try myself one day if I figure out how to do it under Windows.

    I am also going to try to do this and if I can accomplish that I am going to keep on doing that with links that support it.

    I can understand why one would use https instead of http when dealing
    with sensitive information such as bank account numbers etc. But for Fidonet? What are you trying to hide/protect from whom?

    I have nothing to hide. I would just prefer to be secure that unsecure.

    TLS does not hide the meta data such as what IP communicates with what other IP. Binkd already has encryption on the pkt content level.

    I don't want or need to hide the fact I am on and using the internet. I would like passwords to be hidden from anyone who might be snooping my traffic.

    Plus that 99% of Fidonet is echomail and encryting echomail makes
    little or no sense. For routed netmail, using encrytion on the
    transport level does not protect against snooping by sysops en route.

    Mystic's implementation of all this includes netmail optionaly. When Mystic nodes use an encryption key between nodes netmail between them is encrypted. If it is stored, it is stored in an encrypted state.

    I know this because I had a typo in my encryption key at one time and could not read my own netmail.. :)

    So other than the pure sensation of a technical challenge, why?

    It's not sensational. It is just security. Security must be important at some level or there would not be a crypt option at all. I think TLS is just the way it is done today. Someone told me there was a new big thing on the horizon, I forget what it was called. We may need to move to something else one day, I wouldn't even guess but I would be happy with TLS. I think that will do what we need to do.. probably for some time to come.


    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Michiel van der Vlist@2:280/5555 to Alan Ianson on Sun Dec 15 11:45:52 2019
    Hello Alan,

    On Sunday December 15 2019 02:15, you wrote to me:

    I can understand why one would use https instead of http when
    dealing with sensitive information such as bank account numbers
    etc. But for Fidonet? What are you trying to hide/protect from
    whom?

    I have nothing to hide. I would just prefer to be secure that
    unsecure.

    Just watch out for a false sense of security.

    TLS does not hide the meta data such as what IP communicates with
    what other IP. Binkd already has encryption on the pkt content
    level.

    I don't want or need to hide the fact I am on and using the internet.
    I would like passwords to be hidden from anyone who might be snooping
    my traffic.

    Binkd already has secure verification of the session password. Other passwords are automatically secured by binkd's own encryption. an extra TLS layer adds nothing to that.
    Plus that 99% of Fidonet is echomail and encryting echomail makes
    little or no sense. For routed netmail, using encrytion on the
    transport level does not protect against snooping by sysops en
    route.

    Mystic's implementation of all this includes netmail optionaly. When Mystic nodes use an encryption key between nodes netmail between them
    is encrypted. If it is stored, it is stored in an encrypted state.

    For end to end message encryption and authorisation we have PGP. Served me well for three centuries.

    I know this because I had a typo in my encryption key at one time and could not read my own netmail.. :)

    That shows that one can overdo it. I see no advantage in storing my netmail in encrypted form. It just makes things difficult for me. To read my stored netmail one needs physical access to my system.

    I don't have locks on my bathoom either. Just a warning that it is in use. Anything moe just makes life more difficult fo myself.

    So other than the pure sensation of a technical challenge, why?

    It's not sensational. It is just security. Security must be important
    at some level or there would not be a crypt option at all.

    Of course it is important at some level. But one can overdo it and than it gets in the way of comfort. I protect the codes for internet banking and use a secure link for it. But I am not going out of my way to protect my toilet against unauthorised use. That just makes life difficult for me in case of .. well guess what.. ;-)

    I think TLS is just the way it is done today.

    Hmmm... I have my doubts. Have you heard about the Diginotar debacle? Diginotar was a Dutch CA. It was hacked and all the certificates were compromised.

    Other CAs have had problems with security too.

    As I said, I consider it a technical challenge. When I find a way to get it working with Windows, I may give it a try. But I won't feel ant safer than I already am with binkd's own security.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Tommi Koivula@2:221/0 to Michiel van der Vlist on Sun Dec 15 13:50:22 2019
    On 15.12.2019 9:29, Michiel van der Vlist - Alan Ianson :

    MvdV> So other than the pure sensation of a technical challenge, why?

    Why not? :)

    'Tommi

    ---
    * Origin: smapinntp://rpi.rbb.bbs.fi (2:221/0.0)
  • From Michiel van der Vlist@2:280/5555 to Tommi Koivula on Mon Dec 16 12:33:48 2019
    Hello Tommi,

    On Sunday December 15 2019 13:50, you wrote to me:

    On 15.12.2019 9:29, Michiel van der Vlist - Alan Ianson :

    MvdV>> So other than the pure sensation of a technical challenge, why?

    Why not? :)

    I can think of several reasons:

    1) Don't fix it if it ain't broke. I am not convinced yet that binkd's security is broke and needs fixing. I am not convinced that TLS offers better protection against snooping than what binkd alread hasy. Half of TLS is providing authoritative identity to the server. I don't see any value for that in Fidonet. TTBOMK there has been no case of someone succesfully setting up a rogue node amd maskerading for someone else. If only because there is no bussines model..

    2) It violates the KISS principle. I see little or no added value in adding TLS to Binkd. In the case of Binkd it just makes things more complicatied and prone to misconfigutaion and other mishaps.

    3) If it were integrated in Binkd it would be one thing, but I looked at stunnel for Windows and it exists. But it does not look all that easy to implement. There is lots of room for typos and other errors.

    4) The stunnel method does not scale well. It has the same problem as running an old IPv4 only application via a 6to4 proxy. Incoming is easy, outgoing requires a dedicated setting for each destination. Does not scale well beyond 10 destinations or so.

    5) A weakness of TLS is that it depends on a third party: the Certificate Authority. I don't like to be dependant om a third party. Fidonet was designed as a peer to peer network.

    6) I suspect the main reason for the existance of certificates is that it is a bussiness model for those issuing the certificates.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Alan Ianson@1:153/757 to Michiel van der Vlist on Mon Dec 16 14:59:10 2019
    Hello Michiel,

    Why not? :)

    I can think of several reasons:

    1) Don't fix it if it ain't broke. I am not convinced yet that binkd's security is broke and needs fixing.

    I don't think binkd or the binkp protocol are broken and need fixing.

    I am not convinced that TLS offers better protection against snooping
    than what binkd alread hasy. Half of TLS is providing authoritative identity to the server. I don't see any value for that in Fidonet.
    TTBOMK there has been no case of someone succesfully setting up a
    rogue node amd maskerading for someone else. If only because there is
    no bussines model..

    This has happened in the past. nobogus comes to mind.

    TLS certainly offers better security. No question.

    2) It violates the KISS principle. I see little or no added value in adding TLS to Binkd. In the case of Binkd it just makes things more complicatied and prone to misconfigutaion and other mishaps.

    It does require some setup. Synchronet's BinkIT mailer currently has support for a binkps listener setup like this in Synchronet's services.ini

    [BINKPS]
    Port=24553
    Command=binkit.js
    Options=TLS

    That's it for a binkps listener. To poll a node over a binkps capable link add "BinkpTLS=true" in that nodes section of sbbsecho.ini along with the appropriate port.

    The above seems pretty simple to me. I'm hopefull that we can also do this just as simply with binkd but we'd need some help and input from the binkd developers.

    This was all done without changing binkp. We have simply put binkp on a secure channel.

    3) If it were integrated in Binkd it would be one thing, but I looked
    at stunnel for Windows and it exists. But it does not look all that
    easy to implement. There is lots of room for typos and other errors.

    Yes, that is what we need. Perhaps binkd could also listen on port 24553 (or whatever port you choose) for binkps (binkp over TLS) and an easy way to poll binkps capable nodes, something along the lines of BinkpTLS=true.

    4) The stunnel method does not scale well. It has the same problem as running an old IPv4 only application via a 6to4 proxy. Incoming is
    easy, outgoing requires a dedicated setting for each destination. Does
    not scale well beyond 10 destinations or so.

    I have not been able to figure this out but I see some nodes do this successfully with binkd. The binkd developers may have a better way.

    5) A weakness of TLS is that it depends on a third party: the
    Certificate Authority. I don't like to be dependant om a third party. Fidonet was designed as a peer to peer network.

    I currently use a self signed certificate. I could also get a certificate from letsencrypt or elsewhere if that would be better.

    Do folks still use PGP? Something like that is also possible although we are stepping away from simplicity again.

    6) I suspect the main reason for the existance of certificates is that
    it is a bussiness model for those issuing the certificates.

    I do have a certificate from letsencrypt that I use for my domain. It hasn't cost me any extra $$$ to date.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Deon George@3:633/509 to Alan Ianson on Tue Dec 17 11:44:50 2019
    Re: Binkd and TLS
    By: Alan Ianson to Michiel van der Vlist on Mon Dec 16 2019 02:59 pm

    Do folks still use PGP? Something like that is also possible although we are stepping away from simplicity again.

    I've got PGP messages being sent/received in Synchronet - I use it for my InterBBS transport of Videotex pages - to verify the signed message has authorisation on the pages that it is updating. (At the moment I shell out to pgp.)

    I would really like to get native PGP support into SBBS - there are a few javascript modules to enable it, but SBBS' javascript engine is too old (from what I've worked out so far). DM said he is planning on updating it, but I dont know when that would happen.

    If he did, then PGP could be used for netmail signing and verification as well, which would be great.
    ...deon


    ... I used to work in a fire hydrant factory. You couldn't park anywhere near it.
    --- SBBSecho 3.10-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Alexey Fayans@2:5030/1997 to Alan Ianson on Tue Dec 17 04:21:22 2019
    Hello Alan!

    On Mon, 16 Dec 2019 at 14:59 -0800, you wrote to Michiel van der Vlist:

    TLS certainly offers better security. No question.
    [...]
    I currently use a self signed certificate.

    Self-signed certificate means no security, unless you publish your CA pubkey somewhere and client verifies it.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Richard Menedetter@2:310/31 to Alan Ianson on Tue Dec 17 09:55:52 2019
    Hi Alan!

    16 Dec 2019 14:59, from Alan Ianson -> Michiel van der Vlist:

    I currently use a self signed certificate. I could also get a
    certificate from letsencrypt or elsewhere if that would be better.

    Yes, definitely.
    Your certificate is not signed by a trusted party, so it will NOT be trusted until you manually declare it as trusted.

    Do folks still use PGP? Something like that is also possible although
    we are stepping away from simplicity again.

    Yes.
    But PGP does not tie into TLS.
    You can't use PGP certificates for TLS.

    6) I suspect the main reason for the existance of certificates is
    that it is a bussiness model for those issuing the certificates.
    I do have a certificate from letsencrypt that I use for my domain. It hasn't cost me any extra $$$ to date.

    Prior to Letsencrypt certificates cost money. (there was cacert.org but this was not trusted either, so it was not really a solution for most)
    Now it still costs money, if you are using it for businesses, or if you do not want to use letsencrypt.

    CU, Ricsi

    ... If you are going to try cross country skiing start with a small country. --- GoldED+/LNX
    * Origin: We've learned how to make a living, but not a life. (2:310/31)
  • From Michiel van der Vlist@2:280/5555 to Alan Ianson on Tue Dec 17 10:40:02 2019
    Hello Alan,

    On Monday December 16 2019 14:59, you wrote to me:

    1) Don't fix it if it ain't broke. I am not convinced yet that
    binkd's security is broke and needs fixing.

    I don't think binkd or the binkp protocol are broken and need fixing.

    Then what problem ARE we trying to fix?

    I am not convinced that TLS offers better protection against
    snooping than what binkd alread hasy. Half of TLS is providing
    authoritative identity to the server. I don't see any value for
    that in Fidonet. TTBOMK there has been no case of someone
    succesfully setting up a rogue node amd maskerading for someone
    else. If only because there is no bussines model..

    This has happened in the past. nobogus comes to mind.

    Apples and oranges. Nobogus solved problems created by rouge CLIENTS. TLS does not protect against that. It only authorises the /server/, not the /client/.

    TLS certainly offers better security. No question.

    So you say. But merely claiming it is "better" is just like claiming aluminium is "better" than copper.

    In what way is TLS "better"? A claim of "better" security has to be more specific than just that. Better than what? Better against what threats and by whom?

    If you do not specify the threat, a claim of better security is meaningless.

    2) It violates the KISS principle. I see little or no added value
    in adding TLS to Binkd. In the case of Binkd it just makes things
    more complicatied and prone to misconfigutaion and other mishaps.

    It does require some setup. Synchronet's BinkIT mailer currently has support for a binkps listener setup like this in Synchronet's
    services.ini

    The world of Fidonet is bigger than Synchronet (Thank god). You make it sound like "Synchronet supports it, so it must be a good thing". Sorry, I am not of the "Synchronet is better" club.

    This was all done without changing binkp. We have simply put binkp on
    a secure channel.

    But why? I still have no answer for that. Let me put it this way:

    If binkd over TLS is the solution, what is the problem?


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Alan Ianson@1:153/757 to Michiel van der Vlist on Tue Dec 17 02:19:14 2019
    Hello Michiel,

    Then what problem ARE we trying to fix?

    We are not trying to fix problems. We are trying to be secure.

    Apples and oranges. Nobogus solved problems created by rouge CLIENTS.
    TLS does not protect against that. It only authorises the /server/,
    not the /client/.

    TLS needs to be supported and used by both client and server.

    TLS certainly offers better security. No question.

    So you say. But merely claiming it is "better" is just like claiming aluminium is "better" than copper.

    In what way is TLS "better"? A claim of "better" security has to be
    more specific than just that. Better than what? Better against what threats and by whom?

    I can't answer why, I don't know all the reasons why. TLS is the standard method used today to secure traffic on the internet, and I would like to be secure.

    We could also just stand still and see how it goes. I am just being proactive WRT security.

    It does require some setup. Synchronet's BinkIT mailer currently
    has support for a binkps listener setup like this in Synchronet's
    services.ini

    The world of Fidonet is bigger than Synchronet (Thank god). You make
    it sound like "Synchronet supports it, so it must be a good thing".
    Sorry, I am not of the "Synchronet is better" club.

    True. I want us all to be secure regardless of our choice of software.

    This was all done without changing binkp. We have simply put
    binkp on a secure channel.

    But why? I still have no answer for that. Let me put it this way:

    If binkd over TLS is the solution, what is the problem?

    There is no problem here that we are trying to solve. Binkd currently supports an option called CRYPT, for the purposes of security. That was a good option when it was implemented. Today TLS is used for the purposes of security.

    I could be all wrong but I think TLS is a better option, that's all.


    Maybe I said that wrong. How about this. Binkd's CRYPT option is weak (by todays standards). Maybe we should think about using something more up to date, like TLS.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Michiel van der Vlist@2:280/5555 to Alexey Fayans on Tue Dec 17 12:19:34 2019
    Hello Alexey,

    On Tuesday December 17 2019 04:21, you wrote to Alan Ianson:

    I currently use a self signed certificate.

    Self-signed certificate means no security, unless you publish your CA pubkey somewhere and client verifies it.

    Even if one publishes the pub key somewhere. It is still like:

    I, Michiel van der Vlist - self appointed Certified Authority - hereby declare that when Michiel van der Vlist claims to be Michiel van der Vlist, he is telling the truth. For verifications, download my public key from my website: www.vlist.eu/pubkey.

    A self signed certificate is usefull for testing the setup in the lab. For real use in the big bad world it is useless.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Richard Menedetter@2:310/31 to Michiel van der Vlist on Tue Dec 17 12:36:36 2019
    Hi Michiel!

    17 Dec 2019 10:40, from Michiel van der Vlist -> Alan Ianson:

    Apples and oranges. Nobogus solved problems created by rouge CLIENTS.
    TLS does not protect against that.
    It only authorises the /server/, not the /client/.

    Nope.
    You can authenticate the client as well.
    But naturally then every client needs a signed certificate, and the server needs to verify that client certificate.

    CU, Ricsi

    ... Thoughtfulness is to friendship what sunshine is to a garden.
    --- GoldED+/LNX
    * Origin: Always first decide the sentence, then the verdict. (2:310/31)
  • From Michiel van der Vlist@2:280/5555 to Alan Ianson on Tue Dec 17 13:13:01 2019
    Hello Alan,

    On Tuesday December 17 2019 02:19, you wrote to me:

    Then what problem ARE we trying to fix?

    We are not trying to fix problems. We are trying to be secure.

    "Secure" is meaningless without specifying against WHAT. What threats are we securing against?

    Apples and oranges. Nobogus solved problems created by rouge
    CLIENTS. TLS does not protect against that. It only authorises
    the /server/, not the /client/.

    TLS needs to be supported and used by both client and server.

    I know that. But it is designed for a client/server model. It verifies to the client that the server is who it claims to be. Not the other way around. (Not in the standard impelmentatios anyway) The TLS verification mechanism protects the client against being redirected to a rogue server. It does not protect the server against a maliciouis client. For that there usually is identification on the application level. Often called log in. So TLS does not protect against someone with evil intentions to connect to your binkp server and do something malicious.

    In what way is TLS "better"? A claim of "better" security has to
    be more specific than just that. Better than what? Better against
    what threats and by whom?

    I can't answer why, I don't know all the reasons why. TLS is the
    standard method used today to secure traffic on the internet,

    That does not make it better for use in Fidonet. Fidonet is not the InterNet, it just makes use of it.

    and I would like to be secure.

    You keep saying that, but you can't explain against what we are securing and you can't explain why using TLS is more secure than using the security binkp already has,

    We could also just stand still and see how it goes.

    If you do not know what you are doing, "do nothing" ain't such a bad strategy...

    I am just being proactive WRT security.

    In order to move forward, one first has to know which direction matches "forward".

    It does require some setup. Synchronet's BinkIT mailer currently
    has support for a binkps listener setup like this in
    Synchronet's services.ini

    The world of Fidonet is bigger than Synchronet (Thank god). You
    make it sound like "Synchronet supports it, so it must be a good
    thing". Sorry, I am not of the "Synchronet is better" club.

    True. I want us all to be secure regardless of our choice of software.

    I am not convinced that adding TLS to binkp enhances security. Especially with security, just "moving forward" withou knowing exactly what you are doing is a bad idea. You may actually be less secure after the move.

    This was all done without changing binkp. We have simply put
    binkp on a secure channel.

    But why? I still have no answer for that. Let me put it this way:

    If binkd over TLS is the solution, what is the problem?

    There is no problem here that we are trying to solve.

    If there is no problem then why add TLS to binkp?

    Binkd currently supports an option called CRYPT, for the purposes of security.

    First there is the session password. That protects the server against a rogue client posing as a trusted party.

    That was a good option when it was implemented.

    What makes you think the CRYPT option of binkp is no longer a good option?

    Today TLS is used for the purposes of security.

    It is used by many. That's no guarantee it is "better".

    I could be all wrong but I think TLS is a better option, that's all.

    When it concern security I'd rather not rely on "think". I prefer demonstrated facts.

    Maybe I said that wrong. How about this. Binkd's CRYPT option is weak
    (by todays standards).

    In what way is it weak? Has it been cracked? Is there a known vulnerability? Is there a backdoor? Are there any known cases of damage to Fidonet because of a weakness in CRYPT?

    Maybe we should think about using something more up to date, like TLS.

    "More up to date" is not better by definition. With governments that keep pushing for backdoors in encryption, "someting more up to date" may actually be a step back.

    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Alexey Fayans@2:5030/1997 to Michiel van der Vlist on Tue Dec 17 15:31:28 2019
    Hello Michiel!

    On Tue, 17 Dec 2019 at 12:19 +0100, you wrote to me:

    Self-signed certificate means no security, unless you publish
    your CA pubkey somewhere and client verifies it.

    Even if one publishes the pub key somewhere. It is still like:

    I, Michiel van der Vlist - self appointed Certified Authority - hereby declare that when Michiel van der Vlist claims to be Michiel van der Vlist, he is telling the truth. For verifications, download my public
    key from my website: www.vlist.eu/pubkey.

    A self signed certificate is usefull for testing the setup in the lab.
    For real use in the big bad world it is useless.

    I mean something different. For example, if it would be somehow possible to store CA pubkey in the nodelist, it could work.

    Or we could have a global FIDONET CA. :)


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Michiel van der Vlist@2:280/5555 to Richard Menedetter on Tue Dec 17 13:29:37 2019
    Hello Richard,

    On Tuesday December 17 2019 12:36, you wrote to me:

    Apples and oranges. Nobogus solved problems created by rouge
    CLIENTS. TLS does not protect against that. It only authorises
    the /server/, not the /client/.

    Nope.
    You can authenticate the client as well.

    Yes, I know, it can be done. But TLS was designed around a client/server model and authentication of the client is not standard.

    But naturally then every client needs a signed certificate, and the
    server needs to verify that client certificate.

    Indeed. And what is the added value of that? Session and packet passwords have ended anonymus mailbombs and other bad stuff. Binkp's CRYPT protects against unauthorised listeners on the channel. I am not aware of binkp's security being compromised.

    Plus that I still wonder what we are protecting against whom. Do we really need 10 cm armour and triple locks to protect Fidonet content?


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Richard Menedetter@2:310/31 to Michiel van der Vlist on Tue Dec 17 14:31:44 2019
    Hi Michiel!

    17 Dec 2019 13:29, from Michiel van der Vlist -> Richard Menedetter:

    You can authenticate the client as well.
    Yes, I know, it can be done. But TLS was designed around a
    client/server model and authentication of the client is not standard.

    I beg to differ on this.
    It _IS_ standard, but much less used, so it is less common.
    Because it is easier to roll out certificates on one server, then on all clients that could potentially access your server.

    But this does not make it less standard, only less used.
    You can import a client certificate into Firefox and other browsers for a long period of time.
    And you can use this as a more secure means of authentication.

    But naturally then every client needs a signed certificate, and
    the server needs to verify that client certificate.
    Indeed. And what is the added value of that?

    There is potential value. (eg. passwords can be very easy to guess ... toor, passw0rd, ...) client certificates are much more secure than eg. 8 digit passwords.
    I doubt that that added value is "worth it" in fidonet, where many people used ancient software, and only a small minority is interested to roll out new features.

    Binkp's CRYPT protects against unauthorised listeners on the channel.
    I am not aware of binkp's security being compromised.

    I am also not aware of it.
    But you have to admit that security researchers have more prestigeous targets then binkd crypt. (So I assume that it was never really challenged and analyzed.)
    Breaking TLS gains you lots of $$$, so many people try it. (without any knowledge of then being successful.)

    Plus that I still wonder what we are protecting against whom. Do we
    really need 10 cm armour and triple locks to protect Fidonet content?

    Why not? ;)
    Using binkp in a stunnel definitely will not weaken the security.
    (eg. if you break the stunnel, you still are left with the same binkp stream that you would have had previously.)
    And adding a TLS option for clients that support it, will not be weaker than our existing crypt implementation.

    So it is doable, and would benefit security from my point of view.
    But I do not think many people would use it.

    The easiest target would be to have a second port where you can make stunnel connections. (this is not very practicable from my point of view, outside of PoC)
    Or the second easiest but more useable target would be to implement starttls and use it if both parties support it. (relying on passwords, not client certificates)

    CU, Ricsi

    ... If you knew what you're talking about, you'd be dangerous
    --- GoldED+/LNX
    * Origin: You are an insult to free speech. (2:310/31)
  • From Michiel van der Vlist@2:280/5555 to Alexey Fayans on Tue Dec 17 14:34:52 2019
    Hello Alexey,

    On Tuesday December 17 2019 15:31, you wrote to me:

    I mean something different. For example, if it would be somehow
    possible to store CA pubkey in the nodelist, it could work.

    That would mean a significant redesign of the format of the nodelist. WHich would make a lot of nodelist processing sofware go in a flat spin. I am not sure we should go that way...

    Or we could have a global FIDONET CA. :)

    Experience with previous "centralised authority" in Fidonet tells me this is a bad idea. Can you say "echolist"?

    If I have to choose between the two evils of a centralised authority within Fidonet or one outside Fidonet, I'd pefer the latter. At last the latter presumably has no interest in playing fidonet politcal games.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Alexey Fayans@2:5030/1997 to Michiel van der Vlist on Tue Dec 17 18:02:40 2019
    Hello Michiel!

    On Tue, 17 Dec 2019 at 14:34 +0100, you wrote to me:

    I mean something different. For example, if it would be somehow
    possible to store CA pubkey in the nodelist, it could work.
    That would mean a significant redesign of the format of the nodelist. WHich would make a lot of nodelist processing sofware go in a flat
    spin. I am not sure we should go that way...

    Yep, exactly.

    Or we could have a global FIDONET CA. :)
    Experience with previous "centralised authority" in Fidonet tells me
    this is a bad idea. Can you say "echolist"?

    I don't like this either.

    If I have to choose between the two evils of a centralised authority within Fidonet or one outside Fidonet, I'd pefer the latter. At last
    the latter presumably has no interest in playing fidonet politcal
    games.

    The only problem with internet trusted CAs is that a node would need a domain to issue certificate for. While in FIDONET we could issue certificates for node addresses.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Tommi Koivula@2:221/360 to Michiel van der Vlist on Tue Dec 17 17:31:11 2019

    MvdV>> So other than the pure sensation of a technical challenge, why?

    Why not? :)

    I can think of several reasons:

    1) Don't fix it if it ain't broke.

    I did not fix anything, I just added a parallel way to connect my binkd. :)

    'Tommi

    --- Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
    * Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)
  • From Michiel van der Vlist@2:280/5555 to Richard Menedetter on Tue Dec 17 16:10:47 2019
    Hello Richard,

    On Tuesday December 17 2019 14:31, you wrote to me:

    But this does not make it less standard, only less used. You can
    import a client certificate into Firefox and other browsers for a long period of time. And you can use this as a more secure means of authentication.

    OK, "less used" describes it better than "non standard".

    But naturally then every client needs a signed certificate, and
    the server needs to verify that client certificate.

    Indeed. And what is the added value of that?

    There is potential value. (eg. passwords can be very easy to guess ... toor, passw0rd, ...)

    That is not a shortcoming of the protocol, it is a shortcoming of the user.

    client certificates are much more secure than eg. 8 digit passwords.

    Binkd session passwords are not limited to 8 characters. I just tried a 25 byte string and it functions. I say "bytes" because I inserted a cyrillic UTF-8 character. Changing the last byte results in a password error, so all bytes are used. Case sensitive. I don't know what the limit is, but it is at least 25.

    A properly choosen 25 byte string is impossible to guess I'd say. A brute force attack won't work very well with binkd either. So I don't think that part of binkd can be considered "weak".

    I doubt that that added value is "worth it" in fidonet, where many
    people used ancient software, and only a small minority is interested
    to roll out new features.

    Frankly I see no significant added value at this point. It just adds overhead...

    Binkp's CRYPT protects against unauthorised listeners on the
    channel. I am not aware of binkp's security being compromised.

    I am also not aware of it. But you have to admit that security
    researchers have more prestigeous targets then binkd crypt. (So I
    assume that it was never really challenged and analyzed.)

    Yes, there is that. It was probably never really challenged.

    Breaking TLS gains you lots of $$$, so many people try it. (without
    any knowledge of then being successful.)

    I suspect it is already boken by government agencies. Those are the ones that have the resources...

    Plus that I still wonder what we are protecting against whom. Do
    we really need 10 cm armour and triple locks to protect Fidonet
    content?

    Why not? ;)
    Using binkp in a stunnel definitely will not weaken the security.

    Not if you do it right. If you do it wrong....

    (eg. if you break the stunnel, you still are left with the same binkp stream that you would have had previously.) And adding a TLS option
    for clients that support it, will not be weaker than our existing
    crypt implementation.

    Unless you use TLS not in addition to but instead of binkp session password and CRYPT.

    So it is doable, and would benefit security from my point of view.
    But I do not think many people would use it.

    Like I said before, I may give it a try just for the sake of the technical challenge. I don't consider the added security of such magnitude that I'd start using it large scale..

    The easiest target would be to have a second port where you can make stunnel connections. (this is not very practicable from my point of
    view, outside of PoC) Or the second easiest but more useable target
    would be to implement starttls and use it if both parties support it. (relying on passwords, not client certificates)

    The Synchronet fans do not seem to like starttls, they want a diffrent port. So we alreay have two competing standards...


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Tommi Koivula@2:221/360 to Michiel van der Vlist on Tue Dec 17 17:37:09 2019

    download my public key from my website: www.vlist.eu/pubkey.

    Not Found

    KFWebServer/2.5.0 Windows XP at http://www.vlist.eu Port 80

    --- Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
    * Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)
  • From Rob Swindell@1:103/705 to Richard Menedetter on Tue Dec 17 12:21:32 2019
    Re: Binkd and TLS
    By: Richard Menedetter to Michiel van der Vlist on Tue Dec 17 2019 02:31 pm

    Binkp's CRYPT protects against unauthorised listeners on the channel.
    I am not aware of binkp's security being compromised.

    I am also not aware of it.

    Binkd's CRYPT option uses the PKZIP method of encryption which in considered "weak" when compared to modern methods: https://crypto.stackexchange.com/questions/72910/how-safe-can-pkzip-compatible- encryption-be

    digital man

    Synchronet/BBS Terminology Definition #22:
    DSL = Digital Subscriber Line
    Norco, CA WX: 62.2F, 16.0% humidity, 5 mph W wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.10-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Ward Dossche@2:292/854 to Rob Swindell on Tue Dec 17 22:19:32 2019
    Synchronet/BBS Terminology Definition #22:
    DSL = Digital Subscriber Line

    DSL stands for "Deep Scattering Layer". It is a thin horizontal zone of living organisms in the ocean located in the water column. This layer appears to rise in the evening and to descend in the morning. It is named this way because it has the property to reflect sound waves, same as the seabed.

    In technical language this layer therefore is also refered to as "false bottom".

    \%/@rd

    --- D'Bridge 3.99
    * Origin: Do not meddle in the affairs of wizards (2:292/854)
  • From Rob Swindell@1:103/705 to Ward Dossche on Tue Dec 17 13:38:11 2019
    Re: Re: Binkd and TLS
    By: Ward Dossche to Rob Swindell on Tue Dec 17 2019 10:19 pm

    Synchronet/BBS Terminology Definition #22:
    DSL = Digital Subscriber Line

    DSL stands for "Deep Scattering Layer". It is a thin horizontal zone of living organisms in the ocean located in the water column. This layer appears to rise in the evening and to descend in the morning. It is named this way because it has the property to reflect sound waves, same as the seabed.

    In technical language this layer therefore is also refered to as "false bottom".

    Neat!

    digital man

    This Is Spinal Tap quote #18:
    Sustain, listen to it. Don't hear anything. You would though were it playing. Norco, CA WX: 62.5F, 17.0% humidity, 1 mph NNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.10-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Alan Ianson@1:153/757 to Michiel van der Vlist on Tue Dec 17 14:32:48 2019
    Hello Michiel,

    We are not trying to fix problems. We are trying to be secure.

    "Secure" is meaningless without specifying against WHAT. What threats
    are we securing against?

    Any and all.

    In what way is TLS "better"? A claim of "better" security has to
    be more specific than just that. Better than what? Better
    against what threats and by whom?

    I wish I could answer that question. I am no expert on protocols or security.

    I believe that TLS is an open standard, largely accepted as a secure mechanism for internet transport today.

    I know that you want the facts (and that's a good thing) but I can't give you more than I already have.

    That does not make it better for use in Fidonet. Fidonet is not the InterNet, it just makes use of it.

    There are very few dial-up nodes today. The vast majority of traffic today is carried over the internet. That is unavoidable unless we go back to dial-up and I don't think that is going to happen.

    and I would like to be secure.

    You keep saying that,

    Yes, it is nothing more than that.

    In order to move forward, one first has to know which direction
    matches "forward".

    The TLS option is a very secure one.

    Maybe I said that wrong. How about this. Binkd's CRYPT option is
    weak (by todays standards).

    In what way is it weak? Has it been cracked?

    Yes, many years ago.

    Maybe we should think about using something more up to date, like
    TLS.

    "More up to date" is not better by definition. With governments that
    keep pushing for backdoors in encryption, "someting more up to date"
    may actually be a step back.

    TLS has been developed in the open so no backdoors there.

    I would be happy to answer any questions you have, if I could. I'm sure there are matter of fact answers to all your questions, but I don't know what they are.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Rob Swindell@1:103/705 to Michiel van der Vlist on Tue Dec 17 15:11:07 2019
    Re: Binkd and TLS
    By: Michiel van der Vlist to Richard Menedetter on Tue Dec 17 2019 04:10 pm

    The Synchronet fans do not seem to like starttls, they want a diffrent
    port.

    The people-in-the-know don't like starttls: https://serverfault.com/questions/523804/is-starttls-less-safe-than-tls-ssl

    So we alreay have two competing standards...

    Are you refering to Binkd's CRYPT option as one of those standards? Not to pick a nit, but it's not actually a standard. It's not even a proposed standard:
    http://ftsc.org/docs/fsp-1024.000

    I could also argue that BinkP over TLS (binkps) is an implicitly defined standard since the TCP application protocol (binkp) is already a defined standard:
    http://ftsc.org/docs/fts-1026.001

    If you take an existing clear-text TCP application protocol (e.g. telnet) and simply define a new TCP port to be used for the implicit TLS transport of a secure implementation of that same protocol (e.g. telnets) - you don't actually need a new protocol definition (e.g. RFC) for the secure protocol to be a "standard". The same is true of binkps.

    digital man

    Synchronet "Real Fact" #77:
    Rob Swindell still has dozens of BBS-related magazines in his possession. Norco, CA WX: 61.5F, 16.0% humidity, 6 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.10-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Fabio Bizzi@2:335/364.1 to Ward Dossche on Wed Dec 18 08:03:48 2019
    Hello Ward!

    17 Dec 19 22:19, you wrote to Rob Swindell:

    Synchronet/BBS Terminology Definition #22:
    DSL = Digital Subscriber Line

    DSL stands for "Deep Scattering Layer". It is a thin horizontal zone
    of living organisms in the ocean located in the water column. This
    layer appears to rise in the evening and to descend in the morning. It
    is named this way because it has the property to reflect sound waves,
    same as the seabed.

    In technical language this layer therefore is also refered to as
    "false bottom".

    DSL = Damn Small Linux, a "really" tiny linux distribution. http://www.damnsmalllinux.org/

    :P

    Ciao!
    Fabio

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: ]\/[imac Rebirth Boss Point (2:335/364.1)
  • From Richard Menedetter@2:310/31 to Michiel van der Vlist on Wed Dec 18 09:38:24 2019
    Hi Michiel!

    17 Dec 2019 16:10, from Michiel van der Vlist -> Richard Menedetter:

    There is potential value. (eg. passwords can be very easy to
    guess ... toor, passw0rd, ...)
    That is not a shortcoming of the protocol, it is a shortcoming of the user.

    But the protocol allows it.
    With client certificates that problem does not exist.
    (but others do ;))

    client certificates are much more secure than eg. 8 digit
    passwords.
    Binkd session passwords are not limited to 8 characters.

    I know.
    But many passwords are 8 characters.
    That is why I put the eg. there.

    A properly choosen 25 byte string is impossible to guess I'd say.
    A brute force attack won't work very well with binkd either. So I
    don't think that part of binkd can be considered "weak".

    If you are using a good password, then yes.

    I doubt that that added value is "worth it" in fidonet, where
    many people used ancient software, and only a small minority is
    interested to roll out new features.
    Frankly I see no significant added value at this point. It just adds overhead...

    I have the gut feeling that proper implemented TLS is much more secure against crypto analysis then the current crypt implementation.
    And no, it is just a gut feeling, I cannot provide a link to a paper.

    Breaking TLS gains you lots of $$$, so many people try it.
    (without any knowledge of then being successful.)
    I suspect it is already boken by government agencies.
    Those are the ones that have the resources...

    Pre Snowden it was not broken.
    As long as there is no quantum attack ongoing I believe it to be quite secure currently.
    On the other hand the number of stable QBits in publicly known quantum computers is increasing rapidly.
    If a government has much more advanced quantum computers, then it is absolutely possible that those codes can be broken.

    (eg. if you break the stunnel, you still are left with the same
    binkp stream that you would have had previously.) And adding a
    TLS option for clients that support it, will not be weaker than
    our existing crypt implementation.
    Unless you use TLS not in addition to but instead of binkp session password and CRYPT.

    That was the usecase of just slap a stunnel before the whole thing.
    I think nobody seriously thought about replacing passwords.

    The easiest target would be to have a second port where you can
    make stunnel connections. (this is not very practicable from my
    point of view, outside of PoC) Or the second easiest but more
    useable target would be to implement starttls and use it if both
    parties support it. (relying on passwords, not client
    certificates)
    The Synchronet fans do not seem to like starttls, they want a diffrent port. So we alreay have two competing standards...

    (Nearly) nobody will use it with a different port.

    The only way to gain any traction is to implement it transparently, and if both partners implement the extension, then TLS will be used, otherwise you fallback to the current method.

    My 2 cents.

    CU, Ricsi

    ... Do what comes naturally now. Seethe and fume and throw a tantrum.
    --- GoldED+/LNX
    * Origin: A little enthusiasm never hurt anybody... (2:310/31)
  • From Richard Menedetter@2:310/31 to Rob Swindell on Wed Dec 18 09:53:42 2019
    Hi Rob!

    17 Dec 2019 15:11, from Rob Swindell -> Michiel van der Vlist:

    The Synchronet fans do not seem to like starttls, they want a
    diffrent port.
    The people-in-the-know don't like starttls: https://serverfault.com/questions/523804/is-starttls-less-safe-than-tl s-ssl

    There was a discussion recently here, where it was stated that those discussions are focused around mail.
    So is your link.

    Alexey posted a link about this (including a link ... sadly I am too busy currently to deep dive on this).

    And generally talking about "the people in the know" is a bit very generalized ;)
    Some people knowledgable do not like it.

    CU, Ricsi

    ... Eating words has never given me indigestion. -Winston Churchill
    --- GoldED+/LNX
    * Origin: Actions are usually right, but the reasons are not. (2:310/31)
  • From Alexey Fayans@2:5030/1997 to Rob Swindell on Wed Dec 18 13:23:02 2019
    Hello Rob!

    On Tue, 17 Dec 2019 at 15:11 -0800, you wrote to Michiel van der Vlist:

    The people-in-the-know don't like starttls: https://serverfault.com/questions/523804/is-starttls-less-safe-than-tl s-ssl

    If you read this carefully, you will see that all flaws are optional. Yes, protocol allows to continue in plain text if TLS negotiation failed, but not required. Seurity is not about how strictly a protocol is designed. It's about implementation.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Michiel van der Vlist@2:280/5555 to Tommi Koivula on Wed Dec 18 13:07:34 2019
    Hello Tommi,

    On Tuesday December 17 2019 17:37, you wrote to me:

    download my public key from my website: www.vlist.eu/pubkey.

    Not Found

    Oops typo:

    www.vlist.eu/pubkeys


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Rob Swindell@1:103/705 to Richard Menedetter on Wed Dec 18 20:57:46 2019
    Re: Binkd and TLS
    By: Richard Menedetter to Rob Swindell on Wed Dec 18 2019 09:53 am

    Hi Rob!

    17 Dec 2019 15:11, from Rob Swindell -> Michiel van der Vlist:

    The Synchronet fans do not seem to like starttls, they want a
    diffrent port.
    The people-in-the-know don't like starttls: https://serverfault.com/questions/523804/is-starttls-less-safe-than-tl s-ssl

    There was a discussion recently here, where it was stated that those discussions are focused around mail.
    So is your link.

    And BinkP is used for transporting... mail. But that's really irrelevant. Whatever the data is that you want to be kept private, Implicit TLS is superior to Oportunistic / Explicit TLS (e.g. STARTTLS).

    Alexey posted a link about this (including a link ... sadly I am too busy currently to deep dive on this).

    And generally talking about "the people in the know" is a bit very generalized ;)
    Some people knowledgable do not like it.

    Knowledge about what? Security experts don't like STARTTLS. BinkP implementers don't like STARTTLS. That's the people that matter.

    digital man

    Synchronet/BBS Terminology Definition #73:
    TCP = Transmission Control Protocol
    Norco, CA WX: 48.4F, 42.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.10-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Michiel van der Vlist@2:280/5555 to Richard Menedetter on Thu Dec 19 22:41:49 2019
    Hello Richard,

    On Wednesday December 18 2019 09:38, you wrote to me:

    That is not a shortcoming of the protocol, it is a shortcoming of
    the user.

    But the protocol allows it.

    Binkd is for use by sysops. Sysops are supposed to have more knowledge of these things than Otto Normalverbraucher.

    With client certificates that problem does not exist.
    (but others do ;))

    Indeed, there are other problems with certificates. such as "how do we know we can trust the CA?"

    client certificates are much more secure than eg. 8 digit
    passwords.

    Binkd session passwords are not limited to 8 characters.

    I know.

    So what is stopping someone from using a much longer password of one feels eight is not enough?

    But many passwords are 8 characters.

    Indeed, some passwords in use in Fidonet are limited to 8 characters. That does not make ALL passwords in Fidonet "weak".

    That is why I put the eg. there.

    A properly choosen 25 byte string is impossible to guess I'd say.
    A brute force attack won't work very well with binkd either. So I
    don't think that part of binkd can be considered "weak".

    If you are using a good password, then yes.

    So I see no problem.

    I doubt that that added value is "worth it" in fidonet, where
    many people used ancient software, and only a small minority is
    interested to roll out new features.

    Don't fix it if it ain't broke...

    Frankly I see no significant added value at this point. It just
    adds overhead...

    I have the gut feeling that proper implemented TLS is much more secure against crypto analysis then the current crypt implementation. And no,
    it is just a gut feeling, I cannot provide a link to a paper.

    Possibly. Probabably even. My filosofy on this is that the level of protection should match te nature of the threat. "More" sounds nice, but I am not a fan of the "more is better club". I can protect my toilet with 10 cm armour and triple locks against unauthorised use, but that would just make things harder fo myself. Unauthorised use is not a great theat.

    Breaking TLS gains you lots of $$$, so many people try it.
    (without any knowledge of then being successful.)

    I suspect it is already boken by government agencies.
    Those are the ones that have the resources...

    Pre Snowden it was not broken.

    1) Snowdon does not know everything.

    2) That was how many years ago?

    Plus that ever so often security is not broken because of a weakness in the algoritm but because of other things. One of the problems with certificats issued by a "trusted authority" is "can I really trust the authority?. Letsencrypt is located in the US. Are they up against a governement that has been proven to install spyware in routers? How about the Patriot Act?

    I very much prefer the block chain like mechanisme of PGP than a US based "trusted authority" ...

    As long as there is no quantum attack ongoing I believe it to be quite secure currently. On the other hand the number of stable QBits in
    publicly known quantum computers is increasing rapidly. If a
    government has much more advanced quantum computers, then it is
    absolutely possible that those codes can be broken.

    In the end only quantum encryption based on quantum entanglement wil be unbreakable. But I do not know if I will live to see that...

    (eg. if you break the stunnel, you still are left with the same
    binkp stream that you would have had previously.) And adding a
    TLS option for clients that support it, will not be weaker than
    our existing crypt implementation.

    Unless you use TLS not in addition to but instead of binkp
    session password and CRYPT.

    That was the usecase of just slap a stunnel before the whole thing.
    I think nobody seriously thought about replacing passwords.

    Are you sure? Binkd session passwords require a pre arranged password with every node that one wants a secure link. TLS only requires each node to have a certificate signed by a trusted authority. Just ONE certificate per node to make secure links between ever pair of nodes. I would say that if this gets widely used, one could easely drop the effort of arraging session password with all others. Thinking TLS it is just as safe without the binkp session password...

    The easiest target would be to have a second port where you can
    make stunnel connections. (this is not very practicable from my
    point of view, outside of PoC) Or the second easiest but more
    useable target would be to implement starttls and use it if both
    parties support it.

    I have not made up my mind yet...

    (relying on passwords, not client certificates)

    Yep.

    The Synchronet fans do not seem to like starttls, they want a
    diffrent port. So we alreay have two competing standards...

    (Nearly) nobody will use it with a different port.

    Perhaps. It seems cumbesome.

    The only way to gain any traction is to implement it transparently,
    and if both partners implement the extension, then TLS will be used, otherwise you fallback to the current method.

    Even then. If it is not integrated in binkd I don't give it much of a chance.

    My 2 cents.

    My EU 0.02 also.



    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Alan Ianson on Sat Dec 21 12:34:39 2019
    Hello Alan,

    On Tuesday December 17 2019 14:32, you wrote to me:

    "Secure" is meaningless without specifying against WHAT. What
    threats are we securing against?

    Any and all.

    That is not a realistic goal. One can not effectively defend if one has no idea about who or what is the threat.

    I believe that TLS is an open standard, largely accepted as a secure mechanism for internet transport today.

    That does not mean it is good or not good for the specific needs of Fidonet.

    That does not make it better for use in Fidonet. Fidonet is not
    the InterNet, it just makes use of it.

    There are very few dial-up nodes today. The vast majority of traffic
    today is carried over the internet. That is unavoidable unless we go
    back to dial-up and I don't think that is going to happen.

    Sure POTS is on the way out. Fidonet uses the Internet as the main means of transport. So?

    and I would like to be secure.

    You keep saying that,

    Yes, it is nothing more than that.

    Secure without knowledge of the threat is no security.

    In order to move forward, one first has to know which direction
    matches "forward".

    The TLS option is a very secure one.

    There is no such thing as universal security. I have reason to trust the electronic key that protects my car against theft. It does not protect against a thief breaking into my house to steal the key. It also does not protect against a thief with a row truck.

    Maybe I said that wrong. How about this. Binkd's CRYPT option is
    weak (by todays standards).

    In what way is it weak? Has it been cracked?

    Yes, many years ago.

    In the context of Fidonet or in the context of PkZip?

    Maybe we should think about using something more up to date,
    like TLS.

    "More up to date" is not better by definition. With governments
    that keep pushing for backdoors in encryption, "someting more up
    to date" may actually be a step back.

    TLS has been developed in the open so no backdoors there.

    1) Open source is no absolute guarantee against backdoors or other weaknesses.

    2) The weakness need not be in the protocol itself, it could be in the way that it is used. Thje weakness in my car key is how ell I guard the key. If the key falls in the wrong hands, it is useless for potection. TLS depends on the integrity of the authority signing the certificates. If the authority is compromised, so are the certificates and the security of TLS.This has alreaduy happened with the Diginotar CA.

    The main threat in Fidonet has been a malicious sysop masquarading a trusted party to gain access to the secure inbound. A properly configured Fidonet system has the secure inbound protected by a session password. Session passwords ended the mail bomb. Binkp does not exchange the passwords in clear text. Plus that there ar packet passwords. TTBOMK this mechanism has been effective in protecting the secure inbound.

    Please note that the normal implementation of TLS (cerificate for the server only) does not protect against the main threat of Fidonet: someone masquarading as a trusted party to gain access to the secure inbound.

    Nr 2 on the list of threats in Fidonet is snooping on routed netmail. TLS does not protect against that either. You need end to end encryption on the message level for that.

    So what does TLS in Fidonet protect against? Someone snooping on the stream? I say there is no protection against a sufficiently motivated agency with "infinite" resources. Such as a government. And for the rest it does not matter. There is no financial gain to be expected by snooping on Fidonet. For 99% it is an exercise in futility anyway. 99% of the traffic in Fidonet is echomail.

    Sorry, I see TLS in Fidonet as shooting on a musquito with a canon.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Alan Ianson@1:153/757 to Michiel van der Vlist on Sat Dec 21 14:00:48 2019
    Hello Michiel,

    That does not make it better for use in Fidonet. Fidonet is not
    the InterNet, it just makes use of it.

    There are very few dial-up nodes today. The vast majority of
    traffic today is carried over the internet. That is unavoidable
    unless we go back to dial-up and I don't think that is going to
    happen.

    Sure POTS is on the way out. Fidonet uses the Internet as the main
    means of transport. So?

    My comment is simply a comment on your comment.

    Binkd is and always has been a TCP/IP mailer. Fidonet is not the internet but we are listening and talking over the internet.

    The TLS option is a very secure one.

    There is no such thing as universal security. I have reason to trust
    the electronic key that protects my car against theft. It does not
    protect against a thief breaking into my house to steal the key. It
    also does not protect against a thief with a row truck.

    There are different approaches to security. You just need one that works for you. I also have an onion address that I do/can use over the internet. It is also very secure and fairly simple to impliment. I don't like that solution and I don't think others would either so I am looking for something simple and secure that isn't hard for nodes to implement.

    Maybe I said that wrong. How about this. Binkd's CRYPT option
    is weak (by todays standards).

    In what way is it weak? Has it been cracked?

    Yes, many years ago.

    In the context of Fidonet or in the context of PkZip?

    That algorithm. The same is true of the algorithm used by rar. The folks behind the rar archiver may has changed the algrithm they use today, I don't know.

    Maybe we should think about using something more up to date,
    like TLS.

    "More up to date" is not better by definition. With governments
    that keep pushing for backdoors in encryption, "someting more up
    to date" may actually be a step back.

    I still think the TLS option would serve us well.

    TLS has been developed in the open so no backdoors there.

    1) Open source is no absolute guarantee against backdoors or other weaknesses.

    Open source is free and available to everyone, including the source.

    I think TLS is a good option but it's not the only one. We could come up with a new protocol that does what we want/need it to do. Someone would need to do and maintain that. If someone did that I would support their efforts.

    TLS was designed for this purpose. With TLS already on the table I don't think anyone will do that.

    Sorry, I see TLS in Fidonet as shooting on a musquito with a canon.

    Too much of a good thing?

    I think TLS is a good way forward. It has already been implemented in BinkIT and to some degree in Mystic. If binkd had support for it also these mailer could communicate securely.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Michiel van der Vlist@2:280/5555 to Alan Ianson on Sun Dec 22 10:18:24 2019
    Hello Alan,

    On Saturday December 21 2019 14:00, you wrote to me:

    Maybe I said that wrong. How about this. Binkd's CRYPT option
    is weak (by todays standards).

    In what way is it weak? Has it been cracked?

    Yes, many years ago.

    In the context of Fidonet or in the context of PkZip?

    That algorithm. The same is true of the algorithm used by rar. The
    folks behind the rar archiver may has changed the algrithm they use
    today, I don't know.

    Is there a documented case of someone successfully gaining unauthorised access to the secure inbound of a Fidenet node by breaking the algoritm and doing any harm that way?

    Is there a documented case of anyone listening in on the stream by breaking the algoritm and causing any harm that way?

    I still think the TLS option would serve us well.

    I say for Fidonet it is shooting a canon at a musquito.

    Too much of a good thing?

    Too much hassle for the added value.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Alan Ianson@1:153/757 to Michiel van der Vlist on Sun Dec 22 13:45:18 2019
    Is there a documented case of someone successfully gaining
    unauthorised access to the secure inbound of a Fidenet node by
    breaking the algoritm and doing any harm that way?

    Is there a documented case of anyone listening in on the stream by breaking the algoritm and causing any harm that way?

    I have no such documents and I hope I never will. You are not under
    threat from me or any fido operator TTBOMK. We all have port 24554 (or
    others) open on our computers. I think it would be prudent to simply
    lock that door.

    I still think the TLS option would serve us well.

    I say for Fidonet it is shooting a canon at a musquito.

    TLS is a big weapon.

    TLS is transport layer security, a cryptographic protocol designed to
    provide communications security over a computer network. The TLS
    protocol aims primarily to provide privacy and data integrity between
    two or more communicating computer applications.

    The above is largely a cut 'n' paste from wikipedia but is sums up my
    reasons for suggesting it.

    Too much of a good thing?

    Too much hassle for the added value.

    If you are happy with what you have nothing further is required.

    TLS has been developed by many people over many years and continues to
    be developed. It is provided by the OS at no cost for use cases like
    this. We can simply implement it in binkd if we choose to do so.

    It's possible we could design, implement and maintain our own protocol
    for this purpose. I'm not sure if anyone is with us today with the
    skills, know how and time to devote to that, but I would support that
    option as well.


    --- MagickaBBS v0.13alpha (Linux/x86_64)
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)