2 min read

Devil in the details

Răzvan STOICA

November 27, 2008

Promo Protect all your devices, without slowing them down.
Free 30-day trial
Devil in the details

A German
mathematician called Martin von Gagern found a bug in GnuTLS , an open-source library that implements TLS, a protocol that
allows client/server applications to communicate in a way that is secure from
tampering, eavesdroping or forgery.

TLS is used by banks and e-commerce sites to secure transactions, but has other
uses as well. One of the aspects of the protocol is that the identity of a
server can be positively established via a chain of X.509 certificates. The way
this works is that a “root” server, usually belonging to a
certification authority such as Thawte, cryptographically signs certificates
for other servers (called intermediaries), which in turn can “pass
on” that trust to other servers.

Clients eventually get to see chains of certificates, something like “Bob
(we all know Bob and we know Bob is Bob because we have here his signature,
which is public and un-forgeable) signed Carol’s cert, so she’s really Carol
and Carol signed Dave’s, so he’s really Dave, so you can go ahead and establish
a secure channel to Dave”. If we know and trust Bob, we can trust everyone
else in the chain. By virtue of being such a nice person, Bob gets to sign his
own certificates, that are nevertheless trusted. This should be an honor rarely
and sparingly granted.

In fact, every client gets to choose whose signatures he trusts a priori –
usually those are signatures of public certification authorities, but some
clients may choose to also trust private CA’s, and end up generating their own
private chains of trust, usually within a company or other organisation. This
is a nice feature of the protocol, but somewhat rarely used.

A client should verify the chain of trust on each certificate received, making
sure that each server’s cert is signed by its parent and ultimately by someone
the client trusts apriorically. However, the GnuTLS client was not doing that,
not exactly. Say it asked “Are you really Dave?” and received a
certificate looking like “Bob says Carol really is Carol. Also, Alice (the
undersigned) says the guy you’re talking to really is Dave.”. The client,
instead of going “hmm… who the heck is Alice?” would think:
“Bob’s Bob, of course, and… ah, look, Alice signed her own cert so she
must be an OK girl too” and then would go ahead and establish a secure
channel with “Dave”. Yup, it’s the kind of mistake only a computer
could make.

Obviously, this is very bad news. Alice (i.e. just about anybody) can convince
the client that she’s anybody else at all, by simply intercepting and
re-routing his calls so they pass through her server and claiming her
sockpuppet is actually the intended recipient.

Alice could accomplish this, for example, by exploiting flaws in the way the domain name system works, so that Bob looks up Dave’s IP
address but gets Alice’s, who then proceeds to dupe him by the method outlined
above.

This particular bug in this particular TLS implementation has been fixed, of
course – open source projects are nice like that – but there’s no telling if
and how many times the bug was exploited before the fix. The issue of whether
we should be trusting the ‘Net with our money has been again raised, in the
starkest of manners.

tags


Author


Răzvan STOICA

Razvan Stoica is a journalist turned teacher turned publicist and technology evangelist. Recruited by Bitdefender in 2004 to add zest to the company's online presence.

View all posts

You might also like

Bookmarks


loader