Reported by jteh on 2014-12-20 01:23
Now that Python 2.7.9 verifies https certificates, we should move to using https for update checks. This will prevent MITM attacks for update checks. We should also include a hash for the executable in the update check response and verify it once downloaded to prevent MITM attacks for the download itself.
This requires changes in both NVDA and the server. Blocked by #4715 Blocking #4803
The text was updated successfully, but these errors were encountered:
Comment 3 by leonarddr on 2015-01-14 08:08
Currently, NVDA next-11478,349a1b9 reports an error when checking for updates. DEBUGWARNING - updateCheck.UpdateChecker._bg (09:06:08): Error checking for update Traceback (most recent call last): File "updateCheck.pyc", line 103, in _bg File "updateCheck.pyc", line 70, in checkForUpdate File "urllib.pyc", line 87, in urlopen File "urllib.pyc", line 213, in open File "urllib.pyc", line 443, in open_https File "httplib.pyc", line 997, in endheaders File "httplib.pyc", line 850, in _send_output File "httplib.pyc", line 812, in send File "httplib.pyc", line 1216, in connect File "ssl.pyc", line 350, in wrap_socket File "ssl.pyc", line 566, in __init__ File "ssl.pyc", line 788, in do_handshake IOError: [socket error](Errno) [CERTIFICATE_VERIFY_FAILED](SSL:) certificate verify failed (_ssl.c:581)
Comment 5 by nvdakor on 2015-01-14 18:14
A number of people are reporting that after next.11478, certificate validation fails when trying to retrieve an update and snapshot page itself doesn't show newer updates.
Comment 6 by nvdakor on 2015-01-15 01:26
It appears that custom certificate might be sitting somewhere. Google searches point out that if you use custom certificates, Python 2.7.9's SSL module will throw the IOError described in #4803.
Pages of interest:
Comment 7 by jteh (in reply to comment 6) on 2015-01-15 03:07
Replying to nvdakor:
It appears that custom certificate might be sitting somewhere.
Thanks for the research. The issues you mentioned relate to a custom certificate location on Unix or self-signed certificates. Neither of these is the case here. However, the lack of intermediate certificates on our server as discussed in #4803 could be the problem. I've fixed this now, so I'm awaiting feedback on #4803.