A mighty fortress is our PKI

[Paul Tiemann]

Hi Peter,

I like your humorous subject line.  After reading your email, I thought of my own humorous twist on a phrase from the same tradition:

"Doth our crypto community judge any CA, before it hear him, and know what he doeth?"

> Readers are cordially invited to go to https://edgecastcdn.net and have a look
> at the subjectAltName extension in the certificate that it presents.  An
> extract is shown at the end of this message, this is just one example of many
> like it.  I'm not picking on Edgecast specifically, I just used this one
> because it's the most Sybilly certificate I've ever seen.

I challenge your Sybil characterization.  Wikipedia's definition:

       "The Sybil attack in computer security is an attack wherein a reputation system is subverted by forging identities in peer-to-peer networks.  It is named after the subject of the book Sybil, a case study of a woman with multiple personality disorder."
       "A Sybil attack is one in which an attacker subverts the reputation system of a peer-to-peer network by creating a large number of pseudonymous entities, using them to gain a disproportionately large influence..."

In this context (SSL cert with many SAN entries for hosted CDN clients) I see these differences:

a) Identities are not being forged.  Each FQDN in the certificate is specifically authorized by the entity owning the domain in question.
b) The entities are *not* pseudonymous -- nobody is using sound-alike or look-alike domain names in there.
c) There is no attempt to gain large influence.  Just to serve content over HTTPS.

The only part that seems to fit is that this kind of certificate presents multiple personalities, however there is no intention  to fool end-users.

> You'll find that
> this one Sybil certificate, among its hundred-and-seven hostnames, includes
> everything from Mozilla, Experian, the French postal service, TRUSTe, and the
> Information Systems Audit and Control Association (ISACA), through to
> Chainlove, Bonktown, and Dickies Girl (which aren't nearly as titillating as
> they sound, and QuiteSFW).

Since this is a certificate we (DigiCert) have issued, I'm trying to understand if there is a vulnerability here that's more apparent to others than to me, or if we're looking at something that is more an issue of taste.  If there is a vulnerability, I hope to understand its precise nature first, instead of taking a "shoot first, ask questions later" approach.

The bulk of the FQDNs included in the certificate are for subdomains like media., www-cdn., static., and the like.  Apply a different test: Is it bad for various organizations to use the same CDN for services over http?  Is it bad for all those different FQDNs to CNAME to the same DNS entry and point to the same IP address?  Is it bad for a CDN to host multiple individual SSL certificates for its customers on the same set of hardware?   If not, then what is so abhorrent about their various FQDNs being included in a single SSL certificate?  If it is considered safe to pass HTTP through your CDN, and it is considered safe to pass your HTTPS through a unique SSL certificate on your CDN, why does it cross the line when you put more than one FQDN into one certificate?  

> Still, who needs to compromise a CA when you have
> these things floating around on multihomed hosts and CDNs.

If you have 100 SSL sites to host, and they're going to live on a shared platform, is it safer to use an individual certificate for each site?  If a hacker were to compromise your servers and have root access to your filesystem, would individual certificates present a hurdle versus a single certificate with 100 SAN entries?  (Side note: It is a fair amount easier to manage the whole list in one certificate, and if needed to revoke one certificate in the event of a compromise than to hunt down and revoke all affected serials of individual certificates.)

Considering the vulnerability landscape, is it safe to assume that there will be more opportunities for exploiting vulnerabilities in web applications and 3rd party packages at the origin level where the actual web application code is executed than at the CDN level where no PHP/ASP/Java/etc is allowed to run?  There is a security maxim that says "Complexity is the enemy of security."  If you turn that around, into "Simplicity is the friend of security," can it be argued that a CDN will generally be less likely to contain things like file disclosure vulnerabilities simply by virtue of running less application code?

Considering the business incentives landscape, is it safe to assume a strong incentive for a CDN running all those sites to be vigilant about their own server security?  Are there any inherently skewed incentives that I'm just not seeing which would lead a CDN to be negligent in its management of its network security and the SSL certificates it manages?

I've spoken with my contacts at Edgecast, and they expressed that they're very willing to consider alternate approaches.  We discussed SNI as an experimental option that may interest some of their customers -- but I'm sure you are aware that  SSL certificates are not good for much if the SSL clients don't support them, and some widely used software did not add SNI support until very recently.  Of course such realities are a thorn in my side: I would _love_ to see OCSP Stapling widely supported--especially by SSL accelerators, or to see SNI widely supported.  To the extent that such things can be pushed forward by a CA, I want to help push them forward.  For example, due to discussions on the certid at ietf list, we have begun to issue all of our certificates with the Subject Alternative Name extension present, and will handle incompatibilities as they arise, instead of taking the safer, more compatible route that most CAs understandably follow for compatibility's sake.

Focusing on SNI for a second: Would that even improve the security in this scenario?  You would still be running hundreds of certificates on a common platform.  I can see technical advantages when SNI is well supported, like faster SSL handshakes due to smaller end-entity certificates, but are there technical security oriented advantages?

> Ian Grigg pointed out that this is also an EV certificate,

Wrong.  It's not an EV certificate.  EV certificates have to include the CA issuer's EV policy OID in addition to chaining up to an EV-enabled root certificate.  A list of those policy OIDS can be found here: http://en.wikipedia.org/wiki/Extended_Validation_Certificate

Edgecast doesn't offer EV or wildcard in this kind of certificate, and neither does DigiCert.  One of the purposes of an EV certificate is to identify the subject organization that owns the domains included in the certificate.

In contrast, it's widely agreed that a non-EV certificate needs to at least be authorized by the domain owners.  In this case, the owners of the domains included in the certificate all had to give written approval for Edgecast to include their respective FQDNs in the certificate.  Those approvals are then verified using out-of-band communications with the domain owners.  We take our verification process seriously enough to augment our automated checks with human checks (it costs more to do it the way we do, but we take pride in our work and try to do it responsibly)  If it's hard to believe that coming from me, here's a reference from a respected voice in the security community: http://schmoil.blogspot.com/2008_08_01_archive.html

> I've tried connecting to the above site with HTTPS and get a normal non-EV
> Sybil certificate even though it's rooted in an EV CA... well, pseudo-rooted,
> the "root" is then signed by an old Entrust certificate,

Cross-signed by a more ubiquitous Entrust certificate is how I would put it.  Again, SSL isn't very useful if browser clients reject it, and a cross-signed root is a reality of life for many CAs that don't have roots that come from the late nineties.  Legacy clients chain to the Entrust root because they lack the DigiCert root.  Modern clients (FF, IE, Safari, Opera, etc) chain up to the DigiCert root which they include in their trusted list.

> I wonder if they have some context-specific way to override
> EV on a per-site basis when it's used with Sybil certificates?

No, a certificate is either all EV or all non-EV.  The policy OID's presence is required, and there's only one of those per certificate.

> At the moment
> it's rather hard to test because depending on where you are in the world you
> get different views of servers and certificates (for example when I connect to
> ISACA, which is an EV site, I get a standard non-Sybil certificate that's only
> valid for ISACA), and finding a particular hostname in a Sybil certificate
> doesn't mean that you'll see that particular certificate when you connect to
> the server.

Perhaps ISACA isn't currently pointing its DNS at its Edgecast CNAMEs?  I see 12.239.13.10 for www.isaca.org which is IP spaced owned by ISACA itself.  It could be that ISACA switches its DNS entry to Edgecast during seasonally high traffic, and carries the traffic on its own at other times?

> (Again, not wanting to pick on ISACA here, but finding a security audit
> organisation sharing a certificate with Dickies Girl is kinda funny.  You'd
> think there'd be a security audit process to catch this :-).

Here's my opinion: It's only kinda funny if there's a real and credible threat to consider.  I don't think ISACA or any other organization should be harried into yanking their FQDN from this specific certificate based on what's been said so far.  

> What a mess!  A single XSS/XSRF/XS* attack, or just a plain config problem,
> and the whole house of cards comes down.

Well, I admit I'm not an XS* ninja, but I don't think that's accurate.  The Javascript same origin policy doesn't take any cues about what's considered "same origin" from the SSL cert:

https://developer.mozilla.org/En/Same_origin_policy_for_JavaScript

I admit there are areas of XS* in practice which I do not understand perfectly.  Can anyone think of a specific vulnerability here?

As for config problems, you have to weigh the risk of downtime due to running your web presence in one datacenter versus running it at 15+ locations simultaneously via Anycast.  There is always going to be a risk of _something_ happening that can take your site offline.  Running high volume or high profile sites out of multiple locations seems to be a growing practice though.

CDNs running anycast are facing another big problem: There's not much IPv4 space left to go around.  To run anycast you'll need to have a /24 at a minimum.  Even if you put one SSL certificate on each of your spare IP addresses, you're only going to be able to run 254 certificates per block.  What if you eventually have a few thousand customers?  Two realities deserve explicit mention: 

1) Most CDNs are new entities, started up long after the days when individuals could get their own giant netblock assignments.  Most CDNs are not sitting on their own /16s.
2) Most CDN customers are big enough to be running an SSL certificate on their main site, and if they are serving all their images and other media content via the CDN, they will _need_ to have SSL on the CDN or they're going to run into "Insecure mixed content" warnings when their HTTPS content refers to HTTP content on the CDN.

Should having an SSL certificate on your CDN cost you more per month than your bandwidth costs, and consume lots of IPv4 space?  What is an appropriate amount of SAN entries in one certificate?  Are two unrelated domains too many?  What about twenty or fifty?  I can tell you at the moment that we're considering putting a cap of somewhere between 25 and 50 on the number of SAN entries allowed in one certificate.  Would that solve the problem?  I'd really like more feedback on how to improve this.  

> (For the TLS folks, SNI (a client-supplied Server Name Indication when it
> connects) won't fix this because (a) it's not widely-enough supported yet and
> (b) the server admin would have to buy 107 separate certificates to do the
> job that's currently done by one Sybil certificate, and then repeat this for
> every other Sybil certificate they use).

True for (a) which makes it a bit of a show stopper for SNI at the moment, but (b) is not so problematic due to the internal automation that is likely to be a pre-requisite for managing many certificates across multiple locations.

I appreciate the chance to participate in the discussion.  We're very open to considering the risks, and not afraid to make changes based on feedback like this.  From my call with Edgecast I can tell you they feel the same way, and they're willing to make changes to improve.  

All the best,

Paul Tiemann
CTO, DigiCert, Inc.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com