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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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.2øF, 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)

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)

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.5øF, 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)

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)

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.5øF, 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)

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)

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)

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)

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)

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)

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.4øF, 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)

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)

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)

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)

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)

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)