[tor-commits] [tor-browser-spec/master] Add selfsigned-user-safety proposal as 103

[gk@xxxxxxxxxxxxxx]

commit aa4789f02be3a60c9288a00d42e32fc153c22f98
Author: Georg Koppen <gk@xxxxxxxxxxxxxx>
Date:   Mon Apr 8 07:30:47 2019 +0000

    Add selfsigned-user-safety proposal as 103
---
 proposals/103-selfsigned-user-safety.txt | 111 +++++++++++++++++++++++++++++++
 1 file changed, 111 insertions(+)

diff --git a/proposals/103-selfsigned-user-safety.txt b/proposals/103-selfsigned-user-safety.txt
new file mode 100644
index 0000000..35de1c8
--- /dev/null
+++ b/proposals/103-selfsigned-user-safety.txt
@@ -0,0 +1,111 @@
+Filename: 103-selfsigned-user-safety.txt
+Title: Protecting Against Malicious Exit Nodes Performing TLS Interception
+Author: Tom Ritter
+Created: 06-Mar-2019
+Status: Open
+
+1. Motivation
+
+  Sometimes, exit nodes are malicious and perform TLS interception using self-
+  signed or otherwise invalid TLS certificates. 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. Classifying TLS Certificate Errors
+
+  First we classify TLS Certificate Errors into two categories. We will use
+  these classifications later.
+
+  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
+
+2.2. Browser Logic
+
+  If the browser encounters an invalid TLS certificate when connecting to a
+  hostname, and the type of invalidness is a Suspicious Certificate Error,
+  the browser will not _immediately_ allow the user to bypass the error and
+  add an exception.
+
+  Instead it will create a new circuit through a new exit node (making sure
+  to check the Family of the nodes), begin a TLS handshake, and obtain the
+  certificate offered.
+
+  If the certificate is the same as the one offered through the initial
+  circuit, the user is allowed to add an exception and continue. If the
+  certificate is different, the user is not allowed to bypass the error.
+
+2.3. Optional Extension
+
+  If a certificate mismatch occurs, 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
+  certificates received over which exit nodes.
+
+3. False Positives
+
+  It is possible, although I suspect uncommon, that a server may have
+  geographic or other load balancing that presents different self-signed
+  certificates to different exit nodes.
+
+  If we receive reports of such occurances, we could either relax protects
+  for such domains we hardcode into the browser, or perform the new-circuit
+  verification choosing an exit node in the same country.
+
+4. User Interface/Experience
+
+  While the certificate is being verified over another circuit, it would be
+  best to provide feedback to the user.
+
+  a. The button can appear disabled and say something like
+     'Pending (Verifying Certificate)'
+  b. A small progress bar can appear under the button that tracks the progress
+     of creating and extending the circuit, sending the request and getting
+     the reply.
+  c. A small 'Retry' underlined, clickable link could sit by the progress
+     bar to retry the circuit in case it gets stalled.
+
+  If the certificate comes back and is a mismatch, we could replace the entire
+  error page with more information, including a cloudflare-style diagram[0] showing
+  the malicious exit node, and prompting the user to submit the information.
+
+  If the certificate comes back with a match, we could add some text noting that
+  some amount of verification has been performed. However it seems bad to
+  automatically accept the certificate or relax the warning too much, since it
+  is still possible a TLS attack is occuring (just not inside the Tor network.)
+  Alternately, we could not change the warning page at all.
+
+5. Concerns
+
+  An exit node who observes an aborted TLS handshake will learn that a user
+  encountered a self-signed certificate error for this server on another circuit.
+  What would this tell them? It leaks a user's browsing activity. It also leaks
+  the prescence of a malicious exit node on the network (assuming the exit node
+  observes a valid TLS certificate.)
+
+  Exit nodes who lie about their family have a chance to successfully attack the
+  user.
+
+  [0] https://external-preview.redd.it/S65-yhtC6IAqpzS6AMhMnrrFwvtyRA6WjuM_hQpJLg0.png?auto=webp&s=285e86af8e638df6ecc143a52af024f006389151



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits