2014-06-08 02:38:10 UTC
And a 14-page 184kB PDF of the article is available here:
Excerpt from the l-o-n-g article:
TRUST ON THE INTERNET
Walking around a physical neighborhood, you can gather a lot of
information if you are open to it. On the Internet, it can be a very
different story. Imagine an office with a single PC, used in the
morning by Albert and in the afternoon by Betty. Each has a different
account and logs out at the end of the shift. Albert and Betty work
from the same physical place, and from the same IP address, but they may
have very different experiences on the Internet, depending on what they
Extend that to a data center hosting many companies. Each company's
servers may be separated by only a few feet, but how they experience the
Internet, and how the Internet experiences them, can vary widely. The
physical distance between the servers is irrelevant. What matters is
the hardware they are composed of, the operating systems that run on
them, the application server software, and the configuration data for
each of those things, plus all of the utility and ancillary software
needed to support and maintain them. The quality and quantity of users,
as well as administrators, also matter a great deal.
In spring 2014, a bug in the open-source package OpenSSL became widely
known. The bug, now known as Heartbleed (http://heartbleed.com), had
been present for some time, and may have been known by some, but the
full disclosure of the problem in the OpenSSL package came to the
public's attention only recently. OpenSSL had been reviewed by many
experts and had been a well-used and trusted part of the Internet
ecosystem until that point. As of this writing, there is no evidence
suggesting any cause other than a programming error on the part of an
On the morning before the Heartbleed bug was made public, few people
were familiar with OpenSSL and they hardly gave the functions it
provided a second thought. Those who knew of it often had a strong
level of trust in it. By the end of the day, that had all changed.
Systems administrators and companies of all sizes were scrambling to
contain the problem. Within just a few days, this obscure piece of
specialized software was at the top of the news cycle, and
strangers—perhaps sitting in outdoor cafes at tables they had reserved
with their house and car keys—were discussing it in the same tones with
which they might have discussed other catastrophes.
At the heart of everything that works on the Internet are systems
administrators. Sometimes they are skilled experts, sometimes low paid
and poorly trained, sometimes volunteers of known or unknown provenance.
Often they work long, unappreciated hours fixing problems behind the
scenes or ones that are all too visible. They have access to systems
that goes beyond that of regular users.
One such systems administrator worked for the NSA (National Security
Agency). His name is Edward Snowden. You probably know more about him
now than you ever expected to know about any sysadmin, even if you are
Another less familiar name is Terry Childs, a network administrator for
the city of San Francisco, who was arrested in 2008 for refusing to
divulge the administrative passwords for the city's FiberWAN network.
This network formed the core of many city services. According to
reports, Childs, a highly qualified and certified network engineer who
designed and implemented much of the city's network himself, was very
possessive of it—perhaps too possessive, as he became the sole
administrator of the network, claiming not to trust his colleagues'
abilities. He allowed himself to be on-call 24/7, year-round, rather
than delegate access to those he considered less qualified.
After an argument with a new boss who wanted to audit the network
against Childs's wishes, the city's CIO demanded that Childs provide the
administrative credentials to the FiberWAN. Childs refused, which led
to his arrest. Even after his arrest, Childs would not provide
administrative access to the network. Finally he relented and gave the
mayor of San Francisco the access credentials, ending the standoff.
His supervisors claimed he was crazy and wanted to damage the network.
Childs claimed he did not want to provide sensitive access credentials
to unqualified individuals who might damage "his" network.
In 2010, Childs was found guilty of felony network tampering and
sentenced to four years in prison and $1.5 million in restitution for
the costs the city incurred in regaining control of the network. An
appeals court upheld the verdict.