Re: [tor-bugs] #25594 [Obfuscation/Snowflake]: Broker: investigate non-domain-fronting secure client / proxy registrations

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#25594: Broker: investigate non-domain-fronting secure client / proxy registrations
-----------------------------------+------------------------
 Reporter:  arlolra                |          Owner:  (none)
     Type:  defect                 |         Status:  new
 Priority:  Medium                 |      Milestone:
Component:  Obfuscation/Snowflake  |        Version:
 Severity:  Normal                 |     Resolution:
 Keywords:                         |  Actual Points:
Parent ID:                         |         Points:
 Reviewer:                         |        Sponsor:
-----------------------------------+------------------------

Comment (by dcf):

 Replying to [comment:4 arma]:
 > Ok, from https://www.bamsoftware.com/papers/thesis/#fig:snowflake-
 rendezvous it looks like it can be just one round-trip? So something like
 encrypted dns is a great answer?

 That's correct. It needs one round trip. DNS is a good match.

 We should (but don't yet) encrypt client registration messages; see
 #22945. The registration messages don't reveal a ''ton'' of sensitive
 metadata beyond the client's IP address (which we can't hide anyway); but
 there's no reason not to encrypt it. I believe the statement from the
 description ''"the client is making TLS connections with the broker"'' is
 incorrect; in the domain fronting case, the client has a TLS session with
 the CDN, and the CDN has a TLS session with the broker, but the CDN is in
 a MITM position and can read the plaintest of registration messages, in
 the absence of any other protection. It's the same thing with encrypted
 DNS: we may as well encrypt the messages before encoding them as DNS
 requests. But that's a privacy thing, not a blocking resistance thing.

 The situation with Moat is more complicated: Moat relies on end-to-end TLS
 with bridgedb.torproject.org for integrity: it doesn't have separate
 integrity for the message that contains your 3 bridges, for instance. So
 Moat is using a comparatively heavyweight full meek tunnel, constructing a
 general-purpose bidirectional tunnel atop multiple roundtrips. In Moat,
 there is an outer TLS session between the client and the CDN, and a
 separate outer TLS session between the CDN and BridgeDB's Moat endpoint;
 but inside of both is a tunneled end-to-end TLS session between the client
 and BridgeDB.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25594#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

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