Subj : Binkd and TLS
To   : Michiel van der Vlist
From : Richard Menedetter
Date : Tue Dec 17 2019 14:31:44

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
 * Origin: You are an insult to free speech. (2:310/31)

.