> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Benjamin Schulz
> Sent: Monday, 14 April, 2014 15:01
>
> Could the openssl foundation add official rules that
This list is probably not the place to discuss this at any length, but I for
one find these proposed "rules" foolish, naive, counterproductive, impractical,
and unlikely to achieve anything useful.
> a) it is not accepting money from intelligence agencies or companies that
> work for intelligence agencies and that, if it turned out, a given money
> comes from intelligence agencies or a contractor of them, the openssl
> foundation will return the money, and that this applies even to all earlier
> donations.
I propose an amendment: "Benjamin Schulz, and others who believe this is a good
idea, particularly the bit about 'earlier donations', will donate funds to
openssl.org in the amount rejected or returned".
> b) that developers of openssl are not allowed to do contracting work for
> intelligence agencies and companies working for intelligence agencies, and
> that if it turned out a developer had such contracts, he may no longer work
> for openssl, and that this applies also for earlier contracts of the openssl
> developers.
So if, say, the NSA decides to use Akamai as an edge server for their site,
then OpenSSL has to remove the memory-protection code supplied by Rich Salz?
Brilliant.
> c) that the names of all companies who hire openssl developers must be
> published in the open on the openssl homepage, and that this applies also for
> the companies who hired openssl developers earlier
Because there's no way for the evil masterminds of shadowy security agencies to
disguise their affiliations...
> d) that the companies who make donations to openssl will be published in the
> open on the openssl homepage and that this applies also for the companies who
> donated to openssl earlier.
...or to hide a money trail.
And as for "companies who donated to openssl earlier": Violating a prior
agreement and the trust of people who donated to your organization to satisfy
the paranoia of random users is a fair trade?
> e) and that donnations above a certain value, or a person donating very often
> is named publicly on the openssl website.
What part of your threat model could this possibly address? (Let's leave aside
for the moment the question of whether that threat model is at all realistic or
sensible.) What's the vulnerability here? That some intelligence agency will
donate so much money to OpenSSL.org or the OSF that the OpenSSL developers will
deliberately introduce backdoors for them? Aren't there dozens of easier, less
detectable ways to suborn developers - from direct bribes (why go through the
organization?) to threats to blackmail to ideological persuasion? Either
OpenSSL developers are corruptible or they aren't - donating money to the
organization is surely one of the clumsier ways to attempt to corrupt them.
> If you incorporate these rules ito the openssl foundation, it may help to
> scare intelligence agencies away from openssl, since these agencies hate
> nothing more than publicity.
What a peculiar fantasy.
Certainly intelligence agencies (ones with SIGINT remits, anyway) have an
interest in defeating OpenSSL, just as they do with any secure-communications
implementation. And yes, as both an operational imperative and a matter of
habit, they like to limit their public exposure. But none of your proposed
rules impose any significant barrier to anything those agencies might do today.
As everyone knows, OpenSSL included Dual_EC_DRBG at the request of a paying
customer. It happened to be a broken implementation, and no one noticed,
because there wasn't any reason to use it; but there's no reason to believe
that paying customer was a front for some intelligence agency. Customers ask
for all sorts of things.
How is OpenSSL.org or the OSF supposed to determine whether a customer "work[s]
for an intelligence agency"? What constitutes "working for" an agency? If an
agency purchases software from my employer, does that mean I work for such an
agency? What kind of resources is OSF meant to devote to performing background
checks on its customers?
And what's to stop an agency from operating through a proxy that has no public
connection to the intelligence industry? Nothing, that's what.
> Is it possible for the openssl foundation to do this?
Oh, sure. They're swimming in cash. What can't you do with $2000 a year?
> And by the way:
> Is there a book or something where one can learn the programming of openssl?
I'd suggest starting with Rescorla's /SSL and TLS/ and Schneier's /Applied
Cryptography/. For the code that handles ASN.1 DER parsing and generation (for
X.509 certificate handling and some of the PKCS standards), there are a number
of good online resources, such as:
http://www.zytrax.com/books/ldap/apb/asn1.pdf
> I know a bit C++ and C and would be interested to look closer at the
> sourcecode. But I see that it is very large. Is there something that makes
> the entry in openssl programming easier?
Not really. The OpenSSL sources aren't as difficult to read as some people make
them out to be, but they are far from trivial. And since they're written in C,
knowing "a bit [of] C++" will only hurt, as many people who don't have
extensive C experience have trouble keeping those two quite different languages
apart.
--
Michael Wojcik
Technology Specialist, Micro Focus
This message has been scanned for malware by Websense. www.websense.com
