= Сообщение: 6181 из 7128 ====================================== FTSC_PUBLIC = От : James Coyle 1:129/215 28 Feb 22 10:15:12 Кому : Tim Schattkowsky 28 Feb 22 10:15:12 Тема : Re: Re^2: Re^4: Directly include binary data in messages FGHI : area://FTSC_PUBLIC?msgid=1:129/215+708ff82e На : area://FTSC_PUBLIC?msgid=2:240/1120.29+3c750986 = Кодировка сообщения определена как: ASCII ================================== Ответ: area://FTSC_PUBLIC?msgid=2:240/1120.29+3d17e113 Ответ: area://FTSC_PUBLIC?msgid=31649.ftsc_pub@1:103/705+2682e92b ============================================================================== 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 !?
Yes you are right for direct SSL connections there would need to be some way for a node to know if the connection is compatible with SSL when transmitting netmail via unsecure connections.
Maybe a nodelist flag, or if not then just "trial and error" by attempting to connect to a default SSL port first before falling back to the standard BINKP port.
For these reasons, I was experimenting with opportunistic SSL for BINKP. With opportunistic SSL the connection is always on the same port and if both clients support SSL it will convert the connection prior to any authentication.
It also gives us the capability to decide if a connection should be accepted in real-time. For example, if unsecure node then maybe SSL is required otherwise known nodes can use cleartext. BINKP would be able to make decisions as to what it will and won't allow in "real-time" and then gracefully accept or refuse connections with a proper error message.
We would not require any broader changes (nodelist flags, etc) outside of BINKP client that supports opportunistic SSL extension and it is fully backwards compatible with BINKP that does not support the extension.
A nodelist flag that states that a node may require SSL would still be ideal in the long run, but we would not depend on it for this to work well.
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 the TS> symmetric keys are used only once.
I agree this would be where the challenge is for unsecure transfer. The AES in Mystic was done a while back and is a bit outdated. It does not have any way to circulate a keystore in a peer-to-peer way so it only works for known nodes.
One thing I found is that many end users didn't really seem to grasp the SSL keystores/certs/keys concepts all that well, so in Mystic I present an "Encryption password" and when that is set for a known node, Mystic will AES256 encrypt.
Behind the scenes it takes that password and then uses SHA256 to create the actual 256-bit key that is used. It uses AES256-CBC which today isn't as ideal, but it does use a randomized IV and it does have authentication of the decrypted data to help secure tampering. In 2022 a GCM version would be better though instead of using proprietary means to secure CBC.
One benefit of using this approach is that there is a lot of AES256 code available for just about any language that people can leverage, and I think that would be highly important for adoption.
