Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    BINKD    |    Support for the Internet BinKD mailer    |    8,958 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 6,486 of 8,958    |
|    Richard Menedetter to Michiel van der Vlist    |
|    Binkd and TLS    |
|    17 Dec 19 14:31:44    |
      REPLY: 2:280/5555 5df8cd03       MSGID: 2:310/31 5df8dd29       CHRS: LATIN-1 2       TZUTC: 0100       TID: hpt/lnx 1.9.0-cur 2019-01-08       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)       SEEN-BY: 1/123 90/1 103/705 154/10 203/0 221/0 227/114 229/101 200       SEEN-BY: 229/354 426 1014 240/5832 249/307 317 280/464 5003 5555 292/854       SEEN-BY: 310/31 342/200 396/45 423/120 712/848 770/1 2452/250       PATH: 310/31 280/464 229/426           |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca