home bbs files messages ]

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