EFF Certificate change disables update check

[dadoug]

The issue

"Check for update" failed when executed both from the web interface and the (ssh) command-line:

root@cerowrt:~# /lib/update/update.py check
Advise-only mode (checking whether update is available)
Getting update metadata...
(60, 'SSL certificate problem: unable to get local issuer certificate')
Failed to download update metadata

A local fix

I downloaded a new ca-cert bundle, cacert.pem, and placed it in /etc/ssl/certs/cacert.pem on the router. I then changed line number 39 in /lib/update/update.py to point to the new ca-cert bundle and was able to successfully run an update check from both the web interface and the command-line.

My Trouble-shooting Process

Is there a problem with /etc/ssl/certs/StartCom_Certification_Authority.crt?
I've found zero bit-wise difference between this file on the router and copies obtained elsewhere. So, ... no? It should be noted, however, that I am no expert when it comes to CA-certs, so this probably an avenue worth double-checking.

Is s.eff.org presenting a new/different cert?
Good question. I don't know the answer, but it's probably easy for a skilled someone to check. EDIT: Yep, this is the cause of the issue.

What about bare curling?
I noticed that bare curl also fails to retrieve the signed metadata. To wit,
root@cerowrt:~# curl -v --socks4a localhost:9050 --cacert /etc/ssl/certs/StartCom_Certification_Authority.crt https://s.eff.org /files/openwireless/update.json.asc
gives:

* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
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" 
 ...

I tried many permutations and combinations of bare curling, to no avail:

• Removing the --socks4a localhost:9050 option
• Removing the --cacert ... option
• Disabling tor on the router
• Removing any/all tor related iptables from /etc/firewall.user on the router
• Adding the -k flag to curl "works", of course, but this is cheating big-time!

My Version Information

root@cerowrt:~# cat /etc/openwrt_*
DISTRIB_ID="MVP-EA"
DISTRIB_RELEASE="3.10.50-1"
DISTRIB_TAINTS="no-all busybox"
DISTRIB_CODENAME="b7eafbe"
DISTRIB_TARGET="ar71xx/generic"
DISTRIB_REVISION="r41861"
DISTRIB_RELEASE_DATE="1420850891"
DISTRIB_DESCRIPTION="MVP-EA  b7eafbe  r41861  3.10.50-1"
3.10.50-1

[jsha]

The problem is that s.eff.org switched to use DigiCert in the last week. We need to add the appropriate certificate to /etc/ on the router image, or probably the full cacert list (since the downloaded file is verified using PGP anyhow).

[dadoug]

After all the trouble-shooting, I suspected that this was the problem. It's a relief to hear that all my tinkering on the router didn't break the thing.

So, if I understand correctly, we are now in a situation where we can verify but not actually retrieve update metadata. Is it now true that no one can update their router, even if simply in order to obtain the new EFF cert?! This sounds like it could be a notable hiccup for the project, requiring us to push some kind of manual upgrade instructions. There are obvious ways of doing so, but none of them involve an easy "push this button" solution of the type that is so crucial for casual users, since the "button" is effectively broken. Perhaps we can, in the future, retrieve the update metadata in the clear (over Tor) since, as you point out, "the downloaded file is verified using PGP anyhow."

Alas, such is life in this tangled web of trust we weave ...