Skip to content
This repository was archived by the owner on Nov 6, 2023. It is now read-only.

[VirusBulletin] Add new domain #4280

Merged
fuglede merged 2 commits into from
Mar 6, 2016
Merged

[VirusBulletin] Add new domain #4280

fuglede merged 2 commits into from
Mar 6, 2016

Conversation

@funkydude
Copy link
Contributor

@funkydude funkydude commented Mar 6, 2016

Resolves #4273

@fuglede
Copy link
Contributor

fuglede commented Mar 6, 2016

As mentioned in my comment in #4273, https://www.virusbtn.com seems problematic enough that it should not be used as a target for the forwarding.

Under normal circumstances, I would just point to #3107 and say that that would have caught the issue, but that does not actually seem to be the case: running fetch-test.sh rules/Virus_Bulletin.xml reveals no issues at all. While completely off-topic for this PR, this is rather confusing to me; https-everywhere-checker is based on pycurl, which does not like the site at all:

In [1]: import pycurl
In [2]: c = pycurl.Curl()
In [3]: c.setopt(c.URL, 'https://www.virusbtn.com')
In [4]: c.perform()
---------------------------------------------------------------------------
error                                     Traceback (most recent call last)
<ipython-input-4-ca1d06f79dfb> in <module>()
----> 1 c.perform()

error: (60, 'SSL certificate problem: unable to get local issuer certificate')

@fuglede
Copy link
Contributor

fuglede commented Mar 6, 2016

Ah, seeing the issue now; I hadn't noticed that https-everywhere-checker uses its own root certs, which for whatever reason have discrepancies from the ones that are shipped with Debian Jessie.

In [1]: import pycurl
In [2]: c = pycurl.Curl()
In [3]: c.setopt(c.URL, 'https://www.virusbtn.com/')
In [4]: c.setopt(c.CAPATH, '/home/fuglede/https-everywhere/test/rules/platform_certs/chromium')
In [5]: c.perform()
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
...

@jsha / @hiviah, this seems like a problem?

@funkydude
Copy link
Contributor Author

funkydude commented Mar 6, 2016

(I was about to blame your cURL version)

@fuglede Debian has had issues with certs since January, it works fine in other (newer) Linux distributions and in every browser. Here's an example: https://einstein.phys.uwm.edu/forum_thread.php?id=11768

@fuglede
Copy link
Contributor

fuglede commented Mar 6, 2016

Yeah, I came across https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812708. I didn't look into the background myself, but from that it looks like the removal is entirely on purpose. And probably warranted:

$ curl -s https://www.thawte.com/roots/thawte_Premium_Server_CA.pem | openssl x509 -noout -text | grep Public-Key
            Public-Key: (1024 bit)

Should we not expect such changes to diffuse into other stores? Mozilla's not a fan either.

@funkydude
Copy link
Contributor Author

funkydude commented Mar 6, 2016

@fuglede The certificates change (directly) isn't to blame, it's the use of an old OpenSSL. In the case of Ubuntu 14.04, they patched theirs. https://bugs.launchpad.net/debian/+source/ca-certificates/+bug/1551615

@fuglede
Copy link
Contributor

fuglede commented Mar 6, 2016

But as far as I can tell from https://www.ssllabs.com/ssltest/analyze.html?d=www.virusbtn.com, only 1 path is provided?

Edit: Ah, scratch that, the Qualys test gives a purely 2048 bit path; the site itself provides the complete chain (CA included, but with the CA cert listing the 1024 bit cert as its issuer).

@funkydude
Copy link
Contributor Author

funkydude commented Mar 6, 2016

@fuglede I don't know what's taking Debian so long to resolve a "grave" issue when it's already been resolved for Ubuntu, but I don't see the reason to change this rule to workaround it. This way when they kill off the old domain, people will actually update their bookmarks.

@hiviah
Copy link

hiviah commented Mar 6, 2016

@fuglede https-everywhere-checker used its own certs which should have been kept in sync with whatever Firefox has, plus transitive closure of intermediate certs for validating chains with missing intermediate certs. But the certs just got a few updates and haven't been kept up to date.

It might be better to use 'static_ca_path' option, point to copy of your distro's certs. IIRC c_rehash utility from openssl needs to be run in the dir beforehand, otherwise openssl won't be able to lookup the proper certs (maybe this have changed and you just point it at /etc/ssl/certs).

fuglede added a commit that referenced this pull request Mar 6, 2016
@fuglede
Merge pull request #4280 from funkydude/virusbtn
14955d3 
[VirusBulletin] Add new domain
@fuglede fuglede merged commit 14955d3 into EFForg:master Mar 6, 2016
@fuglede
Copy link
Contributor

fuglede commented Mar 6, 2016

@funkydude: Agreed on that.

@hiviah: Apologies for going completely off-topic in this PR, but why patch up the broken chains? We would want those to give errors since they will when browsers discover them in the wild.

@funkydude funkydude deleted the virusbtn branch March 6, 2016 18:07
@fuglede fuglede mentioned this pull request Mar 6, 2016
Open
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@funkydude @fuglede @hiviah