Opened 5 months ago

Last modified 7 weeks ago

#25594 new defect

Broker: investigate non-domain-fronting secure client / proxy registrations

Reported by: arlolra Owned by:
Priority: Medium Milestone:
Component: Obfuscation/Snowflake Version:
Severity: Normal Keywords:
Cc: dcf, arlolra, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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

Child Tickets

Change History (9)

comment:1 Changed 5 months ago 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.

comment:2 Changed 4 months ago by mcs

Cc: mcs added

comment:3 Changed 4 months ago by arma

Can somebody summarize the requirements for the interaction between the Snowflake client and the brokerwhatever 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?

comment:4 Changed 4 months ago 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?

comment:5 in reply to:  4 Changed 4 months ago by dcf

Replying to 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.

comment:6 Changed 4 months ago by dcf

I made #25874 for the DNS idea.

comment:7 Changed 4 months ago by twim

See also #25985 for AMP cache fronting.

comment:8 Changed 3 months ago by dcf

#26151 is about using Amazon SQS.

comment:9 Changed 7 weeks ago 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

Note: See TracTickets for help on using tickets.