[Cryptography] GnuTLS -- time to look at the diff.

[Bill Frantz]

On 3/6/14 at 12:12 AM, hallam at gmail.com (Phillip Hallam-Baker) wrote:

>Coding risk is just another risk and there are different ways to control.
>We have just seen the failure of the open source security argument. There
>are many good reasons to use open source licenses and public domain. But
>publishing the source code does not sprinkle magic security dust over it.
>
>What it does mean is that we have the chance to learn from the error should
>we choose to..

We have a remarkably poor record of learning from past mistakes. 
Buffer overruns are a very clear example. We could use 
languages, PL/I is one of the early ones, where buffer overruns 
are not possible, but we don't. We could use languages where use 
after free is impossible, but we don't. etc. We could even do 
things with macros, libraries etc., to address these problems, 
but we don't.

Admittedly, all these safer languages are implemented in unsafe 
languages -- machine language at the bottom. But if we fix a bug 
at the language level, we have fixed it for all the applications 
written in that language, a much better use of debugging resources.

What we have is a history or having a problem and doing nothing 
to solve it. Instead we rely on techniques which don't work, 
like code reviews. We are unwilling to accept any solution to 
problems, even ones which repeatedly show up in the wild, if it 
makes the program slower. It is as if speed trumps correctness.


We also have a serious problem with demonstrating the 
correctness of security programs. For must programs we are 
interested in what they can do. That is relatively easy to test 
for. You try it and if it works the program passes.

With security programs we are mostly interested in what you 
can't do. That is much harder to demonstrate through testing. 
Sometimes we can turn the problem around into what the program 
can do. Can it reject a TLS connection where the signature hash 
in the signature isn't actually the hash of the connection setup 
exchange. Can it reject a connection where the certificate 
presented didn't actually certify the key presented. etc. etc. 
But for many issues, the attack hasn't been invented yet.

It is depressing to think that the problem is primarily cultural.

CHeers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"After all, if the conventional wisdom was 
working, the
408-356-8506       | rate of systems being compromised would be 
going down,
www.pwpconsult.com | wouldn't it?" -- Marcus Ranum