Text 12629, 75 rader
Skriven 2022-02-28 13:13:08 av James Coyle (1:129/215)
  Kommentar till text 12627 av Tim Schattkowsky (2:240/1120.29)
Ärende: Re: Re^2:  Re^2:  Re^4:  Directly include binary data in messages
=========================================================================
 TS>  JC> or if not then just "trial and error" by attempting to connect to a
 TS>  JC> default SSL port first before falling back to the standard BINKP   
TS>  JC> TS>  JC> TS>  JC> port
 TS> 
 TS> Better than the nodelist flag. Should be another "unused" port ...

Agreed!  Current Mystic defaults to port 24553 for direct SSL.  I believe
Synchronet may use the same default but Rob could probably clarify.

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

Fair enough.  To be clearer Mystic only supports TLS 1.2 in its SSL BINKP
implementation and it should be the minimum version allowed as per current
security recommendations.

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

I was just making an example, but what I meant was you could configure if you
accept non-SSL connections for unknown (unsecured) echomail nodes vs known
(secured) echomail nodes.  This would not be something we could do with a
direct SSL connection.

Just trying to outline some of the benefits of the opportunistic approach :)

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

True it does not hide the initial nature of the communication as you have said,
and this I would agree is probably its only real flaw.  But I feel the trade
off is that it will work without user awareness or configuration.

Even with direct-connection TLS 1.2 BINKP in Mystic many people still do not
use it.  Realistically if we want the network to be more secure, then making it
opportunistic and automatic may be the best compromise?

I think we may have to decide if we care about hiding the fact that a FidoNet
node even exists, or if (instead) we want widely adopted better security within
the network.

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

Can you expand on why you think AES-256 is not ideal from a security
perspective?  Or did you just mean the CBC + random IV + authentication
workaround?

There are alternatives but none of them have had huge enterprise adoption and
decades of scruinty from the best cryptographers in the world.  There is
something to be said about anything in the security industry that has had that
type of exposure and is still regarded as safe.

Newer things may in theory be technically better, but its only theoretical.
These do not have the adoption or decades of scrutiny and could be exposed at
any time.  It is risky to assume newer is better when the "old" hasn't been
broken.

Similar arguements could be made for using hashes like SHA256 vs others, for
example.  Mystic uses a PBKDF2 with SHA512 for user passwords for example and I
still question if using SHA512 was a mistake for those reasons.

In terms of Netmail the subject line in a Mystic encrypted netmail contains
version levels, flags, and some verification data which could be used to
support multiple types of encryption in the future while still being backwards
compatible.

... If you choose not to decide, you still have made a choice

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