Text 12625, 56 rader
Skriven 2022-02-28 10:15:12 av James Coyle (1:129/215)
  Kommentar till text 12622 av Tim Schattkowsky (2:240/1120.29)
Ärende: 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 !?

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.

... Condense soup, not books!

--- Mystic BBS v1.12 A48 2022/02/17 (Windows/32)
 * Origin: Sector 7 * Mystic WHQ (1:129/215)