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,482 of 8,958   
   Michiel van der Vlist to Alan Ianson   
   Binkd and TLS   
   17 Dec 19 13:13:01   
   
   TID: FMail-W32 2.1.3.7-B20170919   
   RFC-X-No-Archive: Yes   
   TZUTC: 0100   
   CHRS: CP850 2   
   MSGID: 2:280/5555 5df8c8af   
   REPLY: 1:153/757 5df8b39b   
   Hello Alan,   
      
   On Tuesday December 17 2019 02:19, you wrote to me:   
      
    MV>> Then what problem ARE we trying to fix?   
      
    AI> We are not trying to fix problems. We are trying to be secure.   
      
   "Secure" is meaningless without specifying against WHAT. What threats are we   
   securing against?   
      
    MV>> Apples and oranges. Nobogus solved problems created by rouge   
    MV>> CLIENTS. TLS does not protect against that. It only authorises   
    MV>> the /server/, not the /client/.   
      
    AI> TLS needs to be supported and used by both client and server.   
      
   I know that. But it is designed for a client/server model. It verifies to the   
   client that the server is who it claims to be. Not the other way around. (Not   
   in the standard impelmentatios anyway) The TLS verification mechanism protects   
   the client against being redirected to a rogue server. It does not protect the   
   server against a maliciouis client. For that there usually is identification   
   on the application level. Often called log in. So TLS does not protect against   
   someone with evil intentions to connect to your binkp server and do something   
   malicious.   
      
    MV>> In what way is TLS "better"? A claim of "better" security has to   
    MV>> be more specific than just that. Better than what? Better against   
    MV>> what threats and by whom?   
      
    AI> I can't answer why, I don't know all the reasons why. TLS is the   
    AI> standard method used today to secure traffic on the internet,   
      
   That does not make it better for use in Fidonet. Fidonet is not the InterNet,   
   it just makes use of it.   
      
    AI> and I would like to be secure.   
      
   You keep saying that, but you can't explain against what we are securing and   
   you can't explain why using TLS is more secure than using the security binkp   
   already has,   
      
    AI> We could also just stand still and see how it goes.   
      
   If you do not know what you are doing, "do nothing" ain't such a bad   
   strategy...   
      
    AI> I am just being proactive WRT security.   
      
   In order to move forward, one first has to know which direction matches   
   "forward".   
      
    AI>>> It does require some setup. Synchronet's BinkIT mailer currently   
    AI>>> has support for a binkps listener setup like this in   
    AI>>> Synchronet's services.ini   
      
    MV>> The world of Fidonet is bigger than Synchronet (Thank god). You   
    MV>> make it sound like "Synchronet supports it, so it must be a good   
    MV>> thing". Sorry, I am not of the "Synchronet is better" club.   
      
    AI> True. I want us all to be secure regardless of our choice of software.   
      
   I am not convinced that adding TLS to binkp enhances security. Especially with   
   security, just "moving forward" withou knowing exactly what you are doing is a   
   bad idea. You may actually be less secure after the move.   
      
    AI>>> This was all done without changing binkp. We have simply put   
    AI>>> binkp on a secure channel.   
      
    MV>> But why? I still have no answer for that. Let me put it this way:   
      
    MV>> If binkd over TLS is the solution, what is the problem?   
      
    AI> There is no problem here that we are trying to solve.   
      
   If there is no problem then why add TLS to binkp?   
      
    AI> Binkd currently supports an option called CRYPT, for the purposes of   
    AI> security.   
      
   First there is the session password. That protects the server against a rogue   
   client posing as a trusted party.   
      
    AI> That was a good option when it was implemented.   
      
   What makes you think the CRYPT option of binkp is no longer a good option?   
      
    AI> Today TLS is used for the purposes of security.   
      
   It is used by many. That's no guarantee it is "better".   
      
    AI> I could be all wrong but I think TLS is a better option, that's all.   
      
   When it concern security I'd rather not rely on "think". I prefer demonstrated   
   facts.   
      
    AI> Maybe I said that wrong. How about this. Binkd's CRYPT option is weak   
    AI> (by todays standards).   
      
   In what way is it weak? Has it been cracked? Is there a known vulnerability?   
   Is there a backdoor? Are there any known cases of damage to Fidonet because of   
   a weakness in CRYPT?   
      
    AI> Maybe we should think about using something more up to date, like TLS.   
      
   "More up to date" is not better by definition. With governments that keep   
   pushing for backdoors in encryption, "someting more up to date" may actually   
   be a step back.   
      
   Cheers, Michiel   
      
   --- GoldED+/W32-MSVC 1.1.5-b20170303   
    * Origin: http://www.vlist.eu (2:280/5555)   
   SEEN-BY: 1/123 90/1 103/705 154/10 203/0 221/0 6 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 5019/40   
   SEEN-BY: 5020/1042 5053/58   
   PATH: 280/5555 464 229/426   
      

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca