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

[Tor Bug Tracker & Wiki]

#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 fs):

 TapDance also sounds like a good fit(perhaps, fallback) for rendezvous
 protocol.
 Currently existing TapDance deployment doesn't cover enough high-value
 decoys to be truly resistant to enumeration attacks, but, hopefully, that
 will change in future.

 Should be pretty easy to integrate: you just need to give TapDance a
 folder to store things, copy initial config(ask devs to send you one) in
 that folder, and then you could just
 `conn, err := tapdance.Dial("tcp", "snowflake-broker.org:443")` - same
 signature as `net.Dial`.

 > We should (but don't yet) encrypt client registration messages
 If you want to do TLS, you can then pass that `conn` into standard
 `tls.Client`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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):

 #26151 is about using Amazon SQS.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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 twim):

 See also #25985 for AMP cache fronting.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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):

 I made #25874 for the DNS idea.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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 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?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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 arma):

 Can somebody summarize the requirements for the interaction between the
 Snowflake client and ~~the broker~~whatever components the client has to
 talk to?

 I see mentions of a TLS handshake above, but I'm hoping to get at the
 underlying requirements, for which "do a TLS handshake" is part of one
 possible approach to meeting the requirements, but once we understand the
 requirements more maybe we'll realize there are others.

 In particular, does it have to be an arbitrary number of round-trip
 interactions (e.g. because we're bundling info from a nat piercing
 protocol that needs arbitrary round-trips) or can we constraint it down
 more?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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:
---+
Changes (by mcs):

 * cc: mcs (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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):

 An idea to use DNS over HTTPS:
 https://groups.google.com/forum/#!topic/traffic-obf/ZQohlnIEWM4
 > The circumvention idea is to take any existing DNS tunneling scheme and
 send it through DNS over HTTPS. To be a bit more specific: you send
 recursive DNS queries (encoding your upstream traffic) to the DNS-over-
 HTTPS server, which then forwards the queries to another specialized
 server that decodes them and proxies the data they contain.
 >
 > Even if not a general-purpose transport, DNS-over-HTTPS could be an
 ideal rendezvous mechanism for a system like Snowflake or Moat. One where
 you only need to send/receive a small amount of very hard-to-block data in
 order to bootstrap a connection.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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 |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 > Pasting discussion from email,
 >
 >> in the Flashproxy case, registration wasn't
 >> bidi, and I think they imagined using insecure
 >> channels to register like OSSes. In Snowflake,
 >> the client is making TLS connections with the
 >> broker, which amounts to the same thing as
 >> encrypting the payload with the facilitator's
 >> public key.
 >
 > Also,
 >
 >> There's also the case where an adversary DOSes the facilitator with a
 >> bunch of fake client or proxy registrations and things like that.
 >
 > This is now #25593
 >
 >> Also, there is the potential that in the future we might need some
 >> sort of non-domain-fronting rendezvous. It seems that right now we
 >> have an ecosystem of tools growing that assumes domain-fronting will
 >> always be available & effective. May be worth considering how to
 >> prepare for regions where this might not work as well in the future.
 >
 > So this ticket should probably be for that.

 \\ Migrated from https://github.com/keroserene/snowflake/issues/13

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs