[tor-commits] [tor-browser-spec/master] Add download-user-safety proposal to ideas

[gk at torproject.org]

commit ab5ab0ea175578bbd4569f7863c7a8f4d07806f7
Author: Georg Koppen <gk at 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 at .
+
+  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.