Let’s say, I create a bank with the caveat that all of my banking phone apps and webapps are FOSS (or if they depend on non-free components — banks probably do to communicate with each other —, then just OSS). Am I going to be behind the competition by doing this?

If the most secure crypto algorithms are the ones that are public, can we ensure the security of a bank’s apps by publicizing it?

Are they not doing this because they secretly collect a lot of data (on top of your payment history because of the centralized nature of card payments) through these apps?

EDIT: Clarifying question: Is there a technical reason they don’t publicize their code or is it just purely corporate greed and nothing else?

  • freedomPusher@sopuli.xyz
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    1 year ago

    I’m well aware that Cloudflare holds the TLS keys. I’m also well aware that that does not equal having access to credentials.

    Can you elaborate? I believe the hashing must be done on the server side not the user side, so Cloudflare would see the creds before hashing. I know it’s possible to subscribe to an enterprise package where you hold your own SSL keys, but it’s unclear why CF would even be used in that scenario. If CF cannot see the traffic, it cannot optimize it as it all has to be passed through to the original host anyway. AFAICT, CF’s only usefulness in that scenario is privacy of the websites ownership - something that banks would not benefit from.

    Banks certainly can not outsource willy nilly. Or well, I suppose they may in some jurisdictions, but the context here is Europe, where the banks actually are regulated.

    US banks outsource with reckless disregard. Europe is indeed different in this regard. But European banks have no hesitation to outsource email to Microsoft or Google and then to use email for unencrypted correspondence with customers. That crosses a line for me.

    European banks will also outsource investments to JP Morgan (one of the most unethical banks in the world), and they tend to be quiet about it. I boycott JPM along with other similar banks in part due to investments in fossil fuels and private prisons. This means banking in Europe is a minefield if you boycott the upstream baddies.

    • sweng@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 year ago

      Without TLS termination Cloudflare is still useful for e.g. DDoS protection, and serving content that do not contain client information.

      Caching client data globally using Cloudflare would be pretty pointless and help very little and probably even be harmful to performance, so them having the TLS key for it would absolutely not be worth it.

      • freedomPusher@sopuli.xyz
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        1 year ago

        Without TLS termination Cloudflare is still useful for e.g. DDoS protection,

        I’m not seeing that. Cloudflare’s DDoS protection is all about having the bandwidth to serve the traffic. If CF cannot treat the traffic itself (due to inability to see the payloads), that whole firehose of traffic must be passed through to the original host which then must be able to handle that volume. CF’s firewall in itself is not sophisticated enough to significantly reduce the traffic that’s passed along. It crudely uses IP reputation which can easily be done by one’s own firewall. What am I missing?

        • sweng@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          Well, it seems people are prepared to pay quite a bit for cloudflare DDoS protection. Maybe you are right, and they are all wrong. But it does not really matter, because they cmearly have convinced people that it is worth paying for it, even if you disagree.

          • freedomPusher@sopuli.xyz
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            1 year ago

            I’m not looking to be proven right. The purpose of the tangent discussion was to substantiate whether or not bank creds are exposed to CF. If banks are actually protecting consumer creds from CF, then it requires a bit of analysis because banks don’t even disclose the fact that they use Cloudflare. They make the switch to CF quietly and conceal it from customers (which is actually illegal - banks are supposed to disclose it but it’s not enforced in the US). AFAICT, CF’s role is mostly useless if the SSL keys are held by the site owner.

            In the US, the financial system is quite sloppy with user creds and user data. There are even a couple 3rd-party services (Yodlee / Mint) that ask customers for their banking creds at all the places they bank. This service then signs on to all the banks on behalf of the customer to fetch their statements, so customers can get all their bank statements in one place. IIRC some banks even participate so that you login to a participating bank to reach Yodlee and get all your other bank statements. Yodlee and Mint are gratis services, so you have to wonder how they are profiting. The banks are not even wise enough to issue a separate set of read-only creds to their customers who use that Yodlee service. In any case, with that degree of cavalier recklessness, I don’t envision that a US bank would hesitate to use CF in a manner that gives the bank the performance advantage of CF handling the traffic directly. But I’m open to convincing arguments.

            • sweng@programming.dev
              link
              fedilink
              arrow-up
              1
              ·
              1 year ago

              AFAICT, CF’s role is mostly useless if the SSL keys are held by the site owner.

              It seems like a lot of your points hinges on this being true, but it simply isn’t. There is a massive benefit to preventing DDoS attacks, and that does not require keys. There is no indication that banks are handing over client ctedentials to CF.

              • freedomPusher@sopuli.xyz
                link
                fedilink
                arrow-up
                1
                ·
                edit-2
                1 year ago

                It seems like a lot of your points hinges on this being true, but it simply isn’t.

                “AFAICT” expands to “as far as I know”, which means the text that follows not an assertion. It’s an intuitive expectation that is open to be proved or disproved. The pins are all set up for you to simply knock down.

                There is a massive benefit to preventing DDoS attacks, and that does not require keys.

                This is unexplained. I’ve explained how CF uses its own keys to offer DDoS protection (they directly treat the traffic because they can see the request). I’ve also explained why CFs other (payload-blind) techniques are not useful. You’ve simply asserted the contrary with no explanation. HOW does CF prevent DDoS in the absence of treatment of the traffic? Obviously it’s not merely CFs crude IP reputation config because any website can trivially configure their own firewall in the same way without CF. So I’m just waiting for you to support your own point.

                There is no indication that banks are handing over client ctedentials to CF.

                This is trivially verifiable. E.g. if you get the SSL cert for eagleone.ns3web.org, what do you see? I see CF keys. That means they’re not using the premium option to use their own keys. Thus CF sees the payloads. I’m open to being disproven so feel free to elaborate on your claim.

                • sweng@programming.dev
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  edit-2
                  1 year ago

                  any website can trivially configure their own firewall in the same way without CF.

                  How many websites can handle the amount of traffic that CF can handle? It’s not just about configuring your firewall, it’s about having the bandwidth. Otherwise it’s not much of a DDoS protection.

                  I see CF keys.

                  As I don’t have an account there I can’t see which requests containing credentials use which cert.

                  And also, just because the cert is verified by cloudflare does not mean they have the private key.

                  • freedomPusher@sopuli.xyz
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    edit-2
                    1 year ago

                    How many websites can handle the amount of traffic that CF can handle? It’s not just about configuring your firewall, it’s about having the bandwidth. Otherwise it’s not much of a DDoS protection.

                    That’s what I’ve been saying throughout this thread. The only significant DDoS protection offered by Cloudflare requires CF seeing the traffic (and holding the keys) so it can treat the high-volume traffic. If CF cannot see the payloads, it cannot process it other than to pass it all through to the original host (thus defeating the DDoS protection purpose).

                    As I don’t have an account there I can’t see which requests containing credentials use which cert.

                    Why would you need an account? Why wouldn’t bogus creds take the same path?

                    If it’s true that this is unverifiable, that’s good cause to avoid Cloudflared banks. It’s a bad idea for customers to rely on blind trust. Customers need to know who the creds are shared with /before/ they make use of them – ideally even before they make the effort of opening an account.

                    And also, just because the cert is verified by cloudflare does not mean they have the private key.

                    This uncertainty is indeed good cause to avoid using a Cloudflared bank.

                    UPDATE: I’ve spoken to some others on this who assert that it is impossible for a bank customer to know for certain if a bank uses their own key to prevent disclosure to CF.