Re: LYNX-DEV Lynx and secure channel, is that a reality?

[Jim Dennis]

> Dear Lynx developers!
> 
> I am designing a website which is supposed to accept credit and visa card
> as well as other information that should be sent via secure channel. The
> obstacle appeared when I started to test things under Lynx text browser.
> I found that Vanila version of Lynx, which by default, is compiled on most
> Internet machines, doesn't suport https protocol. So the idea of having
> all the ISPs to recompile their Lynx browsers seems rather fantastic and
> unreal.
> Is there any way that I can have text-oriented users submit their secure
> information through Lynx?

        The stock lynx, and other common ISP tools (telnet, rlogin,
        etc) simply don't support encryption.  Any solution that
        would be reasonably secure would require encryption or a
        trusted out-of-band communications medium.

        As an example of an OOB mechanism:  Your customer registers
        an address and gets an account number via a web form: then 
        calls a voice phone to call an IVR (interactive voice resonse)
        system -- then types in (dialtones) their credit card number and 
        their account number.  Now the account is associated with the
        cc number.  An attacker might make bogus orders on that account
        (using intercepted information) -- but they'll all be shipped to 
        the true account holder's shipping address -- which can't be 
        modified.  The customer's credit card is never exposed to the
        Internet (unless they used some "cyberphone" for their voice call
        or your 'store' is inadequately firewalled).

        "inband" methods are numerous.  The obvious one is the 
        require an SSL browser (such as Lynx with the SSL support --
        or Lynx configured to use an SSL proxy).  Note:  any 
        browser pointing at a non-localhost proxy is exposing the
        data during it's transit from the localhost to the proxy.
        Netgain: zip!  Another method would be to set up a 
        server of your own that allows ssh, STEL, or ssltelnet 
        connections -- and runs a "jailed" lynx session.  Thus the
        customer uses some encrypted access to your system (requires
        the ISP to install and maintain a client program!) and then
        uses that to talk to your copy of lynx (which could be running
        on the "storefront" host -- "securely" in your domain -- and/or
        be SSL enabled).  Unfortunately this leads back to your 
        first problem -- common shell account ISP's aren't likely to 
        install any such software (and worse -- it's not certain how 
        much trust should be placed in the ISP's software:  ISP's are
        compromised almost as routinely as college/university computing
        centers).

        Lastly there is the simple method of having accounts established
        via PGP (or S/MIME, PEM/RIPEM or the e-mail encryption toy of
        choice).  This is basically identical to the OOB method I 
        described before -- except that you can also get a computer
        readable response back to the user.  This could be a one-time
        password pad (for example) -- which would allow your user to 
        access the online store via plaintext (telnet, browswer, whatever)
        and prevent the "bogus orders" problem via a challenge/response
        (OTP) authentication.  The only attack that I know of that would 
        be effective against this would be a dynamic man-in-the-middle
        (one who sits between the client and the server, relaying the 
        challenge response and hooking into the rest of the session to
        insert the bogus order).  Again this can be implemented such that
        there is no facility for changing the shipping address associated
        with a given CC account.

        Of course, if you're going to create a PGP account management
        system (presumably using procmail on the server side -- to 
        automated some of the details) you might as well create a 
        full e-mail system for order processing and an e-mail catalog
        infobot (to send selected queries and portions of your catalog
        in automated response to e-mailed requests; you can even support
        graphics, animation, and sound using MIME).  It's not as "sexy"
        as the "web" but it's every bit as functional.

        If the customer uses a copy of PGP on their ISP's system they
        have the same problems we described earlier.  However if they 
        have installed PGP on their own system then they can cut and 
        paste (or use text editor and text file xfers) to compose 
        thier e-mail.  It's also possible that these customers are 
        using some sort of offline mail reader (QWK, SOUP, YARN)
        for their mail -- so they might have e-mail support for MIME
        despite their text only access to the 'net.

        All of this is increasingly unlikely, however.  These days there
        is considerable "market" and medial pressure to twist everyone
        into using PPP (SLIP isn't good enough either!) and one of the
        two big software company "approved" browsers for all access to the
        'net.  Diversity is great for political correctness -- but we can't
        have any of that interfering with our operational costs and 
        marketing preferences.

        It never ceases to amaze me how much of the "market pressure" 
        takes the form of the "marketeers" putting their pressure on the
        consumers.  It wasn't supposed to be that way!  We were supposed
        to convey our needs to the market, not have our needs dictated to
        us by them!  Ahh, the splendor of modern capitalism!
 
> I would ver much appreciate your answer or advice.
> Best regards,
> Victor

--
Jim Dennis  (800) 938-4078              address@hidden
Proprietor, Starshine Technical Services:  http://www.starshine.org
        PGP  1024/2ABF03B1 Jim Dennis <address@hidden>
        Key fingerprint =  2524E3FEF0922A84  A27BDEDB38EBB95A 
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;