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.
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.
keroserene
changed the title
Broker: more secure client / proxy registrations, similar to flashproxy facilitator
Broker: investigate non-domain-fronting secure client / proxy registrations
Dec 17, 2016
No description provided.
The text was updated successfully, but these errors were encountered: