Devil in the details

TLS implementation flaw left e-commerce insecure

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

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.

About the author


Razvan Stoica is a journalist turned teacher turned publicist and
technology evangelist. When Bitdefender isn't paying him to bring complex subjects to wide audiences, he enjoys writing fiction, skiing and biking.

Razvan Stoica started off writing for a science monthly and was the chief
editor of a science fiction magazine for a short while before moving on to
the University of Medicine in Bucharest where he lectured on the English
language. Recruited by Bitdefender in 2004 to add zest to the company's
online presence, he has fulfilled a bevy of roles within the company since.

In his current position, he is primarily responsible for the communications and community-building efforts of the Bitdefender research and technology development arm.