501–510 of 519 posts
Earlier quoted context omitted.
Russia had no problem whatsoever blocking both of them when blocking Tether a couple weeks ago.
No problem? They crippled their own use of the internet, at huge financial cost.
Earlier quoted context omitted.
.... Because the US Military is responsible for changing a sovereign state's law if Americans don't like it? What the fuck?
Yes. It's called war. What's confusing here? If a citizen of a nation thinks that another nation is not behaving as they would like (whichever country or whatever behavior that is), the proper channels to enact change are through government action, either diplomatic or militarized. Asking a private corporation to be international police is not good for anyone, as well intentioned as it may seem.
> Asking a private corporation to be international police
This implies only police can and does enforce cultural and moral norms. This is the exact opposite of the correct order of things - the police should be preventing or punishing crimes, like theft, robbery, rape, murder, etc. - and people themselves - individually or in organized groups, like companies, NGOs, voluntary societies, etc. - should be creating and enforcing moral norms. You can not just delegate this to "the police", being it national or international.
Thus, asking Amazon to take part in helping to create an international norm of upholding free speech is reasonable. And their refusal is morally despicable.
Earlier quoted context omitted.
Isn't the first problem that mr Marlinspike has been holding off federation of the Signal protocol? If anyone could run a server and join the Signal network (like Riot/Matrix, who got it right), the problem of circumventing censorship would be a lot easier. Any one of these federated servers could use whatever tricks they like to circumvent censorship, and yes they'd risk getting banned themselves if their circumvent…
> I haven't heard a single reason for holding off federation from Moxie (and the "best" reason I currently can come up with is that he has issues letting go of "his baby", other reasons being more nefarious). I mean, there's no need to speculate here. There's an entire blog post on signal written about why they chose not to federate just a quick google search for 'signal federation' away, and the reasons, whether you…
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…
Amazon's general stance seems to be "spoofing is bad and makes the internet less reliable, so we're opposing it even here". It's understandable, but I think also thoroughly unjustified. If the objection is "Signal plans to impersonate us without our permission for a good cause", one obvious response is "so let's give them permission".
(Not coincidentally, this is a reasonable alternative to a lot of corporate heavy-handedness. Fighting trademark erosion by slapping down small businesses falls into much the same category - an alternative to coercing harmless-but-unauthorized users is to authorize them.)
Earlier quoted context omitted.
Amazon has a ton of customers, at least a few of which like https://preemptivelove.org/ are also doing good things in these countries. It's not just Amazon that suffers, but Amazon's customers and everyone else downstream.
I'm sure Amazon will be ok. They'll probably have enough money even with the loss to run the servers for that site I think.
Earlier quoted context omitted.
Push notifications? How do these work, when the app can't rely on access to any particular domain or IP? Your posts in this thread seem to include a great deal of hand-waving.
Here's a simplest push notification ever: email It was used by Akamai to do automated billing from the edges in the nineties when it was the first network that billed per byte delivered at the edges with multiple tiers. It is very easy to kill an annoying mosquito in a room if it can hide in 3 places. It is much more difficult if it can hide in thousands.
Earlier quoted context omitted.
> I haven't heard a single reason for holding off federation from Moxie (and the "best" reason I currently can come up with is that he has issues letting go of "his baby", other reasons being more nefarious). I mean, there's no need to speculate here. There's an entire blog post on signal written about why they chose not to federate just a quick google search for 'signal federation' away, and the reasons, whether you…
For completeness a counterpoint from one of prominent XMPP developers: An Objection to ‘The ecosystem is moving’: https://gultsch.de/objection.html
Earlier quoted context omitted.
https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encrypti... ... 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 majo…
Modern browsers (send ALPN) to sites with decent TLS 1.2 stacks (respond to ALPN, even if it's just to say http/1.1) get a 1RTT handshake on TLS 1.2 with TLS false start. TLS 1.3 is nice, but it's not required to get 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…
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.
Earlier quoted context omitted.
An HTTPS connection sends the domain it wants to connect to in two layers: first unencrypted in the TLS headers, then encrypted in the HTTP header. In a regular connection (even using a CDN), those two will match. Using domain fronting, you put a popular domain in the unencrypted part, and the real domain in a encrypted HTTP header. Due to how they're implemented, the load balancers at Google and Amazon will ignore t…
> only a custom app like Signal can perform domain fronting. Or curl, or openssl s_client. I'm still trying to understand domain fronting, and exactly what is being disallowed now. Do all of my CDN requests have to have identical Host headers and TLS server name indicators now? What if they're mismatched? Does the TLS handshake still succeed, and the traffic just doesn't get passed through the CDN server?
Sure.
I'm still trying to understand domain fronting, and exactly what is being disallowed now. Do all of my CDN requests have to have identical Host headers and TLS server name indicators now? What if they're mismatched? Does the TLS handshake still succeed, and the traffic just doesn't get passed through the CDN server?
Well, the current conflict is with Amazon; your CDN might or might not object to domain fronting.
Amazon is not saying that they must match, they're saying that you can't use someone else's domain for domain fronting without their permission. That is, if the domains don't match, whoever owns the domain indicated in the TLS server name must give express permission to do that.
I don't think their infrastructure can actually block it, they just ban your Cloudfront account if they happen to know this is going on. So you can probably get away with it if you keep quiet and nobody finds out.
Earlier quoted context omitted.
Modern browsers (send ALPN) to sites with decent TLS 1.2 stacks (respond to ALPN, even if it's just to say http/1.1) get a 1RTT handshake on TLS 1.2 with TLS false start. TLS 1.3 is nice, but it's not required to get 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…
In TLS False Start the client sends encrypted data to an unknown remote party. It hopes they're the intended recipient, but it won't actually know until it gets a reassuring Finished message which is too late. Now, if it isn't really the intended recipient the remote party doesn't have all the keys it should have. So cross fingers they can't decrypt the data they've been sent. But this is... less than ideal. It's a h…
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.