Hello Oli,

You were saying in another area something about using binkp over TLS. Is it possible to do that now?

I'm going to hang on for a day or three and see if Alexey has anything to say about secure binkp and then I'll likely netmail him and see what (if anything) he has to say about it.

In the mean time though, I don't mind just messing with it and see what can be done around all that.

Ttyl :-),
Al

--- GoldED+/LNX 1.1.5-b20180707
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

"Al -> Oli" <[email protected]> wrote:

You were saying in another area something about using binkp over TLS.
Is it possible to do that now?

With binkd it is.

I'm going to hang on for a day or three and see if Alexey has
anything to say about secure binkp and then I'll likely netmail him
and see what (if anything) he has to say about it.

In the mean time though, I don't mind just messing with it and see
what can be done around all that.

The easiest way is to install stunnel and ncat. You have to create a self-signed certificate (or use the one from letsencrypt) and configure stunnel. Just take an example for https, smtps, imaps or pop3s and change the ports.

and then use -pipe and ncat in the node line:

node 5:4/3@fidonet -pipe "ncat --ssl-alpn binkp *H *I" hostname:24553 -
or
node 5:4/3@fidonet -pipe "ncat --ssl hostname 24553"

---
* Origin: (21:1/151)

On Sat, 23 Nov 2019 11:11:42 -0800
"Al -> Oli" <[email protected]> wrote:

You were saying in another area something about using binkp over TLS.
Is it possible to do that now?

You could use my node to test outgoing binkp TLS connections. My node might be offline at times, so first two ways of testing connectivity from the command line:

openssl s_client -alpn binkp -connect binkps-test.uk.to:443

ncat --ssl --ssl-alpn binkp binkps-test.uk.to 443

You also can use either of the two programs with binkd:

node 21:1/151@fsxnet -pipe "ncat --ssl-alpn binkp *H *I" binkps-test:443
node 21:1/151@fsxnet -pipe "openssl s_client -quiet -alpn binkp -connect *H:*I"
binkps-test:443

---
* Origin: (21:1/151)

"Al -> Oli" <[email protected]> wrote:

I'm going to hang on for a day or three and see if Alexey has
anything to say about secure binkp and then I'll likely netmail him
and see what (if anything) he has to say about it.

Alexey answered to your echomail. I'm still not sure what he meant with secure binkp. Is it the CRYPT extension? It's not really "totally new technology", but
never published by the FTSC. Or is there a new protocol in development?

Quote from FTSC_PUBLIC:

I was thinking about this and the posibility of a standard so
different mailers could use secure binkp.

JFYI: binkd already has this capability.

Alexey said something about secure binkp that made me curious.

Yes. We needed a method for safe and secure peer-to-peer file distribution:
0. Looking like a completely different protocol.
1. Immune to DPI (twice a fuck to Roscompozor).
2. Almost impossible to ban
(18446744073709551616 more fucks to Roscompozor).
3. Capable of connection multiplexing on a single host:port pair.

End Quote

Anyway, my understanding is that there is no more secure and simple alternative
to CRYPT in the making.

---
* Origin: (21:1/151)

You were saying in another area something about using binkp
over TLS. Is it possible to do that now?

With binkd it is.

OK, I'll have a go at this once I get the pieces together.

The easiest way is to install stunnel and ncat. You have to create
a self-signed certificate (or use the one from letsencrypt) and
configure stunnel. Just take an example for https, smtps, imaps or
pop3s and change the ports.

and then use -pipe and ncat in the node line:

node 5:4/3@fidonet -pipe "ncat --ssl-alpn binkp *H *I"
hostname:24553 - or
node 5:4/3@fidonet -pipe "ncat --ssl hostname 24553"

This can be used to connect securely to a binkd mailer listening
securely?

It'll take me a bit. I have a few minutes here and a few minutes there
before I need to be on my way but I'll get there.. :)

Ttyl :-),
Al

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

You were saying in another area something about using binkp
over TLS. Is it possible to do that now?

You could use my node to test outgoing binkp TLS connections. My
node might be offline at times, so first two ways of testing
connectivity from the command line:

OK, I'll save a couple of these messages to a file and see what I can do.

Ttyl :-),
Al

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

I'm going to hang on for a day or three and see if Alexey has
anything to say about secure binkp and then I'll likely netmail
him and see what (if anything) he has to say about it.

Alexey answered to your echomail. I'm still not sure what he meant
with secure binkp. Is it the CRYPT extension? It's not really
"totally new technology", but never published by the FTSC. Or is
there a new protocol in development?

I think the CRYPT extention has done what it can do. Is that more or less
the algo that PKZIP/PKUNZIP used to password protect a file?

Sounds like Alexey is thinking on a new protocol. Maybe we'll end up with
a binkd mailer that supports binkp as it is and another protocol for
secure binkp, possibly binkps.

I'm only guessing.

He made it sound like TLS was not a solution, and insecure?

I didn't quite follow what he said there.

Ttyl :-),
Al

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

Re: RE: Secure binkp
By: Al to Oli on Sun Nov 24 2019 02:25 pm

Sounds like Alexey is thinking on a new protocol. Maybe we'll end up with a binkd mailer that supports binkp as it is and another protocol for secure binkp, possibly binkps.

This makes sense to me - it should be binkps. It probably would need a new nodelist flag and parseing, since IBN is for binkp.

He made it sound like TLS was not a solution, and insecure?

From what I understand (and I havent thought this through, nor am I an expert in this area) - but if you connect on a non secure channel and the server says "lets go encrypted" and the client says "not today", then you are no more secure.

Further, if the client does say "going secure: code is ABC", that code is sent in the clear, so anybody can see the code on the wire and use the code. I think
that's the crux of it?

Thinking it through further the "Code is ABC" needs to be linked to something external (time?) so that it's not always "ABC" - but the server recalculates the code that the client sends and comes to the same answer. Maybe TLS cannot do it this way...

Now I'm rambling... :(
...δεσπ

... It would be illogical to assume that all conditions remain stable.
--- SBBSecho 3.10-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

"Al -> Oli" <[email protected]> wrote:

node 5:4/3@fidonet -pipe "ncat --ssl-alpn binkp *H *I"
hostname:24553 - or
node 5:4/3@fidonet -pipe "ncat --ssl hostname 24553"

This can be used to connect securely to a binkd mailer listening
securely?

Yes. That can be used to connect too any binkp mailer that is behind a TLS proxy (or has built-in support for direct TLS). We need to test it though. I haven't found any problems, but I only used it in a test environment.

---
* Origin: (21:1/151)

On Sun, 24 Nov 2019 14:25:50 -0800
"Al -> Oli" <[email protected]> wrote:

He made it sound like TLS was not a solution, and insecure?

I didn't quite follow what he said there.

If I understand it correctly Alexey claims that TLS was weakened on request by some three letter agency. Of course algorithms with known backdoors were proposed by someone at some time and the financial industry tried to weaken the
TLS 1.3 specification [1]. We also know that there are a number of vulnerabilities in TLS 1.2 and earlier versions.

On the one hand we have TLS 1.3 developed openly over years by the key players in the industry and experts from the crypto community. On the other hand we have the statement from Alexey about something something insecure without pointing to any specific vulnerability.

There is a lot to criticize about Google, Mozilla and Cloudflare, but when it comes to encryption I think they are doing a pretty good job. The Snowden leaks
were a wake-up call and many were pissed and angry. Since then there is a clear determination to encrypt everything as secure as possible. If new vulnerabilities are discovered, they will be fixed ...

Maybe someone will implement a good alternative to TLS for binkp or a completely new protocol, but I haven't seen any announcement. Until then TLS (1.3) could provide strong encryption and is easy to add (the other alternative
is encryption at the transport layer, like VPN, Tor, i2p, IPsec, ...)


[1] https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-shouldnt-use-it

---
* Origin: (21:1/151)

On the one hand we have TLS 1.3 developed openly over years by the
key players in the industry and experts from the crypto community.
On the other hand we have the statement from Alexey about something something insecure without pointing to any specific vulnerability.

Yes, I found that statement to be questionable, although when he said
that I have to look at that too.

There is a lot to criticize about Google, Mozilla and Cloudflare,
but when it comes to encryption I think they are doing a pretty
good job. The Snowden leaks were a wake-up call and many were
pissed and angry. Since then there is a clear determination to
encrypt everything as secure as possible. If new vulnerabilities
are discovered, they will be fixed ...

My understanding is that TLS 1.3 is secure and a good way to proceed.

Maybe someone will implement a good alternative to TLS for binkp or
a completely new protocol, but I haven't seen any announcement.
Until then TLS (1.3) could provide strong encryption and is easy to
add (the other alternative is encryption at the transport layer,
like VPN, Tor, i2p, IPsec, ...)

I don't know much about these alternate transport methods. My only
presence on the web is my BBSs web site.

I have heard IPsec but don't know what that is. Something to do with
IPv6? If connected via IPv6 do I have IPsec enabled or do I need to take
extra steps for that, and does it negate the need for other security like
TLS?

Ttyl :-),
Al

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

On Mon, 25 Nov 2019 14:13:52 -0800
"Al -> Oli" <[email protected]> wrote:

My understanding is that TLS 1.3 is secure and a good way to proceed.

Maybe someone will implement a good alternative to TLS for
binkp or a completely new protocol, but I haven't seen any
announcement. Until then TLS (1.3) could provide strong
encryption and is easy to add (the other alternative is
encryption at the transport layer, like VPN, Tor, i2p,
IPsec, ...)

I don't know much about these alternate transport methods. My only
presence on the web is my BBSs web site.

I have heard IPsec but don't know what that is. Something to do with
IPv6? If connected via IPv6 do I have IPsec enabled or do I need to
take extra steps for that, and does it negate the need for other
security like TLS?

I just included some buzzwords and you picked the one I know the least about :). IPsec is way to complicated for normal human beans like us to understand. IPsec is encrypting on the IP level (network layer). If the traffic on the network itself is already encrypted, applications don't have to do the encryption. I think that was the basic idea. Maybe we should just ignore that I
mentioned IPsec, but if your really want to know more, here are some infos: https://www.freeswan.org/freeswan_snaps/CURRENT-SNAP/doc/ipsec.html https://www.comparitech.com/blog/information-security/ipsec-encryption/

What I forgot to mention is that QUIC will be the next big thing / encrypted protocol (HTTP/3 is based on it).

Can someone read this and explain it to us in a few words? ;) https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/

---
* Origin: (21:1/151)

On Monday, November 25th Al was heard saying...

My understanding is that TLS 1.3 is secure and a good way to proceed.

I don't mean to butt in, but the TLS 1.3 protocol is certainly secure. Ensure you choose secure & modern suite(s). For example: TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

AES has the benefit of using AES-NI instructions on modern CPUs. Without these instructions it can be up 30x slower and much more CPU intensive. If you're running on very old hardware, some of this becomes almost a no-go as it's just too intensive.

TLS is for PKI, which might make sense for a network op who could perhaps but the Certificate Authority (CA), but I can see that quickly becoming an issue when someone loses their private key/etc.

A end-to-end encryption system might be better if you're considering from scratch (but of course OpenSSL and such make TLS much easier to implement).




--

NuSkooler
Xibalba BBS @ xibalba.l33t.codes / 44510(telnet) 44511(ssh)
ENiGMA 1/2 BBS WHQ | Phenom | 67 | iMPURE | ACiDic

--- ENiGMA 1/2 v0.0.11-beta (linux; x64; 12.13.1)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)

What I forgot to mention is that QUIC will be the next big thing / encrypted protocol (HTTP/3 is based on it).

Thunk!

Ttyl :-),
Al

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

I don't mean to butt in, but the TLS 1.3 protocol is certainly
secure. Ensure you choose secure & modern suite(s). For example: TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305 _SHA256

Your not butting in at all, and if you are you are welcome too.. :)

We are really just passing around ideas about doing binkp over TLS or
other secure methods.

It's likely not important to many but I would like my binkp transfers to
be as secure as a session on a web site, or as secure as they can be.
Even my BBS sessions for the most part these days are over ssh.

Ttyl :-),
Al

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

On 25 Nov 2019 at 11:55p, Al pondered and said...

Your not butting in at all, and if you are you are welcome too.. :)

I second, even third this :)

--- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On Mon, 25 Nov 2019 19:49:35 -0700
"NuSkooler -> Al" <[email protected]> wrote:

On Monday, November 25th Al was heard saying...

My understanding is that TLS 1.3 is secure and a good way to
proceed.

I don't mean to butt in, but the TLS 1.3 protocol is certainly
secure. Ensure you choose secure & modern suite(s). For example: TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Is it possible to choose insecure ciphersuites with TLS 1.3?

AES has the benefit of using AES-NI instructions on modern CPUs.
Without these instructions it can be up 30x slower and much more CPU intensive. If you're running on very old hardware, some of this
becomes almost a no-go as it's just too intensive.

ChaCha20-Poly1305 is faster, if there is no support for AES in the CPU.

But how important is the support for _very_ old hardware? Is anyone still developing Fidonet software for these computers, especially a binkp mailer? Does binkp still compile for Amiga 68k? Is it possbile to use any secure encryption (by todays standards) on these machines?

There are two options:
1) You just run your old software with no or weak encryption as all the other nodes do today.
2) You do the encryption on another device.

Tor, i2p or other overlay networks would work for 2). It's also possible to write some kind of TLS proxy for outgoing connections.

And maybe
3) use a secure encryption algorithm that works on very slow computers. Not sure if something like this exist.

TLS is for PKI, which might make sense for a network op who could
perhaps but the Certificate Authority (CA), but I can see that
quickly becoming an issue when someone loses their private key/etc.

I would like to avoid this. This would open another can of worms.

A end-to-end encryption system might be better if you're considering
from scratch (but of course OpenSSL and such make TLS much easier to implement).

What do you mean with e2e encryption in this context? e2e on the network level or on the message level?

---
* Origin: (21:1/151)

Oli around Tuesday, November 26th...

Is it possible to choose insecure ciphersuites with TLS 1.3?

I don't know of any that are currently considered insecure, no.

Twas Tuesday, November 26th when Oli said...

But how important is the support for _very_ old hardware? Is anyone still developing Fidonet software for these computers, especially a binkp mailer? Does binkp still compile for Amiga 68k? Is it possbile to use any secure encryption (by todays standards) on these machines?

I know a lot of people are running FTN on older hardware. I have no idea if any
of them are running bink. ...but presumably, they need to talk to newer hardware that is, and if it's encrypted... It's a tough situation I guess.

Even with older hardware that doesn't support AES-NI, the kind of traffic we're
talking for the BBS world is probably a non-issue as long as said hardware can
even do *any* semi modern crypto.


Oli around Tuesday, November 26th...

There are two options: 1) You just run your old software with no or weak encryption as all the other nodes do today. 2) You do the encryption on another device.

With something more standard like TLS this becomes easier since you can do TLS termination via HAProxy or similar, so I guess that's the work around for older
setups.

On Tuesday, November 26th Oli was heard saying...

I would like to avoid this. This would open another can of worms.

Build in support for Let's Encrypt :)


Twas Tuesday, November 26th when Oli said...

What do you mean with e2e encryption in this context? e2e on the network level or on the message level?

Application level protocol, same layer as TLS lives. Was mostly tossing that out there, I don't know that it's a good idea in any way due to the various limitations that need to be overcome (e.g. the offloading for older setups, writing the stuff in various languages, so on.)


--

NuSkooler
Xibalba BBS @ xibalba.l33t.codes / 44510(telnet) 44511(ssh)
ENiGMA 1/2 BBS WHQ | Phenom | 67 | iMPURE | ACiDic

--- ENiGMA 1/2 v0.0.11-beta (linux; x64; 12.13.1)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)

On Tue, 26 Nov 2019 19:15:02 -0700
"NuSkooler -> Oli" <[email protected]> wrote:

I would like to avoid this. This would open another can of
worms.

Build in support for Let's Encrypt :)

For testing we can use self-signed certs. I also would prefer not to be dependent on CAs by default. We could use trust on first use (TOFU) instead (like SSH does by default). Ideally this would be configurable per domain, zone, network or node/point. Of course there is also DANE.

What is still missing is some authentication of incoming connections if no session password is configured. On the TLS level we could use client certificates, but it would make everything more complicated and less flexible.

Maybe some new callback OPT in binkp?

I have mail for you, please poll my node to get it

< Okay

cu, bye

or
< Nah, just dump it, I don't care about authenticity

[files]
done, bye

or
< I don't want it and I will not call back

whatever, bye

---
* Origin: (21:1/151)

Oli around Wednesday, November 27th...

For testing we can use self-signed certs.

If you don't want to muck around with CA's (I'd highly recommend you *do*; ACME
/ Let's Encrypt works very well -- but you *do* need domains and the like), the "sign up" process simly becomes "Trust this particular cert", which isn't really that bad.

On Wednesday, November 27th Oli said...

What is still missing is some authentication of incoming connections if no session password is configured. On the TLS level we could use client certificates, but it would make everything more complicated and less flexible.

I've used client authentication many times over the years, what are you concerns over compliexity/less flexible here? As for passwords, they are now OK
to send as they don't go over the wire unless the TLS handshake completes (or maybe I'm misunderstanding what you're saying here)


--

NuSkooler
Xibalba BBS @ xibalba.l33t.codes / 44510(telnet) 44511(ssh)
ENiGMA 1/2 BBS WHQ | Phenom | 67 | iMPURE | ACiDic

--- ENiGMA 1/2 v0.0.11-beta (linux; x64; 12.13.1)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)

On Wed, 27 Nov 2019 09:25:49 -0700
"NuSkooler -> Oli" <[email protected]> wrote:

On Wednesday, November 27th Oli said...

What is still missing is some authentication of incoming
connections if no session password is configured. On the TLS
level we could use client certificates, but it would make
everything more complicated and less flexible.

I've used client authentication many times over the years, what are
you concerns over compliexity/less flexible here? As for passwords,
they are now OK to send as they don't go over the wire unless the TLS handshake completes (or maybe I'm misunderstanding what you're saying
here)

To make sure that we are talking about the same thing: If we are receiving a binkp call, we don't know if the presented FTN address is really the address of
the caller (until both nodes uses a shared password). Now it would be possible
to use client certificates to authenticate the calling node. I just don't think we should depend too much on TLS certificate stuff.

Complexity: managing certificates: signing, distributing, renewing, revoking. Based on FTN's own CA or on real Internet domains and CAs?

(In)Flexibility 1: only works with mailers that supports TLS directly. Doesn't work with proxies and wrappers.

(In)Flexibility 2: we would need to fully commit to TLS. I don't think it would
happen nor that it is a good idea.

I would use TLS as a simple encryption layer that is used for secure encryption
only.

I also wonder if we should use QUIC instead of TCP+TLS?

---
* Origin: (21:1/151)