The same thing just happened with Telegram in Russia which explains the preemptive messages: https://arstechnica.com/information-technology/2018/04/in-ef...
It's entirely their right of course.
Right, because of the risk of being blocked.
It is their right, but to say it's not motivated by a risk of censorship is pretty disingenuous.
(I have no horse in this race. I'm merely contextualizing the debate)
It's not a single company here, thousands of businesses rely on AWS and don't want their service disrupted because of Signal.
Time to look for another option then, like any other technical challenge. I support Signal's work here but unfortunately we can't just enlist every other business to help (otherwise censorship wouldn't be much of a problem in the first place).
But we should! Telex[1] and other solutions based on collateral freedom[2] have huge potential to disrupt censorship from the outside.
[1] https://telex.cc
That's the plan. This is covered briefly in the second-to-last paragraph.
> so it was never really viable
Signal remained running for more than a year and a half in several countries that were actively trying to censor the service.
How do you encrypt SNI for cold start? For a future connection, I could see how, but at that point you may as well simply do a resumption.
... is the current state of work on this problem.
It's true that encryption (within the desirable parameters discussed in that ID) costs us a round trip, but it might be worth it for most of us most of the time.
Keep in mind the TLS you're using today for most sites has 2RTT setup, and we put up with that (if you have a modern browser and go to some major sites you end up using TLS 1.3 draft 23 and thus 1RTT)
The doc you sent is titled SNI encryption, but is really about tunneling a client hello through a proxy, and provides for the proxy to not send its own server hello, but only send the origin server's server hello. That's interesting, and should be useful for domain fronting and as a general purpose TLS proxy with fewer layers, but it's not really encrypted SNI.
In TLS 1.3 that 1RTT completes the handshake so as the client we know who we're taking to.
That SNI draft is the result of interested parties coming up with a list of desirable properties for SNI encryption. If you have a better idea that satisfies those properties you absolutely should propose it.
When a server has multiple identities to choose from, and the client has not previously communicated with (and has no no out of band information), as far as I can tell, either the SNI has to be in plain text, or it could be encrypted with an untrusted DHE key (which only eliminates passive detection).
Way upthread, bscphil wondered if [big companies] will oppose encrypted SNI to avoid having their IP ranges banned, but their business reasons don't really flow into a decision not to do impossible things.