[145385] in cryptography@c2.net mail archive
Re: A mighty fortress is our PKI
daemon@ATHENA.MIT.EDU (Paul Tiemann)
Sun Jul 25 21:15:19 2010
From: Paul Tiemann <paul.tiemann.usenet@gmail.com>
Date: Sun, 25 Jul 2010 19:04:06 -0600
To: cryptography@metzdowd.com
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? =20
> 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@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. =20
> 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:=20
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. =20
> (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. =46rom my call with Edgecast I can tell you they =
feel the same way, and they're willing to make changes to improve. =20
All the best,
Paul Tiemann
CTO, DigiCert, Inc.=
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
