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 
cer...@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 majord...@metzdowd.com

Reply via email to