We also discussed this proposal at the monthly Tor/Mozilla meeting.

Dennis pointed out that an attacker who is modifying a page served over an insecure connection can change the link to point to the malicious file, so it seems more valuable to just block such a download outright.

If the link is served over HTTPS however, that might be a situation to allow (and verify) it.

Dennis also pointed out that sometimes users are served customized binaries or only allowed to download a file once. Both would break verification.

We discussed using an exit node to measure how common it is for a Tor user to download an executable file or non-opaque over HTTP. Such an experiment shouldn't be done without talking to the Tor Research Safety Group. But the idea would only be to record the number of such files downloaded and the total amount of traffic pushed by Tor, to give a statistic such as "For every 5 terabit of trafic, users download ~4 executable files insecurely." No record of type of file, file itself, location, time, or anything else should be kept.

Finally, we talked about checking an authenticode-style signature block on an executable to make such a verification faster. A short proposal would be: 1) Check if the file has an authenticode signature. If not, verify by some other means 2) Download the PE Header and the signature block at the end of the file over a new circuit 3) Compare the Header,, Signature Block, and Signature Public Key and confirm they match 4) Confirm that the signature isn't a weak signature that would verify any file (Dennis pointed this out too)

At this point we should be assured that a) The OS will check the authenticode block b) if the file hash doesn't match the signature block the OS won't run it c) the file hash was the same on both circuit downloads.

-tom

On Thu, 7 Mar 2019 at 06:06, Tom Ritter tom@ritter.vg wrote:

Third of three.

This one is definitely the least fleshed out. The short version is verify most types of files downloaded over a potentially insecure connection.

-tom