4 ms·
I really dislike the way they put it in the title of this post. What they are doing is simply abusing the name/size of a totally unrelated company to mask signa
by mvanbaak 8y ago
I really dislike the way they put it in the title of this post.
What they are doing is simply abusing the name/size of a totally unrelated company to mask signal traffic.
While I am totally in favor of signal, simply using a domain name you dont own in the SNI header just because it is terminated at the same service as you want to use is something you cannot do.
They could have simply have sent the question to the owner of the domains (google and amazon) explaining what they wanted to do, and only think about implementing it when the owner agreed.
And last but not least to answer those: 'why would they even care, the traffic goes to cloudfront anyways?' ... It will seriously mess up the stats (and billing, yes, amazon owned companies pay internal bills to aws for usage, it's a very normal way of doing business and get your taxes right).
It's sad that tricks like these are being considered/needed to have access to internet services in some parts of the world, but simply doing it without all parties involved knowing about it and agreeing on it is _NOT_ the way to do it.
- wildfire 8y agoIf this would "seriously mess up the stats", then arguably the CDN is doing it wrong. It should bill on the inner (encrypted) domain and not what is outside.
- mvanbaak 8y agoStill, the initial package is meant for the infra of the outer domain. Sure, the real payload will be billed to the inner domain owner, but not the initial handshake (and usage of keys etc)
- nebulous1 8y ago> simply using a domain name you dont own in the SNI header just because it is terminated at the same service as you want to use is something you cannot do Why not out of curiosity? I'm not disputing Amazon's right to disallow this (it's their service after all), but before that I don't see any objective reason why this is something they they "cannot" or even "should not" do. Also, unless Amazon put in a technical barrier (which they are in the process of doing), then they can't stop a third party from doing it anyway (i.e. me personally sending a different domain in the SNI header than the one I actually end up communicating with), and on that level (ie me rather than Amazon's customer) I see no reason why I wouldn't do exactly that if my ISP was blocking the target domain.
- mvanbaak 8y ago> Why not out of curiosity? Because you are lying about what domain you want to access. This is against the TOS, and simply something you should not do. I know it helps signal to get around censorship and blocks, and it's technically working, but one should not do that.
- Tepix 8y agoYou are only pretending to contact a certain address during the (short) unencrypted phase of the request. As soon as encryption is present you reveal the real address you want to talk to. The only ones getting spoofed are the censors.
- mvanbaak 8y agoCorrect. But still it's something one should not do and is against the TOS of AWS Cloudfront.
- nebulous1 8y agoI'm not lying about anything. This entire system is designed so that the user can get what they're looking for, and the user is using it to get what they're looking for. Whether doing this as AWS's customer breaks their TOS is up for debate, but it's a fairly moot one as Amazon could easily change their TOS.
- trumped 8y agoCan't amazon use different domain names for different customers to avoid this issue?
- mvanbaak 8y agoIt's not an issue with 'domain names per customer' but with SNI. Because ip addresses are limited (well, ipv4 at least) they cannot use dedicated ip's per domain name. That's the whole issue.