Hi Michiel!

17 Dec 2019 13:29, from Michiel van der Vlist -> Richard Menedetter:

 RM>> You can authenticate the client as well.
 MV> Yes, I know, it can be done. But TLS was designed around a
 MV> client/server model and authentication of the client is not standard.

I beg to differ on this.
It _IS_ standard, but much less used, so it is less common.
Because it is easier to roll out certificates on one server, then on all
clients that could potentially access your server.

But this does not make it less standard, only less used.
You can import a client certificate into Firefox and other browsers for a long
period of time.
And you can use this as a more secure means of authentication.

 RM>> But naturally then every client needs a signed certificate, and
 RM>> the server needs to verify that client certificate.
 MV> Indeed. And what is the added value of that?

There is potential value. (eg. passwords can be very easy to guess ... toor,
passw0rd, ...) client certificates are much more secure than eg. 8 digit
passwords.
I doubt that that added value is "worth it" in fidonet, where many people used
ancient software, and only a small minority is interested to roll out new
features.

 MV> Binkp's CRYPT protects against unauthorised listeners on the channel.
 MV> I am not aware of binkp's security being compromised.

I am also not aware of it.
But you have to admit that security researchers have more prestigeous targets
then binkd crypt. (So I assume that it was never really challenged and
analyzed.)
Breaking TLS gains you lots of $$$, so many people try it. (without any
knowledge of then being successful.)

 MV> Plus that I still wonder what we are protecting against whom. Do we
 MV> really need 10 cm armour and triple locks to protect Fidonet content?

Why not? ;)
Using binkp in a stunnel definitely will not weaken the security.
(eg. if you break the stunnel, you still are left with the same binkp stream
that you would have had previously.)
And adding a TLS option for clients that support it, will not be weaker than
our existing crypt implementation.

So it is doable, and would benefit security from my point of view.
But I do not think many people would use it.

The easiest target would be to have a second port where you can make stunnel
connections. (this is not very practicable from my point of view, outside of
PoC)
Or the second easiest but more useable target would be to implement starttls
and use it if both parties support it. (relying on passwords, not client
certificates)

CU, Ricsi

... If you knew what you're talking about, you'd be dangerous
--- GoldED+/LNX