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)
