1. 7
  1. 15

    Wait, what? Do I understand this correctly?

    Cloudflare fixes a problem that they created themselves by inserting Cloudflare in between an app publisher and a user by asking the user to install a Cloudflare extension so that it can query a Cloudflare endpoint to make sure Cloudflare did not mess with said website app?

    And also: do they really direct my Firefox browser to a Chrome extension in the same article where they argue that ‘Security should be convenient’?

    1. 8

      I believe you misunderstood and the main picture of the article explains it actually really well.

      • Whenever WhatsApp is making a new release of their website, they upload the cryptographic hashes of the assets to cloudflare
      • Whenever you open the WhatsApp website, the “Code Verify” extension will be able to compare the software delivered from WhatsApp with a hash from a “trusted third-party” (Cloudflare), to ensure it is indeed the latest and has not been tampered with.

      I suppose the idea is that internet access to Cloudflare is even harder to mess with undetected than WhatsApp and through their partnership, WhatsApp is profiting from their reach.

      1. 7

        Let me explain my.thought process a bit, because I still don’t get it.

        Without Cloudflare:

        • WhatApp releases a new version of their app.
        • A user requests it straight from WhatsApp’s server.
        • The user trusts the app, because they requested it over HTTPS and the certificate belongs to WhatsApp. So they got it directly from the people that made the app and no-one could interfere.

        With Cloudflare before the solution described in the article:

        • WhatsApp releases a new version of their app and makes that available through the Cloudflare CDN.
        • A user requests it from this CDN, over HTTPS, but doesn’t see WhatsApps’s certificate. Instead it is from Cloudflare. Hmm… Who are these people? Can they be trusted to serve the right app? Are rheir processess secure and in order?

        With the solution described:

        • WhatsApp releases a new version of their app, makes that available through the Cloudflare CDN, also uploads the hash to that special hash thingie
        • A user requests it… yadayada. Can these Cloudflare people be trusted?
        • Yes! Because beforehand, the user installed a Cloudflare extension and that extension now checks whether the hash from the app matches with what the Cloudflare hash thingie says it should be.

        So what I mean is: if you suspect that Cloudflare could be compromised in any way, why would this be better?

        1. 6

          In the proposed [and current] solution:

          1. WhatsApp releases a new version of their app, updates resources on their servers/CDN.
          2. WhatsApp notifies CF of the new version using the dedicated CF endpoint.
          3. A user requests WhatsApp from WhatsApp’s server. The request is served straight from Whatsapp servers/CDN.
          4. The (chrome) extension in user’s browser verifies the web app downloaded in the previous step via the dedicated CF endpoint.

          So steps (1) and (3) are business as usual. Steps (2) and (4) add a further level of security/verification:to deliver a forged/tempered version of whatsapp the attacker should compromise both WhatsApp and CF endpoint. This works under the assumption that the system (from WhatsApp) pushing the hashes to the the CF endpoint is somewhat separated from the system (from WhatsApp) serving the web app.

          1. 1

            I believe their solution achieves tamper resistance against active man in the middle attacks for TLS (probably not in most people’s thread model). But they say it’s for an “at risk” user population 🤷‍♂️

        2. 2

          I’m just as confused. Once they have an extension to verify the right code is being downloaded, why would CF need to do anything special? It’s just a file mapping the version to a hash, stored in some service - it could live in a tweet if they wanted, as long as the hashes and the code come from different sources/paths.

        3. 2

          The source of the extension is on GitHub if someone wants to figure out how this actually is supposed to work - https://github.com/facebookincubator/meta-code-verify/

          1. 4

            They are currently not using Subresource Integrity but working around that with a combination of fetch(), TextEncoder() and crypto.subtle.digest(). That’s really surprising.

            I would have assumed that they register a ServiceWorker to handle all fetch events and then replace the existing request with a fetch(sameURL, { integrity: expectedHash})… The variables have names like workaround, so maybe they are dealing with some browser inconsistencies here?

            (Using TextEncoder is also a bit error-prone. I wrote it up for them in https://github.com/facebookincubator/meta-code-verify/issues/128).

            1. 2

              Does this offer anything over just using subresource integrity?

              1. 2

                It adds a further (and “independent” from the web app provider) audit point. Suppose an attacker compromises whatsapp web server/CDN, she would be able to change as well subresource integrity hashes in the HTML source of the web page. With Code Verify she would have also to compromise CloudFlare verification endpoint (with the compromised hashes).