commit ab5ab0ea175578bbd4569f7863c7a8f4d07806f7 Author: Georg Koppen gk@torproject.org Date: Mon Apr 8 07:54:31 2019 +0000

Add download-user-safety proposal to ideas --- proposals/ideas/xxx-download-user-safety.txt | 203 +++++++++++++++++++++++++++ 1 file changed, 203 insertions(+)

diff --git a/proposals/ideas/xxx-download-user-safety.txt b/proposals/ideas/xxx-download-user-safety.txt new file mode 100644 index 0000000..f62a8a6 --- /dev/null +++ b/proposals/ideas/xxx-download-user-safety.txt @@ -0,0 +1,203 @@ +Filename: xxx-download-user-safety.txt +Title: Protecting Against Malicious Exit Nodes Performing File Infection +Author: Tom Ritter +Created: 06-Mar-2019 +Status: Draft + +1. Motivation + + Sometimes, exit nodes are malicious. One activity malicious exit nodes + perform is infecting files (most commonly executables) downloaded over + insecure or otherwise compromised connections. Tor Project and + volunteers scan and report malicious exit relays where-upon they are + given the BadExit flag. + + In the period of time between the nodes being identified and being + blocklisted, users are put at risk from these nodes. + +2. Proposal + +2.1. Required Infrastructure + + Firstly, we assume that for each operating system, we have devised two lists of + file types for that system. + + Executable File Types: These files are programs or otherwise things that + can definitly and intentionally execute code. + Examples: .exe .deb + + Transparent File Types: These files are trivial or simple file types where + the risk presented is very low. + Examples: .txt .html .jpg, .png + + Additionally, it would be ideal if, for file archive types (e.g. .zip), we read + the file archive manifest and classified the file archive accordingly. + + Secondly, this proposal is complementary to the 103-selfsigned-user-safety.txt + proposal. We assume that (only) one of the following is in place, and we concern + ourselves only with downloads that meet one of the follow criteria + + Criteria: + - the resource of concern is loaded over HTTP + or + - selfsigned-user-safety is not implemented, the resource of concern is loaded + over HTTPS, and the certificate has a Class 1 Suspicious Certificate Error + (defined below) + +2.1.1 selfsigned-user-safety + + The selfsigned-user-safety proposal is implemented. + +2.1.2 Self-signed certificate error detection + + As in selfsigned-user-safety, we classify TLS Certificate Errors into two + categories. + + Class 1: Suspicious Certificate Errors + + - A self-signed certificate + - A certificate signed by a Trust Anchor but for a different hostname + - A certificate that appears to be signed by a Trust Anchor, but is + missing an intermediate allowing a full path to be built + + Class 2: Unsuspicious Certificate Errors + + - An expired certificate signed by a Trust Anchor + - A certificate that requires an OCSP staple, but the staple is not + present + + The browser will detect a Class 1 error and make this state available for + the browser to base decisions off of. + +2.2. The difference between the download _link_ and the download + + We concern ourselves with two situations, that is whether or not the + download link appears on is secure (defined as not having a Class 1 + Error for any active page content). + + When the download link comes from a secure page, but the target of the + download is insecure (defined as being HTTP or having a Class 1 Error), + the link itself impacts some amount of authenticity for the download. + + However, when the download link comes from an insecure page, no + authenticity is possible, as a MITM attacker can point the download link + at a malicious file. + +2.3. Browser Logic for Executable Files + + Option 1: If the filetype of a download is one of a predefined set of executable + formats, the download is prevented entirely. + + Option 2: If the filetype of a download is one of a predefined set of executable + formats, we attempt to verify the download. + + If the download link is secure, we could consider either option. + If the download link is insecure, we should only consider Option 1. Verification + can impart no additional value. + +2.4. Browser Logic for Non-Transparent, Non-Executable Files + + This essentially reverses the option numbers from above, to reflect the reduced + risk of infection of non-executable files. + + To be clear, however, the risk is still non-zero. Complex types such as .doc can + include macros or other executable code, alternately they are prime suspects for + client-side exploits. + + Option 1: If the filetype of a download is NOT one of a predefined set of executable + formats, we attempt to verify the download. + + Option 2: If the filetype of a download is NOT one of a predefined set of executable + formats, the download is prevented entirely. + + Option 3: No verification is performed, and the download is allowed. + + Again, if the download link is secure, we could consider Option 1 or 2. + If the download link is insecure, we should only consider Options 2 or 3. (Option 3 + given the reduced risk for this filetype, Option 2 given the non-zero risk.) + +2.4. Browser Logic for Transparent Files + + To be exhaustive, no special action is taken for transparent files. + +2.5 Verifying a File Download + + To verify a file download, several different approaches could be taken: + + Option 1: The entire file could be downloaded over a new circuit (taking care to + avoid the same exit family) and compared. + + Option 2: Assuming the server supports range requests, random parts of the file could + be requested over a new circuit, and compared. This would save bandwidth and + time. + + Note that we must choose random parts of the file; otherwise an attacker + could rewrite the binary in a way that avoids alternating the checked parts. + + [[ How probable is it that we catch an alteration? We'd need to check a + component of the file already downloaded, and for large files we'd need to + check a lotbecause thered be a lot of places malicious code could hide...]] + + Option 3: If the file supports Authenticode or a similar signature extension, we could + a) Check if the file has an authenticode signature. If not, verify by + some other means + b) Download the PE Header and the signature block at the end of the + file over a new circuit + c) Compare the Header,, Signature Block, and Signature Public Key and + confirm they match + d) Confirm that the signature isn't a weak signature that would verify + any file + + 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. + + [[ Are there other approaches to file verification we could do that would work? ]] + +2.6. Optional Extension + + If a download verification fails, the browser could prompt the user to + send a report to Tor Project. + + The simple version of this feature could open an email message with + details prepopulated and addressed to badrelays@. + + The more advanced version could submit the information to an onion + service operated by Tor Project. On the backend, we could build an + automatic verification process as well. + + The details would include the hostname visited, time, exit nodes, and + file data received over which exit nodes. + +3. False Positives + + False Positives during verification could occur if a server provides customized + binaries or only allows download of a file once. + +4. User Interface/Experience + + We should, in some way, alter the download screens to ensure that they do not register + a download as complete before the verification process has occured. + + Similarly, we should not rename in-progress .part download files until the verification + has completed. + +5. Concerns + + An exit node who observes a range request will learn that a user is downloading + this file on another circuit. What would this tell them? It leaks a user's browsing + activity. Anything else? + + Exit nodes who lie about their family have a chance to successfully attack the + user. + +6. Research + + It would probably be possible to perform a research experiment at one or more + exit nodes to determine the frequency of users download filetypes over HTTP. + We could record the number of filetypes downloaded over HTTP and the total + amount of exit traffic pushed by Tor. (No other records should be kept, for + safety reasons.) This would given us some ratio to indicate the frequency such + files are downloaded. This may guide us to choose more stringent blocking or + less stringent.