SSL error in (e)links(2) web browers

[Marko Randjelovic]

When I use links2 or elinks web browsers on some websites when https is
protocol I get error "Error loading ... SSL error" and page is not
loaded.

--
http://markorandjelovic.hopto.org

One should not be afraid of humans.
Well, I am not afraid of humans, but of what is inhuman in them.
Ivo Andric, "Signs near the travel-road"


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/20150205134...@eunet.rs

[Bob Proulx]

Marko Randjelovic wrote:
> When I use links2 or elinks web browsers on some websites when https is
> protocol I get error "Error loading ... SSL error" and page is not
> loaded.

This is probably due to the combination of supported protocols. When
negotiating the encryption it may not have an overlapping set that
works. For example if the site is old and stale and only offers SSLv3
which has been deprecated then a browser with SSLv3 disabled for
security will not be able to connect to it.

Do you have an example https page so that we could examine the offered
protocols and compare against those supported by those browsers?

Bob

[Marko Randjelovic]

https://webmail.sbb.rs/?r=s

[Bob Proulx]

Marko Randjelovic wrote:
> When I use links2 or elinks web browsers on some websites when https is

> https://webmail.sbb.rs/

elinks does not complain about the site. This may be a bug in elinks
as it may be ignoring an error.

I am able to recreate that problem using links2. And also curl and
wget. elinks gives me this error:

Verification failure: unable to get local issuer certificate

curl produces:

$ curl https://webmail.sbb.rs/
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

wget produces:

$ wget -O- https://webmail.sbb.rs/
--2015-02-06 23:01:30-- https://webmail.sbb.rs/
Resolving webmail.sbb.rs (webmail.sbb.rs)... 89.216.2.57
Connecting to webmail.sbb.rs (webmail.sbb.rs)|89.216.2.57|:443... connected.
ERROR: The certificate of ‘webmail.sbb.rs’ is not trusted.
ERROR: The certificate of ‘webmail.sbb.rs’ hasn't got a known issuer.

With three out of three complaining about the site I diagnose the
problem to be the site and not your browsers.

When I probe using:

openssl s_client -connect webmail.sbb.rs:443

It shows me this information:

Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=webmail.sbb.rs
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2

I think that is insufficient. I am not an expert and hopefully
someone else will jump in with better diagnosis but I believe the site
itself does not include enough of the certificate chain back to the CA
root and therefore the certificate does not verify. When I used
PositiveSSL previously there was an additional
"AddTrustExternalCARoot" certificate which was provided too.

In the browser cases that do accept it the browser must already have
the chain available to it. If the browser has access to the
intermediate security certificates already then it would be possible
to verify it back to the CA root. Firefox and Chromium both verify
the certificate successfully. Therefore they must already have the
intermediate certs available.

In summary I think the site itself provides insufficient certificate
information. It needs to provide the intermediate security chain.

Anyone else on the list have a better diagnosis?

Bob

[Marko Randjelovic]

On Fri, 6 Feb 2015 23:08:29 -0700
Bob Proulx <b...@proulx.com> wrote:

> Marko Randjelovic wrote:
> > When I use links2 or elinks web browsers on some websites when https is
> > https://webmail.sbb.rs/
>
> elinks does not complain about the site. This may be a bug in elinks
> as it may be ignoring an error.
>
> I am able to recreate that problem using links2. And also curl and
> wget. elinks gives me this error:
>
> Verification failure: unable to get local issuer certificate

When I use elinks (Squeeze) with

set connection.ssl.cert_verify = 1

$ elinks -dump https://webmail.sbb.rs/
ELinks: SSL error

Without:

$ elinks -dump https://webmail.sbb.rs/
SBB

Prijava

Korisničko ime [1]_____________________
Lozinka [2]_____________________
[3]Captcha Verification Image [4]osveži
Unesite kod [5]_____________________
[6]Prijava
Ukoliko nemate kreiran SBB webmail nalog, možete ga kreirati na portalu
[7]MojSBB.
Copyright © 2002 - 2014, SBB. All rights reserved.

References

Visible links
4. javascript:void(0);
7. https://www.mojsbb.rs/sbb_home/faces/cms/

[Darac Marjal]

When testing an SSL site, I find the SSLLabs test to be nice and clear:

https://www.ssllabs.com/ssltest/analyze.html?d=webmail.sbb.rs&hideResults=on&latest

Under "Certification Paths", you see how the test navigates from the
provided certificate to something that it already trusts. The "Extra
Download" warning means that it's been able to identify the signer of
the certificate, but has had to download that in order to find the next
item in the chain.

To solve this, it is usual to create a file like "cat mysite.crt
intermediate.crt > mysite-bundle.crt" and use THAT bundle as the
certificate file for your site. This provides both certificates to the
browser and speeds up verification.

Note, also, the rather large number of RED text items on that test,
though.

>
> Bob

[Bob Proulx]

Marko Randjelovic wrote:
> When I use elinks (Squeeze) with
>
> set connection.ssl.cert_verify = 1
>
> $ elinks -dump https://webmail.sbb.rs/
> ELinks: SSL error

Ah! Very good. That explains why it didn't complain for me.

connection.ssl.cert_verify [0|1] (default: 0)
Verify the peer's SSL certificate. Note that this needs
extensive configuration of OpenSSL by the user.

I am sorry but I do not know how to improve the situation for you
beyond having the web site include the glue certificates. I don't
know why Chromium and Firefox approve of the certificate chain.

Hopefully someone else will have a better answer. Sorry.

Bob