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