30

I was looking at my bank website's certificate and discovered that it's issued to multiple websites, and the bank's domain name is only listed among many other domains in the 'alternative names' field.

Is this considered a bad practice? What risks are their customers subjected to? (man in the middle? impersonation?)

SSL Labs screenshot

5
  • This seems like bad practice, since all these other parties have the same private key if they are also using this certificate. This means that compromise of any of there other sites can mean that your SSL traffic is no longer safe.
    – Silver
    Jul 7 '16 at 12:56
  • 16
    A bank using 3rd-party, 3rd-country CDN with SSL interception... I would rather close the account.
    – techraf
    Jul 7 '16 at 13:08
  • 8
    "looking at my bank website ..." - What part of the website is that? Is it just the static welcome, we're-the-bank-with-the-many-images-of-happy-employees-and-customers-on-our-site part, or is it the part which includes the log-in form and maybe the stuff behind that?
    – JimmyB
    Jul 8 '16 at 9:32
  • 4
    I don't think many people answering actually bothered to check the contents of the website you have queried. This is just the bank's information pages, marketing, etc. As soon as you actually attempt to log into the banks actual banking service, you are directed to a different domain that has an EV certificate and does not route through Incapsula. There's nothing unusual or too concerning about this. Jul 8 '16 at 14:31
  • 4
    @JimmyB even if the welcome page doesn't include a log-in form, it almost certainly includes a link to the login form. An attacker can do a lot of damage by changing that link.
    – bdsl
    Jul 8 '16 at 21:57
50

It is a certificate of a content delivery network – a U.S. company Incapsula Inc. – intercepting your whole communication with the bank. The certificate itself does not pose a direct risk to customers' data, but:

Is this considered a bad practice?

Unlike the other answers, I would say it is not normal and the situation indicates a certain level of incompetence on the bank's side.

  1. According to Incapsula's pricing plans, your bank might be using $59/month, while the company offers custom SSL for $299/month (feature "Supports custom SSL certificates") and a real plan for enterprises.

  2. Even if the bank pays more to CDN, the bank is using functionality aimed at professional blogs and not using the features their plan/agreement offers.

  3. Your bank may be violating privacy laws in your country by letting a company from another country, under a different legislature, process customers' personally identifiable data.

What risks are their customers are subjected to? (man in the middle? impersonation?)

The data in a encrypted between your browser and the CDN's endpoint. The private key is (hopefully) stored only on CDN's servers, so there is no risk other companies from the list could impersonate the bank.

As long as security standards are met on a link between CDN and the bank, the MitM is technically not possible either.

3
  • 2
    I would note that the whole point of a CDN is to server traffic from many distributed locations to improve performance and/or avoid attacks. Unfortunately for https this means spreading the keys to the kingdom far and wide. Using a seperate certificate for each customer would make it less obvious what is going on but wouldn't really improve security. Jul 7 '16 at 18:48
  • 20
    I would point out that, contrary to your last point, the CDN technically is MitM-ing every connection to the bank. They (probably) aren't maliciously doing anything bad, but it is a risk and it does increase the exposure of sensitive banking info/credentials because a compromise at either the bank or the CDN can expose confidential financial data to attackers. What is (hopefully) impossible is for an additional MitM between either customer and CDN, or CDN and bank, but you can't forget that the CDN is itself, by definition, a MitM.
    – Kromey
    Jul 7 '16 at 19:10
  • 2
    Yes, it is a risk (even bigger as the CDN is seemingly in a different legislature, which I mentioned), but it's not the risk coming from the fact that the certificate is shared among different domains, which was the question. If the bank used its own certificate, it wouldn't change the situation.
    – techraf
    Jul 7 '16 at 23:12
5

Notice incapsula.com in the subject. Incapsula is a company that offers web application security that includes WAF, DDOS protection and a few more services.

My guess is that your banks website is actually proxied through their server and so are all those other sites. That server gives out the same certificate on all those sites because they are all actually proxied through the same server.

There is no reason to worry here.

1
  • 3
    techraf's answer indicates that while the first two paragraphs may very well be correct, the conclusion in the third may be premature.
    – user
    Jul 8 '16 at 8:25
2

This may be normal.

Banks often consolidate, purchase, cross-market, and do all sorts of things that mean that they're answering to more than one name. It is not unusual for a bank to have numerous SAN entries to allow all their varied customers to get to their web site, even if they're a customer of a bank purchased by a bank purchased by a bank purchased by a bank that was purchased by a bank that they've acquired.

You may wish to check if those other names listed resolve to the same IP address and/or are served by web sites using the same certificate. If those domains truly do share a common owner, this may be somewhat normal practice.

In security terms, it is potentially worse - if the private key is shared out to numerous servers, numerous admins - but not definitively. You don't know enough about what's actually happening behind the scenes to say.

4
  • 12
    Look at that screenshot. It has many not bank related domain names like nescafemountainwash.com.my in it. Your SAN explanation makes no sense.
    – SPRBRN
    Jul 7 '16 at 13:20
  • I personally have never understood why SSL only provides one layer of cryptographic security. What would be ideal in this case would be if the SSL content were encrypted twice: one layer is stripped-off by the proxy host, leaving a second layer to be stripped-off by the bank. This would enable the proxy to handle the traffic without knowing what it contained. It would also allow the two parties that are "ultimately communicating" (the bank and its customer) to recognize one another in spite of the proxy. Jul 8 '16 at 13:20
  • @MikeRobinson, you can see some answers (pro and con) to that idea here (...has anyone used PGP or AES to encrypt the actual data inside SSL?)
    – gowenfawr
    Jul 8 '16 at 13:29
  • Yes, I see that. It has just always surprised me a little bit that the SSL protocol and its various successors have never provided for this idea. The encryption provided by the protocol is highly-desirable because it is transparent to those that are communicating. But, it only directly provides for a single layer of encryption. In the real world, sometimes you put a sealed envelope inside of another sealed envelope ... Jul 8 '16 at 13:54
2

Not necessarily a concrete security risk, as soon as you (the IT admin) are prepared to the new risks.

Strenghtened procedures

If you have a single certificate for many domains, it's a single point of failure and weakest chain ring. You need to enforce expensive IT procedures to keep its private key "eyes only" or better "HTTPS server only". Compromise of the single key will impact all services at once. Your entire business depends on a sigle 4096-bit long number

Possible availability issues

When a single key is shared across several services in a CDN, its compromise will bring the entire CDN down for the period of renewal of the key. Adding a new domain for service involves re-issuing the certificate with its associated downtime.

Load balancing effective

There is one advantage of using such shared certificates. In a CDN, you can effectively set up HTTPS proxies. This is a widely used practice and has great performance advantages.

Basically your DMZ hosts a set of load-balanced reverse proxy servers that will receive HTTPS traffic, decrypt it, and forward HTTP (notice, no S) traffic to the real servers inside the CDN network. This requires a strong setup of the internal network to ensure packet security but there are professionals working at that, and remember that the unencrypted traffic flows only within a trust zone.

So why load balancing? Because if your CDN hosts 1000 sites and a few of them get a traffic increase, you don't need to provision machines for them. You can let the proxies work as round-robin.

No SNI

There is a technical reason behind multi-aliased certificates and it is that the CDN doesn't want to require SNI (Server Name Identification) from clients. Especially in the financial/enterprise world, some people's browsers may be too old to support SNI.

Provisioning a new certificate for each new service, with a different private key, is a good security practice.

1

I'm with the Imperva Incapsula Team.

There seem to be a lot of confusion, so I'd like to point out a few facts:

  1. The vast majority of all websites use a CDN.
  2. We are PCI-certified and SOC2-certified company, all data processing, access and any other compliance-related issue is tightly regulated, audited and logged.
  3. We have some of the biggest banks, financial and healthcare organizations, and governments using our service and trusting us with their certificates.
  4. Honestly, Bank IT departments are some of the most scrutinized in the IT industry, you can trust they know SSL/TLS cert best-practices.

But most importantly - it's just not a security hazard. In any way.

Take all the comments here with a big chunk of salt.

I feel it's important to state that these comments (even if written in good intention) are baseless, misguided and false:

  • "Compromise of any of there other sites can mean that your SSL traffic is no longer safe" --nope
  • "Adding a new domain for service involves re-issuing the certificate with its associated downtime." --nope
  • "Forward HTTP (notice, no S) traffic to the real servers inside the CDN network." --nope
  • "Your bank may be violating privacy laws in your country by letting a company from another country, under a different legislature, process customers' personally identifiable data." --may, but nope

HTH

2
  • Mostly agree with the person from Incapsula however, he forgot to mention one thing. The main issue here is performance. This Shared Cert is a UC/SAN issued to Incapsula by GlobalSign. It includes a very large number of SAN which is going to impact performance. It is also quite weird to see a bank not using an EV Cert.
    – user121737
    Aug 18 '16 at 3:35
  • Thanks, would love to see some figures around performance impact (not a security issue anyway). Would it be better if they use an EV? sure. Is a shared-non-ev more dangerous than regular-non-ev? nope.
    – ZigZag_IL
    Aug 19 '16 at 14:24
0

As far as security goes no. As noted by several people, the CDNs protect the private key with more security than organizations will.

But the risk can be more of an appearance. For example ABC Bank might not want to share a certificate with XYX Guns and Ammo. It's an appearance issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.