331–340 of 519 posts
Earlier quoted context omitted.
Reasonable, but cowardly and disgusting.
Maybe point that anger towards the government and military then, instead of a private corporation with thousands of business customers and millions of consumers.
Why can’t they use raw HTTP vs HTTPS and use an encrypted payload? That handles the SNI front as they outlined as the detection mechanism hindering them. I’m sure there’s more to it because this seems pretty basic, but curious the reason why this was ruled out.
Why can’t they use raw HTTP vs HTTPS and use an encrypted payload? That handles the SNI front as they outlined as the detection mechanism hindering them. I’m sure there’s more to it because this seems pretty basic, but curious the reason why this was ruled out.
The other technique that might be useful to register lots and lots of obscure domain names and rotate them regularly. Might cost a bit in SSL certs.
Earlier quoted context omitted.
Exactly, free countries (or those who consider themselves as such) should make it fully illegal for private companies to aid in any kind of censorship in behalf of oppressive countries. But what we see in reality is the opposite, all companies trying to make it as cheap and as simple as possible to censor anything every government dislikes; meaning the liberal fantasy of allowing every private company to do as it ple…
As you note, private companies are typically free to do as they please in free countries...that's kinda the point. You have no right to use AWS, so this is not censorship in the legal sense. And free governments also tend to have strong laws respecting the sovereignty of other nations, whether or not their laws are similar. Your frustration is noble, but it's also internally inconsistent.
Nonetheless, among such regulations, designed to make private companies somewhat work for the general public interest, we can include not aiding censorship.
Why can’t they use raw HTTP vs HTTPS and use an encrypted payload? That handles the SNI front as they outlined as the detection mechanism hindering them. I’m sure there’s more to it because this seems pretty basic, but curious the reason why this was ruled out.
The issue here isn't that the content can be read, it's that oppressive regimes can censor content from apps like Signal completely. It's a question of hiding the source/destination, not the contents.
2) I have to assume they aren’t relying on traditional dns alone because that’s the first thing countries like the UAE filter on, so if dns blocking was an issue, they’d be dead before domain fronting would be needed.
3) the mechanism claimed for detection now is TLS SNI. So my point is remove that part and secure contents otherwise thus moving the cat and mouse game further!
They're spoofing identity of non-consenting parties. The cause is noble, but it isn't what the headline would imply. Amazon isn't saying "You can't host encrypted services on our platform", they are saying "You can't use TLS and load balancing hacks to pretend to be us in oppresive countries". And >The idea behind domain fronting was that to block a single site, you’d have to block the rest of the internet as well. I…
> "They're spoofing identity" That's the entire point. By making it impossible for censors to distinguish Signal traffic from other web traffic going to AWS, domain fronting forces the government censors to either 1) stop censoring, or 2) censor many important websites that people rely upon. The associated economic cost has the tendency to discourage censors, and as shown by Signal, is actually quite an effective det…
I'm not saying Amazon is evil or anything, but if a bunch of hugely important customers started getting their traffic blocked by huge geographic segments due to another unrelated customer.... business is business.
Earlier quoted context omitted.
Morally, it's still the right thing to do, even though I guess it's in amazon's best interests not to allow it.
How is it moral for Amazon to shirk their fiduciary duty to shareholders for the sake of a political battle it isn't theirs to wage? I counter it would be more immoral to put, say, the retirement funds of firefighters and teachers arty risk to achieve what is the responsibility of, say, the State Department?
Earlier quoted context omitted.
>You can't use TLS and load balancing hacks to pretend to be us in oppresive countries They're not pretending to be Amazon, they're pretending to initiate a connection to an Amazon domain. The "conversation" goes like so: Clear text request: "Hello, I would like to speak TLS with souq.com" Clear text response: "Why yes, let us do that with these parameters" Encrypted request: "Please give me the page for signal.org/a…
This important description of the actual implementation of domain fronting — namely that it’s implemented on the client side, and only as a cover for initializing the TLS channel — I think is very important and unfortunately missing from TFA. There is nothing on the server side which is masquerading as Amazon or Google. There is no impersonation or spoofing whatsoever. This is akin to making a DNS lookup for a differ…
- This most definitely is against the CloudFront terms of service. See the linked article if you disagree - the ToS is quoted there.
- One direct impact to the owners of the SOUQ.COM domain is that their DNS query volume will increase drastically. They have to pay for those queries. Would you like it if your side project all of a sudden got a 6 figure DNS bill because Signal decided they want to piggy back on your domain to route around censorship?
Why can’t they use raw HTTP vs HTTPS and use an encrypted payload? That handles the SNI front as they outlined as the detection mechanism hindering them. I’m sure there’s more to it because this seems pretty basic, but curious the reason why this was ruled out.
That occurred to me too. But HTTP/1.1 requires a Host: header. It also brings a problem of key distribution. The other technique that might be useful to register lots and lots of obscure domain names and rotate them regularly. Might cost a bit in SSL certs.
Yes, but that’s easily forgeable as long as the servers in between allow it.
> It also brings a problem of key distribution.
Not really, you can still do chain of trust SSL validation on a payload in the body of HTTP as you could to encrypt the entire HTTP connection as in the case of HTTPS.
> Might cost a bit in SSL certs.
LetsEncrypt could help there.