[openssl.org #3133] minor make install improvement for Windows/Visual Studio in ms\nt.mak

[Kees Dekker via RT]

Hi,

It may be useful to add the .pdb file to the lib directory in the install 
target. Windows build that adopt OpenSSL may benefit from it. When using 
ssleay32.lib and/or libeay32.lib then Visual Studio may complain about missing 
symbol information. That information is in the pdb file. If a pdb file is not 
provided, then Visual Studio will raise the following warning:

libeay32.lib(cryptlib.obj) : warning LNK4099: PDB 'lib.pdb' was not found with 
'libeay32.lib(cryptlib.obj)' or at 'xyz\lib.pdb'; linking object as if no debug 
info.

Suggestion: change ms\nt.mak a little and add a line, similar to the following 
diff:

474c474
<
---
>   $(CP) "$(OBJ_D)\lib.pdb" "$(INSTALLTOP)\lib"

Regards,
Kees Dekker



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Patch for Correct fix for CVE-2013-0169 for openssl-.0.9.8y

[Costas Stasimos]

Hello!

I'm currenty working with openssl-0.9.8.y. As we can see in the changelog
in the official openssl page there is a correct fix concerning
the CVE-2013-0169 which is only available at version openssl-1.0.1.e.

My question is when do you plan to included this change at the series
0.9.8??

Is there already prepared patch for 0.9.8y for this issue? If yes where I
could download it?

Is it possible to overcome this problem without update to 1.0.1.e?

Also does this issue can lead to "BAD_CLIENT_HANDSHAKE" and dropped valid
SSL connections??

Thanks in advance!

Re: Design change observed at ssl3_get_client_certificate()

[Rajeswari K]

Sorry team. Change observed between openssl 0.9.8g to openssl0.9.8k

Can you please tell us the intent of this change and how we can get out of
this problem.

Regards,
Rajeswari


On Thu, Sep 26, 2013 at 3:18 PM, Rajeswari K wrote:

> Hello Openssl dev team,
>
> Currently we are using openssl 0.9.8q version. Earlier we have used
> openssl 0.9.8k.
> We have seen change in the return value handling of
> ssl_verify_cert_chain() at function ssl3_get_client_certificate().
>
> At openssl 0.9.8k, ssl_verify_cert_chain() is handled like this
>
>  else  { 
> i=ssl_verify_cert_chain(s,sc->cert_chain); if (i < 0) 
> { ret = i;
> goto err;} else if (i == 0)   
>   { 
> al=ssl_verify_alarm_type(s->verify_result);   
>* \*
> SSLerr(SSL_F_SSL3_GET_CLIENT_CERTIFICATE,SSL_R_NO_CERTIFICATE_RETURNED);  
>goto f_err; }  }
>
> But at  openssl 0.9.8q, same code is changed as
>
> else
>
> {
>
>  i=ssl_verify_cert_chain(s,sk);
>
> if (i <= 0)
>
>   {
>
>   al=ssl_verify_alarm_type(s->verify_result);
>
>
> SSLerr(SSL_F_SSL3_GET_CLIENT_CERTIFICATE,SSL_R_NO_CERTIFICATE_RETURNED);
>
> goto f_err;
>
>}
>
> }
>
> Currently we have registered with our callback functions to perform 
> verification of certificates. In our code, we return negative values if CRL 
> fetch//certificate verifitication is in progress. Due to this, current 
> openssl0.9.8q, is treating the negative values as error and sending an alert 
> and clearing its session.
>
> Same code worked with openssl0.9.8k because OPENSSL is not treating negative 
> value as error.
>
> Is there any way we can get out of this situation with openssl0.9.8q?
>
>
> Thanks & Regards,
>
> Rajeswari.
>
>

Design change observed at ssl3_get_client_certificate()

[Rajeswari K]

Hello Openssl dev team,

Currently we are using openssl 0.9.8q version. Earlier we have used openssl
0.9.8k.
We have seen change in the return value handling of ssl_verify_cert_chain()
at function ssl3_get_client_certificate().

At openssl 0.9.8k, ssl_verify_cert_chain() is handled like this

 else  {
i=ssl_verify_cert_chain(s,sc->cert_chain); if (i < 0)
   { ret = i;
  goto err;} else if
(i == 0) {
al=ssl_verify_alarm_type(s->verify_result);
  * \*
SSLerr(SSL_F_SSL3_GET_CLIENT_CERTIFICATE,SSL_R_NO_CERTIFICATE_RETURNED);
goto f_err; }
}

But at  openssl 0.9.8q, same code is changed as

else

{

 i=ssl_verify_cert_chain(s,sk);

if (i <= 0)

  {

  al=ssl_verify_alarm_type(s->verify_result);


SSLerr(SSL_F_SSL3_GET_CLIENT_CERTIFICATE,SSL_R_NO_CERTIFICATE_RETURNED);

goto f_err;

   }

}

Currently we have registered with our callback functions to perform
verification of certificates. In our code, we return negative values
if CRL fetch//certificate verifitication is in progress. Due to this,
current openssl0.9.8q, is treating the negative values as error and
sending an alert and clearing its session.

Same code worked with openssl0.9.8k because OPENSSL is not treating
negative value as error.

Is there any way we can get out of this situation with openssl0.9.8q?


Thanks & Regards,

Rajeswari.

[openssl.org #3132] Query related to d2i_X509 and X509_free

[Sandeepa SHARMA via RT]

Hi,

We are using openssl-1.0.0e. I am facing a memory leak of 98 bytes when I use 
d2i_X509() function. This memory leak is seen even if d2i_X509() return NULL. I 
couldn't find the source code for d2i_X509() and X509_free() function. Can you 
please help me in this.

int secwrap_certCheckExtKeyUsage(unsigned char *cert,   // pointer to 
certificate
unsigned int certLen)   // length of certificate
{
intiReturnStatus = OPENSSL_SECWRAP_FAILURE, iCritical;

X509 *x509Cert = NULL;
const unsigned char *pCert = cert;  // See OpenSSL FAQ. 
Temp pointer recommended.
EXTENDED_KEY_USAGE *extusage = NULL;
int count;

if(cert == NULL || certLen == 0)
{
DEBUGPRINT(DEBUG_DEFAULT,"%s - %d FAIL\n",__FUNCTION__,__LINE__);
return OPENSSL_SECWRAP_FAILURE; // bad parameters
}



   x509Cert = d2i_X509(NULL, &pCert, certLen);   

if(x509Cert == NULL)
{
DEBUGPRINT(DEBUG_DEFAULT,"%s - %d FAIL\n",__FUNCTION__,__LINE__);
return OPENSSL_SECWRAP_FAILURE; // unable to parse 
cert
}

count = X509_get_ext_count(x509Cert);
if(count == 1)   // only 1 extension allowed
{
extusage = (EXTENDED_KEY_USAGE *) X509_get_ext_d2i(x509Cert, 
NID_ext_key_usage, &iCritical, NULL);
if(extusage != NULL && iCritical != 0)  // MUST be Extended 
Key Usage and marked critical
{
if(sk_ASN1_OBJECT_num(extusage) == 1)   // only 1 purpose 
OID allowed
{
if(OBJ_obj2nid(sk_ASN1_OBJECT_value(extusage,0)) == 
NID_code_sign)// MUST be for code signing
{
iReturnStatus = OPENSSL_SECWRAP_SUCCESS;
}
else
{
DEBUGPRINT(DEBUG_DEFAULT,"%s - %d 
FAIL\n",__FUNCTION__,__LINE__);
}
}
else
{
DEBUGPRINT(DEBUG_DEFAULT,"%s - %d 
FAIL\n",__FUNCTION__,__LINE__);
}
}
else
{
DEBUGPRINT(DEBUG_DEFAULT,"%s - %d FAIL\n",__FUNCTION__,__LINE__);
}
}
else
{
DEBUGPRINT(DEBUG_DEFAULT,"%s - %d FAIL count 
%d\n",__FUNCTION__,__LINE__,count);
}



if(x509Cert != NULL)
X509_free(x509Cert);


return iReturnStatus;
}

Regards,
Sandeepa Sharma
Project Leader
(Docsis Team)
STMicrolectonics India
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: FIPS OpenSSL default DRBG continuous test failing

[David Jacobson]

I'm an expert on random number generators and knowledgeable about FIPS 
140.  But I'm not knowledegable about the RNG facilities on OpenSSL.  In 
general you don't "set" the entropy, rather you set up an entropy 
source. However, some systems do allow running on a fixed input string. 
But the design of the system needs to combine that with some other 
things like date&time, processor serial number, etc., that together make 
a value that will never occur more than once.


--David

On 9/25/13 10:10 AM, Karan Popali wrote:

Thanks David.

If I use the default DRBG, do I need to set the entropy?

-Karan


On Wed, Sep 25, 2013 at 9:34 AM, David Jacobson 
mailto:dmjacob...@sbcglobal.net>> wrote:


According to FIPS 140, the continuous test fails if two
consecutive values from the RNG are the same. No matter how
strange or low-entropy the seeding, this should happen only with
vanishingly small probability.  So something is seriously wrong.
 You absolutely should not try to work around this.  You must find
the root cause and fix it.

Also you imply that this is repeatable.  Are the failures exactly
repeatable?  If so, this would suggest that you have no entropy at
all.

--David

On 9/24/13 2:23 PM, karanpopali wrote:

I'm using FIPS OpenSSL on Android and it FIPS_rand_bytes()
fails continuous
test after sometime. I read in the SecurityPolicy that if it
fails then we
need to uninstantiate and re-instantiate the DRBG.

Few questions:
1. Is there any way to avoid this? Will using HMAC DRBG or
Hash DRBG help?
2. Is this a FATAL error?
3. If we hit this error, do we need to restart the process or just
uninstantiate/re-instantiate is enough?

Version info:
FIPS canister: 2.0.1
OpenSSL: 1.0.1c

Thanks,
Karan



--
View this message in context:

http://openssl.6102.n7.nabble.com/FIPS-OpenSSL-default-DRBG-continuous-test-failing-tp46646.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org

Automated List Manager majord...@openssl.org