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

[gk at torproject.org]

commit 61bf94fd1413d00a76b4d16eeeedfca8314f265e
Author: Georg Koppen <gk at torproject.org>
Date:   Mon Apr 8 07:51:32 2019 +0000

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

diff --git a/proposals/ideas/xxx-cryptocurrency-user-safety.txt b/proposals/ideas/xxx-cryptocurrency-user-safety.txt
new file mode 100644
index 0000000..4ac7fb0
--- /dev/null
+++ b/proposals/ideas/xxx-cryptocurrency-user-safety.txt
@@ -0,0 +1,97 @@
+Filename: xxx-cryptocurrency-user-safety.txt
+Title: Protecting Against Malicious Exit Nodes Performing Cryptocurrency Hijacking
+Author: Tom Ritter
+Created: 06-Mar-2019
+Status: Draft
+
+1. Motivation
+
+  Sometimes, exit nodes are malicious. One activity malicious exit nodes
+  perform is rewriting the addresses of cryptocurrencies to hijack and steal
+  funds users are trying to send to the original address. 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
+
+  This proposal is complementary to the 103-selfsigned-user-safety.txt proposal.
+  We assume that (only) one of the following is in place.
+
+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
+
+  The browser will be able to recognize addresses of common cryptocurrencies
+  and when a user executes a copy event, will search for such an address in the
+  copied text.
+
+  If an address is detected and:
+   - 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
+
+  Then the text MUST NOT be copied to the clipboard.
+
+  Basically this prevents the address from being copied if the address could
+  have been changed by the exit node.
+
+3. False Positives
+
+  Not every cryptocurrency address served over HTTP is being attacked by a
+  malicious exit node.
+
+4. False Negatives (Attacker-Controlled)
+
+  An attacker could change the address to a QR code and prompt the user to
+  scan it with their phone. This would not be detectable if the attacker
+  rendered the QR code using background-colored <div> elements for example.
+
+  There are likely other bypasses to consider.
+
+5. User Interface/Experience
+
+  The text will not be copied. But when the user executes the copy shortcut or
+  menu item a model dialog (like alert()) could be presented explaining why the
+  copy failed.
+
+  We could also use a doorhanger or information bar - but both of these seem prone
+  to being missed or ignored; while a modal dialog will be immediate, come with a
+  sound, and
+
+6. User Bypass
+
+  The user can, of course, manually type the address.
+
+7. Implementation
+
+  In Firefox, this entire concept can likely be implemented as a WebExtension
+  using the TLS Web Extension APIs and the Clipboard APIs.