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: Thu, 20 Oct 2016 23:26:50 -0600
User-agent: NeoMutt/20161014 (1.7.1)

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



reply via email to

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