bug#16791: w3m fails to do any SSL certificate checking

bug#16791: w3m fails to do any SSL certificate checking

[Mark H Weaver]

In Guix, neither w3m nor emacs-w3m warn me when I visit an https URL
that uses a server certificate that is both self-signed and expired.
To make matters worse, if I ask for page information (with the '=' key),
it tells me that the certificate is valid.

On Debian, both w3m and emacs-w3m inform me when an SSL certificate is
invalid in some way, e.g. if it's expired or not signed by a certificate
authority in my trust store.

      Mark

bug#16791: w3m fails to do any SSL certificate checking

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

On Tue, Feb 18, 2014 at 03:58:21AM -0500, Mark H Weaver wrote:
> In Guix, neither w3m nor emacs-w3m warn me when I visit an https URL
> that uses a server certificate that is both self-signed and expired.
> To make matters worse, if I ask for page information (with the '=' key),
> it tells me that the certificate is valid.
> 
> On Debian, both w3m and emacs-w3m inform me when an SSL certificate is
> invalid in some way, e.g. if it's expired or not signed by a certificate
> authority in my trust store.

w3m can be configured to not verify ssl certificates; but this is not the
case for us. I checked that if the server presents a certificate for a
different domain, there is a message:
   Bad cert ident xxx from yyy: accept? (y/n)

However, the debian w3m asks whether a self-signed certificate should be
accepted. Among the about 30 patches in debian for w3m, the name of only one
is related to ssl; I am attaching it, but it does not seem related to our
problem.

Andreas


[-- Attachment #2: 260_openssl.patch --]
[-- Type: text/plain, Size: 991 bytes --]

Subject: OpenSSL issues
Author: Cristian Rodriguez <crrodriguez@opensuse.org>
Origin: https://build.opensuse.org/request/show/141054
Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2012-4929

  Mon Nov 12 18:26:45 UTC 2012 - crrodriguez@opensuse.org
  - Due to the "CRIME attack" (CVE-2012-4929) HTTPS clients
    that negotiate TLS-level compression can be abused for
    MITM attacks. (w3m-openssl.patch) 
  - Use SSL_MODE_RELEASE_BUFFERS if available .

--- w3m.orig/url.c
+++ w3m/url.c
@@ -337,7 +337,15 @@ openSSLHandle(int sock, char *hostname,
 	    if (strchr(ssl_forbid_method, 'T'))
 		option |= SSL_OP_NO_TLSv1;
 	}
+#ifdef SSL_OP_NO_COMPRESSION
+	option |= SSL_OP_NO_COMPRESSION;
+#endif
 	SSL_CTX_set_options(ssl_ctx, option);
+
+#ifdef SSL_MODE_RELEASE_BUFFERS
+	SSL_CTX_set_mode (ssl_ctx, SSL_MODE_RELEASE_BUFFERS);
+#endif
+
 #ifdef USE_SSL_VERIFY
 	/* derived from openssl-0.9.5/apps/s_{client,cb}.c */
 #if 1				/* use SSL_get_verify_result() to verify cert */

bug#16791: w3m fails to do any SSL certificate checking

[Andreas Enge]

I wondered whether the problem lied in our openssl. It does not seem so.
"openssl verify cert.pem" on my problematic certificate does print as expected:
  error 18 at 0 depth lookup:self signed certificate
  error 10 at 0 depth lookup:certificate has expired

Andreas

bug#16791: w3m fails to do any SSL certificate checking

[Leo Famulari]

I looked into how Debian does it. They bundle a configuration file that
sets the correct options.

If you download the "debian" file [0], which includes all of their
packaging for w3m, you can view the file at 'debian/w3mconfig'.

The relevant option is "ssl_verify_server", and it must be set to "1" in
order for w3m to perform verification.

Example with a domain whose certificate is expired:
$ w3m -o ssl_verify_server 1 fmrl.me

Do we ever bundle configuration files in this manner?

Can a wrapper set command-line variables?

I will investigate whether these options can be set at build time.

I don't think we should ship a browser in this state, even if users are
able to configure it properly after installation. w3m is used by other
programs like mutt to render html "under the hood".

[0]
http://http.debian.net/debian/pool/main/w/w3m/w3m_0.5.3-26.debian.tar.xz

bug#16791: w3m fails to do any SSL certificate checking

[Leo Famulari]

On Sat, Jan 02, 2016 at 09:20:30PM -0500, Leo Famulari wrote:
> I looked into how Debian does it. They bundle a configuration file that
> sets the correct options.
> 
> If you download the "debian" file [0], which includes all of their
> packaging for w3m, you can view the file at 'debian/w3mconfig'.
> 
> The relevant option is "ssl_verify_server", and it must be set to "1" in
> order for w3m to perform verification.
> 
> Example with a domain whose certificate is expired:
> $ w3m -o ssl_verify_server 1 fmrl.me
> 
> Do we ever bundle configuration files in this manner?
> 
> Can a wrapper set command-line variables?
> 
> I will investigate whether these options can be set at build time.
> 
> I don't think we should ship a browser in this state, even if users are
> able to configure it properly after installation. w3m is used by other
> programs like mutt to render html "under the hood".
> 
> [0]
> http://http.debian.net/debian/pool/main/w/w3m/w3m_0.5.3-26.debian.tar.xz
> 

This particular issue was resolved in October 2014 in this commit
(tested):
http://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=05503271dfd26b843589dece0da35ba5d7d38654

It looks like there is a lot of development activity happening within
Debian, beyond simple packaging [0]. Even what seems to be the official
SourceForge page seems to be tracking the Debian work [1].

The Debian developers are regularly issuing release tags but not release
tarballs. I built from the latest one and it seems to work.

I think we should use the Debian repo as the source for our w3m package.
What does everyone else think?

[0]
http://anonscm.debian.org/cgit/collab-maint/w3m.git/

[1]
http://sourceforge.net/p/w3m/patches/71/

bug#16791: w3m fails to do any SSL certificate checking

[Leo Famulari]

On Mon, Jan 04, 2016 at 01:19:32AM -0500, Leo Famulari wrote:
> On Sat, Jan 02, 2016 at 09:20:30PM -0500, Leo Famulari wrote:
> > I looked into how Debian does it. They bundle a configuration file that
> > sets the correct options.
> > 
> > If you download the "debian" file [0], which includes all of their
> > packaging for w3m, you can view the file at 'debian/w3mconfig'.
> > 
> > The relevant option is "ssl_verify_server", and it must be set to "1" in
> > order for w3m to perform verification.
> > 
> > Example with a domain whose certificate is expired:
> > $ w3m -o ssl_verify_server 1 fmrl.me
> > 
> > Do we ever bundle configuration files in this manner?
> > 
> > Can a wrapper set command-line variables?
> > 
> > I will investigate whether these options can be set at build time.
> > 
> > I don't think we should ship a browser in this state, even if users are
> > able to configure it properly after installation. w3m is used by other
> > programs like mutt to render html "under the hood".
> > 
> > [0]
> > http://http.debian.net/debian/pool/main/w/w3m/w3m_0.5.3-26.debian.tar.xz
> > 
> 
> This particular issue was resolved in October 2014 in this commit
> (tested):
> http://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=05503271dfd26b843589dece0da35ba5d7d38654
> 
> It looks like there is a lot of development activity happening within
> Debian, beyond simple packaging [0]. Even what seems to be the official
> SourceForge page seems to be tracking the Debian work [1].
> 
> The Debian developers are regularly issuing release tags but not release
> tarballs. I built from the latest one and it seems to work.
> 
> I think we should use the Debian repo as the source for our w3m package.
> What does everyone else think?

I wanted to "tighten" w3m's SSL configuration in general, and found that
the Debian developers have already disabled SSLv2 and SSLv3 [0] and some
insecure ciphers [1].

[0]
http://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=05503271dfd26b843589dece0da35ba5d7d38654
http://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=1aace42d026c7df31c4762ef1095ce83450916fc

[1]
http://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=3335b5e824eecf70055af985b12c60651787fbfc

> 
> [0]
> http://anonscm.debian.org/cgit/collab-maint/w3m.git/
> 
> [1]
> http://sourceforge.net/p/w3m/patches/71/
> 
> 
> 

bug#16791: w3m fails to do any SSL certificate checking

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Sat, Jan 02, 2016 at 09:20:30PM -0500, Leo Famulari wrote:
>> I looked into how Debian does it. They bundle a configuration file that
>> sets the correct options.
>> 
>> If you download the "debian" file [0], which includes all of their
>> packaging for w3m, you can view the file at 'debian/w3mconfig'.
>> 
>> The relevant option is "ssl_verify_server", and it must be set to "1" in
>> order for w3m to perform verification.
>> 
>> Example with a domain whose certificate is expired:
>> $ w3m -o ssl_verify_server 1 fmrl.me
>> 
>> Do we ever bundle configuration files in this manner?
>> 
>> Can a wrapper set command-line variables?
>> 
>> I will investigate whether these options can be set at build time.
>> 
>> I don't think we should ship a browser in this state, even if users are
>> able to configure it properly after installation. w3m is used by other
>> programs like mutt to render html "under the hood".
>> 
>> [0]
>> http://http.debian.net/debian/pool/main/w/w3m/w3m_0.5.3-26.debian.tar.xz
>> 
>
> This particular issue was resolved in October 2014 in this commit
> (tested):
> http://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=05503271dfd26b843589dece0da35ba5d7d38654

Looks like applying this patch would fix the bug right away, right?

> It looks like there is a lot of development activity happening within
> Debian, beyond simple packaging [0]. Even what seems to be the official
> SourceForge page seems to be tracking the Debian work [1].
>
> The Debian developers are regularly issuing release tags but not release
> tarballs. I built from the latest one and it seems to work.
>
> I think we should use the Debian repo as the source for our w3m package.
> What does everyone else think?

Unless upstream is really dead, we should track it.  I think it’s not
the distro’s job to do non-trivial development.

What about using the latest upstream tarball, along with the patch
above and probably the one that disables SSLv{2,3}?

Thanks,
Ludo’.

bug#16791: w3m fails to do any SSL certificate checking

[Leo Famulari]

On Tue, Jan 05, 2016 at 12:35:57AM +0100, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> 
> > On Sat, Jan 02, 2016 at 09:20:30PM -0500, Leo Famulari wrote:
> >> I looked into how Debian does it. They bundle a configuration file that
> >> sets the correct options.
> >> 
> >> If you download the "debian" file [0], which includes all of their
> >> packaging for w3m, you can view the file at 'debian/w3mconfig'.
> >> 
> >> The relevant option is "ssl_verify_server", and it must be set to "1" in
> >> order for w3m to perform verification.
> >> 
> >> Example with a domain whose certificate is expired:
> >> $ w3m -o ssl_verify_server 1 fmrl.me
> >> 
> >> Do we ever bundle configuration files in this manner?
> >> 
> >> Can a wrapper set command-line variables?
> >> 
> >> I will investigate whether these options can be set at build time.
> >> 
> >> I don't think we should ship a browser in this state, even if users are
> >> able to configure it properly after installation. w3m is used by other
> >> programs like mutt to render html "under the hood".
> >> 
> >> [0]
> >> http://http.debian.net/debian/pool/main/w/w3m/w3m_0.5.3-26.debian.tar.xz
> >> 
> >
> > This particular issue was resolved in October 2014 in this commit
> > (tested):
> > http://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=05503271dfd26b843589dece0da35ba5d7d38654
> 
> Looks like applying this patch would fix the bug right away, right?
> 
> > It looks like there is a lot of development activity happening within
> > Debian, beyond simple packaging [0]. Even what seems to be the official
> > SourceForge page seems to be tracking the Debian work [1].
> >
> > The Debian developers are regularly issuing release tags but not release
> > tarballs. I built from the latest one and it seems to work.
> >
> > I think we should use the Debian repo as the source for our w3m package.
> > What does everyone else think?
> 
> Unless upstream is really dead, we should track it.  I think it’s not
> the distro’s job to do non-trivial development.

I'm trying to reach the people that used to work on w3m to ask if they
are still active or if they have abandoned it. They haven't been around
in ~4 years from what I have seen.

> 
> What about using the latest upstream tarball, along with the patch
> above and probably the one that disables SSLv{2,3}?

I'll try that.

> 
> Thanks,
> Ludo’.

bug#16791: w3m fails to do any SSL certificate checking

[Leo Famulari]

On Tue, Jan 05, 2016 at 11:32:14AM -0500, Leo Famulari wrote:
> On Tue, Jan 05, 2016 at 12:35:57AM +0100, Ludovic Courtès wrote:
> > Leo Famulari <leo@famulari.name> skribis:
> > 
> > > On Sat, Jan 02, 2016 at 09:20:30PM -0500, Leo Famulari wrote:
> > >> I looked into how Debian does it. They bundle a configuration file that
> > >> sets the correct options.
> > >> 
> > >> If you download the "debian" file [0], which includes all of their
> > >> packaging for w3m, you can view the file at 'debian/w3mconfig'.
> > >> 
> > >> The relevant option is "ssl_verify_server", and it must be set to "1" in
> > >> order for w3m to perform verification.
> > >> 
> > >> Example with a domain whose certificate is expired:
> > >> $ w3m -o ssl_verify_server 1 fmrl.me
> > >> 
> > >> Do we ever bundle configuration files in this manner?
> > >> 
> > >> Can a wrapper set command-line variables?
> > >> 
> > >> I will investigate whether these options can be set at build time.
> > >> 
> > >> I don't think we should ship a browser in this state, even if users are
> > >> able to configure it properly after installation. w3m is used by other
> > >> programs like mutt to render html "under the hood".
> > >> 
> > >> [0]
> > >> http://http.debian.net/debian/pool/main/w/w3m/w3m_0.5.3-26.debian.tar.xz
> > >> 
> > >
> > > This particular issue was resolved in October 2014 in this commit
> > > (tested):
> > > http://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=05503271dfd26b843589dece0da35ba5d7d38654
> > 
> > Looks like applying this patch would fix the bug right away, right?
> > 
> > > It looks like there is a lot of development activity happening within
> > > Debian, beyond simple packaging [0]. Even what seems to be the official
> > > SourceForge page seems to be tracking the Debian work [1].
> > >
> > > The Debian developers are regularly issuing release tags but not release
> > > tarballs. I built from the latest one and it seems to work.
> > >
> > > I think we should use the Debian repo as the source for our w3m package.
> > > What does everyone else think?
> > 
> > Unless upstream is really dead, we should track it.  I think it’s not
> > the distro’s job to do non-trivial development.
> 
> I'm trying to reach the people that used to work on w3m to ask if they
> are still active or if they have abandoned it. They haven't been around
> in ~4 years from what I have seen.
> 
> > 
> > What about using the latest upstream tarball, along with the patch
> > above and probably the one that disables SSLv{2,3}?
> 
> I'll try that.

Mark, can you check if commit 62339e2d49 fixes this bug for you?

> 
> > 
> > Thanks,
> > Ludo’.
> 
> 
> 

bug#16791: w3m fails to do any SSL certificate checking

[Leo Famulari]

On Thu, Jan 07, 2016 at 11:55:12PM -0500, Leo Famulari wrote:
> On Tue, Jan 05, 2016 at 11:32:14AM -0500, Leo Famulari wrote:
> > On Tue, Jan 05, 2016 at 12:35:57AM +0100, Ludovic Courtès wrote:

[...]

> > > What about using the latest upstream tarball, along with the patch
> > > above and probably the one that disables SSLv{2,3}?
> > 
> > I'll try that.
> 
> Mark, can you check if commit 62339e2d49 fixes this bug for you?

I believe this bug is fixed. Please re-open if that is not the case.