[OT] MatrixSSL

[OT] MatrixSSL

[Alex Efros]

Hi!

Below is forward of my email to Gerrit Pape. He didn't reply yet
(I suppose this can be because of some bug/misconfiguration in his
qconfirm spam protection or he just ignore me :)), so maybe somebody else
here can answer on question.

----- Forwarded message from Alex Efros <powerman@powerman.asdfGroup.com> -----

Date: Tue, 6 Jun 2006 02:32:22 +0300
From: Alex Efros <powerman@powerman.asdfGroup.com>
To: Gerrit Pape <pape@smarden.org>
Subject: MatrixSSL

Hi!

I noticed you using MatrixSSL library in your sslio program and I wanna
know your attitude to this library as C-expert (if you remember, I'm
Perl programmer and don't know C good enough).

I've also tried to use MatrixSSL and found some issues. For example,
I try to configure my https:// client based on MatrixSSL to know some
root CA certificates. I've found in /etc/ssl/certs/ 12 root CA
certificates installed by openssl package, and I try to send them into
matrixSslReadKeys() using trustedCAcertFiles param.

There exists two ways how to do this AFAIK:
1) set trustedCAcertFiles to ;-separated list of .pem-files like:
    'cert/vsignss.pem;cert/wellsfgo.pem;cert/nortelCA.pem;...'
2) `cat` all certificated into single .pem file
First way result in "Segmentation fault" in matrixSslReadKeys().
Second way result in "stack smashing attack in function matrixX509ReadCert()"
in matrixSslReadKeys() [this error probably result of my hardened gcc with
pie/ssp patches].

I've send email to MatrixSSL support, but they didn't reply yet.

I'm worrying about these errors because they probably indicate bad,
insecure style of C programming and may result in unexpected segfaults
in long-running script which doing a lot of ssl-work or
remotely exploitable security holes. :( From other view, this can be
single rare mistake in elegant and secure code. I'm not a C-expert and
can't know which supposition correct, so I'm asking you.

If you think this isn't looks like 'single rare mistake', then I probably
shouldn't continue using MatrixSSL and must return to developing my own SSL
perl module - at least there will be no stack overflows there. :-/

-- 
			WBR, Alex.

----- End forwarded message -----

P.S. After sending that email situation was slightly changed:
1) MatrixSSL support replied on my email and provide a fix for described
SegFaults - very bad fix, from my view:
    --- matrixCommon.h	2006-06-07 16:14:38.000000000 +0300
    +++ matrixCommon.h	2006-06-12 15:29:20.000000000 +0300
    @@ -183,1 +183,1 @@
    -#define MAX_CHAIN_LENGTH		8
    +#define MAX_CHAIN_LENGTH		192
but I hope it's just a dirty hack and this issue will be solved in right way
in next release
2) I've found (and fixed myself because MatrixSSL support isn't reply on
my email yet) significant memory leak while reading certificates:
    --- x509.c.orig 2006-04-04 14:14:02.000000000 +0300
    +++ x509.c      2006-06-11 03:17:22.000000000 +0300
    @@ -834,6 +834,7 @@
				    matrixStrDebugMsg("extension format that is notcurrently\n", NULL);
				    matrixStrDebugMsg("recognized.  Please emailsupport@peersec.com\n", NULL);
				    matrixStrDebugMsg("to add support for theextension.\n\n", NULL);
    +                               matrixX509FreeCert(cert);
				    return -1;
			    }
		    }
but I suppose there a lot of similar memory leaks left - memory must be
freed before _each_ 'return -1', I think, and there a lot of them.
3) I've found few minor bugs. :(

So, maybe MatrixSSL is best for embedded environment, but I'm not sure is
it good for OpenSSL replacement for real-world https:// clients and servers.

-- 
			WBR, Alex.

Re: [OT] MatrixSSL

[Charlie Brady]

On Mon, 12 Jun 2006, Alex Efros wrote:

> Below is forward of my email to Gerrit Pape. He didn't reply yet
> (I suppose this can be because of some bug/misconfiguration in his
> qconfirm spam protection or he just ignore me :)), ...

Or perhaps he expects you have read "Why ask questions in public" - 
http://www.eyrie.org/~eagle/faqs/questions.html

[I think this question is more appropriate to the "misc" list.]

Re: [OT] MatrixSSL

[Alex Efros]

Hi!

On Mon, Jun 12, 2006 at 09:56:47AM -0400, Charlie Brady wrote:
> >Below is forward of my email to Gerrit Pape. He didn't reply yet
> >(I suppose this can be because of some bug/misconfiguration in his
> >qconfirm spam protection or he just ignore me :)), ...
> 
> Or perhaps he expects you have read "Why ask questions in public" - 
> http://www.eyrie.org/~eagle/faqs/questions.html

Of course I've read it. :) But this question isn't really related to
his software, so I suppose it's OffTopic in this list and decide to
send it by email. I'm not aware about 'misc' maillist existence.

-- 
			WBR, Alex.

Re: [OT] MatrixSSL

[Charlie Brady]

On Mon, 12 Jun 2006, Alex Efros wrote:

> Of course I've read it. :) But this question isn't really related to
> his software, ...

His program sslio links against matrixSSL

> so I suppose it's OffTopic in this list and decide to
> send it by email. I'm not aware about 'misc' maillist existence.

http://smarden.org/ipsvd/index.html

  ipsvd is discussed on the <misc@list.smarden.org> mailing list. To
  subscribe send an empty email to <misc-subscribe@list.smarden.org>. Send
  an empty email to <misc-help@list.smarden.org> for more information about
  this list.

matrixSSL is GPLd. If you are getting no response from the developer, I'd 
suggest you publish a fixed version.

Re: [OT] MatrixSSL

[Alex Efros]

Hi!

On Mon, Jun 12, 2006 at 11:04:53AM -0400, Charlie Brady wrote:
> http://smarden.org/ipsvd/index.html
> 
>  ipsvd is discussed on the <misc@list.smarden.org> mailing list. To
>  subscribe send an empty email to <misc-subscribe@list.smarden.org>. Send
>  an empty email to <misc-help@list.smarden.org> for more information about
>  this list.

Thanks, I'll repost it there.

> matrixSSL is GPLd. If you are getting no response from the developer, I'd 
> suggest you publish a fixed version.

Hehehe. I've asked MatrixSSL support about 10 different issues but they
reply only about 3 of them... so I still wait for other replies. :-)

-- 
			WBR, Alex.