Cryptography Reference
In-Depth Information
As it turns out, this is actually poorly specifi ed. The compromise here has
been to insert the domain name into the
CN
fi eld of the subject name and allow
the client to compare the domain name it thinks it's connecting to against the
domain name listed in the
CN
fi eld of the certifi cate's subject. However, this is
imperfect. Consider an e-commerce site that controls three different domains:
shop.whizbang.com
,
purchase.whizbang.com
and
orders.whizbang.com
. SSL
certifi cates are expensive to obtain — at least, those issued by reputable CAs — and
something of a hassle to maintain. The site administrator has to keep track of
expiration dates and ensure that the certifi cates get reissued within a reason-
able timeframe. As the administrator of
whizbang.com
, you'd really want one
certifi cate that authenticates all of the site's servers. After all,
www.whizbang
.com
almost certainly identifi es multiple physical IP addresses.
As a result, it's acceptable for the certifi cate's subject's
CN
fi eld to include a
wildcard, such as
*.whizbang.com
. This actually creates other problems. If you
can convince a CA to register you a certifi cate with a subject name including
CN=*.com
, you can masquerade as any site on the Internet, and the browser has
no way of differentiating your certifi cate from the legitimate owner of the site.
Although authorities are smart enough to check for this, security researcher Moxie
Marlinspike, in his paper “Null Prefi x Attacks Against SSL Certifi cates,” detailed
an interesting vulnerability not in the protocol itself but in most implementations
of it. An attacker requests a certifi cate whose common name was
*\0.badguy
.com
. Note the insertion of the null-terminator \0 in the domain name. Because
he owns the top-level domain name
badguy.com
, the CA issues the certifi cate.
However, a C-based client implementation almost certainly loads the common
name into a string fi eld and does a
strcmp
to determine equality — reading the
common name as * or “any website”. This is something that implementers of the
TLS protocol need to be aware of; the length of the string needs to be checked,
and null terminators before the actual end of the string should be removed. If
you're lucky, the CA checks for this as well. You shouldn't rely on luck, though;
as the implementer, make sure you protect your users against lazy CA's.
RFC 2247 extends the X.509 subject name to explicitly include domain-name
components, split out according to the DNS hierarchy, so that
www.whizbang.com
becomes
DC=www,DC=whizbang,DC=com
. This new
DC
(domai n-name component)
attribute has OID 0.9.2342.19200300.100.1.25 and is not particularly common;
most sites still instead use the
CN
fi eld to identify their domain names. This is
part of a chicken-and-egg problem; some older clients don't recognize the
DC
component, so to interoperate with them, sites identify themselves using the
CN
fi eld. Because so few sites advertise
DC
components, there's little incentive
for clients to recognize it. At the time of this writing, neither Firefox 3.6.3 nor
Internet Explorer 8 properly recognize the
DC
fi eld in the subject name, although
RFC 3280 states that recognizing it is mandatory. If the
DC
fi eld correctly identi-
fi es the domain name, but the
CN
does not (or is missing), a security exception is
still reported. The
DC
fi eld is more common in LDAP-based certifi cates; perhaps
someday in the future, web browsers will make use of it.
Search WWH ::
Custom Search