search

Hexxeh / rpi-update

An easier way to update the firmware of your Raspberry Pi
MIT License
1.94k stars 232 forks source link

Certificates issue with wget #65

Closed shrx closed 10 years ago

shrx commented 11 years ago

output of running sudo rpi-update:

 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS
 *** Performing self-update
--2013-01-28 21:20:16--  https://github.com/Hexxeh/rpi-update/raw/master/rpi-update
Resolving github.com... 207.97.227.239
Connecting to github.com|207.97.227.239|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.github.com/Hexxeh/rpi-update/master/rpi-update [following]
--2013-01-28 21:20:16--  https://raw.github.com/Hexxeh/rpi-update/master/rpi-update
Resolving raw.github.com... 199.27.77.193
Connecting to raw.github.com|199.27.77.193|:443... connected.
ERROR: certificate common name `*.a.ssl.fastly.net' doesn't match requested host name `raw.github.com'.
To connect to raw.github.com insecurely, use `--no-check-certificate'.
 !!! Failed to download update for rpi-update!
 !!! Make sure you have ca-certificates installed and that the time is set correctly
popcornmix commented 11 years ago

Did you read the readme? https://github.com/Hexxeh/rpi-update

shrx commented 11 years ago

Yes, this happened suddenly after almost a year of running this script with no problems. I did not touch the certificates for some time now, so the issue must be elsewhere. Also the time is synchronised. edit: also, if I run the script with UPDATE_SELF=0, it works.

popcornmix commented 11 years ago

Does wget https://github.com/Hexxeh/rpi-update/raw/master/rpi-update work? (it does currently for me)

Can you wget from any https page?

skgsergio commented 11 years ago

Running with UPDATE_SELF=0 don't trigger wget that's why it works. On the other hand, is not the date problem @popcornmix have a look to this:

ERROR: certificate common name *`.a.ssl.fastly.net' doesn't match requested host name `raw.github.com'**.

I saw, the cdn that GitHub uses is fastly and for some unknown reason couldn't identify the domain you were accessing (raw.github.com) so the server gave you the fastly generic ssl certificate causing wget fail because is not the site it asked for... Why the server is not identifying what domain is your wget is asking for? I don't know... can be a proxy forwarding bad info, can be a temporal issue, can be a bug on wget... don't really know...

If you don't have proxys I think that the issue will disappear like it appeared...

shrx commented 11 years ago

@popcornmix I get the same error with your suggested command. Downloading an image from https wikipedia works:

wget https://upload.wikimedia.org/wikipedia/commons/thumb/3/32/Koningin_Beatrix_in_Vries.jpg/100px-Koningin_Beatrix_in_Vries.jpg
--2013-01-28 22:45:45--  https://upload.wikimedia.org/wikipedia/commons/thumb/3/32/Koningin_Beatrix_in_Vries.jpg/100px-Koningin_Beatrix_in_Vries.jpg
Resolving upload.wikimedia.org... 91.198.174.234, 2620:0:862:ed1a::b
Connecting to upload.wikimedia.org|91.198.174.234|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9016 (8.8K) [image/jpeg]
Saving to: `100px-Koningin_Beatrix_in_Vries.jpg'

100%[======================================>] 9,016       --.-K/s   in 0.002s  

2013-01-28  22:45:45 (5.52 MB/s) - `100px-Koningin_Beatrix_in_Vries.jpg' saved [9016/9016]

I don't use a proxy.

skgsergio commented 11 years ago

Very funny, really... Have a look to this: screenshoot The failed download is from my dedicated server hosted by OVH at France. The successful download is from my work at Spain (Technical University of Madrid - RedIRIS network)... Also form my house works without problems...

So is not your issue, seems that GitHub's CDN it's failing...

shrx commented 11 years ago

Interesting. So I should just wait till they fix it.

licaon-kter commented 11 years ago

I had some issues a few days ago too, not certificate related ( https://github.com/Hexxeh/rpi-firmware/issues/7 ) but mostly pointing out that github itself seems at fault.

popcornmix commented 11 years ago

Is this working again?

shrx commented 11 years ago

No, still the same error.

shrx commented 11 years ago

Update: two-raspberries On the left is my main raspberry pi with the non-working script. On the right is the secondary raspberry pi - the script works. Both are connected to the internet through the same router. The difference between them is that the non-working script is on the soft-float debian, the working is on hard-float. Could this be the problem?

metachris commented 11 years ago

To solve this issue, you could just add --no-check-certificate as parameter for wget. I believe the security risk by not checking the certs is neglectible since we know the link refers to the correct filename and just assume Github has not been hacked.

shrx commented 11 years ago

Another update: I spent several hours building the latest version of wget (1.14) and its dependencies, but it was worth it. The newly built version works with no errors.

popcornmix commented 11 years ago

So do you believe it is a bug in older version of wget? May be worth flagging the issue on raspbian section of forum for plugwash to consider updating.

skgsergio commented 11 years ago

After digging the internet I saw that wget debian packages prior to 1.14-1 don't have SNI [1] support so the webserver don't know which ssl certificate needs to use.

I've checked and my failing machine has 1.12 and the working machine 1.14 :)

For more info: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653267

[1] http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

shrx commented 11 years ago

I've also received reply from github support:

This is a bug in older versions of wget where it does not correctly parse the full list of subjectAlternateNames in the certificate. If you open the cert, you will see that raw.github.com is listed, but it's rather far down on the list. The only recommendation I have at this time is to try a more recent version of wget, or consider switching to cURL.

So someone should put the 1.14 version of wget on apt-get repositories for the old soft-float debian, so people could update it easily without compiling everything. I don't know how to do it, but I can upload the compiled files if it helps. (I'd need to know which files need to be uploaded too.)

popcornmix commented 11 years ago

So someone should put the 1.14 version of wget on apt-get repositories for the old soft-float debian, so people could update it easily without compiling everything.

The soft float debian should be the standard debian wheezy packages. Have you run sudo apt-get update && sudo apt-get upgrade ?

metachris commented 11 years ago

Good job on finding the root cause. Currently the standard wget version in the wheezy repos is 1.12 (http://packages.debian.org/stable/wget). A quick fix for the meantime could be to add --no-check-certificate as parameter for wget in the rpi-update.sh script.

popcornmix commented 11 years ago

wheezy is not stable though: http://packages.debian.org/wheezy/wget shows wget at 1.13.4-3.

Which is newer than my Ubuntu 11.10 machine...

metachris commented 11 years ago

Good point, I used the wrong link (first result habit on Google). Here's the overview: http://packages.debian.org/search?keywords=wget

shrx commented 11 years ago

This is the debian I have:

lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 6.0.6 (squeeze) Release: 6.0.6 Codename: squeeze

popcornmix commented 11 years ago

@shrx That is very old. There is a soft float version of wheezy available for download if you need soft float (although hard float would be recommened).

shrx commented 11 years ago

Yeah, I got my raspberry pi in may 2012, and wheezy came out much later, when I already got my entire system set up and running. So I decided to not upgrade and deal with everything again. And afaik I can't just use wheezy packages on squeeze?

Pitel commented 10 years ago

I just got this errors, wget https://github.com/Hexxeh/rpi-update/raw/master/rpi-update doesn't work. It worked fine couple of days ago.

--2014-03-20 09:06:47--  https://github.com/Hexxeh/rpi-update/raw/master/rpi-update
Resolving github.com (github.com)... 192.30.252.131
Connecting to github.com (github.com)|192.30.252.131|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/Hexxeh/rpi-update/master/rpi-update [following]
--2014-03-20 09:06:52--  https://raw.githubusercontent.com/Hexxeh/rpi-update/master/rpi-update
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.31.17.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.31.17.133|:443... connected.
GnuTLS: A TLS warning alert has been received.
Unable to establish SSL connection.
GNU Wget 1.13.4 built on linux-gnueabihf.

+digest +https +ipv6 +iri +large-file +nls -ntlm +opie +ssl/gnutls 

Wgetrc: 
    /etc/wgetrc (system)
Locale: /usr/share/locale 
Compile: gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/etc/wgetrc" 
    -DLOCALEDIR="/usr/share/locale" -I. -I../lib -I../lib 
    -D_FORTIFY_SOURCE=2 -Iyes/include -g -O2 -fstack-protector 
    --param=ssp-buffer-size=4 -Wformat -Werror=format-security 
    -DNO_SSLv2 -D_FILE_OFFSET_BITS=64 -g -Wall 
Link: gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
    -Werror=format-security -DNO_SSLv2 -D_FILE_OFFSET_BITS=64 -g -Wall 
    -Wl,-z,relro -Lyes/lib -lgnutls -lgcrypt -lgpg-error -lz -lidn -lrt 
    ftp-opie.o gnutls.o ../lib/libgnu.a 

Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://www.gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Originally written by Hrvoje Niksic <hniksic@xemacs.org>.
Please send bug reports and questions to <bug-wget@gnu.org>.
popcornmix commented 10 years ago

It is working for me at the moment:

pi@raspberrypi:~ $ wget https://github.com/Hexxeh/rpi-update/raw/master/rpi-update
--2014-03-20 14:49:59--  https://github.com/Hexxeh/rpi-update/raw/master/rpi-update
Resolving github.com (github.com)... 192.30.252.129
Connecting to github.com (github.com)|192.30.252.129|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/Hexxeh/rpi-update/master/rpi-update [following]
--2014-03-20 14:50:05--  https://raw.githubusercontent.com/Hexxeh/rpi-update/master/rpi-update
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.31.16.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.31.16.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7174 (7.0K) [text/plain]
Saving to: `rpi-update'

100%[==========================================================================================================================================================================================================================================================================>] 7,174       --.-K/s   in 0.009s  

2014-03-20 14:50:09 (789 KB/s) - `rpi-update' saved [7174/7174]

Not sure if it was a temporary glitch (I did notice that github web interface was very slow yesterday, but seems better today), or it's something location dependent. Can you try again now?

Pitel commented 10 years ago

It still doesn't work.

I'm from Czech Republic, and github.com resolved to 192.30.252.131 and raw.githubusercontent.com resolved to 185.31.17.133.

notGMman commented 10 years ago

Exactly the same error for me. The redirection resolved first to 185.31.17.133 and then to 185.31.16.133 and neither worked. Tried on two raspis, both at the end of the upgrade process so already up-to-date software. wget version 1.13.4. Not a firewall issue - I can see the traffic tootling off over the www just fine.

notGMman commented 10 years ago

Ah, from the posts on the Troubleshooting forum at http://www.raspberrypi.org a lot of people are seeing the same fault.

notGMman commented 10 years ago

OK, on an old raspi, not up-to-date software but same wget version, the self update works just fine. Looks like something has happened in a piece of code we pick up elsewhere.

popcornmix commented 10 years ago 
pi@raspberrypi:~ $ wget --version
GNU Wget 1.13.4 built on linux-gnueabihf.

So wget 1.13.4 is working for me.

Does changing /etc/resolv.conf to include: nameserver 8.8.8.8

make any difference?

notGMman commented 10 years ago

the google nameserver is already the only resolver in the file

notGMman commented 10 years ago

A quick google suggests this isn't only a raspi issue. One or two other posts in the last day or two from debian users - eg. something called calibre. And a report on "theregister" about GnuTLS here: http://www.theregister.co.uk/2014/03/05/gnu_security_library_gnutls_fails_on_cert_checks_patch_now/

g7ruh commented 10 years ago

I tried this several hours ago and posted on troubleshooting on raspi forum. It is still the same now

skgsergio commented 10 years ago

As I said one year ago here https://github.com/Hexxeh/rpi-update/issues/65#issuecomment-13332143 the problem is that wget prior to 1.14 doesn't have SNI extension and GitHub uses it so it sometimes fail. Once you update to wget 1.14 or greater it works.

@notGMman the gnutls fail isn't related to your issue. It's a complete different thing.

notGMman commented 10 years ago

OK skgsergio. There's not much detail in these comments which is why I didn't google "wget sni" before. Sad to see a bug fix proposed for wget 1.11 not incorporated in 1.13 and also sad that rp-update fails without it, as you put it "sometimes". Thanks for the info anyway. Got mine to work by copying rpi-update to rpi-update.tmp and then deleting the wget self update from the original script before running it.

skgsergio commented 10 years ago

@notGMman instead editing rpi-update you can just run UPDATE_SELF=0 rpi-update if it fails self-updating it.

skgsergio commented 10 years ago

Ok, I've checked and debian backported the fix to wget 1.13.4 (http://metadata.ftp-master.debian.org/changelogs/main/w/wget/wget_1.13.4-3+deb7u1_changelog) and plugwash confirmed me that it is already in Raspbian:

<plugwash> repo@raspbian:~/private/private$ reprepro list wheezy wget
<plugwash> wheezy|main|armhf: wget 1.13.4-3+deb7u1

So please run apt-get update && apt-get upgrade and then try rpi-update.

@popcornmix If the ppl having this problem update the system shouldn't have this issue.

peepo commented 10 years ago

~ $ wget -V GNU Wget 1.13.4 built on linux-gnueabihf.

I already ran sudo update upgrade

nix for rpi-update as per above, and yes ca certificates is installed and time checked...

updates appreciated....

notGMman commented 10 years ago

Hi skgsergio - that's quick work. But I tried the apt-get upgrade and it picked up no changes. So I removed and then installed wget and rpi-update still hasn't worked. Didn't do a reboot between remove and install though - just rebooted before the rpi-update.

jj358mhz commented 10 years ago

I am running into the same issue as well. I did all recommended updates/upgrades and am still receiving the ca-certificates error.

MrEngman commented 10 years ago

I am seeing an error a well. All was OK until I installed the newest version of wget.

Unpacking wget (from .../wget_1.13.4-3+deb7u1_armhf.deb) ...

wget -V
GNU Wget 1.13.4 built on linux-gnueabihf.

Then now I receive the following error 

Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.31.18.133|:443... connected.
GnuTLS: A TLS warning alert has been received.
Unable to establish SSL connection.
 !!! Failed to download update for rpi-update!
 !!! Make sure you have ca-certificates installed and that the time is set correctly

ca-certificates and time are OK

Installed new image raspbian 3.10.25+ #622 then updated using rpi-update to 3.10.33+ #658 and rpi-update ran OK. Using apt-get update/upgrade and installing all files ~20 excluding wget and rpi-update still OK. After installing wget then rpi-update failed on self-update.

Also installing new image raspbian 3.10.25+ then updated using rpi-update to 3.10.33+ #658 and only installing wget 1.13.4 and none of the other packages indicated by apt-get upgrade and rpi-update again failed on self-update as above.

dl9sec commented 10 years ago

Seems for me, that it doesn't work anymore since kernel 3.10.33+ #654...

skgsergio commented 10 years ago

Weird... The patch Debian included in wget 1.13.4-3+deb7u1 should fix it but the problem seems to be even worst. With wget 1.14 I've run 500 downloads from github without problem, so if Debian backported the patch correctly it should work... I'm going to do some test to see if I can understand what's happening now.

Let's see if I can get a proper workaround.

I can confirm the bug:

root@rpi:/# apt-cache policy wget | grep Installed
  Installed: 1.13.4-3+deb7u1
root@rpi:/# wget https://github.com/Hexxeh/rpi-update/raw/master/rpi-update
--2014-03-21 08:57:51--  https://github.com/Hexxeh/rpi-update/raw/master/rpi-update
Resolving github.com (github.com)... 192.30.252.128
Connecting to github.com (github.com)|192.30.252.128|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/Hexxeh/rpi-update/master/rpi-update [following]
--2014-03-21 08:58:01--  https://raw.githubusercontent.com/Hexxeh/rpi-update/master/rpi-update
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.31.18.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.31.18.133|:443... connected.
GnuTLS: A TLS warning alert has been received.
Unable to establish SSL connection.
mwagner commented 10 years ago

As workaround I downloaded the rpi-update script manually and run with UPDATE_SELF=0:

curl -O https://raw.githubusercontent.com/Hexxeh/rpi-update/master/rpi-update
chmod +x rpi-update
sudo UPDATE_SELF=0 ./rpi-update
skgsergio commented 10 years ago

Well, the problem here has changed... there is no SNI problem now. I've done multiple tests about SNI without problems.

I'll try to be as plain as I can with the thing I think is the problem:

Since Feb 25 00:00:00 2014 GMT GitHub is using a new certificate which wget/GnuTLS don't likes. How can be that?

New certificate subject is: C=US, ST=California, L=San Francisco, O=Fastly, Inc., CN=www.github.com That is valid for www.github.com.

But also it have this extension:

X509v3 Subject Alternative Name: 
    DNS:www.github.com, DNS:*.github.com, DNS:*.github.io, DNS:*.githubusercontent.com

So it's also valid for raw.githubusercontent.com but seems that wget/GnuTLS is not checking the alternative name extension...

What can we do? If the reference images comes with curl we can simply switch to curl: curl https://url/.. -o /path/to/store/the/file. If is not installed we can simply warn the user to install it (just checking if curl exists).

popcornmix commented 10 years ago

Strangely rpi-update is still working just fine for me. I've run it multiple times, and can wget from github both on Pi and Ubuntu. But, I've pushed a commit to use curl rather than wget. Any better?

skgsergio commented 10 years ago

@popcornmix seems to be a little random because sometimes fails and sometimes works for me on the RPi. On Ubuntu you probably have a greater version like me on Debian or Arch.

mwagner commented 10 years ago

after getting the updated file using curl it works fine

popcornmix commented 10 years ago

So, to get from the current rpi-update to the latest rpi-update you should be able to run:

sudo curl -L --output `which rpi-update` https://github.com/Hexxeh/rpi-update/raw/master/rpi-update
iz8mbw commented 10 years ago

Hi. With: "sudo curl -L --output which rpi-update https://github.com/Hexxeh/rpi-update/raw/master/rpi-update" it works: root@raspberrypi:~# sudo curl -L --output which rpi-update https://github.com/Hexxeh/rpi-update/raw/master/rpi-update % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 135 100 135 0 0 214 0 --:--:-- --:--:-- --:--:-- 283 100 7177 100 7177 0 0 6951 0 0:00:01 0:00:01 --:--:-- 38586

root@raspberrypi:~# rpi-update * Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS * Performing self-update % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 135 100 135 0 0 193 0 --:--:-- --:--:-- --:--:-- 253 100 7177 100 7177 0 0 7787 0 --:--:-- --:--:-- --:--:-- 7787 * Relaunching after update * Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS * ARM/GPU split is now defined in /boot/config.txt using the gpu_mem option! * Setting up firmware (this may take a few minutes) Cloning into '//root/.rpi-firmware'...