= Сообщение: 6185 из 7128 ====================================== FTSC_PUBLIC = От : James Coyle 1:129/215 28 Feb 22 13:13:08 Кому : Tim Schattkowsky 28 Feb 22 13:13:08 Тема : Re: Re^2: Re^2: Re^4: Directly include binary data in messages FGHI : area://FTSC_PUBLIC?msgid=1:129/215+b7124989 На : area://FTSC_PUBLIC?msgid=2:240/1120.29+3d17e113 = Кодировка сообщения определена как: ASCII ================================== ============================================================================== 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
