Subj : Binkd and TLS
To : Richard Menedetter
From : Michiel van der Vlist
Date : Tue Dec 17 2019 04:10 pm
Hello Richard,
On Tuesday December 17 2019 14:31, you wrote to me:
RM> But this does not make it less standard, only less used. You can
RM> import a client certificate into Firefox and other browsers for a long
RM> period of time. And you can use this as a more secure means of
RM> authentication.
OK, "less used" describes it better than "non standard".
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?
RM> There is potential value. (eg. passwords can be very easy to guess ...
RM> toor, passw0rd, ...)
That is not a shortcoming of the protocol, it is a shortcoming of the user.
RM> client certificates are much more secure than eg. 8 digit passwords.
Binkd session passwords are not limited to 8 characters. I just tried a 25 byte
string and it functions. I say "bytes" because I inserted a cyrillic UTF-8
character. Changing the last byte results in a password error, so all bytes are
used. Case sensitive. I don't know what the limit is, but it is at least 25.
A properly choosen 25 byte string is impossible to guess I'd say. A brute force
attack won't work very well with binkd either. So I don't think that part of
binkd can be considered "weak".
RM> I doubt that that added value is "worth it" in fidonet, where many
RM> people used ancient software, and only a small minority is interested
RM> to roll out new features.
Frankly I see no significant added value at this point. It just adds
overhead...
MV>> Binkp's CRYPT protects against unauthorised listeners on the
MV>> channel. I am not aware of binkp's security being compromised.
RM> I am also not aware of it. But you have to admit that security
RM> researchers have more prestigeous targets then binkd crypt. (So I
RM> assume that it was never really challenged and analyzed.)
Yes, there is that. It was probably never really challenged.
RM> Breaking TLS gains you lots of $$$, so many people try it. (without
RM> any knowledge of then being successful.)
I suspect it is already boken by government agencies. Those are the ones that
have the resources...
MV>> Plus that I still wonder what we are protecting against whom. Do
MV>> we really need 10 cm armour and triple locks to protect Fidonet
MV>> content?
RM> Why not? ;)
RM> Using binkp in a stunnel definitely will not weaken the security.
Not if you do it right. If you do it wrong....
RM> (eg. if you break the stunnel, you still are left with the same binkp
RM> stream that you would have had previously.) And adding a TLS option
RM> for clients that support it, will not be weaker than our existing
RM> crypt implementation.
Unless you use TLS not in addition to but instead of binkp session password and
CRYPT.
RM> So it is doable, and would benefit security from my point of view.
RM> But I do not think many people would use it.
Like I said before, I may give it a try just for the sake of the technical
challenge. I don't consider the added security of such magnitude that I'd start
using it large scale..
RM> The easiest target would be to have a second port where you can make
RM> stunnel connections. (this is not very practicable from my point of
RM> view, outside of PoC) Or the second easiest but more useable target
RM> would be to implement starttls and use it if both parties support it.
RM> (relying on passwords, not client certificates)
The Synchronet fans do not seem to like starttls, they want a diffrent port. So
we alreay have two competing standards...
Cheers, Michiel
--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin:
http://www.vlist.eu (2:280/5555)
