• Secure binkp

    From Al@21:4/106 to Oli on Sat Nov 23 11:11:42 2019
    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)
  • From Oli@21:1/151 to Al on Sat Nov 23 21:42:05 2019
    "Al -> Oli" <0@106.4.21> 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)
  • From Oli@21:1/151 to Al on Sun Nov 24 13:30:36 2019
    On Sat, 23 Nov 2019 11:11:42 -0800
    "Al -> Oli" <0@106.4.21> 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)
  • From Oli@21:1/151 to Al on Sun Nov 24 18:12:49 2019
    "Al -> Oli" <0@106.4.21> 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)
  • From Al@21:4/106 to Oli on Sun Nov 24 14:16:18 2019
    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)
  • From Al@21:4/106 to Oli on Sun Nov 24 14:17:46 2019
    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)
  • From Al@21:4/106 to Oli on Sun Nov 24 14:25:50 2019
    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)
  • From Alterego@21:2/116 to Al on Mon Nov 25 11:26:41 2019
    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)
  • From Oli@21:1/151 to Al on Mon Nov 25 10:12:38 2019
    "Al -> Oli" <0@106.4.21> 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)
  • From Oli@21:1/151 to Al on Mon Nov 25 17:51:42 2019
    On Sun, 24 Nov 2019 14:25:50 -0800
    "Al -> Oli" <0@106.4.21> 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)
  • From Al@21:4/106 to Oli on Mon Nov 25 14:13:52 2019
    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)
  • From Oli@21:1/151 to Al on Tue Nov 26 00:53:04 2019
    On Mon, 25 Nov 2019 14:13:52 -0800
    "Al -> Oli" <0@106.4.21> 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)
  • From NuSkooler@21:1/121 to Al on Mon Nov 25 19:49:35 2019

    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)
  • From Al@21:4/106 to Oli on Mon Nov 25 23:51:22 2019
    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)
  • From Al@21:4/106 to NuSkooler on Mon Nov 25 23:55:52 2019
    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)
  • From Avon@21:1/101 to Al on Tue Nov 26 21:01:29 2019
    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)
  • From Oli@21:1/151 to NuSkooler on Tue Nov 26 13:31:49 2019
    On Mon, 25 Nov 2019 19:49:35 -0700
    "NuSkooler -> Al" <0@121.1.21> 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)
  • From NuSkooler@21:1/121 to Oli on Tue Nov 26 19:15:02 2019

    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)
  • From Oli@21:1/151 to NuSkooler on Wed Nov 27 11:12:30 2019
    On Tue, 26 Nov 2019 19:15:02 -0700
    "NuSkooler -> Oli" <0@121.1.21> 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)
  • From NuSkooler@21:1/121 to Oli on Wed Nov 27 09:25:49 2019

    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)
  • From Oli@21:1/151 to NuSkooler on Fri Nov 29 13:48:19 2019
    On Wed, 27 Nov 2019 09:25:49 -0700
    "NuSkooler -> Oli" <0@121.1.21> 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)