hpr-knowledge-base/hpr_transcripts/hpr1529.txt

Episode: 1529
Title: HPR1529: TrueCrypt, Heartbleed, and Lessons Learned
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1529/hpr1529.mp3
Transcribed: 2025-10-18 04:42:37

---

music
Hello, this is Ahuka, welcoming you to Hacker Public Radio and another exciting episode
this time in our security and privacy series.
And what I want to do today is I want to talk about some lessons learned from some recent
events involving the heartbleed vulnerability and an audit of true crypt, and I think there's
a few things we can learn from taking a look at this.
These two events over the last four to six weeks have combined to deliver a powerful
lesson on the security of open source software, but I think it is important to know exactly
what the right lesson is.
I have seen reports that heartbleed was a proof of something fundamentally wrong with
the open source model, as denying the accuracy of Eric Raymond's famous saying with many
eyeballs all bugs are shallow.
The heartbleed bug was a significant number of systems, about one sixth of internet sites
as far as I can tell from an analysis of how many sites use open SSL.
And what percent of those use versions of the software that are affected.
You see, one of the things that came out of this was the initial report was, oh my God,
open SSL is everywhere, we're all at risk, it was a version of open SSL, and it turns
out not one that was all that widely distributed.
So there was certainly a bit of hyperbole in how bad it was, but it's no doubt, it was
pretty bad.
How did that happen?
I'm going to refer everyone to an excellent article that has all of the details.
It is called, how did the heartbleed open SSL bug happen?
And it's shortened to the point, there is a link in the show notes so that you can go
to the website and read this for yourself.
Basically, there was a request to have an extension to open SSL to provide something called
a TLS heartbeat extension.
This is a perfectly reasonable thing to do.
It was covered in RFC 6520, which has the title, Transport Layer Security and Data Graham
Transport Layer Security Heartbeat Extension.
I'll link that in the show notes as well.
I'm sure it'll make extremely stimulating late night reading for you.
Now as the RFC makes clear, the purpose is to provide a keep-alive functionality without
requiring a re-negotiation.
So open SSL was simply trying to be compliant in adding a capability that the internet engineering
task force had decided should be provided.
But how does the open SSL project handle this?
The first thing we notice is that open SSL has a core team of just 11 people.
Most of them volunteers and only one full-time person devoted to the project.
Generally, they get about $2,000 a year in donations.
They make some money from support contracts.
In other words, they're stretch tight.
A volunteer in Germany, Dr. Robin Segelman, wrote the code, ImplementRFC, and submitted
it for review.
Dr. Segelman is a respected academic and computer science researcher, and there is no
possible way to suggest either malice or stupidity here.
As it happens, he did not actually have commit rights to open SSL, so he submitted the code
to the project members who do have those rights, and they reviewed it.
They saw nothing wrong with the code.
They verified that it did what it said it would do, in other words, implement a heartbeat,
and the code was put into production in early 2012.
The problem was discovered by Google researchers and by a Finnish company called Code Namicon
at about the same time, and it was made public in April 2014.
There is some suggestion that there was talk from one of the Google people that might have
pointed code Namicon in the right direction, but perhaps it was simply independent discovery.
These things do happen.
But as Steve Marquess of the Open SSL Foundation said, the mystery is not that a few overworked
volunteers missed the bug, the mystery is why it hasn't happened more often.
The other event I want to talk about is the True Crypt audit, which released preliminary
results recently.
As you may recall in the wake of Edward Snowden's revelations, there was a general anxiety
about the security of encryption.
And people wanted to know if their encryption had been weakened or a backdoor inserted
by the NSA, the GCHQ, or any other acronym government agency.
In the case of True Crypt, you again have an open source project.
With the wrinkle that the developers were deliberately anonymous and based in Eastern Europe.
Three Snowden, that might not have aroused too much speculation, but post-Snowden people
wanted answers.
The True Crypt Foundation did the right thing.
They raised money.
I was one of the people who contributed to their crowdfunded campaign.
And it listed Dr. Matthew Green, a highly respected cryptography expert who teaches at Johns
Hopkins University in the United States to put together a team to perform an audit of
the code.
This is a lengthy and difficult task, but the first phase has been completed.
And while there are criticisms of certain sloppiness errors, they've said there's no sign
of any deliberate errors here.
Now you can read a good report on this at novainfosec.com.
And that article also has a link to the actual report itself if you really want to dig into
it.
Again, links are in the show notes.
Now this first phase looked good, but what it was dealing with was the bootloader and
the Windows kernel driver implementations.
Now there is a second phase planned to go into the cryptography itself, and that's going
to use a completely different team of researchers.
So what were the results?
Well, True Crypt is not perfect, but to expect that would be unrealistic in any case.
The audit team did find a certain amount of sloppiness, which probably derives from
the fact that the project was done by volunteers and grew organically.
But the audit team found no evidence in phase one that there were any deliberate problems
or backdoors in the code.
This is good news, since this is one of the major open source programs to offer serious
encryption.
If you want to encrypt a directory, a drive, or an entire computer, this will do the
job for you.
And so far there is no evidence that the encryption is compromised, though there are things they
can do to tighten up the code.
And of course, we should wait for the phase to audit before giving them a completely
clean bill of health here.
Now, I brought up both of these because I think they combined to give us some lessons learned.
And now I want to tell you what I think those lessons are.
If you think there are other ones that I have not gotten to, as Ken Fallon would say,
record a show.
So here's my opinion.
First one, both these programs are important to the internet.
So where was the support?
To me, this gets at a fundamental problem of companies treating open source like it's
a free lunch.
It's not.
As you should all know, there ain't no such thing as a free lunch.
Frequently abbreviated as Tonstoffel.
Now, open source is really just a different model for developing and supporting software,
one that relies on participation by all of the interested parties.
If all of these companies were relying on open SSL, for instance, where was their participation?
To the fact, it does look like many of them woke up.
The Linux Foundation has put together a consortium of major companies to quote from the
NARS technical article, again, link in the show notes on the subject, Amazon Web Services,
Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel, Microsoft, NetApp, Qualcomm, Rackspace,
and VMware have all pledged to commit at least 100,000 a year for at least three years
to the core infrastructure initiative.
Linux Foundation Executive Director Jim Zemlin told ours, this initiative will be aimed
at more than just open SSL, but that is good.
It means that these companies are taking seriously their responsibility to support the
code they rely on.
This is in contrast, in my mind, to a move that really sounds suspicious to me, Theodirat,
to create a fork called Libra SSL.
It strikes me as more like ego than a constructive move.
I would stick with open SSL and give Libra SSL a pass, at least until such time as they
can show a long track record of success.
A good general rule in security is that new code is much more dangerous than code that
has been around for a long time.
In the very first reports I heard from the Libra SSL project, we're about all the lines
of code they had immediately thrown out, and then all the stuff they decided they just
weren't going to deal with because they didn't care about it.
Doesn't, to me, does not look good, you know, you are free to make up your own mind on
that.
That lesson learned, security is hard, and it's a different skill set than most development.
Dr. Segalman is a smart guy who was trying to implement a requirement in an RFC.
His code did in fact do that.
It was reviewed by someone else on the open SSL team, and they did not see any problems
with it, and they put it into production.
It sat there for two years before someone noticed a problem.
The reason a number of smart people miss this is it takes a very different skill set
to do security.
In hindsight, it is easy to say they should have brought in a specialist, and I hope that
the core infrastructure initiative is going to help address this sort of thing.
Third lesson learned.
Bugs are not shallow if the eyeballs are not there.
Both true crypt and open SSL had small groups of developers with limited resources.
Everyone else just assumed the code was fine, and never tried to look at it.
And given that security requires a specialized skill set, just adding eyeballs is not enough
to need to be the right kind of eyeballs.
A question this raises in my mind is about the governance of critical open source projects.
We need a little more structure to the process to avoid these kinds of problems.
The next lesson I learned from this, fixing this requires money among other things.
One of the key takeaways regarding the open SSL project is that they were on what I call
a shoe string budget, where on average they got about 2,000 a year in donations.
Contrast this with the cost of the true crypt audit, where they appear to have raised
about $60,000, and I doubt that is any too much.
They put together a team of professionals who understand the work, and they can probably
go through $60,000 in no time.
I always tell people they need to support free software and that includes financial support.
If you're only interested in what you can get for free, you will get these kind of results
because the results will not be there.
Or as my good friend, the door to door geek says, support the people who support you.
So it really is important.
Supporting free software means coming up with some money from time to time.
As I mentioned earlier, I did contribute to the fundraiser for the true crypt audit.
Next lesson learned.
The advantage of open source software is not that it is bug free.
No software of any kind is bug free.
We make a grave mistake to think so.
If it has zeros and ones in it, it'll have bugs in it.
And it's probably not even correct to think that open source has fewer bugs.
As we have seen, the weakness of the many eyeballs equal shallow bugs theory is that for
many open source projects, even critical ones, they're simply or not that many eyeballs
and often the ones that are there may not be the ones we need to detect subtle problems such as security issues.
That does not imply the opposite, however.
The idea that open source has issues does not mean that proprietary software does any better
as a recent Internet Explorer bug illustrates.
As I am writing and recording this, people have been advised to stop using Internet Explorer all together
because of a fundamental security issue.
If you want more Google operation, clandestine Fox.
Now the superiority of open source in my mind is principally that issues generally are addressed quickly.
Patches for the heart-bleed bug started to roll out within hours of this disclosure.
Patches for the Internet Explorer bug will at best show up in the next round
of Microsoft patches which could mean waiting a month.
Furthermore, with open source, the whole code is on display, so the quality of our information is much better.
With proprietary software, the code is never available.
The information about the bug tends to be sketchy at best, and in some cases, companies will try to keep any information
from going out because it could have an adverse effect on their bottom line.
And one final lesson I want to bring in.
In the case of open SSL in particular, Simon Fipps, who is the executive director of the open source initiative,
wrote a very interesting article, again, link in the show notes.
Based on work by David Wheeler, that points to the license as a source of problems here.
Open SSL use the license all of their own, which was copy left, but incompatible with the GPL,
and this creates a disincentive for anyone to get involved.
He quotes Ebb and Moglin as saying that the open source license acts as the constitution of the community,
which governs how everyone participates.
By having a license that no one else uses, they had the effect of putting in ground rules for participation
that no one else understood.
The lesson here is that you should not try to reinvent the wheel.
There are plenty of good, well-understood open source licenses out there, and you should use one of them
so that the largest number of contributors will be involved.
This is one of the reasons that Fipps, who, as I said, is executive director of the open source initiative,
strongly discourages any new license applications.
It just isn't a good idea, and people need to stop this needless proliferation.
So, I hope that you have found this enjoyable.
This is Huka, signing off for Hacker Public Radio, and as always reminding you, support free software.
Bye-bye.
You have been listening to Hacker Public Radio, as Hacker Public Radio does already.
We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by a HPR listener like yourself.
If you ever consider recording a podcast, then visit our website to find out how easy it really is.
Hacker Public Radio was founded by the Digital Dark Pound and the Infonomicom Computer Club.
HPR is funded by the Binary Revolution at binref.com.
All binref projects are proudly sponsored by LUNAR Pages.
From shared hosting to custom private clouds, go to LUNAR Pages.com for all your hosting needs.
Unless otherwise stasis, today's show is released under a creative commons,
attribution, share a like, 3.0 license.