Re: On Open Source

From: Tom St Denis (tomstdenis_at_iahu.ca)
Date: 05/23/04 

Date: Sun, 23 May 2004 11:57:06 GMT

Henrick Hellström wrote:
> It has come to my attention that OpenSSL defaults to not validating the
> server certificate against root certificates when used for client side
> SSL/TLS. I argue that this is a major design flaw with serious security
> implications, and furthermore that this is a kind of issue that is not
> likely to be caught be the mechanisms (i.e. peer-review) that are
> normally considered to make de facto standard open source software more
> likely to be secure than non-standard or closed source software.
>
> Premise 1. Client side authentication of the remote host identity is THE
> security service you would normally use SSL/TLS for. Getting a
> confidential communication channel with message integrity is pointless
> unless you have equally strong proof of the identity of the remote peer.
> I am tempted to say that using client side SSL/TLS without root
> certificates is like buying a Volvo for safety and driving it in 200
> km/h without fastening your seat belt.

You would want to verify the servers certificate but checking the root
signature on it [if there is one] is next to meaningless in some
circumstances. For example, this scenario.

I have to monitoring nodes. I put them side by side and make SSL keys.
  I then put the public keys in the opposite machines and set them up.
In this case a root signature is useless since I already know and can
trust the public key.

Also "root signatures" are just the digital representation of "hello my
name is" tags. Doesn't guarantee you anything.

> Premise 2. This kind of issue is likely to be caught by trained
> professionals, by professional support/consultancy and in sufficiently
> large and active communities consisting of users, possibly with
> different backgrounds, but with access to the source code.

It's not an issue though. So this is moot. The fact is you can verify
a cert chain with SSL. The fact that it isn't mandatory isn't a bug.

> Premise 3. This kind of issue is not likely to be caught by open
> sourcing the software and relying on peer-review. My argument for this
> is that the people that are likely to spot the problem (i.e. the trained
> professionals) are not necessarily interesting in seeing it fixed: They
> can use the software securely anyway since they know what to do, and it
> is not unlikely that they make a living from knowing this kind of
> things. The latter might even entail a direct interest in the problem
> NOT being fixed.

While I agree that many OSS developers cut corners [and in crypto in
particular] I'd say there have been many fixes to SSL via the open
source review model. The issue here though is you *think* there is a
problem with SSL and therefore seem just to demand addressing.

> Conclusion: Recommending non-experts to use a de facto standard Open
> Source solution for cryptographic services is not necessarily good
> advice. Recommending them to learn more/hire an expert (or better yet
> more than one expert)/participate in relevant community groups is good
> advice.

I'd say just the opposite. Hire experts who use de factor standard open
source packages.

If I were some software tycoon hiring people to co-ordinate security
into my latest software package I wouldn't want them to waste time on
the nitty gritty [ciphers, hash, MACs, PK, bn math, etc...]. I'd much
rather them pick up a quality library and design/implement a system with it.

Tom

Relevant Pages