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)
