17

The X509 specification allows a CA to issue a single certificate for multiple hostnames, by using the "Subject Alternative Name" extension.

From the spec:

The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate.

This has numerous uses; in particular, consider a hosting / reverse-proxy situation, with multiple sites colocated. These sites do not particularly trust each other, and do not have any kind of affiliation; they are just being hosted by the same server, and thus sharing the same certificate.

Is this as risky as it sounds?
At first glance I would say that being as the sites are not trusted to each other, it might be possible for siteA to spoof siteB, even over SSL, since siteA uses the same private key that siteB does. DNS would still need to be spoofed, but there are several ways to do so (even if they are not trivial).
Am I wrong, IS there some other cryptographic (or other) mitigation that I am not seeing here?

Community
  • 1
AviD
  • 72,138
  • 22
  • 136
  • 218
  • 2
    While your question is indeed valid, you're starting with an incorrect premise. You're proposing a situation where a SAN cert is used incorrectly (for sites that are operated by different entities or where there's no mutual trust). Examples of correct usage is when you want to have `avid.org` and `avid.net`, or your holding company runs two entities `avid-firm.com` and `avid-agency.com`. That's what SAN is for. – Adi Jun 06 '13 at 09:10
  • 1
    No, thats not an incorrect premise, that is the exact scenario I am describing. This does seem to me to be oh so very wrong, I am looking for validation - or better yet, to learn by finding out I am wrong and this setup is not as vulnerable as I would think. – AviD Jun 06 '13 at 09:20
  • 1
    For my education: the right way to do this is [SNI](http://en.wikipedia.org/wiki/Server_Name_Indication), right? – Gilles 'SO- stop being evil' Jun 06 '13 at 12:10
  • 1
    @Gilles see Thomas's answer below. – AviD Jun 06 '13 at 12:52

3 Answers3

19

If every tenant has a copy of the private key, then well, they all have it, which means that they can spoof each other. They can also decrypt traffic between other tenants and their clients, unless they use the "DHE" cipher suites of SSL, which removes this specific issue; this is known as Perfect Forward Secrecy. DHE does nothing against the spoofing issue, and can be used only if the client software agrees.

The trick is, then, not to give the private key to each tenant. Instead of having them share the same certificate, make them share the same SSL server. Run a single, trusted HTTPS server which uses the certificate, and then forwards the decrypted HTTP traffic to the relevant tenant (whose name is specified in the HTTP header -- no need for SNI support here). Indeed, a reverse proxy situation. Such a setup is safe (tenants are given nothing); however, it requires tenants to trust the shared SSL server (that's still better than requiring the tenants to trust each other), and it will interfere with (i.e. in all practicality, prevent) use of client certificates.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Thanks! So if this multiple-SAN cert is installed on the reverse proxy, it's not a problem for the backend sites to share the same cert? The sites themselves dont have access to the private key, sure, but they do have access to the connection with the client via the same cert. I guess I'm thinking in the direction of malicious sites, that send down javascript (or flash, or whathaveyou) that then forces a connection to the same server, using the other site's name, ala DNS Rebinding. E.g. some form of redirected tunnelling... I am explicitly NOT clear on how this would work, though... – AviD Jun 06 '13 at 12:50
  • 1
    From the point of view of the client, "same server" means "same name". That's how Same-Origin Policies work; they don't give a fig about whether two distinct host names happen to be hosted on the same IP, or, for that matter, use the same certificate. The multiple servers also don't have access to the same _connection_: for each name, the client browser opens a new SSL connection, because the client, at that point, does not know that the other server will use the same certificate (and it won't "merge" connection afterwards either). – Thomas Pornin Jun 06 '13 at 22:37
  • 1
    Would anything prevent the following attack: the owner of site1 also intercepts someone's network connection (say, on coffee shop wifi). He rewrites requests for site2 to refer to site1, so that the reverse proxy uses site1 to respond. They use the same certificate, so the browser accepts the reverse proxy's signature on the response. Even if he only rewrites some requests, cross origin protection does not kick in, because as far as the browser is concerned, it's loading everythin from site2. – Thomas K Aug 02 '14 at 00:39
  • @ThomasK: owner1, like everybody else, cannot intercept or tamper TLS connections to the shared proxy if they don't have the privatekey. If owner1 does have the privatekey they can intercept and tamper connections that use plain-RSA keyexchange; they cannot do so for connections using DHE or ECDHE keyexchange. But with the privatekey they don't need to tamper at all; they can just divert traffic to their own server that impersonates site2 and doesn't even touch the proxy or real site1 and doesn't care about keyexchange -- that's _why_ they must not have the privatekey. – dave_thompson_085 Sep 08 '17 at 01:45
7

Yes, it is as risky as it sounds. You're not wrong, and, AFAIK, I don't think you're missing anything.

Multiple entities sharing the same certificate which signs a public key, means they share the same private key. Not A Good ThingTM. If site1.com doesn't trust site2.com then they shouldn't be configured to use a Subject Alternative Name (SAN) certificate.

A good CA will verify that the entity requesting a certificate has ownership over subjects defined in the SAN (domain name, IP address, email address, etc.)

So in conclusion, SAN certificates should only be used when the covered subjects trust each others. A good example of different sites using the same certificate (one you mentioned in the DMZ), is the case of SE sites. Even though stackoverflow.com is a different site from superuser.com, they still trust each others and belong to the same entity.

Adi
  • 43,808
  • 16
  • 135
  • 167
  • 1
    +1, but the point about the CA is misplaced - if there is a multi-tenant hosting situation - or think of a CDN - the host *does* have authorization to install the certificates for those sites, and should eventually have a cert for each site installed. But I agree about the site1 shouldnt be using the *same* cert as site2, even if both certs would otherwise be installed on the same server. – AviD Jun 06 '13 at 10:19
  • Other than common sense, do you have any resources, exploit PoC, authoritative statements to that effect, etc? This is a large, wellknown entity that is doing this, I want to have something to point them at for backup.... – AviD Jun 06 '13 at 10:21
6

@Adnan and @Thomas Pornin both touch on the first leg of the tripod: If the key is only accessed by the shared provider (e.g., a CDN) then the security is not necessarily lower, and if it is shared by unconnected parties then the security is ridiculously lower.

There is a second leg to the tripod, which is maintenance. Let's assume that the key is only held by the shared provider (HostCo), so the security is not an issue. HostCo has 20 tenants that he stuffs onto the key using Subject Alternative Names (SAN). Great! June passes, July arrives, 3 tenants leave and 4 new ones show up. Whoops! Time to get a new cert issued reflecting the adds/changes. Great. Whoops! August comes... see where this is going? The maintenance of redoing a cert with multiple SANs is stupid over time unless the pool of names going onto a SAN is pretty static.

The third leg of the tripod is money. It may be cheaper for HostCo to use a SAN cert than to go out and buy 20 certs. This leg doesn't make sense, really, because of the tenants are truly unconnected units that don't trust each other, HostCo is just going to pass the costs of individual certs along to them. There's not the same economic incentive that, say, Massive Dynamic has to save money on the cert for the web site that all 273 of it's subsidiaries are served by.

That's three remarkably wobbly legs. I wouldn't sit on that stool given the option.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • I think you're underestimating the costs and problems associated with individual certs, you forget that at current each individual cert required a dedicated IP address, which themselves are in shorter supply and costing more and more per month to lease. This becomes economically unviable in a multi-tenant load balancing scenario. The only concern is that when an interested competitor looks up the actual cert, they would then get a list of your other clients all nice and tidy :) – oucil Feb 27 '15 at 18:17