1. 3

    Very nice article. One interesting addition would be MTA-STS.

    1. 1

      And TLS-RTP. Hardenize has good primers on both:

    1. 13

      Some of the ‘alternatives’ are a bit more iffy than others. For any service that you don’t have the source to or can’t self-host (telegram, protonmail, duckduckgo, mega, macOS, siri to name a few), you’re essentially trusting them to uphold their privacy policy and to respect your data (now, but also hopefully in the future).

      And in some cases it seems to me that it’s little more than fancy marketing capitalizing on privacy-conscious users.

      1. 18

        Telegram group messages aren’t even e2e encrypted, Telegram has access to full message content. The only thing Telegram is good at is marketing, because they’ve somehow convinced people they’re a secure messenger.

        1. 6

          To be fair, they at least had the following going for them:

          • no need to use a phone client, as compared to WhatsApp which deletes your account if you access it with an unofficial client. You can just buy a pay-as-you-go SIM card and receive your PIN with a normal cell-phone
          • they had an option for e2e encrypted chats, with self deleting messages (there was this whole fuss with the creator offering a million dollars (?) if anyone could find a loophole)
          • their clients were open source, and anyone could implement their API

          Maybe there was more, but these were the arguments I could think of on the spot. I agree that it isn’t enough, but it’s not like their claim was unsubstantiated. It just so happened that other services started adopting some of Telegrams features, making them loose their edge over the competition.

          1. 4

            Also the client UX is pretty solid imho. Bells and whistles are not too intrusive, and stuff works as you’d expect.

            Regarding its security: It is discussed in the FAQ what security models they offer in which chat mode.

          2. 6

            I’m much less worried about the source code than I am the incentives of the organization behind the software. YMMV, of course.

            1. 2

              Even if you have source code, it’s difficult to verify a service or piece of software (binary) matches that source code.

              1. 2

                Yes, but then if anything feels wrong, it gets possible to find an alternative provider for the same software.

                Still… Hard to beat the privacy of a hard drive at home accessed through SFTP.

              2. 2

                I was checking email SaaS providers last weekend as the privacy policy changes at current provider urge me not to renew my subscription when it ends. I have found mostly the same offers, and to be honest neither seemed convincing to me.

                For example the Tutanota offer seemed questionable: They keep me so secured that the email account can only be accessed by their email client, no free/open protocol is available. Only their mail client can be used, they use proprietary encryption scheme for my own benefit… OK, it is open sourced, but come on… I cannot export my data in a meaningful way to change providers. So what kind of encryption scheme is it? It is RSA-2048+AES, not using GPG/PGP “standards”, and is hosted in Germany, pretty much a surveillance state… This makes their claims questionable at least.

                1. 4

                  Be careful before using this, it’s trivially vulnerable to server side request forgery (i.e. if your server tries to fetch a user-submitted url they can pass urls or ip addresses on your private network).

                  1. 2

                    Good point. There should definitely be some care taken with the urls. I don’t think it’s that much of an issue though in this case. Jsdom only accepts html and xml formatted responses. Worst case scenario, it returns all the open graph and twitter tags from an internal document. Accepted urls should be monitored closely but sensitive information really shouldn’t be placed in Open Graph tags.

                    1. 4

                      I don’t think it’s that much of an issue though in this case. Jsdom only accepts html and xml formatted responses. Worst case scenario, it returns all the open graph and twitter tags from an internal document.

                      • even if internal documents shouldn’t have sensitive information in meta tags, you have no guarantee of that. Someone who pulls in this library would have no idea that that’s a requirement, it’s not called out anywhere and even if it was they might miss it. Also why would this library force that restriction on an organization, perhaps it’s very reasonable for them to put some content into a tag, when they consider it to be in the internal network?
                      • returning page content isn’t the only bad thing that can happen, so it’s moot that JSDOM expects an html or xml response. There have been many cases of SSRF being escalated to RCE by hitting non-http services (for instance http://blog.orange.tw/2017/07/how-i-chained-4-vulnerabilities-on.html, http://www.kernelpicnic.net/2017/05/29/Pivoting-from-blind-SSRF-to-RCE-with-Hashicorp-Consul.html, and others). Right now it happens to be the case that you don’t have any user input in the body, but there’s no guarantee that won’t change in the future either. Vulnerabilities are introduced like this all the time - it looks safe and then a change is made down the line because no one understands or realizes the assumptions being used.
                      • even without RCE risk, internal services can have mutating effects from GET requests. They’re not supposed to, it’s against the RFC, but developers do it all the time. Google and Twitter services built internally have special GET endpoints /quitquitquit and /abortabortabort that kill services - if your package was deployed internally there someone could use it to take down production services.

                      Not trying to be harsh - I think it’s a useful library if you make it secure by default. There are existing libraries that do SSRF filtering for you - you could swap in one of those to fetch the page contents and pass that to JSDOM.

                      Libraries really have to be secure by default, otherwise developers will mess it up, 100% guaranteed.

                      1. 3

                        Not trying to be harsh

                        That’s really not harsh at all. I’m a student; I learn through conversations like this.

                        I see what you mean. It would make sense to have an ssrf option and I’ll work on adding that. I’m pretty sure it’s only ever going to send get requests though and get endpoints that kill services should be heavily protected. I get that “should” doesn’t imply “would” but having unauthenticated get endpoints that kill internal services has to be seen as careless.