[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] Proposal for Tor instances to accept other cell types before VERSIONS
commit cc2d3209079682ccc285a1e9a89caaf14be3fbe8
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date: Sun Oct 16 16:50:26 2011 -0400
Proposal for Tor instances to accept other cell types before VERSIONS
---
proposals/187-allow-client-auth.txt | 131 +++++++++++++++++++++++++++++++++++
1 files changed, 131 insertions(+), 0 deletions(-)
diff --git a/proposals/187-allow-client-auth.txt b/proposals/187-allow-client-auth.txt
new file mode 100644
index 0000000..3d3cf25
--- /dev/null
+++ b/proposals/187-allow-client-auth.txt
@@ -0,0 +1,131 @@
+Filename: 187-allow-client-auth.txt
+Title: Reserve a cell type to allow client authorization
+Author: Nick Mathewson
+Created: 16-Oct-2011
+Status: Open
+Target: 0.2.3.x
+
+Overview:
+
+ Proposals 176 and 184 introduce a new "v3" handshake, coupled with
+ a new version 3 link protocol. This is a good time to introduce
+ other stuff we might need.
+
+ One thing we might want is a scanning resistance feature for
+ bridges. This proposal suggests a change we should make right
+ away to enable us to deploy such a feature in future versions of
+ Tor.
+
+Motivation:
+
+ If an adversary has a suspected bridge address/port combination,
+ the easiest way for them to confirm or disconfirm their suspicion
+ is to connect to the address and see whether they can do a Tor
+ handshake. The easiest way to fix this problem seems to be to
+ give out bridge addresses along with some secret that clients
+ should know, but which an adversary shouldn't be able to learn
+ easily. The client should prove to the bridge that it's
+ authorized to know about the bridge, before the bridge acts like a
+ bridge. If the client doesn't show knowledge of the proper
+ secret, the bridge should at like an HTTPS server or a bittorrent
+ tracker or something.
+
+ This proposal *does not* specify a way for clients to authorize
+ themselves at bridges; rather, it specifies changes that we should
+ make now in order to allow this kind of authorization in the
+ future.
+
+Design:
+
+ Currently, now that proposal 176 is implemented, if a server
+ provides a certificate that indicates a v3 handshake, and the
+ client understands how to do a V3 handshake, we specify that the
+ client's first cell must be a VERSIONS cell.
+
+ Instead, we make the following specification changes:
+
+ We reserve a new variable-length cell type, "AUTHORIZE."
+
+ We specify that any number of PADDING or VPADDING or AUTHORIZE
+ cells may be sent by the client before it sends a VERSIONS cell.
+ Servers that do not require client authorization MUST ignore such
+ cells, except to include them when calculating the HMAC that will
+ appear in the CLOG part of a client's AUTHENTICATE cell.
+
+ We still specify that clients SHOULD send VERSIONS as their first
+ cell; only in some future version of Tor will an AUTHORIZE cell be sent
+ first.
+
+Discussion:
+
+ This change allows future versions of the Tor client to know that
+ some bridges need authorization, and to send them authentication
+ before sending them anything recognizably Tor-like.
+
+ The authorization cell needs to be received before the server can
+ send any Tor cells, so we can't just patch it in after the
+ VERSIONS cell exchange: the server's VERSIONS cell is unsendable
+ until after the AUTHORIZE has been accepted.
+
+ Note that to avoid scanning attacks, it's not sufficient to wait
+ for a single cell, and then either handle it as authorization or
+ reject the connection. Instead, we need to decide what kind of
+ server we're impersonating, and respond once the client has
+ provided *either* an authorization cell, *or* a recognizably valid
+ or invalid command in the impersonated protocol.
+
+
+Alternative design: Just use pluggable transports
+
+ Pluggable transports can do this too, but in general, we want to
+ avoid designing the Tor protocol so that any particular desirable
+ feature can only be done with a pluggable transport. That is, any
+ feature that *every* bridge should want, should be doable in Tor
+ proper.
+
+ Also, as of 16 Oct 2011, pluggable transports aren't in general
+ use. Past experience IMO suggests that we shouldn't offload
+ architectural responsibilities to our chickens until they've
+ hatched.
+
+Alternative design: Out-of-TLS authorization
+
+ There are features (like port-knocking) designed to allow a client
+ to show that it's authorized to use a bridge before the TLS
+ handshake even happens. These are appropriate for bunches of
+ applications, but they're trickier with an adversary who is
+ MITMing the client.
+
+Alternative design: Just use padding.
+
+ Arguably, we could only add the "VPADDING" cell type to the list
+ of those allowed before VERSIONS cells, and say that any client
+ authorization we specify later on will be sent as a VPADDING
+ cell. But that design is kludgy: padding should be padding, not
+ semantically significant. Besides, cell types are still fairly
+ plentiful.
+
+Counterargument: specify it later
+
+ We could, later on, say that if a client learns that a bridge
+ needs authorization, it should send an AUTHORIZE cell. So long as
+ a client never sends an AUTHORIZE to anything other than a bridge that
+ needs authorization, it'll never violate the spec.
+
+ But all things considered, it seems easier (just a few lines of
+ spec and code) to let bridges eat unexpected authorization now
+ than it does to have stuff fail later when clients think that a
+ bridge needs authorization but it doesn't.
+
+Counterargument: it's too late!
+
+ We've already got the prop176 branch merged and running on a few
+ servers. But as of this writing, it isn't in any Tor version.
+
+ Even if it *is* out in an alpha before we can get this proposal
+ accepted and implemented, that's not a big disaster. In the worst
+ case, where future clients don't know whom to send authorization
+ to so they need to send it to _all_ v3 servers, they will at worst
+ break their connections only to a couple of alpha versions which
+ one hopes by then will be long-deprecated already.
+
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits