A mighty fortress is our PKI

[Chris Palmer]

Paul Tiemann writes:

> 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,

If an attacker can steal the cert by any means, perhaps by means particular
to one of the hosted sites, he can now forge the identities of the 100+
sites. It gives the attack a multiplier. (It appears 100+ is not even the
largest number of entities in a single cert.) Potential attacks:

* Attack the server (e.g. buffer overflow in FooHTTPD or some other bug in
a web app the CDN runs (I know not all CDNs run cloud app hosting services,
but some do)). Note that even though all sites are served by the same
server, all sites suffer the risk profile of the highest-profile site. If a
CDN server is serving tiny.unknown.com and also mega.often-attacked.net,
tiny.unknown effectively endures attacks on mega.often-attacked.

* Questionable reseller. Although reselling a CDN might normally give you
access only to a subset of the CDN's subscriber's sites, you can get many in
one go because these certs have so many subjects. See below.

> 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?

Let's just say I'd rather get the advantages of a CDN by other means, but
that I recognize that using a CDN can be a reasoanble economic trade-off in
many situations.

> If not, then what is so abhorrent about their various FQDNs being included
> in a single SSL certificate?

I wouldn't say "abhorrent", but the increased size of the cert could be a
concern.

I just wiresharked an HTTPS connection to https://ne.edgecastcdn.net/. The
cert is 7,044 bytes. Admirably small given how many names are in it, but
still 6 KB larger than another cert I observed containing only one subject.

I have a hard enough time convincing people that HTTPS is not the root of
their web app performance problems and that therefore they CAN afford to use
it; the last thing we need is a certificate that big increasing latency at a
critical time in the page load. TLS sessions to that server don't seem to
last very long either, increasing the frequency of cert delivery; but maybe
that is necessary due to the high traffic such a server handles. (Gotta have
a limit on the size of the session store.)

I know it's a small thing, especially relative to the general content layer
heft of most sites, but still. When trying to convince developers to use
HTTPS, I need every rhetorical advantage I can get. :)

> 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?

As Peter noted, http://www.webhostingtalk.com/showthread.php?t=873555.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com