Broker: investigate non-domain-fronting secure client / proxy registrations
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 legacy/trac#25593 (moved)
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
Ideas that have been proposed or done:
- #25985 (closed) AMP cache
- #25874 DNS
- #26151 (closed) Amazon SQS