problem with pem file, no start line. centos.

2010-11-18 Thread Steve yongjin Shin
Hi all.

I have trouble with using certificates with openssl.

os : centos5.4
kernel : 2.6.27.29
openssl-ver : 0.9.8e-fips-rhel5

At first, I created rsa private key and let's suppose this is test.key.

with test.key I generated certificate request. and lets suppose this as 
test.csr

with test.csr I requested ssl certificate to verisign.com

and they gave me a certificates.

and I save it as test.crt.


with this certificate, I try to run vnc reflect server.
my system requires pem file which includes rsa private key.
in here, I use openssl.

so, I concatenated test.key and test.crt as test.pem

when I verify test.pem with openssl,
(openssl verify test.pem), it says OK.

when I print out the contains,
(openssl x509 -in test.pem -text)
it shows

==

Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number:
    16:81:64:a4:28:ca:12:df:ab:12:f1:9f:b1:b9:35:54
    Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=US, O=VeriSign, Inc., OU=For Test Purposes Only.  No 
assurances., CN=VeriSign Trial Secure Server Root CA - G2
    Validity
    Not Before: Apr  1 00:00:00 2009 GMT
    Not After : Mar 31 23:59:59 2029 GMT
    Subject: C=US, O=VeriSign, Inc., OU=For Test Purposes Only.  No 
assurances., CN=VeriSign Trial Secure Server Root CA - G2
    Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
    RSA Public Key: (2048 bit)
    Modulus (2048 bit):
.omitted..
    Exponent: 65537 (0x10001)
    X509v3 extensions:
    X509v3 Basic Constraints: critical
    CA:TRUE
    X509v3 Key Usage: critical
    Certificate Sign, CRL Sign
    1.3.6.1.5.5.7.1.12:
    
0_.].[0Y0W0U..image/gif0!0.0...+..k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif

    X509v3 Subject Key Identifier:
    48:19:E7:92:6F:92:9D:34:63:99:C0:F0:99:C8:D6:A5:8C:8C:7F:65
    Signature Algorithm: sha1WithRSAEncryption
    omitted...
-BEGIN CERTIFICATE-
..omitted.
-END CERTIFICATE-
==


when I open test.pem
this file shows.
==

-BEGIN RSA PRIVATE KEY-
...omitted..
-END RSA PRIVATE KEY-
-BEGIN CERTIFICATE-
...omitted...
-END CERTIFICATE-
=


so I started my vnc reflect server
but, it shows error message
=

openssl_init: SSL_CTX_use_certificate_chain_file() failed.
ssl error: error:0906D06C:PEM routines:PEM_read_bio:no start line
=


my test.pem file itself definitely has a start line.
but, it shows that kind of error message.

Searching google and the archives of this list turned nothing up
so I'm hoping someone here can help shed some light on this issue. 

Thanks in advance.



  

Re: problem with pem file, no start line. centos.

2010-11-18 Thread David Schwartz

On 11/18/2010 12:50 AM, Steve yongjin Shin wrote:


-BEGIN RSA PRIVATE KEY-
...omitted..
-END RSA PRIVATE KEY-
-BEGIN CERTIFICATE-
...omitted...
-END CERTIFICATE-
=
so I started my vnc reflect server
but, it shows error message
=
openssl_init: SSL_CTX_use_certificate_chain_file() failed.
ssl error: error:0906D06C:PEM routines:PEM_read_bio:no start line
=
my test.pem file itself definitely has a start line.
but, it shows that kind of error message.


The program wants a private key file, not an RSA private key file. You 
can convert one to the other with 'openssl pkey'.


openssl pkey -in my_rsa_private_key.pem -out my_private_key.pem

DS

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.0b testssl fails

2010-11-18 Thread Brodie Thiesfield
On Wed, Nov 17, 2010 at 9:38 AM, Victor Duchovni
victor.ducho...@morganstanley.com wrote:
 On Tue, Nov 16, 2010 at 11:36:50PM +0100, Mounir IDRASSI wrote:

 Under Windows (32bit and 64bit) with VC++ 2008, all tests are OK. But under
 Ubuntu 8.04 LTS with gcc 4.2.4, I have the same error.

 I don't see anything OS specific in the changes introduced in t1_lib.c or
 s3_srvr.c. Could it be a gcc bug?

 No, rather the tests on Windows are not as comprehensive as those
 on Unix. There is no tls1 test.

So does anyone know if this test failure and quick checkin fix mean
that we should shelve the 1.0.0b release and we wait for a more fully
tested 1.0.0c?

Regards,
Brodie
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: Question regarding OpenSSL Security Advisory

2010-11-18 Thread Pandit Panburana
Hi,

   I am not clear about the condition that vulnerability when using internal 
session caching mechanism. Is it the same thing as TLS session caching or this 
is some thing different?

Thank you,
- Pandit 




From: David Schwartz dav...@webmaster.com
To: openssl-users@openssl.org
Cc: Nivedita Melinkeri nivedita...@gmail.com
Sent: Wed, November 17, 2010 4:15:36 AM
Subject: Re: Question regarding OpenSSL Security Advisory

On 11/16/2010 11:06 PM, Nivedita Melinkeri wrote:

 Hi,
 I had some questions about the latest security advisory. I understand
 that this applies to multi-threaded application while using ssl sessions.

Correct.

 If the application is written thread safe using
 CRYPTO_set_locking_callback functions will the vulnerability still apply ?

If it didn't, it wouldn't be a vulnerability at all.

 If the ssl code calls the locking callback function before accessing the
 internal session cache then the vulnerability should not
 apply to above mentioned applications.

Right, it shouldn't, but it does. That's what makes it a vulnerability. Code 
not 
working under conditions where it cannot be expected to work is not a 
vulnerability, it's simply misuse. This is a vulnerability because it affects 
applications that use the code correctly.

DS

__
OpenSSL Projecthttp://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager  majord...@openssl.org



  

Re: OpenSSL 1.0.0b testssl fails

2010-11-18 Thread Dr. Stephen Henson
On Thu, Nov 18, 2010, Brodie Thiesfield wrote:

 On Wed, Nov 17, 2010 at 9:38 AM, Victor Duchovni
 victor.ducho...@morganstanley.com wrote:
  On Tue, Nov 16, 2010 at 11:36:50PM +0100, Mounir IDRASSI wrote:
 
  Under Windows (32bit and 64bit) with VC++ 2008, all tests are OK. But under
  Ubuntu 8.04 LTS with gcc 4.2.4, I have the same error.
 
  I don't see anything OS specific in the changes introduced in t1_lib.c or
  s3_srvr.c. Could it be a gcc bug?
 
  No, rather the tests on Windows are not as comprehensive as those
  on Unix. There is no tls1 test.
 
 So does anyone know if this test failure and quick checkin fix mean
 that we should shelve the 1.0.0b release and we wait for a more fully
 tested 1.0.0c?
 

A 1.0.0c release is planned in the next few days. We're just seeing if any
other issues arise before the release: a couple have been fixed already.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: Question regarding OpenSSL Security Advisory

2010-11-18 Thread David Schwartz

On 11/18/2010 7:26 AM, Pandit Panburana wrote:


I am not clear about the condition that vulnerability when using
internal session caching mechanism. Is it the same thing as TLS session
caching or this is some thing different?


The internal session caching mechanism caches TSL session information. 
If that doesn't answer your question, then I'm not sure what you're asking.


DS

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.0b testssl fails

2010-11-18 Thread William A. Rowe Jr.
On 11/18/2010 10:36 AM, Dr. Stephen Henson wrote:
 
 A 1.0.0c release is planned in the next few days. We're just seeing if any
 other issues arise before the release: a couple have been fixed already.

Have any observed issues affected 0.9.8p?  If so, is there a planned .8q?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.0b testssl fails

2010-11-18 Thread Dr. Stephen Henson
On Thu, Nov 18, 2010, William A. Rowe Jr. wrote:

 On 11/18/2010 10:36 AM, Dr. Stephen Henson wrote:
  
  A 1.0.0c release is planned in the next few days. We're just seeing if any
  other issues arise before the release: a couple have been fixed already.
 
 Have any observed issues affected 0.9.8p?  If so, is there a planned .8q?

No, both the original SNAFU (the self test failure) and the other issues
(all platform compilation problems so far) affect OpenSSL 1.0.0b only.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.0b testssl fails

2010-11-18 Thread Victor Duchovni
On Thu, Nov 18, 2010 at 11:12:11AM -0600, William A. Rowe Jr. wrote:

 On 11/18/2010 10:36 AM, Dr. Stephen Henson wrote:
  
  A 1.0.0c release is planned in the next few days. We're just seeing if any
  other issues arise before the release: a couple have been fixed already.
 
 Have any observed issues affected 0.9.8p?  If so, is there a planned .8q?

None that are publically visible. You can check for yourself:

http://cvs.openssl.org/timeline

No commits to the 0.9.8 branch after the release of 0.9.8p.

http://cvs.openssl.org/chngview?cn=19996

The 1.0.0b issues are just the one reported in this thread:

http://cvs.openssl.org/chngview?cn=20001

and a couple of platform variants where elimination of dead variables
left non-working code referencing the eliminated variables.

http://cvs.openssl.org/chngview?cn=20008
http://cvs.openssl.org/chngview?cn=20005

So far, it looks like the 20001 patch is sufficient for most
platforms.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: Question regarding OpenSSL Security Advisory

2010-11-18 Thread Nivedita Melinkeri
Hey Pandit,

From what I understand the vulnerability can apply if:

1) Internal session caching is *not* disable  - This means the session cache
is mantained in SSL_CTX.
2) Internal Lookup is not disabled  - This means that the ssl
code will lookup the session cache on receiving ClientHello with valid
session Id.
3) Your application is designed such that you create a SSL_CTX and multiple
threads can access it. In this case multiple threads could be accessing the
same session object (from session cache). T he function in t1_lib.c




On Thu, Nov 18, 2010 at 7:26 AM, Pandit Panburana ppanb...@yahoo.comwrote:

  Hi,

I am not clear about the condition that vulnerability when using
 internal session caching mechanism. Is it the same thing as TLS session
 caching or this is some thing different?

 Thank you,
 - Pandit

  --
 *From:* David Schwartz dav...@webmaster.com
 *To:* openssl-users@openssl.org
 *Cc:* Nivedita Melinkeri nivedita...@gmail.com
 *Sent:* Wed, November 17, 2010 4:15:36 AM
 *Subject:* Re: Question regarding OpenSSL Security Advisory

 On 11/16/2010 11:06 PM, Nivedita Melinkeri wrote:

  Hi,
  I had some questions about the latest security advisory. I understand
  that this applies to multi-threaded application while using ssl sessions.

 Correct.

  If the application is written thread safe using
  CRYPTO_set_locking_callback functions will the vulnerability still apply
 ?

 If it didn't, it wouldn't be a vulnerability at all.

  If the ssl code calls the locking callback function before accessing the
  internal session cache then the vulnerability should not
  apply to above mentioned applications.

 Right, it shouldn't, but it does. That's what makes it a vulnerability.
 Code not working under conditions where it cannot be expected to work is not
 a vulnerability, it's simply misuse. This is a vulnerability because it
 affects applications that use the code correctly.

 DS

 __
 OpenSSL Projecthttp://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager  majord...@openssl.org




Re: Question regarding OpenSSL Security Advisory

2010-11-18 Thread Nivedita Melinkeri

 Hey Pandit,


Sorry for sending out the previous before it was complete. So here it
goes


 From what I understand the vulnerability can apply if:

 1) Internal session caching is *not* disable  - This means the session
 cache is mantained in SSL_CTX.
 2) Internal session cache Lookup is *not* disabled  - This means that the
 ssl code will lookup the session cache on receiving ClientHello with valid
 session Id.
 3) Your application is designed such that you create a SSL_CTX and multiple
 threads can access it. In this case multiple threads could be accessing the
 same session object (from session cache). The function
 ssl_parse_clienthello_tlsext in t1_lib.c has unsynchronized access to
 members in session object which could cause the vulnerability.


 David/other experinced openssl users correct me if you think this
 understanding is incottect.

  Regards,

Nivedita




  On Thu, Nov 18, 2010 at 7:26 AM, Pandit Panburana ppanb...@yahoo.comwrote:

  Hi,

I am not clear about the condition that vulnerability when using
 internal session caching mechanism. Is it the same thing as TLS session
 caching or this is some thing different?

 Thank you,
 - Pandit

  --
 *From:* David Schwartz dav...@webmaster.com
 *To:* openssl-users@openssl.org
 *Cc:* Nivedita Melinkeri nivedita...@gmail.com
 *Sent:* Wed, November 17, 2010 4:15:36 AM
 *Subject:* Re: Question regarding OpenSSL Security Advisory

 On 11/16/2010 11:06 PM, Nivedita Melinkeri wrote:

  Hi,
  I had some questions about the latest security advisory. I understand
  that this applies to multi-threaded application while using ssl
 sessions.

 Correct.

  If the application is written thread safe using
  CRYPTO_set_locking_callback functions will the vulnerability still apply
 ?

 If it didn't, it wouldn't be a vulnerability at all.

  If the ssl code calls the locking callback function before accessing the
  internal session cache then the vulnerability should not
  apply to above mentioned applications.

 Right, it shouldn't, but it does. That's what makes it a vulnerability.
 Code not working under conditions where it cannot be expected to work is not
 a vulnerability, it's simply misuse. This is a vulnerability because it
 affects applications that use the code correctly.

 DS

 __
 OpenSSL Projecthttp://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager  majord...@openssl.org





Re: OpenSSL 1.0.0b testssl fails

2010-11-18 Thread William A. Rowe Jr.
On 11/18/2010 12:05 PM, Victor Duchovni wrote:
 
 None that are publically visible. You can check for yourself:
 
 No commits to the 0.9.8 branch after the release of 0.9.8p.
 
 http://cvs.openssl.org/chngview?cn=19996

I was aware of this.  It's why I raised the question, if any of these were
slated for backport, but simply not applied yet.  The answer is no, so that
resolves my questions.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: Question regarding OpenSSL Security Advisory

2010-11-18 Thread Pandit Panburana
Thank you David and Nivedita. I think I got it.

-Pandit




From: Nivedita Melinkeri nivedita...@gmail.com
To: Pandit Panburana ppanb...@yahoo.com
Cc: openssl-users@openssl.org
Sent: Thu, November 18, 2010 1:53:22 PM
Subject: Re: Question regarding OpenSSL Security Advisory


Hey Pandit,
 
Sorry for sending out the previous before it was complete. So here it 
goes
 
From what I understand the vulnerability can apply if:
 
1) Internal session caching is not disable  - This means the session cache is 
mantained in SSL_CTX.
2) Internal session cache Lookup is not disabled  - This means that the ssl 
code 
will lookup the session cache on receiving ClientHello with valid session Id.
3) Your application is designed such that you create a SSL_CTX and multiple 
threads can access it. In this case multiple threads could be accessing the 
same 
session object (from session cache). The function ssl_parse_clienthello_tlsext 
in t1_lib.c has unsynchronized access to members in session object which could 
cause the vulnerability.
 
David/other experinced openssl users correct me if you think this 
understanding 
is incottect.

 Regards,
Nivedita
 
 
 
On Thu, Nov 18, 2010 at 7:26 AM, Pandit Panburana ppanb...@yahoo.com wrote:

Hi,


   I am not clear about the condition that vulnerability when using internal 
session caching mechanism. Is it the same thing as TLS session caching or 
this 
is some thing different?


Thank you,
- Pandit 




 From: David Schwartz dav...@webmaster.com
To: openssl-users@openssl.org
Cc: Nivedita Melinkeri nivedita...@gmail.com
Sent: Wed, November 17, 2010 4:15:36 AM
Subject: Re: Question regarding OpenSSL Security Advisory
 

On 11/16/2010 11:06 PM, Nivedita Melinkeri wrote:

 Hi,
 I had some questions about the latest security advisory. I understand
 that this applies to multi-threaded application while using ssl sessions.

Correct.

 If the application is written thread safe using
 CRYPTO_set_locking_callback functions will the vulnerability still apply ?

If it didn't, it wouldn't be a vulnerability at all.

 If the ssl code calls the locking callback function before accessing the
 internal session cache then the vulnerability should not
 apply to above mentioned applications.

Right, it shouldn't, but it does. That's what makes it a vulnerability. Code 
not 
working under conditions where it cannot be expected to work is not a 
vulnerability, it's simply misuse. This is a vulnerability because it affects 
applications that use the code correctly.

DS


__
OpenSSL Projecthttp://www.openssl.org/
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager  majord...@openssl.org






  

Re: Question regarding OpenSSL Security Advisory

2010-11-18 Thread Muhammed Shafeek
In the Advisory it is mentioned that
Users of all OpenSSL 0.9.8 releases from 0.9.8f through 0.9.8o should
update
to the OpenSSL 0.9.8p release which contains a patch to correct this issue.

What about users of OpenSSL releases before 0.9.8f ? Isn't the vulnerability
applicable there as well?

Thanks
Shafeek



 On Tue, Nov 16, 2010 at 7:15 AM, OpenSSL open...@master.openssl.orgwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 OpenSSL Security Advisory [16 November 2010]

 TLS extension parsing race condition.
 =

 A flaw has been found in the OpenSSL TLS server extension code parsing
 which
 on affected servers can be exploited in a buffer overrun attack.

 The OpenSSL security team would like to thank Rob Hulswit for reporting
 this
 issue.

 The fix was developed by Dr Stephen Henson of the OpenSSL core team.

 This vulnerability is tracked as CVE-2010-3864

 Who is affected?
 =

 All versions of OpenSSL supporting TLS extensions contain this
 vulnerability
 including OpenSSL 0.9.8f through 0.9.8o, 1.0.0, 1.0.0a releases.

 Any OpenSSL based TLS server is vulnerable if it is multi-threaded and
 uses
 OpenSSL's internal caching mechanism. Servers that are multi-process
 and/or
 disable internal session caching are NOT affected.

 In particular the Apache HTTP server (which never uses OpenSSL internal
 caching) and Stunnel (which includes its own workaround) are NOT affected.

 Recommendations for users of OpenSSL
 =

 Users of all OpenSSL 0.9.8 releases from 0.9.8f through 0.9.8o should
 update
 to the OpenSSL 0.9.8p release which contains a patch to correct this
 issue.

 Users of OpenSSL 1.0.0 and 1.0.0a should update to the OpenSSL 1.0.0b
 release
 which contains a patch to correct this issue.

 If upgrading is not immediately possible, the relevant source code patch
 provided in this advisory should be applied.

 Patch for OpenSSL 0.9.8 releases
 

 Index: ssl/t1_lib.c
 ===
 RCS file: /v/openssl/cvs/openssl/ssl/t1_lib.c,v
 retrieving revision 1.13.2.27
 diff -u -r1.13.2.27 t1_lib.c
 - --- ssl/t1_lib.c  12 Jun 2010 13:18:58 -  1.13.2.27
 +++ ssl/t1_lib.c15 Nov 2010 15:20:14 -
 @@ -432,14 +432,23 @@
switch (servname_type)
{
case TLSEXT_NAMETYPE_host_name:
 - - if (s-session-tlsext_hostname ==
 NULL)
 +   if (!s-hit)
{
 - - if (len 
 TLSEXT_MAXLEN_host_name ||
 - -
 ((s-session-tlsext_hostname = OPENSSL_malloc(len+1)) == NULL))
 +
 if(s-session-tlsext_hostname)
 +   {
 +   *al =
 SSL_AD_DECODE_ERROR;
 +   return 0;
 +   }
 +   if (len 
 TLSEXT_MAXLEN_host_name)
{
*al =
 TLS1_AD_UNRECOGNIZED_NAME;
return 0;
}
 +   if
 ((s-session-tlsext_hostname = OPENSSL_malloc(len+1)) == NULL)
 +   {
 +   *al =
 TLS1_AD_INTERNAL_ERROR;
 +   return 0;
 +   }

  memcpy(s-session-tlsext_hostname, sdata, len);

  s-session-tlsext_hostname[len]='\0';
if
 (strlen(s-session-tlsext_hostname) != len) {
 @@ -452,7 +461,8 @@

}
else
 - - s-servername_done =
 strlen(s-session-tlsext_hostname) == len
 +   s-servername_done =
 s-session-tlsext_hostname
 +   
 strlen(s-session-tlsext_hostname) == len

 strncmp(s-session-tlsext_hostname, (char *)sdata, len) == 0;

break;

 Patch for OpenSSL 1.0.0 releases
 

 Index: ssl/t1_lib.c
 ===
 RCS file: /v/openssl/cvs/openssl/ssl/t1_lib.c,v
 retrieving revision 1.64.2.14
 diff -u -r1.64.2.14 t1_lib.c
 - --- ssl/t1_lib.c  15 Jun 2010 17:25:15