Google shuttering domain fronting, Signal moving to souqcdn.com
github.com
github.com
Amazon also recently acquired Souq so wondering if the 'same large provider' in this case is AWS?
A lot of companies, including Google and Amazon, run a bunch of reverse HTTP proxies (called "edge caches") all over the world as a way to reduce latency, since if the cache already contains a file, it doesn't have to go all the way to the backend server to get it. They don't just spread the backend servers themselves all over the world because they're more expensive, they're optimized for particular applications, and because database consistency gets harder and harder the more you spread out the replicas.
Since the edge caches are application-agnostic, the same one can also be reused for multiple apps. Your browser, then, can talk to the same edge cache all the time even when it's actually interacting with several different services. This is where domain fronting comes in.
As a quirk in the application protocol, your browser ends up sending out the domain name it wants to interact with three times:
1. During domain resolution, where it uses the DNS protocol to convert the relatively human-readable names into IP addresses. In a domain fronting session, this step has to use the "front domain".
2. During TLS negotiation, where it requests a signed certificate corresponding to a domain. In a domain fronting session, this step also has to use the "front domain".
3. During the HTTP request. HTTP doesn't just rely on the DNS one, because the same IP might have multiple domains, and it doesn't just rely on TLS, because HTTP is supposed to be able to work over plaintext. In most edge cache implementations, the HTTP domain is the only one that's actually used to decide which backend server to talk to, so a domain fronting implementation like Signal will use the "target domain" here, and since this is part of the HTTP session, MITM-based blocking systems can't see it.
notriddle@DESKTOP-IIQA1VP:~$ host souqcdn.com
souqcdn.com has address 46.137.109.63
notriddle@DESKTOP-IIQA1VP:~$ host 46.137.109.63
63.109.137.46.in-addr.arpa domain name pointer ec2-46-137-109-63.eu-west-1.compute.amazonaws.com. server-52-85-146-234.iad12.r.cloudfront.netWe're using Souq because it is popular in the countries where we have Censorship Circumvention enabled (Egypt, Oman, Qatar, and UAE) but it would be nice to have other options on CloudFront as well. It's possible that we overlooked other highly ranked domains in these countries that use the CloudFront CDN.
If anyone has any suggestions, we would appreciate them.
If the censors somehow didn't hit every single worthwhile federated endpoint, users would still be left wondering why they couldn't communicate with most of their friends. Moving between federated hosts would also necessitate an entirely new identifier, so users would need to rebuild their social graph again.
In addition to being ineffective against censorship, there are several other properties and trade-offs that make federation a difficult proposition for an application like Signal: https://signal.org/blog/the-ecosystem-is-moving/
That's not how federation works, at least in XMPP. You only need to connect to one server that's out of censorships' reach to be able to communicate with everyone.
While it's true that my friends on other servers might be able to send messages that will arrive on my chosen server, that distinction isn't very meaningful because I am unable to connect and retrieve those messages.
I wouldn't be communicating with my friends until I switched to a new server and rebuilt my social graph.
Also, while it's not specified in XMPP (yet), it's easy to imagine a federated service that lets you connect to any server in the network that then behaves as a proxy to whatever server you have your account on.
With domain fronting, you can exfiltrate data from a company by making the connection appear to go to a legitimate google service (ex: drive.google.com), whereas it actually is going to a server hosted on google cloud services and controlled by an attacker.
Who else do you think should decide who gets to host content through Google's servers?
Google is not accessible to about 1.4 billion people because the single government of China "dares" to censor Google. That's close to 20% of the world's population.
I don't think companies nor governments should get to decide this at all. Information wants to/should be free.
[1] https://www.fireeye.com/blog/threat-research/2017/03/apt29_d... [2] https://www.cyberark.com/threat-research-blog/red-team-insig...
Google can respond to Russia with a single "OK, lets see" and block all Russian IP addresses from accessing/using any and all Google resources. Such action would create the kind of pressure on the Russian government it would within days change its decision -- it is not that the top of the Russian society does not rely on services provided by Google in a day to day life. It is that top that matters. Leaning on them creates leverage.
Compromising one's principals allows competitors to exploit one's weak principals.
https://www.theverge.com/2018/4/18/17253784/google-domain-fr...
https://en.wikipedia.org/wiki/Domain_fronting circumvents Internet censorship by hiding the true endpoint of a connection
Host: signal.org
This will only work with compatible servers. In Signal's case they use AppEngine which is behind Google's network and the servers for google.com are able to connect to their app servers when given the appropriate Host header.
Is this related to Russia blocking a ton of google IPs to enforce the telegram block, or is that a separate thing entirely?
Completely separate.
In-depth explanation of Domain Fronting: https://www.bamsoftware.com/papers/fronting/
https://www.torproject.org/docs/pluggable-transports.html.en
Not the case since meek-google was discontinued long ago, meek-amazon and meek-azure don't rely on Google as a front. It does affect however Moat and Snowflake, all of them are still only available in the alpha releases.
https://medium.com/@pmvk/domain-fronting-a-technique-used-to...