RE: Problems Identified in Static Source Analysis
Hi David, To generate a static report from Coverity, run cov-format-errors. This command generates a set of HTML pages which contain all the issues found in the last run. Yair -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Hartman Sent: Monday, January 09, 2006 11:19 PM To: Andy Polyakov; openssl-dev@openssl.org Cc: Andrew Schnable Subject: RE: Problems Identified in Static Source Analysis Hi Andy, It turns out there was no easy way to give you the Coverity test results directly. For the runs to be useful, you really need a viewer, and we are limited by the licenses as to who can use the viewer. We have a copy of 0.9.8a in our source tree, and I made the changes to our copy of 0.9.8a. I attached the diffs. I apologize for making these changes against our own copy of the sources, that means the resulting diffs can't be used directly as a patch against your CVS repository since the file revisions will be different. Hopefully this is still useful as you can still use the file names and line numbers. I will work on getting rsynch set up and getting a local copy of your CVS repository so I can submit proper patches in the future. -David > -Original Message- > From: Andy Polyakov [mailto:[EMAIL PROTECTED] > Sent: Sunday, December 18, 2005 7:41 AM > To: openssl-dev@openssl.org; David Hartman > Cc: Andrew Schnable > Subject: Re: Problems Identified in Static Source Analysis > > Hi, > > > We recently ran Coverity, a static source analysis tool, against OpenSSL > > 0.9.7 and 0.9.8. We found a number of problems such as the potential to > > access null pointers, lack of error checking on return codes, etc. > > There are in the neighborhood of 25 errors that we considered worth > fixing. > > > > Would you like us to contribute these fixes back to the project? > > Yes. > > > If so, > > what would be the best format for submitting them? > > Coverity report itself by all means preferred, as more eyeballs on > deciding on what's worth fixing and in which branch is better. If > disclosure on public list such as openssl-dev is not appropriate, send > it to openssl-team. > > > Would you like the diffs or raw sources? > > See "HOW TO CONTRIBUTE TO OpenSSL" paragraph in ./README for formalized > description. > > > Also, which branch would be best? > > The normal workflow goes as following: 1. HEAD [see > http://www.openssl.org/source/repos.html], 2. backport to released > versions. Backports to 0.9.8 are currently very common, while backports > to 0.9.7 are rather rare. Meaning that HEAD is by all means preferred, > but as long as we're not talking about changed functionality or new > features, 0.9.8 is OK for the moment, as it has not diverged too much. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Contribution: doc/HOWTO/key-management.txt
This is aimed at the manager of a technical team, primarily, but also at people getting into the field of cryptography and its application via Apache. I tried to write it approximating the tone of Schneier's Applied Cryptography, but it probably came out sounding much more low-brow. There should be mention of what the OpenSSL code itself can do, and what requires external engine support (i.e., external signing operations), I think. I'm not entirely sure -- I posted it here primarily to engender a bit of discussion. (BTW, a thank-you goes out to Duncan Evans of Thawte for following up with me regarding the statements that I made in the initial document. He's still investigating exactly what happened when, but at this point the Thawte CPS v2.2 now defines a 'Medium' identity assurance, related to "domain-validated" certificates that it now issues under the SSL123 moniker.) -Kyle A Hamilton On 1/9/06, David Holmes <[EMAIL PROTECTED]> wrote: > Hey that's pretty neat. > > Question: Who is the target audience and what level of technical > ability should they be assumed to have? If they are reading this list > or looking through the openssl source code I would guess its higher than > the one that appears to be targetted by this fine document. > > I recommend replacing the "Conclusions" with a sentence that says > something like: > > If you have more money than time, for around $10K you can secure your > keys in a Level III FIPS 140-2 certified device (list of vendors would > follow). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Contribution: doc/HOWTO/key-management.txt
Hey that's pretty neat.
Question: Who is the target audience and what level of technical
ability should they be assumed to have? If they are reading this list
or looking through the openssl source code I would guess its higher than
the one that appears to be targetted by this fine document.
I recommend replacing the "Conclusions" with a sentence that says
something like:
If you have more money than time, for around $10K you can secure your
keys in a Level III FIPS 140-2 certified device (list of vendors would
follow).
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kyle Hamilton
Sent: Wednesday, January 04, 2006 3:04 PM
To: openssl-dev@openssl.org
Subject: Contribution: doc/HOWTO/key-management.txt
Feel free to hack this up as you see fit. Copyright assigned to the
OpenSSL Project 2006, Kyle Hamilton.
HOWTO: Key Management (best practice information) (written by Kyle A
Hamilton, [EMAIL PROTECTED])
1. Introduction
Keys are the heart and soul of how cryptography work -- the algorithms
are publicly-known, so the security of any cryptography lies in the
secrecy of the keys and just how well they're protected.
UNIX file modes provide some level of security; Windows NT and Trusted
UNIX ACLs provide a much higher level of security, but note that in
every case there is a group of users -- the 'superusers' or
'administrators' -- who can bypass any protection scheme that you put on
your keys. In some circumstances ("I just want people to have a
reasonable expectation that they're communicating with my webserver and
not with someone else's") this might be sufficient, depending on what
you mean by 'reasonable expectation'. In other cases, this is not
sufficient (PGP/GPG keys residing on a remote system, for example, that
are being used to sign software tarballs).
2. Background (or, "Why Key Management Is Important")
Every time you generate a 'key', you're creating one of two things: a
public/private (i.e., asymmetric) key pair, or a secret (i.e.,
symmetric) key. These have different properties, and different things
that they are useful for.
For OpenSSL, the one we're most usually concerned with with the
public/private (asymmetric) key pair, though (because of some of the
properties of asymmetric keypairs) we do also have to worry about the
other kind as well.
Public keys are sent off to registration authorities, certifying
authorities, clients of our webservices/email servers/IMAP
servers/POP3 servers, and so on. The way this model works, everyone
knows our public key. Anyone who has our private key can 'prove'
(cryptographically) that they are us. [In a world where cryptographic
signatures are increasingly being viewed as legal signatures, it makes a
lot of sense to ensure that our signatures can't be cryptographically
forged.]
What we get back from the CAs that we send our public keys to are
statements of who we are, what our public key is, and a signature from
the CA that it has verified that this information is correct (i.e., a
'certificate'). Unfortunately, CAs make mistakes, and sometimes CAs
don't do what they say they're going to do. (If you remember the
brouhaha from 1999 or so, someone managed to convince Verisign that he
represented Microsoft, and obtained two certificates from Verisign
stating that they belonged to Microsoft Corporation. This caused
Microsoft to issue an emergency patch including a "Certificate
Revocation List" from Verisign to explicitly tell MS's software that
those two certificates were invalid.) (Thawte Consulting Pty, Ltd has
recently begun issuing certificates in direct violation of their
'certification practice statement' -- i.e., their publicly-vowed
statement of the ONLY situations they will create a certificate in.)
This means that CAs, too, need to keep their private keys private, and
appropriately limit their usage.
3. Essential Key Management Issues
There are several levels of 'key management' you can take, not all of
which can be directly compared. These are, "key and certificate in the
same file", "encrypted key and unencrypted certificate in the same
file", "unencrypted key in one file, certificate in another file",
"encrypted key in one file, certificate in another file", "encrypted key
not directly accessible by the system, certificate in file."
In addition, the longer a private key stays in memory, the more insecure
it becomes. (Webservers that read the private key on startup, for
example, and then leave it in memory to access again and again -- it's a
performance gain, but a security loss.) However, there is no way to
avoid the need for a long-running process to be hardened against
security issues, especially one that listens to network requests -- this
is something to be kept in mind when building an application, or adding
cryptographic functionality to an application that already exists.
So, here are some general guidelines for each of the preceding
scenarios:
a. unencrypted key and c
RE: Problems Identified in Static Source Analysis
Hi Andy, It turns out there was no easy way to give you the Coverity test results directly. For the runs to be useful, you really need a viewer, and we are limited by the licenses as to who can use the viewer. We have a copy of 0.9.8a in our source tree, and I made the changes to our copy of 0.9.8a. I attached the diffs. I apologize for making these changes against our own copy of the sources, that means the resulting diffs can't be used directly as a patch against your CVS repository since the file revisions will be different. Hopefully this is still useful as you can still use the file names and line numbers. I will work on getting rsynch set up and getting a local copy of your CVS repository so I can submit proper patches in the future. -David > -Original Message- > From: Andy Polyakov [mailto:[EMAIL PROTECTED] > Sent: Sunday, December 18, 2005 7:41 AM > To: openssl-dev@openssl.org; David Hartman > Cc: Andrew Schnable > Subject: Re: Problems Identified in Static Source Analysis > > Hi, > > > We recently ran Coverity, a static source analysis tool, against OpenSSL > > 0.9.7 and 0.9.8. We found a number of problems such as the potential to > > access null pointers, lack of error checking on return codes, etc. > > There are in the neighborhood of 25 errors that we considered worth > fixing. > > > > Would you like us to contribute these fixes back to the project? > > Yes. > > > If so, > > what would be the best format for submitting them? > > Coverity report itself by all means preferred, as more eyeballs on > deciding on what's worth fixing and in which branch is better. If > disclosure on public list such as openssl-dev is not appropriate, send > it to openssl-team. > > > Would you like the diffs or raw sources? > > See "HOW TO CONTRIBUTE TO OpenSSL" paragraph in ./README for formalized > description. > > > Also, which branch would be best? > > The normal workflow goes as following: 1. HEAD [see > http://www.openssl.org/source/repos.html], 2. backport to released > versions. Backports to 0.9.8 are currently very common, while backports > to 0.9.7 are rather rare. Meaning that HEAD is by all means preferred, > but as long as we're not talking about changed functionality or new > features, 0.9.8 is OK for the moment, as it has not diverged too much. A. coverity_8a.diffs Description: coverity_8a.diffs
[openssl.org #1267]
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204]: bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
I have found that there might be a different length computing in zlib V1.2.3 (or may be even in 1.2.2). In my opinion the length field set by zlib is ok. But openssl changes this length field in the SSL_OP_TLS_BLOCK_PADDING_BUG handling => ERROR (I traced the problem in openssl and zlib under openssl) Until now I've got only one mail that the error might happen also with 1.2.2 (4) and 1.2.3 under apache. I've got also an hint on a restriction on RC4 which might help. But the restriction might be a problem with my usage scenario. Nothing more. I have produced openssl libs without zlib used by my program. This works fine. And with flexible ZLIB usage around Openssl and zlib level 1 and HTTP-chunking I've got best performance --- better than zlib level 6 (default) inside Openssl. - Christiane >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Kurt Roeckx via RT >Sent: Sunday, December 25, 2005 11:35 AM >To: Kämpfe, Christiane >Cc: openssl-dev@openssl.org >Subject: [openssl.org #1204]: bad record mac because of wrong >SSL_OP_TLS_BLOCK_PADDING_BUG handling > > >Hi, > >Has there been any progress on finding what the cause of this is? > >There is also a bug open about this in the Debian bug tracking at: >http://bugs.debian.org/338006 > >There might be some more useful information in it. > > >Kurt > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Hmm, I want to use this for an multi usable web service independent of apache and no restrictions (or so) for the users or user scenarios about openssl usage ... If the caller has an certificate generated by an not-restricted openssl using whatever he want to to ... how can "I"=web service handle this certificate without getting an "bad record mac" error ? >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of via RT >Sent: Saturday, January 07, 2006 3:22 AM >To: Kämpfe, Christiane >Cc: openssl-dev@openssl.org >Subject: [openssl.org #1204] bug report - 0.9.8 and bad record >mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling > > >For Subversion, which goes through apache, I found that one workaround >is to disable all SSLv3 ciphers except RC4. My apache config now has: > > SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA > >and subversion appears to work again. > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
