28 Apr 20 22:42, you wrote to All:

 PJ> On Tue 17-Dec-2019  8:33 , Oli@2:275/201.0 said to Alexey Fayans:
 O>>  AF>>> No it doesn't. MitM attack can only fool client into
 O>> thinking
 O>>  AF>>> that TLS is not supported. But you can require TLS on a
 O>> client
 O>>  AF>>> side and it will just disconnect, no harm done.
 O>>  AI>> I believe it does.

 PJ> What is TLS and what is different about it from what we are using
 PJ> today with the standard Binkd config?

the binkp CRYPT extension requires a session password for the encryption. With
TLS it's possible to use encryption without a session password.

 PJ> If your a hub why would you force your clients to use it?

I think there is some context missing. IIRC correctly the discussion was about
opportunistic TLS:. the connection starts as plaintext and then is upgraded to
a TLS encrypted session. A man-in-the-middle can strip the TLS negotiation. To
mitigate the attack the client could insist on TLS and refuse any plaintext
connection. See
https://en.wikipedia.org/wiki/Opportunistic_TLS

There is no standard and for opportunistic TLS with binkp. We are using direct
TLS now. The server listens on another port and expects a TLS session on that
port (but still can offer plaintext sessions on the IBN port).

 PJ> Some of us are using some really old operating systems.

It's possible to run a TLS proxy on another machine, like a Raspberry Pi or an
OpenWRT based router.

Using Tor and Tor a hidden services is much easier to setup though.