Re: lynx-dev How to find if my isp's lynx is ssl-enabled?

[Serge Munhoven]

On Mon, Oct 22, 2001 at 08:44:41PM -0400, David Combs wrote:
 >  
 >  I have just been told by someone that soon the only
 >  way they will distribute upgrades, etc, will be
 >  via a SSL-enabled www-site.
 >  
 >  He asked if my (shell-account's) browser (lynx)
 >  supported ssl.
 >  
 >  I looked at my year-old copy of the user-guide
 >  and found only one reference to ssl:
 >  
 >      =force_secure
 >       toggles forcing of the secure flag for SSL cookies.
 >  
 >  I did try the option, and lynx didn't bomb --
 >  but I'm not sure if that alone tells me that
 >  the version they've set up is ssl-enabled
 >  or not.
 >  
IMHO you get a definitive anwser only by trying: e.g. go to

  https://localhost/

It won't bomb, but yield either:

  Alert!: This client does not contain support for HTTPS URLs.

(no SSL compiled in), or:

  Alert!: Unable to connect to remote host.

or some web page in return if a secure server happens to be running (SSL
compiled in in both cases).

 >  Nor do I have any idea how to either go to (if there
 >  is any difference) an ssl-enabled www-site, and
 >  what to do when I get there.
 >  
Except for the protocol (https://... vs http://... at the beginning of the URL)
there should not be any difference. SSL tries to connect to a server on port
number 443 instead of 80 and negotiates encryption with it, but this is
completely transparent to the user.  TLS (the successor to SSL) is even more
transparent in that it does not need separate ports (if I remember correctly).

On Tue, Oct 23, 2001 at 07:10:29AM +0100, David Woolley wrote:
 >  > >   The browser you are using does not meet Wells Fargo's stringent
 >  > >   security standards. This means that you will not be able to bank
 >  > ....
 >  > 
 >  > which is a load of crap.
 >  
 >  I believe some builds have inadequate random number generators - I think
 >  only those that make use of an OS kernel random number generator may be
 >  safe in that respect.
[...]
 >  There is at least someone to sue and with a reputation to defend when you
 >  use a commercial product, even if they have been naive about encryption
 >  in the past.
Hum, whom will they sue if the OS kernel (pseudo-)random number of <insert your
favorite open source OS supported by Netscape> turns out to be inadequate?
 >  
 >  At the very best, I would say that anyone faking the user agent string in
 >  this context would have to bear all the financial consequences of a breach
 >  of security or any other failure that could possible be due to a breach
 >  of security, and, at worst, their actions might be considered fraudulent,
 >  because of the faked user agent string.  IANAL, but I would advise 
 >  consulting one before faking a user agent string to get round encryption
 >  authorisation rules.
 >  
An upgrade distribution site may be a little less critical.

But if I understand it right, there is at the moment a more serious issue
with the SSL support in lynx: there is no verification whatsoever of the
certificate presented by the server.  We trust it blindly and silently.
Encryption is only one part of the story ...

 - Serge


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden