Subj : Web access, false BBS ID To : Andy Ball From : Michel Samson Date : Sat Oct 30 2004 06:43 am Hi Andy, About "TelNet vs SSH" of October 29: BG> Are there any web-access BBSs, other than EleWeb... MS> ...the obvious lack of security is what i'd call a deterrent, in MS> favour of plain old DialUp/~TelNet~ BBSing, i mean... AB> How is this any more secure than an unencrypted HTTP connection? MS> We're in perfect agreement over ~SSH~, not the removal of ~TelNet~. AB> Sysops seem pretty thin on the ground these days... MS> ...it's not tempting to leave such people too much ground... AB> What telnet transition? MS> ...total disapearance of local DialUp BBSes... The real challenge MS> was ~OLMR~ BBSing which depended on the availability of ~TelNet~ MS> clients with suitable `ZMoDem' support... ...for the ones who must MS> cope with transitions on their own... there's more to come... AB> You make it sound as though users are being forced to progress AB> through dial-up -> Telnet -> Web -> SSH, which is nonsense. You fail to take into account the context where an analogy with the "~POP3~ before ~SMTP~" validation method is brought in, i wonder if it's obvious to you what "~POP3~ before ~SMTP~" is implying. ;-) Throughout the years, Authors/SysOps have been acting like MicroSoft $hare holder$, or employee$: they took for granted that all BBSers are using `Windows' and it's even more specific than that since a BBSer's HardWare should be able to run a `Win 32' OS for ~SSH~/~HTTPS~; i've lived thru times when there were no other way to get `ZMoDem'/~TelNet~, ~WEB~ access, ~SSH~ or ~HTTPS~ than to launch `Win 32', i mean... Each time the authors/SysOps discover a new standard they fail to ensure that it doesn't break what i call the "UpGrade Path" and *THAT* is what sounds like "nonsense" to me. AB> None are compulsory and there is certainly no need to progress AB> through them in any kind of sequence. Do you suggest that the user AB> is authenticated on the basis of a static IP address? Perhaps you AB> meant once each session, but you have still not explained what AB> mechanisms you would use for authentication and encryption. I missed the point, really? 1st, the time-scale is over years when i discuss "transitions" like going ~TelNet~ because there's no BBS left; the time-scale is over minutes when the topic is about validation in the "~POP3~ before ~SMTP~" fashion. There's no need to explore ways to make ~TelNet~ secure with help of ~SSH~ or ~HTTPS~ since authors/SysOps would just remove that LEGACY feature instead but i will because you insist... MS> ...i haven't tried to determine on which criteria the ~IP~ address MS> should be approved just yet. What about Domain Names? AB> What about them? Do you expect BBS users to register a domain name AB> just so that they can connect to a BBS? I'd be a monster and a fraud if i were to promote BBSing like this! MS> This was only meant as an alternative to accomodate BBSers who must MS> connect using ~SSH~ then ~TelNet~ *SEPARATELY*, for some reason... AB> What reason? Describe a scenario in which this makes sense. Lets start with the BBS system from where i'm posting right now. I got "69.75.117.170" when i fed `NSLookUp' with "BBSNets.COM" and then it led to two very distinct results when i used `TraceRt'... I have access to two different ~ISP~s at home so i made this test with both and here's what i found: my 128 Kbps ~DSL~ feed gives two consistent strings which show up as "bellnexia.net" and "inet.qwest.net" in the listing; with my DialUp account there were three of these, somehwere in the listing i got "sogetel.net", "vtl.net" and "level3.net". In both cases, it began with a Domain Name i could associate with the ~ISP~ i used to ~TelNet~ and it ended with what i believe to be the Domain Name of the ~ISP~ which gives access the remote BBS system. Forget about the exact ~IP~s and focus on paterns which can be recognized time after time after time when the user connects to the ~TelNettable~ BBS via his ~ISP~. Now, lets combine with this distinct patern a form of secure validation thru the previous ~SSH~ or ~HTTPS~ session (which took place MINUTES AGO); if i were a SysOp, a validation method as selective as this would sound secure enough for the LEGACY BBSers to use ~TelNet~. In this context, it does make sense, no? MS> ...accomodate BBSers who can't use file transfers over a same ~SSH~ MS> session but who could ~SSH~ then ~TelNet~, separately. AB> It may also be possible to use traditional BBS file transfer AB> protocols such as XModem, Kermit etc. over an SSH connection. Human perception is amazing. Anyway, as i explained, ~SSH~/~HTTPS~ and ~TelNet~ ARE available separately, probably under most of the OSes i can think of and even under DOS i might add! I see no reason why i'd be unable to validate thru ~SSH~ and then call a BBS thru unsecure ~TelNet~ SoftWare, given the validation scheme i have in mind can be supported... ;-) So far, once a session is initiated i wouldn't care that my BBSer's ~IP~ is changing as long as his partern is going to be the same. Do you still fail to see where the "~POP3~ before ~SMTP~" analogy fits here, or must we argue further over something which we both know won't happen?... `Zap-O-Com' would allow that but this is a `Win 32' application and i rarely launch `Windows' just to get a message-packet (the wait is very long and is measured in minutes because INet acces under `Windows' would require that i use a Fire-Wall, an Anti-Virus and also an Anti-PopUp, if the only option left is a ~WEB~ BBS)... All this HardWare and SoftWare, just for a message-packet! How can i say, it's like driving a 10 wheels heavy truck to go buy chips at the local store! Access to our hobby can be made simpler for BBSers, SysOps should ensure smoother UpGrade Paths. Salutations, ;-) Michel Samson a/s Bicephale http://public.sogetel.net/bicephale/ .... W32/WSock+DSL+COM/IP+DOS/Int-14+MS-Kermit+.QWK are LEGACY inclusive. ___ MultiMail/MS-DOS v0.45 - It could make TelNet OLMR BBSing UNIVERSAL! --- Maximus/2 3.01 * Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000) .