Text 12627, 97 rader
Skriven 2022-02-28 17:54:06 av Tim Schattkowsky (2:240/1120.29)
  Kommentar till text 12625 av James Coyle (1:129/215)
Ärende: Re^2:  Re^2:  Re^4:  Directly include binary data in messages
=====================================================================
//Hello James,//

on *28.02.22* at *15:15:12* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Re: Re^2:  Re^4:  Directly include binary data in
messages"*.

 TS>> That already helps a lot. Have to add this. However, this in the end
 TS>> requires some additional information for the clients to connect to be
 TS>> aware of SSL/TLS support !?

 JC> Yes you are right for direct SSL connections there would need to be some
 JC> way for a node to know if the connection is compatible with SSL when
 JC> transmitting netmail via unsecure connections.

 JC> Maybe a nodelist flag,

That was my first thought as well.

 JC> or if not then just "trial and error" by attempting to connect to a
 JC> default SSL port first before falling back to the standard BINKP port.

Better than the nodelist flag. Should be another "unused" port ...

 JC> For these reasons, I was experimenting with opportunistic SSL for BINKP.
 JC> With opportunistic SSL the connection is always on the same port and if
 JC> both clients support SSL it will convert the connection prior to any
 JC> authentication.

Before it comes up (there is always a troll): probably TLS rather than SSL, but
admittedly I also someimes keep talkin about SSL when referring whatever
session layer protocol is actually in charge. Educated people know what its
about ...

 JC> It also gives us the capability to decide if a connection should be
 JC> accepted in real-time.  For example, if unsecure node then maybe SSL is
 JC> required otherwise known nodes can use cleartext.

I am not sure if this makes sense. So you want to use an unsecured connection
to have the session password transmitted? ;)

 JC> BINKP would be able to make decisions as to what it will and won't allow
 JC> in "real-time" and then gracefully accept or refuse connections with a
 JC> proper error message.

This brings us to a potential integration into BinkP itself. That would server
the above issues, but overall it is more compliated to implement and does not
hide the nature of the communication itself, which maybe a point. (I already
see VPN arguments coming up ...)

 JC> We would not require any broader changes (nodelist flags, etc) outside of
 JC> BINKP client that supports opportunistic SSL extension and it is fully
 JC> backwards compatible with BINKP that does not support the extension.

Not relying on the nodelist would be a big plus. I also think, it is more
desirable to have something that works out-of-the-box if both systems are
compatible without any additional infrastructure/metadata/explicit
configuration.

 JC> A nodelist flag that states that a node may require SSL would still be
 JC> ideal in the long run, but we would not depend on it for this to work
 JC> well.

Having it for information purpose is fine.

 TS>> The key distribution is the interesting part. Also, probably one should
 TS>> probably employ a combination of asym/sym (e.g., RSA+AES) as usal, so
 TS>> the symmetric keys are used only once.

 JC> I agree this would be where the challenge is for unsecure transfer.  The
 JC> AES in Mystic was done a while back and is a bit outdated.  It does not
 JC> have any way to circulate a keystore in a peer-to-peer way so it only
 JC> works for known nodes.

 JC> One thing I found is that many end users didn't really seem to grasp the
 JC> SSL keystores/certs/keys concepts all that well, so in Mystic I present
 JC> an "Encryption password" and when that is set for a known node, Mystic
 JC> will AES256 encrypt.

 JC> Behind the scenes it takes that password and then uses SHA256 to create
 JC> the actual 256-bit key that is used.  It uses AES256-CBC which today
 JC> isn't as ideal, but it does use a randomized IV and it does have
 JC> authentication of the decrypted data to help secure tampering.  In 2022 a
 JC> GCM version would be better though instead of using proprietary means to
 JC> secure CBC.

 JC> One benefit of using this approach is that there is a lot of AES256 code
 JC> available for just about any language that people can leverage, and I
 JC> think that would be highly important for adoption.

Jep, straightforward. However, it is not ideal from a security and usability
perspective. (No, I have no better proposal at hand for now).

Regards,
Tim

--- WinPoint 401.1
 * Origin: Original WinPoint Origin! (2:240/1120.29)