w3m SSL handling error

w3m SSL handling error

[B.V. Raghav]

Hi,

This may not be related to emacs, but if anybody here has solved this
issue, may definitely help

Opening a https URL on w3m errors out with:

   error:0906d06c:pem routines:pem_read_bio:no start line

Example: Open `https://www.emacswiki.org/'  and w3m fails.
`Something seems to be wrong with URL or this system.'

Then open xterm and `w3m https://www.emacswiki.org/'
The error message is
`0906d06c:pem routines:pem_read_bio:no start line'

Any suggestions?

r
-- 
Raghav

Re: w3m SSL handling error

[Bob Proulx]

B.V. Raghav wrote:
> This may not be related to emacs, but if anybody here has solved this
> issue, may definitely help

Since you see the problem directly from w3m in an xterm it isn't a
problem with emacs.  However it is an emacs wiki page and so that
gives some cover for it.

> Opening a https URL on w3m errors out with:
> 
>    error:0906d06c:pem routines:pem_read_bio:no start line
> 
> Example: Open `https://www.emacswiki.org/'  and w3m fails.
> `Something seems to be wrong with URL or this system.'

This works okay for me.  I cannot recreate the problem.

> Then open xterm and `w3m https://www.emacswiki.org/'
> The error message is
> `0906d06c:pem routines:pem_read_bio:no start line'
> 
> Any suggestions?

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.

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.

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.

Bob

Re: w3m SSL handling error

[Eli Zaretskii]

> Date: Mon, 17 Oct 2016 03:12:12 -0600
> From: Bob Proulx <bob@proulx.com>
> Cc: help-gnu-emacs@gnu.org
> 
> B.V. Raghav wrote:
> > This may not be related to emacs, but if anybody here has solved this
> > issue, may definitely help
> 
> Since you see the problem directly from w3m in an xterm it isn't a
> problem with emacs.

I concur.

> > Opening a https URL on w3m errors out with:
> > 
> >    error:0906d06c:pem routines:pem_read_bio:no start line
> > 
> > Example: Open `https://www.emacswiki.org/'  and w3m fails.
> > `Something seems to be wrong with URL or this system.'
> 
> This works okay for me.  I cannot recreate the problem.
> 
> > Then open xterm and `w3m https://www.emacswiki.org/'
> > The error message is
> > `0906d06c:pem routines:pem_read_bio:no start line'
> > 
> > Any suggestions?

This seems relevant:

  http://stackoverflow.com/questions/20837161/openssl-pem-routinespem-read-biono-start-linepem-lib-c703expecting-truste

Sounds like your certificate store need fixing.

Re: w3m SSL handling error

[B.V. Raghav]

Eli Zaretskii <eliz@gnu.org> writes:

> This seems relevant:
>
>   http://stackoverflow.com/questions/20837161/openssl-pem-routinespem-read-biono-start-linepem-lib-c703expecting-truste
>
> Sounds like your certificate store need fixing.
>

With the Stack Exchange pointer, I tried on the xterm:

----

$ openssl x509 -text -inform DER -in /etc/ssl/certs/ca-certificates.crt

unable to load certificate
139969532745368:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1197:
139969532745368:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:374:Type=X509

----
Can't figure out what is happening.

The most common solution suggested on SE, i.e. to change the
NEWLINE_ENCODING does not seem applicable here. It is unix line endings
on debian.

-- 
Raghav

तमसो मा ज्योतिर्गमय

Re: w3m SSL handling error

[B.V. Raghav]

Bob Proulx <bob@proulx.com> writes:

> B.V. Raghav wrote:
[...]
>> Opening a https URL on w3m errors out with:
>> 
>>    error:0906d06c:pem routines:pem_read_bio:no start line
>> 
>> Example: Open `https://www.emacswiki.org/'  and w3m fails.
>> `Something seems to be wrong with URL or this system.'
>
> This works okay for me.  I cannot recreate the problem.

Okay... As expected

>> Then open xterm and `w3m https://www.emacswiki.org/'
>> The error message is
>> `0906d06c:pem routines:pem_read_bio:no start line'
>> 
>> Any suggestions?
>
> 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. 

>
> 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.

> 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

I cant figure out how to find some meaningful information, as yourself.

r
-- 
Raghav

श्रद्धावाँल्लभते ज्ञानम् [https://duckduckgo.com/?q=श्रद्धावाँल्लभते+ज्ञानम्]

Re: w3m SSL handling error

[Bob Proulx]

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

Re: w3m SSL handling error

[B.V. Raghav]

Bob Proulx <bob@proulx.com> writes:

> [snip]

> 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.
>
> [snip]
>
> 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.
>
> [snip]
>
> 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.

The results are matching!

$ apt-cache policy w3m
w3m:
  Installed: 0.5.3-29
  Candidate: 0.5.3-29
  Version table:
 *** 0.5.3-29 500
        500 http://mirror.cse.iitk.ac.in/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status

except the w3m version 0.5.3-29 in my case vs 0.5.3-31 in your case. My
mirror does not have it updated as yet, I checked. But I think that's
okay.

$ apt-cache policy libssl1.0.2
libssl1.0.2:
  Installed: 1.0.2h-1
  Candidate: 1.0.2j-1
  Version table:
     1.0.2j-1 500
        500 http://mirror.cse.iitk.ac.in/debian stretch/main amd64 Packages
 *** 1.0.2h-1 100
        100 /var/lib/dpkg/status

$ 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

$ ldd -d -r /usr/bin/w3m
	linux-vdso.so.1 (0x00007fff49974000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe639383000)
	libgc.so.1 => /usr/lib/x86_64-linux-gnu/libgc.so.1 (0x00007fe639113000)
	libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 (0x00007fe638ea9000)
	libcrypto.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 (0x00007fe638a46000)
	libgpm.so.2 => /usr/lib/x86_64-linux-gnu/libgpm.so.2 (0x00007fe638840000)
	libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fe638615000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe638274000)
	/lib64/ld-linux-x86-64.so.2 (0x0000563c1eb9f000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe638057000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe637e52000)

> Can you bypass your proxy and connect directly in order to test your
> software configuration?

Yes. I did that:

$ http_proxy= w3m https://www.emacswiki.org/

But result is the same
SSL error: error:0906D06C:PEM routines:PEM_read_bio:no start line

Thanks for your support

r
-- 
Raghav

यस्य स्मरण मात्रेन जन्म संसार बन्धनात् विमुच्यते नमस्तस्मै विष्णवे प्रभविष्णवे
Salutations to the one, whose mere thought itself manifests in freedom
from bonds of the world of life.

Re: w3m SSL handling error

[Bob Proulx]

B.V. Raghav wrote:
> The results are matching!

Do they really match?  Your results say otherwise.

> $ apt-cache policy libssl1.0.2
> libssl1.0.2:
>   Installed: 1.0.2h-1
>   Candidate: 1.0.2j-1
>   Version table:
>      1.0.2j-1 500
>         500 http://mirror.cse.iitk.ac.in/debian stretch/main amd64 Packages
>  *** 1.0.2h-1 100
>         100 /var/lib/dpkg/status

Why aren't you using 1.0.2j-1?  That is a big difference!  

> > Can you bypass your proxy and connect directly in order to test your
> > software configuration?
> 
> Yes. I did that:
> 
> $ http_proxy= w3m https://www.emacswiki.org/
> 
> But result is the same
> SSL error: error:0906D06C:PEM routines:PEM_read_bio:no start line

I suggest upgrading your system and then trying again.

Bob

Re: w3m SSL handling error

[B.V. Raghav]

Bob Proulx <bob@proulx.com> writes:


> Why aren't you using 1.0.2j-1?  That is a big difference!  

My my! I totally missed that. In fact I apologise for not having
bothered about it!

# apt update && apt full-upgrade

$ 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://mirror.cse.iitk.ac.in/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status

It is not up to date. But the result is the same. Is there some cache
clear etc. required?

$ w3m https://www.emacswiki.org/
SSL error: error:0906D06C:PEM routines:PEM_read_bio:no start line

This is one more preposterous

$ gnutls-cli-debug www.emacswiki.org
GnuTLS debug client 3.5.4
Checking www.emacswiki.org:443
                             for SSL 3.0 (RFC6101) support... no
                        whether we need to disable TLS 1.2... yes
                        whether we need to disable TLS 1.1... yes
                        whether we need to disable TLS 1.0... yes
                        whether %NO_EXTENSIONS is required... yes
                               whether %COMPAT is required... yes
                             for TLS 1.0 (RFC2246) support...
Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1 and TLS 1.2 no

With other domains, I run the command
$ gnutls-cli --tofu domain.tld

and it succeeds in connecting with following Certificate[#] info:
 - subject `CN=domain.tld', issuer `C=IN,O=IIT Kanpur,OU=Computer
 Center,CN=ironport1.iitk.ac.in', serial ...

but fails to terminate `properly':

*** Fatal error: The TLS connection was non-properly terminated.
*** Server has terminated the connection abnormally.

Does this seem to have a bearing on my problem?

-- 
Raghav

Re: w3m SSL handling error

[Bob Proulx]

B.V. Raghav wrote:
> $ 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://mirror.cse.iitk.ac.in/debian stretch/main amd64 Packages
>         100 /var/lib/dpkg/status
> 
> It is not up to date. But the result is the same. Is there some cache
> clear etc. required?

That is up to date.  The "***" is pointing to what is installed.  That
is version 1.0.2j-1 which is from the stretch/main repository.
Previously that was listed as newer and not installed.  Now it is
listed as being installed.  All good.

> $ w3m https://www.emacswiki.org/
> SSL error: error:0906D06C:PEM routines:PEM_read_bio:no start line

Drat!  Was hoping that would solve the problem.  Since it needed to be
upgraded anyway.  The two version of packages you upgraded through
with that had a long list of CVEs fixed by the update.  It was needed
to be done anyway.

> This is one more preposterous
> 
> $ gnutls-cli-debug www.emacswiki.org
> GnuTLS debug client 3.5.4
> Checking www.emacswiki.org:443
>                              for SSL 3.0 (RFC6101) support... no
>                         whether we need to disable TLS 1.2... yes
>                         whether we need to disable TLS 1.1... yes
>                         whether we need to disable TLS 1.0... yes
>                         whether %NO_EXTENSIONS is required... yes
>                                whether %COMPAT is required... yes
>                              for TLS 1.0 (RFC2246) support...
> Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1 and TLS 1.2 no

That does not match what I see.  I have 3.5.5 from Sid but that seems
like a small difference.

                             for SSL 3.0 (RFC6101) support... no
                        whether we need to disable TLS 1.2... no
                        whether we need to disable TLS 1.1... no
                        whether we need to disable TLS 1.0... no

Something in your environment is intercepting your packets.  But you
said that much already in one of your emails that you were forced to
go through a proxy of some type.

> With other domains, I run the command
> $ gnutls-cli --tofu domain.tld
> 
> and it succeeds in connecting with following Certificate[#] info:
>  - subject `CN=domain.tld', issuer `C=IN,O=IIT Kanpur,OU=Computer
>  Center,CN=ironport1.iitk.ac.in', serial ...

It seems to me that you are living in an environment that tries to
MITM man-in-the-middle all of your traffic to the outside world.  For
http this is typical.  No real problem.  As long as the proxy is
operating correctly.

For https this is very problematic.  The MITM appears to be an
attacker.  Which they are since they are.  The only way this is done
is by having the MITM use their own certificate and having all clients
trust that certificate.  This is typically within the rights of
companies at work when you are using work equipment that the company
owns.  It is the only way the company can inspect what you are doing.
This is a removal of your privacy.  But if it is the company euipment
and you are using it on work time then perhaps they have the right to
do so.  In which case I would NOT use company equipment for anything
other than strictly work related business.  Nothing more.  Do all
personal and non-work anything elsewhere on my own non-work equipment.

> but fails to terminate `properly':
> 
> *** Fatal error: The TLS connection was non-properly terminated.
> *** Server has terminated the connection abnormally.
> 
> Does this seem to have a bearing on my problem?

Yes.  I don't understand your environment but it seems you are in a
captured network where they are trying to prevent you from connecting
directly through https to the outside world.  Your errors are an
indication that the network restrictions are restricting you.  And if
you were to get it to work then you should know that someone is seeing
every byte of data that you are transmitting and that your "encrypted"
https connection is being observed by a MITM.  Personally I can reject
such an environment.  Whether you need it for your job or not is
something you will need to decide.

Do you have outbound ssh access outside of your network?  To another
machine that is outside of this control?  If so then you can set up a
vpn / tunnel between your client and this outside server.  You could
use it to proxy through to the outside world.  There are several good
ways to do this.  "sshuttle" is one good way.  You should be able to
"apt-get install sshuttle" it.

Bob