[tbb-dev] A proposal for verifying http downloads

[Tom Ritter]

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
-------------- next part --------------
Filename: xxx-download-user-safety.txt
Title: Protecting Against Malicious Exit Nodes Performing File Infection
Author: Tom Ritter
Created: 06-Mar-2019
Status: Open

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 definetly 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 xxx-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 page is loaded over HTTP
   or
   - selfsigned-user-safety is not implemented, the page 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. 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.

2.3. 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 

  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.

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...]]

  [[ 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

  It's possible there could be false positives... but I'm not sure why they would occur.

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.