4 ms·
Can someone explain how does one serve content on a domain they don't own, like in this case Souq.com? Do they shove their content to something like product rev
by alpb 8y ago
Can someone explain how does one serve content on a domain they don't own, like in this case Souq.com? Do they shove their content to something like product reviews or what?
EDIT: I realized they use souqcdn.com. Does this mean it works because their clients use "souqcdn.com" to resolve to CloudFront CDN's IP address and then they craft a different Host header (like "Host: api.signal.org").
Also how can they possibly use CDN for this? As far as I know, CDN works only with GET requests, so how are they doing a chat app on this?
- pault 8y agoTFA explains it in detail.
- sincerely 8y agoWhat's TFA?
- deleted 8y ago[deleted]
- derivagral 8y agothe "friendly" article
- gruez 8y agothe fucking article
- monochromatic 8y agoThe Fucking Article
- tzakrajs 8y agoThe fine article
- basch 8y agothe father article
- detaro 8y agoThey aren't serving content on that domain. They just make requests look like they are going to that domain in the outer layer (by using it as the TLS server name), but the actual request inside the encryption is for a different domain they own. The load-balancer in front of the cloud service accepts the connection for souq.com (since it is responsible for that too it has the matching server certificate), decrypts the request, sees in the request that its for "signal.org" or whatever and delivers it there.
- mbrumlow 8y agoEven with GET request you can pack all sorts of stuff in the headers --- such as a message.
- xfs 8y agoThis is a recent technique for censorship circumvention called "domain fronting." See https://en.wikipedia.org/wiki/Domain_fronting https://en.wikipedia.org/wiki/Domain_fronting for details. Essentially when implementing encrypted channels with TLS, the domain name is still clear text in the SNI field, making the censorship circumvention scheme vulnerable to deep packet inspection. The technique is to modify the SNI field in TLS traffic to innocent domains. Major anticencorship efforts have all adopted this approach. Tor has it as meek. A while ago Google has disabled such usage for Tor. This is just another cloud vendor shutting down another anticensorship vendor. The real implications here are two things. First, domain fronting is built based on the deterrence of collateral damage, i.e. as a censor you wouldn't want to block TLS traffic with google.com SNI in it, but this deterrence viewed from the perspective of cloud providers is unwanted risks. Second, domain fronting in practice is abused by malware too much (in fact Tor is also a major malware enabler) and cloud providers can't accept this.
- snvzz 8y ago>the domain name is still clear text in the SNI field Something which could have been fixed on TLS 1.3, but didn't happen. Very unfortunately.