help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: w3m SSL handling error


From: Bob Proulx
Subject: Re: w3m SSL handling error
Date: Mon, 17 Oct 2016 13:08:03 -0600
User-agent: NeoMutt/20161014 (1.7.1)

B.V. Raghav wrote:
> Bob Proulx writes:
> > Here are some ideas.  What system are you operating from?  You didn't
> > say.  It is an xterm so I might assume some generic GNU/Linux system.
> 
> I am running on Debian stretch/sid. 

Me too.  It works okay for me from Debian Sid fully updated.  It also
works for me on Debian Jessie 8 Stable.

> > How up to date is it?  The error reminds me of other errors I have
> > seen when the client system is old enough that it only supports SSLv3
> > connecting to a web server that no longer supports SSLv3 anymore.
> 
> I dont know how to watch a network while some process is connecting to
> it. Please tell me I will do so.

I think your system may be in an unhappy state.  This is probably a
topic for debian-user but...  Unless someone complains let's just keep
going here.

You later say you are running behind a network wide proxy which I
think is likely the problem.  But first let's start with your system
anyway.  I tend to inspect these things from several different
viewpoints all at once and then something wrong appears that can be
fixed.  Please inspect with (on my Debian Sid system for example).
Following are a few commands and example output shown from my system.
Then later down I will ask about the network proxy.

  ldd -d -r /usr/bin/w3m
        linux-vdso.so.1 (0x00007ffcacdfa000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f008f1b8000)
        libgc.so.1 => /usr/lib/x86_64-linux-gnu/libgc.so.1 (0x00007f008ef48000)
        libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 
(0x00007f008ecde000)
        libcrypto.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 
(0x00007f008e87a000)
        libgpm.so.2 => /usr/lib/x86_64-linux-gnu/libgpm.so.2 
(0x00007f008e674000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x00007f008e448000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f008e0aa000)
        /lib64/ld-linux-x86-64.so.2 (0x000056338d052000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x00007f008de8d000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f008dc89000)

In the above I see that w3m is linking against libssl.so.1.0.2 =>
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 which is in the libssl1.0.2
package.

  dpkg -S /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
    libssl1.0.2:amd64: /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2

  apt-cache policy w3m
    w3m:
      Installed: 0.5.3-31
      Candidate: 0.5.3-31
      Version table:
     *** 0.5.3-31 500
            500 http://ftp.us.debian.org/debian sid/main amd64 Packages
            100 /var/lib/dpkg/status
         0.5.3-29 500
            500 http://ftp.us.debian.org/debian testing/main amd64 Packages

  apt-cache policy libssl1.0.2
    libssl1.0.2:
      Installed: 1.0.2j-1
      Candidate: 1.0.2j-1
      Version table:
     *** 1.0.2j-1 500
            500 http://ftp.us.debian.org/debian sid/main amd64 Packages
            500 http://ftp.us.debian.org/debian testing/main amd64 Packages
            100 /var/lib/dpkg/status

That is from Debian Sid today and fully updated.  I am hoing that your
system will show different version numbers.  I am in the US and using
the US mirror but I expect your mirror will be different which is
okay.  The versions of the packages should be the same however.

> > Looking at the handshake connecting to it I see that it only supports
> > TLS v1.1 and v1.2.  I am rather expect that your client might not be
> > supporting one of those two protocols.
> 
> I am running behind network-wide proxy, with auth. So I use delegate
> server to create a local proxy server that takes care of auth over the
> clients that do not support auth.
> 
> When I do `netstat -tc', what I see is multiple instances of
> `localhost:PORT' which happens to be my local PROXY_SERVER:PORT

The above waves flags and rings alarm bells in my head as likely to be
related to the problem because it is right in the middle of
everything.  This is a complicated process and I suspect it of being
the problem.

Unfortunately I don't know how to test your proxy.  Perhaps someone
else will know how to inspect it and test it for proper working.
Can you bypass your proxy and connect directly in order to test your
software configuration?

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]