1. 31

  2. 28

    After reading the article and many HN comments, I found the headline to be highly misleading as if they’re targeting Signal for their activities in fighting censorship. It’s actually more incidental. They’re targeting a fraudulent practice Signal is doing that violates terms of service. Signal is doing it for good reasons but others might not. Google and Amazon are trying to stop it wholesale. A proper headline might be that “Several providers threaten to suspend anyone doing ‘domain fronting’ via hacks, including us.” Average person reading something like that would think it sounds totally to be expected. A technical person liking Signal or not should also notice the MO is an operational inconsistency that shouldn’t exist in the first place.

    So, they’re not doing a bad thing given the situation. They’re just an apathetic, greedy party in a business context fixing a technical problem that some good folks were using to help some other good folks deal with evil parties in specific countries. Sucks for those specific people that they did it but they’re not aiming at Signal to stop their good deeds. They’re just addressing an infrastructure problem that affects anyone hacking around with their service. Like they should.

    I wish Signal folks the best finding another trick, though.

    1. 16

      I think the correct headline would be “AWS is fixing a bug allowing domain fronting and calling it Enhanced Domain Protections”. An analogous situation would be console homebrew people exploiting buffer overflows in Nintendo games. Of course Nintendo should fix them, and like you, I root for console homebrew people to find another one.

      1. 3

        That’s another good one. It’s just a bug in their services. Them not fixing it would be more questionable to me.

      2. 9

        I found the headline to be highly misleading as if they’re targeting Signal for their activities in fighting censorship. It’s actually more incidental.

        And that’s why they immediately sent signal an email containing a threat to close the account immediately, instead of a regretful email telling them that this will stop working due to abuse prevention measures.

        1. 1

          It my experience that’s generally how they treat literally any issue.

        2. 5

          Signal is doing it for good reasons but others might not.

          I’m failing to think of a way to use domain fronting for a not good reason, especially one where the provider being fronted is still happy to host the underlying service.

          1. 4

            There is nothing fraudulent about domain fronting. Show me one court anywhere in the world which has convicted someone of fraud for domain fronting. That’s a near-libelous claim.

            Can you provide an example of a “bad reason” for domain fronting?

            As the article points out, the timing of Amazon’s decision relative to the publicity about Signal’s use of domain fronting suggests that Signal is in fact the likely intended target of this change, not incidental fallout.

            The headline is accurate. Your comment really mischaracterizes what is happening.

            1. 3

              I meant it in the popular definition of lying while using something. Apparently, a lot of people agree its use isn’t what was intended, the domains supplied are certainly not them, and service providers might negatively react to that. It would probably be a contract law thing as a terms of use violation if it went to court. I’m not arguing anything more than that on the legal side. I’m saying he was doing something deceptive that they didn’t want him to do with their services. Big companies rarely care about the good intentions behind that.

              “the timing of Amazon’s decision relative to the publicity about Signal’s use of domain fronting suggests that Signal is in fact the likely intended target of this change”

              The article actually says he was bragging online in a way that reached highly-visible places like Hacker News about how he was tricking Amazon’s services for his purposes. Amazon employees stay reading these outlets partly to collect feedback from customers. I see the cloud people on HN all the time saying they’ll forward complaints or ideas to people that can take action. With that, I totally expected Amazon employees to be reading articles about him faking domains through Amazon services. Equally unsurprising that got to a decision-maker, technical or more lay person, who was worried about negative consequences. Then, knowing a problem and seeing a confession online by Signal author, they took action against a party they knew was abusing the system.

              We can’t just assume a conspiracy against Signal looking for everything they could use against it with domain fronting being a lucky break for their evil plans. One they used against Signal while ignoring everyone else they knew broke terms of service using hacker-like schemes. If you’re insisting targeted, you’d be ignoring claims in the article supporting my position:

              “A month later, we received 30-day advance notice from Google that they would be making internal changes to stop domain fronting from working entirely.

              “a few days ago Amazon also announced what they are calling Enhanced Domain Protections for Amazon CloudFront Requests. It is a set of changes designed to prevent domain fronting from working entirely, across all of CloudFront.

              It’s a known problem they and Google were apparently wanting to deal with across the board per his own article. Especially Google. They also have employees reading forums where Signal was bragging about exploiting the flaw for its purposes. I mean, what did you expect to happen? Risk-reducing, brand-conscious companies that want to deal with domain fronting were going to leave it on in general or for Signal since that one party’s deceptions were for good reasons according to claims on their blog?

              Although I think that addresses it, I’m still adding one thing people in cryptotech-media-bubble might not consider: the manager or low-level employee who made the decision might not even know what Signal is. Most IT people I’ve encouraged to try it have never heard of it. If you explain what it does, esp trying to get things past the governments, then that would just further worry the average risk manager. They’d want a brick wall between the company’s operations and whatever legal risks the 3rd party is taking to reduce their own liabilities.

              So, there’s at least several ways employees would react this way ranging from a general reaction to an abuse confession online to one with a summary of Signal about dodging governments. And then, if none of that normal stuff that happens every day at big firms, you might also think about Amazon targeting Signal specifically due to their full knowledge of what they’re doing plus secret, evil plans to help governments stop them. I haven’t gotten past the normal possibilities, though, with Amazon employees reading stuff online and freaking out being most likely so far.

              1. 3

                This rings true to me (particularly the middle-management banality-of-evil take), bar one nitpick:

                The article actually says he was bragging online in a way that reached highly-visible places like Hacker News about how he was tricking Amazon’s services for his purposes.

                How did you get that impression? The article states:

                We’re an open source project, so the commit switching from GAE to CloudFront was public. Someone saw the commit and submitted it to HN. That post became popular, and apparently people inside Amazon saw it too.

                I haven’t read the mentioned HN thread, but that hardly constitutes “bragging online”.

                1. 2

                  I can’t remember why I originally said it. He usually blogs about his activities. I might have wrongly assumed they got it out of one of his technical write-ups or comments instead of a commit. If it was just a commit, then I apologize. Thanks for the catch regardless.

            2. 3

              “Service provider warns misbehaving customer to knock it off after repeated RFC violations.”

            3. 11

              “Domain fronting” wouldn’t exist as a misfeature if SNI was encrypted.

              If SNI was encrypted, Google or Amazon would probably still be unhappy about Signal’s use of their IP addresses. But, the conversation would be “Google / Amazon kicks Signal off the cloud” as opposed to “Signal fraudulently uses Google / Amazon’s domain name to combat censorship.”

              Food for thought wrt. the continued existence of unencrypted SNI, even post-TLS 1.3.

              1. 4

                How could SNI be encrypted? SNI determines which certificate should be used to encrypt and decrypt traffic. Maybe I’m missing something, but it looks like an egg and chicken problem.

                Update: Here is some slides about “encrypted SNI”. It makes sense only if the DNS query is encrypted too, and if the server IP cannot be used to indirectly identify the HTTP host.

                1. 9

                  The SNI Encryption in TLS RFC draft summarizes the issue far better than I can.

                  Update: “make sense only if…” is letting perfect be the enemy of good. Work is being done to encrypt SNI. Work is being done to encrypt DNS. Like peanut butter and jelly, both are good in and of themselves. And they’re even better together!

              2. 5

                2 cents: this is the reason why federated protocols make more sense, instead of centralizing, but moxie is against federation.

                the infrastructure should be owned by the users.

                i never quite got why signal is so hyped, you essentially just choose to trust them and not whatsapp/telegram/whatever with your metadata.

                1. 3

                  There’s always going to be a question of trust, and OWS is more independent than your examples. If something is federated and as secure and trustworthy, you got to have easy-to-use clients and trust in maintainership of the servers and the code base.

                  1. 3

                    While signal is open source, what should keep them from not deploying that version to their servers, but a slightly modified? Even if that’s not a problem with the chats being e2e encrypted, why should i trust them with the metadata? With federation I (or a party I know and trust) can run a server, and I am still able to talk to people on other servers (the other party has to be trusted with metadata too, but thats inherent to the problem).

                    I just don’t like the OWS cult. The classic advise “use signal and everythings gonna be fine” is misled. OWS is a single point of failure. People have to learn how technology works. Not the gory crypto details, but at least the 10000ft view. They use cloud resources. I’d expect that there are some parties that are more than interested in access to those servers. I know that this sounds a bit tin-foil-heady, but with the risk profile of signal, the first thing I’d do would be having my own infrastructure I can control. It’s just a compromise which doesn’t match the whole secure communitations idea.

                    Imagine: Someone other than OWS has access to the cloudy servers and deploys a version of signal server which exploits a flaw in the signal client, maybe a protocol parsing bug. I don’t know how good the client sanitizes the communication with the server, but I’ll guess the expectation is that the server is well behaving. Bingo, possibly all clients are pwnd. With federated services this seems to be much harder, as a) other parties should always expect malign behavior in such protocols b) just the clients of this one instance are affected. Other servers are probably running a different OS, with a different setup, in different countrys, which makes attacking every server much more complicated.

                    edit: fix b0rken english

                2. 3

                  Censorship detects the internet as damage and routes around it.