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,468 of 8,958   
   Michiel van der Vlist to Alan Ianson   
   Binkd and TLS   
   15 Dec 19 11:45:52   
   
   TID: FMail-W32 2.1.3.7-B20170919   
   RFC-X-No-Archive: Yes   
   TZUTC: 0100   
   CHRS: CP850 2   
   MSGID: 2:280/5555 5df61314   
   REPLY: 1:153/757 5df60c73   
   Hello Alan,   
      
   On Sunday December 15 2019 02:15, you wrote to me:   
      
    MV>> I can understand why one would use https instead of http when   
    MV>> dealing with sensitive information such as bank account numbers   
    MV>> etc. But for Fidonet? What are you trying to hide/protect from   
    MV>> whom?   
      
    AI> I have nothing to hide. I would just prefer to be secure that   
    AI> unsecure.   
      
   Just watch out for a false sense of security.   
      
    MV>> TLS does not hide the meta data such as what IP communicates with   
    MV>> what other IP. Binkd already has encryption on the pkt content   
    MV>> level.   
      
    AI> I don't want or need to hide the fact I am on and using the internet.   
    AI> I would like passwords to be hidden from anyone who might be snooping   
    AI> my traffic.   
      
   Binkd already has secure verification of the session password. Other passwords   
   are automatically secured by binkd's own encryption. an extra TLS layer adds   
   nothing to that.    
    MV>> Plus that 99% of Fidonet is echomail and encryting echomail makes   
    MV>> little or no sense. For routed netmail, using encrytion on the   
    MV>> transport level does not protect against snooping by sysops en   
    MV>> route.   
      
    AI> Mystic's implementation of all this includes netmail optionaly. When   
    AI> Mystic nodes use an encryption key between nodes netmail between them   
    AI> is encrypted. If it is stored, it is stored in an encrypted state.   
      
   For end to end message encryption and authorisation we have PGP. Served me   
   well for three centuries.   
      
    AI> I know this because I had a typo in my encryption key at one time and   
    AI> could not read my own netmail.. :)   
      
   That shows that one can overdo it. I see no advantage in storing my netmail in   
   encrypted form. It just makes things difficult for me. To read my stored   
   netmail one needs physical access to my system.   
      
   I don't have locks on my bathoom either. Just a warning that it is in use.   
   Anything moe just makes life more difficult fo myself.   
      
    MV>> So other than the pure sensation of a technical challenge, why?   
      
    AI> It's not sensational. It is just security. Security must be important   
    AI> at some level or there would not be a crypt option at all.   
      
   Of course it is important at some level. But one can overdo it and than it   
   gets in the way of comfort. I protect the codes for internet banking and use a   
   secure link for it. But I am not going out of my way to protect my toilet   
   against unauthorised use. That just makes life difficult for me in case of ..   
   well guess what.. ;-)   
      
    AI> I think TLS is just the way it is done today.   
      
   Hmmm... I have my doubts. Have you heard about the Diginotar debacle?   
   Diginotar was a Dutch CA. It was hacked and all the certificates were   
   compromised.   
      
   Other CAs have had problems with security too.   
      
   As I said, I consider it a technical challenge. When I find a way to get it   
   working with Windows, I may give it a try. But I won't feel ant safer than I   
   already am with binkd's own security.   
      
      
   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