From janjust at nikhef.nl  Mon Feb  1 09:03:57 2016
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Mon, 01 Feb 2016 10:03:57 +0100
Subject: [openssl-users] Certificate verification failure
In-Reply-To: <c3ed5b0c1693432aae6148131a1e2c61@SW550EXP003.visa.com>
References: <c3ed5b0c1693432aae6148131a1e2c61@SW550EXP003.visa.com>
Message-ID: <56AF1F7D.6000008@nikhef.nl>

Yan, Bob wrote:
>
> Dear Sir/Madam,
>
> I have an application which acting as SSL server. When the application 
> loads the root and intermediate CA files from a CA path, the handshake 
> between my application and openssl client was failed at the point when 
> my application was authenticating the client?s certificate. But when I 
> bound the root CA and intermediate CA into a single pem file and 
> reload it from my application, the handshake is successful. Could 
> anybody help me resolve this issue? Below is the sample of my 
> application code for loading the CA certificates:
>
> if (SSL_CTX_load_verify_locations(ctx, caFile, caPath) != 1) {
>
> exit;
>
> }
>
> if (SSL_CTX_set_default_verify_paths(ctx) != 1) {
>
> exit;
>
> }
>
> if (SSL_CTX_use_certificate_chain_file(ctx, certFile) != 1) {
>
> exit;
>
> }
>
> if (SSL_CTX_use_PrivateKey_file(ctx, keyFile, SSL_FILETYPE_PEM) != 1) {
>
> exit;
>
> }
>
> SSL_CTX_set_verify_depth(ctx, chainDepths);
>
> SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | 
> SSL_VERIFY_FAIL_IF_NO_PEER_CERT, callback);
>
> SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2);
>

when you're using CA path , what are the contents of this CA path 
directory? In it you should have placed the root and intermediate CA 
files using special names. Instead of using "ca.pem" you need to have a 
file "<hash>.0" , where <hash> is the output of "openssl x509 -hash 
-noout -in ca.pem" (and similarly for the intermediate CA file).

JJK


From mainardinicholas at gmail.com  Mon Feb  1 11:57:37 2016
From: mainardinicholas at gmail.com (Nicholas Mainardi)
Date: Mon, 1 Feb 2016 12:57:37 +0100
Subject: [openssl-users]  Certificate Chain Verify Error
Message-ID: <CAJi3d3vo+vFko+45+tuHwxnnotN0L9zpLL_2x+HKVf1_snBGhA@mail.gmail.com>

I wrote this small program which takes as input X509 certificates,
base64-encoded, parse them and build a certificate chain, which is
eventually verified by x509_Verify_cert(). The last certificate is added to
the trusted store if it's self-signed, in order to avoid OpenSSL policy
about self.signed certificates, as it's recommended in this post
<https://zakird.com/2013/10/13/certificate-parsing-with-openssl/>. The code
is at this pastebin link <http://pastebin.com/2N2DSxbe>.

However, when I run this with a correct certificate chain (Facebook one,
already tested with other libraries), I got error 7, certificate signature
validation, at depth 1. The certificate chain is composed by server
certificate, CA certificate and a self-signed root certificate, which is
also in the trusted system store. Hence, it seems that the public key of
the self-signed root certificate is not correctly used to verify the
signature on the CA certificate. Moreover, I compile the same source but
linking boringSSL crypto library instead of OpenSSL one, and everything
works perfectly. Hence, my hyphotesis is that this is an OpenSSL issue
found by Google and fixed in BoringSSL, but it has not been fixed in
OpenSSL yet. So, I would like to know if I'm missing some steps in order to
properly use x509_verify_cert() method, or my hyphotesis about BoringSSL
fixing could be appropriate.

Thank You,

Nicholas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160201/a9416297/attachment-0001.html>

From fm at frank4dd.com  Mon Feb  1 12:30:47 2016
From: fm at frank4dd.com (Frank Migge)
Date: Mon, 01 Feb 2016 21:30:47 +0900
Subject: [openssl-users] Certificate Chain Verify Error
In-Reply-To: <CAJi3d3vo+vFko+45+tuHwxnnotN0L9zpLL_2x+HKVf1_snBGhA@mail.gmail.com>
References: <CAJi3d3vo+vFko+45+tuHwxnnotN0L9zpLL_2x+HKVf1_snBGhA@mail.gmail.com>
Message-ID: <56AF4FF7.9060108@frank4dd.com>

Hi Nicholas,

Not calling OpenSSL_add_all_algorithms();  at the beginning could cause it?

Cheers,
Frank

> Nicholas Mainardi <mailto:mainardinicholas at gmail.com>
> Monday, February 01, 2016 8:57 PM
> I wrote this small program which takes as input X509 certificates, 
> base64-encoded, parse them and build a certificate chain, which is 
> eventually verified by |x509_Verify_cert()|. The last certificate is 
> added to the trusted store if it's self-signed, in order to avoid 
> OpenSSL policy about self.signed certificates, as it's recommended in 
> this post 
> <https://zakird.com/2013/10/13/certificate-parsing-with-openssl/>. The 
> code is at this pastebin link <http://pastebin.com/2N2DSxbe>.
>
> However, when I run this with a correct certificate chain (Facebook 
> one, already tested with other libraries), I got error 7, certificate 
> signature validation, at depth 1. The certificate chain is composed by 
> server certificate, CA certificate and a self-signed root certificate, 
> which is also in the trusted system store. Hence, it seems that the 
> public key of the self-signed root certificate is not correctly used 
> to verify the signature on the CA certificate. Moreover, I compile the 
> same source but linking boringSSL crypto library instead of OpenSSL 
> one, and everything works perfectly. Hence, my hyphotesis is that this 
> is an OpenSSL issue found by Google and fixed in BoringSSL, but it has 
> not been fixed in OpenSSL yet. So, I would like to know if I'm missing 
> some steps in order to properly use |x509_verify_cert()| method, or my 
> hyphotesis about BoringSSL fixing could be appropriate.
>
> Thank You,
>
> Nicholas
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
Sent with Postbox <http://www.getpostbox.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160201/83a8a715/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160201/83a8a715/attachment.jpg>

From mainardinicholas at gmail.com  Mon Feb  1 12:53:37 2016
From: mainardinicholas at gmail.com (Nicholas Mainardi)
Date: Mon, 1 Feb 2016 13:53:37 +0100
Subject: [openssl-users] Certificate Chain Verify Error
In-Reply-To: <56AF4FF7.9060108@frank4dd.com>
References: <CAJi3d3vo+vFko+45+tuHwxnnotN0L9zpLL_2x+HKVf1_snBGhA@mail.gmail.com>
 <56AF4FF7.9060108@frank4dd.com>
Message-ID: <CAJi3d3tEOF5qG2o03VYphh6V2o7_=fC7BVJYQAAU06uODGSWyw@mail.gmail.com>

Hi Frank,

Now it's properly working! I was not aware I have to call that function to
use OpenSSL algorithms. Thank You very much :)

Cheers,

Nicholas

2016-02-01 13:30 GMT+01:00 Frank Migge <fm at frank4dd.com>:

> Hi Nicholas,
>
> Not calling OpenSSL_add_all_algorithms();  at the beginning could cause
> it?
>
> Cheers,
> Frank
>
> Nicholas Mainardi <mainardinicholas at gmail.com>
> Monday, February 01, 2016 8:57 PM
> I wrote this small program which takes as input X509 certificates,
> base64-encoded, parse them and build a certificate chain, which is
> eventually verified by x509_Verify_cert(). The last certificate is added
> to the trusted store if it's self-signed, in order to avoid OpenSSL policy
> about self.signed certificates, as it's recommended in this post
> <https://zakird.com/2013/10/13/certificate-parsing-with-openssl/>. The
> code is at this pastebin link <http://pastebin.com/2N2DSxbe>.
>
> However, when I run this with a correct certificate chain (Facebook one,
> already tested with other libraries), I got error 7, certificate signature
> validation, at depth 1. The certificate chain is composed by server
> certificate, CA certificate and a self-signed root certificate, which is
> also in the trusted system store. Hence, it seems that the public key of
> the self-signed root certificate is not correctly used to verify the
> signature on the CA certificate. Moreover, I compile the same source but
> linking boringSSL crypto library instead of OpenSSL one, and everything
> works perfectly. Hence, my hyphotesis is that this is an OpenSSL issue
> found by Google and fixed in BoringSSL, but it has not been fixed in
> OpenSSL yet. So, I would like to know if I'm missing some steps in order to
> properly use x509_verify_cert() method, or my hyphotesis about BoringSSL
> fixing could be appropriate.
>
> Thank You,
>
> Nicholas
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> --
> Sent with Postbox <http://www.getpostbox.com>
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160201/da31e90b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160201/da31e90b/attachment.jpg>

From redmond at 139.com  Mon Feb  1 13:42:11 2016
From: redmond at 139.com (Redmond@139.)
Date: Mon, 1 Feb 2016 21:42:11 +0800 (CST)
Subject: [openssl-users] How do I verify the pin of USBKEY?
Message-ID: <2b0c56af5febbe9-00005.Richmail.00044707082325592579@139.com>


hello

  it's not relative to the OPENSSL diretly,however I have no idea totally except to send email to you.please help me,although I'm not familiar with CryptoAPI 
program,however with Google,I have written the following code, I have 
two questions on CSP program,I'm using Win7 & Visual Studio 2008


#1 how do I verify the pin of USBKEY hardware via CryptoAPI?





#include "stdafx.h"
#include <windows.h>
#include <wincrypt.h>
#include "iostream"
#pragma comment(lib,"crypt32.lib")

using namespace std

int _tmain(int argc, _TCHAR* argv[])
{
    
    PCCERT_CONTEXT m_pCertContext
    HCERTSTORE m_hStore
    m_pCertContext = NULL
    m_hStore = NULL


    if(m_pCertContext == NULL)
    {
        string strOName("Organization ClassA CA")
        TCHAR* lpszStoreName =_T("MY")
         HCERTSTORE m_hStore = CertOpenSystemStore(NULL, lpszStoreName)

        if (m_hStore) 
        {    
            CERT_RDN certRDN
            certRDN.cRDNAttr = 1
            certRDN.rgRDNAttr = new CERT_RDN_ATTR
            certRDN.rgRDNAttr->pszObjId = szOID_ORGANIZATIONAL_UNIT_NAME
            certRDN.rgRDNAttr->dwValueType = CERT_RDN_ANY_TYPE
            certRDN.rgRDNAttr->Value.pbData = (BYTE *) strOName.c_str()
            certRDN.rgRDNAttr->Value.cbData = strlen(strOName.c_str())
            PCCERT_CONTEXT pCurrent = NULL
            pCurrent = CertFindCertificateInStore(    m_hStore, 
                                                    X509_ASN_ENCODING | PKCS_7_ASN_ENCODING, 
                                                    0, 
                                                    CERT_FIND_ISSUER_ATTR, 
                                                    &certRDN, 
                                                    NULL)
            while(pCurrent != NULL)
            {
                BOOL bRet = FALSE
                byte bUsage

             
                bRet = CertGetIntendedKeyUsage(X509_ASN_ENCODING | PKCS_7_ASN_ENCODING, pCurrent->pCertInfo, &bUsage, 1)
               if(bRet)
               {
              //check cert contains private key
                if((bUsage & CERT_DIGITAL_SIGNATURE_KEY_USAGE) && (bUsage & CERT_NON_REPUDIATION_KEY_USAGE))
                {
         
                    bRet = CryptFindCertificateKeyProvInfo(pCurrent,0,NULL)

                }
                if(bRet)
                {
                    m_pCertContext = pCurrent
                    pCurrent = NULL

                    //the code of pin verification should be here,but I can't figure out what I should written.



                    break
                }

                pCurrent = CertFindCertificateInStore(    m_hStore, 
                                                    X509_ASN_ENCODING | PKCS_7_ASN_ENCODING, 
                                                    0, 
                                                    CERT_FIND_ISSUER_ATTR, 
                                                    &certRDN, 
                                                    pCurrent)
            }
            

            delete certRDN.rgRDNAttr        
        }

    //if there's no cert that I want to be found,release the resource 
        if(m_pCertContext == NULL)
        {
            if (m_pCertContext) {
        CertFreeCertificateContext(m_pCertContext)
        m_pCertContext = NULL
            }
    if (m_hStore) {
        CertCloseStore(m_hStore, CERT_CLOSE_STORE_FORCE_FLAG)
        m_hStore = NULL
    }
        }
        }

  
    }
        return 0
}

#2 How do I get the message in below via CryptoAPI?

this is  a XML file,I have to read the data though CryptoAPI and paste them to a XML,I just don't know how to get it


<DigestValue>uBQI2f/2CMbtPbVLni0jL+J1psE=</DigestValue>

<SignatureValue>PVfM1YCAU701rshiHuALV6LiLuQKQTPidejsUKyMu4ys3dQhO1a36mAZrjnEN0ZIYcRn7VFTWsjDr8imCGjE09GHnsJY0QtqByjUxBpIaxu95MBiqNy4geFy/PKVFQ19yAtKwNd1jXkvjpN7e4eQ0JhUyfc9rA69KIXonvsF2hE=</SignatureValue>

<X509IssuerName>CN=NETCA Individual ClassA CA, OU=Individual ClassA CA, O=NETCA Certificate Authority, C=CA</X509IssuerName><X509SerialNumber>81795886028495042323800393625097362204</X509SerialNumber></X509IssuerSerial><X509Certificate>MIIEBjCCAu6gAwIBAgIQPYlQiyH4Ks50d1Pg0NZbHDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJDTjEkMCIGA1UEChMbTkVUQ0EgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MR0wGwYDVQQLExRJbmRpdmlkdWFsIENsYXNzQSBDQTEjMCEGA1UEAxMaTkVUQ0EgSW5kaXZpZHVhbCBDbGFzc0EgQ0EwHhcNMTIwNDE4MTYwMDAwWhcNMTMwNDE5MTU1OTU5WjBzMQswCQYDVQQGEwJDTjESMBAGA1UECBMJR3Vhbmdkb25nMQ0wCwYDVQQHHgRef13eMSUwIwYDVQQDHhxOKk66bUuL1QAyADAAMQAxADAANAAyADIAMAAxMRowGAYJKoZIhvcNAQkBFgt6c0BjbmNhLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1DO/NjAy1++niPTgcVcR3WwQ5z0uiq0qkg/g1mwhXDWZ7V5cAtrGsQVl82SYXBIxaVMPEXPI2ess8rYY7w7KJD/WFMpdRHmK57ZkDsqJbh55D0ylMBPovwJwfmJ6mJwu9+9oU13zlKKetL3eVAIomp3i37YVPWWpRbWTU2GcnG0CAwEAAaOCARQwggEQMB8GA1UdIwQYMBaAFLFHZEQZX2XMQLsGS+l5BOAe7LVOMB0GA1UdDgQWBBShjFOEYwPh3wcsixILjbcCat+4XjBXBgNVHSAEUDBOMEwGCisGAQQBgZJIAQowPjA8BggrBgEFBQcCARYwaHR0cDovL3d3dy5jbmNhLm5ldC9jcy9rbm93bGVkZ2Uvd2hpdGVwYXBlci9jcHMvMBYGA1UdEQQPMA2BC3pzQGNuY2EubmV0MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgbAMD8GA1UdHwQ4MDYwNKAyoDCGLmh0dHA6Ly9jbGFzc2FjYTEuY25jYS5uZXQvY3JsL0luZGl2aWR1YWxDQS5jcmwwDQYJKoZIhvcNAQEFBQADggEBAAdTQ0s+EYNLchwSoAb5MvGGFWh24XuQGLJLJ+81F3ww11Ah31GSRqJVoXzhozH9GPym0M77LjUiasWCN47tOuhTN3aVGZfGq2daMq2+j+p6LOya/mbq7w3SdhGa1vTrTjkxXNCRnFHDsLR1ujv40WrQM7HfBJ9TOckDSzGbDXSog14mbGTWJaP+FwDb/4YEH7W4Wy2vcPG5/gbWYWwujvSTDBtK9QXhM48Car2oExnmYAbxiu81z4CPPB0LB/GyxtzsYbB4YItFWTY4E8jcQb+VDRbYruX5k1ndk4zLAu45bqrhInAknr9tlMu01VofDNexz0xqmScEkWqdtLhMDow=</X509Certificate></



any idea?

thanks

Regards

Ken





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160201/ee31a590/attachment-0001.html>

From tony.reix at atos.net  Mon Feb  1 18:07:29 2016
From: tony.reix at atos.net (REIX, Tony)
Date: Mon, 1 Feb 2016 18:07:29 +0000
Subject: [openssl-users] config no-symlinks option generates an issue on AIX
 for version 1.0.2f (and 1.0.1r)
In-Reply-To: <B37989F2852398498001550C29155BE5247183@FRCRPVV9EX3MSX.ww931.my-it-solutions.net>
References: <B37989F2852398498001550C29155BE5247183@FRCRPVV9EX3MSX.ww931.my-it-solutions.net>
Message-ID: <B37989F2852398498001550C29155BE52471DE@FRCRPVV9EX3MSX.ww931.my-it-solutions.net>

Hi,

I'm trying to build last versions of OpenSSL on AIX 6.1, as RPMs with .spec files.

With versions 1.0.1p and 1.0.2d , on same machine, my .spec file works perfectly.

Now, with versions 1.0.1r and 1.0.2f, my .spec file (changing 1.0.2d to 1.0.2f) breaks as:
make[2]: Entering directory '/home/reixt/OPENSSL/openssl-1.0.2f/crypto/objects'
cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -O -DB_ENDIAN -qmaxmem=16384   -c -o obj_dat.o obj_dat.c
"obj_dat.h", line 2435.30: 1506-045 (S) Undeclared identifier NID_dhpublicnumber.

However, on Ubuntu/x86_64, building 1.0.2f works perfectly well.

Experimenting with the options of ./config in OpenSSL directory (without the .spec file) for 1.0.2f, it appears that the no-symlinks option is the root cause:

This works perfectly:
tar zxf openssl-1.0.2f.tar.gz
cd openssl-1.0.2f
export OBJECT_MODE=64
./config \
    --prefix=%{_prefix} \
    --openssldir=%{openssldir64}
make depend
make build_libs
make

Though this breaks as described above when compiling  obj_dat.c :
tar zxf openssl-1.0.2f.tar.gz
cd openssl-1.0.2f
export OBJECT_MODE=64
./config \
    no-symlinks \
    --prefix=%{_prefix} \
    --openssldir=%{openssldir64}
make depend
make build_libs
make


Now, using same commands as above with 1.0.2d version, still with no-symlinks, that works perfectly.


Does anyone have encountered this issue with no-symlink and versions 1.0.1r or 1.0.2f ?

Any idea about the root cause ?

Thanks/Regards,

Cordialement,

Tony Reix

Bull - ATOS
IBM Coop Architect & Technical Leader
Office : +33 (0) 4 76 29 72 67
1 rue de Provence - 38432 ?chirolles - France
www.atos.net<https://mail.ad.bull.net/owa/redir.aspx?C=PvphmPvCZkGrAgHVnWGsdMcDKgzl_dEIsM6rX0g4u4v8V81YffzBGkWrtQeAXNovd3ttkJL8JIc.&URL=http%3a%2f%2fwww.atos.net%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160201/abc1b68f/attachment.html>

From BYan at visa.com  Mon Feb  1 19:17:30 2016
From: BYan at visa.com (Yan, Bob)
Date: Mon, 1 Feb 2016 19:17:30 +0000
Subject: [openssl-users] Certificate verification failure
In-Reply-To: <56AF1F7D.6000008@nikhef.nl>
References: <c3ed5b0c1693432aae6148131a1e2c61@SW550EXP003.visa.com>
 <56AF1F7D.6000008@nikhef.nl>
Message-ID: <94c082e49d8a4c21b41cb64f518ccc92@SW550EXP003.visa.com>

Thanks Jan,

When I am using the CApath, I do have the symbolic hash link (with ".0" at the end hash) linked to my ca-root.pem certificate file and ca-intermediate.pem certificate. Any other issues which could cause this issue? 

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jan Just Keijser
Sent: Monday, February 01, 2016 1:04 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Certificate verification failure

Yan, Bob wrote:
>
> Dear Sir/Madam,
>
> I have an application which acting as SSL server. When the application 
> loads the root and intermediate CA files from a CA path, the handshake 
> between my application and openssl client was failed at the point when 
> my application was authenticating the client's certificate. But when I 
> bound the root CA and intermediate CA into a single pem file and 
> reload it from my application, the handshake is successful. Could 
> anybody help me resolve this issue? Below is the sample of my 
> application code for loading the CA certificates:
>
> if (SSL_CTX_load_verify_locations(ctx, caFile, caPath) != 1) {
>
> exit;
>
> }
>
> if (SSL_CTX_set_default_verify_paths(ctx) != 1) {
>
> exit;
>
> }
>
> if (SSL_CTX_use_certificate_chain_file(ctx, certFile) != 1) {
>
> exit;
>
> }
>
> if (SSL_CTX_use_PrivateKey_file(ctx, keyFile, SSL_FILETYPE_PEM) != 1) 
> {
>
> exit;
>
> }
>
> SSL_CTX_set_verify_depth(ctx, chainDepths);
>
> SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | 
> SSL_VERIFY_FAIL_IF_NO_PEER_CERT, callback);
>
> SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2);
>

when you're using CA path , what are the contents of this CA path directory? In it you should have placed the root and intermediate CA files using special names. Instead of using "ca.pem" you need to have a file "<hash>.0" , where <hash> is the output of "openssl x509 -hash -noout -in ca.pem" (and similarly for the intermediate CA file).

JJK

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From martin.vegter9 at gmail.com  Mon Feb  1 21:21:49 2016
From: martin.vegter9 at gmail.com (Martin Vegter)
Date: Mon, 1 Feb 2016 22:21:49 +0100
Subject: [openssl-users] error when linking with OpenSSL library dynamically
Message-ID: <CANE3EASqBPdYdeFh6NY2Z7JL28oVVSucBs1X+jQXn_S92ZjKSA@mail.gmail.com>

Hello,

I have a C program, which is using AES routines from the OpenSSL
library. I have the necessary library installed (libssl-dev
1.0.1e-2+deb7u19):

  $ ls /usr/lib/x86_64-linux-gnu/libcrypto.*
  /usr/lib/x86_64-linux-gnu/libcrypto.a
  /usr/lib/x86_64-linux-gnu/libcrypto.so
  /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0

I can compile my program statically:

  gcc -s -o aes aes.c /usr/lib/x86_64-linux-gnu/libcrypto.a

but when i try to compile it dynamically, I get following error:

  $ gcc -s -o aes aes.c -lcrypto
  /tmp/ccofFr4N.o: In function `encrypt':
  aes.c:(.text+0x9f): undefined reference to `aesni_set_encrypt_key'
  aes.c:(.text+0xd9): undefined reference to `aesni_cbc_encrypt'
  aes.c:(.text+0x1a0): undefined reference to `aesni_cbc_encrypt'
  /tmp/ccofFr4N.o: In function `decrypt':
  aes.c:(.text+0x2d4): undefined reference to `aesni_set_decrypt_key'
  aes.c:(.text+0x31e): undefined reference to `aesni_cbc_encrypt'
  collect2: error: ld returned 1 exit status

I noticed the following:

  $ grep aesni_set_encrypt_key /usr/lib/x86_64-linux-gnu/libcrypto.*
  Binary file /usr/lib/x86_64-linux-gnu/libcrypto.a matches

Is it possible, that libcrypto.so does not contain the functions,
while libcrypto.a does ?

could somebody please advise how I can compile my program dynamically ?

From security.veteran at gmail.com  Mon Feb  1 21:35:19 2016
From: security.veteran at gmail.com (security veteran)
Date: Mon, 1 Feb 2016 13:35:19 -0800
Subject: [openssl-users] How to enable FIPS mode system-wide for the
 FIPS capable OpenSSL?
In-Reply-To: <56AB77A4.6020308@openssl.com>
References: <CAC5owtEf8GXwQ4Vw5egcTT9uuTHsGwFtsX8i38HAuCCtzox=+g@mail.gmail.com>
 <56AB77A4.6020308@openssl.com>
Message-ID: <CAC5owtGNB21m9RhQ1_7i6Ur=WQ5OLW9i=aXGq2iGXp-mdSjWSw@mail.gmail.com>

Thanks Steve.

I think the way to use OPENSSL_config() and openssl.conf basically still
requires each application to explicitly invoke OPENSSL_config() API in
order to truly enable the FIPS mode, is that correct?

If that's the case, then basically there's no way to really globally enable
the FIPS mode in the OpenSSL library in a system-wide way, so that all the
applications which use OpenSSL (libcrypto to be more specific) will be
running under FIPS mode by default (i.e. without the needs of modification
tomake them invoke either OPENSSL_config() or FIPS_mode_set() API). Is that
correct?

The reason I ask was mainly because I am evaluating how I should modify my
server platform and applications in order to adapt FIPS capable OpenSSL
library into the platform.

Thanks and I truly appreciate your answers and helps.

On Fri, Jan 29, 2016 at 6:31 AM, Steve Marquess <marquess at openssl.com>
wrote:

> On 01/28/2016 07:11 PM, security veteran wrote:
> > Hi All:
> >
> > Is there a way to enable FIPS mode globally, instead of having to
> > explicitly invoke the FIPS_mode_set() API from each application, for
> > enabling the FIPS mode?
> >
> > ...
>
> Kinda-sorta, via OPENSSL_config() and openssl.conf. See the FIPS user
> guide, https://openssl.org/docs/fips/UserGuide-2.0.pdf, section 5.2.
>
> -Steve M.
>
> --
> Steve Marquess
> OpenSSL Software Foundation
> 1829 Mount Ephraim Road
> Adamstown, MD  21710
> USA
> +1 877 673 6775 s/b
> +1 301 874 2571 direct
> marquess at openssl.com
> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160201/041bf762/attachment.html>

From security.veteran at gmail.com  Mon Feb  1 21:37:40 2016
From: security.veteran at gmail.com (security veteran)
Date: Mon, 1 Feb 2016 13:37:40 -0800
Subject: [openssl-users] OpenSSL FIPS: OPENSSL_config() and self-tests
Message-ID: <CAC5owtGzNXdRcBVSQwWbzeiq_eYD2o=H-DSBNOh92T3DdvMe1w@mail.gmail.com>

Hi All:

Based on the OpenSSL FIPS user guide, the FIPS_mode_set API from the
OpenSSL FIPS modules run a the necessary self-tests.

I was wondering does the OPENSSL_config() API also run the self-tests?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160201/827dc97d/attachment-0001.html>

From openssl-users at dukhovni.org  Mon Feb  1 21:45:35 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 1 Feb 2016 21:45:35 +0000
Subject: [openssl-users] error when linking with OpenSSL library
 dynamically
In-Reply-To: <CANE3EASqBPdYdeFh6NY2Z7JL28oVVSucBs1X+jQXn_S92ZjKSA@mail.gmail.com>
References: <CANE3EASqBPdYdeFh6NY2Z7JL28oVVSucBs1X+jQXn_S92ZjKSA@mail.gmail.com>
Message-ID: <20160201214534.GB4987@mournblade.imrryr.org>

On Mon, Feb 01, 2016 at 10:21:49PM +0100, Martin Vegter wrote:

> I have a C program, which is using AES routines from the OpenSSL
> library. I have the necessary library installed (libssl-dev
> 1.0.1e-2+deb7u19):
> 
>   $ ls /usr/lib/x86_64-linux-gnu/libcrypto.*
>   /usr/lib/x86_64-linux-gnu/libcrypto.a
>   /usr/lib/x86_64-linux-gnu/libcrypto.so
>   /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> 
> I can compile my program statically:
> 
>   gcc -s -o aes aes.c /usr/lib/x86_64-linux-gnu/libcrypto.a
> 
> but when i try to compile it dynamically, I get following error:
> 
>   $ gcc -s -o aes aes.c -lcrypto
>   /tmp/ccofFr4N.o: In function `encrypt':
>   aes.c:(.text+0x9f): undefined reference to `aesni_set_encrypt_key'
>   aes.c:(.text+0xd9): undefined reference to `aesni_cbc_encrypt'
>   aes.c:(.text+0x1a0): undefined reference to `aesni_cbc_encrypt'
>   /tmp/ccofFr4N.o: In function `decrypt':
>   aes.c:(.text+0x2d4): undefined reference to `aesni_set_decrypt_key'
>   aes.c:(.text+0x31e): undefined reference to `aesni_cbc_encrypt'
>   collect2: error: ld returned 1 exit status

You're using internal function names that are not exported by the
libcrypto shared library on Debian systems.  Use the EVP interface.

In future versions of OpenSSL constrained visibility of shared
library symbols will be extended to more platforms (than just Debian
where the export list was created by the Debian package maintainer).

The EVP interface is faster on many systems (supports AES-NI on
suitably capable Intel CPUs) and also safer (avoids timing
side-channels).

-- 
	Viktor.

From jb-openssl at wisemo.com  Tue Feb  2 00:05:02 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 2 Feb 2016 01:05:02 +0100
Subject: [openssl-users] error when linking with OpenSSL library
 dynamically
In-Reply-To: <20160201214534.GB4987@mournblade.imrryr.org>
References: <CANE3EASqBPdYdeFh6NY2Z7JL28oVVSucBs1X+jQXn_S92ZjKSA@mail.gmail.com>
 <20160201214534.GB4987@mournblade.imrryr.org>
Message-ID: <56AFF2AE.6050809@wisemo.com>

On 01/02/2016 22:45, Viktor Dukhovni wrote:
> On Mon, Feb 01, 2016 at 10:21:49PM +0100, Martin Vegter wrote:
>
>> I have a C program, which is using AES routines from the OpenSSL
>> library. I have the necessary library installed (libssl-dev
>> 1.0.1e-2+deb7u19):
>>
>>    $ ls /usr/lib/x86_64-linux-gnu/libcrypto.*
>>    /usr/lib/x86_64-linux-gnu/libcrypto.a
>>    /usr/lib/x86_64-linux-gnu/libcrypto.so
>>    /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
>>
>> I can compile my program statically:
>>
>>    gcc -s -o aes aes.c /usr/lib/x86_64-linux-gnu/libcrypto.a
>>
>> but when i try to compile it dynamically, I get following error:
>>
>>    $ gcc -s -o aes aes.c -lcrypto
>>    /tmp/ccofFr4N.o: In function `encrypt':
>>    aes.c:(.text+0x9f): undefined reference to `aesni_set_encrypt_key'
>>    aes.c:(.text+0xd9): undefined reference to `aesni_cbc_encrypt'
>>    aes.c:(.text+0x1a0): undefined reference to `aesni_cbc_encrypt'
>>    /tmp/ccofFr4N.o: In function `decrypt':
>>    aes.c:(.text+0x2d4): undefined reference to `aesni_set_decrypt_key'
>>    aes.c:(.text+0x31e): undefined reference to `aesni_cbc_encrypt'
>>    collect2: error: ld returned 1 exit status
> You're using internal function names that are not exported by the
> libcrypto shared library on Debian systems.  Use the EVP interface.
>
> In future versions of OpenSSL constrained visibility of shared
> library symbols will be extended to more platforms (than just Debian
> where the export list was created by the Debian package maintainer).
>
> The EVP interface is faster on many systems (supports AES-NI on
> suitably capable Intel CPUs) and also safer (avoids timing
> side-channels).
The OP is already invoking the AES-NI functions (those are in fact
the ones failing).

As for the side channel protection: Is this really restricted to
the EVP interface (which would be a security bug in 1.0.x), or is
it simply that the EVP interface does not expose certain lower
level APIs that can be accidentally invoked without side channel
protection options?

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160202/fa0c8550/attachment.html>

From jb-openssl at wisemo.com  Tue Feb  2 07:52:31 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 2 Feb 2016 08:52:31 +0100
Subject: [openssl-users] Strange problem with 1.0.2f SSL_shutdown in
	multithreaded server
Message-ID: <56B0603F.9060207@wisemo.com>

I am trying to upgrade an existing 3rd party multithreaded server
from OpenSSL 1.0.2c to 1.0.2f .  However when I do so, it starts
mishandling the close_notify "alert".

1.0.2f seems to send the close_notify alert unencrypted followed
by an encrypted decrypt_failed alert, where 1.0.2c correctly
sends just an encrypted close_notify alert.

I am unsure if this exposed a bug in the daemon or in OpenSSL
itself.

P.S. The "block cipher pad is wrong:s3_pkt.c:452" error message
really means "unencrypted parts of encrypted record are invalid
for encryption algorithm" (ssl3_enc->enc() returned 0 because an
AES-CBC encrypted block cannot be be 2 bytes long).

Notes on the daemon:

- It is the same binary in both tests, compiled against 1.0.2a,
  but loading either the OpenSSL 1.0.2c or 1.0.2f shared object.

- It is multithreaded and does set up a thread id callback and
  a locking callback (but not a dyn locking callback).  The
  thread id callback uses the 0.9.8 compatible thread callback
  API, and I have checked that the thread_id is actually an
  unsigned long value.

- Tests below were done with TLS 1.0 to keep the log shorter,
  but the same error occurs with TLS 1.2.

- The error does not occur against 1.0.2 s_server, which I
  suppose is single_threaded.

- OS is Linux x86_64.

Output from 1.0.2f s_client against 1.0.2f daemon:

read from 0xbd4780 [0xbda813] (5 bytes => 5 (0x5))
0000 - 15 03 01 00 02 .....
<<< ??? [length 0005]
     15 03 01 00 02
read from 0xbd4780 [0xbda818] (2 bytes => 2 (0x2))
0000 - 01                                                .
0002 - <SPACES/NULS>
 >>> ??? [length 0005]
     15 03 01 00 20
write to 0xbd4780 [0xbded63] (37 bytes => 37 (0x25))
0000 - 15 03 01 00 20 dd ce 72-24 f3 d6 2f e1 12 72 e3 .... ..r$../..r.
0010 - 89 53 f0 ef 28 da 7d d3-76 c3 f4 2c a8 af 12 2f .S..(.}.v..,.../
0020 - 0a 01 2e e0 a5 .....
 >>> TLS 1.0 Alert [length 0002], fatal decryption_failed
     02 15
140649912034984:error:1408F081:SSL routines:SSL3_GET_RECORD:block cipher 
pad is wrong:s3_pkt.c:452:
 >>> ??? [length 0005]
     15 03 01 00 20
write to 0xbd4780 [0xbded63] (37 bytes => -1 (0xFFFFFFFFFFFFFFFF))


Output from 1.0.2f s_client against 1.0.2c daemon:

read from 0x10e6780 [0x10ec813] (5 bytes => 0 (0x0))
read:errno=0
 >>> ??? [length 0005]
     15 03 01 00 20
write to 0x10e6780 [0x10f0d63] (37 bytes => 37 (0x25))
0000 - 15 03 01 00 20 db 1d f3-2e 24 a6 ae 93 27 05 67 .... ....$...'.g
0010 - b2 0e 61 5f 11 32 83 32-3e 55 d9 e9 0b c2 39 34 ..a_.2.2>U....94
0020 - f0 46 70 8f 16 .Fp..
 >>> TLS 1.0 Alert [length 0002], warning close_notify
     01 00



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From martin.vegter9 at gmail.com  Tue Feb  2 09:18:34 2016
From: martin.vegter9 at gmail.com (Martin Vegter)
Date: Tue, 2 Feb 2016 10:18:34 +0100
Subject: [openssl-users] error when linking with OpenSSL library
	dynamically
In-Reply-To: <20160201214534.GB4987@mournblade.imrryr.org>
References: <CANE3EASqBPdYdeFh6NY2Z7JL28oVVSucBs1X+jQXn_S92ZjKSA@mail.gmail.com>
 <20160201214534.GB4987@mournblade.imrryr.org>
Message-ID: <CANE3EATXFSBNVc=a2z9t1inFn7KF4T7RKsBD4dwQWSTSBpPS4w@mail.gmail.com>

On 1 February 2016 at 22:45, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
>
> You're using internal function names that are not exported by the
> libcrypto shared library on Debian systems.  Use the EVP interface.
>
> In future versions of OpenSSL constrained visibility of shared
> library symbols will be extended to more platforms (than just Debian
> where the export list was created by the Debian package maintainer).
>
> The EVP interface is faster on many systems (supports AES-NI on
> suitably capable Intel CPUs) and also safer (avoids timing
> side-channels).

thanks Viktor,
but what if (for reasons beyond this discussion) I wish to use the low
level internal aesni_* functions?

Would I have to compile libssl-dev myself ?

It looks to me as if Debian was trying to protect me from myself.
Can't I play with the internal functions ? I don't mind loosing
compatibility on non-AES-NI processors.

From matt at openssl.org  Tue Feb  2 09:40:10 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 2 Feb 2016 09:40:10 +0000
Subject: [openssl-users] error when linking with OpenSSL library
 dynamically
In-Reply-To: <CANE3EATXFSBNVc=a2z9t1inFn7KF4T7RKsBD4dwQWSTSBpPS4w@mail.gmail.com>
References: <CANE3EASqBPdYdeFh6NY2Z7JL28oVVSucBs1X+jQXn_S92ZjKSA@mail.gmail.com>
 <20160201214534.GB4987@mournblade.imrryr.org>
 <CANE3EATXFSBNVc=a2z9t1inFn7KF4T7RKsBD4dwQWSTSBpPS4w@mail.gmail.com>
Message-ID: <56B0797A.2020809@openssl.org>



On 02/02/16 09:18, Martin Vegter wrote:
> On 1 February 2016 at 22:45, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
>>
>> You're using internal function names that are not exported by the
>> libcrypto shared library on Debian systems.  Use the EVP interface.
>>
>> In future versions of OpenSSL constrained visibility of shared
>> library symbols will be extended to more platforms (than just Debian
>> where the export list was created by the Debian package maintainer).
>>
>> The EVP interface is faster on many systems (supports AES-NI on
>> suitably capable Intel CPUs) and also safer (avoids timing
>> side-channels).
> 
> thanks Viktor,
> but what if (for reasons beyond this discussion) I wish to use the low
> level internal aesni_* functions?
> 
> Would I have to compile libssl-dev myself ?

These symbols are in libcrypto not libssl.

> It looks to me as if Debian was trying to protect me from myself.
> Can't I play with the internal functions ? I don't mind loosing
> compatibility on non-AES-NI processors.

Indeed it is. These symbols do not form part of the public API (they are
not in any of the public header files). Therefore they are liable to
change without notice (even, in theory, between letter releases). In the
forthcoming 1.1.0 we do very much the same thing in the main tree that
Debian does now for 1.0.2, i.e. these symbols are not exported at all in
the .so - you would have to start hacking the OpenSSL source to make
them visible again.

You can of course compile up your own libcrypto and access them directly
- but you're really on your own if you decide to do so.

Matt

From matt at openssl.org  Tue Feb  2 10:40:18 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 2 Feb 2016 10:40:18 +0000
Subject: [openssl-users] Strange problem with 1.0.2f SSL_shutdown in
 multithreaded server
In-Reply-To: <56B0603F.9060207@wisemo.com>
References: <56B0603F.9060207@wisemo.com>
Message-ID: <56B08792.20604@openssl.org>



On 02/02/16 07:52, Jakob Bohm wrote:
> I am trying to upgrade an existing 3rd party multithreaded server
> from OpenSSL 1.0.2c to 1.0.2f .  However when I do so, it starts
> mishandling the close_notify "alert".
> 
> 1.0.2f seems to send the close_notify alert unencrypted followed
> by an encrypted decrypt_failed alert, where 1.0.2c correctly
> sends just an encrypted close_notify alert.
> 
> I am unsure if this exposed a bug in the daemon or in OpenSSL
> itself.

I have a theory.

Previous versions of 1.0.2 handled an SSL_shutdown() call while in the
middle of a handshake by ignoring it and returning 1 immediately
(meaning everything shutdown successfully). Clearly everything did not
shutdown successfully so the return value is not correct.

1.0.2f "fixed" this to attempt to more appropriately shutdown the
connection. It now attempts to send a close_notify alert immediately
(and will return 0 - meaning more work to do), it will then fail with a
-1 return on a second call to SSL_shutdown (meaning we failed to
complete a bi-directional shutdown). The reason is that completing a
full bi-directional shutdown while mid-handshake is problematic (e.g. if
the peer has sent a CCS before it receives our close_notify).

My theory as to what is happening in this case is that SSL_shutdown is
being called mid-handshake. Could that be the case do you think? It
doesn't entirely match with the description you gave (i.e. 1.0.2c would
not send an encrypted close_notify...it wouldn't send anything in this
scenario)...but its the only change I can think of that might have a
bearing on this.

If so then I could see a situation where the server has not yet
processed a CCS from the client and SSL_shutdown is called. It therefore
sends its close_notify in the clear. In the meantime the client has sent
its CCS before processing the close_notify. The client then expects the
next message from the server to be encrypted...which it obviously isn't.

It's not entirely clear to me what the correct behaviour is in that
situation, but it is certainly unexpected and a change from what
happened before.

It looks to me that trying to send a close_notify mid-handshake was
probably a bad idea. Perhaps a better fix is just to have SSL_shutdown()
return -1 and do nothing if called mid-handshake.

I've attached a 1.0.2 patch that does this. Would you be able to try it,
and see if that corrects your problem?

Thanks

Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shutdown-1.0.2.patch
Type: text/x-patch
Size: 3888 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160202/89ed97fd/attachment-0001.bin>

From jb-openssl at wisemo.com  Tue Feb  2 11:24:01 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 2 Feb 2016 12:24:01 +0100
Subject: [openssl-users] Strange problem with 1.0.2f SSL_shutdown in
 multithreaded server
In-Reply-To: <56B08792.20604@openssl.org>
References: <56B0603F.9060207@wisemo.com> <56B08792.20604@openssl.org>
Message-ID: <56B091D1.8010008@wisemo.com>

On 02/02/2016 11:40, Matt Caswell wrote:
> On 02/02/16 07:52, Jakob Bohm wrote:
>> I am trying to upgrade an existing 3rd party multithreaded server
>> from OpenSSL 1.0.2c to 1.0.2f .  However when I do so, it starts
>> mishandling the close_notify "alert".
>>
>> 1.0.2f seems to send the close_notify alert unencrypted followed
>> by an encrypted decrypt_failed alert, where 1.0.2c correctly
>> sends just an encrypted close_notify alert.
>>
>> I am unsure if this exposed a bug in the daemon or in OpenSSL
>> itself.
> I have a theory.
>
> Previous versions of 1.0.2 handled an SSL_shutdown() call while in the
> middle of a handshake by ignoring it and returning 1 immediately
> (meaning everything shutdown successfully). Clearly everything did not
> shutdown successfully so the return value is not correct.
No, actual application data (just a few bytes) was sent in each
direction.

Specifically, some bytes were sent client to server, then a reply
was sent server to client and the connection was closed.

Also, the s_client output showed a completed handshake, with
ChangeCipherSpec in both directions and dump of certificate
chain before the first application data was sent (client to
server, then server to client).

The s_client command line was

cat data | openssl s_client -connect xx.xx.xx.xx:xxxx -msg -tls1 
-ign_eof -debug

However I cannot rule out that the changes to either SSL_shutdown()
or the rearranged error checking code triggered the issue.



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From matt at openssl.org  Tue Feb  2 11:34:10 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 2 Feb 2016 11:34:10 +0000
Subject: [openssl-users] Strange problem with 1.0.2f SSL_shutdown in
 multithreaded server
In-Reply-To: <56B091D1.8010008@wisemo.com>
References: <56B0603F.9060207@wisemo.com> <56B08792.20604@openssl.org>
 <56B091D1.8010008@wisemo.com>
Message-ID: <56B09432.40105@openssl.org>



On 02/02/16 11:24, Jakob Bohm wrote:
> On 02/02/2016 11:40, Matt Caswell wrote:
>> On 02/02/16 07:52, Jakob Bohm wrote:
>>> I am trying to upgrade an existing 3rd party multithreaded server
>>> from OpenSSL 1.0.2c to 1.0.2f .  However when I do so, it starts
>>> mishandling the close_notify "alert".
>>>
>>> 1.0.2f seems to send the close_notify alert unencrypted followed
>>> by an encrypted decrypt_failed alert, where 1.0.2c correctly
>>> sends just an encrypted close_notify alert.
>>>
>>> I am unsure if this exposed a bug in the daemon or in OpenSSL
>>> itself.
>> I have a theory.
>>
>> Previous versions of 1.0.2 handled an SSL_shutdown() call while in the
>> middle of a handshake by ignoring it and returning 1 immediately
>> (meaning everything shutdown successfully). Clearly everything did not
>> shutdown successfully so the return value is not correct.
> No, actual application data (just a few bytes) was sent in each
> direction.
> 
> Specifically, some bytes were sent client to server, then a reply
> was sent server to client and the connection was closed.
> 
> Also, the s_client output showed a completed handshake, with
> ChangeCipherSpec in both directions and dump of certificate
> chain before the first application data was sent (client to
> server, then server to client).
> 
> The s_client command line was
> 
> cat data | openssl s_client -connect xx.xx.xx.xx:xxxx -msg -tls1
> -ign_eof -debug
> 
> However I cannot rule out that the changes to either SSL_shutdown()
> or the rearranged error checking code triggered the issue.

Hmmm. Perhaps try reverting the SSL_shutdown() change to rule that out
as related in some way? Patch attached to revert that change back to the
previous implementation.

Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: revert-shutdown.patch
Type: text/x-patch
Size: 4187 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160202/18e8002a/attachment.bin>

From mcepl at cepl.eu  Tue Feb  2 17:04:46 2016
From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl)
Date: Tue, 02 Feb 2016 18:04:46 +0100
Subject: [openssl-users] Help with M2Crypto on Windows?
Message-ID: <slrnnb1ode.u0v.mcepl@mitmanek.ceplovi.cz>

Hi,

I am the crazy guy who decided to continue in maintenance of 
M2Crypto when everybody else wisely (?) left the ship.  
Unfortunately (for M2Crypto), I am a Linux guy, so while I have 
finally gave up and installed Windows X in VM, I am really lost 
in the Windows APIs and we have currently M2Crypto released 
which doesn't even build on Windows.

The official upstream repo for M2Crypto is now on 
https://gitlab.com/m2crypto/m2crypto/ and I have this merge 
request https://gitlab.com/m2crypto/m2crypto/merge_requests/26 
where I am trying to make things working.

I have managed to make CI on Appveyor working for me, but still 
even the build fails (not mentioning I haven't run the tests on 
Windows ever).

Is there anybody here who would be willing and able to help with 
fixing problems of M2Crypto on Windows?

Also, if anybody else is willing to help with issues we have, 
I would hugely appreciate it and you would increase your karma 
on project which is suprisingly popular and widly used.  Aside 
from Windows people I am looking for somebody who would be 
willing to help with maintenance on Macs. It is at least Unix so 
we have POSIX APIs there, but still intricacies of brew and 
weird Apple policies on providing non-working header files for 
non-existent libraries (at least that's my feeling from their 
stance on OpenSSL) baffles me.

Thank you for any help,

Mat?j

-- 
https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
Wise walks steady step, only fools around them dance contemporary
dances.
  -- Franz Kafka


From pdrotter at us.ibm.com  Tue Feb  2 17:45:24 2016
From: pdrotter at us.ibm.com (Neptune)
Date: Tue, 2 Feb 2016 10:45:24 -0700 (MST)
Subject: [openssl-users] FIPS Static Library linked into Win32 Dll builds
 but fails self test
Message-ID: <1454435124826-63011.post@n7.nabble.com>

FIPS Object Module 2.0.9 
OpenSSL 1.0.1l 
Platform: Win32 

I am attempting to statically link a FIPS-capable library into a .dll. The
.dll is built without errors and by viewing the .dll in a hex editor I can
see the correct HMAC is embedded within and correct, but the self test is
failing. 

Originally I had built the FIPS-capable library as a dynamic library, but
during testing we experienced address clashes since the libeay32.dll
requires a fixed address and there is no way to guarantee an address we
choose will always be vacant, so static linking is a requirement. 

Here is my process... 
1. Build the .dll project in Visual Studio 2005 
2. Run a custom batch file which links all of the .obj files including the
fips_premain.obj 

Here is my batch file: 
<<<< 
@ECHO OFF 
SET FIPS_PATH=C:\SWTOOLS\OpenSSL_FIPS\openssl-fips-2.0.9 
SET INC_D=C:\SWTOOLS\OpenSSL_FIPS\openssl-1.0.1l\inc32 
SET INCL_D=C:\SWTOOLS\OpenSSL_FIPS\openssl-1.0.1l\tmp32 

SET INC=-I %INC_D% -I %INCL_D% 
SET FIPS_CC=cl 
SET CFLAG=/MD /Ox -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -Gy -nologo
-DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DUNICODE
-D_UNICODE -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-IC:\SWTOOLS\OpenSSL_FIPS\openssl-fips-2.0.9\include -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM
-DGHASH_ASM -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5
-DOPENSSL_FIPS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_DYNAMIC_ENGINE 
SET LIB_CFLAG= /Zl /Zi 
SET SHLIB_CFLAG= 
SET SHLIB_CFLAGS=%INC% %CFLAG% %LIB_CFLAG% %SHLIB_CFLAG% 
SET
FIPS_CC_ARGS=/FoC:\SWTOOLS\OpenSSL_FIPS\Static_Libraries\luaCrypto\fips_premain.obj
%SHLIB_CFLAGS% -c 

SET FIPS_LINK=link 
SET
PREMAIN_DSO_EXE=C:\SWTOOLS\OpenSSL_FIPS\openssl-1.0.1l\out32\fips_premain_dso.exe 
SET
FIPS_TARGET=C:\SWTOOLS\OpenSSL_FIPS\Static_Libraries\luaCrypto\luaCrypto.dll 
SET FIPS_SHA1_EXE=%FIPS_PATH%\bin\fips_standalone_sha1.exe 
SET FIPS_SIG=perl C:\SWTOOLS\OpenSSL_FIPS\openssl-fips-2.0.9\util\msincore 
SET FIPSLIB_D=%FIPS_PATH%\lib 

@ECHO ON 
perl %FIPS_PATH%\bin\fipslink.pl /MACHINE:X86 /ERRORREPORT:PROMPT /DEBUG
/DLL /FIXED /NOLOGO /MAPINFO:EXPORTS /SUBSYSTEM:WINDOWS
/OUT:"C:\SWTOOLS\OpenSSL_FIPS\Static_Libraries\luaCrypto\luaCrypto.dll"
/LIBPATH:\"C:\SWTOOLS\OpenSSL_FIPS\Static_Libraries\luaCrypto\lib\"
/LIBPATH:\"C:\SWTOOLS\OpenSSL_FIPS\openssl-fips-2.0.9\lib\"
/LIBPATH:\"C:\SWTOOLS\OpenSSL_FIPS\openssl-1.0.1l\out32\" libeayfips32.lib
ssleay32.lib libeaycompat32.lib ws2_32.lib gdi32.lib advapi32.lib
crypt32.lib user32.lib kernel32.lib fiblua.lib rijndael.lib winspool.lib
comdlg32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib
odbccp32.lib CryptoHelper.obj luaCrypto.obj SHA1Ex.obj fips_premain.obj 
@ECHO OFF 
>>>> 

So, this process generates a .dll which can be loaded, but when
FIPS_set_mode(1); is called, the self-test fails with bad fingerprint. 

I know the HMAC is in there, as verified in hex editor, so I'm thinking this
must have something to do with the location of the HMAC, but how can I have
any control over where it is place? 

Thanks for any help! 

Paul 



--
View this message in context: http://openssl.6102.n7.nabble.com/FIPS-Static-Library-linked-into-Win32-Dll-builds-but-fails-self-test-tp63011.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From steve at openssl.org  Tue Feb  2 19:03:07 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 2 Feb 2016 19:03:07 +0000
Subject: [openssl-users] FIPS Static Library linked into Win32 Dll
 builds but fails self test
In-Reply-To: <1454435124826-63011.post@n7.nabble.com>
References: <1454435124826-63011.post@n7.nabble.com>
Message-ID: <20160202190307.GA17500@openssl.org>

On Tue, Feb 02, 2016, Neptune wrote:

> FIPS Object Module 2.0.9 
> OpenSSL 1.0.1l 
> Platform: Win32 
> 
> I am attempting to statically link a FIPS-capable library into a .dll. The
> .dll is built without errors and by viewing the .dll in a hex editor I can
> see the correct HMAC is embedded within and correct, but the self test is
> failing. 
> 
> Originally I had built the FIPS-capable library as a dynamic library, but
> during testing we experienced address clashes since the libeay32.dll
> requires a fixed address and there is no way to guarantee an address we
> choose will always be vacant, so static linking is a requirement. 
> 

You'll hit the same issue if you link the static version of OpenSSL into a
DLL. The only way to escape it is to link the static version of OpenSSL into
the executable or use Win64 which doesn't have this problem.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From pdrotter at us.ibm.com  Tue Feb  2 18:54:41 2016
From: pdrotter at us.ibm.com (Neptune)
Date: Tue, 2 Feb 2016 11:54:41 -0700 (MST)
Subject: [openssl-users] FIPS Static Library linked into Win32 Dll
 builds but fails self test
In-Reply-To: <20160202190307.GA17500@openssl.org>
References: <1454435124826-63011.post@n7.nabble.com>
 <20160202190307.GA17500@openssl.org>
Message-ID: <1454439281711-63018.post@n7.nabble.com>

Thank you...that would explain why I'm suddenly having success when I give
our .dll a fixed address. Unfortunately, this is something we are trying to
avoid. Even more unfortunate is we are stuck with Win32 (at least for
another year) and linking to the executable is not a solution because the
dll must have the library since its functionality is called from more than
one executable and from a LUA interpreter and must be independent of other
processes.

It looks like fixed addressing is the only way we can accomplish this. At
the very least I've got a workable solution as long as I choose an address
that is very unlikely to be used.

Is there a strategy that the folks here employ to avoid address clashes?

Thanks,
Paul



--
View this message in context: http://openssl.6102.n7.nabble.com/FIPS-Static-Library-linked-into-Win32-Dll-builds-but-fails-self-test-tp63011p63018.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From security.veteran at gmail.com  Wed Feb  3 01:02:55 2016
From: security.veteran at gmail.com (security veteran)
Date: Tue, 2 Feb 2016 17:02:55 -0800
Subject: [openssl-users] OpenSSL FIPS: OPENSSL_config() and self-tests
In-Reply-To: <CAC5owtGzNXdRcBVSQwWbzeiq_eYD2o=H-DSBNOh92T3DdvMe1w@mail.gmail.com>
References: <CAC5owtGzNXdRcBVSQwWbzeiq_eYD2o=H-DSBNOh92T3DdvMe1w@mail.gmail.com>
Message-ID: <CAC5owtG1k9kJSXwbWcSBHk4SK88GG_icEx3yqf0TDZENObqrkQ@mail.gmail.com>

Hi All:

Based on the OpenSSL FIPS user guide, the FIPS_mode_set API from the
OpenSSL FIPS modules run a the necessary self-tests.

I was wondering does the OPENSSL_config() API also run the self-tests?

Your suggestions are greatly appreciated.

Thanks.

On Mon, Feb 1, 2016 at 1:37 PM, security veteran <security.veteran at gmail.com
> wrote:

> Hi All:
>
> Based on the OpenSSL FIPS user guide, the FIPS_mode_set API from the
> OpenSSL FIPS modules run a the necessary self-tests.
>
> I was wondering does the OPENSSL_config() API also run the self-tests?
>
> Thanks.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160202/21c00438/attachment-0001.html>

From security.veteran at gmail.com  Wed Feb  3 01:04:30 2016
From: security.veteran at gmail.com (security veteran)
Date: Tue, 2 Feb 2016 17:04:30 -0800
Subject: [openssl-users] How to enable FIPS mode system-wide for the
 FIPS capable OpenSSL?
In-Reply-To: <CAC5owtGNB21m9RhQ1_7i6Ur=WQ5OLW9i=aXGq2iGXp-mdSjWSw@mail.gmail.com>
References: <CAC5owtEf8GXwQ4Vw5egcTT9uuTHsGwFtsX8i38HAuCCtzox=+g@mail.gmail.com>
 <56AB77A4.6020308@openssl.com>
 <CAC5owtGNB21m9RhQ1_7i6Ur=WQ5OLW9i=aXGq2iGXp-mdSjWSw@mail.gmail.com>
Message-ID: <CAC5owtH2n8Vtr1HcUHf0aGQJjrYtyUwKzyaN9Rtyr4Z=_G-3CQ@mail.gmail.com>

Thanks Steve.

I think the way to use OPENSSL_config() and openssl.conf to enable FIPS
mode basically still requires each application to explicitly invoke
OPENSSL_config() API in order to truly enable the FIPS mode, is that
correct?

If that's the case, then basically there's no way to really globally enable
the FIPS mode in the OpenSSL library in a system-wide way, so that all the
applications which use OpenSSL (libcrypto to be more specific) will be
running under FIPS mode by default (i.e. without the needs of modification
tomake them invoke either OPENSSL_config() or FIPS_mode_set() API). Is that
correct?

The reason I ask was mainly because I am evaluating how I should modify my
server platform and applications in order to adapt FIPS capable OpenSSL
library into the platform.

Thanks and any suggestions are greatly appreciated.

On Mon, Feb 1, 2016 at 1:35 PM, security veteran <security.veteran at gmail.com
> wrote:

> Thanks Steve.
>
> I think the way to use OPENSSL_config() and openssl.conf basically still
> requires each application to explicitly invoke OPENSSL_config() API in
> order to truly enable the FIPS mode, is that correct?
>
> If that's the case, then basically there's no way to really globally
> enable the FIPS mode in the OpenSSL library in a system-wide way, so that
> all the applications which use OpenSSL (libcrypto to be more specific)
> will be running under FIPS mode by default (i.e. without the needs of
> modification tomake them invoke either OPENSSL_config() or
> FIPS_mode_set() API). Is that correct?
>
> The reason I ask was mainly because I am evaluating how I should modify my
> server platform and applications in order to adapt FIPS capable OpenSSL
> library into the platform.
>
> Thanks and I truly appreciate your answers and helps.
>
> On Fri, Jan 29, 2016 at 6:31 AM, Steve Marquess <marquess at openssl.com>
> wrote:
>
>> On 01/28/2016 07:11 PM, security veteran wrote:
>> > Hi All:
>> >
>> > Is there a way to enable FIPS mode globally, instead of having to
>> > explicitly invoke the FIPS_mode_set() API from each application, for
>> > enabling the FIPS mode?
>> >
>> > ...
>>
>> Kinda-sorta, via OPENSSL_config() and openssl.conf. See the FIPS user
>> guide, https://openssl.org/docs/fips/UserGuide-2.0.pdf, section 5.2.
>>
>> -Steve M.
>>
>> --
>> Steve Marquess
>> OpenSSL Software Foundation
>> 1829 Mount Ephraim Road
>> Adamstown, MD  21710
>> USA
>> +1 877 673 6775 s/b
>> +1 301 874 2571 direct
>> marquess at openssl.com
>> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
>> _______________________________________________
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160202/78bc2fd6/attachment.html>

From steve at openssl.org  Wed Feb  3 01:15:42 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 3 Feb 2016 01:15:42 +0000
Subject: [openssl-users] OpenSSL FIPS: OPENSSL_config() and self-tests
In-Reply-To: <CAC5owtG1k9kJSXwbWcSBHk4SK88GG_icEx3yqf0TDZENObqrkQ@mail.gmail.com>
References: <CAC5owtGzNXdRcBVSQwWbzeiq_eYD2o=H-DSBNOh92T3DdvMe1w@mail.gmail.com>
 <CAC5owtG1k9kJSXwbWcSBHk4SK88GG_icEx3yqf0TDZENObqrkQ@mail.gmail.com>
Message-ID: <20160203011542.GA16603@openssl.org>

On Tue, Feb 02, 2016, security veteran wrote:

> Hi All:
> 
> Based on the OpenSSL FIPS user guide, the FIPS_mode_set API from the
> OpenSSL FIPS modules run a the necessary self-tests.
> 
> I was wondering does the OPENSSL_config() API also run the self-tests?
> 

Short answer: yes.

Longer answer: if you enable FIPS mode in a config file then
OPENSSL_config() will call FIPS_mode_set().

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From hareesh.sai at gmail.com  Wed Feb  3 01:52:05 2016
From: hareesh.sai at gmail.com (Hareesh D)
Date: Wed, 3 Feb 2016 07:22:05 +0530
Subject: [openssl-users] Rgd. CVE-2015-3197 fix test verification !!
Message-ID: <CAD19CyQ-Xwu=9pS1Kx_AC8yG=7JFo+2zfaQ+8RR6BVzEMzAUtw@mail.gmail.com>

Can someone please tell me how to verify the fix done for

CVE-2015-3197. I want to test 1.0.1r version for this issue.

>From the issue description I'm not able to understand what exactly
client and server doing.

Please tell me what packet client has to send or else please provide
me the packet capture of the issue.

Please help. Thanks !!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160203/0e928c4d/attachment.html>

From mofassir_haque at yahoo.com  Wed Feb  3 06:02:47 2016
From: mofassir_haque at yahoo.com (Mofassir Ul Haque)
Date: Wed, 3 Feb 2016 06:02:47 +0000 (UTC)
Subject: [openssl-users] Minumum Key Size Supported by HMAC in FIPS Mode
References: <468772600.918935.1454479367370.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <468772600.918935.1454479367370.JavaMail.yahoo@mail.yahoo.com>

Hi All,
???? I have a question about minimum key size supported by HMAC in FIPS mode. Currently, I am able to run HMAC with 8 bit key in FIPS mode. Shouldn?t FIPS mode only allow keys greater then 14 bytes ? 
Any reply will be greatly appreciated !? Thanks,

Regards, 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160203/dc7beb7d/attachment.html>

From jb-openssl at wisemo.com  Wed Feb  3 11:36:13 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 3 Feb 2016 12:36:13 +0100
Subject: [openssl-users] FIPS Static Library linked into Win32 Dll
 builds but fails self test
In-Reply-To: <20160202190307.GA17500@openssl.org>
References: <1454435124826-63011.post@n7.nabble.com>
 <20160202190307.GA17500@openssl.org>
Message-ID: <56B1E62D.6090100@wisemo.com>

On 02/02/2016 20:03, Dr. Stephen Henson wrote:
> On Tue, Feb 02, 2016, Neptune wrote:
>
>> FIPS Object Module 2.0.9
>> OpenSSL 1.0.1l
>> Platform: Win32
>>
>> I am attempting to statically link a FIPS-capable library into a .dll. The
>> .dll is built without errors and by viewing the .dll in a hex editor I can
>> see the correct HMAC is embedded within and correct, but the self test is
>> failing.
>>
>> Originally I had built the FIPS-capable library as a dynamic library, but
>> during testing we experienced address clashes since the libeay32.dll
>> requires a fixed address and there is no way to guarantee an address we
>> choose will always be vacant, so static linking is a requirement.
>>
> You'll hit the same issue if you link the static version of OpenSSL into a
> DLL. The only way to escape it is to link the static version of OpenSSL into
> the executable or use Win64 which doesn't have this problem.
Actually, I think the issue (and solution) is simpler:

Due to the FIPS-HMAC test being affected by relocations, it will fail
in any DLL or EXE loaded at other than its default address.  Due to
the design of the amd64 (x86_64) instruction set, DLLs for that
architecture (which is not the only Win64 architecture) have much
fewer relocations, but detailed checking (which I have not done) is
needed to determine if the Windows compiler specified in the
validated FIPS policy will insert any such relocations within the
checksummed FIPS blob for Win64 on amd64.

Thus any DLL or EXE containing the FIPS module (and intending to use
it) must be linked with the "/FIXED" option (or have the relocations
stripped later in the build process), and its load address (BASE
address in Windows linker options) must be chosen so it is very
unlikely to clash with 3rd party DLLs, such as globally preloaded
antivirus DLLs.

For EXE files on Win32 (and Win64), the default base address for EXE
files is globally reserved and can be used.

For product-specific DLL files, that are "statically dynamically
linked" to the product EXE files (i.e. marked to be loaded at load
time by statically linking the EXE to a stub "import library"), base
addresses just after the end of the largest product EXE file are
generally safe too.  The easiest way to do this is to use the
sequence: REBASE (with proper file lists for and/or handling, also
specify extra space between modules corresponding to code signing
overhead) BIND, EDITBIN relocation stripping, fips-ld HMAC
calculation, actual release code signing, installer packing,
installer signing, release.

For DLL files that are not tied to a single product (such as the
default libcrypto DLLs, still named libeay on Windows) careful
selection of a likely free fixed load address is needed.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From tony.reix at atos.net  Wed Feb  3 15:03:01 2016
From: tony.reix at atos.net (REIX, Tony)
Date: Wed, 3 Feb 2016 15:03:01 +0000
Subject: [openssl-users] 1.0.2f : crypto/opensslv.h : SHLIB_VERSION_NUMBER
	is still "1.0.0"
Message-ID: <B37989F2852398498001550C29155BE5248472@FRCRPVV9EX3MSX.ww931.my-it-solutions.net>

Hi,

Looking at crypto/opensslv.h of version 1.0.2f, it says:
     # define SHLIB_VERSION_NUMBER "1.0.0"

Shouldn't it be 1.0.2 ??


On AIX, we provide previous versions (32 & 64 bots) of libssl.so and libcrypto.so , for compatibility, like:
libssl.so.0.9.7
libssl.so.0.9.8
libssl.so.1.0.0

and, for 1.0.1r as an example, we deliver libssl.a which contains (for 32bits):
ar tv /opt/freeware/lib/libssl.a
rwxr-xr-x     0/0     802481 Feb  2 16:55 2016 libssl.so.1.0.1
rw-r--r--     0/0     414263 Feb  2 16:58 2016 libssl.so.0.9.7
rw-r--r--     0/0     597413 Feb  2 16:58 2016 libssl.so.0.9.8
rwxr-xr-x     0/0     653177 Feb  2 16:58 2016 libssl.so.1.0.0

Shouldn't I provide the 1.0.2f version as: libssl.so.1.0.2 ?
And thus,  SHLIB_VERSION_NUMBER shouldn't it be set as "1.0.2" in crypto/opensslv.h ?

Thanks

Cordialement,

Tony Reix

Bull - ATOS
IBM Coop Architect & Technical Leader
Office : +33 (0) 4 76 29 72 67
1 rue de Provence - 38432 ?chirolles - France
www.atos.net<https://mail.ad.bull.net/owa/redir.aspx?C=PvphmPvCZkGrAgHVnWGsdMcDKgzl_dEIsM6rX0g4u4v8V81YffzBGkWrtQeAXNovd3ttkJL8JIc.&URL=http%3a%2f%2fwww.atos.net%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160203/c338eadb/attachment-0001.html>

From matt at openssl.org  Wed Feb  3 15:18:12 2016
From: matt at openssl.org (Matt Caswell)
Date: Wed, 3 Feb 2016 15:18:12 +0000
Subject: [openssl-users] 1.0.2f : crypto/opensslv.h :
 SHLIB_VERSION_NUMBER is still "1.0.0"
In-Reply-To: <B37989F2852398498001550C29155BE5248472@FRCRPVV9EX3MSX.ww931.my-it-solutions.net>
References: <B37989F2852398498001550C29155BE5248472@FRCRPVV9EX3MSX.ww931.my-it-solutions.net>
Message-ID: <56B21A34.3030801@openssl.org>



On 03/02/16 15:03, REIX, Tony wrote:
> Hi,
> 
> Looking at crypto/opensslv.h of version 1.0.2f, it says:
>      # define SHLIB_VERSION_NUMBER "*1.0.0*"
> 
> Shouldn't it be 1.0.2 ??

No. It is correct. Probably when we released 1.0.0 we should have given
it a SHLIB_VERSION_NUMBER OF "1.0". The last digit isn't helpful (and in
fact IIRC in the forthcoming 1.1.0 release it is "1.1").

This represents the ABI version. 1.0.2 is binary compatible with 1.0.0.
You should be able to drop in a 1.0.2 version of the library without
having to recompile apps built for 1.0.0 (as long as we didn't
accidentally break something ;-)). This only works if the compile
options have remained consistent between the two library versions though.

Matt

From tony.reix at atos.net  Wed Feb  3 15:52:44 2016
From: tony.reix at atos.net (REIX, Tony)
Date: Wed, 3 Feb 2016 15:52:44 +0000
Subject: [openssl-users] 1.0.2f : crypto/opensslv.h :
 SHLIB_VERSION_NUMBER is still "1.0.0"
Message-ID: <B37989F2852398498001550C29155BE52484BB@FRCRPVV9EX3MSX.ww931.my-it-solutions.net>

Thanks.

I was asking because, when looking at the traces of the build (on AIX and Intel), I see several things like:
if [ -n "" ]; then \
        (cd ..; gmake libcrypto.so.1.0.0); \
fi
where 1.0.0 comes from SHLIB_VERSION_NUMBER  defined in crypto/opensslv.h .
And it looked wrong to me. At least, it seems to do nothing.

  crypto/Makefile:   (cd ..; $(MAKE) $(SHARED_LIB)); \
                        shows:  (cd ..; gmake libcrypto.so.'''1.0.0'''); \
                     SHARED_LIB= libcrypto$(SHLIB_EXT)
  Makefile:          SHLIB_EXT=.so.$(SHLIB_MAJOR).$(SHLIB_MINOR)
  Makefile:          SHLIB_MAJOR=1
                     SHLIB_MINOR=0.0
  Configure:         my $shlib_minor = "unknown";
  Configure:         $shlib_minor=$2;
  Configure:         s/^SHLIB_MINOR=.*/SHLIB_MINOR=$shlib_minor/;
                     open(IN,'<crypto/opensslv.h')
                     $shlib_version_number=$1 if /SHLIB_VERSION_NUMBER *"([^"]+)"/;
                     if ($shlib_version_number =~ /(^[0-9]*)\.([0-9\.]*)/)
                         $shlib_major=$1;    1
                         $shlib_minor=$2;    0.0
 crypto/opensslv.h:  # define SHLIB_VERSION_NUMBER "'''1.0.0'''"

Regards

Cordialement,

Tony Reix

Bull - ATOS
IBM Coop Architect & Technical Leader
Office : +33 (0) 4 76 29 72 67
1 rue de Provence - 38432 ?chirolles - France
www.atos.net

________________________________________
De : openssl-users [openssl-users-bounces at openssl.org] de la part de Matt Caswell [matt at openssl.org]
Envoy? : mercredi 3 f?vrier 2016 16:18
? : openssl-users at openssl.org
Objet : Re: [openssl-users] 1.0.2f : crypto/opensslv.h : SHLIB_VERSION_NUMBER is still "1.0.0"

On 03/02/16 15:03, REIX, Tony wrote:
> Hi,
>
> Looking at crypto/opensslv.h of version 1.0.2f, it says:
>      # define SHLIB_VERSION_NUMBER "*1.0.0*"
>
> Shouldn't it be 1.0.2 ??

No. It is correct. Probably when we released 1.0.0 we should have given
it a SHLIB_VERSION_NUMBER OF "1.0". The last digit isn't helpful (and in
fact IIRC in the forthcoming 1.1.0 release it is "1.1").

This represents the ABI version. 1.0.2 is binary compatible with 1.0.0.
You should be able to drop in a 1.0.2 version of the library without
having to recompile apps built for 1.0.0 (as long as we didn't
accidentally break something ;-)). This only works if the compile
options have remained consistent between the two library versions though.

Matt
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160203/ef041a4e/attachment.html>

From tony.reix at atos.net  Wed Feb  3 16:04:01 2016
From: tony.reix at atos.net (REIX, Tony)
Date: Wed, 3 Feb 2016 16:04:01 +0000
Subject: [openssl-users] How to run one test when gcc is not used ?
Message-ID: <B37989F2852398498001550C29155BE52484D8@FRCRPVV9EX3MSX.ww931.my-it-solutions.net>

Hi,

Runing one test can be done with GCC and the following process:

 $ make clean
 $ export CC="gcc -fprofile-arcs -ftest-coverage"; ./config enable-unit-test
 $ make depend
 $ make
 $ make TESTS="test_cms" test
 $ make TESTS=test_heartbeat test


However, on AIX, I'm using xlC, which does not provide the -fprofile-arcs -ftest-coverage options. So, it seems that I only can run ALL the tests.

Is there another solution for running one test that does not depend on GCC ?
If not, shouldn't the unit testing of OpenSSL use a GCC-independent mechanism so that running one test is possible without GCC ?

Where is the page explaining how to unit test in details ? I haven't been able to find it, only hints on the Web, and general ideas on OpenSSL wiki pages but no details.

Thanks

Cordialement,

Tony Reix

Bull - ATOS
IBM Coop Architect & Technical Leader
Office : +33 (0) 4 76 29 72 67
1 rue de Provence - 38432 ?chirolles - France
www.atos.net<https://mail.ad.bull.net/owa/redir.aspx?C=PvphmPvCZkGrAgHVnWGsdMcDKgzl_dEIsM6rX0g4u4v8V81YffzBGkWrtQeAXNovd3ttkJL8JIc.&URL=http%3a%2f%2fwww.atos.net%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160203/86d70a04/attachment.html>

From janjust at nikhef.nl  Wed Feb  3 16:17:03 2016
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Wed, 03 Feb 2016 17:17:03 +0100
Subject: [openssl-users] Certificate verification failure
In-Reply-To: <94c082e49d8a4c21b41cb64f518ccc92@SW550EXP003.visa.com>
References: <c3ed5b0c1693432aae6148131a1e2c61@SW550EXP003.visa.com>
 <56AF1F7D.6000008@nikhef.nl>
 <94c082e49d8a4c21b41cb64f518ccc92@SW550EXP003.visa.com>
Message-ID: <56B227FF.7030300@nikhef.nl>

Yan, Bob wrote:
> Thanks Jan,
>
> When I am using the CApath, I do have the symbolic hash link (with ".0" at the end hash) linked to my ca-root.pem certificate file and ca-intermediate.pem certificate. Any other issues which could cause this issue? 
>   
what happens if you run
  openssl verify -CApath <dir>   client.crt

? is that certificate correctly verified?

HTH,

JJK

> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jan Just Keijser
> Sent: Monday, February 01, 2016 1:04 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Certificate verification failure
>
> Yan, Bob wrote:
>   
>> Dear Sir/Madam,
>>
>> I have an application which acting as SSL server. When the application 
>> loads the root and intermediate CA files from a CA path, the handshake 
>> between my application and openssl client was failed at the point when 
>> my application was authenticating the client's certificate. But when I 
>> bound the root CA and intermediate CA into a single pem file and 
>> reload it from my application, the handshake is successful. Could 
>> anybody help me resolve this issue? Below is the sample of my 
>> application code for loading the CA certificates:
>>
>> if (SSL_CTX_load_verify_locations(ctx, caFile, caPath) != 1) {
>>
>> exit;
>>
>> }
>>
>> if (SSL_CTX_set_default_verify_paths(ctx) != 1) {
>>
>> exit;
>>
>> }
>>
>> if (SSL_CTX_use_certificate_chain_file(ctx, certFile) != 1) {
>>
>> exit;
>>
>> }
>>
>> if (SSL_CTX_use_PrivateKey_file(ctx, keyFile, SSL_FILETYPE_PEM) != 1) 
>> {
>>
>> exit;
>>
>> }
>>
>> SSL_CTX_set_verify_depth(ctx, chainDepths);
>>
>> SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | 
>> SSL_VERIFY_FAIL_IF_NO_PEER_CERT, callback);
>>
>> SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2);
>>
>>     
>
> when you're using CA path , what are the contents of this CA path directory? In it you should have placed the root and intermediate CA files using special names. Instead of using "ca.pem" you need to have a file "<hash>.0" , where <hash> is the output of "openssl x509 -hash -noout -in ca.pem" (and similarly for the intermediate CA file).
>
> JJK
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>   


From BYan at visa.com  Wed Feb  3 22:33:17 2016
From: BYan at visa.com (Yan, Bob)
Date: Wed, 3 Feb 2016 22:33:17 +0000
Subject: [openssl-users] Certificate verification failure
In-Reply-To: <56B227FF.7030300@nikhef.nl>
References: <c3ed5b0c1693432aae6148131a1e2c61@SW550EXP003.visa.com>
 <56AF1F7D.6000008@nikhef.nl>
 <94c082e49d8a4c21b41cb64f518ccc92@SW550EXP003.visa.com>
 <56B227FF.7030300@nikhef.nl>
Message-ID: <c1be36e4da124d9c911c0d2f65538e72@SW550EXP003.visa.com>

Hi Jan,

The problem is due to the mis-matched version between openssl library (used by application) and openssl executable. Basically the CA/Intermediate CA certificate hash is calculated different between two versions.

Thank you for your help!
Bob
    
-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jan Just Keijser
Sent: Wednesday, February 03, 2016 8:17 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Certificate verification failure

Yan, Bob wrote:
> Thanks Jan,
>
> When I am using the CApath, I do have the symbolic hash link (with ".0" at the end hash) linked to my ca-root.pem certificate file and ca-intermediate.pem certificate. Any other issues which could cause this issue? 
>   
what happens if you run
  openssl verify -CApath <dir>   client.crt

? is that certificate correctly verified?

HTH,

JJK

> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> Behalf Of Jan Just Keijser
> Sent: Monday, February 01, 2016 1:04 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Certificate verification failure
>
> Yan, Bob wrote:
>   
>> Dear Sir/Madam,
>>
>> I have an application which acting as SSL server. When the 
>> application loads the root and intermediate CA files from a CA path, 
>> the handshake between my application and openssl client was failed at 
>> the point when my application was authenticating the client's 
>> certificate. But when I bound the root CA and intermediate CA into a 
>> single pem file and reload it from my application, the handshake is 
>> successful. Could anybody help me resolve this issue? Below is the 
>> sample of my application code for loading the CA certificates:
>>
>> if (SSL_CTX_load_verify_locations(ctx, caFile, caPath) != 1) {
>>
>> exit;
>>
>> }
>>
>> if (SSL_CTX_set_default_verify_paths(ctx) != 1) {
>>
>> exit;
>>
>> }
>>
>> if (SSL_CTX_use_certificate_chain_file(ctx, certFile) != 1) {
>>
>> exit;
>>
>> }
>>
>> if (SSL_CTX_use_PrivateKey_file(ctx, keyFile, SSL_FILETYPE_PEM) != 1) 
>> {
>>
>> exit;
>>
>> }
>>
>> SSL_CTX_set_verify_depth(ctx, chainDepths);
>>
>> SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | 
>> SSL_VERIFY_FAIL_IF_NO_PEER_CERT, callback);
>>
>> SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2);
>>
>>     
>
> when you're using CA path , what are the contents of this CA path directory? In it you should have placed the root and intermediate CA files using special names. Instead of using "ca.pem" you need to have a file "<hash>.0" , where <hash> is the output of "openssl x509 -hash -noout -in ca.pem" (and similarly for the intermediate CA file).
>
> JJK
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>   

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From lesley.j.kimmel at gmail.com  Thu Feb  4 15:13:01 2016
From: lesley.j.kimmel at gmail.com (Lesley Kimmel)
Date: Thu, 4 Feb 2016 09:13:01 -0600
Subject: [openssl-users] Enforcing FIPS via Cipher Suites Declaration
Message-ID: <CAAQu=7T=WShU_SKh9R70oiLFRcQg7rpg5LpA3n6DrOW_hO05_Q@mail.gmail.com>

All;

I'm working with PosgreSQL in a DoD environment and am supposed to enforce
FIPS operation. PostgreSQL doesn't perform a call to FIP_mode_set() but
does provide a configuration item 'ssl_ciphers'. Is there more to FIPS_mode
than I am aware of or would it be functionally equivalent to simply set my
ciphers to something like 'FIPS:!aNULL:!eNULL'?

As a semi-related question, would a non-FIPS OpenSSL installation still
enforce the same cipher suites but just not be 'officially' validated?

Thanks!
-LJK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160204/975db552/attachment.html>

From marquess at openssl.com  Thu Feb  4 16:29:05 2016
From: marquess at openssl.com (Steve Marquess)
Date: Thu, 4 Feb 2016 11:29:05 -0500
Subject: [openssl-users] Enforcing FIPS via Cipher Suites Declaration
In-Reply-To: <CAAQu=7T=WShU_SKh9R70oiLFRcQg7rpg5LpA3n6DrOW_hO05_Q@mail.gmail.com>
References: <CAAQu=7T=WShU_SKh9R70oiLFRcQg7rpg5LpA3n6DrOW_hO05_Q@mail.gmail.com>
Message-ID: <56B37C51.6070106@openssl.com>

On 02/04/2016 10:13 AM, Lesley Kimmel wrote:
> All;
> 
> I'm working with PosgreSQL in a DoD environment and am supposed to
> enforce FIPS operation. PostgreSQL doesn't perform a call to
> FIP_mode_set() but does provide a configuration item 'ssl_ciphers'. Is
> there more to FIPS_mode than I am aware of or would it be functionally
> equivalent to simply set my ciphers to something like 'FIPS:!aNULL:!eNULL'?
> 
> As a semi-related question, would a non-FIPS OpenSSL installation still
> enforce the same cipher suites but just not be 'officially' validated?

Yes, there's a whole lot more to "FIPS 140-2 validated" than just choice
of algorithms/ciphers. There is "magical pixie dust" that won't make
much sense from a pure software engineering perspective. You can find
lots of info online; the Wikipedia article is as good a place as any to
start. Also note the OpenSSL FIPS User Guide,
https://openssl.org/docs/fips/SecurityPolicy-2.0.pdf.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From nn33lik at yahoo.es  Thu Feb  4 16:34:40 2016
From: nn33lik at yahoo.es (Juanan)
Date: Thu, 4 Feb 2016 16:34:40 +0000 (UTC)
Subject: [openssl-users] SSL EV - jurisdictionCountryName - UTF8
References: <181746556.2730138.1454603680679.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <181746556.2730138.1454603680679.JavaMail.yahoo@mail.yahoo.com>


Hello, 

I'm trying to make a SSL EV certificate. 

The config file that I've used has string_mask = utf8only because I need to use UTF8 in commonName,... 

The country and the serialNumber are in the correct format (PrintableString) 

But jurisdictionCountryName is UTF8 and it must be an PrintableString (ASN.1 ? X520countryName as specified in RFC 5280) 

Can you help me? 

Thanks in advance 
Juan

From thomas.francis.jr at pobox.com  Thu Feb  4 16:34:51 2016
From: thomas.francis.jr at pobox.com (Thomas Francis, Jr.)
Date: Thu, 4 Feb 2016 11:34:51 -0500
Subject: [openssl-users] Enforcing FIPS via Cipher Suites Declaration
In-Reply-To: <CAAQu=7T=WShU_SKh9R70oiLFRcQg7rpg5LpA3n6DrOW_hO05_Q@mail.gmail.com>
References: <CAAQu=7T=WShU_SKh9R70oiLFRcQg7rpg5LpA3n6DrOW_hO05_Q@mail.gmail.com>
Message-ID: <7D6C4194-BC6D-4F0E-8FC1-A44D62012C67@pobox.com>

> On Feb 4, 2016, at 10:13 AM, Lesley Kimmel <lesley.j.kimmel at gmail.com> wrote:
> 
> All;
> 
> I'm working with PosgreSQL in a DoD environment and am supposed to enforce FIPS operation. PostgreSQL doesn't perform a call to FIP_mode_set() but does provide a configuration item 'ssl_ciphers'. Is there more to FIPS_mode than I am aware of or would it be functionally equivalent to simply set my ciphers to something like 'FIPS:!aNULL:!eNULL??

Yes, there is more to it.  From a technical standpoint, several ?power-on self-tests? are supposed to be run in order for FIPS mode to be enabled.  While my own experience is the DoD?s auditors are a lot looser with the rules than most, other people report the opposite, and even the looser ones I?ve been in contact with would never allow what you?re suggesting.  You really need to be modifying PostgreSQL to invoke FIPS_mode_set(), and understand that there may be more to it than that.  I haven?t looked in a long time, but there are conceivably runtime issues if you just add that single call.

Also, depending on the auditor, you?d probably need to modify PostgreSQL?s documentation, too, so that it cannot in any way refer to non-approved algorithms as cryptography (except as allowed by relevant NIST publications, but I think SHA-1 is the only special case).  That could be tricky, and it?s up to the you to prove it?s OK, and then to remove the references anyway if the auditor still doesn?t like it. :)

> As a semi-related question, would a non-FIPS OpenSSL installation still enforce the same cipher suites but just not be 'officially' validated?

AFAIK, you could limit it to the appropriate cipher suites, but be aware that FIPS 140 is all about proving that only certain known and tested [implementations of] algorithms are used.  It?s unlikely that another version of OpenSSL would use exactly the same implementations (after all, fixes and performance enhancements have been added), and there?d still be nothing to prove those are the approved algorithms, even if they were the exact same.  So I can?t imagine any auditor approving such a setup.

OpenSSL doesn?t provide a cheap, easy answer to the issues surrounding FIPS 140 compliance, but it does significantly reduce the cost of effort for those producing software.  For those who rely on third-party software, it still helps, but it?s usually going to be a lot more effort than just ?add the OpenSSL FIPS module? to the system. :)

TOM

> Thanks!
> -LJK
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From steve at openssl.org  Thu Feb  4 16:57:09 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 4 Feb 2016 16:57:09 +0000
Subject: [openssl-users] Enforcing FIPS via Cipher Suites Declaration
In-Reply-To: <7D6C4194-BC6D-4F0E-8FC1-A44D62012C67@pobox.com>
References: <CAAQu=7T=WShU_SKh9R70oiLFRcQg7rpg5LpA3n6DrOW_hO05_Q@mail.gmail.com>
 <7D6C4194-BC6D-4F0E-8FC1-A44D62012C67@pobox.com>
Message-ID: <20160204165709.GA12792@openssl.org>

On Thu, Feb 04, 2016, Thomas Francis, Jr. wrote:

> 
> AFAIK, you could limit it to the appropriate cipher suites, but be aware
> that FIPS 140 is all about proving that only certain known and tested
> [implementations of] algorithms are used.  It???s unlikely that another
> version of OpenSSL would use exactly the same implementations (after all,
> fixes and performance enhancements have been added), and there???d still be
> nothing to prove those are the approved algorithms, even if they were the
> exact same.  So I can???t imagine any auditor approving such a setup.
> 

That's correct: when you enter FIPS mode OpenSSL switches algorithm
implementations to those in the validated FIPS module and changes several
other things such as the use of DRBGs for random number generation instead of
the usual OpenSSL PRNG. If you're not in FIPS mode this wont happen and you
wont be using validated versions of algorithms.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From levitte at openssl.org  Thu Feb  4 17:29:13 2016
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 04 Feb 2016 18:29:13 +0100 (CET)
Subject: [openssl-users] Fw: [openssl-dev] Evolution of build refactoring
Message-ID: <20160204.182913.201545962437252542.levitte@openssl.org>

Forwarding this here.  However, I would prefer discussions to happen
on openssl-dev at openssl.org, since this is about OpenSSL development.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

-------------- next part --------------
An embedded message was scrubbed...
From: Richard Levitte <levitte at openssl.org>
Subject: [openssl-dev] Evolution of build refactoring
Date: Thu, 04 Feb 2016 18:27:52 +0100 (CET)
Size: 3621
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160204/7f59e3f6/attachment.mht>

From BYan at visa.com  Thu Feb  4 17:36:46 2016
From: BYan at visa.com (Yan, Bob)
Date: Thu, 4 Feb 2016 17:36:46 +0000
Subject: [openssl-users] =?utf-8?q?WARNING_message_=22can=27t_open_config_?=
 =?utf-8?q?file=E2=80=9D_when_running_openssl_command?=
Message-ID: <98b9cfcc689340d889a0e8b8a8d609f5@SW550EXP003.visa.com>

Hi All,

I downloaded openssl 1.0.2e source files and built it in a Linux server. It seems everything working fine except there is a WARNING message, ?can't open config file? always shown on screen when I run openssl command, see below for detail:

$ openssl x509 -in cert.pem -noout -text
$ WARNING: can't open config file: /usr/local/ssl/openssl.cnf

How can I eliminate this WARNING message even though the ?/usr/local/ssl/openssl.cnf? file does not exist?

Thanks
Bob


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160204/9db68987/attachment-0001.html>

From rsalz at akamai.com  Thu Feb  4 18:41:11 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 4 Feb 2016 18:41:11 +0000
Subject: [openssl-users]
 =?utf-8?q?WARNING_message_=22can=27t_open_config_?=
 =?utf-8?q?file=E2=80=9D_when_running_openssl_command?=
In-Reply-To: <98b9cfcc689340d889a0e8b8a8d609f5@SW550EXP003.visa.com>
References: <98b9cfcc689340d889a0e8b8a8d609f5@SW550EXP003.visa.com>
Message-ID: <1b369c1827f246a2a46d07d6706df9cb@usma1ex-dag1mb1.msg.corp.akamai.com>

> $ openssl x509 -in cert.pem -noout -text
> $ WARNING: can't open config file: /usr/local/ssl/openssl.cnf

> How can I eliminate this WARNING message even though the ?/usr/local/ssl/openssl.cnf? file does not exist?

Among other options, "OPENSSL_CONF=/dev/null ; export OPENSSL_CONF" 

From BYan at visa.com  Thu Feb  4 18:52:19 2016
From: BYan at visa.com (Yan, Bob)
Date: Thu, 4 Feb 2016 18:52:19 +0000
Subject: [openssl-users]
 =?utf-8?q?WARNING_message_=22can=27t_open_config_?=
 =?utf-8?q?file=E2=80=9D_when_running_openssl_command?=
In-Reply-To: <1b369c1827f246a2a46d07d6706df9cb@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <98b9cfcc689340d889a0e8b8a8d609f5@SW550EXP003.visa.com>
 <1b369c1827f246a2a46d07d6706df9cb@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <4958a276fa0f4f63816c2430097bc3d7@SW550EXP003.visa.com>

Hi Rich,

It works, thank you for your suggestions! I am just wondering is there any other options, for example eliminate the WARNING message while building the openssl libraries and executables?

Thank you very much!
Bob


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich
Sent: Thursday, February 04, 2016 10:41 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] WARNING message "can't open config file? when running openssl command

> $ openssl x509 -in cert.pem -noout -text $ WARNING: can't open config 
> file: /usr/local/ssl/openssl.cnf

> How can I eliminate this WARNING message even though the ?/usr/local/ssl/openssl.cnf? file does not exist?

Among other options, "OPENSSL_CONF=/dev/null ; export OPENSSL_CONF" 
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From rsalz at akamai.com  Thu Feb  4 18:57:08 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 4 Feb 2016 18:57:08 +0000
Subject: [openssl-users]
 =?utf-8?q?WARNING_message_=22can=27t_open_config_?=
 =?utf-8?q?file=E2=80=9D_when_running_openssl_command?=
In-Reply-To: <4958a276fa0f4f63816c2430097bc3d7@SW550EXP003.visa.com>
References: <98b9cfcc689340d889a0e8b8a8d609f5@SW550EXP003.visa.com>
 <1b369c1827f246a2a46d07d6706df9cb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <4958a276fa0f4f63816c2430097bc3d7@SW550EXP003.visa.com>
Message-ID: <9993acc8688140eaa43285ac696aeeb2@usma1ex-dag1mb1.msg.corp.akamai.com>

> It works, thank you for your suggestions! I am just wondering is there any
> other options, for example eliminate the WARNING message while building
> the openssl libraries and executables?

You could modify the source (e_os2.h, somewhere in that #ifdef maze sorry) to set the default ot be /dev/null

From lesley.j.kimmel at gmail.com  Thu Feb  4 19:07:02 2016
From: lesley.j.kimmel at gmail.com (Lesley Kimmel)
Date: Thu, 4 Feb 2016 13:07:02 -0600
Subject: [openssl-users] Enforcing FIPS via Cipher Suites Declaration
In-Reply-To: <20160204165709.GA12792@openssl.org>
References: <CAAQu=7T=WShU_SKh9R70oiLFRcQg7rpg5LpA3n6DrOW_hO05_Q@mail.gmail.com>
 <7D6C4194-BC6D-4F0E-8FC1-A44D62012C67@pobox.com>
 <20160204165709.GA12792@openssl.org>
Message-ID: <CAAQu=7S9SBXOL_0BYh=8Ckatb1_ZU_2n453LhFQSX6w-6uE6iQ@mail.gmail.com>

Thanks for the input, all. Those are basically the responses I was
expecting, I just wanted to see it in writing as I couldn't find a clear
answer during a short internet search.

On Thu, Feb 4, 2016 at 10:57 AM, Dr. Stephen Henson <steve at openssl.org>
wrote:

> On Thu, Feb 04, 2016, Thomas Francis, Jr. wrote:
>
> >
> > AFAIK, you could limit it to the appropriate cipher suites, but be aware
> > that FIPS 140 is all about proving that only certain known and tested
> > [implementations of] algorithms are used.  It???s unlikely that another
> > version of OpenSSL would use exactly the same implementations (after all,
> > fixes and performance enhancements have been added), and there???d still
> be
> > nothing to prove those are the approved algorithms, even if they were the
> > exact same.  So I can???t imagine any auditor approving such a setup.
> >
>
> That's correct: when you enter FIPS mode OpenSSL switches algorithm
> implementations to those in the validated FIPS module and changes several
> other things such as the use of DRBGs for random number generation instead
> of
> the usual OpenSSL PRNG. If you're not in FIPS mode this wont happen and you
> wont be using validated versions of algorithms.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160204/3a7d3bf5/attachment.html>

From BYan at visa.com  Thu Feb  4 19:15:55 2016
From: BYan at visa.com (Yan, Bob)
Date: Thu, 4 Feb 2016 19:15:55 +0000
Subject: [openssl-users]
 =?windows-1252?q?WARNING_message_=22can=27t_open_?=
 =?windows-1252?q?config_file=94_when_running_openssl_command?=
In-Reply-To: <9993acc8688140eaa43285ac696aeeb2@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <98b9cfcc689340d889a0e8b8a8d609f5@SW550EXP003.visa.com>
 <1b369c1827f246a2a46d07d6706df9cb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <4958a276fa0f4f63816c2430097bc3d7@SW550EXP003.visa.com>
 <9993acc8688140eaa43285ac696aeeb2@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <c122b84fec1f47a686b4a9f8550adcef@SW550EXP003.visa.com>

Thanks again, Rich!

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich
Sent: Thursday, February 04, 2016 10:57 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] WARNING message "can't open config file? when running openssl command

> It works, thank you for your suggestions! I am just wondering is there 
> any other options, for example eliminate the WARNING message while 
> building the openssl libraries and executables?

You could modify the source (e_os2.h, somewhere in that #ifdef maze sorry) to set the default ot be /dev/null _______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From openssl-users at dukhovni.org  Thu Feb  4 19:16:02 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 4 Feb 2016 19:16:02 +0000
Subject: [openssl-users]
 =?utf-8?q?WARNING_message_=22can=27t_open_config_?=
 =?utf-8?q?file=E2=80=9D_when_running_openssl_command?=
In-Reply-To: <9993acc8688140eaa43285ac696aeeb2@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <98b9cfcc689340d889a0e8b8a8d609f5@SW550EXP003.visa.com>
 <1b369c1827f246a2a46d07d6706df9cb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <4958a276fa0f4f63816c2430097bc3d7@SW550EXP003.visa.com>
 <9993acc8688140eaa43285ac696aeeb2@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20160204191602.GO19242@mournblade.imrryr.org>

On Thu, Feb 04, 2016 at 06:57:08PM +0000, Salz, Rich wrote:

> > It works, thank you for your suggestions! I am just wondering is there any
> > other options, for example eliminate the WARNING message while building
> > the openssl libraries and executables?
> 
> You could modify the source (e_os2.h, somewhere in that #ifdef maze sorry) to set the default ot be /dev/null

The OP should try 1.1.0-dev (master built from source) and see
whether it behaves differently.  What I see is that most of the
commands that don't explicitly need configuration data quietly
ignore a missing default configuration file.  

In master (1.1.0-dev), only commands like "openssl req" that want
various subject DN prompts, ...  complain when there's no configuration
file.  And "req" has a "-config" argument that makes that go away.

So in 1.0.2: I get

    $ OpenSSL_1_0_2/bin/openssl version
    WARNING: can't open config file: .../OpenSSL_1_0_2/ssl/openssl.cnf
    OpenSSL 1.0.2g-dev  xx XXX xxxx

But master (1.1.0-dev) is silent:

    $ mv OpenSSL_master/ssl/openssl.cnf{,.hide}
    $ OpenSSL_master/bin/openssl version
    OpenSSL 1.1.0-pre3-dev  xx XXX xxxx
    $ mv OpenSSL_master/ssl/openssl.cnf{.hide,} 

So the issue is addressed in 1.1.0.  Since the warnings have been
with us since at least the initial 1.0.2 release, and are not new
with 1.0.2f, they're likely to stay for now.

-- 
	Viktor.

From hongyang99 at gmail.com  Thu Feb  4 20:19:28 2016
From: hongyang99 at gmail.com (Yang Hong)
Date: Thu, 4 Feb 2016 15:19:28 -0500
Subject: [openssl-users] FIPS building scripts does NOT work for iOS >=7
Message-ID: <CA+i9jariK9iu5mCXUcEAiZzC2RfO7stooov5dS5AcZ6WnbH3vg@mail.gmail.com>

Hello folks.


I follow the latest User Guide 2.0 to build iOS the FIPS Object Module and
FIPS Capable library for iOS devices (*E.2 Apple iOS Support *page 131)


https://www.openssl.org/docs/fips/UserGuide-2.0.pdf


I got two errors below.

************************************************************

Error #1:


*$ llvm?gcc   -?v*


openssl-fips-2.0.1/iOS/llvm-gcc: line 8: /Applications/

Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin//llvm-gcc:
No such file or directory



Error #2:


$,/config


$make


making fips in crypto...

openssl-fips-2.0.1/iOS/llvm-gcc -I. -I.. -I../include
-DOPENSSL_FIPSCANISTER -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -arm64-9-ios -arch armv7 -O3 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk
-fomit-frame-pointer -fno-common   -c -o cryptlib.o cryptlib.c

openssl-fips-2.0.1/iOS/llvm-gcc: line 8:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin//llvm-gcc:
No such file or directory


*********************************************************************


It seems that the OpenSSL repository for building FIPS module for iOS
remains unchanged since the year 2012. The building script only works on
iOS < 7.


http://openssl.com/fips/2.0/platforms/ios/


The file ?Configure? of openssl-fips-2.0.1.tar.gz only allows to build FIPS
module for iOS < 7.


However, the file ?Configure? of openssl-fips-2.0.11.tar.gz allows to build
FIPS module for iOS >=7. The configuration setting for iOS >=7 has been
updated on July 4, 2015.


Would you please update the corresponding shell scripts setenv-reset.sh and
serenv-ios-11.sh in the following repository? Thank you very much.


http://openssl.com/fips/2.0/platforms/ios/


With best regards,


Winston Hong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160204/e95289e8/attachment-0001.html>

From marquess at openssl.com  Thu Feb  4 22:31:48 2016
From: marquess at openssl.com (Steve Marquess)
Date: Thu, 4 Feb 2016 17:31:48 -0500
Subject: [openssl-users] FIPS building scripts does NOT work for iOS >=7
In-Reply-To: <CA+i9jariK9iu5mCXUcEAiZzC2RfO7stooov5dS5AcZ6WnbH3vg@mail.gmail.com>
References: <CA+i9jariK9iu5mCXUcEAiZzC2RfO7stooov5dS5AcZ6WnbH3vg@mail.gmail.com>
Message-ID: <56B3D154.4020101@openssl.com>

On 02/04/2016 03:19 PM, Yang Hong wrote:
> Hello folks.
> 
> 
> I follow the latest User Guide 2.0 to build iOS the FIPS Object Module
> and FIPS Capable library for iOS devices (*/E.2 Apple iOS Support /*page
> 131)
> 
> 
> https://www.openssl.org/docs/fips/UserGuide-2.0.pdf
> 
> 
> I got two errors below.
> 
> ************************************************************
> 
> ...

No iOS 7 or greater platforms have been tested yet, so this is no
surprise. The FIPS 140-2 validation won't apply for untested versions of
iOS anyway.

If/when we test more iOS versions we'll make changes as appropriate.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From marquess at openssl.com  Thu Feb  4 22:35:41 2016
From: marquess at openssl.com (Steve Marquess)
Date: Thu, 4 Feb 2016 17:35:41 -0500
Subject: [openssl-users] FIPS building scripts does NOT work for iOS >=7
In-Reply-To: <56B3D154.4020101@openssl.com>
References: <CA+i9jariK9iu5mCXUcEAiZzC2RfO7stooov5dS5AcZ6WnbH3vg@mail.gmail.com>
 <56B3D154.4020101@openssl.com>
Message-ID: <56B3D23D.4060109@openssl.com>

On 02/04/2016 05:31 PM, Steve Marquess wrote:
> On 02/04/2016 03:19 PM, Yang Hong wrote:
>> Hello folks.
>>
>>
>> I follow the latest User Guide 2.0 to build iOS the FIPS Object Module
>> and FIPS Capable library for iOS devices (*/E.2 Apple iOS Support /*page
>> 131)
>>
>>
>> https://www.openssl.org/docs/fips/UserGuide-2.0.pdf
>>
>>
>> I got two errors below.
>>
>> ************************************************************
>>
>> ...
> 
> No iOS 7 or greater platforms have been tested yet, so this is no
> surprise. The FIPS 140-2 validation won't apply for untested versions of
> iOS anyway.
> 
> If/when we test more iOS versions we'll make changes as appropriate.

... and I spoke (typed) too fast. The User Guide discussion of iOS is
way out of date. You'll find some relevant info for iOS 7.1, and 8.1 at:

  http://openssl.com/testing/validation-2.0/platforms/ios-7.1/
  http://openssl.com/testing/validation-2.0/platforms/ios-8.1/

I'll get around to updating the User Guide one of these days...

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From steve at openssl.org  Thu Feb  4 23:40:23 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 4 Feb 2016 23:40:23 +0000
Subject: [openssl-users] WARNING message "can't open config file??? when
 running openssl command
In-Reply-To: <4958a276fa0f4f63816c2430097bc3d7@SW550EXP003.visa.com>
References: <98b9cfcc689340d889a0e8b8a8d609f5@SW550EXP003.visa.com>
 <1b369c1827f246a2a46d07d6706df9cb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <4958a276fa0f4f63816c2430097bc3d7@SW550EXP003.visa.com>
Message-ID: <20160204234023.GA26967@openssl.org>

On Thu, Feb 04, 2016, Yan, Bob wrote:

> Hi Rich,
> 
> It works, thank you for your suggestions! I am just wondering is there any other options, for example eliminate the WARNING message while building the openssl libraries and executables?
> 

Another option is to set an appropriate install location (the default is a
Unixy path which doesn't make much sense on Windows) and install openssl.cnf
in there.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From BYan at visa.com  Thu Feb  4 23:56:11 2016
From: BYan at visa.com (Yan, Bob)
Date: Thu, 4 Feb 2016 23:56:11 +0000
Subject: [openssl-users] WARNING message "can't open config file??? when
 running openssl command
In-Reply-To: <20160204234023.GA26967@openssl.org>
References: <98b9cfcc689340d889a0e8b8a8d609f5@SW550EXP003.visa.com>
 <1b369c1827f246a2a46d07d6706df9cb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <4958a276fa0f4f63816c2430097bc3d7@SW550EXP003.visa.com>
 <20160204234023.GA26967@openssl.org>
Message-ID: <aac636c886db4eaf8a0748e7bc503bb1@SW550EXP003.visa.com>

Thanks, Steve!

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Thursday, February 04, 2016 3:40 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] WARNING message "can't open config file??? when running openssl command

On Thu, Feb 04, 2016, Yan, Bob wrote:

> Hi Rich,
> 
> It works, thank you for your suggestions! I am just wondering is there any other options, for example eliminate the WARNING message while building the openssl libraries and executables?
> 

Another option is to set an appropriate install location (the default is a Unixy path which doesn't make much sense on Windows) and install openssl.cnf in there.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org _______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From jb-openssl at wisemo.com  Fri Feb  5 04:25:48 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 5 Feb 2016 05:25:48 +0100
Subject: [openssl-users] Strange problem with 1.0.2f SSL_shutdown in
 multithreaded server
In-Reply-To: <56B09432.40105@openssl.org>
References: <56B0603F.9060207@wisemo.com> <56B08792.20604@openssl.org>
 <56B091D1.8010008@wisemo.com> <56B09432.40105@openssl.org>
Message-ID: <56B4244C.7090402@wisemo.com>

I have not yet found the cause of this issue, however I have
found that a minimal version of your patch which just adds
back the SSL_in_init() condition seems to at least make the
diagnostic test case (using s_client) work again.

I have not kept the test for s being NULL, as that case would
have crashed a few lines earlier in SSL_shutdown(), so can't
reach the if statement anyway.

I have attached the reduced patch, but I still think the real
cause must be elsewhere.

On 02/02/2016 12:34, Matt Caswell wrote:
> On 02/02/16 11:24, Jakob Bohm wrote:
>> On 02/02/2016 11:40, Matt Caswell wrote:
>>> On 02/02/16 07:52, Jakob Bohm wrote:
>>>> I am trying to upgrade an existing 3rd party multithreaded server
>>>> from OpenSSL 1.0.2c to 1.0.2f .  However when I do so, it starts
>>>> mishandling the close_notify "alert".
>>>>
>>>> 1.0.2f seems to send the close_notify alert unencrypted followed
>>>> by an encrypted decrypt_failed alert, where 1.0.2c correctly
>>>> sends just an encrypted close_notify alert.
>>>>
>>>> I am unsure if this exposed a bug in the daemon or in OpenSSL
>>>> itself.
>>> I have a theory.
>>>
>>> Previous versions of 1.0.2 handled an SSL_shutdown() call while in the
>>> middle of a handshake by ignoring it and returning 1 immediately
>>> (meaning everything shutdown successfully). Clearly everything did not
>>> shutdown successfully so the return value is not correct.
>> No, actual application data (just a few bytes) was sent in each
>> direction.
>>
>> Specifically, some bytes were sent client to server, then a reply
>> was sent server to client and the connection was closed.
>>
>> Also, the s_client output showed a completed handshake, with
>> ChangeCipherSpec in both directions and dump of certificate
>> chain before the first application data was sent (client to
>> server, then server to client).
>>
>> The s_client command line was
>>
>> cat data | openssl s_client -connect xx.xx.xx.xx:xxxx -msg -tls1
>> -ign_eof -debug
>>
>> However I cannot rule out that the changes to either SSL_shutdown()
>> or the rearranged error checking code triggered the issue.
> Hmmm. Perhaps try reverting the SSL_shutdown() change to rule that out
> as related in some way? Patch attached to revert that change back to the
> previous implementation.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160205/c88bb508/attachment.html>
-------------- next part --------------
This is sufficient to stop the race condition in one multithreaded server
application that causes it to send ordinary after init shutdown unencrypted,
the underlying race condition has not been found.
---
 ssl/ssl_lib.c |  5 ++++-
 4 files changed, 4 insertions(+), 20 deletions(-)

diff --git a/ssl/ssl_lib.c b/ssl/ssl_lib.c
index 2744be8..f2071db 100644
--- a/ssl/ssl_lib.c
+++ b/ssl/ssl_lib.c
@@ -1060,7 +1060,10 @@ int SSL_shutdown(SSL *s)
         return -1;
     }
 
-    return s->method->ssl_shutdown(s);
+    if (!SSL_in_init(s))
+        return (s->method->ssl_shutdown(s));
+    else
+        return (1);
 }
 
 int SSL_renegotiate(SSL *s)
-- 
2.5.0



From matt at openssl.org  Fri Feb  5 09:17:07 2016
From: matt at openssl.org (Matt Caswell)
Date: Fri, 5 Feb 2016 09:17:07 +0000
Subject: [openssl-users] Strange problem with 1.0.2f SSL_shutdown in
 multithreaded server
In-Reply-To: <56B4244C.7090402@wisemo.com>
References: <56B0603F.9060207@wisemo.com> <56B08792.20604@openssl.org>
 <56B091D1.8010008@wisemo.com> <56B09432.40105@openssl.org>
 <56B4244C.7090402@wisemo.com>
Message-ID: <56B46893.9060605@openssl.org>



On 05/02/16 04:25, Jakob Bohm wrote:
> I have not yet found the cause of this issue, however I have
> found that a minimal version of your patch which just adds
> back the SSL_in_init() condition seems to at least make the
> diagnostic test case (using s_client) work again.
> 
> I have not kept the test for s being NULL, as that case would
> have crashed a few lines earlier in SSL_shutdown(), so can't
> reach the if statement anyway.
> 
> I have attached the reduced patch, but I still think the real
> cause must be elsewhere.

I am currently pushing a very similar patch through the internal review
process. The main difference is that -1 is returned in the "else" case.
This is actually primarily to address a different issue, but it seems it
should help you too. It would be good to know the underlying cause though.

Matt




From openssl at aise.re  Sun Feb  7 14:43:50 2016
From: openssl at aise.re (Wesley)
Date: Sun, 07 Feb 2016 18:43:50 +0400
Subject: [openssl-users] Encrypt/Decrypt files using openssl's crypto
	libraries
Message-ID: <07ed66c34931e5e7f493d28aa8e9e40a@aise.re>

 

Hi, 

I want to make a write an app that will encrypt/decrypt files
using the OpenSSL's crypto libraries. 

Actually i can encrypt files
using system() with the command line (and VARIABLES) :


"/usr/bin/openssl enc -aes-256-cbc -salt -in FILENAME -out
FILENAME_ENC -pass pass:HASH" 

and decrypt file using :


"/usr/bin/openssl enc -aes-256-cbc -d -in FILENAME_ENC -out FILENAME
-pass pass:HASH" 

I read this :
https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption


But i don't know where to start... Does anyone can help me ? 

Thank
you very much for your replies. 

Cheers, 

Wesley 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160207/d40cf631/attachment.html>

From openssl at aise.re  Sun Feb  7 14:49:02 2016
From: openssl at aise.re (Wesley)
Date: Sun, 07 Feb 2016 18:49:02 +0400
Subject: [openssl-users] Encrypt/Decrypt files using openssl's crypto
	libraries
Message-ID: <b784acfa4fce5a5c3b720580b80c26ac@aise.re>

Hi,

I want to make an app that will encrypt/decrypt files using the 
OpenSSL's crypto libraries.

Actually i can encrypt files using system() with the command line (and 
VARIABLES) :

"/usr/bin/openssl enc -aes-256-cbc -salt -in FILENAME -out FILENAME_ENC 
-pass pass:HASH"

and decrypt file using :

"/usr/bin/openssl enc -aes-256-cbc -d -in FILENAME_ENC -out FILENAME 
-pass pass:HASH"

I read this : 
https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption
But i don't know where to start... Does anyone can help me ?

Thank you very much for your replies.



Cheers,

Wesley



From marquess at openssl.com  Mon Feb  8 13:36:12 2016
From: marquess at openssl.com (Steve Marquess)
Date: Mon, 8 Feb 2016 08:36:12 -0500
Subject: [openssl-users] FIPS 140-2 X9.31 RNG transition ... still in
	transition
Message-ID: <56B899CC.9040008@openssl.com>

I'm getting private queries about the status of the OpenSSL FIPS Object
Module v2.0 (the "OpenSSL FIPS module") which I'll answer here for everyone.

As always, if you don't know or care what I'm talking about then run for
high ground lest you trip and fall down the rabbit hole...

The OpenSSL FIPS module is (very confusingly) covered by three nominally
separate validations, #1747, #2398, #2473.

It used to be that validations lived forever. Recently the CMVP has
introduced two policy changes that can kill extant validations (see
http://csrc.nist.gov/groups/STM/cmvp/notices.html, under headings
"validation sunsetting policy" and "X9.31 RNG transition".

One is expiration of validations that haven't been updated in five
years, beginning in 2017; not a factor for any validation yet and moot
for the OpenSSL FIPS module validations for a few years still (as those
tend to be updated frequently).

The other is the "RNG transition" of a large class of validations,
including all the OpenSSL and OpenSSL derived ones, that will kill (has
killed) validations not updated by a week ago. Those deceased
validations can be found at:

  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-historical.htm

Note there are a lot of them, including the older OpenSSL open source
based validations (#1051 and prior).

What about the current OpenSSL FIPS module, which is validation(s)
#1747/#2398/#2473? Well, the paperwork for updating those three
validations (said update consisting of wordsmithing only, no software
changes) was submitted at the same time. But, as so frequently happens
those very similar submissions encountered different receptions.

Two of the submissions have been approved, for #1747 and #2473. The one
for #2398 is still pending. The CMVP has left that validation in the
active validation list, with the notation "This module is in process for
the RNG transition.". So the #2398 validation is in limbo at present,
waiting for CMVP action.

Since the OpenSSL FIPS module is represented by all three validations,
it is in a limbo of sorts too. The practical effect is probably minimal,
though, as there is no reason to expect the CMVP won't eventually
approve the third submission.  That validation has a lot of company in
limbo status, too.

That's short term. There are implications for the long term too.

Note that the five year expiration will for all practical purposes
impose an upper limit on the usable lifespan of any current or future
open source based validations (such as #1051, #1747, etc.). That is
because those collaborative validations are only possible with support
from multiple separate sponsors (several dozen so far for the
#1747/#2398/#2473 module). That collaborative support results in many
platforms ("OE"s) for the one shared validation(s); over 120 platforms
for the latest module. That collaborative support makes these
validations economically feasible (barely...) and also makes the
collaborative validations valuable to a very wide range of end users.
However, the concentration of so many platforms for one validation makes
that validation(s) very vulnerable to forced changes (as will be
required to avoid the five year termination). Any forced change that
requires retesting of all the platforms is economically infeasible (I
estimate retesting of the 120+ platforms for the #1747+ validation(s)
would cost over $800K even if we could spare the time and manpower,
which we can't). Note such a forced change impact has effectively
happened already, in 2015[1], with a financially ruinous outcome for the
OpenSSL FIPS business.

What vendors can do, and are doing, is obtaining separate "clone"
("Alternative Scenario 1A/1B") or "private label" ("5SUB") validations
based on the OpenSSL FIPS module. That works well for those specific
vendors, as long as they have an open source based module to copy from,
but those copycat validations don't do the rest of the OpenSSL user
community any good and don't contribute to the support of the open
source based validations. Without sharing costs among many sponsors the
open source validations aren't possible.

So the collaborative open source based FIPS validation model that
brought us five successive OpenSSL FIPS modules, culminating in the
#1747/#2398/#2473 validation, is dead[2]. If there's any viable
opportunity to pursue a new validation I haven't seen it yet.

-Steve M.

[1] Tediously documented in the "hostage/ransom/aftermath" trilogy at
http://openssl.com/fips/

[2] See https://openssl.org/blog/blog/2015/09/29/fips/

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From martin at black-sheep-research.com  Mon Feb  8 14:43:00 2016
From: martin at black-sheep-research.com (counterpoint)
Date: Mon, 8 Feb 2016 07:43:00 -0700 (MST)
Subject: [openssl-users] Extra EPOLLIN event at end of SSL connection
Message-ID: <1454942580904-63384.post@n7.nabble.com>

Working on a multi-threaded system that is providing an SSL server
capability, I am running into an odd problem at the end of a connection.
There seems no functional downside, in that it appears all data is handled
correctly. The trouble is errors are being logged.

What seems to happen is that the connection works fine up to the point where
it comes to an end. The client uses the application protocol (MySQL) to send
a message saying it wants to disconnect. However, it seems that there is an
EPOLLIN event that occurs after this. Because of the multi-threading, it is
possible for the new EPOLLIN event to be processed before the relevant entry
is removed from the poll list. This results in an SSL_read that gives back a
SYSCALL error but no further analysis can be done as nothing returns from
ERR_get_error.

It is possible to put in some extra tests and reduce the incidence of the
problem, but in the nature of multi-threading, it does not look possible to
totally eliminate it. So I am wondering why there is an extra EPOLLIN event
when it is not possible to do an SSL_read.  Is there anything I could do to
prevent it?



--
View this message in context: http://openssl.6102.n7.nabble.com/Extra-EPOLLIN-event-at-end-of-SSL-connection-tp63384.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From martin at black-sheep-research.com  Mon Feb  8 16:45:30 2016
From: martin at black-sheep-research.com (counterpoint)
Date: Mon, 8 Feb 2016 09:45:30 -0700 (MST)
Subject: [openssl-users] Extra EPOLLIN event at end of SSL connection
In-Reply-To: <1454942580904-63384.post@n7.nabble.com>
References: <1454942580904-63384.post@n7.nabble.com>
Message-ID: <1454949930248-63394.post@n7.nabble.com>

Looks as if I can reply to my own message! Maybe this exchange might help
someone else. 

It seems that EPOLLIN events with no data are inevitable and have to be
accepted. So in a way, it is a quirk of OpenSSL that typical example code
results in the no data case being interpreted as an error. I've concluded
that if the analysis of the return gives SYSCALL error but there is nothing
to be had from ERR_get_error, then the case should be ignored, and not
logged as an error.

But I'd still be happy to receive a second opinion!



--
View this message in context: http://openssl.6102.n7.nabble.com/Extra-EPOLLIN-event-at-end-of-SSL-connection-tp63384p63394.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From rsalz at akamai.com  Mon Feb  8 17:41:19 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 8 Feb 2016 17:41:19 +0000
Subject: [openssl-users] Extra EPOLLIN event at end of SSL connection
In-Reply-To: <1454949930248-63394.post@n7.nabble.com>
References: <1454942580904-63384.post@n7.nabble.com>
 <1454949930248-63394.post@n7.nabble.com>
Message-ID: <0920f4c8429a41369b0865c1064ee7eb@usma1ex-dag1mb1.msg.corp.akamai.com>

Are you getting WANT_READ or WANT_WRITE?  That is common for non-blocking.  And also, yeah, way back when, it was common to return zero when read on a non-blocking socket had no data :)  And what release are you using?

From rsalz at akamai.com  Mon Feb  8 18:37:31 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 8 Feb 2016 18:37:31 +0000
Subject: [openssl-users] Do you use the JPAKE feature?
Message-ID: <cfaafe95d6f84cbbad64046b532c6185@usma1ex-dag1mb1.msg.corp.akamai.com>

It's currently "experimental" and we're thinking of dropping it completely from the next release.  If you use it, please reply here soon.

--
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160208/3c2620f7/attachment.html>

From kurt at roeckx.be  Mon Feb  8 22:14:33 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 8 Feb 2016 23:14:33 +0100
Subject: [openssl-users] Extra EPOLLIN event at end of SSL connection
In-Reply-To: <1454942580904-63384.post@n7.nabble.com>
References: <1454942580904-63384.post@n7.nabble.com>
Message-ID: <20160208221432.GA16831@roeckx.be>

On Mon, Feb 08, 2016 at 07:43:00AM -0700, counterpoint wrote:
> Working on a multi-threaded system that is providing an SSL server
> capability, I am running into an odd problem at the end of a connection.
> There seems no functional downside, in that it appears all data is handled
> correctly. The trouble is errors are being logged.
> 
> What seems to happen is that the connection works fine up to the point where
> it comes to an end. The client uses the application protocol (MySQL) to send
> a message saying it wants to disconnect. However, it seems that there is an
> EPOLLIN event that occurs after this.

TLS also does a shutdown of the connection, in which no
application data is send anymore but at the TLS level packets
still get send.  Is that what you mean?


Kurt


From hongyang99 at gmail.com  Tue Feb  9 03:11:19 2016
From: hongyang99 at gmail.com (Yang Hong)
Date: Mon, 8 Feb 2016 22:11:19 -0500
Subject: [openssl-users] FIPS building scripts does NOT work for iOS >=7
In-Reply-To: <56B3D23D.4060109@openssl.com>
References: <CA+i9jariK9iu5mCXUcEAiZzC2RfO7stooov5dS5AcZ6WnbH3vg@mail.gmail.com>
 <56B3D154.4020101@openssl.com> <56B3D23D.4060109@openssl.com>
Message-ID: <CA+i9jaqAEHdn0nYRYa4FZefqjA4zzCu8EOBH7YyvSUGXDGkpaw@mail.gmail.com>

Hello Steve.

Thank you very much for your quick response.

I have tried different approaches to build FIPS module, according to the
testing instructions of iOS 7.1 and iOS 8.1. Unfortunately I failed for all
the FIPS packages for iOS >= 7, i.e., openssl-fips-2.0.8.tar,
openssl-fips-2.0.9.tar, openssl-fips-2.0.10.tar, openssl-fips-2.0.11.tar.

Apple Mac OS has been automatically updated to the new version. I failed to
recover it to the old version.
**************************************************
$ uname -a
Darwin Honeycrisp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19
15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64

$ clang -v
Apple LLVM version 7.0.0 (clang-700.1.76)
Target: x86_64-apple-darwin15.0.0
Thread model: posix

$ ls
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs

iPhoneOS.sdk iPhoneOS6.1.sdk  iPhoneOS7.1.sdk iPhoneOS9.1.sdk
**************************************************


I reports the building issues below:
**************************************************
(1) For iOS 7.1,

http://openssl.com/testing/validation-2.0/platforms/ios-7.1/TestingInstructions-iOS-7.1.pdf

(1a) Correct results in Section 4.3 Compilation of "incore_macho" Utility

$ tar zxf openssl-fips-2.0.8.tar

$ cd openssl-fips-2.0.8

$ tar zxvf ../ios64?incore.tar.gz

$ . ../setenv?reset.sh

$ . ../setenv?darwin?i386.sh

$ ./config

$ make

$ cd iOS

$ make

$ ./incore_macho usage:
./incore_macho [??debug] [?exe|?dso] executable

$ lipo ?info ancore_macho
Non?fat file: iOS/incore_macho is architecture: i386

$cd ..

$ make clean

All the above operations achieve the exactly same results as indicated by
the testing guide.

(1b) the errors appear in Section  4.4 Cross? compilation of FIPS module

$ . ../setenv-reset.sh

$ . ../setenv-ios-11.sh

$ ./config

$ make

ld: building for iOS simulator, but linking against dylib built for OSX,
file '/usr/lib/libSystem.dylib' for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see
invocation)


(2) I met the same failures for the other 3 FIPS packages  2.0.9 -- 2.0.11

I have noticed that 2.0.10 and 2.0.11 have included iOS folders. Thus we do
NOT need to extract ios64incore.tar,gz

**************************************************************

If I run the following shell script in a separate folder, I can build
OpenSSL generate module successfully. The built OpenSSL library works well
for iOS 9 device.

https://github.com/x2on/OpenSSL-for-iPhone/blob/master/build-libssl.sh


I have tried many approaches from the Internet, for example,

https://github.com/GotoHack/iOS-openSSL-FIPS

http://stackoverflow.com/questions/1211854/xcode-conditional-build-settings-based-on-architecture-device-arm-vs-simulat

http://stackoverflow.com/questions/6293298/llvm-gcc-4-2-error

I still can not solve the issues.

***************************************************************

I have used Beyond compare 4 to check the difference between
openssl-1.0.2f/config (or Configure) and openssl-fips-2.0.11/config (or
Configure). I do NOT know how to modify the setenv-ios-11.sh to generate
OpenSSL FIPS module for iOS >=8 under the new Mac OS available from Apple
website.

Would you shed some light on how to modify the building script for iOS >=8?
Thank you very much.

With best regards,

Winston Hong


On Thu, Feb 4, 2016 at 5:35 PM, Steve Marquess <marquess at openssl.com> wrote:

> On 02/04/2016 05:31 PM, Steve Marquess wrote:
> > On 02/04/2016 03:19 PM, Yang Hong wrote:
> >> Hello folks.
> >>
> >>
> >> I follow the latest User Guide 2.0 to build iOS the FIPS Object Module
> >> and FIPS Capable library for iOS devices (*/E.2 Apple iOS Support /*page
> >> 131)
> >>
> >>
> >> https://www.openssl.org/docs/fips/UserGuide-2.0.pdf
> >>
> >>
> >> I got two errors below.
> >>
> >> ************************************************************
> >>
> >> ...
> >
> > No iOS 7 or greater platforms have been tested yet, so this is no
> > surprise. The FIPS 140-2 validation won't apply for untested versions of
> > iOS anyway.
> >
> > If/when we test more iOS versions we'll make changes as appropriate.
>
> ... and I spoke (typed) too fast. The User Guide discussion of iOS is
> way out of date. You'll find some relevant info for iOS 7.1, and 8.1 at:
>
>   http://openssl.com/testing/validation-2.0/platforms/ios-7.1/
>   http://openssl.com/testing/validation-2.0/platforms/ios-8.1/
>
> I'll get around to updating the User Guide one of these days...
>
> -Steve M.
>
> --
> Steve Marquess
> OpenSSL Validation Services, Inc.
> 1829 Mount Ephraim Road
> Adamstown, MD  21710
> USA
> +1 877 673 6775 s/b
> +1 301 874 2571 direct
> marquess at openssl.com
> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160208/9d92560c/attachment-0001.html>

From stm at pdflib.com  Tue Feb  9 09:15:14 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Tue, 9 Feb 2016 10:15:14 +0100
Subject: [openssl-users] Is the structure of this CMS object correct?
Message-ID: <56B9AE22.6000501@pdflib.com>

Hi,

I'm trying to decrypt a DER-encoded CMS object (created by Adobe 
Acrobat) with OpenSSL 1.0.2d:

$ openssl cms -decrypt -in recipient.bin  -inform DER -inkey 
atssecp521r1.key -recip atssecp521r1.pem
Error reading S/MIME message
140735227593552:error:0D0680A8:asn1 encoding 
routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1198:
140735227593552:error:0D06C03A:asn1 encoding 
routines:ASN1_D2I_EX_PRIMITIVE:nested asn1 error:tasn_dec.c:762:
140735227593552:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:694:Field=version, Type=CMS_KeyAgreeRecipientInfo
140735227593552:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:685:
140735227593552:error:0D07803A:asn1 encoding 
routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:336:Field=d.kari, 
Type=CMS_RecipientInfo
140735227593552:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:666:Field=recipientInfos, Type=CMS_EnvelopedData
140735227593552:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:694:
140735227593552:error:0D08403A:asn1 encoding 
routines:ASN1_TEMPLATE_EX_D2I:nested asn1 
error:tasn_dec.c:557:Field=d.envelopedData, Type=CMS_ContentInfo

The full dumpasn1 output of the file "recipient.bin" is below at the end 
of the message. Is this a correct CMS object?

If I compare this to the structure of a CMS object that was generated by 
OpenSSL itself, there's a difference in the structure of the 
RecipientInfos object. If I understand it correctly, this is the start 
of the RecipientInfos object (starting at line 6 of the dumpasn1 output):

        SET {
          [1] {
            SEQUENCE {
              INTEGER 3
              ...

I can match this to the following rules in RFC 5652:

RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

RecipientInfo ::= CHOICE {
         ktri KeyTransRecipientInfo,
         kari [1] KeyAgreeRecipientInfo,
         kekri [2] KEKRecipientInfo,
         pwri [3] PasswordRecipientinfo,
         ori [4] OtherRecipientInfo }

KeyAgreeRecipientInfo ::= SEQUENCE {
         version CMSVersion,  -- always set to 3
         originator [0] EXPLICIT OriginatorIdentifierOrKey,
         ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
         keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
         recipientEncryptedKeys RecipientEncryptedKeys }

If I dump a CMS object that was created with OpenSSL's CMS tool with the 
same certificate as the problematic one, the structure of the 
RecipientInfos object looks like this:

        SET {
          [1] {
            INTEGER 3
            ...

So the "SEQUENCE" element of the KeyAgreeRecipientInfo is not present here.

Another issue in the Acrobat-generated CMS object is the top-level 
CMSVersion in the EnvelopedData object being 0. I believe this is wrong 
and should be 2, but apparently OpenSSL doesn't care.

Full output of dumpasn1 for "recipient.bin" file:

  SEQUENCE {
    OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
    [0] {
      SEQUENCE {
        INTEGER 0
        SET {
          [1] {
            SEQUENCE {
              INTEGER 3
              [0] {
                [1] {
                  SEQUENCE {
                    SEQUENCE {
                      OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
                      OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
                      }
                    BIT STRING
                    04 01 91 BE 01 63 00 79 C2 D2 95 0F 9D 03 A4 34
                    5A 9C 2F 98 4A 13 D4 59 C6 EA 6C 4B 6D 7D 2B DC
                    1C 08 16 86 EF F0 C2 3D AE A4 AF A3 7C 7E 15 80
                    55 18 06 2C E9 09 19 3A 3A 78 DD 93 F1 33 B1 1E
                    9A 76 7C 01 1E 8B B6 B0 FE 5E BA FD 04 EE F3 84
                    3D 47 61 22 D2 A3 AC 1C D4 B8 66 57 94 B1 74 83
                    B1 4E 7F 2F 64 7F 4F 64 40 6A 1D 02 38 5F FE DF
                    93 7B 14 6D 5A BF 75 AC 77 CB 47 2B 16 F0 9D C7
                            [ Another 5 bytes skipped ]
                    }
                  }
                }
              [1] {
                OCTET STRING E5 38 52 B1 13 7C 44 40
                }
              SEQUENCE {
                OBJECT IDENTIFIER '1 3 132 1 11 3'
                SEQUENCE {
                  OBJECT IDENTIFIER
                    aes256-wrap (2 16 840 1 101 3 4 1 45)
                  }
                }
              SEQUENCE {
                SEQUENCE {
                  SEQUENCE {
                    SEQUENCE {
                      SET {
                        SEQUENCE {
                          OBJECT IDENTIFIER countryName (2 5 4 6)
                          PrintableString 'DE'
                          }
                        }
                      SET {
                        SEQUENCE {
                          OBJECT IDENTIFIER localityName (2 5 4 7)
                          UTF8String 'Munich'
                          }
                        }
                      SET {
                        SEQUENCE {
                          OBJECT IDENTIFIER organizationName (2 5 4 10)
                          UTF8String 'PDFlib GmbH'
                          }
                        }
                      SET {
                        SEQUENCE {
                          OBJECT IDENTIFIER commonName (2 5 4 3)
                          UTF8String 'PDFlib GmbH ATS Demo Intermediate CA'
                          }
                        }
                      }
                    INTEGER 27
                    }
                  OCTET STRING
                    3E 41 09 AD 71 B5 E3 26 5F 5A D8 97 01 0D D1 72
                    2F 37 3C AA 47 4F B6 67
                  }
                }
              }
            }
          }
        SEQUENCE {
          OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
          SEQUENCE {
            OBJECT IDENTIFIER aes128-CBC (2 16 840 1 101 3 4 1 2)
            OCTET STRING
              97 40 83 5E 1D 25 48 49 95 56 CE 75 61 1B 49 12
            }
          [0]
            EF 24 A2 94 42 A4 5F C1 F5 6C B4 26 DA BA 6A 1C
            F5 01 21 91 B9 0B 3E 69 29 2E 5C F1 AD EC F0 63
          }
        }
      }
    }

--
  Stephan

From Erwann.Abalea at docusign.com  Tue Feb  9 10:53:47 2016
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Tue, 9 Feb 2016 10:53:47 +0000
Subject: [openssl-users] Is the structure of this CMS object correct?
In-Reply-To: <56B9AE22.6000501@pdflib.com>
References: <56B9AE22.6000501@pdflib.com>
Message-ID: <AF40454C-E74A-4359-B53C-E694AE1FC590@docusign.com>

Bonjour,

Le 9 f?vr. 2016 ? 10:15, Stephan M?hlstrasser <stm at pdflib.com<mailto:stm at pdflib.com>> a ?crit :

Hi,

I'm trying to decrypt a DER-encoded CMS object (created by Adobe Acrobat) with OpenSSL 1.0.2d:

$ openssl cms -decrypt -in recipient.bin  -inform DER -inkey atssecp521r1.key -recip atssecp521r1.pem
Error reading S/MIME message
140735227593552:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1198:
140735227593552:error:0D06C03A:asn1 encoding routines:ASN1_D2I_EX_PRIMITIVE:nested asn1 error:tasn_dec.c:762:
140735227593552:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:694:Field=version, Type=CMS_KeyAgreeRecipientInfo
140735227593552:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:685:
140735227593552:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:336:Field=d.kari, Type=CMS_RecipientInfo
140735227593552:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:666:Field=recipientInfos, Type=CMS_EnvelopedData
140735227593552:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:694:
140735227593552:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1 error:tasn_dec.c:557:Field=d.envelopedData, Type=CMS_ContentInfo

The full dumpasn1 output of the file "recipient.bin" is below at the end of the message. Is this a correct CMS object?

If I compare this to the structure of a CMS object that was generated by OpenSSL itself, there's a difference in the structure of the RecipientInfos object. If I understand it correctly, this is the start of the RecipientInfos object (starting at line 6 of the dumpasn1 output):

      SET {
        [1] {
          SEQUENCE {
            INTEGER 3
            ?

This is the expression of an EXPLICIT tag.

I can match this to the following rules in RFC 5652:

RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

RecipientInfo ::= CHOICE {
       ktri KeyTransRecipientInfo,
       kari [1] KeyAgreeRecipientInfo,
       kekri [2] KEKRecipientInfo,
       pwri [3] PasswordRecipientinfo,
       ori [4] OtherRecipientInfo }

KeyAgreeRecipientInfo ::= SEQUENCE {
       version CMSVersion,  -- always set to 3
       originator [0] EXPLICIT OriginatorIdentifierOrKey,
       ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
       keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
       recipientEncryptedKeys RecipientEncryptedKeys }

See RFC5652 section 12.1.
These data types are defined in a module with IMPLICIT TAGS (it was changed between PKCS#7v1.5 and RFC2630), so kari, kekri, pwri, and ori elements are associated to an IMPLICIT tag.

Additional definition to read the dump.

OriginatorIdentifierOrKey ::= CHOICE {
     issuerAndSerialNumber IssuerAndSerialNumber,
     subjectKeyIdentifier [0] SubjectKeyIdentifier,
     originatorKey [1] OriginatorPublicKey }

OriginatorPublicKey ::= SEQUENCE {
     algorithm AlgorithmIdentifier,
     publicKey BIT STRING }


If I dump a CMS object that was created with OpenSSL's CMS tool with the same certificate as the problematic one, the structure of the RecipientInfos object looks like this:

      SET {
        [1] {
          INTEGER 3
          ?

So the "SEQUENCE" element of the KeyAgreeRecipientInfo is not present here.

This is the correct behavior of an IMPLICIT tag.

Another issue in the Acrobat-generated CMS object is the top-level CMSVersion in the EnvelopedData object being 0. I believe this is wrong and should be 2, but apparently OpenSSL doesn't care.

Full output of dumpasn1 for "recipient.bin" file:

SEQUENCE {
  OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
  [0] {
    SEQUENCE {
      INTEGER 0
      SET {
        [1] {
          SEQUENCE {

This is wrong, the SEQUENCE is to be hidden by the [1] tag.

            INTEGER 3
            [0] {

The [0] introduces the originator element, of type OriginatorIdentifierOrKey, it?s EXPLICIT.

              [1] {
                SEQUENCE {

Also wrong, the [1] here should be IMPLICIT and hide the SEQUENCE tag of the OriginatorPublicKey structure.

                  SEQUENCE {
                    OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
                    OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
                    }
                  BIT STRING
                  04 01 91 BE 01 63 00 79 C2 D2 95 0F 9D 03 A4 34
                  5A 9C 2F 98 4A 13 D4 59 C6 EA 6C 4B 6D 7D 2B DC
                  1C 08 16 86 EF F0 C2 3D AE A4 AF A3 7C 7E 15 80
                  55 18 06 2C E9 09 19 3A 3A 78 DD 93 F1 33 B1 1E
                  9A 76 7C 01 1E 8B B6 B0 FE 5E BA FD 04 EE F3 84
                  3D 47 61 22 D2 A3 AC 1C D4 B8 66 57 94 B1 74 83
                  B1 4E 7F 2F 64 7F 4F 64 40 6A 1D 02 38 5F FE DF
                  93 7B 14 6D 5A BF 75 AC 77 CB 47 2B 16 F0 9D C7
                          [ Another 5 bytes skipped ]
                  }
                }
              }

I haven?t checked the rest.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160209/4408c59e/attachment-0001.html>

From stm at pdflib.com  Tue Feb  9 11:29:08 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Tue, 9 Feb 2016 12:29:08 +0100
Subject: [openssl-users] Is the structure of this CMS object correct?
In-Reply-To: <AF40454C-E74A-4359-B53C-E694AE1FC590@docusign.com>
References: <56B9AE22.6000501@pdflib.com>
 <AF40454C-E74A-4359-B53C-E694AE1FC590@docusign.com>
Message-ID: <56B9CD84.7020207@pdflib.com>

Bonjour Erwann,

Am 09.02.16 um 11:53 schrieb Erwann Abalea:
> Bonjour,
>
>> Le 9 f?vr. 2016 ? 10:15, Stephan M?hlstrasser <stm at pdflib.com
>> <mailto:stm at pdflib.com>> a ?crit :
>> ...
>>
>>       SET {
>>         [1] {
>>           SEQUENCE {
>>             INTEGER 3
>>             ?
>
> This is the expression of an EXPLICIT tag.
>
>> I can match this to the following rules in RFC 5652:
>>
>> RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
>>
>> RecipientInfo ::= CHOICE {
>>        ktri KeyTransRecipientInfo,
>>        kari [1] KeyAgreeRecipientInfo,
>>        kekri [2] KEKRecipientInfo,
>>        pwri [3] PasswordRecipientinfo,
>>        ori [4] OtherRecipientInfo }
>>
>> KeyAgreeRecipientInfo ::= SEQUENCE {
>>        version CMSVersion,  -- always set to 3
>>        originator [0] EXPLICIT OriginatorIdentifierOrKey,
>>        ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
>>        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>>        recipientEncryptedKeys RecipientEncryptedKeys }
>
> See RFC5652 section 12.1.
> These data types are defined in a module with IMPLICIT TAGS (it was
> changed between PKCS#7v1.5 and RFC2630), so kari, kekri, pwri, and ori
> elements are associated to an IMPLICIT tag.
>
> Additional definition to read the dump.
>
> OriginatorIdentifierOrKey ::= CHOICE {
>       issuerAndSerialNumber IssuerAndSerialNumber,
>       subjectKeyIdentifier [0] SubjectKeyIdentifier,
>       originatorKey [1] OriginatorPublicKey }
>
> OriginatorPublicKey ::= SEQUENCE {
>       algorithm AlgorithmIdentifier,
>       publicKey BIT STRING }
>
>
>> If I dump a CMS object that was created with OpenSSL's CMS tool with
>> the same certificate as the problematic one, the structure of the
>> RecipientInfos object looks like this:
>>
>>       SET {
>>         [1] {
>>           INTEGER 3
>>           ?
>
>> So the "SEQUENCE" element of the KeyAgreeRecipientInfo is not present
>> here.
>
> This is the correct behavior of an IMPLICIT tag.

many thanks for the analysis! One follow-up question:

I can also not decrypt the recipient.bin file with the "openssl smime" 
command. Do I understand it correctly then that the input file is 
neither a correct PKCS#7 file nor a correct CMS file?

--
Stephan


From marquess at openssl.com  Tue Feb  9 14:13:03 2016
From: marquess at openssl.com (Steve Marquess)
Date: Tue, 9 Feb 2016 09:13:03 -0500
Subject: [openssl-users] FIPS building scripts does NOT work for iOS >=7
In-Reply-To: <CA+i9jaqAEHdn0nYRYa4FZefqjA4zzCu8EOBH7YyvSUGXDGkpaw@mail.gmail.com>
References: <CA+i9jariK9iu5mCXUcEAiZzC2RfO7stooov5dS5AcZ6WnbH3vg@mail.gmail.com>
 <56B3D154.4020101@openssl.com> <56B3D23D.4060109@openssl.com>
 <CA+i9jaqAEHdn0nYRYa4FZefqjA4zzCu8EOBH7YyvSUGXDGkpaw@mail.gmail.com>
Message-ID: <56B9F3EF.1050405@openssl.com>

On 02/08/2016 10:11 PM, Yang Hong wrote:
> Hello Steve.
> 
> Thank you very much for your quick response.
> 
> I have tried different approaches to build FIPS module, according to the
> testing instructions of iOS 7.1 and iOS 8.1. Unfortunately I failed for
> all the FIPS packages for iOS >= 7, i.e., openssl-fips-2.0.8.tar,
> openssl-fips-2.0.9.tar, openssl-fips-2.0.10.tar, openssl-fips-2.0.11.tar. 
> 
> Apple Mac OS has been automatically updated to the new version. I failed
> to recover it to the old version.
>

Yeah, that's one of the problems with FIPS testing for OS X. We almost
always have to tweak the build process for new OS X and/or Xcode versions.

The build process we used and documented for the formal validation
testing can only be expected to work for exactly the same version of OS
X and Xcode we used. That ties with WinCE/EC as the most fragile and
challenging of FIPS platforms to build for.

> ...<snip>...
>
> I still can not solve the issues.
> 
> ***************************************************************
> 
> I have used Beyond compare 4 to check the difference between
> openssl-1.0.2f/config (or Configure) and openssl-fips-2.0.11/config (or
> Configure). I do NOT know how to modify the setenv-ios-11.sh to generate
> OpenSSL FIPS module for iOS >=8 under the new Mac OS available from
> Apple website. 
> 
> Would you shed some light on how to modify the building script for iOS
>>=8? Thank you very much.

Unfortunately I can't; I've let our Apple developer subscription lapse
and can't justify spending time on this until/if we hear from a new OS X
or iOS platform sponsor (which probably will happen eventually). Even
when I do work on such testing I usually have to call on my smarter
colleagues for assistance.

There are others who may be able to help, for instance Jeff Walton.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From Erwann.Abalea at docusign.com  Tue Feb  9 15:39:55 2016
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Tue, 9 Feb 2016 15:39:55 +0000
Subject: [openssl-users] Is the structure of this CMS object correct?
In-Reply-To: <56B9CD84.7020207@pdflib.com>
References: <56B9AE22.6000501@pdflib.com>
 <AF40454C-E74A-4359-B53C-E694AE1FC590@docusign.com>
 <56B9CD84.7020207@pdflib.com>
Message-ID: <74002D90-1437-45F0-96F3-401B27B8569A@docusign.com>

Bonjour Stephan,


Le 9 f?vr. 2016 ? 12:29, Stephan M?hlstrasser <stm at pdflib.com<mailto:stm at pdflib.com>> a ?crit :

Am 09.02.16 um 11:53 schrieb Erwann Abalea:
Bonjour,

Le 9 f?vr. 2016 ? 10:15, Stephan M?hlstrasser <stm at pdflib.com<mailto:stm at pdflib.com>
<mailto:stm at pdflib.com>> a ?crit :
...

     SET {
       [1] {
         SEQUENCE {
           INTEGER 3
           ?

This is the expression of an EXPLICIT tag.

I can match this to the following rules in RFC 5652:

RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

RecipientInfo ::= CHOICE {
      ktri KeyTransRecipientInfo,
      kari [1] KeyAgreeRecipientInfo,
      kekri [2] KEKRecipientInfo,
      pwri [3] PasswordRecipientinfo,
      ori [4] OtherRecipientInfo }

KeyAgreeRecipientInfo ::= SEQUENCE {
      version CMSVersion,  -- always set to 3
      originator [0] EXPLICIT OriginatorIdentifierOrKey,
      ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
      keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
      recipientEncryptedKeys RecipientEncryptedKeys }

See RFC5652 section 12.1.
These data types are defined in a module with IMPLICIT TAGS (it was
changed between PKCS#7v1.5 and RFC2630), so kari, kekri, pwri, and ori
elements are associated to an IMPLICIT tag.

Additional definition to read the dump.

OriginatorIdentifierOrKey ::= CHOICE {
     issuerAndSerialNumber IssuerAndSerialNumber,
     subjectKeyIdentifier [0] SubjectKeyIdentifier,
     originatorKey [1] OriginatorPublicKey }

OriginatorPublicKey ::= SEQUENCE {
     algorithm AlgorithmIdentifier,
     publicKey BIT STRING }


If I dump a CMS object that was created with OpenSSL's CMS tool with
the same certificate as the problematic one, the structure of the
RecipientInfos object looks like this:

     SET {
       [1] {
         INTEGER 3
         ?

So the "SEQUENCE" element of the KeyAgreeRecipientInfo is not present
here.

This is the correct behavior of an IMPLICIT tag.

many thanks for the analysis! One follow-up question:

I can also not decrypt the recipient.bin file with the "openssl smime" command. Do I understand it correctly then that the input file is neither a correct PKCS#7 file nor a correct CMS file?

PKCS#7 and CMS are pretty much interchangeable.
Here, your file is strictly not a PKCS#7v1.5, because in this version, RecipientInfo wasn?t a CHOICE (see RFC2315 to see PKCS#7v1.5 definitions).

How did you generate this structure? Adobe Acrobat?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160209/835a6d31/attachment.html>

From stm at pdflib.com  Tue Feb  9 17:16:03 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Tue, 9 Feb 2016 18:16:03 +0100
Subject: [openssl-users] Is the structure of this CMS object correct?
In-Reply-To: <74002D90-1437-45F0-96F3-401B27B8569A@docusign.com>
References: <56B9AE22.6000501@pdflib.com>
 <AF40454C-E74A-4359-B53C-E694AE1FC590@docusign.com>
 <56B9CD84.7020207@pdflib.com>
 <74002D90-1437-45F0-96F3-401B27B8569A@docusign.com>
Message-ID: <56BA1ED3.8060808@pdflib.com>

Am 09.02.2016 um 16:39 schrieb Erwann Abalea:
> Bonjour Stephan,
> ...

>> I can also not decrypt the recipient.bin file with the "openssl smime"
>> command. Do I understand it correctly then that the input file is
>> neither a correct PKCS#7 file nor a correct CMS file?
>
> PKCS#7 and CMS are pretty much interchangeable.
> Here, your file is strictly not a PKCS#7v1.5, because in this version,
> RecipientInfo wasn?t a CHOICE (see RFC2315 to see PKCS#7v1.5 definitions).
>
> How did you generate this structure? Adobe Acrobat?

Yes, this structure was generated with Adobe Acrobat XI (document 
encrypted with "certificate security").

-- 
Stephan

From cloud.force858 at gmail.com  Tue Feb  9 20:19:18 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Tue, 9 Feb 2016 12:19:18 -0800
Subject: [openssl-users] FIPS Object Module v2.0 and openssl security patches
Message-ID: <CAEsYawzgKtx-4M_NfOCL=tahQ=mf+4e9JOJ3S1q7pmcbGAs7=w@mail.gmail.com>

Hello everyone,

Would the FIPS Object Module v2.0 supposed to only work with the vanilla
openssl library? If I apply the security patches to the openssl library,
should the FIPS Object Module v2.0 still work without problems?

Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160209/7e887884/attachment-0001.html>

From marquess at openssl.com  Tue Feb  9 20:29:00 2016
From: marquess at openssl.com (Steve Marquess)
Date: Tue, 9 Feb 2016 15:29:00 -0500
Subject: [openssl-users] FIPS Object Module v2.0 and openssl security
 patches
In-Reply-To: <CAEsYawzgKtx-4M_NfOCL=tahQ=mf+4e9JOJ3S1q7pmcbGAs7=w@mail.gmail.com>
References: <CAEsYawzgKtx-4M_NfOCL=tahQ=mf+4e9JOJ3S1q7pmcbGAs7=w@mail.gmail.com>
Message-ID: <56BA4C0C.6030604@openssl.com>

On 02/09/2016 03:19 PM, cloud force wrote:
> Hello everyone,
> 
> Would the FIPS Object Module v2.0 supposed to only work with the vanilla
> openssl library? If I apply the security patches to the openssl library,
> should the FIPS Object Module v2.0 still work without problems?

You should patch OpenSSL whether you use it with the FIPS module or not.

>From the perspective of the FIPS 140-2 validation, stock OpenSSL is just
application code and is out of scope. So you can patch/hack OpenSSL
proper as much as you want; as long as the intact FIPS module is built
per the mandated process its FIPS-ness is unaffected by OpenSSL.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From markp at e9.com  Tue Feb  9 20:31:41 2016
From: markp at e9.com (Mark Parr)
Date: Tue, 9 Feb 2016 14:31:41 -0600
Subject: [openssl-users] OpenSSL library/development problems on OpenSUSE
	13.2
Message-ID: <001101d16378$e2a14460$a7e3cd20$@e9.com>

I have a program that for some time now under SUSE Linux Enterprise Server has worked fine.  Recently, it was moved over to an OpenSUSE 13.2 system and a problem was encountered.  The program interfaces to a 3rd party  and data is received into our program where the data block consists of some header information and AES encrypted data.  Using the OpenSSL libcrypto library we successfully interfaced to this system under SLES.  However, under OpenSUSE we consistently see the an error where the end of the decrypted data contains garbage.  I have identified where the problem happens and have a work around but in looking at the code, I don?t see why there would be a problem.

 

I have created a test program that simulates the problem.  The test program works fine under SUSE Linux Enterprise Server 11 and on a Red Hat 7.2 Enterprise Linux but fails on OpenSUSE 13.2 using different release levels of the OpenSSL libraries.  Under SLES and Red Hat, the decrypted data is cleanly returned.  Under OpenSUSE, most of the data is decrypted cleanly except for some garbage that appears toward the end of the data block.  The returned block of data is correct, then contains some garbage, and then ends correct.  The code for my sample program is below but the line causing the problem is a memcpy() where I shift the encrypted data to the front of the data block for processing.  The line in my sample program is below:

 

   // Generates Garbage

   memcpy(encbuf, encbuf+100, enclen);                 

 

If I move the encrypted data to temporary buffer before moving it to the start of the encbuf, the garbage is not generated.

 

   // This does not generate garbage

   memcpy(tmpbuf, encbuf+100, enclen);                 

   memcpy(encbuf, tmpbuf, enclen);                 

 

My sample program takes a defined buffer of clear text, encrypts it using a key and IV and then decrypts it back and displays the result.  Condensed code is as follows:

 

#include <stdio.h>      

#include <stdlib.h>     

#include <string.h>     

#include <unistd.h>     

#include <time.h>       

#include <fcntl.h>      

#include <sys/types.h>  

                        

#include <openssl/evp.h>

                        

#define EVP_DECRYPT   0 

#define EVP_ENCRYPT   1

 

char clrbuf[100000];

char encbuf[100000];

char tmpbuf[100000];

int clrlen;         

int enclen;         

 

char enckey[1024];      

unsigned char enciv[16];

 

main()

{

   int rc;

 

   // Set clear text to 50 lines of text

   sprintf(clrbuf,                                                   

         "0001this is a test this is a test this is a test this is a test\n" \

         "0002this is a test this is a test this is a test this is a test\n" \

         "0003this is a test this is a test this is a test this is a test\n" \

         // etc etc etc??????.

         "0048this is a test this is a test this is a test this is a test\n" \

         "0049this is a test this is a test this is a test this is a test\n" \

         "0050this is a test this is a test this is a test this is a test\n"  

 

   sprintf(enckey, "this is the key this is the key ");

   sprintf(enciv, "1234567890123456");

 

   // Encrypt the data and simulate a 100 byte header by returning encrypted data 100 bytes into the data block

   //

   memcpy(encbuf, "Some header stuff that will need to be removed", 46);

   rc = evp_aes256_cbc(clrbuf, strlen(clrbuf), encbuf+100, &enclen, enckey, enciv, EVP_ENCRYPT);                  

 

   // Now remove the header by shifting the encrypted data to the start of the data block and decrypt

   // This is where doing the memcpy() as coded in OpenSUSE results in garbage at the end of clrbuf

   // but everything is returned correctly in SLES and Red Hat

   //

   // This work fines on all OSes:

   //         memcpy(tmpbuf, encbuf+100, enclen);                 

   //         memcpy(encbuf, tmpbuf, enclen);                 

 

   memcpy(encbuf, encbuf+100, enclen);                 

   rc = evp_aes256_cbc(encbuf, enclen, clrbuf, &clrlen, enckey, enciv, EVP_DECRYPT);

 

   printf("Decrypt: rc=%d  EncLen=%d  ClrLen=%d\n", rc, enclen, clrlen);

   printf("Data:\n\n<\n%s\n>\n\n", clrbuf);                             
}

 

/****************************************************************************/  

                                                                                

evp_aes256_cbc(char *InBuf, int InLen, char *OutBuf, int OutLen, char *Key, char *IV, int EncryptFlag)              

{                                                                               

   EVP_CIPHER_CTX ctx;                                                          

   int padlen;                                                                  

                                                                                

   EVP_CIPHER_CTX_init(&ctx);                                                   

                                                                                

   if (! EVP_CipherInit_ex(&ctx, EVP_aes_256_cbc(), NULL, Key, IV, EncryptFlag))

      return(0);                                                                

                                                              

   if (! EVP_CipherUpdate(&ctx, OutBuf, OutLen, InBuf, InLen))

      return(0);                                              

                                                              

   if (! EVP_CipherFinal_ex(&ctx, OutBuf+(*OutLen), &padlen)) 

      return(0);                                              

                                                              

   *OutLen = *OutLen + padlen;                                

                                                              

   EVP_CIPHER_CTX_cleanup(&ctx);                              

                                                              

   return(1);                                                 

}                                                             

 

On SLES and Red Hat, final output looks like:

 

0046this is a test this is a test this is a test this is a test

0047this is a test this is a test this is a test this is a test

0048this is a test this is a test this is a test this is a test

0049this is a test this is a test this is a test this is a test

0050this is a test this is a test this is a test this is a test

 

On OpenSUSE, final output can look like:

 

0046this is a test this is a test this is a test this is a test                 

0047this is a test this is a test this is a test this is a test                 

0048this is a test this is a tes??S_?Re??       |?Zk???P?ii?w?p?8?'M??t?g{Y??E??

?n}?*???2??LS4=Q???;~??<?^??D0?T.OQ?q#?                                         

                                       xest                                     

0050this is a test this is a test this is a test this is a test                 

 

 

Any thoughts?

 

Thanks

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160209/41bbf112/attachment-0001.html>

From rsalz at akamai.com  Tue Feb  9 20:44:16 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 9 Feb 2016 20:44:16 +0000
Subject: [openssl-users] OpenSSL library/development problems on
	OpenSUSE	13.2
In-Reply-To: <001101d16378$e2a14460$a7e3cd20$@e9.com>
References: <001101d16378$e2a14460$a7e3cd20$@e9.com>
Message-ID: <32a56fdf868149849400b2505c47f88d@ustx2ex-dag1mb1.msg.corp.akamai.com>


?? // Generates Garbage
?? memcpy(encbuf, encbuf+100, enclen);???????????????? 

For overlapping copies you are supposed to use memmove.


From aerowolf at gmail.com  Tue Feb  9 20:47:40 2016
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Tue, 9 Feb 2016 12:47:40 -0800
Subject: [openssl-users] FIPS Object Module v2.0 and openssl security
 patches
In-Reply-To: <56BA4C0C.6030604@openssl.com>
References: <CAEsYawzgKtx-4M_NfOCL=tahQ=mf+4e9JOJ3S1q7pmcbGAs7=w@mail.gmail.com>
 <56BA4C0C.6030604@openssl.com>
Message-ID: <56BA506C.4050804@gmail.com>



On 2/9/2016 12:29 PM, Steve Marquess wrote:
> On 02/09/2016 03:19 PM, cloud force wrote:
>> Hello everyone,
>>
>> Would the FIPS Object Module v2.0 supposed to only work with the vanilla
>> openssl library? If I apply the security patches to the openssl library,
>> should the FIPS Object Module v2.0 still work without problems?
> You should patch OpenSSL whether you use it with the FIPS module or not.
>
> From the perspective of the FIPS 140-2 validation, stock OpenSSL is just
> application code and is out of scope. So you can patch/hack OpenSSL
> proper as much as you want; as long as the intact FIPS module is built
> per the mandated process its FIPS-ness is unaffected by OpenSSL.
>
> -Steve M.
>

...with the caveat that you cannot patch the stock OpenSSL in such a way
that any crypto operations are done by anything other than the FIPS
module, if you want to maintain the FIPS-ness of the systems you build
using it.  Formatting and processing of (including memory management
for) data that is encrypted or decrypted by the FIPS module is fair
game, which includes pretty much all of the security holes that have
happened to date in the OpenSSL library.

-Kyle H

From markp at e9.com  Tue Feb  9 20:55:09 2016
From: markp at e9.com (Mark Parr)
Date: Tue, 9 Feb 2016 14:55:09 -0600
Subject: [openssl-users] OpenSSL library/development problems
	on	OpenSUSE	13.2
In-Reply-To: <32a56fdf868149849400b2505c47f88d@ustx2ex-dag1mb1.msg.corp.akamai.com>
References: <001101d16378$e2a14460$a7e3cd20$@e9.com>
 <32a56fdf868149849400b2505c47f88d@ustx2ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <001d01d1637c$29da1e30$7d8e5a90$@e9.com>

Thanks, Rich.

That fixed things.  Obviously not familiar w/ memmove() or the memcpy() issue w/ overlapping data area.

Thanks again.

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich
Sent: Tuesday, February 09, 2016 2:44 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] OpenSSL library/development problems on OpenSUSE 13.2


   // Generates Garbage
   memcpy(encbuf, encbuf+100, enclen);                 

For overlapping copies you are supposed to use memmove.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



From marquess at openssl.com  Wed Feb 10 12:44:49 2016
From: marquess at openssl.com (Steve Marquess)
Date: Wed, 10 Feb 2016 07:44:49 -0500
Subject: [openssl-users] FIPS 140-2 X9.31 RNG transition finally complete
Message-ID: <56BB30C1.5010408@openssl.com>

Some good news for a change, but if you neither know nor care what FIPS
120-2 is you're not missing anything.

The final "X9.31 RNG transition" change letter update for the third
validation (#2398) of the OpenSSL FIPS Object Module v2.0 trilogy
(#1747/#2398/#2747) was approved yesterday. This approval means that
OpenSSL FIPS module is now past any risk of de-listing to "not to be
used" status as has happened to so many other validations recently[*].
All 120+ platforms listed across those three validations for multiple
module revisions are valid.

Approval of this validation took a lot longer than the essentially
identical submissions for the other two validations done at the same
time; presumably because the CMVP decided to roll up multiple pending
change letters for the #2398 validation. This recently approved
submission includes the addition of some new platforms at revision
2.0.12 along with the RNG transition wordsmithing.

Thanks again to DataGravity for making this "RNG transition" compliance
possible by paying the test lab fees.

-Steve M.

[*] The de-listed validations can be found at
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-historical.htm

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc


From axel.luttgens at skynet.be  Wed Feb 10 16:27:24 2016
From: axel.luttgens at skynet.be (Axel Luttgens)
Date: Wed, 10 Feb 2016 17:27:24 +0100
Subject: [openssl-users] Compilation with both options "no-comp" and "zlib"
	fails
Message-ID: <373486B0-2051-4C4F-BBFF-18AA562ED690@skynet.be>

Hello,

According to this thread:

	http://openssl.6102.n7.nabble.com/config-and-no-zlib-td42924.html

it would make sense to execute Configure with both "no-comp" and "zlib" options.

If I understand correctly, this would avoid to have the openssl library to use compression for SSL/TLS by default while still having compression available for other purposes (for example, the command line tools).

However, using both options leads to a failure here (please see details for openssl-1.0.2f at the end of this message).

So, first of all, does it really make sense to configure with both options? Or am I just plain wrong with my understanding of, for example, the INSTALL file, the comments at the beginning of Configure, the reasonings in above thread?

Otherwise, perhaps am I missing an obvious step in my configure/build attempts?

TIA,
Axel


Configuring for darwin64-x86_64-cc
   no-comp         [option]   OPENSSL_NO_COMP (skip dir)
   no-gmp          [default]  OPENSSL_NO_GMP (skip dir)
   no-jpake        [experimental] OPENSSL_NO_JPAKE (skip dir)
   no-krb5         [krb5-flavor not specified] OPENSSL_NO_KRB5
   no-libunbound   [experimental] OPENSSL_NO_LIBUNBOUND (skip dir)
   no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
   no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
   no-rfc3779      [default]  OPENSSL_NO_RFC3779 (skip dir)
   no-sctp         [default]  OPENSSL_NO_SCTP (skip dir)
   no-shared       [default] 
   no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE (skip dir)
   no-ssl2         [option]   OPENSSL_NO_SSL2 (skip dir)
   no-store        [experimental] OPENSSL_NO_STORE (skip dir)
   no-unit-test    [default]  OPENSSL_NO_UNIT_TEST (skip dir)
   no-zlib-dynamic [default] 
[?]
cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM   -c -o cms_cd.o cms_cd.c
cms_cd.c:131:20: warning: implicit declaration of function 'BIO_f_zlib' is invalid in C99
     [-Wimplicit-function-declaration]
   return BIO_new(BIO_f_zlib());
                  ^
[?]
cc -DMONOLITH -I.. -I../include  -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM   -c -o enc.o enc.c
enc.c:468:28: warning: implicit declaration of function 'BIO_f_zlib' is invalid in C99
     [-Wimplicit-function-declaration]
       if ((bzl = BIO_new(BIO_f_zlib())) == NULL)
                          ^
[?]
Undefined symbols for architecture x86_64:
 "_BIO_f_zlib", referenced from:
     _enc_main in enc.o
     _cms_CompressedData_init_bio in libcrypto.a(cms_cd.o)
ld: symbol(s) not found for architecture x86_64
[?]

And indeed, file openssl.conf is built with:
	# define OPENSSL_NO_COMP 
Moreover, both files cms_cd.c and enc.c have:
	#ifndef OPENSSL_NO_COMP
	# include <openssl/comp.h>
	#endif
so that the definition of BIO_f_zlib() can?t be found.
And it appears that "comp" is removed from the SDIRS variable.

Playing very dangerously, that is:
	manually adding comp to SDIRS
	replacing
		#ifndef OPENSSL_NO_COMP
	with
		#if defined ZLIB || not defined OPENSSL_NO_COMP
it seems that make succeeds.
Dangerously, because I just don?t know what I am doing, what side-effects I am very likely introducing. ;-)


From cloud.force858 at gmail.com  Wed Feb 10 19:41:44 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Wed, 10 Feb 2016 11:41:44 -0800
Subject: [openssl-users] How do I verify the FIPS mode
Message-ID: <CAEsYawwjpuf+CLS_D7exsH526hduEBC1hqJj7Fhu=XVAKqN8aw@mail.gmail.com>

Hi everyone,

I built and installed the FIPS capable OpenSSL lib on my system, and I was
wondering what's the easiest way to find out whether my OpenSSL is really
FIPS capable or not.

e.g. is there any way to run some openssl commands to find out, such as
"openssl ciphers -v", and what cipher suite should definitely not show up
in FIPS mode.

Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160210/292924de/attachment.html>

From lesley.j.kimmel at gmail.com  Wed Feb 10 19:49:49 2016
From: lesley.j.kimmel at gmail.com (Lesley Kimmel)
Date: Wed, 10 Feb 2016 13:49:49 -0600
Subject: [openssl-users] How do I verify the FIPS mode
In-Reply-To: <CAEsYawwjpuf+CLS_D7exsH526hduEBC1hqJj7Fhu=XVAKqN8aw@mail.gmail.com>
References: <CAEsYawwjpuf+CLS_D7exsH526hduEBC1hqJj7Fhu=XVAKqN8aw@mail.gmail.com>
Message-ID: <CAAQu=7TU1=3TXhHM6enkGdubGNM4D7bSUj1efUCo-QKYbtkRnQ@mail.gmail.com>

I think you can run 'OPENSSL_FIPS=1 openssl ciphers -v'. I believe that if,
FIPS is compiled in properly you should get output. Otherwise an error
should occur.

On Wed, Feb 10, 2016 at 1:41 PM, cloud force <cloud.force858 at gmail.com>
wrote:

> Hi everyone,
>
> I built and installed the FIPS capable OpenSSL lib on my system, and I was
> wondering what's the easiest way to find out whether my OpenSSL is really
> FIPS capable or not.
>
> e.g. is there any way to run some openssl commands to find out, such as
> "openssl ciphers -v", and what cipher suite should definitely not show up
> in FIPS mode.
>
> Thanks,
> Rich
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160210/c675ac72/attachment-0001.html>

From lesley.j.kimmel at gmail.com  Wed Feb 10 19:56:56 2016
From: lesley.j.kimmel at gmail.com (Lesley Kimmel)
Date: Wed, 10 Feb 2016 13:56:56 -0600
Subject: [openssl-users] How do I verify the FIPS mode
In-Reply-To: <CAAQu=7TU1=3TXhHM6enkGdubGNM4D7bSUj1efUCo-QKYbtkRnQ@mail.gmail.com>
References: <CAEsYawwjpuf+CLS_D7exsH526hduEBC1hqJj7Fhu=XVAKqN8aw@mail.gmail.com>
 <CAAQu=7TU1=3TXhHM6enkGdubGNM4D7bSUj1efUCo-QKYbtkRnQ@mail.gmail.com>
Message-ID: <CAAQu=7StfvfQ+O5B3asyBiHpew6GqiTA3iJE19pxfV_kRU-K0A@mail.gmail.com>

Actuall, I may have steered you wrong. It appears that OPENSSL_FIPS may
have no affect against a non-FIPS enabled OpenSSL. According to some posts
you can do 'OPENSSL_FIPS=1 openssl md5' which should return an error as md5
is not an enabled cipher in FIPS mode.

On Wed, Feb 10, 2016 at 1:49 PM, Lesley Kimmel <lesley.j.kimmel at gmail.com>
wrote:

> I think you can run 'OPENSSL_FIPS=1 openssl ciphers -v'. I believe that
> if, FIPS is compiled in properly you should get output. Otherwise an error
> should occur.
>
> On Wed, Feb 10, 2016 at 1:41 PM, cloud force <cloud.force858 at gmail.com>
> wrote:
>
>> Hi everyone,
>>
>> I built and installed the FIPS capable OpenSSL lib on my system, and I
>> was wondering what's the easiest way to find out whether my OpenSSL is
>> really FIPS capable or not.
>>
>> e.g. is there any way to run some openssl commands to find out, such as
>> "openssl ciphers -v", and what cipher suite should definitely not show up
>> in FIPS mode.
>>
>> Thanks,
>> Rich
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160210/237c71ea/attachment.html>

From marquess at openssl.com  Wed Feb 10 20:02:42 2016
From: marquess at openssl.com (Steve Marquess)
Date: Wed, 10 Feb 2016 15:02:42 -0500
Subject: [openssl-users] How do I verify the FIPS mode
In-Reply-To: <CAAQu=7StfvfQ+O5B3asyBiHpew6GqiTA3iJE19pxfV_kRU-K0A@mail.gmail.com>
References: <CAEsYawwjpuf+CLS_D7exsH526hduEBC1hqJj7Fhu=XVAKqN8aw@mail.gmail.com>
 <CAAQu=7TU1=3TXhHM6enkGdubGNM4D7bSUj1efUCo-QKYbtkRnQ@mail.gmail.com>
 <CAAQu=7StfvfQ+O5B3asyBiHpew6GqiTA3iJE19pxfV_kRU-K0A@mail.gmail.com>
Message-ID: <56BB9762.3010801@openssl.com>

On 02/10/2016 02:56 PM, Lesley Kimmel wrote:
> Actuall, I may have steered you wrong. It appears that OPENSSL_FIPS may
> have no affect against a non-FIPS enabled OpenSSL. According to some
> posts you can do 'OPENSSL_FIPS=1 openssl md5' which should return an
> error as md5 is not an enabled cipher in FIPS mode.

It depends on the version. Recent versions of OpenSSL will give a "FIPS
mode not supported" error for

  env OPENSSL_FIPS=1 openssl md5 ...

Whereas that command for a properly built FIPS-enabled OpenSSL will give
a "not permitted in FIPS mode" error.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From cloud.force858 at gmail.com  Wed Feb 10 20:23:41 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Wed, 10 Feb 2016 12:23:41 -0800
Subject: [openssl-users] Configure and config in openssl source folder
Message-ID: <CAEsYawxBWLsq_h1DhFaUVpWAAs5pbgQw0He3M7YhH0YVneWX=Q@mail.gmail.com>

Hi Everyone,

I am trying to build FIPS capable OpenSSL as an Ubuntu 12.04 package.

>From the OpenSSL doc it mentioned we need to do ./config fips in order to
build openssl under tips mode. I tried that and it worked well.

Now I am building the OpenSSL FIPS as a Ubuntu package. I noticed the
package manager meta script use the Configure (instead of config script)
under the openssl source folder.

I was wondering should I also do "Configure fips", if I use the Configure
script to configure the source tree? What's the relationship between config
and Configure scripts?

Or should I just run ./config fips first and then let the package manager
script to run Configure?

Thanks.
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160210/25889c7c/attachment.html>

From cloud.force858 at gmail.com  Wed Feb 10 20:27:50 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Wed, 10 Feb 2016 12:27:50 -0800
Subject: [openssl-users] How do I verify the FIPS mode
In-Reply-To: <56BB9762.3010801@openssl.com>
References: <CAEsYawwjpuf+CLS_D7exsH526hduEBC1hqJj7Fhu=XVAKqN8aw@mail.gmail.com>
 <CAAQu=7TU1=3TXhHM6enkGdubGNM4D7bSUj1efUCo-QKYbtkRnQ@mail.gmail.com>
 <CAAQu=7StfvfQ+O5B3asyBiHpew6GqiTA3iJE19pxfV_kRU-K0A@mail.gmail.com>
 <56BB9762.3010801@openssl.com>
Message-ID: <CAEsYawxwP7e3GvTpLRU5taSjNFq-X7G_ji0ui1ApGFOiUNengw@mail.gmail.com>

Thanks Lesley and Steve for the answers.

Rich


On Wed, Feb 10, 2016 at 12:02 PM, Steve Marquess <marquess at openssl.com>
wrote:

> On 02/10/2016 02:56 PM, Lesley Kimmel wrote:
> > Actuall, I may have steered you wrong. It appears that OPENSSL_FIPS may
> > have no affect against a non-FIPS enabled OpenSSL. According to some
> > posts you can do 'OPENSSL_FIPS=1 openssl md5' which should return an
> > error as md5 is not an enabled cipher in FIPS mode.
>
> It depends on the version. Recent versions of OpenSSL will give a "FIPS
> mode not supported" error for
>
>   env OPENSSL_FIPS=1 openssl md5 ...
>
> Whereas that command for a properly built FIPS-enabled OpenSSL will give
> a "not permitted in FIPS mode" error.
>
> -Steve M.
>
> --
> Steve Marquess
> OpenSSL Validation Services, Inc.
> 1829 Mount Ephraim Road
> Adamstown, MD  21710
> USA
> +1 877 673 6775 s/b
> +1 301 874 2571 direct
> marquess at openssl.com
> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160210/719904e0/attachment.html>

From aerowolf at gmail.com  Wed Feb 10 20:37:34 2016
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Wed, 10 Feb 2016 12:37:34 -0800
Subject: [openssl-users] Configure and config in openssl source folder
In-Reply-To: <CAEsYawxBWLsq_h1DhFaUVpWAAs5pbgQw0He3M7YhH0YVneWX=Q@mail.gmail.com>
References: <CAEsYawxBWLsq_h1DhFaUVpWAAs5pbgQw0He3M7YhH0YVneWX=Q@mail.gmail.com>
Message-ID: <56BB9F8E.1030406@gmail.com>

My understanding is, you must follow the steps given in the Security
Guide *exactly*, with no deviation, in order to produce a validated
binary of the FIPS canister.  In other words, you *must not* try to use
Configure when attempting to build the FIPS canister because it does not
match the steps given in the Security Guide.

Once you have the FIPS canister, you can build a version of OpenSSL that
uses it pretty much indiscriminately (as long as you ensure that all the
things that fipsld does actually happen when it comes time to link).

(I apologize if my knowledge is out of date, I haven't been following
the FIPS development for a couple of years.)

-Kyle H

On 2/10/2016 12:23 PM, cloud force wrote:
> Hi Everyone,
>
> I am trying to build FIPS capable OpenSSL as an Ubuntu 12.04 package.
>
> From the OpenSSL doc it mentioned we need to do ./config fips in order
> to build openssl under tips mode. I tried that and it worked well.
>
> Now I am building the OpenSSL FIPS as a Ubuntu package. I noticed the
> package manager meta script use the Configure (instead of config
> script) under the openssl source folder.
>
> I was wondering should I also do "Configure fips", if I use the
> Configure script to configure the source tree? What's the relationship
> between config and Configure scripts?
>
> Or should I just run ./config fips first and then let the package
> manager script to run Configure?
>
> Thanks.
> Rich
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160210/61e0a43d/attachment.html>

From cloud.force858 at gmail.com  Wed Feb 10 20:47:11 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Wed, 10 Feb 2016 12:47:11 -0800
Subject: [openssl-users] Configure and config in openssl source folder
In-Reply-To: <56BB9F8E.1030406@gmail.com>
References: <CAEsYawxBWLsq_h1DhFaUVpWAAs5pbgQw0He3M7YhH0YVneWX=Q@mail.gmail.com>
 <56BB9F8E.1030406@gmail.com>
Message-ID: <CAEsYawxn1TeuB0xJCEnnxKW2QtaC21T-WdWvm14TbCXnWKz-Bw@mail.gmail.com>

Thanks Kyle.

Yes, for building FIPS canister I did exactly the same thing as it
mentioned in the security policy doc.

My questions above were mainly regarding building the OpenSSL library
itself with the fipscanister.o modules.

In the doc it said we should just do "*config fips*", and since the Ubuntu
OpenSSL packaging script does not run *config* script and it run *Configure*
script instead, I was wondering should I still run "./config tips" before
run the Configure script, or should I just run "Configure fips" instead?

Thanks,
Rich

On Wed, Feb 10, 2016 at 12:37 PM, Kyle Hamilton <aerowolf at gmail.com> wrote:

> My understanding is, you must follow the steps given in the Security Guide
> *exactly*, with no deviation, in order to produce a validated binary of the
> FIPS canister.  In other words, you *must not* try to use Configure when
> attempting to build the FIPS canister because it does not match the steps
> given in the Security Guide.
>
> Once you have the FIPS canister, you can build a version of OpenSSL that
> uses it pretty much indiscriminately (as long as you ensure that all the
> things that fipsld does actually happen when it comes time to link).
>
> (I apologize if my knowledge is out of date, I haven't been following the
> FIPS development for a couple of years.)
>
> -Kyle H
>
>
> On 2/10/2016 12:23 PM, cloud force wrote:
>
> Hi Everyone,
>
> I am trying to build FIPS capable OpenSSL as an Ubuntu 12.04 package.
>
> From the OpenSSL doc it mentioned we need to do ./config fips in order to
> build openssl under tips mode. I tried that and it worked well.
>
> Now I am building the OpenSSL FIPS as a Ubuntu package. I noticed the
> package manager meta script use the Configure (instead of config script)
> under the openssl source folder.
>
> I was wondering should I also do "Configure fips", if I use the Configure
> script to configure the source tree? What's the relationship between config
> and Configure scripts?
>
> Or should I just run ./config fips first and then let the package manager
> script to run Configure?
>
> Thanks.
> Rich
>
>
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160210/13089135/attachment-0001.html>

From marquess at openssl.com  Wed Feb 10 20:47:46 2016
From: marquess at openssl.com (Steve Marquess)
Date: Wed, 10 Feb 2016 15:47:46 -0500
Subject: [openssl-users] Configure and config in openssl source folder
In-Reply-To: <CAEsYawxBWLsq_h1DhFaUVpWAAs5pbgQw0He3M7YhH0YVneWX=Q@mail.gmail.com>
References: <CAEsYawxBWLsq_h1DhFaUVpWAAs5pbgQw0He3M7YhH0YVneWX=Q@mail.gmail.com>
Message-ID: <56BBA1F2.8000208@openssl.com>

On 02/10/2016 03:23 PM, cloud force wrote:
> Hi Everyone,
> 
> I am trying to build FIPS capable OpenSSL as an Ubuntu 12.04 package.
> 
> From the OpenSSL doc it mentioned we need to do ./config fips in order
> to build openssl under tips mode. I tried that and it worked well.
> 
> Now I am building the OpenSSL FIPS as a Ubuntu package. I noticed the
> package manager meta script use the Configure (instead of config script)
> under the openssl source folder.
> 
> I was wondering should I also do "Configure fips", if I use the
> Configure script to configure the source tree? What's the relationship
> between config and Configure scripts?
> 
> Or should I just run ./config fips first and then let the package
> manager script to run Configure?

Well, if you're building OpenSSL proper, as a "FIPS capable" OpenSSL,
then you can do what you want.

Building of the FIPS module beforehand that the "FIPS capable" needs to
reference is a different matter. The sad fact is that the mandated build
procedure for creating ("installing") the OpenSSL FIPS module conflicts
rather violently with typical industry software engineering practice.

That process mandates, as an metaphysical/ideological "pixie dust"
requirement, that the specifically documented commands must be used
exactly as given. It is not acceptable to do something logically and
technically equivalent, such as "Configure" instead of "config". Many
users want to force that rigidly mandated process into an existing
in-house process, with ugly results.

Since you're required to start with the official tarball, and aren't
allowed to change the contents of the tarball, not even a teeny tiny
little bit, there is no point in dumping the tarball contents into your
local source code management/version control system. My recommendation
is that one time only you conduct a solemn candlelit ceremony in which
the build is manually performed in profound and reverential observance
of the mandated procedure. Then take the resulting fipscanister.* and
fips_premain.* files and version control those from then on out. Don't
try to continually rebuild the FIPS module from source that cannot be
modified anyway.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From aerowolf at gmail.com  Wed Feb 10 20:56:14 2016
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Wed, 10 Feb 2016 12:56:14 -0800
Subject: [openssl-users] Configure and config in openssl source folder
In-Reply-To: <56BBA1F2.8000208@openssl.com>
References: <CAEsYawxBWLsq_h1DhFaUVpWAAs5pbgQw0He3M7YhH0YVneWX=Q@mail.gmail.com>
 <56BBA1F2.8000208@openssl.com>
Message-ID: <56BBA3EE.2030003@gmail.com>



On 2/10/2016 12:47 PM, Steve Marquess wrote:
> Since you're required to start with the official tarball, and aren't
> allowed to change the contents of the tarball, not even a teeny tiny
> little bit, there is no point in dumping the tarball contents into
> your local source code management/version control system. My
> recommendation is that one time only you conduct a solemn candlelit
> ceremony in which the build is manually performed in profound and
> reverential observance of the mandated procedure. Then take the
> resulting fipscanister.* and fips_premain.* files and version control
> those from then on out. Don't try to continually rebuild the FIPS
> module from source that cannot be modified anyway. -Steve M. 

And once you build them, make sure to get SHA-256 and SHA-512 digests of
them, print them out on a piece of paper along with an "I,
______________________, do certify that I built the OpenSSL FIPS version
_______ distribution in accordance with its Security Policy under FIPS
Certificate #_____ and generated these files with the following digests,
on ____________." statement.  Then sign the statement.  Everything
related to FIPS is related to being able to document it, if you want to
sell to a government agency... and if you don't want to sell to a
government agency, there's no real reason for you to bother with it.

-Kyle H

From aerowolf at gmail.com  Wed Feb 10 20:57:48 2016
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Wed, 10 Feb 2016 12:57:48 -0800
Subject: [openssl-users] Configure and config in openssl source folder
In-Reply-To: <CAEsYawxn1TeuB0xJCEnnxKW2QtaC21T-WdWvm14TbCXnWKz-Bw@mail.gmail.com>
References: <CAEsYawxBWLsq_h1DhFaUVpWAAs5pbgQw0He3M7YhH0YVneWX=Q@mail.gmail.com>
 <56BB9F8E.1030406@gmail.com>
 <CAEsYawxn1TeuB0xJCEnnxKW2QtaC21T-WdWvm14TbCXnWKz-Bw@mail.gmail.com>
Message-ID: <56BBA44C.4030405@gmail.com>

./config autodetects the platform and such, passing various parameters
to Configure. So, after you've built the canister, you can do as you want.

So, to do this, figure out from ./config what parameters it passes to
Configure in the presence of the 'fips' argument, then modify the
command line the packaging script invokes accordingly.

-Kyle H

On 2/10/2016 12:47 PM, cloud force wrote:
> Thanks Kyle.
>
> Yes, for building FIPS canister I did exactly the same thing as it
> mentioned in the security policy doc.
>
> My questions above were mainly regarding building the OpenSSL library
> itself with the fipscanister.o modules.
>
> In the doc it said we should just do "/*config fips*/", and since the
> Ubuntu OpenSSL packaging script does not run /*config*/ script and it
> run /*Configure*/ script instead, I was wondering should I still run
> "./config tips" before run the Configure script, or should I just run
> "Configure fips" instead?
>
> Thanks,
> Rich
>
> On Wed, Feb 10, 2016 at 12:37 PM, Kyle Hamilton <aerowolf at gmail.com
> <mailto:aerowolf at gmail.com>> wrote:
>
>     My understanding is, you must follow the steps given in the
>     Security Guide *exactly*, with no deviation, in order to produce a
>     validated binary of the FIPS canister.  In other words, you *must
>     not* try to use Configure when attempting to build the FIPS
>     canister because it does not match the steps given in the Security
>     Guide.
>
>     Once you have the FIPS canister, you can build a version of
>     OpenSSL that uses it pretty much indiscriminately (as long as you
>     ensure that all the things that fipsld does actually happen when
>     it comes time to link).
>
>     (I apologize if my knowledge is out of date, I haven't been
>     following the FIPS development for a couple of years.)
>
>     -Kyle H
>
>
>     On 2/10/2016 12:23 PM, cloud force wrote:
>>     Hi Everyone,
>>
>>     I am trying to build FIPS capable OpenSSL as an Ubuntu 12.04 package.
>>
>>     From the OpenSSL doc it mentioned we need to do ./config fips in
>>     order to build openssl under tips mode. I tried that and it
>>     worked well.
>>
>>     Now I am building the OpenSSL FIPS as a Ubuntu package. I noticed
>>     the package manager meta script use the Configure (instead of
>>     config script) under the openssl source folder.
>>
>>     I was wondering should I also do "Configure fips", if I use the
>>     Configure script to configure the source tree? What's the
>>     relationship between config and Configure scripts?
>>
>>     Or should I just run ./config fips first and then let the package
>>     manager script to run Configure?
>>
>>     Thanks.
>>     Rich
>>
>>
>>
>
>
>     --
>     openssl-users mailing list
>     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160210/768e6294/attachment.html>

From cloud.force858 at gmail.com  Wed Feb 10 21:08:35 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Wed, 10 Feb 2016 13:08:35 -0800
Subject: [openssl-users] Configure and config in openssl source folder
In-Reply-To: <56BBA44C.4030405@gmail.com>
References: <CAEsYawxBWLsq_h1DhFaUVpWAAs5pbgQw0He3M7YhH0YVneWX=Q@mail.gmail.com>
 <56BB9F8E.1030406@gmail.com>
 <CAEsYawxn1TeuB0xJCEnnxKW2QtaC21T-WdWvm14TbCXnWKz-Bw@mail.gmail.com>
 <56BBA44C.4030405@gmail.com>
Message-ID: <CAEsYawxwZ1L=OCgpYH9EtmEfxZo+_JMo++xQiA_d4_H5pZ0OkA@mail.gmail.com>

Thanks Kyle. So basically I can just use Configure for building FIPS
capable OpenSSL library, as long as I pass the right parameters to it right?

Also if I use Configure, do I need to explicitly turn off the non-FIPS
approved algorithms, like passing "no-rc4" as a parameter to the Configure
command?

I understand it's not necessary do that if I use config script.

Thanks,
Rich


On Wed, Feb 10, 2016 at 12:57 PM, Kyle Hamilton <aerowolf at gmail.com> wrote:

> ./config autodetects the platform and such, passing various parameters to
> Configure. So, after you've built the canister, you can do as you want.
>
> So, to do this, figure out from ./config what parameters it passes to
> Configure in the presence of the 'fips' argument, then modify the command
> line the packaging script invokes accordingly.
>
> -Kyle H
>
>
> On 2/10/2016 12:47 PM, cloud force wrote:
>
> Thanks Kyle.
>
> Yes, for building FIPS canister I did exactly the same thing as it
> mentioned in the security policy doc.
>
> My questions above were mainly regarding building the OpenSSL library
> itself with the fipscanister.o modules.
>
> In the doc it said we should just do "*config fips*", and since the
> Ubuntu OpenSSL packaging script does not run *config* script and it run
> *Configure* script instead, I was wondering should I still run "./config
> tips" before run the Configure script, or should I just run "Configure
> fips" instead?
>
> Thanks,
> Rich
>
> On Wed, Feb 10, 2016 at 12:37 PM, Kyle Hamilton <aerowolf at gmail.com>
> wrote:
>
>> My understanding is, you must follow the steps given in the Security
>> Guide *exactly*, with no deviation, in order to produce a validated binary
>> of the FIPS canister.  In other words, you *must not* try to use Configure
>> when attempting to build the FIPS canister because it does not match the
>> steps given in the Security Guide.
>>
>> Once you have the FIPS canister, you can build a version of OpenSSL that
>> uses it pretty much indiscriminately (as long as you ensure that all the
>> things that fipsld does actually happen when it comes time to link).
>>
>> (I apologize if my knowledge is out of date, I haven't been following the
>> FIPS development for a couple of years.)
>>
>> -Kyle H
>>
>>
>> On 2/10/2016 12:23 PM, cloud force wrote:
>>
>> Hi Everyone,
>>
>> I am trying to build FIPS capable OpenSSL as an Ubuntu 12.04 package.
>>
>> From the OpenSSL doc it mentioned we need to do ./config fips in order to
>> build openssl under tips mode. I tried that and it worked well.
>>
>> Now I am building the OpenSSL FIPS as a Ubuntu package. I noticed the
>> package manager meta script use the Configure (instead of config script)
>> under the openssl source folder.
>>
>> I was wondering should I also do "Configure fips", if I use the Configure
>> script to configure the source tree? What's the relationship between config
>> and Configure scripts?
>>
>> Or should I just run ./config fips first and then let the package manager
>> script to run Configure?
>>
>> Thanks.
>> Rich
>>
>>
>>
>>
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160210/7565a46e/attachment-0001.html>

From aerowolf at gmail.com  Wed Feb 10 21:18:15 2016
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Wed, 10 Feb 2016 13:18:15 -0800
Subject: [openssl-users] Configure and config in openssl source folder
In-Reply-To: <CAEsYawxwZ1L=OCgpYH9EtmEfxZo+_JMo++xQiA_d4_H5pZ0OkA@mail.gmail.com>
References: <CAEsYawxBWLsq_h1DhFaUVpWAAs5pbgQw0He3M7YhH0YVneWX=Q@mail.gmail.com>
 <56BB9F8E.1030406@gmail.com>
 <CAEsYawxn1TeuB0xJCEnnxKW2QtaC21T-WdWvm14TbCXnWKz-Bw@mail.gmail.com>
 <56BBA44C.4030405@gmail.com>
 <CAEsYawxwZ1L=OCgpYH9EtmEfxZo+_JMo++xQiA_d4_H5pZ0OkA@mail.gmail.com>
Message-ID: <56BBA917.9040109@gmail.com>

The FIPS module will explicitly deny any attempt to use unapproved
algorithms when it's in FIPS mode.  It's only when it's not in FIPS mode
that you might be able to use the unapproved algorithms, because the
generated library will use the original code and not the FIPS canister.

So, if you want to disable the use of rc4 even when it's not in FIPS
mode, pass no-rc4.  FIPS mode will disable it as a matter of course.

-Kyle H

On 2/10/2016 1:08 PM, cloud force wrote:
> Thanks Kyle. So basically I can just use Configure for building FIPS
> capable OpenSSL library, as long as I pass the right parameters to it
> right?
>
> Also if I use Configure, do I need to explicitly turn off the non-FIPS
> approved algorithms, like passing "no-rc4" as a parameter to the
> Configure command?
>
> I understand it's not necessary do that if I use config script.
>
> Thanks,
> Rich
>
>
> On Wed, Feb 10, 2016 at 12:57 PM, Kyle Hamilton <aerowolf at gmail.com
> <mailto:aerowolf at gmail.com>> wrote:
>
>     ./config autodetects the platform and such, passing various
>     parameters to Configure. So, after you've built the canister, you
>     can do as you want.
>
>     So, to do this, figure out from ./config what parameters it passes
>     to Configure in the presence of the 'fips' argument, then modify
>     the command line the packaging script invokes accordingly.
>
>     -Kyle H
>
>
>     On 2/10/2016 12:47 PM, cloud force wrote:
>>     Thanks Kyle.
>>
>>     Yes, for building FIPS canister I did exactly the same thing as
>>     it mentioned in the security policy doc.
>>
>>     My questions above were mainly regarding building the OpenSSL
>>     library itself with the fipscanister.o modules.
>>
>>     In the doc it said we should just do "/*config fips*/", and since
>>     the Ubuntu OpenSSL packaging script does not run /*config*/
>>     script and it run /*Configure*/ script instead, I was wondering
>>     should I still run "./config tips" before run the Configure
>>     script, or should I just run "Configure fips" instead?
>>
>>     Thanks,
>>     Rich
>>
>>     On Wed, Feb 10, 2016 at 12:37 PM, Kyle Hamilton
>>     <aerowolf at gmail.com <mailto:aerowolf at gmail.com>> wrote:
>>
>>         My understanding is, you must follow the steps given in the
>>         Security Guide *exactly*, with no deviation, in order to
>>         produce a validated binary of the FIPS canister.  In other
>>         words, you *must not* try to use Configure when attempting to
>>         build the FIPS canister because it does not match the steps
>>         given in the Security Guide.
>>
>>         Once you have the FIPS canister, you can build a version of
>>         OpenSSL that uses it pretty much indiscriminately (as long as
>>         you ensure that all the things that fipsld does actually
>>         happen when it comes time to link).
>>
>>         (I apologize if my knowledge is out of date, I haven't been
>>         following the FIPS development for a couple of years.)
>>
>>         -Kyle H
>>
>>
>>         On 2/10/2016 12:23 PM, cloud force wrote:
>>>         Hi Everyone,
>>>
>>>         I am trying to build FIPS capable OpenSSL as an Ubuntu 12.04
>>>         package.
>>>
>>>         From the OpenSSL doc it mentioned we need to do ./config
>>>         fips in order to build openssl under tips mode. I tried that
>>>         and it worked well.
>>>
>>>         Now I am building the OpenSSL FIPS as a Ubuntu package. I
>>>         noticed the package manager meta script use the Configure
>>>         (instead of config script) under the openssl source folder.
>>>
>>>         I was wondering should I also do "Configure fips", if I use
>>>         the Configure script to configure the source tree? What's
>>>         the relationship between config and Configure scripts?
>>>
>>>         Or should I just run ./config fips first and then let the
>>>         package manager script to run Configure?
>>>
>>>         Thanks.
>>>         Rich
>>>
>>>
>>>
>>
>>
>>         --
>>         openssl-users mailing list
>>         To unsubscribe:
>>         https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>>
>>
>
>
>     --
>     openssl-users mailing list
>     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160210/4f57abb0/attachment.html>

From cloud.force858 at gmail.com  Wed Feb 10 21:46:28 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Wed, 10 Feb 2016 13:46:28 -0800
Subject: [openssl-users] no version information available error
Message-ID: <CAEsYawxZLuPk42hyX6tmmdNyi33xLjpREsEdaVhqZAdz18Qvsw@mail.gmail.com>

Hi Everyone,

I installed the FIPS capable openssl library (which was built by myself) on
my Ubuntu linux box.

For some reason, I keep running into the following errors whenever I run
ssh related command:

ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information
available (required by ssh)

The same error happens when I ran openssl command such as the following:

linux-fips at ubuntu:/usr/local/ssl/lib$ openssl ciphers -v | wc -l
openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information
available (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information
available (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information
available (required by /lib/x86_64-linux-gnu/libssl.so.1.0.0)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information
available (required by /lib/x86_64-linux-gnu/libssl.so.1.0.0)


Not sure what I did wrong as I followed the same steps mentioned in the
OpenSSL FIPS doc to build both FIPS canister.o and openssl lib.

Any suggestion are greatly appreciated.

Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160210/20b51074/attachment.html>

From alex_chen at filemaker.com  Thu Feb 11 01:03:02 2016
From: alex_chen at filemaker.com (Alex Chen)
Date: Wed, 10 Feb 2016 17:03:02 -0800
Subject: [openssl-users] Errors in building 1.0.2f
Message-ID: <D2E11ABC.1544F%alex_chen@filemaker.com>

I tried to build openssl 1.0.2f on MacOS with the following configuration
options "Configure no-bf" but it failed because there is no header file
blowfish.h in include/openssl directory.
This does not happen in 1.0.2d where include/openssl/blowfish.h is a
symbolic link to ../../crypto/bf/blowfish.h.
This is true for idea, cast, jpake, camellia, too.

What has changed?

Alex 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160210/f2a58c93/attachment.html>

From cloud.force858 at gmail.com  Thu Feb 11 01:34:49 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Wed, 10 Feb 2016 17:34:49 -0800
Subject: [openssl-users] OpenSSL lib build errors
Message-ID: <CAEsYawwu9SPWgvLpFyziBe2p7Bxm=GDwnaNpEmFnmhgJqsZnbA@mail.gmail.com>

Hi All:

I tried to build a FIPS capable OpenSSL Ubuntu package (using the Ubuntu
12.04 debian meta file).

The Ubuntu package uses Configure for configuring the source tree with the
following parameters:



*ARCH_CONFARGS := enable-ec_nistp_64_gcc_128CONFARGS  = --prefix=/usr
--openssldir=/usr/lib/ssl --libdir=lib/$(DEB_HOST_MULTIARCH) fips no-idea
no-mdc2 no-rc5 zlib  enable-tlsext no-ssl2 $(ARCH_CONFARGS)*


I ran into the following errors near the end of the build:






























*shlib_target=; if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \
    shlib_target="linux-shared"; \    elif [ -n "libcrypto" ]; then \
FIPSLD_CC="gcc"; CC=/usr/local/ssl/fips-2.0/bin/fipsld; export CC
FIPSLD_CC; \    fi; \    LIBRARIES="-L.. -lssl  -L.. -lcrypto" ; \    make
-f ../Makefile.shared -e \        APPNAME=openssl OBJECTS="openssl.o
verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o
errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o
ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o
s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o
nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o
rand.o engine.o ocsp.o prime.o ts.o srp.o" \        LIBDEPS=" $LIBRARIES
-ldl -lz" \        link_app.${shlib_target}make[3]: Entering directory
`/home/precise/amd64/openssl/openssl-1.0.1/apps'speed.o: In function
`speed_main':/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1219:
undefined reference to
`private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1220:
undefined reference to
`private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1221:
undefined reference to
`private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1224:
undefined reference to
`private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1225:
undefined reference to
`private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1226:
undefined reference to
`private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1229:
undefined reference to
`private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1230:
undefined reference to
`private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1231:
undefined reference to
`private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1237:
undefined reference to
`private_SEED_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1240:
undefined reference to
`private_RC4_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1243:
undefined reference to
`private_RC2_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1249:
undefined reference to
`private_BF_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1252:
undefined reference to `private_CAST_set_key'collect2: ld returned 1 exit
status*


Any suggestions and possible solutions are greatly appreciated.

-- 
Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160210/a70543cf/attachment-0001.html>

From noloader at gmail.com  Thu Feb 11 02:03:35 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 10 Feb 2016 21:03:35 -0500
Subject: [openssl-users] Working around servers requiring SSL 2/3 record
	layer, and using TLS 1.2?
Message-ID: <CAH8yC8nG8xAmLqgNs861vLUX=KurF4=WYHbc1GKfcf6O42wyLQ@mail.gmail.com>

How do we work around a server that seems to require SSLv23_method?
That is, they accept the SSLv3 record layer and TLS 1.2 protocol, but
they reject record layers and protocols that only specify TLS 1.2?

As far as I know, there are no constants for TLS 1.0 and 1.1, so we
can't extend this in clients:

    const SSL_METHOD* method = SSLv23_method();
    ctx = SSL_CTX_new(method);
    ...

    const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 |
SSL_OP_NO_COMPRESSION;
    SSL_CTX_set_options(ctx, flags);

Thanks in advance.

From rsalz at akamai.com  Thu Feb 11 02:08:47 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 11 Feb 2016 02:08:47 +0000
Subject: [openssl-users] Errors in building 1.0.2f
In-Reply-To: <D2E11ABC.1544F%alex_chen@filemaker.com>
References: <D2E11ABC.1544F%alex_chen@filemaker.com>
Message-ID: <db98fd0673d54e059dd836eda49fe2ac@ustx2ex-dag1mb1.msg.corp.akamai.com>

Do an initial config to get the symlinks copied, then do your 'real' config.
This will be fixed next time :)

From openssl-users at dukhovni.org  Thu Feb 11 02:14:10 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 10 Feb 2016 21:14:10 -0500
Subject: [openssl-users] Working around servers requiring SSL 2/3 record
	layer, and using TLS 1.2?
In-Reply-To: <CAH8yC8nG8xAmLqgNs861vLUX=KurF4=WYHbc1GKfcf6O42wyLQ@mail.gmail.com>
References: <CAH8yC8nG8xAmLqgNs861vLUX=KurF4=WYHbc1GKfcf6O42wyLQ@mail.gmail.com>
Message-ID: <05476437-34E6-4E38-8A0C-BF73F01F17AB@dukhovni.org>


> On Feb 10, 2016, at 9:03 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> 
> How do we work around a server that seems to require SSLv23_method?

Don't think of this as a work-around.  You SHOULD use the version-flexible
method (renamed from SSLv23_method() to TLS_method() in master).

You should then disable unwanted protocols that are too weak.  In master
use the new min/max version controls and avoid the SSL_OP_NO_<some_version>
macros.  In 1.0.x, use the macros to disable some contiguous set of protocol
versions starting at SSLv2.

-- 
	Viktor.


From noloader at gmail.com  Thu Feb 11 02:28:58 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 10 Feb 2016 21:28:58 -0500
Subject: [openssl-users] Working around servers requiring SSL 2/3 record
 layer, and using TLS 1.2?
In-Reply-To: <05476437-34E6-4E38-8A0C-BF73F01F17AB@dukhovni.org>
References: <CAH8yC8nG8xAmLqgNs861vLUX=KurF4=WYHbc1GKfcf6O42wyLQ@mail.gmail.com>
 <05476437-34E6-4E38-8A0C-BF73F01F17AB@dukhovni.org>
Message-ID: <CAH8yC8ktNb3LWS0n+zFWK3gucaTAuZf-8GVh9wQoLyEJLWy7Zw@mail.gmail.com>

>> How do we work around a server that seems to require SSLv23_method?
>
> Don't think of this as a work-around.  You SHOULD use the version-flexible
> method (renamed from SSLv23_method() to TLS_method() in master).
>
> You should then disable unwanted protocols that are too weak.  In master
> use the new min/max version controls and avoid the SSL_OP_NO_<some_version>
> macros.  In 1.0.x, use the macros to disable some contiguous set of protocol
> versions starting at SSLv2.
>
Thanks Viktor. It sounds like Master is in good working order. Is
there anything that can be done with OpenSSL 1.0.2?

Jeff

From openssl-users at dukhovni.org  Thu Feb 11 02:54:39 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 10 Feb 2016 21:54:39 -0500
Subject: [openssl-users] Working around servers requiring SSL 2/3 record
	layer, and using TLS 1.2?
In-Reply-To: <CAH8yC8ktNb3LWS0n+zFWK3gucaTAuZf-8GVh9wQoLyEJLWy7Zw@mail.gmail.com>
References: <CAH8yC8nG8xAmLqgNs861vLUX=KurF4=WYHbc1GKfcf6O42wyLQ@mail.gmail.com>
 <05476437-34E6-4E38-8A0C-BF73F01F17AB@dukhovni.org>
 <CAH8yC8ktNb3LWS0n+zFWK3gucaTAuZf-8GVh9wQoLyEJLWy7Zw@mail.gmail.com>
Message-ID: <5CE89493-C3AA-4529-8525-EA9F2E0B55F0@dukhovni.org>


> On Feb 10, 2016, at 9:28 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> 
>> You should then disable unwanted protocols that are too weak.  In master
>> use the new min/max version controls and avoid the SSL_OP_NO_<some_version>
>> macros.  In 1.0.x, use the macros to disable some contiguous set of protocol
>> versions starting at SSLv2.
>> 
> Thanks Viktor. It sounds like Master is in good working order. Is
> there anything that can be done with OpenSSL 1.0.2?

Use SSLv23_method() (or SSLv23_client_method() if you prefer) and disable
unwanted protocols via the SSL_OP_NO_<someversion> macros, making sure to
disable each of SSLv2, SSLv3, ... up to some last protocol version you
want to disable without leaving any gaps.  That is don't make the mistake
of disabling SSLv2 and TLSv1 while leaving SSLv3 enabled which creates
"holes" in the range of supported protocols (in this case TLSv1 is a "hole"
between SSLv3 and TLSv1.1).

-- 
	Viktor.


From kurt at roeckx.be  Thu Feb 11 07:20:06 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Thu, 11 Feb 2016 08:20:06 +0100
Subject: [openssl-users] Working around servers requiring SSL 2/3 record
 layer, and using TLS 1.2?
In-Reply-To: <CAH8yC8nG8xAmLqgNs861vLUX=KurF4=WYHbc1GKfcf6O42wyLQ@mail.gmail.com>
References: <CAH8yC8nG8xAmLqgNs861vLUX=KurF4=WYHbc1GKfcf6O42wyLQ@mail.gmail.com>
Message-ID: <20160211072006.GA26506@roeckx.be>

On Wed, Feb 10, 2016 at 09:03:35PM -0500, Jeffrey Walton wrote:
> As far as I know, there are no constants for TLS 1.0 and 1.1, so we
> can't extend this in clients:
> 
>     const SSL_METHOD* method = SSLv23_method();
>     ctx = SSL_CTX_new(method);
>     ...
> 
>     const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 |
> SSL_OP_NO_COMPRESSION;
>     SSL_CTX_set_options(ctx, flags);

The constant for TLS 1.0, 1.1 and 1.2 exist too.  But I don't
think they're all documented in the 1.0.2 branch.

# define SSL_OP_NO_SSLv2                                 0x01000000L
# define SSL_OP_NO_SSLv3                                 0x02000000L
# define SSL_OP_NO_TLSv1                                 0x04000000L
# define SSL_OP_NO_TLSv1_2                               0x08000000L
# define SSL_OP_NO_TLSv1_1                               0x10000000L



Kurt


From matt at openssl.org  Thu Feb 11 09:07:12 2016
From: matt at openssl.org (Matt Caswell)
Date: Thu, 11 Feb 2016 09:07:12 +0000
Subject: [openssl-users] Errors in building 1.0.2f
In-Reply-To: <D2E11ABC.1544F%alex_chen@filemaker.com>
References: <D2E11ABC.1544F%alex_chen@filemaker.com>
Message-ID: <56BC4F40.8010907@openssl.org>



On 11/02/16 01:03, Alex Chen wrote:
> I tried to build openssl 1.0.2f on MacOS with the following
> configuration options "Configure no-bf" but it failed because there is
> no header file blowfish.h in include/openssl directory.
> This does not happen in 1.0.2d where include/openssl/blowfish.h is a
> symbolic link to ../../crypto/bf/blowfish.h.
> This is true for idea, cast, jpake, camellia, too.
> 
> What has changed?

Configure should have instructed you to run "make depend", i.e. mine says:

*** Because of configuration changes, you MUST do the following before
*** building:

	make depend

Did you run it?

Matt

From lloydkl.tech at gmail.com  Thu Feb 11 11:35:35 2016
From: lloydkl.tech at gmail.com (Lloyd)
Date: Thu, 11 Feb 2016 17:05:35 +0530
Subject: [openssl-users] Win32 - PEM_read_PrivateKey crash
Message-ID: <CAA10ZTovJojKCkJGJp7RAh6aDemYZ=D_q0avKsyC8PWm=mfmSg@mail.gmail.com>

Hi,

I have downloaded prebuilt version of openssl for windows. I am running on
Windows 7 64bit,  Using Visual Studio 2010, generating 32bit binary.

When I run a simple application which calling "PEM_read_PrivateKey" it
crashes with error "OPENSSL_Uplink(505D6000,08): no OPENSSL_Applink"

What could be the reason for this? Any hint is greatly appreciated.

Thanks,
  Lloyd

The following is my code -

int main() {
   EVP_PKEY *privkey;
   FILE *fp;
   RSA *rsakey;

   OpenSSL_add_all_algorithms();

   privkey = EVP_PKEY_new();
   fp = fopen ("G:\\temp\\mykey.pem", "r"); //File exists and it opens
   PEM_read_PrivateKey( fp, &privkey, NULL, NULL); //CRASH

   fclose(fp);

    ...

}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160211/c782bccf/attachment.html>

From lloydkl.tech at gmail.com  Thu Feb 11 11:53:04 2016
From: lloydkl.tech at gmail.com (Lloyd)
Date: Thu, 11 Feb 2016 17:23:04 +0530
Subject: [openssl-users] Win32 - PEM_read_PrivateKey crash
In-Reply-To: <CAA10ZTovJojKCkJGJp7RAh6aDemYZ=D_q0avKsyC8PWm=mfmSg@mail.gmail.com>
References: <CAA10ZTovJojKCkJGJp7RAh6aDemYZ=D_q0avKsyC8PWm=mfmSg@mail.gmail.com>
Message-ID: <CAA10ZTokKYbqc6PFt1YXT7M14Zxf+HBjtUvUsxOEKBjNivuYhQ@mail.gmail.com>

Thanks, The problem is solved when compiled and linked with "applink.c"

On Thu, Feb 11, 2016 at 5:05 PM, Lloyd <lloydkl.tech at gmail.com> wrote:

> Hi,
>
> I have downloaded prebuilt version of openssl for windows. I am running on
> Windows 7 64bit,  Using Visual Studio 2010, generating 32bit binary.
>
> When I run a simple application which calling "PEM_read_PrivateKey" it
> crashes with error "OPENSSL_Uplink(505D6000,08): no OPENSSL_Applink"
>
> What could be the reason for this? Any hint is greatly appreciated.
>
> Thanks,
>   Lloyd
>
> The following is my code -
>
> int main() {
>    EVP_PKEY *privkey;
>    FILE *fp;
>    RSA *rsakey;
>
>    OpenSSL_add_all_algorithms();
>
>    privkey = EVP_PKEY_new();
>    fp = fopen ("G:\\temp\\mykey.pem", "r"); //File exists and it opens
>    PEM_read_PrivateKey( fp, &privkey, NULL, NULL); //CRASH
>
>    fclose(fp);
>
>     ...
>
> }
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160211/9881b2c3/attachment-0001.html>

From jb-openssl at wisemo.com  Thu Feb 11 15:50:39 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 11 Feb 2016 16:50:39 +0100
Subject: [openssl-users] no version information available error
In-Reply-To: <CAEsYawxZLuPk42hyX6tmmdNyi33xLjpREsEdaVhqZAdz18Qvsw@mail.gmail.com>
References: <CAEsYawxZLuPk42hyX6tmmdNyi33xLjpREsEdaVhqZAdz18Qvsw@mail.gmail.com>
Message-ID: <56BCADCF.2030109@wisemo.com>

On 10/02/2016 22:46, cloud force wrote:
> Hi Everyone,
>
> I installed the FIPS capable openssl library (which was built by 
> myself) on my Ubuntu linux box.
>
> For some reason, I keep running into the following errors whenever I 
> run ssh related command:
>
>
>     ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version
>     information available (required by ssh)
>
>
> The same error happens when I ran openssl command such as the following:
>
> linux-fips at ubuntu:/usr/local/ssl/lib$ openssl ciphers -v | wc -l
> openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version 
> information available (required by openssl)
> openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version 
> information available (required by openssl)
> openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version 
> information available (required by /lib/x86_64-linux-gnu/libssl.so.1.0.0)
> openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version 
> information available (required by /lib/x86_64-linux-gnu/libssl.so.1.0.0)
>
The Debian-family (includes Ubuntu) standard OpenSSL shared
libraries is built in a special way to include "version tags"
in the resulting .so files, and all the openssl-needing
binaries in Debian/Ubuntu/etc. produce the error message
above if you install copies of those libraries without those
extra "version tags".

There are two alternative ways to solve this:

A) Build your FIPS-cabable OpenSSL (not the FIPScanister)
   with all the extra steps and patches in the Ubuntu OpenSSL
   source package (.dsc etc.), just adding the FIPS canister.
    Note that some of the patches in the source package are
   backports of the security fixes included in the latest
   OpenSSL versions, you'll probably have to figure out the
   details yourself (unless Kurt Roeckz posts a recipe
   somewhere).

B) Patch your FIPS-capable OpenSSL makefile (not the
   FIPScanister makefile) to use a different .so-version, such
   as .so.1.0.2 .  Then your private openssl build will not be
   used by the prepackaged software while software explicitly
   compiled against your locally build OpenSSL will not
   accidentally pick up the standard non-FIPS OpenSSL.



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From alex_chen at filemaker.com  Thu Feb 11 19:09:01 2016
From: alex_chen at filemaker.com (Alex Chen)
Date: Thu, 11 Feb 2016 11:09:01 -0800
Subject: [openssl-users] Errors in building 1.0.2f
In-Reply-To: <56BC4F40.8010907@openssl.org>
References: <D2E11ABC.1544F%alex_chen@filemaker.com>
 <56BC4F40.8010907@openssl.org>
Message-ID: <D2E21BD8.154B6%alex_chen@filemaker.com>

Yes, I did.  It still failed.  I manually made the symbolic links and the
compilation completed without problem.
But this should have been taken care of by Configure, should it not?

Alex 





On 2/11/16, 1:07 AM, "openssl-users on behalf of Matt Caswell"
<openssl-users-bounces at openssl.org on behalf of matt at openssl.org> wrote:

>
>
>On 11/02/16 01:03, Alex Chen wrote:
>> I tried to build openssl 1.0.2f on MacOS with the following
>> configuration options "Configure no-bf" but it failed because there is
>> no header file blowfish.h in include/openssl directory.
>> This does not happen in 1.0.2d where include/openssl/blowfish.h is a
>> symbolic link to ../../crypto/bf/blowfish.h.
>> This is true for idea, cast, jpake, camellia, too.
>> 
>> What has changed?
>
>Configure should have instructed you to run "make depend", i.e. mine says:
>
>*** Because of configuration changes, you MUST do the following before
>*** building:
>
>	make depend
>
>Did you run it?
>
>Matt
>-- 
>openssl-users mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



From Suman.Patro-TRN at lntebg.com  Thu Feb 11 18:31:18 2016
From: Suman.Patro-TRN at lntebg.com (R-D intern)
Date: Thu, 11 Feb 2016 11:31:18 -0700 (MST)
Subject: [openssl-users] regarding SSL security
Message-ID: <1455215478519-63504.post@n7.nabble.com>

Hello ,
        I am a Masters student and currently working on a project related to
security. I have certain queries regarding ssl security. It would be of 
great use to me if some of my queries get clarified. The following is listed
as:
1. How do I prove that ECC 256 bit key is equivalently strong to RSA 2048
bit key?
2. What all types of threats could be used for testing the above question?
3.The paper has listed Openssl library  can be used for enabling ssl
security , certificate generation and management. I have created an ECC
certificate that works fine  but such a certificate shows "Invalid digital
signature "message on the certificate. The elliptic curve used for
certificate generation is one amongst the named curves supported by Openssl
and recommended by NIST-suite B.  How can that be resolved?
4.The Openssl library has certificate verification method that checks the
certificate validity w.r.t validity period, certificate chain depth, etc,
then why is a Certificate Revocation List or an OCSP  needed, in a sense if
the verification is already done, then why should invalid certificates be
revoked and verification be done on the basis of CRL?
5. Is there any other approach for client authentication in SSL other than
certificates approach?
6. Is ssl security suitable enough for securing connections to server in
control and monitoring systems? How can client authentication be done for
such systems using SSL protocol?
7.If CRLs are to be used, then how will the CA know about the private key
being compromised so that it can revoke the certificate considering it being
forged?
   Thanks and regards,
    Suman Patro




--
View this message in context: http://openssl.6102.n7.nabble.com/regarding-SSL-security-tp63504.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From cloud.force858 at gmail.com  Thu Feb 11 19:28:48 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Thu, 11 Feb 2016 11:28:48 -0800
Subject: [openssl-users] OpenSSL lib build errors
In-Reply-To: <CAEsYawwu9SPWgvLpFyziBe2p7Bxm=GDwnaNpEmFnmhgJqsZnbA@mail.gmail.com>
References: <CAEsYawwu9SPWgvLpFyziBe2p7Bxm=GDwnaNpEmFnmhgJqsZnbA@mail.gmail.com>
Message-ID: <CAEsYawyjBhN2A09fc4wAeV8c6p0hRcz8c4P3CBWzMyF==SO8zA@mail.gmail.com>

I checked the libcrypto.so which was built right before this, and was able
to find these symbols. Still not sure why these errors showed up.

Any suggestions and possible solutions are greatly appreciated.

On Wed, Feb 10, 2016 at 5:34 PM, cloud force <cloud.force858 at gmail.com>
wrote:

> Hi All:
>
> I tried to build a FIPS capable OpenSSL Ubuntu package (using the Ubuntu
> 12.04 debian meta file).
>
> The Ubuntu package uses Configure for configuring the source tree with the
> following parameters:
>
>
>
> *ARCH_CONFARGS := enable-ec_nistp_64_gcc_128CONFARGS  = --prefix=/usr
> --openssldir=/usr/lib/ssl --libdir=lib/$(DEB_HOST_MULTIARCH) fips no-idea
> no-mdc2 no-rc5 zlib  enable-tlsext no-ssl2 $(ARCH_CONFARGS)*
>
>
> I ran into the following errors near the end of the build:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *shlib_target=; if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \
>     shlib_target="linux-shared"; \    elif [ -n "libcrypto" ]; then \
> FIPSLD_CC="gcc"; CC=/usr/local/ssl/fips-2.0/bin/fipsld; export CC
> FIPSLD_CC; \    fi; \    LIBRARIES="-L.. -lssl  -L.. -lcrypto" ; \    make
> -f ../Makefile.shared -e \        APPNAME=openssl OBJECTS="openssl.o
> verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o
> errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o
> ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o
> s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o
> nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o
> rand.o engine.o ocsp.o prime.o ts.o srp.o" \        LIBDEPS=" $LIBRARIES
> -ldl -lz" \        link_app.${shlib_target}make[3]: Entering directory
> `/home/precise/amd64/openssl/openssl-1.0.1/apps'speed.o: In function
> `speed_main':/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1219:
> undefined reference to
> `private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1220:
> undefined reference to
> `private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1221:
> undefined reference to
> `private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1224:
> undefined reference to
> `private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1225:
> undefined reference to
> `private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1226:
> undefined reference to
> `private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1229:
> undefined reference to
> `private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1230:
> undefined reference to
> `private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1231:
> undefined reference to
> `private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1237:
> undefined reference to
> `private_SEED_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1240:
> undefined reference to
> `private_RC4_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1243:
> undefined reference to
> `private_RC2_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1249:
> undefined reference to
> `private_BF_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1252:
> undefined reference to `private_CAST_set_key'collect2: ld returned 1 exit
> status*
>
>
> Any suggestions and possible solutions are greatly appreciated.
>
> --
> Thanks,
> Rich
>
>


-- 
Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160211/da77a3d1/attachment.html>

From valerie.fenwick at oracle.com  Thu Feb 11 19:49:13 2016
From: valerie.fenwick at oracle.com (Valerie Anne Fenwick)
Date: Thu, 11 Feb 2016 11:49:13 -0800
Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from
 OpenSSL 1.1 - seeking feedback
In-Reply-To: <5652935D.1030002@wisemo.com>
References: <CAGZjfUYJLnD7Qo28r_iQgnUYAsZay_Ftp8KEG=7MPY5pY+248A@mail.gmail.com>
 <CAH8yC8=oF83TrNm52QjfggEesxwS12yK+rL1tsKG2nMVi6Lkxg@mail.gmail.com>
 <CAGZjfUbHOuOWx-XeCxQRYzADKtX1DDnYsufyMA9YCwYS_ADAFQ@mail.gmail.com>
 <1770293.ATZhSyddb0@pintsize.usersys.redhat.com>
 <564CB19B.6050605@akamai.com> <D27221F6.229F0%uri@ll.mit.edu>
 <3CB9005A-76B1-4F42-BA72-DE46AB82C27D@akamai.com>
 <5652935D.1030002@wisemo.com>
Message-ID: <56BCE5B9.5010705@oracle.com>


Hi Jakob -

On 11/22/15 08:17 PM, Jakob Bohm wrote:
> On 20/11/2015 23:26, Short, Todd wrote:
>> While I am all for simplicity, I also think that removing functionality is a ?bad idea?.
>>
>> To reduce the support burden, deprecate the ciphers:
>> 1. Under support, indicate that these ciphers will no longer receive fixes.
>> 2. Remove any assembly implementations
>> 3. Disable them by default.
>>
>> I suggest following the 80/20 rule (sometimes the 95/5 rule):
>>
>> Those ?who care? (the minority) about the ciphers can re-enable them and rebuild the
>> library.
>> Those ?who don?t care? (the majority) about the ciphers, should get the functionality
>> that most people care about, basically SSL/TLS connectivity.
>>
> You all seem to misunderstand the fundamental release engineering
> issues involved.
>
> 1. Very shortly after you release OpenSSL 1.1.0, many
>    distributions and pointy haired managers will blindly
>    switch to the new version as the only version available.
>     This will not at all await the "end of support" for
>    OpenSSL 1.0.x .  So breaking changes will cause harm much
>    sooner than you claim.

As one of those pointy haired managers, I have to say that
this scenario is simply not possible with the ABI incompatibility
between OpenSSL 1.0.2 and OpenSSL 1.1.0 - applications will
have to be updated, too. (unless I'm completely misunderstanding
something). So, most likely we're looking at a universe where
both will coexist for awhile (that seems to match up with
OpenSSL's support plans as well).

Think of this like when OpenSSL went from 0.9.8 to 1.0.0.
Both co-existed for quite awhile.

>
> 2. Because of the need to easily keep up with routine security
>    updates to OpenSSL, it is highly impractical to maintain
>    locally reconfigured build scripts and patches, though some
>    of us have no choice (and are still struggling with the
>    massively huge and disorganized code reformatting in the
>    middle of the 1.0.1 security update series).

I do not envy this work, but we're talking about a security
toolkit - it should not stay in the past. It's, quite simply,
dangerous to do so.

>
> 3. When distributions upgrade OpenSSL, many applications that
>    have not been actively and deliberately ported to the new
>    OpenSSL version will be blindly recompiled with the new
>    versions, and if they break, random developers with no
>    understanding of either the application, OpenSSL or even
>    security will do ill-informed rushed patches to try to undo
>    the breakage you caused.

Sadly, that happens when any toolkit updates.

>
> 4. OpenSSL is THE primary crypto library for the FOSS universe.
>    You may be volunteers, but you are working on a massively
>    important piece of software, not some random optional library.

Yes, but they are still allowed to change for the better.

GnuTLS did this as well, between their 2.x release and 3.x.
There is precendence. It is not pain free, but it is what
we all need to do to make a better and safter internet.

Bad choices made now will haunt us for another 10+ years.

Valerie

>
> 5. In these times of panic and marshal law, it is essential
>    that the key resources for open source crypto remain
>    unrestrained by the politics of any single country, such that
>    the sudden outlawing of crypto in the current home of the
>    maintainers does not prevent the project from being continued
>    by a different team in a different country.  This makes it
>    essential not to tie any legal or technical aspect to a single
>    place, country, political alliance, company or person.  It is
>    also critical to avoid any and all legal ties to the
>    historically most problematic jurisdictions, such as the US.
>     So don't pay people through any US bank accounts, foundations
>    or legal entities.  Don't keep any technical assets (such as
>    repositories or mail archives) in one country.  Don't create
>    legal documents that tie any license permissions to any
>    specific country or organization.
>     These same considerations exclude any of the US based
>    libraries and forks from being relevant outside that country.
>
> 6. All of this requires a lot more caution and a lot less
>    arrogance from the people making decisions about changes
>    in the OpenSSL library and project.
>
>
> Enjoy
>
> Jakob


Valerie
-- 
Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva
Solaris Cryptographic & Key Management Technologies, Manager
Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.

From jb-openssl at wisemo.com  Thu Feb 11 20:20:14 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 11 Feb 2016 21:20:14 +0100
Subject: [openssl-users] regarding SSL security
In-Reply-To: <1455215478519-63504.post@n7.nabble.com>
References: <1455215478519-63504.post@n7.nabble.com>
Message-ID: <56BCECFE.4040902@wisemo.com>

On 11/02/2016 19:31, R-D intern wrote:
> Hello ,
>          I am a Masters student and currently working on a project related to
> security. I have certain queries regarding ssl security. It would be of
> great use to me if some of my queries get clarified. The following is listed
> as:
> 1. How do I prove that ECC 256 bit key is equivalently strong to RSA 2048
> bit key?
This is so hard that noone has done it yet.  Experienced experts
have made estimates based on the best known theoretical attack
against each and comparing the (extreme/impossibly large) amount
of computer power to break them.

For example one of the relevant attacks against 2048 bit RSA is
to use the best known algorithm to factor a 2048 bit number known
to be the multiple of two large primes.  This requires a certain
number of fundamental computer resources (CPU cycles and memory
bytes).

A similar consideration can be made for the best algorithm to find
the secret multiplier (private key) from the ECC 256-p point
published as the public key.

Next adjust both numbers by how much those algorithms are going
to improve over the time the private key has to be kept secret
(for SSL/TLS session signatures with ephemeral DH session key
exchange), this is just the time from certificate issuance/key
generation until the certificate expires.  But for some other
uses this is the time until signed digital documents (such as
deeds of ownership to a house) are no longer important enough
to protect against forgery, usually many decades.

Especially that last step is very much a matter of opinion,
and thus different researchers disagree.  For instance
Certicom, the original main proponents of ECC crypto,
published tables that claimed a much larger RSA key would be
needed to get the same security as 256 bit ECC.

> 2. What all types of threats could be used for testing the above question?
See above.
> 3.The paper has listed Openssl library  can be used for enabling ssl
> security , certificate generation and management. I have created an ECC
> certificate that works fine  but such a certificate shows "Invalid digital
> signature "message on the certificate. The elliptic curve used for
> certificate generation is one amongst the named curves supported by Openssl
> and recommended by NIST-suite B.  How can that be resolved?
Either you did something wrong when generating the certificate,
or you are testing with a software tool that doesn't support
that particular form of ECC signature.  Note that ECC keys and
signatures can refer to the chosen curve in one of two ways
("named curve" or explicit curve description), OpenSSL only
accepts the "named curve" form as input.


> 4.The Openssl library has certificate verification method that checks the
> certificate validity w.r.t validity period, certificate chain depth, etc,
> then why is a Certificate Revocation List or an OCSP  needed, in a sense if
> the verification is already done, then why should invalid certificates be
> revoked and verification be done on the basis of CRL?
The revocation check is to check if something bad happened after
the certificate was generated and signed by the issuing CA.

Typical examples include:

- The legitimate certificate holder had her private key stolen
  ("compromised") or at least found herself in a situation where
  she could no longer be sure if someone has an illegetimate copy.

- The facts stated in the certificate are no longer true, for
  instance, if the certificate states that the certificate holder
  is a resident of city X, but has since moved to city Y.

- The CA that issued the certificate finds out it did so in
  error, e.g. it accidentally issued it to the wrong person, or it
  issued an SHA-1 based certificate after the official deadline
  for ceasing all such issuance (This has happened sevaral times
  in the last 40 days).

> 5. Is there any other approach for client authentication in SSL other than
> certificates approach?
Yes, the full SSL protocol also supports various password based
methods, but they are considered less secure for most purposes.
> 6. Is ssl security suitable enough for securing connections to server in
> control and monitoring systems? How can client authentication be done for
> such systems using SSL protocol?
Depends how important security of that communication is, and how
strong the minimum SSL settings are configured.

For example if the control connection is for a large industrial
plant of a type where deliberately issuing the wrong control
commands can generate a major disaster (Bopal sized), then as
long as people are living next to the factory or working inside
the factory, it might not be secure to allow such control to be
done from outside the factory, no matter how secure the
connection is (the problem is that the person pushing the buttons
isn't risking his own life too).

But as the potential risks get smaller, the level of security
of the connection can be weighed against the dangers that would
result from compromising the connection.  Assessing this
involves not only the technical dangers (how much damage could
someone do), but also how much money and effort someone might
spend to cause that damage deliberately.

At one extreme, the process and its location/ownership may be
such that a major superpower may dedicate some of its top
secret experts to break in.  At the other extreme, the
circumstances may make it reasonable to assume no one will
spend more than 1M$ to break into the connection (if the
price of breaking in is less than that, there is a real
risk that ordinary criminals might do it using stolen
tools).



> 7.If CRLs are to be used, then how will the CA know about the private key
> being compromised so that it can revoke the certificate considering it being
> forged?
>     Thanks and regards,
>      Suman Patro
>
As previously mentioned, the most common ways a certificate
gets added to a revocation list are:

1. The person/company to whom it was issued calls the CA and
   says "someone may have stolen my key, please revoke it".
    The standard contracts from CAs specify where to call and
   how quickly they have to add it to the public revocation
   systems.

2. The person/company in whose name it was issued calls the
   CA and says "Whomever you issued that certificate to isn't
   me, revoke it at once!".  Again there are are standard
   procedures to do this.

3. A professional review/audit of issued certificates
   discovers something should not have been issued and
   contacts the CA.  Many CAs have internal teams doing such
   reviews on a regular basis, and publicly trusted CAs are
   subject to independent audits at least once a year.

4. A relevant event (death, bankruptcy, etc.) is announced in
   an official medium (such as a national government gazette),
   causing the CA to revoke the certificate in accordance with
   specific contract clauses regarding said type of event.

5. A relevant event (such as a person getting fired from
   their job) is reliably communicated to a CA that issued
   a certificate no longer valid then (for instance a
   certificate identifying said person as being an authorized
   employee).

All in all, these are the same situations in which credit
cards or a door keys might be revoked (mechanical door keys
are revoked by changing the locks).

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160211/08e0e296/attachment.html>

From jb-openssl at wisemo.com  Thu Feb 11 20:34:48 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 11 Feb 2016 21:34:48 +0100
Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from
 OpenSSL 1.1 - seeking feedback
In-Reply-To: <56BCE5B9.5010705@oracle.com>
References: <CAGZjfUYJLnD7Qo28r_iQgnUYAsZay_Ftp8KEG=7MPY5pY+248A@mail.gmail.com>
 <CAH8yC8=oF83TrNm52QjfggEesxwS12yK+rL1tsKG2nMVi6Lkxg@mail.gmail.com>
 <CAGZjfUbHOuOWx-XeCxQRYzADKtX1DDnYsufyMA9YCwYS_ADAFQ@mail.gmail.com>
 <1770293.ATZhSyddb0@pintsize.usersys.redhat.com>
 <564CB19B.6050605@akamai.com> <D27221F6.229F0%uri@ll.mit.edu>
 <3CB9005A-76B1-4F42-BA72-DE46AB82C27D@akamai.com>
 <5652935D.1030002@wisemo.com> <56BCE5B9.5010705@oracle.com>
Message-ID: <56BCF068.9020802@wisemo.com>

Someone picked up an old dead thread, but I'll make some brief
responses.

On 11/02/2016 20:49, Valerie Anne Fenwick wrote:
>
> Hi Jakob -
>
> On 11/22/15 08:17 PM, Jakob Bohm wrote:
>> On 20/11/2015 23:26, Short, Todd wrote:
>>> While I am all for simplicity, I also think that removing 
>>> functionality is a ?bad idea?.
>>>
>>> To reduce the support burden, deprecate the ciphers:
>>> 1. Under support, indicate that these ciphers will no longer receive 
>>> fixes.
>>> 2. Remove any assembly implementations
>>> 3. Disable them by default.
>>>
>>> I suggest following the 80/20 rule (sometimes the 95/5 rule):
>>>
>>> Those ?who care? (the minority) about the ciphers can re-enable them 
>>> and rebuild the
>>> library.
>>> Those ?who don?t care? (the majority) about the ciphers, should get 
>>> the functionality
>>> that most people care about, basically SSL/TLS connectivity.
>>>
>> You all seem to misunderstand the fundamental release engineering
>> issues involved.
>>
>> 1. Very shortly after you release OpenSSL 1.1.0, many
>>    distributions and pointy haired managers will blindly
>>    switch to the new version as the only version available.
>>     This will not at all await the "end of support" for
>>    OpenSSL 1.0.x .  So breaking changes will cause harm much
>>    sooner than you claim.
>
> As one of those pointy haired managers, I have to say that
> this scenario is simply not possible with the ABI incompatibility
> between OpenSSL 1.0.2 and OpenSSL 1.1.0 - applications will
> have to be updated, too. (unless I'm completely misunderstanding
> something). So, most likely we're looking at a universe where
> both will coexist for awhile (that seems to match up with
> OpenSSL's support plans as well).
This shows you are not pointy-haired enough to fit this
example.
>
> Think of this like when OpenSSL went from 0.9.8 to 1.0.0.
> Both co-existed for quite awhile.
>
However the differences between 0.9.8 and 1.0.0 were
much smaller than the upcoming differences between
1.0.x and 1.1.x .

They are basically removing lots of functionality
for very little gain.

>>
>> 2. Because of the need to easily keep up with routine security
>>    updates to OpenSSL, it is highly impractical to maintain
>>    locally reconfigured build scripts and patches, though some
>>    of us have no choice (and are still struggling with the
>>    massively huge and disorganized code reformatting in the
>>    middle of the 1.0.1 security update series).
>
> I do not envy this work, but we're talking about a security
> toolkit - it should not stay in the past. It's, quite simply,
> dangerous to do so.
>
But it should not do things that leave past "customers"
unprotected because they can no longer use the current
but incompatible toolkit.  Because that in and of itself
is also very dangerous.

>>
>> 3. When distributions upgrade OpenSSL, many applications that
>>    have not been actively and deliberately ported to the new
>>    OpenSSL version will be blindly recompiled with the new
>>    versions, and if they break, random developers with no
>>    understanding of either the application, OpenSSL or even
>>    security will do ill-informed rushed patches to try to undo
>>    the breakage you caused.
>
> Sadly, that happens when any toolkit updates.
Yes, but some updates are more likely to cause such
harm than others.  Thisis the whole reason the entire
computer industryis so keen on backwards compatibility.

>
>>
>> 4. OpenSSL is THE primary crypto library for the FOSS universe.
>>    You may be volunteers, but you are working on a massively
>>    important piece of software, not some random optional library.
>
> Yes, but they are still allowed to change for the better.
>
> GnuTLS did this as well, between their 2.x release and 3.x.
> There is precendence. It is not pain free, but it is what
> we all need to do to make a better and safter internet.
>
> Bad choices made now will haunt us for another 10+ years.
>
I was arguing that they *are* making bad choices now.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160211/db348834/attachment-0001.html>

From michel.sales at free.fr  Thu Feb 11 22:16:10 2016
From: michel.sales at free.fr (Michel)
Date: Thu, 11 Feb 2016 23:16:10 +0100
Subject: [openssl-users] PKCS12 command ignore -cipher option silently
Message-ID: <009801d16519$d00b14f0$70213ed0$@sales@free.fr>

Hi, 

 

Testing the PKCS12 command I notice the -cipher option (in this case
-aes128) was silently ignore :

 

c:\OpenSSL_11_dbg\bin\openssl pkcs12 -export -out Certificate.p12 -inkey
RSAKey.pem -in Certificate.cer -aes128 -passin pass:test -passout pass:test

 

looks Ok but verifying, it is still 3des :

 

c:\openssl_11_dbg\bin\openssl pkcs12 -in Certificate.p12 -info -noout
-passin pass:test

MAC Iteration 2048

PKCS7 Encrypted data: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048

Certificate bag

PKCS7 Data

Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048

 

Surprisingly, with 1.0.2 it fails loudly :

 

openssl pkcs12 -export -out Certificate.p12 -inkey RSAKey.pem -in
Certificate.cer -aes128 -passin pass:test -passout pass:test

8632:error:060740A0:digital envelope routines:EVP_PBE_CipherInit:unknown
cipher:.\crypto\evp\evp_pbe.c:181:

8632:error:23077073:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 algor cipherinit
error:.\crypto\pkcs12\p12_decr.c:87:

8632:error:2306C067:PKCS12 routines:PKCS12_item_i2d_encrypt:encrypt
error:.\crypto\pkcs12\p12_decr.c:188:

8632:error:23073067:PKCS12 routines:PKCS12_pack_p7encdata:encrypt
error:.\crypto\pkcs12\p12_add.c:213:

 

Am I missing something ?

 

Regards,

 

Michel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160211/47fd154a/attachment.html>

From cloud.force858 at gmail.com  Thu Feb 11 22:17:00 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Thu, 11 Feb 2016 14:17:00 -0800
Subject: [openssl-users] OpenSSL lib build errors
In-Reply-To: <CAEsYawwu9SPWgvLpFyziBe2p7Bxm=GDwnaNpEmFnmhgJqsZnbA@mail.gmail.com>
References: <CAEsYawwu9SPWgvLpFyziBe2p7Bxm=GDwnaNpEmFnmhgJqsZnbA@mail.gmail.com>
Message-ID: <CAEsYawzw8WV40S_u6OWAFO2vA5hPkveCQ7ztJbmA9Bw=6k4hHA@mail.gmail.com>

Anyone saw these errors before?

On Wed, Feb 10, 2016 at 5:34 PM, cloud force <cloud.force858 at gmail.com>
wrote:

> Hi All:
>
> I tried to build a FIPS capable OpenSSL Ubuntu package (using the Ubuntu
> 12.04 debian meta file).
>
> The Ubuntu package uses Configure for configuring the source tree with the
> following parameters:
>
>
>
> *ARCH_CONFARGS := enable-ec_nistp_64_gcc_128CONFARGS  = --prefix=/usr
> --openssldir=/usr/lib/ssl --libdir=lib/$(DEB_HOST_MULTIARCH) fips no-idea
> no-mdc2 no-rc5 zlib  enable-tlsext no-ssl2 $(ARCH_CONFARGS)*
>
>
> I ran into the following errors near the end of the build:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *shlib_target=; if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \
>     shlib_target="linux-shared"; \    elif [ -n "libcrypto" ]; then \
> FIPSLD_CC="gcc"; CC=/usr/local/ssl/fips-2.0/bin/fipsld; export CC
> FIPSLD_CC; \    fi; \    LIBRARIES="-L.. -lssl  -L.. -lcrypto" ; \    make
> -f ../Makefile.shared -e \        APPNAME=openssl OBJECTS="openssl.o
> verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o
> errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o
> ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o
> s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o
> nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o
> rand.o engine.o ocsp.o prime.o ts.o srp.o" \        LIBDEPS=" $LIBRARIES
> -ldl -lz" \        link_app.${shlib_target}make[3]: Entering directory
> `/home/precise/amd64/openssl/openssl-1.0.1/apps'speed.o: In function
> `speed_main':/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1219:
> undefined reference to
> `private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1220:
> undefined reference to
> `private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1221:
> undefined reference to
> `private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1224:
> undefined reference to
> `private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1225:
> undefined reference to
> `private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1226:
> undefined reference to
> `private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1229:
> undefined reference to
> `private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1230:
> undefined reference to
> `private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1231:
> undefined reference to
> `private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1237:
> undefined reference to
> `private_SEED_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1240:
> undefined reference to
> `private_RC4_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1243:
> undefined reference to
> `private_RC2_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1249:
> undefined reference to
> `private_BF_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1252:
> undefined reference to `private_CAST_set_key'collect2: ld returned 1 exit
> status*
>
>
> Any suggestions and possible solutions are greatly appreciated.
>
> --
> Thanks,
> Rich
>
>


-- 
Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160211/6544fae9/attachment.html>

From nounou.dadoun at avigilon.com  Fri Feb 12 00:53:11 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Fri, 12 Feb 2016 00:53:11 +0000
Subject: [openssl-users] 2-key vs 3-key 3DES
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E07E07@mbx027-w1-ca-4.exch027.domain.local>

I've just been reading about recommended and deprecated encryption and tripped over a nist document (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf) that distinguishes between 2key and 3key 3DES saying that the former is deprecated after 2015 but the latter is still acceptable.

Is this distinguishable in openssl?  I.e. if we negotiate TLS_RSA_WITH_3DES_EDE_CBC_SHA does it always use the 3-key version?

(I'm experimenting running NeXpose against an embedded device to look for security holes and it complained about DES (we only use 3DES) and CBC - odd!)

Thanks ... N


Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 
Support: 888.281.5182 ?|? avigilon.com
Follow?Twitter ?|? Follow?LinkedIn


This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide.



From cloud.force858 at gmail.com  Fri Feb 12 02:45:29 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Thu, 11 Feb 2016 18:45:29 -0800
Subject: [openssl-users] FIPS mode errors
Message-ID: <CAEsYawyiKudDTQSxD5ouFLojei_dR_QtbDzM_wcYvSrjw6WYDA@mail.gmail.com>

Hi,

I built the FIPS capable OpenSSL library on Ubuntu 12.04.
When I run the command "OPENSSL_FIPS=1 openssl ciphers", I saw the
following error:

140073969415840:error:2D06B06F:FIPS
routines:FIPS_check_incore_fingerprint:fingerprint
does not match:fips.c:232:

I tried few other openssl commands under the FIPS mode and got all the same
error messages. The non-FIPS mode was working fine.

What is the above error mean and what could have caused this error?

-- 
Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160211/552ec0f4/attachment.html>

From jb-openssl at wisemo.com  Fri Feb 12 07:34:45 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 12 Feb 2016 08:34:45 +0100
Subject: [openssl-users] FIPS mode errors
In-Reply-To: <CAEsYawyiKudDTQSxD5ouFLojei_dR_QtbDzM_wcYvSrjw6WYDA@mail.gmail.com>
References: <CAEsYawyiKudDTQSxD5ouFLojei_dR_QtbDzM_wcYvSrjw6WYDA@mail.gmail.com>
Message-ID: <56BD8B15.7000008@wisemo.com>

On 12/02/2016 03:45, cloud force wrote:
> Hi,
>
> I built the FIPS capable OpenSSL library on Ubuntu 12.04.
> When I run the command "OPENSSL_FIPS=1 openssl ciphers", I saw the 
> following error:
>
> 140073969415840:error:2D06B06F:FIPS 
> routines:FIPS_check_incore_fingerprint:fingerprint does not 
> match:fips.c:232:
>
> I tried few other openssl commands under the FIPS mode and got all the 
> same error messages. The non-FIPS mode was working fine.
>
> What is the above error mean and what could have caused this error?
This is the most severe FIPS error code, it means one of
3 things:

1. (official reason for this error code): Someone illegally
   modified the FIPS validated crypto code after it was
   compiled, do not use this computer until the cause has
   been thoroughly investigated and corrected.

2. (much more likely): The file containing the FIPS code
   (either lib/libcrypto.so.1.0.0 or the program you ran)
   was relocated to a different memory address this time
   than back when you ran fipsld to set the checksum
   (fingerprint).

3. (sometimes): You forgot to run fipsld to set the
   checksum (fingerprint).



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160212/711b8bc8/attachment-0001.html>

From cloud.force858 at gmail.com  Fri Feb 12 07:52:57 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Thu, 11 Feb 2016 23:52:57 -0800
Subject: [openssl-users] FIPS mode errors
In-Reply-To: <56BD8B15.7000008@wisemo.com>
References: <CAEsYawyiKudDTQSxD5ouFLojei_dR_QtbDzM_wcYvSrjw6WYDA@mail.gmail.com>
 <56BD8B15.7000008@wisemo.com>
Message-ID: <CAEsYawyCy81oSg5s1bm0Yy4oatT5CwKNCMW6qatEfBJjFnqJwg@mail.gmail.com>

Hi Jakob,

This is the most severe FIPS error code, it means one of
> 3 things:
>
> 1. (official reason for this error code): Someone illegally
>   modified the FIPS validated crypto code after it was
>   compiled, do not use this computer until the cause has
>   been thoroughly investigated and corrected.
>
> 2. (much more likely): The file containing the FIPS code
>   (either lib/libcrypto.so.1.0.0 or the program you ran)
>   was relocated to a different memory address this time
>   than back when you ran fipsld to set the checksum
>   (fingerprint).
>

If this is the case, how should I fix this problem?


>
>
> 3. (sometimes): You forgot to run fipsld to set the
>   checksum (fingerprint).
>

At what point during the build should the fipsld be run?

>
>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160211/8e44c1fd/attachment.html>

From noloader at gmail.com  Fri Feb 12 08:11:31 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 12 Feb 2016 03:11:31 -0500
Subject: [openssl-users] 2-key vs 3-key 3DES
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E07E07@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E07E07@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <CAH8yC8ny1S_NpPqhEsijFmYiY5Qg-JhkvTjdNB9yopjwqcSiHQ@mail.gmail.com>

> I've just been reading about recommended and deprecated encryption and tripped over a nist document (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf) that distinguishes between 2key and 3key 3DES saying that the former is deprecated after 2015 but the latter is still acceptable.
>
2-key 3DES provides about 80 bits of security, while 3-key 3DES
provides about 112 bits.

> Is this distinguishable in openssl?  I.e. if we negotiate TLS_RSA_WITH_3DES_EDE_CBC_SHA does it always use the 3-key version?
>

TLS cipher suites, like TLS_RSA_WITH_3DES_EDE_CBC_SHA, use the 3-key
version. Also see RFC 5246, https://tools.ietf.org/html/rfc5246, and
the discussion of "Data Encryption Standard" on page 79:

      DES can also be operated in a mode [3DES] where
      three independent keys and three encryptions are
      used for each block of data; this uses 168 bits of key
      (24 bytes in the TLS key generation method) and
      provides the equivalent of 112 bits of security.

Jeff

From lloydkl.tech at gmail.com  Fri Feb 12 15:05:01 2016
From: lloydkl.tech at gmail.com (Lloyd)
Date: Fri, 12 Feb 2016 20:35:01 +0530
Subject: [openssl-users] Decrypt TCP session
Message-ID: <CAA10ZTpDAsjVRgh6XGuqrhPd3ZKvw_9=x0mOOnJuZyKbAfk+JQ@mail.gmail.com>

Hi,

I have implemented a sample HTTP server/client based on openssl (boost
asio) and able to send the message encrypted. Loaded the key in Wireshark
and able to see the data in plaintext form.

Now I wish to write an application to decrypt the same "tcp session data"
(tcp session data = the output of follow TCP stream option in Wireshark).

what should be the starting point to implement this? does open ssl have
some sample code/application does this?

Any hint is greatly appreciated.

Thanks,
  Lloyd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160212/b718b0f3/attachment.html>

From tshort at akamai.com  Fri Feb 12 16:54:05 2016
From: tshort at akamai.com (Short, Todd)
Date: Fri, 12 Feb 2016 16:54:05 +0000
Subject: [openssl-users] Decrypt TCP session
In-Reply-To: <CAA10ZTpDAsjVRgh6XGuqrhPd3ZKvw_9=x0mOOnJuZyKbAfk+JQ@mail.gmail.com>
References: <CAA10ZTpDAsjVRgh6XGuqrhPd3ZKvw_9=x0mOOnJuZyKbAfk+JQ@mail.gmail.com>
Message-ID: <23C0C0BA-1D17-4954-9F02-A64010ECACA6@akamai.com>

Check out ssldump.
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Feb 12, 2016, at 10:05 AM, Lloyd <lloydkl.tech at gmail.com<mailto:lloydkl.tech at gmail.com>> wrote:

Hi,

I have implemented a sample HTTP server/client based on openssl (boost asio) and able to send the message encrypted. Loaded the key in Wireshark and able to see the data in plaintext form.

Now I wish to write an application to decrypt the same "tcp session data" (tcp session data = the output of follow TCP stream option in Wireshark).

what should be the starting point to implement this? does open ssl have some sample code/application does this?

Any hint is greatly appreciated.

Thanks,
  Lloyd

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160212/0a790080/attachment.html>

From xerces9+osl at gmail.com  Fri Feb 12 17:09:59 2016
From: xerces9+osl at gmail.com (=?UTF-8?Q?David_Bala=C5=BEic?=)
Date: Fri, 12 Feb 2016 18:09:59 +0100
Subject: [openssl-users] Firefox problems with two way SSL auth
In-Reply-To: <CAPJ9Yc874Lu4Mg3r+A6GTQx3c5-AAyV5W_wNv4uxugSpCw5rkQ@mail.gmail.com>
References: <CAPJ9Yc874Lu4Mg3r+A6GTQx3c5-AAyV5W_wNv4uxugSpCw5rkQ@mail.gmail.com>
Message-ID: <CAPJ9Yc_Gmd=tbdyrU_5v5uEBOeoDDgYodPqkA+6TtPfKjdP8cg@mail.gmail.com>

Hi!

Tomcat released version 8.0.32 which bundles OpenSSL 1.0.2e (see below)
The issue remains (with the change that now IE can not connect at all,
it complains about some TLS stuff, did not look into it).

Any hints how to tackle this problem are welcome.

Version details (from tomcat startup log):
Loaded APR based Apache Tomcat Native library 1.2.4 using APR version 1.5.1.
OpenSSL successfully initialized (OpenSSL 1.0.2e 3 Dec 2015)

Regards,
David


On 8 January 2016 at 17:02, David Bala?ic <xerces9+osl at gmail.com> wrote:
> Hi!
>
> I encounter this issue when using Firefox to access tomcat (that is
> using openssl) with client cert authentication.
>
> After a certain timeout, the web application does not "see" the
> clients certificate in requests.
>
> The problem happens on different operating systems (Window,s Linux)
> and browsers.
>
> I reported it to tomcat and Firefox, with not much response.
>
> There is a simple test case in comment 1 of the tomcat bug (see below).
>
> Could someone assist in finding the cause of the problem?
> I also have pcap traces (somewhere) of working and non working network traffic.
>
>
> Latest tested configuration:
> tomcat 8.0.30, using OpenSSL 1.0.1m 19 Mar 2015
> Firefox 43.0.4
> OS: Windows 7 Pro SP1 64bit
>
> The tomcat bug with much details:
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
>
> Firefox bug report (not much details):
> https://bugzilla.mozilla.org/show_bug.cgi?id=1231406
>
> Regards,
> David Bala?ic

From openssl.org at 18informatique.com  Fri Feb 12 18:15:15 2016
From: openssl.org at 18informatique.com (mlrx)
Date: Fri, 12 Feb 2016 19:15:15 +0100
Subject: [openssl-users] ciphers
Message-ID: <56BE2133.5070901@18informatique.com>

Hello !

I have some questions that I don't find answers by myself,
even after read the cookbook and a lot of web pages.
To be honest, I'm not really sure it's a problem but I
need to verify.

Ok. I am setting up web server to host a critical java application.
There is Apache in front of Tomcat and I want to enforce connections
over https only with higher ciphers from TLS 1.2.
Is it a good way ?

There is a part of Apache's settings :
ssl.conf :
<http://paste.opensuse.org/03eefb03>
the vhost file :
<http://paste.opensuse.org/972e254d>

The public part works good, no problem.
For the moment (testing), I use an auto-signed certificate.
Of course, I will use "real" CA signed EV certificate in
production.

Well, I've did some tests. Here is a part of some nmap and testssl.sh
results :
<http://paste.opensuse.org/43377128>

Is everything ok or do I need to change something ?
Could you give some advice to make it safer please ?
I really want to be closer to the state of the art and understand it.

A last thing : please, accept my apologies... I don't speak english
anymore since many many years.

Best regards,
-- 
benoist

-- 
benoist

From Suman.Patro-TRN at lntebg.com  Fri Feb 12 17:37:29 2016
From: Suman.Patro-TRN at lntebg.com (R-D intern)
Date: Fri, 12 Feb 2016 10:37:29 -0700 (MST)
Subject: [openssl-users] regarding SSL security
In-Reply-To: <56BCECFE.4040902@wisemo.com>
References: <1455215478519-63504.post@n7.nabble.com>
 <56BCECFE.4040902@wisemo.com>
Message-ID: <1455298649401-63567.post@n7.nabble.com>

Thank you a lot, Jakob.I understood your answers and am quite satisfied too
that the replies sound conceptually right. But it would be kind on your part
if you answer some questions further.

1. Regarding question 3, I am using openssl 1.0.2e which supports named
curve. Such a question had earlier been asked in this forum which says ,
such a message is only misleading but the certificate works fine. Here is
the below
link:"http://openssl.6102.n7.nabble.com/ECC-Self-Signed-Certificate-td17042.html#a17047".But
I would like the certificate have a clean structure. How can that be done?

2.Regarding question 7, I am working to secure a middleware that will be
deployed in control and monitoring systems, hence there would be know
persons at the client side and  the certificates I am  using are self signed
ones created using openssl 1.0.2e , hence there will be no public CAs . In
such a scenario , how will the CA know that the private  key has been
compromised? If the private key  gets compromised, then even the certificate
can be forged ,then what is the use of CRL?
 Kindly answer. 
Thanks and regards,
Suman Patro




--
View this message in context: http://openssl.6102.n7.nabble.com/regarding-SSL-security-tp63504p63567.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From cloud.force858 at gmail.com  Fri Feb 12 19:44:26 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Fri, 12 Feb 2016 11:44:26 -0800
Subject: [openssl-users] no version information available error
In-Reply-To: <56BCADCF.2030109@wisemo.com>
References: <CAEsYawxZLuPk42hyX6tmmdNyi33xLjpREsEdaVhqZAdz18Qvsw@mail.gmail.com>
 <56BCADCF.2030109@wisemo.com>
Message-ID: <CAEsYawxB3XUP3HJtYdKvgrNO7z6f2XiARc09oizb_vsA=KahsQ@mail.gmail.com>

Thanks Jakob for the detailed info.

On Thu, Feb 11, 2016 at 7:50 AM, Jakob Bohm <jb-openssl at wisemo.com> wrote:

> On 10/02/2016 22:46, cloud force wrote:
>
>> Hi Everyone,
>>
>> I installed the FIPS capable openssl library (which was built by myself)
>> on my Ubuntu linux box.
>>
>> For some reason, I keep running into the following errors whenever I run
>> ssh related command:
>>
>>
>>     ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version
>>     information available (required by ssh)
>>
>>
>> The same error happens when I ran openssl command such as the following:
>>
>> linux-fips at ubuntu:/usr/local/ssl/lib$ openssl ciphers -v | wc -l
>> openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information
>> available (required by openssl)
>> openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information
>> available (required by openssl)
>> openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information
>> available (required by /lib/x86_64-linux-gnu/libssl.so.1.0.0)
>> openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information
>> available (required by /lib/x86_64-linux-gnu/libssl.so.1.0.0)
>>
>> The Debian-family (includes Ubuntu) standard OpenSSL shared
> libraries is built in a special way to include "version tags"
> in the resulting .so files, and all the openssl-needing
> binaries in Debian/Ubuntu/etc. produce the error message
> above if you install copies of those libraries without those
> extra "version tags".
>
> There are two alternative ways to solve this:
>
> A) Build your FIPS-cabable OpenSSL (not the FIPScanister)
>   with all the extra steps and patches in the Ubuntu OpenSSL
>   source package (.dsc etc.), just adding the FIPS canister.
>    Note that some of the patches in the source package are
>   backports of the security fixes included in the latest
>   OpenSSL versions, you'll probably have to figure out the
>   details yourself (unless Kurt Roeckz posts a recipe
>   somewhere).
>
> B) Patch your FIPS-capable OpenSSL makefile (not the
>   FIPScanister makefile) to use a different .so-version, such
>   as .so.1.0.2 .  Then your private openssl build will not be
>   used by the prepackaged software while software explicitly
>   compiled against your locally build OpenSSL will not
>   accidentally pick up the standard non-FIPS OpenSSL.
>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160212/8c4d1ad3/attachment.html>

From scott_n at xypro.com  Fri Feb 12 20:15:15 2016
From: scott_n at xypro.com (Scott Neugroschl)
Date: Fri, 12 Feb 2016 20:15:15 +0000
Subject: [openssl-users] no version information available error
In-Reply-To: <CAEsYawxB3XUP3HJtYdKvgrNO7z6f2XiARc09oizb_vsA=KahsQ@mail.gmail.com>
References: <CAEsYawxZLuPk42hyX6tmmdNyi33xLjpREsEdaVhqZAdz18Qvsw@mail.gmail.com>
 <56BCADCF.2030109@wisemo.com>
 <CAEsYawxB3XUP3HJtYdKvgrNO7z6f2XiARc09oizb_vsA=KahsQ@mail.gmail.com>
Message-ID: <D358E5B1511A314F8160ADC6F37549873438462D@XYSVEX02.XYPRO-23.LOCAL>

OpenSSH does not work with the FIPS mode of OpenSSL.  This has been discussed both here and on the OpenSSH list.

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of cloud force
Sent: Friday, February 12, 2016 11:44 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] no version information available error

Thanks Jakob for the detailed info.

On Thu, Feb 11, 2016 at 7:50 AM, Jakob Bohm <jb-openssl at wisemo.com<mailto:jb-openssl at wisemo.com>> wrote:
On 10/02/2016 22:46, cloud force wrote:
Hi Everyone,

I installed the FIPS capable openssl library (which was built by myself) on my Ubuntu linux box.

For some reason, I keep running into the following errors whenever I run ssh related command:


    ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version
    information available (required by ssh)


The same error happens when I ran openssl command such as the following:

linux-fips at ubuntu:/usr/local/ssl/lib$ openssl ciphers -v | wc -l
openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information available (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information available (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information available (required by /lib/x86_64-linux-gnu/libssl.so.1.0.0)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information available (required by /lib/x86_64-linux-gnu/libssl.so.1.0.0)
The Debian-family (includes Ubuntu) standard OpenSSL shared
libraries is built in a special way to include "version tags"
in the resulting .so files, and all the openssl-needing
binaries in Debian/Ubuntu/etc. produce the error message
above if you install copies of those libraries without those
extra "version tags".

There are two alternative ways to solve this:

A) Build your FIPS-cabable OpenSSL (not the FIPScanister)
  with all the extra steps and patches in the Ubuntu OpenSSL
  source package (.dsc etc.), just adding the FIPS canister.
   Note that some of the patches in the source package are
  backports of the security fixes included in the latest
  OpenSSL versions, you'll probably have to figure out the
  details yourself (unless Kurt Roeckz posts a recipe
  somewhere).

B) Patch your FIPS-capable OpenSSL makefile (not the
  FIPScanister makefile) to use a different .so-version, such
  as .so.1.0.2 .  Then your private openssl build will not be
  used by the prepackaged software while software explicitly
  compiled against your locally build OpenSSL will not
  accidentally pick up the standard non-FIPS OpenSSL.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10<tel:%2B45%2031%2013%2016%2010>
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



--
Thanks,
Rich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160212/029ecbe5/attachment.html>

From karl at denninger.net  Fri Feb 12 20:15:23 2016
From: karl at denninger.net (Karl Denninger)
Date: Fri, 12 Feb 2016 14:15:23 -0600
Subject: [openssl-users] regarding SSL security
In-Reply-To: <1455298649401-63567.post@n7.nabble.com>
References: <1455215478519-63504.post@n7.nabble.com>
 <56BCECFE.4040902@wisemo.com> <1455298649401-63567.post@n7.nabble.com>
Message-ID: <56BE3D5B.8000502@denninger.net>



On 2/12/2016 11:37, R-D intern wrote:
> Thank you a lot, Jakob.I understood your answers and am quite satisfied too
> that the replies sound conceptually right. But it would be kind on your part
> if you answer some questions further.
>
> 1. Regarding question 3, I am using openssl 1.0.2e which supports named
> curve. Such a question had earlier been asked in this forum which says ,
> such a message is only misleading but the certificate works fine. Here is
> the below
> link:"http://openssl.6102.n7.nabble.com/ECC-Self-Signed-Certificate-td17042.html#a17047".But
> I would like the certificate have a clean structure. How can that be done?
>
> 2.Regarding question 7, I am working to secure a middleware that will be
> deployed in control and monitoring systems, hence there would be know
> persons at the client side and  the certificates I am  using are self signed
> ones created using openssl 1.0.2e , hence there will be no public CAs . In
> such a scenario , how will the CA know that the private  key has been
> compromised? If the private key  gets compromised, then even the certificate
> can be forged ,then what is the use of CRL?
>  Kindly answer. 
> Thanks and regards,
> Suman Patro
>

If the CA is private then the CA's public certificate (and any
intermediates required to reach it) is loaded into OpenSSL as the chain
of validation.  That certificate can specify an OCSP or CRL location for
revocation checks, which you must then extract and check in your code.

"Best practice" for something of this sort requires that _*both*_ ends
of the connection present and use certificates, not just the server (in
other words you don't want a random client machine connecting either!)
which in turn means you need to check for validity and revocation on
both ends, /*and */you must ensure the security of the CA infrastructure
and its private key.

Note that "how the CA knows the client private key is compromised" is an
/operational /question, not a programmatic one -- as is the case with a
public CA.  (In other words someone has to tell the CA it was stolen so
the CA can issue the revocation, and the application must check that
revocation resource.)

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160212/49c5e76a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160212/49c5e76a/attachment-0001.bin>

From aerowolf at gmail.com  Fri Feb 12 21:26:59 2016
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Fri, 12 Feb 2016 13:26:59 -0800
Subject: [openssl-users] Validation status of openssl-fips-2.0.11?
Message-ID: <56BE4E23.80505@gmail.com>

I'm not seeing anything about openssl-fips-2.0.11 in
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747
, so I'm not quite certain what its validation/certificate status is? 
Also, is a new Security Policy in the works integrating the new HMAC
digests for the new versions of -fips and -fips-ecp?

(Also, would the mandatory HMAC calculation of the original tarball be
okay if it were done using a FIPS-validated version of Mozilla's NSS?)

-Kyle H

From marquess at openssl.com  Fri Feb 12 22:03:18 2016
From: marquess at openssl.com (Steve Marquess)
Date: Fri, 12 Feb 2016 17:03:18 -0500
Subject: [openssl-users] Validation status of openssl-fips-2.0.11?
In-Reply-To: <56BE4E23.80505@gmail.com>
References: <56BE4E23.80505@gmail.com>
Message-ID: <56BE56A6.2020908@openssl.com>

On 02/12/2016 04:26 PM, Kyle Hamilton wrote:
> I'm not seeing anything about openssl-fips-2.0.11 in
> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747
> , so I'm not quite certain what its validation/certificate status is? 

Ok, this is complex, insanely so.

There is one OpenSSL FIPS Module, the "OpenSSL FIPS Object Module v2.0".
It is updated from time to time, to add new platforms, and each revision
of that module is distributed in a tarball with the name
openssl-fips-2.0.N.tar.gz, with N currently at 12. All revisions of the
module are valid; each successive revision by careful design subsumes
all the previously validated platforms.

For a long time this one module had only one validation, #1747. But, we
ran into an intractable issue with the CMVP that meant we were no longer
able to update the #1747 validation[1]. So, we obtained nominally
separate validations for the *same* FIPS module. That one module is now
covered by three separate validations, #1747, #2398, and #2473.

Collectively the three validations include over 120 platforms. One
module, three validations. If you're shipping a product that uses the
OpenSSL FIPS module and need to state which validation number applies,
you need to look to see which of the three validations your platform of
interest is listed for. That is the validation number you reference.

So all three validations are current. The #1747 and #2473 validations
will remain at revision 2.0.10 forever; #1747 because we can't change it
and #2398 so that multi-platform vendors can use the exact same binary
module on the widest range of platforms. New platforms that don't
require source code changes will go on the #2473 validation. New
platforms that require source code changes and thus a new module
revision will of necessity go on the #2398 validation.

Yeah, it's a mess.

> Also, is a new Security Policy in the works integrating the new HMAC
> digests for the new versions of -fips and -fips-ecp?

I don't understand this question.

> (Also, would the mandatory HMAC calculation of the original tarball be
> okay if it were done using a FIPS-validated version of Mozilla's NSS?)

You wouldn't believe how deep that rabbit hole goes. See section 6.6 of
the OpenSSL FIPS user guide
(https://openssl.org/docs/fips/UserGuide-2.0.pdf). The answer to that
question is why we're still snail-mailing CDs (see
http://openssl.com/fips/verify.html).

-Steve M.

[1] A tedious discussion starts at http://openssl.com/fips/hostage.html

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From cloud.force858 at gmail.com  Fri Feb 12 22:36:51 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Fri, 12 Feb 2016 14:36:51 -0800
Subject: [openssl-users] openssl.ld and global symbols
Message-ID: <CAEsYawxQMiDyn+UKkdGZrzHdZ=qWMw9S2zQKaxsmGuYjVWAFfw@mail.gmail.com>

Hi Everyone,

I tried to build a FIPS capable OpenSSL Ubuntu package (using the Ubuntu
12.04 debian build scripts).

The Ubuntu package uses Configure for configuring the source tree with the
following parameters:



*ARCH_CONFARGS := enable-ec_nistp_64_gcc_128CONFARGS  = --prefix=/usr
--openssldir=/usr/lib/ssl --libdir=lib/$(DEB_HOST_MULTIARCH) fips no-idea
no-mdc2 no-rc5 zlib  enable-tlsext no-ssl2 $(ARCH_CONFARGS)*


I ran into the following errors near the end of the build:






























*shlib_target=; if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \
    shlib_target="linux-shared"; \    elif [ -n "libcrypto" ]; then \
FIPSLD_CC="gcc"; CC=/usr/local/ssl/fips-2.0/bin/fipsld; export CC
FIPSLD_CC; \    fi; \    LIBRARIES="-L.. -lssl  -L.. -lcrypto" ; \    make
-f ../Makefile.shared -e \        APPNAME=openssl OBJECTS="openssl.o
verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o
errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o
ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o
s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o
nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o
rand.o engine.o ocsp.o prime.o ts.o srp.o" \        LIBDEPS=" $LIBRARIES
-ldl -lz" \        link_app.${shlib_target}make[3]: Entering directory
`/home/precise/amd64/openssl/openssl-1.0.1/apps'speed.o: In function
`speed_main':/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1219:
undefined reference to
`private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1220:
undefined reference to
`private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1221:
undefined reference to
`private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1224:
undefined reference to
`private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1225:
undefined reference to
`private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1226:
undefined reference to
`private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1229:
undefined reference to
`private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1230:
undefined reference to
`private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1231:
undefined reference to
`private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1237:
undefined reference to
`private_SEED_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1240:
undefined reference to
`private_RC4_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1243:
undefined reference to
`private_RC2_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1249:
undefined reference to
`private_BF_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1252:
undefined reference to `private_CAST_set_key'collect2: ld returned 1 exit
status*


By comparing with the build from the stock tarball, I noticed that the
above symbols were shown as local (t) in libcrypto.so, while they're shown
as global (T) in the libcrypto.so which was built from the stock openssl
tarball. I found that if I add the above symbols to the openssl.ld file,
then the build went through without problems.


My questions are:
1. How was the openssl.ld file generated?

2. Is it an ok solution to add the above symbols to openssl.ld?

3. How to control the symbols visibility in the Makefile so that these
symbols will be exposed as global in the libcrypto.so?



-- 
Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160212/4b054574/attachment.html>

From aerowolf at gmail.com  Sat Feb 13 09:58:22 2016
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Sat, 13 Feb 2016 01:58:22 -0800
Subject: [openssl-users] Validation status of openssl-fips-2.0.11?
In-Reply-To: <56BE56A6.2020908@openssl.com>
References: <56BE4E23.80505@gmail.com> <56BE56A6.2020908@openssl.com>
Message-ID: <56BEFE3E.1090308@gmail.com>


On 2/12/2016 2:03 PM, Steve Marquess wrote:
> On 02/12/2016 04:26 PM, Kyle Hamilton wrote:
>> I'm not seeing anything about openssl-fips-2.0.11 in
>> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747
>> , so I'm not quite certain what its validation/certificate status is? 
> Ok, this is complex, insanely so.
>
> [concise explanation of insanely complex and incredibly messy situation trimmed]
>
> Yeah, it's a mess.

Thank you for explaining it.  It feels to me like they're intentionally
making it as difficult as possible for OpenSSL to maintain its validations.

#2398 has the correct version that I'm looking for, so that's what I'm
documenting.  However, it also suggests that there's a 2.0.12 that was
validated as of 02/08/2016?  This is not yet distributed on the website.

>> Also, is a new Security Policy in the works integrating the new HMAC
>> digests for the new versions of -fips and -fips-ecp?
> I don't understand this question.

https://openssl.org/docs/fips/SecurityPolicy-2.0.pdf points to
SecurityPolicy-2.0.9.pdf; this is the version that I got, which did not
have the new HMAC values for openssl-fips-ecp-2.0.11.tar.gz.  I was
wondering if there was a SecurityPolicy-2.0.11.pdf.  It appears there
is, but the "official" link to 140sp2398.pdf points to a
SecurityPolicy-2.0.12.pdf.  So, I can't quite manage to figure out if
I'm getting my security policy through a secure path (please see the end
of this email for more on what I mean, and why I say this).

>> (Also, would the mandatory HMAC calculation of the original tarball be
>> okay if it were done using a FIPS-validated version of Mozilla's NSS?)
> You wouldn't believe how deep that rabbit hole goes. See section 6.6 of
> the OpenSSL FIPS user guide
> (https://openssl.org/docs/fips/UserGuide-2.0.pdf). The answer to that
> question is why we're still snail-mailing CDs (see
> http://openssl.com/fips/verify.html).

My understanding of this requirement is:  A secure path can only be
established via mail/courier, or via some series of FIPS-validated
cryptographic modules.

As a result, I cannot use any non-validated openssl to bootstrap to a
validated openssl-fips, because the chain of FIPS-validated
cryptographic verification must not be broken.  If I have another
FIPS-validated module which is validated for SHA1-HMAC, I can use it in
accordance with its security policy to perform the HMAC verification. 
If I already have a FIPS-validated openssl, I can use it.  Otherwise, I
must obtain the CD from OpenSSL Foundation (most likely via registered
mail -- not even certified mail, but registered mail).

There do exist other FIPS-validated modules, like the FIPS-validated
NSS: I've already set all of the cryptography in my Firefox installation
to be through the NSS FIPS module (using cipher
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys, TLS 1.2 --
compliant with the FIPS TLS implementation guidance).  Since I'm using a
FIPS-validated NSS to perform the cryptography to download from
https://openssl.org/source/openssl-fips-ecp-2.0.11.tar.gz, would that
pass the "secure path" challenge, or would I still need to write
something to perform the HMAC test specified in Appendix B of the
Security Policy using the NSS FIPS module?

I suspect the answer depends on whether openssl.org's TLS stack is using
OpenSSL in FIPS mode.  Because I do not know if it is (and the site
itself does not mention it), I think I should assume that the TLS stack
of openssl.org does NOT operate in FIPS mode, and thus I shouldn't rely
on it as being part of the necessary trusted path.  Because of this, I
think I should assume that HMAC verification in accordance with Appendix
B is still compelled.

I hope that this insight might be helpful, though.

-Kyle H


From marquess at openssl.com  Sat Feb 13 18:15:29 2016
From: marquess at openssl.com (Steve Marquess)
Date: Sat, 13 Feb 2016 13:15:29 -0500
Subject: [openssl-users] Validation status of openssl-fips-2.0.11?
In-Reply-To: <56BEFE3E.1090308@gmail.com>
References: <56BE4E23.80505@gmail.com> <56BE56A6.2020908@openssl.com>
 <56BEFE3E.1090308@gmail.com>
Message-ID: <56BF72C1.30008@openssl.com>

On 02/13/2016 04:58 AM, Kyle Hamilton wrote:
> 
> On 2/12/2016 2:03 PM, Steve Marquess wrote:
>> On 02/12/2016 04:26 PM, Kyle Hamilton wrote:
>>> I'm not seeing anything about openssl-fips-2.0.11 in
>>> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747
>>> , so I'm not quite certain what its validation/certificate status is? 
>> Ok, this is complex, insanely so.
>>
>> [concise explanation of insanely complex and incredibly messy situation trimmed]
>>
>> Yeah, it's a mess.
> 
> Thank you for explaining it.  It feels to me like they're intentionally
> making it as difficult as possible for OpenSSL to maintain its validations.

It does tend to look that way.  Whether or not that is the deliberate
intent those obstructions have had the effect of discouraging any new
validation attempts.

> 
> #2398 has the correct version that I'm looking for, so that's what I'm
> documenting.  However, it also suggests that there's a 2.0.12 that was
> validated as of 02/08/2016?  This is not yet distributed on the website.

You've reminded me that we need to upload the 2.0.12 tarball and latest
revisions of the Security Policy docs to openssl.org.

> 
>>> Also, is a new Security Policy in the works integrating the new HMAC
>>> digests for the new versions of -fips and -fips-ecp?
>> I don't understand this question.
> 
> https://openssl.org/docs/fips/SecurityPolicy-2.0.pdf points to
> SecurityPolicy-2.0.9.pdf; this is the version that I got, which did not
> have the new HMAC values for openssl-fips-ecp-2.0.11.tar.gz.  I was
> wondering if there was a SecurityPolicy-2.0.11.pdf.  It appears there
> is, but the "official" link to 140sp2398.pdf points to a
> SecurityPolicy-2.0.12.pdf.  So, I can't quite manage to figure out if
> I'm getting my security policy through a secure path (please see the end
> of this email for more on what I mean, and why I say this).

Well, first of all the Security Policy document doesn't have to come
from a "secure path"; you can download it directly from the NIST CMVP
web site.

You can always use the latest version of the Security policy for any
given OpenSSL FIPS module validation; each successive revision always
subsumes all prior revisions. So the 2.0.11 revision of the Security
Policy for validation #2398 is now of historical interest only; use the
current revision which is for 2.0.12 (but which also still covers
2.0.11, 2.0.10, ...). The NIST CMVP web site links to the current
revision of that document for each validation.

>
>>> (Also, would the mandatory HMAC calculation of the original tarball be
>>> okay if it were done using a FIPS-validated version of Mozilla's NSS?)
>> You wouldn't believe how deep that rabbit hole goes. See section 6.6 of
>> the OpenSSL FIPS user guide
>> (https://openssl.org/docs/fips/UserGuide-2.0.pdf). The answer to that
>> question is why we're still snail-mailing CDs (see
>> http://openssl.com/fips/verify.html).
> 
> My understanding of this requirement is:  A secure path can only be
> established via mail/courier, or via some series of FIPS-validated
> cryptographic modules.

Kinda-sorta...

> ...
> I suspect the answer depends on whether openssl.org's TLS stack is using
> OpenSSL in FIPS mode.  

It doesn't and it won't. I spent many weeks exploring options with the
NIST CMVP at the time (in 2012), with the eventual conclusion that there
was no configuration of open source software for "secure" network file
delivery that would satisfy their rather exacting requirements. For
instance, use of any prior validated version of the OpenSSL FIPS module
(e.g. #1051) for that purpose was specifically rejected.

Long story short, that rabbit hole goes so deep we can't reach the
bottom. The CMVP accepts snail-mailed CDs (regular USPS first class
mail) as "secure", so we go with that as something everyone can
understand and utilize.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From janjust at nikhef.nl  Sat Feb 13 23:55:38 2016
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Sun, 14 Feb 2016 00:55:38 +0100
Subject: [openssl-users] pkcs12 oddity
Message-ID: <56BFC27A.7060909@nikhef.nl>

hi list,

we just ran into an "openssl pkcs12" oddity with various versions of 
openssl (e.g. 1.0.1e from Fedora):

$ cat usercert.pem userkey.pem | openssl pkcs12 -export -out blah.p12
Enter pass phrase:
unable to load certificates

i.e. fails, but this works:

$ cat  userkey.pem usercert.pem | openssl pkcs12 -export -out blah.p12
Enter pass phrase:
Enter Export Password:
Verifying - Enter Export Password:

this works: it seems the private key must always be listed first!
However, the man page for pkcs12 states:

        -in filename
            The filename to read certificates and private keys from, standard input by default.  They must all be in
            PEM format. The order doesn't matter but one private key and its corresponding certificate should be
            present. If additional certificates are present they will also be included in the PKCS#12 file.


so, what am I doing wrong here? (the command listed above is not the 
actual command we want to use, but it does bring out the problem very 
nicely)

thanks for any help and pointers,

JJK / Jan Just Keijser


From grbesd1 at gmail.com  Mon Feb 15 04:42:46 2016
From: grbesd1 at gmail.com (Ganesh Biradar)
Date: Mon, 15 Feb 2016 10:12:46 +0530
Subject: [openssl-users] libsrtp-1.5.3 + openssl-1.0.1j + cryptodev engine
Message-ID: <CABewaXyvSKZzarFk5KCUGSyHcrQm6ZuzvScvpqHzKJ9wzg+hmg@mail.gmail.com>

Hi Guys,

           I'm trying for hardware encryption for my streaming data for
that i'm using
openssl with libsrtp. Below are the things i have noted.

Our CAAM (Cryptographic Acceleration and Assurance Module) driver does not
support AES-GCM. We are using an iMX6 SOC and it has a hardware accelerator
called CAAM to do encryption/decryption. So, we are stuck with AES-CTR mode
to do hardware encryption with libsrtp. We are using a Gstreamer bad plugin
(srtpenc) which relies on libsrtp to do real time encryption of live RTP
video packets.

I modified the encrypt function in aes_icm_openssl.c(libsrtp-1.5.3) to give
a different buffer for input and output.

In the original code, the encryption was done in place. This change was
done because of a segmentation fault thrown from the EVP_EncryptUpdate()
call.

I debugged this and couldn't find anything strange in the cryptodev as well
as openssl code (buffer overflows, memory leaks or out of bound array
access) except for the in place computation.

So, I declared a global buffer for 1 KB (out_buf) and gave this as the
output argument to EVP_EncryptUpdate() and now, the encryption and
decryption succeeded, except that the input had to be padded to a multiple
of 16 so that the decryption could succeed, later. This was a
workaround/hack I did to get basic hardware encryption with AES-CTR,
working.

The 1 KB size was arbitrary and chosen to make the srtp driver tests work.
To encrypt video, I had to increase the buffer size and so, I chose a
maximum size of 1 MB (I didn't want to allocate dynamic memory to keep
things simple) to hold the video packets.

Please note that encryption/decryption works fine without crypto engine
support. i.e. if we pass NULL as the 3rd argument to EVP_EncryptInit_ex(),
there's no need for a separate input/output buffer, and encryption and
decryption work fine with large buffers too (video can be
encrypted/decrypted).

Coming to hardware encryption, i have increase the size of buffer to 1MB,
streaming works fine but for maximum of 10 seconds, i have decrease the
size of buffer at different size. After 10 seconds, the streaming
application closes and it throws segmentation fault.

Can anyone tell me how do i solve this problem and my encryption of
streaming video should be continuous.


Ganesh Biradar,
e-mail - id : grbesd1 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160215/d1baa3a5/attachment.html>

From openssl at openssl.org  Mon Feb 15 19:04:20 2016
From: openssl at openssl.org (OpenSSL)
Date: Mon, 15 Feb 2016 19:04:20 +0000
Subject: [openssl-users] OpenSSL version 1.1.0 pre release 3 published
Message-ID: <20160215190420.GA12045@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 1.1.0 pre release 3 (alpha)
   ===========================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 3 has now
   been made available. For details of changes and known issues see the
   release notes at:

        http://www.openssl.org/news/openssl-1.1.0-notes.html

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   The alpha release is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   http://www.openssl.org/source/mirror.html):

     * http://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.1.0-pre3.tar.gz
      Size: 5024305
      SHA1 checksum: 5b2257c1d7d8db6400c9951865bd7ef58dc758b3
      SHA256 checksum: bb0ead36155dcf6122bfb0555205ba562ad5a82bb6067f2bfc9111ca4a4e6442

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.0-pre3.tar.gz
    openssl sha256 openssl-1.1.0-pre3.tar.gz

   Please download and check this alpha release as soon as possible.
   Bug reports should go to rt at openssl.org. Please check the release
   notes and mailing lists to avoid duplicate reports of known issues.

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJWwhryAAoJENXp5D99+e6MnDwP/juSt7tF3GZRWnR9qVtJOOna
BI8xqEt18S0c396m51+kNJrZ6CMyPOLjA16Jwl+6YRdB634TlrVjxfbyTeMRKCjr
kXWloh/ntOSKEWUql7auJyMZYFnvHg+fwLWRBsmrqnoXmV6044tDIF168qW1i/Sm
9g0aCx2KIKyXkWZ6e6VXOzSIckCCQbzvxhgUAIAVRLTivOwQmCSVSnqI5XzNXhQR
Jm0j16ViMuHd1si/DsQDXtqFzygw6Gnh7IcLsC0S4DHcUKnli9mhcUk+AsiIqtAN
s5tYfZPzyoRbAgqrN4PDBaDMhSK6TFW7b5GmxJMjbEp1UFUxPO7XhyMg3OOL9kx3
MXpCvp7J+azvppXqFgcbRq097jRVv/eS45SA92y64ucZt0Wk6mdGIpD9UJQ6njxd
EiexAf3WwceLo8kxsBcIDayIzjb/HjqzUjHF2qcgfD0qQH19IYACVr2Mu4HyqDCx
GIx0IUg2oltjtynVkJeaTnoApgaUF5dPTgRLKyjir1gIYdquP0mEe35+3ubTNVci
n4X5FPog3U5lDHKMsHWywes8Gm8gynza6KxvaeIUTmQyWOIZwTMpvjKGuMMdyaH8
rEGJ8Xxv4WKmlJRKLrnU0KkICgEPT8sSNGQFABB4xLwxYGrHVOXVaZQ7FXvkEkZT
so0emsh4V0fnfx5rNuOX
=zaOF
-----END PGP SIGNATURE-----

From rhermann at centonline.com  Mon Feb 15 19:59:39 2016
From: rhermann at centonline.com (Rob Hermann)
Date: Mon, 15 Feb 2016 13:59:39 -0600
Subject: [openssl-users] Building OpenSSL on Linux ,
	undefined reference to 'main'
Message-ID: <56C22E2B.1060502@centonline.com>


I'm attempting to build OpenSSL on a Linux box, when I issue the make 
from my OpenSSL directory (OpenSSLWork as seen here),   It builds all 
the subdirectories under crypto,
then proceeds to

OpenSSLWork/engines
OpenSSLWork/ssl
OpenSSLWork/apps

OpenSSLWork/test


making all in test...
make[1]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
make[2]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto  -ldl}"; 
LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS 
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -O3 
-fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS 
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM 
-DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS; 
do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo 
$LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH 
${LDCMD} ${LDFLAGS} -o ${APPNAME:=md2test} md2test.o ${LIBDEPS} )
_/usr/lib/gcc/i686-redhat-linux/4.4.7/../../../crt1.o: In function 
`_start':__
__(.text+0x18): undefined reference to `main'__
_collect2: ld returned 1 exit status
make[2]: *** [link_app.] Error 1
make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
make[1]: *** [md2test] Error 2
make[1]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
make: *** [build_tests] Error 1

I know this means I'm missing the main() function the entry point for 
all C programs.
I'm trying to build OpenSSL using the procedures outlined in the INSTALL 
document,  Has anyone seen this before and if so, what have you done to 
"fix" it ?

I've tried -nostartfiles as a linker option and that did not help.











-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160215/55ca1d67/attachment.html>

From matt at openssl.org  Mon Feb 15 20:15:19 2016
From: matt at openssl.org (Matt Caswell)
Date: Mon, 15 Feb 2016 20:15:19 +0000
Subject: [openssl-users] Building OpenSSL on Linux ,
 undefined reference to 'main'
In-Reply-To: <56C22E2B.1060502@centonline.com>
References: <56C22E2B.1060502@centonline.com>
Message-ID: <56C231D7.3030705@openssl.org>



On 15/02/16 19:59, Rob Hermann wrote:
> 
> I'm attempting to build OpenSSL on a Linux box, when I issue the make
> from my OpenSSL directory (OpenSSLWork as seen here),   It  builds all
> the subdirectories under crypto,
> then proceeds to

What OpenSSL version were you using?

Also please post the build steps you took, including any config options.

Thanks

Matt


From rhermann at centonline.com  Mon Feb 15 20:55:09 2016
From: rhermann at centonline.com (Rob Hermann)
Date: Mon, 15 Feb 2016 14:55:09 -0600
Subject: [openssl-users] Building OpenSSL on Linux ,
 undefined reference to 'main'
In-Reply-To: <56C22E2B.1060502@centonline.com>
References: <56C22E2B.1060502@centonline.com>
Message-ID: <56C23B2D.80302@centonline.com>

To follow up with a bit more detail

The version of OpenSSL is 1.0.2e.

The exact steps inside of my Linux environment that I take are

1) log in as su.
2) run "make clean"
3) run "sh config zlib"
the last line logged from this command is
"Configured for linux-elf"

4) run "make"

the make gets as far as

make[2]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto  -ldl -lz}"; 
LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DZLIB -DOPENSSL_THREADS 
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -O3 
-fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS 
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM 
-DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS; 
do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo 
$LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH 
${LDCMD} ${LDFLAGS} -o ${APPNAME:=ideatest} ideatest.o ${LIBDEPS} )
make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
gcc -I.. -I../include  -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -O3 -fomit-frame-pointer 
-Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM 
-DWHIRLPOOL_ASM -DGHASH_ASM   -c -o md2test.o md2test.c
make[2]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto  -ldl -lz}"; 
LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DZLIB -DOPENSSL_THREADS 
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -O3 
-fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS 
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM 
-DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS; 
do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo 
$LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH 
${LDCMD} ${LDFLAGS} -o ${APPNAME:=md2test} md2test.o ${LIBDEPS} )
/usr/lib/gcc/i686-redhat-linux/4.4.7/../../../crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status
make[2]: *** [link_app.] Error 1
make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
make[1]: *** [md2test] Error 2
make[1]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
make: *** [build_tests] Error 1


it  does make it through build bntest.o,  ectest.o , ecdsatest,o, 
ecdhtest.o, and ideatest.o




On 2/15/2016 1:59 PM, Rob Hermann wrote:
>
> I'm attempting to build OpenSSL on a Linux box, when I issue the make 
> from my OpenSSL directory (OpenSSLWork as seen here),   It builds all 
> the subdirectories under crypto,
> then proceeds to
>
> OpenSSLWork/engines
> OpenSSLWork/ssl
> OpenSSLWork/apps
>
> OpenSSLWork/test
>
>
> making all in test...
> make[1]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
> make[2]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
> ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto  -ldl}"; 
> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS 
> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN 
> -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS 
> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m 
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM 
> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS; 
> do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo 
> $LIBPATH | sed -e 's/ /:/g'`; 
> LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o 
> ${APPNAME:=md2test} md2test.o ${LIBDEPS} )
> _/usr/lib/gcc/i686-redhat-linux/4.4.7/../../../crt1.o: In function 
> `_start':__
> __(.text+0x18): undefined reference to `main'__
> _collect2: ld returned 1 exit status
> make[2]: *** [link_app.] Error 1
> make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
> make[1]: *** [md2test] Error 2
> make[1]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
> make: *** [build_tests] Error 1
>
> I know this means I'm missing the main() function the entry point for 
> all C programs.
> I'm trying to build OpenSSL using the procedures outlined in the 
> INSTALL document,  Has anyone seen this before and if so, what have 
> you done to "fix" it ?
>
> I've tried -nostartfiles as a linker option and that did not help.
>
>
>
>
>
>
>
>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160215/ef6fe676/attachment.html>

From matt at openssl.org  Mon Feb 15 22:08:11 2016
From: matt at openssl.org (Matt Caswell)
Date: Mon, 15 Feb 2016 22:08:11 +0000
Subject: [openssl-users] Building OpenSSL on Linux ,
 undefined reference to 'main'
In-Reply-To: <56C23B2D.80302@centonline.com>
References: <56C22E2B.1060502@centonline.com> <56C23B2D.80302@centonline.com>
Message-ID: <56C24C4B.7060605@openssl.org>



On 15/02/16 20:55, Rob Hermann wrote:
> To follow up with a bit more detail
> 
> The version of OpenSSL is 1.0.2e.
> 
> The exact steps inside of my Linux environment that I take are
> 
> 1) log in as su.
> 2) run "make clean"
> 3) run "sh config zlib"
> the last line logged from this command is
> "Configured for linux-elf"

The only slightly strange thing here is running "make clean" before
running "config". Normally I would run it afterwards.

>From the test directory, what does "ls -l md2test.c" tell us about the
link for that file?

Matt

> 
> 4) run "make"
> 
> the make gets as far as
> 
> make[2]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
> ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto  -ldl -lz}";
> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DZLIB -DOPENSSL_THREADS
> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -O3
> -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS
> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS;
> do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo
> $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH
> ${LDCMD} ${LDFLAGS} -o ${APPNAME:=ideatest} ideatest.o ${LIBDEPS} )
> make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
> gcc -I.. -I../include  -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -O3 -fomit-frame-pointer
> -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
> -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM
> -DWHIRLPOOL_ASM -DGHASH_ASM   -c -o md2test.o md2test.c
> make[2]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
> ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto  -ldl -lz}";
> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DZLIB -DOPENSSL_THREADS
> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -O3
> -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS
> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS;
> do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo
> $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH
> ${LDCMD} ${LDFLAGS} -o ${APPNAME:=md2test} md2test.o ${LIBDEPS} )
> /usr/lib/gcc/i686-redhat-linux/4.4.7/../../../crt1.o: In function `_start':
> (.text+0x18): undefined reference to `main'
> collect2: ld returned 1 exit status
> make[2]: *** [link_app.] Error 1
> make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
> make[1]: *** [md2test] Error 2
> make[1]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
> make: *** [build_tests] Error 1
> 
> 
> it  does make it through build bntest.o,  ectest.o , ecdsatest,o,
> ecdhtest.o, and ideatest.o
> 
> 
> 
> 
> On 2/15/2016 1:59 PM, Rob Hermann wrote:
>>
>> I'm attempting to build OpenSSL on a Linux box, when I issue the make
>> from my OpenSSL directory (OpenSSLWork as seen here),   It  builds all
>> the subdirectories under crypto,
>> then proceeds to
>>
>> OpenSSLWork/engines 
>> OpenSSLWork/ssl
>> OpenSSLWork/apps
>>
>> OpenSSLWork/test
>>
>>
>> making all in test...
>> make[1]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
>> make[2]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
>> ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto  -ldl}";
>> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS
>> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN
>> -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS
>> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
>> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS;
>> do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo
>> $LIBPATH | sed -e 's/ /:/g'`;
>> LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
>> ${APPNAME:=md2test} md2test.o ${LIBDEPS} )
>> _/usr/lib/gcc/i686-redhat-linux/4.4.7/../../../crt1.o: In function
>> `_start':__
>> __(.text+0x18): undefined reference to `main'__
>> _collect2: ld returned 1 exit status
>> make[2]: *** [link_app.] Error 1
>> make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>> make[1]: *** [md2test] Error 2
>> make[1]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>> make: *** [build_tests] Error 1
>>
>> I know this means I'm missing the main() function the entry point for
>> all C programs. 
>> I'm trying to build OpenSSL using the procedures outlined in the
>> INSTALL document,  Has anyone seen this before and if so, what have
>> you done to "fix" it ? 
>>
>> I've tried -nostartfiles as a linker option and that did not help. 
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> 
> 
> 

From rhermann at centonline.com  Mon Feb 15 22:21:06 2016
From: rhermann at centonline.com (Rob Hermann)
Date: Mon, 15 Feb 2016 16:21:06 -0600
Subject: [openssl-users] Building OpenSSL on Linux ,
 undefined reference to 'main'
In-Reply-To: <56C24C4B.7060605@openssl.org>
References: <56C22E2B.1060502@centonline.com> <56C23B2D.80302@centonline.com>
 <56C24C4B.7060605@openssl.org>
Message-ID: <56C24F52.7050400@centonline.com>



[root at rhlinuxdev test]# ls -l md2test.c
-r--r--r--. 1 rhermann centadmin 0 Feb 12 15:40 md2test.c


On 2/15/2016 4:08 PM, Matt Caswell wrote:
>
> On 15/02/16 20:55, Rob Hermann wrote:
>> To follow up with a bit more detail
>>
>> The version of OpenSSL is 1.0.2e.
>>
>> The exact steps inside of my Linux environment that I take are
>>
>> 1) log in as su.
>> 2) run "make clean"
>> 3) run "sh config zlib"
>> the last line logged from this command is
>> "Configured for linux-elf"
> The only slightly strange thing here is running "make clean" before
> running "config". Normally I would run it afterwards.
>
>  From the test directory, what does "ls -l md2test.c" tell us about the
> link for that file?
>
> Matt
>
>> 4) run "make"
>>
>> the make gets as far as
>>
>> make[2]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
>> ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto  -ldl -lz}";
>> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DZLIB -DOPENSSL_THREADS
>> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -O3
>> -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS
>> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
>> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS;
>> do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo
>> $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH
>> ${LDCMD} ${LDFLAGS} -o ${APPNAME:=ideatest} ideatest.o ${LIBDEPS} )
>> make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>> gcc -I.. -I../include  -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
>> -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -O3 -fomit-frame-pointer
>> -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
>> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
>> -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM
>> -DWHIRLPOOL_ASM -DGHASH_ASM   -c -o md2test.o md2test.c
>> make[2]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
>> ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto  -ldl -lz}";
>> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DZLIB -DOPENSSL_THREADS
>> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -O3
>> -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS
>> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
>> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS;
>> do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo
>> $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH
>> ${LDCMD} ${LDFLAGS} -o ${APPNAME:=md2test} md2test.o ${LIBDEPS} )
>> /usr/lib/gcc/i686-redhat-linux/4.4.7/../../../crt1.o: In function `_start':
>> (.text+0x18): undefined reference to `main'
>> collect2: ld returned 1 exit status
>> make[2]: *** [link_app.] Error 1
>> make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>> make[1]: *** [md2test] Error 2
>> make[1]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>> make: *** [build_tests] Error 1
>>
>>
>> it  does make it through build bntest.o,  ectest.o , ecdsatest,o,
>> ecdhtest.o, and ideatest.o
>>
>>
>>
>>
>> On 2/15/2016 1:59 PM, Rob Hermann wrote:
>>> I'm attempting to build OpenSSL on a Linux box, when I issue the make
>>> from my OpenSSL directory (OpenSSLWork as seen here),   It  builds all
>>> the subdirectories under crypto,
>>> then proceeds to
>>>
>>> OpenSSLWork/engines
>>> OpenSSLWork/ssl
>>> OpenSSLWork/apps
>>>
>>> OpenSSLWork/test
>>>
>>>
>>> making all in test...
>>> make[1]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
>>> make[2]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
>>> ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto  -ldl}";
>>> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS
>>> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN
>>> -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS
>>> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
>>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
>>> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS;
>>> do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo
>>> $LIBPATH | sed -e 's/ /:/g'`;
>>> LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
>>> ${APPNAME:=md2test} md2test.o ${LIBDEPS} )
>>> _/usr/lib/gcc/i686-redhat-linux/4.4.7/../../../crt1.o: In function
>>> `_start':__
>>> __(.text+0x18): undefined reference to `main'__
>>> _collect2: ld returned 1 exit status
>>> make[2]: *** [link_app.] Error 1
>>> make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>>> make[1]: *** [md2test] Error 2
>>> make[1]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>>> make: *** [build_tests] Error 1
>>>
>>> I know this means I'm missing the main() function the entry point for
>>> all C programs.
>>> I'm trying to build OpenSSL using the procedures outlined in the
>>> INSTALL document,  Has anyone seen this before and if so, what have
>>> you done to "fix" it ?
>>>
>>> I've tried -nostartfiles as a linker option and that did not help.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>


From matt at openssl.org  Mon Feb 15 23:01:29 2016
From: matt at openssl.org (Matt Caswell)
Date: Mon, 15 Feb 2016 23:01:29 +0000
Subject: [openssl-users] Building OpenSSL on Linux ,
 undefined reference to 'main'
In-Reply-To: <56C24F52.7050400@centonline.com>
References: <56C22E2B.1060502@centonline.com> <56C23B2D.80302@centonline.com>
 <56C24C4B.7060605@openssl.org> <56C24F52.7050400@centonline.com>
Message-ID: <56C258C9.10302@openssl.org>



On 15/02/16 22:21, Rob Hermann wrote:
> 
> 
> [root at rhlinuxdev test]# ls -l md2test.c
> -r--r--r--. 1 rhermann centadmin 0 Feb 12 15:40 md2test.c

That is slightly surprising for two reasons. Firstly that is an empty
file (size is 0). Secondly, it shouldn't be a file at all - it should be
a symbolic link! Looks like somehow or other it has got corrupted.

I also note that the date and timestamp is from a few days ago. Is that
when you last ran the build steps, or have you done it since?

>From the top level openssl directory try running "make clean" and "make
dclean" followed by going through the build steps again.

Matt


> 
> 
> On 2/15/2016 4:08 PM, Matt Caswell wrote:
>>
>> On 15/02/16 20:55, Rob Hermann wrote:
>>> To follow up with a bit more detail
>>>
>>> The version of OpenSSL is 1.0.2e.
>>>
>>> The exact steps inside of my Linux environment that I take are
>>>
>>> 1) log in as su.
>>> 2) run "make clean"
>>> 3) run "sh config zlib"
>>> the last line logged from this command is
>>> "Configured for linux-elf"
>> The only slightly strange thing here is running "make clean" before
>> running "config". Normally I would run it afterwards.
>>
>>  From the test directory, what does "ls -l md2test.c" tell us about the
>> link for that file?
>>
>> Matt
>>
>>> 4) run "make"
>>>
>>> the make gets as far as
>>>
>>> make[2]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
>>> ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto  -ldl -lz}";
>>> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DZLIB -DOPENSSL_THREADS
>>> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -O3
>>> -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS
>>> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
>>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
>>> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS;
>>> do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo
>>> $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH
>>> ${LDCMD} ${LDFLAGS} -o ${APPNAME:=ideatest} ideatest.o ${LIBDEPS} )
>>> make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>>> gcc -I.. -I../include  -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
>>> -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -O3 -fomit-frame-pointer
>>> -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
>>> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
>>> -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM
>>> -DWHIRLPOOL_ASM -DGHASH_ASM   -c -o md2test.o md2test.c
>>> make[2]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
>>> ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto  -ldl -lz}";
>>> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DZLIB -DOPENSSL_THREADS
>>> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -O3
>>> -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS
>>> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
>>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
>>> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS;
>>> do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo
>>> $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH
>>> ${LDCMD} ${LDFLAGS} -o ${APPNAME:=md2test} md2test.o ${LIBDEPS} )
>>> /usr/lib/gcc/i686-redhat-linux/4.4.7/../../../crt1.o: In function
>>> `_start':
>>> (.text+0x18): undefined reference to `main'
>>> collect2: ld returned 1 exit status
>>> make[2]: *** [link_app.] Error 1
>>> make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>>> make[1]: *** [md2test] Error 2
>>> make[1]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>>> make: *** [build_tests] Error 1
>>>
>>>
>>> it  does make it through build bntest.o,  ectest.o , ecdsatest,o,
>>> ecdhtest.o, and ideatest.o
>>>
>>>
>>>
>>>
>>> On 2/15/2016 1:59 PM, Rob Hermann wrote:
>>>> I'm attempting to build OpenSSL on a Linux box, when I issue the make
>>>> from my OpenSSL directory (OpenSSLWork as seen here),   It  builds all
>>>> the subdirectories under crypto,
>>>> then proceeds to
>>>>
>>>> OpenSSLWork/engines
>>>> OpenSSLWork/ssl
>>>> OpenSSLWork/apps
>>>>
>>>> OpenSSLWork/test
>>>>
>>>>
>>>> making all in test...
>>>> make[1]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
>>>> make[2]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
>>>> ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto  -ldl}";
>>>> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS
>>>> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN
>>>> -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS
>>>> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
>>>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
>>>> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS;
>>>> do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo
>>>> $LIBPATH | sed -e 's/ /:/g'`;
>>>> LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
>>>> ${APPNAME:=md2test} md2test.o ${LIBDEPS} )
>>>> _/usr/lib/gcc/i686-redhat-linux/4.4.7/../../../crt1.o: In function
>>>> `_start':__
>>>> __(.text+0x18): undefined reference to `main'__
>>>> _collect2: ld returned 1 exit status
>>>> make[2]: *** [link_app.] Error 1
>>>> make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>>>> make[1]: *** [md2test] Error 2
>>>> make[1]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>>>> make: *** [build_tests] Error 1
>>>>
>>>> I know this means I'm missing the main() function the entry point for
>>>> all C programs.
>>>> I'm trying to build OpenSSL using the procedures outlined in the
>>>> INSTALL document,  Has anyone seen this before and if so, what have
>>>> you done to "fix" it ?
>>>>
>>>> I've tried -nostartfiles as a linker option and that did not help.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
> 

From rhermann at centonline.com  Tue Feb 16 00:18:19 2016
From: rhermann at centonline.com (Rob Hermann)
Date: Mon, 15 Feb 2016 18:18:19 -0600
Subject: [openssl-users] Building OpenSSL on Linux ,
 undefined reference to 'main'
In-Reply-To: <56C258C9.10302@openssl.org>
References: <56C22E2B.1060502@centonline.com> <56C23B2D.80302@centonline.com>
 <56C24C4B.7060605@openssl.org> <56C24F52.7050400@centonline.com>
 <56C258C9.10302@openssl.org>
Message-ID: <56C26ACB.7000109@centonline.com>

that helped out greatly... the build gets past those errors.

1) "make clean"
2) "make dclean"
3) "sh config zlib"
4) "make"
5) "make tests" I get permission error on this one but that may just be 
my user.

  


On 2/15/2016 5:01 PM, Matt Caswell wrote:
>
> On 15/02/16 22:21, Rob Hermann wrote:
>>
>> [root at rhlinuxdev test]# ls -l md2test.c
>> -r--r--r--. 1 rhermann centadmin 0 Feb 12 15:40 md2test.c
> That is slightly surprising for two reasons. Firstly that is an empty
> file (size is 0). Secondly, it shouldn't be a file at all - it should be
> a symbolic link! Looks like somehow or other it has got corrupted.
>
> I also note that the date and timestamp is from a few days ago. Is that
> when you last ran the build steps, or have you done it since?
>
>  From the top level openssl directory try running "make clean" and "make
> dclean" followed by going through the build steps again.
>
> Matt
>
>
>>
>> On 2/15/2016 4:08 PM, Matt Caswell wrote:
>>> On 15/02/16 20:55, Rob Hermann wrote:
>>>> To follow up with a bit more detail
>>>>
>>>> The version of OpenSSL is 1.0.2e.
>>>>
>>>> The exact steps inside of my Linux environment that I take are
>>>>
>>>> 1) log in as su.
>>>> 2) run "make clean"
>>>> 3) run "sh config zlib"
>>>> the last line logged from this command is
>>>> "Configured for linux-elf"
>>> The only slightly strange thing here is running "make clean" before
>>> running "config". Normally I would run it afterwards.
>>>
>>>   From the test directory, what does "ls -l md2test.c" tell us about the
>>> link for that file?
>>>
>>> Matt
>>>
>>>> 4) run "make"
>>>>
>>>> the make gets as far as
>>>>
>>>> make[2]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
>>>> ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto  -ldl -lz}";
>>>> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DZLIB -DOPENSSL_THREADS
>>>> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -O3
>>>> -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS
>>>> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
>>>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
>>>> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS;
>>>> do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo
>>>> $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH
>>>> ${LDCMD} ${LDFLAGS} -o ${APPNAME:=ideatest} ideatest.o ${LIBDEPS} )
>>>> make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>>>> gcc -I.. -I../include  -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
>>>> -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -O3 -fomit-frame-pointer
>>>> -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
>>>> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
>>>> -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM
>>>> -DWHIRLPOOL_ASM -DGHASH_ASM   -c -o md2test.o md2test.c
>>>> make[2]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
>>>> ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto  -ldl -lz}";
>>>> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DZLIB -DOPENSSL_THREADS
>>>> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -O3
>>>> -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS
>>>> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
>>>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
>>>> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS;
>>>> do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo
>>>> $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH
>>>> ${LDCMD} ${LDFLAGS} -o ${APPNAME:=md2test} md2test.o ${LIBDEPS} )
>>>> /usr/lib/gcc/i686-redhat-linux/4.4.7/../../../crt1.o: In function
>>>> `_start':
>>>> (.text+0x18): undefined reference to `main'
>>>> collect2: ld returned 1 exit status
>>>> make[2]: *** [link_app.] Error 1
>>>> make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>>>> make[1]: *** [md2test] Error 2
>>>> make[1]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>>>> make: *** [build_tests] Error 1
>>>>
>>>>
>>>> it  does make it through build bntest.o,  ectest.o , ecdsatest,o,
>>>> ecdhtest.o, and ideatest.o
>>>>
>>>>
>>>>
>>>>
>>>> On 2/15/2016 1:59 PM, Rob Hermann wrote:
>>>>> I'm attempting to build OpenSSL on a Linux box, when I issue the make
>>>>> from my OpenSSL directory (OpenSSLWork as seen here),   It  builds all
>>>>> the subdirectories under crypto,
>>>>> then proceeds to
>>>>>
>>>>> OpenSSLWork/engines
>>>>> OpenSSLWork/ssl
>>>>> OpenSSLWork/apps
>>>>>
>>>>> OpenSSLWork/test
>>>>>
>>>>>
>>>>> making all in test...
>>>>> make[1]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
>>>>> make[2]: Entering directory `/home/rhermann/src/OpenSSLWork/test'
>>>>> ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto  -ldl}";
>>>>> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS
>>>>> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN
>>>>> -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS
>>>>> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
>>>>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
>>>>> -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS;
>>>>> do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo
>>>>> $LIBPATH | sed -e 's/ /:/g'`;
>>>>> LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
>>>>> ${APPNAME:=md2test} md2test.o ${LIBDEPS} )
>>>>> _/usr/lib/gcc/i686-redhat-linux/4.4.7/../../../crt1.o: In function
>>>>> `_start':__
>>>>> __(.text+0x18): undefined reference to `main'__
>>>>> _collect2: ld returned 1 exit status
>>>>> make[2]: *** [link_app.] Error 1
>>>>> make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>>>>> make[1]: *** [md2test] Error 2
>>>>> make[1]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'
>>>>> make: *** [build_tests] Error 1
>>>>>
>>>>> I know this means I'm missing the main() function the entry point for
>>>>> all C programs.
>>>>> I'm trying to build OpenSSL using the procedures outlined in the
>>>>> INSTALL document,  Has anyone seen this before and if so, what have
>>>>> you done to "fix" it ?
>>>>>
>>>>> I've tried -nostartfiles as a linker option and that did not help.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>


From rsalz at akamai.com  Tue Feb 16 21:24:08 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 16 Feb 2016 21:24:08 +0000
Subject: [openssl-users] OpenSSL version 1.1.0 pre release 3 published
In-Reply-To: <20160215190420.GA12045@openssl.org>
References: <20160215190420.GA12045@openssl.org>
Message-ID: <5676344ef8684de0b44603b528127657@ustx2ex-dag1mb1.msg.corp.akamai.com>


>    OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 3 has now
>    been made available. For details of changes and known issues see the
>    release notes at:

Just to emphasize one important point:  Our next release is planned to be Beta-1, in about a month.  After that, no new API's or features will be added to OpenSSL 1.1

	/r$

From rajesh_seetharam at thbs.com  Wed Feb 17 03:48:20 2016
From: rajesh_seetharam at thbs.com (rajesh_seetharam at thbs.com)
Date: Wed, 17 Feb 2016 09:18:20 +0530 (IST)
Subject: [openssl-users] OpenSSL
Message-ID: <1455680900.5208358@webmail.thbs.com>


Dear Team
 
 
 
We have installed httpd-2.2.25-win32-x86-openssl-0.9.8y apache web server which has openssl .9.8y as a part of the package, we ran the vulnerability scan for the same
 
 
 
The system admin team has suggested to upgrade openssl 0.9.8zb, how do we go about it?
 
 
 
We have used openssl to generate the server key and csr for ssl certificate installation and the ssl certificate certificate has been successfully installed.
 
 
 
After upgrading to the openssl 0.9.8zb, should we regenerate the server key and csr and reinstall the ssl certificate..
 
 
 
What is the advantage of using openssl 0.9.8zb over openssl-0.9.8y
 
 
 
Regards
 
Rajesh


******* DISCLAIMER: This email and any files transmitted with it are privileged and confidential information and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Torry Harris Business Solutions has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail.  The recipient should check this email and any attachments for the presence of viruses. THBS reserves the right to monitor and review the content of all messages sent to or from this e-mail address********



******* DISCLAIMER: This email and any files transmitted with it are privileged and confidential information and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Torry Harris Business Solutions has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail.  The recipient should check this email and any attachments for the presence of viruses. THBS reserves the right to monitor and review the content of all messages sent to or from this e-mail address.********
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160217/21e7ccce/attachment.html>

From openssl.org at 18informatique.com  Wed Feb 17 05:29:43 2016
From: openssl.org at 18informatique.com (mlrx)
Date: Wed, 17 Feb 2016 06:29:43 +0100
Subject: [openssl-users] ciphers
In-Reply-To: <56BE2133.5070901@18informatique.com>
References: <56BE2133.5070901@18informatique.com>
Message-ID: <56C40547.9040600@18informatique.com>

Le 12/02/2016 19:15, mlrx a ?crit :
> Hello !
> 
> I have some questions that I don't find answers by myself,
> even after read the cookbook and a lot of web pages.
> To be honest, I'm not really sure it's a problem but I
> need to verify.
> 
> Ok. I am setting up web server to host a critical java application.
> There is Apache in front of Tomcat and I want to enforce connections
> over https only with higher ciphers from TLS 1.2.
> [...]
> 
> Best regards,

Hello !

I have asked stupid questions or it isn't the right way to ask for
advices ? What's happening ?

Regards,
-- 
benoist

From mofassir_haque at yahoo.com  Wed Feb 17 05:51:25 2016
From: mofassir_haque at yahoo.com (Mofassir Ul Haque)
Date: Wed, 17 Feb 2016 05:51:25 +0000 (UTC)
Subject: [openssl-users] OpenSSL
In-Reply-To: <1455680900.5208358@webmail.thbs.com>
References: <1455680900.5208358@webmail.thbs.com>
Message-ID: <1850986985.5687895.1455688285893.JavaMail.yahoo@mail.yahoo.com>

Have a look at Changelog for 0.9.8 branch which is available at https://www.openssl.org/news/cl098.txt . Go through following changes to figure out the difference : 

Changes between 0.9.8za and 0.9.8zb [6 Aug 2014]

Changes between 0.9.8y and 0.9.8za [5 Jun 2014]


Regards,

Mofassir 

    On Wednesday, 17 February 2016 4:57 PM, "rajesh_seetharam at thbs.com" <rajesh_seetharam at thbs.com> wrote:
 

 Dear Team???We have installed httpd-2.2.25-win32-x86-openssl-0.9.8y apache web server which has openssl .9.8y as a part of the package, we ran the vulnerability scan for the same???The system admin team has suggested to upgrade openssl 0.9.8zb, how do we go about it????We have used openssl to generate the server key and csr for ssl certificate installation and the ssl certificate certificate has been successfully installed.???After upgrading to the openssl 0.9.8zb, should we regenerate the server key and csr and reinstall the ssl certificate.???What is the advantage of using openssl 0.9.8zb over openssl-0.9.8y???Regards?Rajesh


******* DISCLAIMER: This email and any files transmitted with it are privileged and confidential information and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Torry Harris Business Solutions has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. The recipient should check this email and any attachments for the presence of viruses. THBS reserves the right to monitor and review the content of all messages sent to or from this e-mail address********
******* DISCLAIMER: This email and any files transmitted with it are privileged and confidential information and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Torry Harris Business Solutions has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail.  The recipient should check this email and any attachments for the presence of viruses. THBS reserves the right to monitor and review the content of all messages sent to or from this e-mail address.********

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160217/f711be6f/attachment-0001.html>

From openssl-users at dukhovni.org  Wed Feb 17 06:09:24 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 17 Feb 2016 06:09:24 +0000
Subject: [openssl-users] ciphers
In-Reply-To: <56C40547.9040600@18informatique.com>
References: <56BE2133.5070901@18informatique.com>
 <56C40547.9040600@18informatique.com>
Message-ID: <20160217060924.GC19242@mournblade.imrryr.org>

On Wed, Feb 17, 2016 at 06:29:43AM +0100, mlrx wrote:

> I have asked stupid questions or it isn't the right way to ask for
> advices ? What's happening ?

I, for one, typically ignore posts that ask me to view detached
content via pastebin and the like.  Present content relevant to
your question in the body of the message, and try to ask one specific
and clear question at a time.

It sounds like you want TLS best-practice advice.  See,

    https://tools.ietf.org/html/rfc7525

-- 
	Viktor.

From openssl.org at 18informatique.com  Wed Feb 17 06:43:32 2016
From: openssl.org at 18informatique.com (mlrx)
Date: Wed, 17 Feb 2016 07:43:32 +0100
Subject: [openssl-users] ciphers
In-Reply-To: <20160217060924.GC19242@mournblade.imrryr.org>
References: <56BE2133.5070901@18informatique.com>
 <56C40547.9040600@18informatique.com>
 <20160217060924.GC19242@mournblade.imrryr.org>
Message-ID: <56C41694.4070700@18informatique.com>

Le 17/02/2016 07:09, Viktor Dukhovni a ?crit :
> On Wed, Feb 17, 2016 at 06:29:43AM +0100, mlrx wrote:
> 
>> I have asked stupid questions or it isn't the right way to ask for
>> advices ? What's happening ?
> 
> I, for one, typically ignore posts that ask me to view detached
> content via pastebin and the like.  Present content relevant to
> your question in the body of the message, and try to ask one specific
> and clear question at a time.
> 
> It sounds like you want TLS best-practice advice.  See,
> 
>     https://tools.ietf.org/html/rfc7525

Hello Viktor, thanks for answering.

It all about habits : others ml don't want to overload a thread
with logs anq others big stuff.

The question is : "do I need to do better to secure it?"

Thanks a lot and for the link : it's really useful.

I add my first message with all parts here :
> 
> I have some questions that I don't find answers by myself,
> even after read the cookbook and a lot of web pages.
> To be honest, I'm not really sure it's a problem but I
> need to verify.
> 
> Ok. I am setting up web server to host a critical java application.
> There is Apache in front of Tomcat and I want to enforce connections
> over https only with higher ciphers from TLS 1.2.
> Is it a good way ?

> There is a part of Apache's settings :
> ssl.conf :
>> # Apache 2.4
>> SSLCipherSuite           HIGH:kEECDH:+ECDSA:ECDSA:kEECDH:kEDH:+SHA:STRENGTH:   \
>>                          !aNULL:!eNULL:!LOW:!MEDIUM:!3DES:!MD5:!EXP:!RC4:!DSS: \
>>                          !PSK:!SRP:!kECDH:!CAMELLIA:!IDEA:!SEED
>> SSLHonorCipherOrder      on
>> SSLProtocol              -All +TLSv1.2
>> SSLCompression           off
>> SSLInsecureRenegotiation off

> the vhost file :
>> <VirtualHost *:443>
>>     ServerName   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>     ServerAdmin  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>     DocumentRoot xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>     ErrorLog     xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>     CustomLog    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>     LogLevel     warn
>> 
>>     <Directory />
>>         Options FollowSymLinks
>>         AllowOverride All
>>     </Directory>
>> 
>>     <Directory xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>>         Options Indexes FollowSymLinks MultiViews
>>         AllowOverride All
>>         Order allow,deny
>>         allow from all
>>     </Directory>
>> 
>>     ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
>> 
>>     <Directory /usr/lib/cgi-bin>
>>         AllowOverride None
>>         Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
>>         Order allow,deny
>>         Allow from all
>>     </Directory>
>> 
>>     <Directory /usr/share/doc/>
>>         AllowOverride None
>>         Options Indexes MultiViews FollowSymLinks
>>         Order deny,allow
>>         Deny from all
>>         Allow from 127.0.0.0/255.0.0.0 ::1/128
>>     </Directory>
>> 
>>     <IfModule mod_jk.c>
>>         JkMount /* ajp13_worker
>>         JkMount / ajp13_worker
>>     </IfModule>
>> 
>>     <IfModule mod_ssl.c>
>>         SSLEngine on
>>         ServerSignature         Off
>>         BrowserMatch .*MSIE.* nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
>>         SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
>>         SSLCertificateFile     xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>         SSLCertificateKeyFile  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>     </IfModule>
>> </VirtualHost>

> 
> The public part works good, no problem.
> For the moment (testing), I use an auto-signed certificate.
> Of course, I will use "real" CA signed EV certificate in
> production.
> 
> Well, I've did some tests. Here is a part of some nmap and testssl.sh
> results :
>
>> ###############################################################
>> nmap --script ssl-cert,ssl-enum-ciphers -p 443 my.dn.tld
>> 
>> # 443/tcp open  https
>> # | ssl-cert: Subject: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> # |           Issuer:  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> # | Public Key type: ec
>> # | Public Key bits: 256
>> # | Not valid before: 2016-01-05T08:13:37+00:00
>> # | Not valid after:  2017-01-04T08:13:37+00:00
>> # | MD5:   1fc9 5b87 be04 a6a8 0939 d05d 3f24 675a
>> # |_SHA-1: 21be 7dd4 2500 c813 89cc a9c0 ca9a 329a 8beb 9159
>> # | ssl-enum-ciphers: 
>> # |   SSLv3: No supported ciphers found
>> # |   TLSv1.2: 
>> # |     ciphers: 
>> # |       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA    - strong
>> # |       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 - strong
>> # |       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - strong
>> # |       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA    - strong
>> # |       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 - strong
>> # |       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - strong
>> # |     compressors: 
>> # |       NULL
>> # |_  least strength: strong
>> 
>> ###############################################################
>> testssl.sh / partial results
>> 
>> Null Ciphers : Local problem : No Null Ciphers configured in /usr/bin/openssl
>> 40 bit encryption : not offered (OK)
>> 56 bit encryption : Local problem : No 56 bit encryption configured in /usr/bin/openssl
>> 
>> Has server cipher order ? : nope (NOT ok)
>> Negotiated protocol : TLSv1.2
>> Negotiated cipher : ECDHE-ECDSA-AES256-GCM-SHA384 (limited sens as client will pick)
>> Negotiated cipher per proto : (limited sens as client will pick)
>>     ECDHE-ECDSA-AES256-GCM-SHA384: TLSv1.2
>> No further cipher order check has been done as order is determined by the client
>> 
>> All the rest seems to be ok (green resulsts)
>> 
>> ###############################################################

> Is everything ok or do I need to change something ?
> Could you give some advice to make it safer please ?
> I really want to be closer to the state of the art and understand it.
> 
> A last thing : please, accept my apologies... I don't speak english
> anymore since many many years.

Best regards,
-- 
benoist

From openssl-users at dukhovni.org  Wed Feb 17 06:57:04 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 17 Feb 2016 06:57:04 +0000
Subject: [openssl-users] ciphers
In-Reply-To: <56C41694.4070700@18informatique.com>
References: <56BE2133.5070901@18informatique.com>
 <56C40547.9040600@18informatique.com>
 <20160217060924.GC19242@mournblade.imrryr.org>
 <56C41694.4070700@18informatique.com>
Message-ID: <20160217065703.GD19242@mournblade.imrryr.org>

On Wed, Feb 17, 2016 at 07:43:32AM +0100, mlrx wrote:

> > Present content relevant to
> > your question in the body of the message, and try to ask one specific
> > and clear question at a time.
> 
> The question is : "do I need to do better to secure it?"

I think this fails the specificity requirement.  If something in
the TLS BCP RFC is not clear, feel free to ask for help.

-- 
	Viktor.

From openssl-users at dukhovni.org  Wed Feb 17 07:15:03 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 17 Feb 2016 07:15:03 +0000
Subject: [openssl-users] ciphers
In-Reply-To: <56C41694.4070700@18informatique.com>
References: <56BE2133.5070901@18informatique.com>
 <56C40547.9040600@18informatique.com>
 <20160217060924.GC19242@mournblade.imrryr.org>
 <56C41694.4070700@18informatique.com>
Message-ID: <20160217071502.GE19242@mournblade.imrryr.org>

On Wed, Feb 17, 2016 at 07:43:32AM +0100, mlrx wrote:

> >> # Apache 2.4
> >> SSLCipherSuite           HIGH:kEECDH:+ECDSA:ECDSA:kEECDH:kEDH:+SHA:STRENGTH:   \
> >>                          !aNULL:!eNULL:!LOW:!MEDIUM:!3DES:!MD5:!EXP:!RC4:!DSS: \
> >>                          !PSK:!SRP:!kECDH:!CAMELLIA:!IDEA:!SEED

This setting is a horrible mess, whichever site recommended this,
never listen to anything they recommend again.  I sure hope Apache
provides a more sensible default, but if you must, try one of:

  * !COMPLEMENTOFDEFAULT:AESGCM+aRSA+kEECDH:AESGCM+aRSA+kEDH:@STRENGTH
  * !COMPLEMENTOFDEFAULT:AES+aRSA+kEECDH:AES+aRSA+kEDH:@STRENGTH
  * !COMPLEMENTOFDEFAULT:AES+aRSA+kEECDH:AES+aRSA+kEDH:AES+aRSA+kRSA:@STRENGTH

The first one gives you the RFC7525 ciphers, the second allows
non-AEAD ciphers, and the third also non-PFS ciphers.  Which is
best for you depends on what clients you need to interoperate with.

You'll want a 2048-bit RSA key, secp384r1 or secp256r1 for an EECDH
curve, and DH parameters based on a 2048-bit EDH safe prime.

This answers one possible question about your configuration.

-- 
	Viktor.

From beldmit at gmail.com  Wed Feb 17 08:04:34 2016
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Wed, 17 Feb 2016 11:04:34 +0300
Subject: [openssl-users] [openssl-dev] OpenSSL version 1.1.0 pre release
	3 published
In-Reply-To: <5676344ef8684de0b44603b528127657@ustx2ex-dag1mb1.msg.corp.akamai.com>
References: <20160215190420.GA12045@openssl.org>
 <5676344ef8684de0b44603b528127657@ustx2ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CADqLbzLed+10pFB72ODAm2QDhByPJn510GAm75zM7dBFBg1sEQ@mail.gmail.com>

Dear Rich,


> Just to emphasize one important point:  Our next release is planned to be
> Beta-1, in about a month.  After that, no new API's or features will be
> added to OpenSSL 1.1
>
>
If so, could you take a look at RT#4267?

Thank you!

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160217/c12b6e4a/attachment.html>

From rsalz at akamai.com  Wed Feb 17 13:44:15 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 17 Feb 2016 13:44:15 +0000
Subject: [openssl-users] ciphers
In-Reply-To: <56C41694.4070700@18informatique.com>
References: <56BE2133.5070901@18informatique.com>
 <56C40547.9040600@18informatique.com>
 <20160217060924.GC19242@mournblade.imrryr.org>
 <56C41694.4070700@18informatique.com>
Message-ID: <5981e8e93c81493289749c6d656264be@ustx2ex-dag1mb1.msg.corp.akamai.com>

If all you want is TLS 1.2, then this line is enough:

> >> SSLProtocol              -All +TLSv1.2
> >> SSLCompression           off
> >> SSLInsecureRenegotiation off



From gustavotabares at gmail.com  Wed Feb 17 18:29:12 2016
From: gustavotabares at gmail.com (Gustavo Tabares)
Date: Wed, 17 Feb 2016 13:29:12 -0500
Subject: [openssl-users] Statically link FIPS OpenSSL to shared library
	application
Message-ID: <CAJt7XrVmv8wQHVAe0vzaJ0waxE10bsBiNAAhGDx-qkDiit9ftQ@mail.gmail.com>

Hello,

I?m trying to statically link OpenSSL to my C++ shared library application
on Linux. I?ve followed the instructions outlined in the Fipsld and C++
Wiki page and everything builds fine. However I?m getting a fingerprint
mismatch when calling FIPS_mode_set. If I change my shared library to an
executable (by adding a main function) everything works fine.

Besides building fipspremain.c with -x c / -x none (as per the Wiki page)
and specifying the -dso flag for the incore script, is there anything else
that I may be missing? The Wiki page covers building executables, but I
didn?t think there was much difference between the two.


Thanks,
Gustavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160217/4ec90606/attachment-0001.html>

From shaun.amyotte at gmail.com  Wed Feb 17 19:58:02 2016
From: shaun.amyotte at gmail.com (Shaun Amyotte)
Date: Wed, 17 Feb 2016 19:58:02 +0000
Subject: [openssl-users] Possible bug -
	SSL_ERROR_RX_UNEXPECTED_CHANGE_CIPHER error in FireFox 44.0
Message-ID: <CAMC0eVqveWk=6z_Q39tVexSUOZjgEp0VE8BRJpcv-L452Zk3ww@mail.gmail.com>

Hello,

I'm hoping you could provide some assistance in diagnosing/investigating an
issue my users are experiencing with FireFox.  Our CDN is using
OpenSSL  1.0.1j-1.4.0.420.  In addition to the below, I did try contacting
Dr. Henson on this topic (his name was referenced in some of the old online
posts) but suspect he has other pressing matters to deal with.  I've
included the body of the message to him here:

--
I'd be thankful for you guidance in an issue I'm investigating.  The error
in the subject has been encountered at random by some of my users when
using Firefox.  In researching this issue I've come across a number of
dated articles/bits of information that suggest at one point there was a
bug in OpenSSL 0.9.8g that caused this error.

Since this is a client side error, I understand this may no longer be tied
to the original OpenSSL bug, however I was hoping to rule it out.  In doing
so I wanted to trace the changelist referenced in the firefox bug post @
https://bugzilla.mozilla.org/show_bug.cgi?id=430703 however it looks as
though the tranition to GitHub has since made the link obsolete.  The link
in question is http://cvs.openssl.org/chngview?cn=17098 and there is
reference to your involvement in this issue.

I've checked the release notes @
https://www.openssl.org/news/changelog.html#x35 between g to h and h to i
to see if I could get any details that way, but admittedly much of the ssl
jargon is greek to me.

Is there anything you could offer that would help me trace the change that
was implemented in 17098 ?
--

---------- Forwarded message ---------
From: Martin Thomson <mt at mozilla.com>
Date: Tue, Feb 16, 2016 at 5:40 PM
Subject: Re: SSL_ERROR_RX_UNEXPECTED_CHANGE_CIPHER error in Firefox 44.0
To: mozilla's crypto code discussion list <dev-tech-crypto at lists.mozilla.org
>


Hi Shaun,

As the documentation suggests, this is very likely a server problem. We
have recently audited the NSS state machine and I think it would be
unlikely that this is a client issue.

I would definitely look at the servers. Old versions of openssl are full of
holes anyway.

If you are able to capture logs for an affected connection and share those
we might be able to help you diagnose the issue. Or maybe you can point us
at a public endpoint that reliably produces the error.

--Martin
On Feb 17, 2016 1:50 AM, "Shaun Amyotte" <shaun.amyotte at gmail.com> wrote:

> Hello,
>
> I initially posted this to support.mozilla.org @
>
>
https://support.mozilla.org/en-US/questions/1109175?utm_campaign=questions-reply&utm_medium=email&utm_source=notification
>
> who suggested I redirect this to the news group.
>
> Any assistance you could provide would be appreciated
> --
>
> The error in the subject has been encountered at random by some of my
users
> when using Firefox. In researching this issue I've come across a number of
> dated articles/bits of information that suggest at one point there was a
> bug in OpenSSL 0.9.8g that caused this error. We are running
> 1.0.1j-1.4.0.420
>
> Since this is a client side error, I understand this may no longer be tied
> to the original OpenSSL bug, however I was hoping to rule it out. In doing
> so I wanted to trace the changelist referenced in the firefox bug post @
> https://bugzilla.mozilla.org/show_bug.cgi?id=430703 however it looks as
> though the tranition to GitHub has since made the link obsolete. The link
> in question is http://cvs.openssl.org/chngview?cn=17098 and there is
> reference to your involvement in this issue.
>
> I have sent an email to one of the developers at OpenSSL who was
referenced
> in the links above but have not heard back. What I'm wondering is if there
> is any client side tracing/debugging I can enable to get more details on
> this issue?
>
> The error is referenced here but provides limited guidance beyond 'its a
> server side issue'
>
>
>
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/SSL_functions/sslerr.html
>
> --
> --
> dev-tech-crypto mailing list
> dev-tech-crypto at lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
dev-tech-crypto mailing list
dev-tech-crypto at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160217/0b3431e7/attachment.html>

From sahib.jakhar at gmail.com  Wed Feb 17 20:07:34 2016
From: sahib.jakhar at gmail.com (Sahib Jakhar)
Date: Thu, 18 Feb 2016 01:37:34 +0530
Subject: [openssl-users] Intermittent SSL_shutdown error
Message-ID: <CAE+y=w4-4CxsMuDS6pGEp_s_NJUsWXuYCQdyt5PqcUo2pCo85Q@mail.gmail.com>

Hi,

I am trying to create a SSL connection (call it connection 2) inside
another SSL connection (call it connection 1). Connection 2 is used to
connect to a machine which is hidden behind the machine to which I
connect using connection 1. Once Connection 2 is established (i.e. SSL
handshake finishes) I close connection 1.

The problem I am facing is SSL_shutdown is returning error (return
code < 0). Most of the time it works, and I am successfully able to
communicate over connection 2 after connection 1 has been closed. But
suddenly once out of the blue it returns error. Subsequent SSL_read on
connection 2 fail with error.

**SSL_get_error returns: 2**

**ERR_error_string returns: error:00000002:lib(0):func(0):system lib**


Note connection 1 is with a java server and connection 2 is with a
openssl based server. Can somebody please help me identify what could
be going wrong over here?

Here is some code for your reference to help you understand what I am doing:


    SSL *ssl; // connection 1
    SSL *ssl2; //connection 2

    // ssl is already established at this point
    // i.e. connection 1 already exists.

    BIO *rbio = BIO_new (BIO_s_mem());
    BIO *wbio = BIO_new (BIO_s_mem());

    SSL_set_bio (ssl, rbio, wbio);
    SSL_set_connect_state (ssl);

    while (!SSL_is_init_finished(ssl))
    {
        ret = SSL_do_handshake (ssl);
        if (ret == 1) /* Handshake was successful */
        {
            break;
        }

        ssl_error = SSL_get_error (ssl, ret);

        if (ssl_error != SSL_ERROR_WANT_READ
        && ssl_error != SSL_ERROR_WANT_WRITE)
        {
            // report failed
            return;
        }

        size = BIO_ctrl_pending (wbio);
        if (size > 0)
        {
            size = BIO_read (wbio, buff, size);
            if (size <= 0)
            {
                // report failed this shouldn't happen
                continue;
            }

            // Write using SSL_WRITE to connection 1
        }

        /* Read only if SSL_do_handshake expects */
        if (ssl_error == SSL_ERROR_WANT_READ)
        {
            // read into buff from SSL_READ from connection 1
            // continue if noting available

            BIO_write (rbio, buff, size);
            free (buff);
        }
    }

    // Write to SSL connection 1 handshake is successful
    // to let Javaserver know that it should close ssl part of connection 1

    SSL_set_quiet_shutdown (ssl, 0);
    ret = SSL_shutdown (ssl);
    if (ret == 0)
        ret = SSL_shutdown (ssl);
    if (ret < 0)
    {
        /* FAILS HERE: This is where it fails sometimes
        (may be once or twice out of 10)*/
    }

    // Some clean up

    /* We are done with cleanup of old SSL connection,
     * and establishing new SSL connection to the new
     * one. Now let's start communicating using connection 2.
     * But before that we need to do a few things. */

    sock_bio = BIO_new_socket (INTERNAL (agentbi)->sock_fd, BIO_NOCLOSE);
    SSL_set_bio (ssl2, sock_bio, sock_bio);

    // From this point onwards we use connection 2 to communicate as
    // connection 1 has been reduced to tcp only.



On the java side I can see close_notify being sent and received:
I call close on SSLSocket once client tells that its SSL handshake for
connection 2 is complete.

From pdrotter at us.ibm.com  Wed Feb 17 19:19:37 2016
From: pdrotter at us.ibm.com (Neptune)
Date: Wed, 17 Feb 2016 12:19:37 -0700 (MST)
Subject: [openssl-users] Statically link FIPS OpenSSL to shared library
	application
In-Reply-To: <CAJt7XrVmv8wQHVAe0vzaJ0waxE10bsBiNAAhGDx-qkDiit9ftQ@mail.gmail.com>
References: <CAJt7XrVmv8wQHVAe0vzaJ0waxE10bsBiNAAhGDx-qkDiit9ftQ@mail.gmail.com>
Message-ID: <1455736777631-63770.post@n7.nabble.com>

Are you supplying a base address for the shared library when linking? I ran
into this same problem but for Win32 .dll, but I'm not sure if there is the
same requirement for Linux so's. The problem was without supplying a base
address, the HMAC signature could not be found and the power on self test
would fail. Supplying the /BASE option in the link stage resolved this -
except in cases where the desired address was already occupied when the dll
was loaded and the dll was rebased - not sure if this is an issue with
Linux.

So, I suspect it is failing either because the fingerprint cannot be found
due to the base address not being supplied during linking, or your shared
object is not getting the address you want and the HMAC is not where the
power on self test expects to find it.

I hope this helps.



--
View this message in context: http://openssl.6102.n7.nabble.com/Statically-link-FIPS-OpenSSL-to-shared-library-application-tp63763p63770.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From steve at openssl.org  Wed Feb 17 20:20:30 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 17 Feb 2016 20:20:30 +0000
Subject: [openssl-users] Statically link FIPS OpenSSL to shared library
 application
In-Reply-To: <CAJt7XrVmv8wQHVAe0vzaJ0waxE10bsBiNAAhGDx-qkDiit9ftQ@mail.gmail.com>
References: <CAJt7XrVmv8wQHVAe0vzaJ0waxE10bsBiNAAhGDx-qkDiit9ftQ@mail.gmail.com>
Message-ID: <20160217202030.GA6250@openssl.org>

On Wed, Feb 17, 2016, Gustavo Tabares wrote:

> Hello,
> 
> I???m trying to statically link OpenSSL to my C++ shared library application
> on Linux. I???ve followed the instructions outlined in the Fipsld and C++
> Wiki page and everything builds fine. However I???m getting a fingerprint
> mismatch when calling FIPS_mode_set. If I change my shared library to an
> executable (by adding a main function) everything works fine.
> 
> Besides building fipspremain.c with -x c / -x none (as per the Wiki page)
> and specifying the -dso flag for the incore script, is there anything else
> that I may be missing? The Wiki page covers building executables, but I
> didn???t think there was much difference between the two.
> 

What commands are you using to build the FIPS module, OpenSSL and to link your
application?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From gustavotabares at gmail.com  Wed Feb 17 21:35:46 2016
From: gustavotabares at gmail.com (Gustavo Tabares)
Date: Wed, 17 Feb 2016 16:35:46 -0500
Subject: [openssl-users] Statically link FIPS OpenSSL to shared library
	application
Message-ID: <CAJt7XrXAH6ctTbOU1+q42Hck9w_ijqiqbUMSA6LwjHFg_xvxpg@mail.gmail.com>

My problem was solved by adding -Wl,-Bsymbolic to the list of compiler
flags. I found this from an old post on this mailing list. It's still not
clear why this flag is needed though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160217/9e4f656a/attachment-0001.html>

From dev at pgnd.us  Thu Feb 18 01:46:00 2016
From: dev at pgnd.us (PGNd)
Date: Wed, 17 Feb 2016 17:46:00 -0800
Subject: [openssl-users] follow-up to:  ChaCha20/Poly1305 in OpenSSL?
Message-ID: <1455759960.2891653.524441962.42194031@webmail.messagingengine.com>

I'm looking for Openssl's Chacha20/Poly1305 cipher support, supported client-side in Chrome/Chromium-dev, and server-side in Nginx.

Last I was able to find on list

	[openssl-users] ChaCha20/Poly1305 in OpenSSL?
	Fri Mar 27 05:05:59 UTC 2015
	https://mta.openssl.org/pipermail/openssl-users/2015-March/000934.html

		"... It appears we are also waiting on the cipher suite values. ..."

but nothing more, afaict.

Currently in 1.0.2f

	openssl version
		OpenSSL 1.0.2f  28 Jan 2016

	openssl ciphers | grep -i chacha
		(empty)

and there's no mention of it here,

	https://www.openssl.org/docs/man1.0.2/apps/ciphers.html

but, in master

	https://www.openssl.org/docs/manmaster/apps/ciphers.html

They're there 

	...
	ChaCha20-Poly1305 cipher suites from draft-ietf-tls-chacha20-poly1305-04, extending TLS v1.2
		...

According to

	https://ianix.com/pub/chacha-deployment.html

Chacha support is available now in 

	LibreSSL, wolfSSL, BoringSSL, Botan, GnuTLS

& for Openssl, "ChaCha support coming soon!"

What's current plan status for these ciphers?

Not until 1.1.0 release? Or earlier?


From dev at pgnd.us  Thu Feb 18 01:48:30 2016
From: dev at pgnd.us (PGNd)
Date: Wed, 17 Feb 2016 17:48:30 -0800
Subject: [openssl-users] follow-up to:  ChaCha20/Poly1305 in OpenSSL?
Message-ID: <1455760110.2892226.524443122.716360D3@webmail.messagingengine.com>

I'm looking for Openssl's Chacha20/Poly1305 cipher support, supported client-side in Chrome/Chromium-dev, and server-side in Nginx.

Last I was able to find on list

	[openssl-users] ChaCha20/Poly1305 in OpenSSL?
	Fri Mar 27 05:05:59 UTC 2015
	https://mta.openssl.org/pipermail/openssl-users/2015-March/000934.html

		"... It appears we are also waiting on the cipher suite values. ..."

but nothing more, afaict.

Currently in 1.0.2f

	openssl version
		OpenSSL 1.0.2f  28 Jan 2016

	openssl ciphers | grep -i chacha
		(empty)

and there's no mention of it here,

	https://www.openssl.org/docs/man1.0.2/apps/ciphers.html

but, in master

	https://www.openssl.org/docs/manmaster/apps/ciphers.html

They're there 

	...
	ChaCha20-Poly1305 cipher suites from draft-ietf-tls-chacha20-poly1305-04, extending TLS v1.2
		...

According to

	https://ianix.com/pub/chacha-deployment.html

Chacha support is available now in 

	LibreSSL, wolfSSL, BoringSSL, Botan, GnuTLS

& for Openssl, "ChaCha support coming soon!"

What's current plan status for these ciphers?

Not until 1.1.0 release? Or earlier?


From rsalz at akamai.com  Thu Feb 18 02:00:30 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 18 Feb 2016 02:00:30 +0000
Subject: [openssl-users] follow-up to:  ChaCha20/Poly1305 in OpenSSL?
In-Reply-To: <1455759960.2891653.524441962.42194031@webmail.messagingengine.com>
References: <1455759960.2891653.524441962.42194031@webmail.messagingengine.com>
Message-ID: <4ba675efa9424ceebc24e0a120de582d@ustx2ex-dag1mb1.msg.corp.akamai.com>



> What's current plan status for these ciphers?
> 
> Not until 1.1.0 release? Or earlier?

Yup, 1.1.  It's a new feature so it doesn't go into current releases which only get fixes.

And the code that's in master, which just released alpha-3, rocks. :) 

From dev at pgnd.us  Thu Feb 18 02:03:39 2016
From: dev at pgnd.us (PGNd)
Date: Wed, 17 Feb 2016 18:03:39 -0800
Subject: [openssl-users] follow-up to:  ChaCha20/Poly1305 in OpenSSL?
In-Reply-To: <4ba675efa9424ceebc24e0a120de582d@ustx2ex-dag1mb1.msg.corp.akamai.com>
References: <1455759960.2891653.524441962.42194031@webmail.messagingengine.com>
 <4ba675efa9424ceebc24e0a120de582d@ustx2ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <1455761019.2896224.524451546.611B1274@webmail.messagingengine.com>



On Wed, Feb 17, 2016, at 06:00 PM, Salz, Rich wrote:
> > What's current plan status for these ciphers?
> > 
> > Not until 1.1.0 release? Or earlier?
> 
> Yup, 1.1.  It's a new feature so it doesn't go into current releases which only get fixes.

Thanks.

> And the code that's in master, which just released alpha-3, rocks. :) 

So the choice is

(1) 1.0.2f + cloudflare patch
(2) 1.1.0-alpha3

If you'd simply "hurry up" ... ;-)

From rsalz at akamai.com  Thu Feb 18 02:05:12 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 18 Feb 2016 02:05:12 +0000
Subject: [openssl-users] follow-up to:  ChaCha20/Poly1305 in OpenSSL?
In-Reply-To: <1455761019.2896224.524451546.611B1274@webmail.messagingengine.com>
References: <1455759960.2891653.524441962.42194031@webmail.messagingengine.com>
 <4ba675efa9424ceebc24e0a120de582d@ustx2ex-dag1mb1.msg.corp.akamai.com>
 <1455761019.2896224.524451546.611B1274@webmail.messagingengine.com>
Message-ID: <d274485928114a11bb1865b8420433de@ustx2ex-dag1mb1.msg.corp.akamai.com>


> (1) 1.0.2f + cloudflare patch
> (2) 1.1.0-alpha3

Did CF update their patch to the official version and codepoints?  Cool.


From dev at pgnd.us  Thu Feb 18 02:10:37 2016
From: dev at pgnd.us (PGNd)
Date: Wed, 17 Feb 2016 18:10:37 -0800
Subject: [openssl-users] follow-up to:  ChaCha20/Poly1305 in OpenSSL?
In-Reply-To: <d274485928114a11bb1865b8420433de@ustx2ex-dag1mb1.msg.corp.akamai.com>
References: <1455759960.2891653.524441962.42194031@webmail.messagingengine.com>
 <4ba675efa9424ceebc24e0a120de582d@ustx2ex-dag1mb1.msg.corp.akamai.com>
 <1455761019.2896224.524451546.611B1274@webmail.messagingengine.com>
 <d274485928114a11bb1865b8420433de@ustx2ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <1455761437.2897147.524456186.3D273919@webmail.messagingengine.com>



On Wed, Feb 17, 2016, at 06:05 PM, Salz, Rich wrote:
> 
> > (1) 1.0.2f + cloudflare patch
> > (2) 1.1.0-alpha3
> 
> Did CF update their patch to the official version and codepoints?  Cool.
> 

Apparently.  But 1st try has one glitch ...

patch -p1 < openssl__chacha20_poly1305_draft_and_rfc_ossl102f.patch 
	patching file Configure
	patching file Makefile.org
	patching file apps/speed.c
	patching file crypto/chacha20poly1305/Makefile
	patching file crypto/chacha20poly1305/asm/chacha20_avx.pl
	patching file crypto/chacha20poly1305/asm/chacha20_avx2.pl
	patching file crypto/chacha20poly1305/asm/poly1305_avx.pl
	patching file crypto/chacha20poly1305/asm/poly1305_avx2.pl
	patching file crypto/chacha20poly1305/asm/poly1305_x64.pl
	patching file crypto/chacha20poly1305/chacha20.c
	patching file crypto/chacha20poly1305/chacha20poly1305.h
	patching file crypto/chacha20poly1305/chapolytest.c
	patching file crypto/chacha20poly1305/poly1305.c
	patching file crypto/cryptlib.c
	patching file crypto/evp/Makefile
	patching file crypto/evp/e_chacha20poly1305.c
	patching file crypto/evp/evp.h
	patching file ssl/s3_lib.c
	patching file ssl/ssl.h
	patching file ssl/ssl_ciph.c
	patching file ssl/ssl_locl.h
	patching file ssl/tls1.h
	patching file test/Makefile
	Hunk #8 FAILED at 614.
	1 out of 8 hunks FAILED -- saving rejects to file test/Makefile.rej

cat test/Makefile.rej 
	--- test/Makefile
	+++ test/Makefile
	@@ -614,6 +622,7 @@ clienthellotest.o: clienthellotest.c
	 constant_time_test.o: ../crypto/constant_time_locl.h ../e_os.h
	 constant_time_test.o: ../include/openssl/e_os2.h
	 constant_time_test.o: ../include/openssl/opensslconf.h constant_time_test.c
	+chapolytest.o: ../include/openssl/chacha20poly1305.h chapolytest.c
	 destest.o: ../include/openssl/des.h ../include/openssl/des_old.h
	 destest.o: ../include/openssl/e_os2.h ../include/openssl/opensslconf.h
	 destest.o: ../include/openssl/ossl_typ.h ../include/openssl/safestack.h


From dev at pgnd.us  Thu Feb 18 02:13:08 2016
From: dev at pgnd.us (PGNd)
Date: Wed, 17 Feb 2016 18:13:08 -0800
Subject: [openssl-users] follow-up to:  ChaCha20/Poly1305 in OpenSSL?
In-Reply-To: <1455761437.2897147.524456186.3D273919@webmail.messagingengine.com>
References: <1455759960.2891653.524441962.42194031@webmail.messagingengine.com>
 <4ba675efa9424ceebc24e0a120de582d@ustx2ex-dag1mb1.msg.corp.akamai.com>
 <1455761019.2896224.524451546.611B1274@webmail.messagingengine.com>
 <d274485928114a11bb1865b8420433de@ustx2ex-dag1mb1.msg.corp.akamai.com>
 <1455761437.2897147.524456186.3D273919@webmail.messagingengine.com>
Message-ID: <1455761588.2897829.524457282.439BD973@webmail.messagingengine.com>

pebkac.

clean re-DL of Openssl 1.0.2f sources fixes that ; patch applies cleanly.

From shetty.bharathraj at gmail.com  Thu Feb 18 03:41:23 2016
From: shetty.bharathraj at gmail.com (Bharathraj Shetty)
Date: Thu, 18 Feb 2016 09:11:23 +0530
Subject: [openssl-users] Changing the encoding in openssl
Message-ID: <CAJEXhEu0ps-RN3ZFGo0RHLPQbwU-zd0Q7n4L8jw5=zTOmSi2pw@mail.gmail.com>

Hi champions,

I would like to use the openssl for encrypting the data and would like to
get the encrypted data in "hex" format rather than UTF-8 format.
Lets I have a bytes "90909090909090909090909090909090" i.e. of 16 bytes in
hex(each char takes 1 nibble when you load into memory). After encrypting i
should get the same number of bytes i.e. 16bytes (32 chars). and I would
like to get that out of encrypted bytes in "hex or binary" form. Is it
possible to get it that way?

Appreciate your help!!

regards,
Bharath
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160218/43069158/attachment-0001.html>

From krzysiekw444 at gmail.com  Thu Feb 18 11:38:33 2016
From: krzysiekw444 at gmail.com (krzysztof w)
Date: Thu, 18 Feb 2016 12:38:33 +0100
Subject: [openssl-users] Supported cipher suites
Message-ID: <CADBu4be1ei648uBDgztJd+7RYiKseQEkD=CJJhmO_xzWiMafWg@mail.gmail.com>

Hi,

I'm looking for a DTLS solution that supports a specific set of cipher
suites. There is a listing (link below, not sure for which openssl
version?) where I found some of them, but still I did not find the
following ones:

TLS_ECDH_ANON_WITH_AES_128_CBC_SHA256
TLS_ECDH_ANON_WITH_AES_256_CBC_SHA256
TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_SHA256
TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA256

Actually, they are on the list but without the "_SHA256" or the "256" at
the end. Any ideas?

Mentioned listing:
https://testssl.sh/openssl-rfc.mappping.html


Regards,
Krzysztof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160218/a21091c3/attachment.html>

From naynjain at in.ibm.com  Thu Feb 18 11:41:17 2016
From: naynjain at in.ibm.com (Nayna Jain)
Date: Thu, 18 Feb 2016 17:11:17 +0530
Subject: [openssl-users] Valid strings to be passed to EVP_get_digestbyname()
Message-ID: <201602181141.u1IBfDUU24117758@d28relay05.in.ibm.com>


Hi,

I am trying to use EVP APIs for generating sha256 hashes.

I think of the step is to pass the digest name to EVP_get_digestbyname()
and get the EVP_MD* structure

However, I am not able to find the valid string to be passed for SHA256
hash algorithm..  I tried passing "sha256", "SHA256", it shows "unknown
message digest"

Tried to do doc and google search, couldn't find the list of valid strings.

Can someone please help me with this ?


Thanks & Regards,
Nayna Jain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160218/bc5382cb/attachment.html>

From c.holper at ades.at  Thu Feb 18 13:05:35 2016
From: c.holper at ades.at (c.holper at ades.at)
Date: Thu, 18 Feb 2016 14:05:35 +0100
Subject: [openssl-users] SMIME: 1.0.0e vs. 1.0.1e
Message-ID: <56C5C19F.80800@ades.at>

Hello!

I have a little problem with an update from an old 1.0.0e (vanilla 
compiled) vs.
debians (7.9, stable) 1.0.1e.

I try to verify an smime-signature
Tried with the same smime-file and with the same certificates on the 
same machine.
The certificates are fine and are ok if I verify them.


openssl smime -verify -purpose any -in "myfile.txt" -out "myfile.out"  
-CApath /etc/ssl/certs -CAfile "cert.cer"

It works fine with 1.0.0e.
Text: Verification successful
Return: 0


But I get the following with 1.0.1e.
Text: Verification failure
139728980395688:error:21071065:PKCS7 
routines:PKCS7_signatureVerify:digest failure:pk7_doit.c:1169:
139728980395688:error:21075069:PKCS7 routines:PKCS7_verify:signature 
failure:pk7_smime.c:410:
Return: 4



The myfile.txt (shortened):
------------------------------
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; 
micalg="sha1"; boundary="----EEFE59145E95831000EE06DE4309E3A9"

This is an S/MIME signed message

------EEFE59145E95831000EE06DE4309E3A9
Content-Transfer-Encoding: binary
Content-Type: application/edi-consent
Content-Disposition: attachment; name="abc.xml"; filename="abc.xml"

<?xml version='1.0' encoding='utf-8'?>
......
......
------EEFE59145E95831000EE06DE4309E3A9
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIIawYJKoZIhvcN7nTRPWZsxevEqzakh6vKxTTE8sn5mzeU4QoEqAP1EOuATPan0VpAXtfJfBQfq/I=
...
EEFE59145E95831000EE06DE4309E3A9
---------------------------------


Can anyone please help, thanks!

Best regards,
christoph





From Michael.Wojcik at microfocus.com  Thu Feb 18 13:27:26 2016
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 18 Feb 2016 13:27:26 +0000
Subject: [openssl-users] Valid strings to be passed to
 EVP_get_digestbyname()
In-Reply-To: <201602181141.u1IBfDUU24117758@d28relay05.in.ibm.com>
References: <201602181141.u1IBfDUU24117758@d28relay05.in.ibm.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088015DC87B97@Rock-Exchange1.microfocus.com>

[Top-posting because Outlook can't handle HTML email properly.]

Always state what version of OpenSSL you're using.

"sha256" is correct, if that algorithm has been added. Have you called OpenSSL_add_all_algorithms()?

There is no universal "list of valid strings", because OpenSSL can be built with various algorithms enabled or disabled, and which algorithms are available at runtime depends on which of those included at compilation have been added when initializing OpenSSL. So the most likely issue is that you haven't called OpenSSL_add_all_algorithms.

Michael Wojcik
Technology Specialist, Micro Focus


From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nayna Jain
Sent: Thursday, February 18, 2016 06:41
To: openssl-users at openssl.org
Subject: [openssl-users] Valid strings to be passed to EVP_get_digestbyname()


Hi,

I am trying to use EVP APIs for generating sha256 hashes.

I think of the step is to pass the digest name to EVP_get_digestbyname() and get the EVP_MD* structure

However, I am not able to find the valid string to be passed for SHA256 hash algorithm.. I tried passing "sha256", "SHA256", it shows "unknown message digest"

Tried to do doc and google search, couldn't find the list of valid strings.

Can someone please help me with this ?


Thanks & Regards,
Nayna Jain


Click here<https://www.mailcontrol.com/sr/KxNNNLAffGPGX2PQPOmvUqs4kYhz3KDrk4yoG9hhq2+fv0ZTFnsZGtcAZ6oaP4MXLiWINVYvmuaYO!6K2KUB+Q==> to report this email as spam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160218/bdddcd89/attachment.html>

From bobbyphilip at gmail.com  Thu Feb 18 15:21:29 2016
From: bobbyphilip at gmail.com (Bobby Philip)
Date: Thu, 18 Feb 2016 20:51:29 +0530
Subject: [openssl-users] Getting a compilation error on openssl 1.0.1 branch
Message-ID: <CA+8cdYeae3iUmtq2ewqwcQuZKHOdf5_yi=VxzQhiUvuOFdFP0w@mail.gmail.com>

Hi,
 I am trying to compile openssl 1.0.1r for android and statically link to
my application.
I am getting a  compile error in the file
https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/crypto/evp/e_aes.c
at line 61  # include "modes_lcl.h"

This modes_lcl.h is present at
https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/crypto/modes/modes_lcl.h,
which is "parallel" to the evp folder which is trying to access this.

I would like to know what I am doing wrong, since obviously this code
should compile without any issue. I am curious to know if the use of #
include "" instead of # include <> or some other way of giving the path is
appropriate in this scenario.

Regards
B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160218/d8d46dc6/attachment-0001.html>

From c.holper at ades.at  Thu Feb 18 16:07:13 2016
From: c.holper at ades.at (c.holper at ades.at)
Date: Thu, 18 Feb 2016 17:07:13 +0100
Subject: [openssl-users]  SMIME: 1.0.0e vs. 1.0.1e
Message-ID: <56C5EC31.2050704@ades.at>

I'd like to add the following to my thread.

- If I use option -nosigs then it is working.
But sure its not verifying. If I change the content it is still ok with 
this option in place.

- I tried also the current 1.0.1r and get the same behaviour with 1.0.1e.

- Option -binary does not help.

Thank!
Cheers,
chris

From steve at openssl.org  Thu Feb 18 18:49:49 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 18 Feb 2016 18:49:49 +0000
Subject: [openssl-users] SMIME: 1.0.0e vs. 1.0.1e
In-Reply-To: <56C5EC31.2050704@ades.at>
References: <56C5EC31.2050704@ades.at>
Message-ID: <20160218184949.GA4637@openssl.org>

On Thu, Feb 18, 2016, c.holper at ades.at wrote:

> I'd like to add the following to my thread.
> 
> - If I use option -nosigs then it is working.
> But sure its not verifying. If I change the content it is still ok
> with this option in place.
> 
> - I tried also the current 1.0.1r and get the same behaviour with 1.0.1e.
> 
> - Option -binary does not help.
> 

I'd suggest you output the content to a file in each case and compare the
two.

This really needs a complete example to debug properly.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From cocommisso at blackberry.com  Thu Feb 18 20:14:25 2016
From: cocommisso at blackberry.com (Cosimo Commisso)
Date: Thu, 18 Feb 2016 20:14:25 +0000
Subject: [openssl-users] building OpenSSL 1.1.0 pre release 3 in debug mode
Message-ID: <9B0E93EE1DE1184184CC819AE4401BCA3B5ED595@XMB102FCNC.rim.net>

I'm trying to build OpenSSL 1.1.0 pre 3 release in debug mode. According to the INSTALL.WIN file:

"If you add --debug to the Configure lines above then debugging symbols will be compiled in."

perl Configure VC-WIN64A --debug no-rc4 no-idea
results in:
Configured for VC-WIN64A.

Using the 1.0.1/1.0.2 approach results in the same:

perl Configure debug-VC-WIN64A no-rc4 no-idea
Configured for VC-WIN64A.

I would expect to see:
perl Configure debug-VC-WIN64A no-rc4 no-idea
Configured for debug-VC-WIN64A.

Is building in debug mode not supported in this alpha release yet or is there something I'm missing?

Environment:
ActiveState Perl 5.20.1

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160218/39f2d3e2/attachment.html>

From matt at openssl.org  Fri Feb 19 11:31:06 2016
From: matt at openssl.org (Matt Caswell)
Date: Fri, 19 Feb 2016 11:31:06 +0000
Subject: [openssl-users] Ubsec and Chil engines
Message-ID: <56C6FCFA.4040602@openssl.org>

Hi all

The ubsec and chil engines are currently disabled in 1.1.0 and do not build.

As far as ubsec is concerned I understand that this is an engine for
broadcom cards. There has been very little activity with this engine
since it was first introduced. Google brings up some very old historic
references to its use.

There are a couple of more recent references.

This post from 2014 suggests that OpenSSL's support for this is broken
anyway and has been for some while:
https://forum.pfsense.org/index.php?topic=71857.0

There is also this post from 2013 from someone trying to get it to work
but with no (apparent) success:
https://stackoverflow.com/questions/17715546/openssl-speed-test-for-broadcom-engine

So for ubsec I can't find any evidence that it is being used successfully.


For chil I found this dicussion from 2012 on openssl-users where
apparently someone was using it (successfully):
http://openssl.6102.n7.nabble.com/Tutorials-on-OpenSSL-integration-with-nCipher-HSM-nShield-td2311.html

This RT ticket from 2008 is suggesting various fixes - the last of which
was applied. There was a brief flurry of commits tweaking stuff in chil
around this time:
https://rt.openssl.org/Ticket/Display.html?id=1736


So it seems that for chil there may possibly be some rare use (but even
the most recent evidence is 4 years old). However the OpenSSL dev team
do not have access to this hardware to maintain the engine and (as noted
above) this is currently not building in 1.1.0.

In both cases I would like to remove these engines from 1.1.0. I'd like
to hear from the community if there is any active use of these. One
option if there is found to be some small scale use is to spin out the
engine into a separately managed repo (as has happened recently with the
GOST engine).

If I don't hear from anyone I will remove these.

Matt


From jaroslav.imrich at gmail.com  Fri Feb 19 13:11:24 2016
From: jaroslav.imrich at gmail.com (Jaroslav Imrich)
Date: Fri, 19 Feb 2016 14:11:24 +0100
Subject: [openssl-users] [openssl-dev] Ubsec and Chil engines
In-Reply-To: <56C6FCFA.4040602@openssl.org>
References: <56C6FCFA.4040602@openssl.org>
Message-ID: <CAB6OCMu0kNioLxFLzLMtg3n3jLyoJk6f-Rz_rJsL3VgFcCPa5A@mail.gmail.com>

Hello Matt,

If I don't hear from anyone I will remove these.
>

I can confirm that CHIL engine is actively used with OpenSSL 1.0.* by the
owners of nCipher/THALES nShield HSMs.

I have notified vendor support about this thread.

Regards, Jaroslav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160219/ad578e33/attachment.html>

From rsalz at akamai.com  Fri Feb 19 14:07:42 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 19 Feb 2016 14:07:42 +0000
Subject: [openssl-users] [openssl-dev] Ubsec and Chil engines
In-Reply-To: <56C6FCFA.4040602@openssl.org>
References: <56C6FCFA.4040602@openssl.org>
Message-ID: <e7c59127958542069ad15cce41349507@ustx2ex-dag1mb1.msg.corp.akamai.com>


> In both cases I would like to remove these engines from 1.1.0. I'd like to hear
> from the community if there is any active use of these. One option if there is
> found to be some small scale use is to spin out the engine into a separately
> managed repo (as has happened recently with the GOST engine).

Please do.  I know Sander was interested in updating CHIL but never found time.

That also removes the last remaining need for "dynamic locks"  huzzah

From sugu.ece28 at gmail.com  Fri Feb 19 16:14:58 2016
From: sugu.ece28 at gmail.com (Sugumar)
Date: Fri, 19 Feb 2016 09:14:58 -0700 (MST)
Subject: [openssl-users] Problem in decryption using python which cipher
 text is encrypted in c++
Message-ID: <1455898498831-63826.post@n7.nabble.com>

Hi,

I have encrypted a free text in C++ using a EVP calls with CFB mode and 32
bytes of IV (Hex String).
Then i am passing this cipher text to my another end which is using a
python(PyCrypto library) code to decrypt a cipher text using same Key and
IV.
But i am getting error "IV must be of 16 bytes" in python.
I tried to convert 32 bytes of Hex string to 16 bytes ascii string but
nothing works.

Please help me to resolve this.



--
View this message in context: http://openssl.6102.n7.nabble.com/Problem-in-decryption-using-python-which-cipher-text-is-encrypted-in-c-tp63826.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From rsalz at akamai.com  Fri Feb 19 17:50:44 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 19 Feb 2016 17:50:44 +0000
Subject: [openssl-users] Problem in decryption using python which cipher
 text is encrypted in c++
In-Reply-To: <1455898498831-63826.post@n7.nabble.com>
References: <1455898498831-63826.post@n7.nabble.com>
Message-ID: <52016c212f204c809ea506110d80686f@ustx2ex-dag1mb1.msg.corp.akamai.com>

> Then i am passing this cipher text to my another end which is using a
> python(PyCrypto library) code to decrypt a cipher text using same Key and
> IV.

The IV, key, and ciphertext are all binary arrays of bytes.  Not C (or ASCII or UTF8 or anything) strings.  You will have to convert back/and forth. 

From pdrotter at us.ibm.com  Fri Feb 19 21:14:26 2016
From: pdrotter at us.ibm.com (Neptune)
Date: Fri, 19 Feb 2016 14:14:26 -0700 (MST)
Subject: [openssl-users] OPENSSL error:21072077:PKCS7 routines:PKCS7_decrypt
	in FIPS mode
Message-ID: <1455916466557-63828.post@n7.nabble.com>

failedcert.crt <http://openssl.6102.n7.nabble.com/file/n63828/failedcert.crt>  

Hello all,
I've attached a .crt certificate file that we are experiencing a problem
with. When trying to process this certificate using the PKCS7_decrypt( )
function. The error string is:

OPENSSL error:21072077:PKCS7 routines:PKCS7_decrypt:decrypt error

This only happens in FIPS mode so we suspect a weak cipher, but I'm unable
to glean any specified error that would verify this suspicion. I was hoping
someone would be nice enough to inspect this file and verify if there is any
non-FIPS-iness. I don't want to point fingers at the environment without
proof.

Thanks for any help!



--
View this message in context: http://openssl.6102.n7.nabble.com/OPENSSL-error-21072077-PKCS7-routines-PKCS7-decrypt-in-FIPS-mode-tp63828.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From steve at openssl.org  Fri Feb 19 22:41:39 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 19 Feb 2016 22:41:39 +0000
Subject: [openssl-users] OPENSSL error:21072077:PKCS7
 routines:PKCS7_decrypt in FIPS mode
In-Reply-To: <1455916466557-63828.post@n7.nabble.com>
References: <1455916466557-63828.post@n7.nabble.com>
Message-ID: <20160219224139.GA7441@openssl.org>

On Fri, Feb 19, 2016, Neptune wrote:

> failedcert.crt <http://openssl.6102.n7.nabble.com/file/n63828/failedcert.crt>  
> 
> Hello all,
> I've attached a .crt certificate file that we are experiencing a problem
> with. When trying to process this certificate using the PKCS7_decrypt( )
> function. The error string is:
> 
> OPENSSL error:21072077:PKCS7 routines:PKCS7_decrypt:decrypt error
> 
> This only happens in FIPS mode so we suspect a weak cipher, but I'm unable
> to glean any specified error that would verify this suspicion. I was hoping
> someone would be nice enough to inspect this file and verify if there is any
> non-FIPS-iness. I don't want to point fingers at the environment without
> proof.
> 

Well that link is not an certificate but a PKCS#7 signed data structure whose
content is itself a PKCS#7 enveloped data structure.

You mentioned PKCS7_decrypt() so that may be a referenceto the inner content.
Analysing that with asn1parse shows that it is using single DES as the content
encryption algorithm (56 bits) which is not approved in FIPS mode. So I
suspect that is the cause.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From bobbyphilip at gmail.com  Sat Feb 20 15:00:59 2016
From: bobbyphilip at gmail.com (Bobby Philip)
Date: Sat, 20 Feb 2016 20:30:59 +0530
Subject: [openssl-users] Getting a compilation error on openssl 1.0.1
	branch
In-Reply-To: <CA+8cdYeae3iUmtq2ewqwcQuZKHOdf5_yi=VxzQhiUvuOFdFP0w@mail.gmail.com>
References: <CA+8cdYeae3iUmtq2ewqwcQuZKHOdf5_yi=VxzQhiUvuOFdFP0w@mail.gmail.com>
Message-ID: <CA+8cdYdV4dGfpRJctHgycKbOsNCM0j7U0dse40gKoJ6dCjaZ3w@mail.gmail.com>

This was because one of my application makefiles wasnt updated to include
the crypto/modes/ folder in its INCLUDES definition.


On Thu, Feb 18, 2016 at 8:51 PM, Bobby Philip <bobbyphilip at gmail.com> wrote:

> Hi,
>  I am trying to compile openssl 1.0.1r for android and statically link to
> my application.
> I am getting a  compile error in the file
>
> https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/crypto/evp/e_aes.c
> at line 61  # include "modes_lcl.h"
>
> This modes_lcl.h is present at
> https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/crypto/modes/modes_lcl.h,
> which is "parallel" to the evp folder which is trying to access this.
>
> I would like to know what I am doing wrong, since obviously this code
> should compile without any issue. I am curious to know if the use of #
> include "" instead of # include <> or some other way of giving the path is
> appropriate in this scenario.
>
> Regards
> B
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160220/db62517d/attachment.html>

From sander at temme.net  Sat Feb 20 20:40:38 2016
From: sander at temme.net (Sander Temme)
Date: Sat, 20 Feb 2016 12:40:38 -0800
Subject: [openssl-users] [openssl-dev] Ubsec and Chil engines
In-Reply-To: <56C6FCFA.4040602@openssl.org>
References: <56C6FCFA.4040602@openssl.org>
Message-ID: <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net>


> On Feb 19, 2016, at 3:31 AM, Matt Caswell <matt at openssl.org> wrote:

OK that made our support lines blow up so yes there is interest.

Disclaimer: I work for Thales but do not speak for Thales.

> So it seems that for chil there may possibly be some rare use (but even
> the most recent evidence is 4 years old). However the OpenSSL dev team
> do not have access to this hardware to maintain the engine and (as noted
> above) this is currently not building in 1.1.0.

I think (again, personal impression) that this is one of those sleeper integrations that a lot of people use but doesn?t get on the radar a whole lot. Using openssl is by far the easiest way to get the nShield HSM to do something with protected keys? as long as those are RSA keys.  Pair that with existing application integrations like Apache, OpenSSH, etc. I know of a number of customers and partners, none of whom I am at liberty to discuss (although they might speak up for themselves), who use OpenSSL with nShield for various applications.

So it?s not dead.  What it does, it does very well.  If anything, the lack of visible activity may indicate how easy CHIL is to use and support.

> In both cases I would like to remove these engines from 1.1.0. I'd like
> to hear from the community if there is any active use of these. One
> option if there is found to be some small scale use is to spin out the
> engine into a separately managed repo (as has happened recently with the
> GOST engine).
> 
> If I don't hear from anyone I will remove these.

Ehm.  Let?s talk about this.  As I noted above, a lot of our valued customers may depend on this even thought they might not know or may have forgotten about it.  From your October 28 commit (29e7a56d), it seems that what broke us was when the bn structure went opaque? I see only two lines in e_chil.c that depend on the internal structure of bn so that should be addressable.  We?d like to do some more things to this Engine, like more key types and, yes, those dynamic locks should go away, which requires some surgery to the stuff underneath but nothing major.  All the platforms we run on now have good locking.  And, Rich, I indeed have had those locks on my guilty conscience for all this time but not found any round tuits.

However, I?m intrigued by the notion of a PKCS#11 Engine in OpenSSL: it?s a standard (an OASIS standard now); it?s fairly fully featured; everyone in the industry supports it including Thales; and you can build a program that calls it without needing a vendor SDK, because there are standard headers and a well defined way to get to the entry points.  If we can come up with a way to pick a PKCS#11 slot and log into it that makes sense (e.g. not by poking PINs into a system wide config file etc.) then I think we?d have a winner.

What I would like to see though is for such a PKCS#11 Engine to be part of OpenSSL proper, so that our customers and everyone else?s don?t have to go hunt hither and yon for bits and bobs of software in order to make their hardware kit work with OpenSSL.  How would OpenSSL obtain a PKCS#11 Engine to include in its distribution?

Thanks,

S.

--
sander at temme.net              http://www.temme.net/sander/
PGP FP: BCD1 6D2C 8906 C48A 540E  253E 94D3 36A3 6D15 930A



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160220/9de5efaf/attachment.sig>

From levitte at openssl.org  Sat Feb 20 21:55:41 2016
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 20 Feb 2016 22:55:41 +0100 (CET)
Subject: [openssl-users] [openssl-dev] Ubsec and Chil engines
In-Reply-To: <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net>
References: <56C6FCFA.4040602@openssl.org>
 <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net>
Message-ID: <20160220.225541.1585601945103016062.levitte@openssl.org>

In message <5B8F45EA-5867-4832-916A-6B31A323A59C at temme.net> on Sat, 20 Feb 2016 12:40:38 -0800, Sander Temme <sander at temme.net> said:

sander> 
sander> > On Feb 19, 2016, at 3:31 AM, Matt Caswell <matt at openssl.org> wrote:
sander> 
sander> OK that made our support lines blow up so yes there is interest.
sander> 
sander> Disclaimer: I work for Thales but do not speak for Thales.
sander> 
sander> > So it seems that for chil there may possibly be some rare use (but even
sander> > the most recent evidence is 4 years old). However the OpenSSL dev team
sander> > do not have access to this hardware to maintain the engine and (as noted
sander> > above) this is currently not building in 1.1.0.
sander> 
sander> I think (again, personal impression) that this is one of those
sander> sleeper integrations that a lot of people use but doesn?t get
sander> on the radar a whole lot. Using openssl is by far the easiest
sander> way to get the nShield HSM to do something with protected
sander> keys? as long as those are RSA keys.  Pair that with existing
sander> application integrations like Apache, OpenSSH, etc. I know of
sander> a number of customers and partners, none of whom I am at
sander> liberty to discuss (although they might speak up for
sander> themselves), who use OpenSSL with nShield for various
sander> applications.

Oh, nShield?  Back when I was playing with e_chil.c, it was nCipher.
But, no matter really...

sander> So it?s not dead.  What it does, it does very well.  If
sander> anything, the lack of visible activity may indicate how easy
sander> CHIL is to use and support.

The trouble is that we can't verify that.  We don't have the hardware
or the expertise.  Even the few of us that got to play with a nCipher
box 15+ years ago don't have that around any more.  So there's that
pile of code that no one dares to touch because we have no idea what
the effects might be and have no way of testing that.

With all that in mind, I've a question back to you...  wouldn't it be
more productive if Thales let an OpenSSL engine, built as a DSO,
accompany the hardware?  Considering you are much closer to the
hardware and the expertise, it seems a bit more appropriate, doesn't
it?

sander> What I would like to see though is for such a PKCS#11 Engine
sander> to be part of OpenSSL proper, so that our customers and
sander> everyone else?s don?t have to go hunt hither and yon for bits
sander> and bobs of software in order to make their hardware kit work
sander> with OpenSSL.  How would OpenSSL obtain a PKCS#11 Engine to
sander> include in its distribution?

I'm not sure if this is a problem specifically for OpenSSL to solve,
or if it is a packager problem.  Sometimes, the border between the two
might be blurry, but...  If OpenSSL is to "obtain" a PKCS#11 engine,
it would probably be by writing one.  It would be far easier, though,
if someone would package the already existing engine_pkcs11 with
OpenSSL (that packaging doesn't have to be done by the OpenSSL team),
*or* with hardware distributions.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From jaroslav.imrich at gmail.com  Sat Feb 20 22:34:10 2016
From: jaroslav.imrich at gmail.com (Jaroslav Imrich)
Date: Sat, 20 Feb 2016 23:34:10 +0100
Subject: [openssl-users] [openssl-dev] Ubsec and Chil engines
In-Reply-To: <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net>
References: <56C6FCFA.4040602@openssl.org>
 <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net>
Message-ID: <CAB6OCMv2cRxY4hh9dEG7VLAe6eiAJKbtqff8v06YXwqEUZfFqQ@mail.gmail.com>

On 20 February 2016 at 21:40, Sander Temme <sander at temme.net> wrote:

> However, I?m intrigued by the notion of a PKCS#11 Engine in OpenSSL: it?s
> a standard (an OASIS standard now); it?s fairly fully featured; everyone in
> the industry supports it including Thales; and you can build a program that
> calls it without needing a vendor SDK, because there are standard headers
> and a well defined way to get to the entry points.  If we can come up with
> a way to pick a PKCS#11 slot and log into it that makes sense (e.g. not by
> poking PINs into a system wide config file etc.) then I think we?d have a
> winner.
>

Let's not forget that CHIL provides one very unique feature - forked
process keeps the authentication state of its parent and can access HSM
keys if its parent was authenticated. PKCS#11 specification prohibits such
behavior (PKCS#11 v2.20 chapter 6.6.1) and because of that PKCS#11 based
engine couldn't fully replace CHIL engine.

Regards, Jaroslav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160220/ec22920d/attachment-0001.html>

From sasc0041 at stud.hs-kl.de  Sun Feb 21 16:15:45 2016
From: sasc0041 at stud.hs-kl.de (Sandra Schreiner)
Date: Sun, 21 Feb 2016 16:15:45 +0000
Subject: [openssl-users] Warning OPENSSL_1.0.0 not found (custom build
	OpenSSL library)
Message-ID: <C24FEA7BFC953B4C88B462646381FD81012C65DC85@kgtz-mb01.ds.fh-kl.de>

Hello,

I am currently developing a C++ application with Boost Asio SSL Sockets. Boost Asio uses OpenSSL for it's TLS support. My application will be ported to Android in the future so I tried to build OpenSSL by myself for my current architecture (Linux, Debian, 64bit, VM) in the first run and link it to my application. Everything went well until I ran the application. At first I received a warning 'no version information found' for OpenSSL. 
I fixed this by providing a version info file like descripted here: http://stackoverflow.com/questions/18390833/no-version-information-available. I changed the version to 1.0.1, because I use OpenSSL 1.0.1f:

OPENSSL_1.0.1 {
    global:
    *;
};

Now I receive a warning 'version `OPENSSL_1.0.0' not found'. I also saw this thread http://openssl.6102.n7.nabble.com/version-script-td63374.html which mentions there is a version script patch for debian and ubuntu in order to get rid of this warnings. 
Unfortunately now I'm confused, because I'm not very familar with building own librarys and linux distributions in general. I don't know how to apply a version patch to a library which I build in a custom directory and which will be shipped together with my application.  Would it be necessary to apply this patch to every device where my app is running? Is this even possible for android? 
At the moment I'm using a CMake file to build OpenSSL:

ExternalProject_Add(
  openssl
  SOURCE_DIR ${openssl_src}
  CONFIGURE_COMMAND ${openssl_src}/config no-ssl2 no-ssl3 shared --openssldir=${openssl_prefix} -Wl,--version-script=${openssl_src}/openssl.ld
  PREFIX ${openssl_prefix}
  BUILD_COMMAND make
  BUILD_IN_SOURCE 1
  INSTALL_COMMAND make install
)

Is it possible to integrate the patch for 1.0.1f in my build process? Or is there a other solution to get rid of this warnings?

Many thanks in advance,
Sandra

From kurt at roeckx.be  Sun Feb 21 18:26:00 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 21 Feb 2016 19:26:00 +0100
Subject: [openssl-users] Warning OPENSSL_1.0.0 not found (custom build
 OpenSSL library)
In-Reply-To: <C24FEA7BFC953B4C88B462646381FD81012C65DC85@kgtz-mb01.ds.fh-kl.de>
References: <C24FEA7BFC953B4C88B462646381FD81012C65DC85@kgtz-mb01.ds.fh-kl.de>
Message-ID: <20160221182600.GA27646@roeckx.be>

On Sun, Feb 21, 2016 at 04:15:45PM +0000, Sandra Schreiner wrote:
> Hello,
> 
> I am currently developing a C++ application with Boost Asio SSL Sockets. Boost Asio uses OpenSSL for it's TLS support. My application will be ported to Android in the future so I tried to build OpenSSL by myself for my current architecture (Linux, Debian, 64bit, VM) in the first run and link it to my application. Everything went well until I ran the application. At first I received a warning 'no version information found' for OpenSSL. 
> I fixed this by providing a version info file like descripted here: http://stackoverflow.com/questions/18390833/no-version-information-available. I changed the version to 1.0.1, because I use OpenSSL 1.0.1f:
> 
> OPENSSL_1.0.1 {
>     global:
>     *;
> };

I suggest you use the version script from the package you're
trying to replace.


Kurt


From sugu.ece28 at gmail.com  Mon Feb 22 05:09:48 2016
From: sugu.ece28 at gmail.com (Sugumar)
Date: Sun, 21 Feb 2016 22:09:48 -0700 (MST)
Subject: [openssl-users] Problem in decryption using python which cipher
 text is encrypted in c++
In-Reply-To: <52016c212f204c809ea506110d80686f@ustx2ex-dag1mb1.msg.corp.akamai.com>
References: <1455898498831-63826.post@n7.nabble.com>
 <52016c212f204c809ea506110d80686f@ustx2ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <1456117788950-63868.post@n7.nabble.com>

Thanks for your reply.

Correct me if i am wrong.
What i have understood from your point is, i have to read the first 2 char
of 32 char IV and convert into a byte array right?
For example: my IV "12345678901234567890123456789012"
I have read first 2 char i.e "12" then i have to convert it into byte array.

Please give me some more clear idea about this. 
If u have any example for this please post it for our better understanding.
Thanks.



--
View this message in context: http://openssl.6102.n7.nabble.com/Problem-in-decryption-using-python-which-cipher-text-is-encrypted-in-c-tp63826p63868.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From sasc0041 at stud.hs-kl.de  Mon Feb 22 07:11:02 2016
From: sasc0041 at stud.hs-kl.de (Sandra Schreiner)
Date: Mon, 22 Feb 2016 07:11:02 +0000
Subject: [openssl-users] Warning OPENSSL_1.0.0 not found (custom build
 OpenSSL library)
In-Reply-To: <20160221182600.GA27646@roeckx.be>
References: <C24FEA7BFC953B4C88B462646381FD81012C65DC85@kgtz-mb01.ds.fh-kl.de>,
 <20160221182600.GA27646@roeckx.be>
Message-ID: <C24FEA7BFC953B4C88B462646381FD81012C65DCA2@kgtz-mb01.ds.fh-kl.de>

>>I suggest you use the version script from the package you're
>>trying to replace.

Hello Kurt,

I'm not sure if I understand you right.
Do you mean the version "patch" I already found?:

>>I also saw this thread http://openssl.6102.n7.nabble.com/version-script-td63374.html which mentions there is a >>version script patch for debian and ubuntu in order to get rid of this warnings. 
>>Unfortunately now I'm confused, because I'm not very familar with building own librarys and linux distributions in >>general.

Do I have to install this patch on every device where my application will run? Would it be possible to integrate this patch in the library already during the build process ? How could this be achieved? Or is there something else I could use instead of the patch?

Best regards,
Sandra


From michel.sales at free.fr  Mon Feb 22 10:46:05 2016
From: michel.sales at free.fr (Michel)
Date: Mon, 22 Feb 2016 11:46:05 +0100
Subject: [openssl-users] Problem in decryption using python which cipher
	text is encrypted in c++
In-Reply-To: <1456117788950-63868.post@n7.nabble.com>
References: <1455898498831-63826.post@n7.nabble.com>
 <52016c212f204c809ea506110d80686f@ustx2ex-dag1mb1.msg.corp.akamai.com>
 <1456117788950-63868.post@n7.nabble.com>
Message-ID: <000c01d16d5e$3bad94c0$b308be40$@sales@free.fr>

Hi Sugumar,

I might misunderstand your need but 'Hex' (as 'Base64') is just an encoding
method to ease use of characters that are not printable.
Your example hex string IV : "12345678901234567890123456789012" should be
converted to :

unsigned char IV[16] = { 0x12, 0x34, 0x56, 0x78, 0x90, 0x12, 0x34, 0x56,
0x78, 0x90, 0x12, 0x34, 0x56, 0x78, 0x90, 0x12 };
in other words       = { 18,   52,   86,   120,  144,  18,   52,   86,
120,  144,  18,   52,   86,   120,  144,  18   }; (decimal values)

-----Message d'origine-----
De?: openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de
Sugumar
Envoy??: lundi 22 f?vrier 2016 06:10
??: openssl-users at openssl.org
Objet?: Re: [openssl-users] Problem in decryption using python which cipher
text is encrypted in c++

Thanks for your reply.

Correct me if i am wrong.
What i have understood from your point is, i have to read the first 2 char
of 32 char IV and convert into a byte array right?
For example: my IV "12345678901234567890123456789012"
I have read first 2 char i.e "12" then i have to convert it into byte array.

Please give me some more clear idea about this. 
If u have any example for this please post it for our better understanding.
Thanks.



From levitte at openssl.org  Mon Feb 22 11:52:36 2016
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 22 Feb 2016 12:52:36 +0100 (CET)
Subject: [openssl-users] [openssl-dev] Ubsec and Chil engines
In-Reply-To: <1456140741.4735.272.camel@infradead.org>
References: <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net>
 <20160220.225541.1585601945103016062.levitte@openssl.org>
 <1456140741.4735.272.camel@infradead.org>
Message-ID: <20160222.125236.1263663358704085081.levitte@openssl.org>

In message <1456140741.4735.272.camel at infradead.org> on Mon, 22 Feb 2016 11:32:21 +0000, David Woodhouse <dwmw2 at infradead.org> said:

dwmw2> On Sat, 2016-02-20 at 22:55 +0100, Richard Levitte wrote:
dwmw2> > 
dwmw2> > sander> What I would like to see though is for such a PKCS#11 Engine
dwmw2> > sander> to be part of OpenSSL proper, so that our customers and
dwmw2> > sander> everyone else?s don?t have to go hunt hither and yon for bits
dwmw2> > sander> and bobs of software in order to make their hardware kit work
dwmw2> > sander> with OpenSSL.? How would OpenSSL obtain a PKCS#11 Engine to
dwmw2> > sander> include in its distribution?
dwmw2> > 
dwmw2> > I'm not sure if this is a problem specifically for OpenSSL to solve,
dwmw2> > or if it is a packager problem.?
dwmw2> 
dwmw2> I touched on this in a message a few minutes ago, but I *definitely*
dwmw2> think it's the former.
dwmw2> 
dwmw2> If we integrate the support natively into OpenSSL, then PKCS#11 URIs
dwmw2> (see RFC7512) can be first-class citizens throughout the crypto and SSL
dwmw2> APIs. Any function which takes a filename for a cert or key should also
dwmw2> accept? a PKCS#11 URI.
dwmw2> 
dwmw2> Then we can also use PKCS#11 for the trust database, which allows us to
dwmw2> properly handle the trusted *purposes* in ways that a flat file
dwmw2> doesn't. And that flat file is now *exported* from the p11-kit-trust
dwmw2> token purely for the benefit of OpenSSL, which it would be nice to stop
dwmw2> doing.
dwmw2> 
dwmw2> I am happy to work on this.

That takes me back to crypto/store, which is currently removed in
master but which I have a rework of in a branch, which is meant to
solve this exact problem, but without being exclusively tied to
PKCS#11.  The design is to have it work with engine backends, and a
PKCS#11 engine that's part of OpenSSL would fit that bill, so to say.

Shall we talk?

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Mon Feb 22 14:46:28 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 22 Feb 2016 14:46:28 +0000
Subject: [openssl-users] [openssl-dev] Ubsec and Chil engines
In-Reply-To: <1456140741.4735.272.camel@infradead.org>
References: <56C6FCFA.4040602@openssl.org>
 <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net>
 <20160220.225541.1585601945103016062.levitte@openssl.org>
 <1456140741.4735.272.camel@infradead.org>
Message-ID: <347004c001fd430aadadceac908e68a2@ustx2ex-dag1mb1.msg.corp.akamai.com>

> If we integrate the support natively into OpenSSL, then PKCS#11 URIs (see
> RFC7512) can be first-class citizens throughout the crypto and SSL APIs. Any
> function which takes a filename for a cert or key should also accept? a
> PKCS#11 URI.

It'd be great to see a crypto/pkcs11 directory with full native support (as much as possible).

But really doubtful to happen in 1.1 as the API freeze is in a month.

From levitte at openssl.org  Mon Feb 22 15:00:34 2016
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 22 Feb 2016 16:00:34 +0100 (CET)
Subject: [openssl-users] [openssl-dev] Ubsec and Chil engines
In-Reply-To: <347004c001fd430aadadceac908e68a2@ustx2ex-dag1mb1.msg.corp.akamai.com>
References: <20160220.225541.1585601945103016062.levitte@openssl.org>
 <1456140741.4735.272.camel@infradead.org>
 <347004c001fd430aadadceac908e68a2@ustx2ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20160222.160034.1279367000656813396.levitte@openssl.org>

In message <347004c001fd430aadadceac908e68a2 at ustx2ex-dag1mb1.msg.corp.akamai.com> on Mon, 22 Feb 2016 14:46:28 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> > If we integrate the support natively into OpenSSL, then PKCS#11 URIs (see
rsalz> > RFC7512) can be first-class citizens throughout the crypto and SSL APIs. Any
rsalz> > function which takes a filename for a cert or key should also accept? a
rsalz> > PKCS#11 URI.
rsalz> 
rsalz> It'd be great to see a crypto/pkcs11 directory with full native support (as much as possible).
rsalz> 
rsalz> But really doubtful to happen in 1.1 as the API freeze is in a month.

Yeah, 1.1 is unrealistic, I'm sorry to say.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From marquess at openssl.com  Mon Feb 22 15:10:54 2016
From: marquess at openssl.com (Steve Marquess)
Date: Mon, 22 Feb 2016 10:10:54 -0500
Subject: [openssl-users] FIPS 140-2 red letter puzzle
Message-ID: <56CB24FE.2000905@openssl.com>

As always, if you don't know or care what FIPS 140-2 is then rejoice at
your good fortune and move on.

I'm getting queries about "red letter" text in the listing of the #1747
validation on the NIT CMVP web site:

  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747

That red letter text says "This module is in process for the RNG
transition."

The #1717 validation is the original validation for the OpenSSL FIPS
Module v2.0, and the one with the most platforms (that module is now
also covered by two additional validations, #2398 and #2473, for
perverse bureaucratic reasons).

The "change letter" updates to satisfy the "RNG transition" requirements
were submitted for all three validations and approved for all three by
the CMVP in late January (#1747, #2473) or early February (#2398) at
which point the "This module is in process for the RNG transition." text
was removed for all three validations.

Now that text is back for the #1747 validation; apparently appearing
sometime on February 19 (or at least that's when I received the first
report). Otherwise that entry still reflects the successful RNG
transition (the new Security Policy is linked and the RNG algorithm
appears in the "Other algorithms" category).

I have no idea why the red letter text is back, and have submitted a
request for clarification through our accredited test lab.

I suspect this is just a clerical error, a not uncommon occurrence. So,
don't panic yet. I think we will eventually receive confirmation that
this red-letter message is an error and that it will be corrected.

Such confirmation may take some time, though. Similar errors in the past
have remained uncorrected for months.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From uri at ll.mit.edu  Mon Feb 22 19:13:59 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Mon, 22 Feb 2016 19:13:59 +0000
Subject: [openssl-users] Simple sample of using engine?
Message-ID: <D2F0C823.27811%uri@ll.mit.edu>

I?m struggling with the following task. I?m writing a software application
linked with OpenSSL-1.0.2. It receives an encrypted symmetric key (say, with
identifying parameters) that needs to be decrypted using hardware token,
accessible via PKCS#11. I know that engine_pkcs11 (or rather it?s current
incarnation libp11) does that fine when invoked via CLI.

My question is: what?s the smallest simplest code example that you could
share to show an absolutely minimalistic way of performing such decryption?
Let?s assume that everything is already known or determined from those other
parameters ? like the token type is already known (RSA), the serial number +
CN + SAN of the certificate used to encrypt, etc.

Thank you, and apologies if this question is less than smart.

P.S. An alternative is to access the token directly via OpenSC (as libp11
does it anyway), but I suspect it would be more complicated code-wise?
-- 
Regards,
Uri Blumenthal


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160222/2c6e73b9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160222/2c6e73b9/attachment.bin>

From S.Runkel at nanotron.com  Mon Feb 22 20:17:01 2016
From: S.Runkel at nanotron.com (Stefan Runkel)
Date: Mon, 22 Feb 2016 20:17:01 +0000
Subject: [openssl-users] How to define server cert in openssl.cnf ?
Message-ID: <51f9a71c286142fd96af483ab5d5ade2@ADMSV1.administration.nanotron.com>

hello,
i am running el5 with unmodified openssl.cnf file and have a program that uses the openssl libraries but is stupid enough to not offer some parameters to configure cert and cacert ("check_nrpe").

This programs source code initializes the openssl lib as follows:
               SSL_library_init();
               SSLeay_add_ssl_algorithms();
               meth=SSLv23_client_method();
               SSL_load_error_strings();
               SSL_CTX_set_options(ctx,SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);

Given "local_host_name.pem" and "ca_new.crt" which are created on a different machine (my root ca) with openssl, if i run a

               openssl s_client -connect remotehost.80:5666 -CAfile /etc/tmpssl/ca_new.crt -cert /etc/tmpssl/local_host_name.pem

that validates remotehost's certificate successfully and remotehost does not complain either in the logs.
So, what i *think* i need now is to setup an openssl.cnf file which enables me to run above command without specifying the certs:

               openssl s_client -connect remotehost.80:5666

After appending "ca_new.crt" to "/etc/pki/tls/certs/ca_bundle.crt", i can omit the "-CAfile /etc/tmpssl/ca_new.crt" parameter from above command and it still works fine.
But i can not find out what to do with the server certificate "local_host_name.pem" to reach my goal.

Could anybody please enlighten me ?

greetings, SR


-- 
Nanotron Technologies GmbH * Alt-Moabit 60 * 10555 Berlin * Germany
Geschaeftsfuehrer: Dr. Jens N. Albers
Sitz der Gesellschaft: Berlin * Registergericht: Berlin-Charlottenburg * HRB 42324
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160222/d3a1efd9/attachment.html>

From S.Runkel at nanotron.com  Mon Feb 22 20:07:24 2016
From: S.Runkel at nanotron.com (Stefan Runkel)
Date: Mon, 22 Feb 2016 20:07:24 +0000
Subject: [openssl-users] How to define server cert in openssl.cnf ?
Message-ID: <21b241358adf4530ab7a8332c4434e6f@ADMSV1.administration.nanotron.com>

hello,
i am running el5 with unmodified openssl.cnf file and have a program that uses the openssl libraries but is stupid enough to not offer some parameters to configure cert and cacert ("check_nrpe").

This programs source code initializes the openssl lib as follows:
               SSL_library_init();
               SSLeay_add_ssl_algorithms();
               meth=SSLv23_client_method();
               SSL_load_error_strings();
               SSL_CTX_set_options(ctx,SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);

Given "local_host_name.pem" and "ca_new.crt" which are created on a different machine (my root ca) with openssl, if i run a

               openssl s_client -connect remotehost.80:5666 -CAfile /etc/tmpssl/ca_new.crt -cert /etc/tmpssl/local_host_name.pem

that validates remotehost's certificate successfully and remotehost does not complain either in the logs.
So, what i *think* i need now is to setup an openssl.cnf file which enables me to run above command without specifying the certs:

               openssl s_client -connect remotehost.80:5666

After appending "ca_new.crt" to "/etc/pki/tls/certs/ca_bundle.crt", i can omit the "-CAfile /etc/tmpssl/ca_new.crt" parameter from above command and it still works fine.
But i can not find out what to do with the server certificate "local_host_name.pem" to reach my goal.

Could anybody please enlighten me ?

greetings, SR


-- 
Nanotron Technologies GmbH * Alt-Moabit 60 * 10555 Berlin * Germany
Geschaeftsfuehrer: Dr. Jens N. Albers
Sitz der Gesellschaft: Berlin * Registergericht: Berlin-Charlottenburg * HRB 42324
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160222/c79a6a1b/attachment-0001.html>

From cloud.force858 at gmail.com  Mon Feb 22 23:59:54 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Mon, 22 Feb 2016 15:59:54 -0800
Subject: [openssl-users] FIPS mode errors
In-Reply-To: <CAEsYawyCy81oSg5s1bm0Yy4oatT5CwKNCMW6qatEfBJjFnqJwg@mail.gmail.com>
References: <CAEsYawyiKudDTQSxD5ouFLojei_dR_QtbDzM_wcYvSrjw6WYDA@mail.gmail.com>
 <56BD8B15.7000008@wisemo.com>
 <CAEsYawyCy81oSg5s1bm0Yy4oatT5CwKNCMW6qatEfBJjFnqJwg@mail.gmail.com>
Message-ID: <CAEsYawzJsu357kBKF-6XTFiCp1tbfrMJ40jRDeB4rsy8cJ0c0A@mail.gmail.com>

Hi Jacob,

Any suggestions regarding how to fix the following errors:

140073969415840:error:2D06B06F:FIPS
routines:FIPS_check_incore_fingerprint:fingerprint
does not match:fips.c:232:

(I built the FIPS module and the OpenSSL library on Ubuntu linux)

Thanks,
Rich


On Thu, Feb 11, 2016 at 11:52 PM, cloud force <cloud.force858 at gmail.com>
wrote:

> Hi Jakob,
>
> This is the most severe FIPS error code, it means one of
>> 3 things:
>>
>> 1. (official reason for this error code): Someone illegally
>>   modified the FIPS validated crypto code after it was
>>   compiled, do not use this computer until the cause has
>>   been thoroughly investigated and corrected.
>>
>> 2. (much more likely): The file containing the FIPS code
>>   (either lib/libcrypto.so.1.0.0 or the program you ran)
>>   was relocated to a different memory address this time
>>   than back when you ran fipsld to set the checksum
>>   (fingerprint).
>>
>
> If this is the case, how should I fix this problem?
>
>
>>
>>
>> 3. (sometimes): You forgot to run fipsld to set the
>>   checksum (fingerprint).
>>
>
> At what point during the build should the fipsld be run?
>
>>
>>
>>
>>
>> Enjoy
>>
>> Jakob
>> --
>> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
>> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
>> This public discussion message is non-binding and may contain errors.
>> WiseMo - Remote Service Management for PCs, Phones and Embedded
>>
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>
>
> --
> Thanks,
> Rich
>
>


-- 
Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160222/88c9b7e4/attachment.html>

From stm at pdflib.com  Tue Feb 23 08:32:39 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Tue, 23 Feb 2016 09:32:39 +0100
Subject: [openssl-users] Is the structure of this CMS object correct?
In-Reply-To: <74002D90-1437-45F0-96F3-401B27B8569A@docusign.com>
References: <56B9AE22.6000501@pdflib.com>
 <AF40454C-E74A-4359-B53C-E694AE1FC590@docusign.com>
 <56B9CD84.7020207@pdflib.com>
 <74002D90-1437-45F0-96F3-401B27B8569A@docusign.com>
Message-ID: <56CC1927.7050701@pdflib.com>

Am 09.02.16 um 16:39 schrieb Erwann Abalea:
> Bonjour Stephan,
>
> ...
>
> PKCS#7 and CMS are pretty much interchangeable.
> Here, your file is strictly not a PKCS#7v1.5, because in this version,
> RecipientInfo wasn?t a CHOICE (see RFC2315 to see PKCS#7v1.5 definitions).
>
> How did you generate this structure? Adobe Acrobat?

The previous structure was generated with Adobe Acrobat XI.

I repeated the experiment with Adobe Acrobat DC, and something was 
changed in the structure of the CMS object, but it still does not look 
correct to me (full dumpasn1 output below).

It is clear to me that there is no problem with OpenSSL here, but I 
would appreciate it if someone with more authority on CMS and ASN.1 than 
me could confirm that the CMS structure is broken and that OpenSSL is 
correct to reject it, thanks.

OpenSSL 1.0.2d produces the following error message when trying to 
decrypt the CMS message:

$ openssl cms -decrypt -in cms-DC-AES256.der -inform DER -out /dev/null 
-inkey atssecp521r1.key -recip atssecp521r1.pem
Error reading S/MIME message
140735215203152:error:0D0680A8:asn1 encoding 
routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1198:
140735215203152:error:0D07803A:asn1 encoding 
routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:372:Type=X509_ALGOR
140735215203152:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:694:Field=keyEncryptionAlgorithm, 
Type=CMS_KeyTransRecipientInfo
140735215203152:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:694:
140735215203152:error:0D07803A:asn1 encoding 
routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:336:Field=d.ktri, 
Type=CMS_RecipientInfo
140735215203152:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:666:Field=recipientInfos, Type=CMS_EnvelopedData
140735215203152:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:694:
140735215203152:error:0D08403A:asn1 encoding 
routines:ASN1_TEMPLATE_EX_D2I:nested asn1 
error:tasn_dec.c:557:Field=d.envelopedData, Type=CMS_ContentInfo

I tried again to map the structure of the CMS object to the definitions 
in RFC 5652 (comments added with a '%'):

1: SEQUENCE {
2:   OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
                                                    % ContentType
3:   [0] {  % eContent
4:     SEQUENCE {
5:       INTEGER 0 % CMSVersion
           % no OriginatorInfo
6:       SET { % RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
7:         SEQUENCE {
        % SEQUENCE tag should not be present because of implicit tagging?
8:           INTEGER 3
          % version 3 only applicable to KeyAgreeRecipientInfo
9:           [0] {
10:             SEQUENCE {
11:               SEQUENCE {
12:                 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
13:                 OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
14:                 }

In line 7 I can't find a mapping anymore to RFC 5652. The OpenSSL error 
message indicates that it wants to parse a KeyTransRecipientInfo. In 
line 8 the CMSVersion is "3", but that is not applicable to a 
KeyTransRecipientInfo, only to a KeyAgreeRecipientInfo.

------------- dumpasn1 output for CMS message ---------------
  SEQUENCE {
    OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
    [0] {
      SEQUENCE {
        INTEGER 0
        SET {
          SEQUENCE {
            INTEGER 3
            [0] {
              SEQUENCE {
                SEQUENCE {
                  OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
                  OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
                  }
                BIT STRING
                  04 00 69 68 2B EA A2 DD 50 48 52 D2 D7 FF 40 9A
                  9F 86 8E 43 33 42 D5 A4 DE 4A 41 5A 73 F3 99 19
                  A4 C5 19 DF 4D 4E EF 4E 47 54 A1 5A 74 41 F3 50
                  43 94 92 35 2B 37 28 49 53 A8 1D 6E BA 21 C2 E0
                  B0 A1 F0 01 E0 61 B6 91 29 23 52 BA 39 D5 1D FE
                  DA 08 DF C8 7C 11 76 56 73 13 51 B7 8D 69 45 CC
                  A1 D4 57 50 45 2A 63 93 5C A8 FB D4 F3 8F 46 68
                  38 BC 57 81 FD C6 06 86 43 C3 3B 53 90 28 C8 B1
                          [ Another 5 bytes skipped ]
                }
              }
            [1] {
              OCTET STRING C8 71 12 9C B5 64 24 52
              }
            SEQUENCE {
              OBJECT IDENTIFIER '1 3 132 1 11 3'
              SEQUENCE {
                OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45)
                }
              }
            SEQUENCE {
              SEQUENCE {
                SEQUENCE {
                  SEQUENCE {
                    SET {
                      SEQUENCE {
                        OBJECT IDENTIFIER countryName (2 5 4 6)
                        PrintableString 'DE'
                        }
                      }
                    SET {
                      SEQUENCE {
                        OBJECT IDENTIFIER localityName (2 5 4 7)
                        UTF8String 'Munich'
                        }
                      }
                    SET {
                      SEQUENCE {
                        OBJECT IDENTIFIER organizationName (2 5 4 10)
                        UTF8String 'PDFlib GmbH'
                        }
                      }
                    SET {
                      SEQUENCE {
                        OBJECT IDENTIFIER commonName (2 5 4 3)
                        UTF8String 'PDFlib GmbH ATS Demo Intermediate CA'
                        }
                      }
                    }
                  INTEGER 27
                  }
                OCTET STRING
                  63 CE 50 C7 31 8A B9 C8 A3 6A 7B 7C 9D 14 50 33
                  09 7C 5D 3D 7B 34 1B 30
                }
              }
            }
          }
        SEQUENCE {
          OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
          SEQUENCE {
            OBJECT IDENTIFIER aes128-CBC (2 16 840 1 101 3 4 1 2)
            OCTET STRING
              88 9B F1 E8 96 0B A8 4D 9C F1 6F FC E3 7D B8 AC
            }
          [0]
            AB 19 35 70 7F CE 88 17 A0 AD FA A2 55 33 68 FD
            48 9D 26 2E DC 7B A7 96 95 19 FA 1F B8 0C DE E0
          }
        }
      }
    }
------------- dumpasn1 output for CMS message ---------------

-- 
Stephan


From krzysiekw444 at gmail.com  Tue Feb 23 12:36:52 2016
From: krzysiekw444 at gmail.com (krzysztof w)
Date: Tue, 23 Feb 2016 13:36:52 +0100
Subject: [openssl-users] ECDHE PSK ciphersuites
Message-ID: <CADBu4bepX-1Zx0OkjWvqZ3uPWW2mgof8oG5z6f2rq2KkHK=dYA@mail.gmail.com>

Hi,

I looking for OpenSSL version that supports the following cipher suites:

ECDHE-PSK-AES128-CBC-SHA256
DHE-PSK-AES128-CCM8

I've looked through the history of the "include\openssl\tls1.h" file where
they are declared in the current master branch, and found out they were
introduced in commit ea6114c6d0e31e3d6d8897d753afeadec33ddeee (2015-06-28).
Hovever, I did not find this code in the OpenSSL_1_0_2-stable branch.

Please could you explain which stable code should I use to have those
cipher suites?

Regards,
Krzysztof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160223/737ee16b/attachment.html>

From rsalz at akamai.com  Tue Feb 23 12:53:30 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 23 Feb 2016 12:53:30 +0000
Subject: [openssl-users] ECDHE PSK ciphersuites
In-Reply-To: <CADBu4bepX-1Zx0OkjWvqZ3uPWW2mgof8oG5z6f2rq2KkHK=dYA@mail.gmail.com>
References: <CADBu4bepX-1Zx0OkjWvqZ3uPWW2mgof8oG5z6f2rq2KkHK=dYA@mail.gmail.com>
Message-ID: <958a29c1b6eb4a72a4d9cc090947d123@ustx2ex-dag1mb1.msg.corp.akamai.com>


> Please could you explain which stable code should I use to have those cipher suites?

Master, which will be 1.1  It's not done yet.

From steve at openssl.org  Tue Feb 23 13:04:44 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 23 Feb 2016 13:04:44 +0000
Subject: [openssl-users] Is the structure of this CMS object correct?
In-Reply-To: <56CC1927.7050701@pdflib.com>
References: <56B9AE22.6000501@pdflib.com>
 <AF40454C-E74A-4359-B53C-E694AE1FC590@docusign.com>
 <56B9CD84.7020207@pdflib.com>
 <74002D90-1437-45F0-96F3-401B27B8569A@docusign.com>
 <56CC1927.7050701@pdflib.com>
Message-ID: <20160223130444.GA8540@openssl.org>

On Tue, Feb 23, 2016, Stephan M?hlstrasser wrote:

> Am 09.02.16 um 16:39 schrieb Erwann Abalea:
> >Bonjour Stephan,
> >
> >...
> >
> >PKCS#7 and CMS are pretty much interchangeable.
> >Here, your file is strictly not a PKCS#7v1.5, because in this version,
> >RecipientInfo wasn?t a CHOICE (see RFC2315 to see PKCS#7v1.5 definitions).
> >
> >How did you generate this structure? Adobe Acrobat?
> 
> The previous structure was generated with Adobe Acrobat XI.
> 
> I repeated the experiment with Adobe Acrobat DC, and something was
> changed in the structure of the CMS object, but it still does not
> look correct to me (full dumpasn1 output below).
> 
> It is clear to me that there is no problem with OpenSSL here, but I
> would appreciate it if someone with more authority on CMS and ASN.1
> than me could confirm that the CMS structure is broken and that
> OpenSSL is correct to reject it, thanks.
> 

To properly analyse the structure it would help if you included the file you
are trying to parse.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From stm at pdflib.com  Tue Feb 23 13:09:57 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Tue, 23 Feb 2016 14:09:57 +0100
Subject: [openssl-users] Is the structure of this CMS object correct?
In-Reply-To: <20160223130444.GA8540@openssl.org>
References: <56B9AE22.6000501@pdflib.com>
 <AF40454C-E74A-4359-B53C-E694AE1FC590@docusign.com>
 <56B9CD84.7020207@pdflib.com>
 <74002D90-1437-45F0-96F3-401B27B8569A@docusign.com>
 <56CC1927.7050701@pdflib.com> <20160223130444.GA8540@openssl.org>
Message-ID: <56CC5A25.10108@pdflib.com>

Am 23.02.16 um 14:04 schrieb Dr. Stephen Henson:
> On Tue, Feb 23, 2016, Stephan M?hlstrasser wrote:
>
>> Am 09.02.16 um 16:39 schrieb Erwann Abalea:
>>> Bonjour Stephan,
>>>
>>> ...
>>>
>>> PKCS#7 and CMS are pretty much interchangeable.
>>> Here, your file is strictly not a PKCS#7v1.5, because in this version,
>>> RecipientInfo wasn?t a CHOICE (see RFC2315 to see PKCS#7v1.5 definitions).
>>>
>>> How did you generate this structure? Adobe Acrobat?
>>
>> The previous structure was generated with Adobe Acrobat XI.
>>
>> I repeated the experiment with Adobe Acrobat DC, and something was
>> changed in the structure of the CMS object, but it still does not
>> look correct to me (full dumpasn1 output below).
>>
>> It is clear to me that there is no problem with OpenSSL here, but I
>> would appreciate it if someone with more authority on CMS and ASN.1
>> than me could confirm that the CMS structure is broken and that
>> OpenSSL is correct to reject it, thanks.
>>
>
> To properly analyse the structure it would help if you included the file you
> are trying to parse.
>

Sure, here it is. I had thought that ASN.1 dump would be sufficient.

-- 
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cms-DC-AES256.der
Type: application/x-x509-ca-cert
Size: 449 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160223/95259e2d/attachment.crt>

From krzysiekw444 at gmail.com  Tue Feb 23 13:12:02 2016
From: krzysiekw444 at gmail.com (krzysztof w)
Date: Tue, 23 Feb 2016 14:12:02 +0100
Subject: [openssl-users] ECDHE PSK ciphersuites
In-Reply-To: <958a29c1b6eb4a72a4d9cc090947d123@ustx2ex-dag1mb1.msg.corp.akamai.com>
References: <CADBu4bepX-1Zx0OkjWvqZ3uPWW2mgof8oG5z6f2rq2KkHK=dYA@mail.gmail.com>
 <958a29c1b6eb4a72a4d9cc090947d123@ustx2ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CADBu4beCHmcahfj=upVeppHdroCEs6bgae2Wr1Zv28AFCMGbLQ@mail.gmail.com>

I saw there are a couple of "pre" tags for the 1.1 version. I need those
cipher suites only to be able to interact with a specific device and the
security is not important since it is only for testing purposes, where the
transport is not the subject of testing. Will the "OpenSSL_1_1_0-pre3" be
enough to do the work? I mean I understand that probably not all the 1.1
features are done yet, but I'm only interested in providing DTLS
connectivity.

2016-02-23 13:53 GMT+01:00 Salz, Rich <rsalz at akamai.com>:

>
> > Please could you explain which stable code should I use to have those
> cipher suites?
>
> Master, which will be 1.1  It's not done yet.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160223/b54df5b9/attachment.html>

From rsalz at akamai.com  Tue Feb 23 13:15:08 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 23 Feb 2016 13:15:08 +0000
Subject: [openssl-users] ECDHE PSK ciphersuites
In-Reply-To: <CADBu4beCHmcahfj=upVeppHdroCEs6bgae2Wr1Zv28AFCMGbLQ@mail.gmail.com>
References: <CADBu4bepX-1Zx0OkjWvqZ3uPWW2mgof8oG5z6f2rq2KkHK=dYA@mail.gmail.com>
 <958a29c1b6eb4a72a4d9cc090947d123@ustx2ex-dag1mb1.msg.corp.akamai.com>
 <CADBu4beCHmcahfj=upVeppHdroCEs6bgae2Wr1Zv28AFCMGbLQ@mail.gmail.com>
Message-ID: <d240cd2729b24b278852d674bf13ca81@ustx2ex-dag1mb1.msg.corp.akamai.com>

It will probably work for your needs.


From krzysiekw444 at gmail.com  Tue Feb 23 13:56:40 2016
From: krzysiekw444 at gmail.com (krzysztof w)
Date: Tue, 23 Feb 2016 14:56:40 +0100
Subject: [openssl-users] ECDHE PSK ciphersuites
In-Reply-To: <d240cd2729b24b278852d674bf13ca81@ustx2ex-dag1mb1.msg.corp.akamai.com>
References: <CADBu4bepX-1Zx0OkjWvqZ3uPWW2mgof8oG5z6f2rq2KkHK=dYA@mail.gmail.com>
 <958a29c1b6eb4a72a4d9cc090947d123@ustx2ex-dag1mb1.msg.corp.akamai.com>
 <CADBu4beCHmcahfj=upVeppHdroCEs6bgae2Wr1Zv28AFCMGbLQ@mail.gmail.com>
 <d240cd2729b24b278852d674bf13ca81@ustx2ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CADBu4bdXidvL_8mLa0JugFksRy3yBV4EgePG0zGRjZHZ=wMxQw@mail.gmail.com>

Thanks. I'll try it then.

2016-02-23 14:15 GMT+01:00 Salz, Rich <rsalz at akamai.com>:

> It will probably work for your needs.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160223/98993d55/attachment.html>

From xerces9+osl at gmail.com  Tue Feb 23 15:27:26 2016
From: xerces9+osl at gmail.com (=?UTF-8?Q?David_Bala=C5=BEic?=)
Date: Tue, 23 Feb 2016 16:27:26 +0100
Subject: [openssl-users] Firefox problems with two way SSL auth
In-Reply-To: <CAPJ9Yc_Gmd=tbdyrU_5v5uEBOeoDDgYodPqkA+6TtPfKjdP8cg@mail.gmail.com>
References: <CAPJ9Yc874Lu4Mg3r+A6GTQx3c5-AAyV5W_wNv4uxugSpCw5rkQ@mail.gmail.com>
 <CAPJ9Yc_Gmd=tbdyrU_5v5uEBOeoDDgYodPqkA+6TtPfKjdP8cg@mail.gmail.com>
Message-ID: <CAPJ9Yc8jFE23e1OoBwuEuKGqzcU0zPWfV8jx6SANFxJ7aVPHJw@mail.gmail.com>

Apparently it is OpenSSL bug/ticket number 2288.
Hopefully fixed sometime...

Regards,
David

On 12 February 2016 at 18:09, David Bala?ic <xerces9+osl at gmail.com> wrote:
> Hi!
>
> Tomcat released version 8.0.32 which bundles OpenSSL 1.0.2e (see below)
> The issue remains (with the change that now IE can not connect at all,
> it complains about some TLS stuff, did not look into it).
>
> Any hints how to tackle this problem are welcome.
>
> Version details (from tomcat startup log):
> Loaded APR based Apache Tomcat Native library 1.2.4 using APR version 1.5.1.
> OpenSSL successfully initialized (OpenSSL 1.0.2e 3 Dec 2015)
>
> Regards,
> David
>
>
> On 8 January 2016 at 17:02, David Bala?ic <xerces9+osl at gmail.com> wrote:
>> Hi!
>>
>> I encounter this issue when using Firefox to access tomcat (that is
>> using openssl) with client cert authentication.
>>
>> After a certain timeout, the web application does not "see" the
>> clients certificate in requests.
>>
>> The problem happens on different operating systems (Window,s Linux)
>> and browsers.
>>
>> I reported it to tomcat and Firefox, with not much response.
>>
>> There is a simple test case in comment 1 of the tomcat bug (see below).
>>
>> Could someone assist in finding the cause of the problem?
>> I also have pcap traces (somewhere) of working and non working network traffic.
>>
>>
>> Latest tested configuration:
>> tomcat 8.0.30, using OpenSSL 1.0.1m 19 Mar 2015
>> Firefox 43.0.4
>> OS: Windows 7 Pro SP1 64bit
>>
>> The tomcat bug with much details:
>>
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
>>
>> Firefox bug report (not much details):
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1231406
>>
>> Regards,
>> David Bala?ic

From sander at temme.net  Tue Feb 23 16:38:41 2016
From: sander at temme.net (Sander Temme)
Date: Tue, 23 Feb 2016 11:38:41 -0500
Subject: [openssl-users] [openssl-dev] Ubsec and Chil engines
In-Reply-To: <20160222.160034.1279367000656813396.levitte@openssl.org>
References: <20160220.225541.1585601945103016062.levitte@openssl.org>
 <1456140741.4735.272.camel@infradead.org>
 <347004c001fd430aadadceac908e68a2@ustx2ex-dag1mb1.msg.corp.akamai.com>
 <20160222.160034.1279367000656813396.levitte@openssl.org>
Message-ID: <BE11817E-03EC-4FDC-BFEB-106D9A10FFF2@temme.net>

All,

I toyed over the weekend with resurrecting CHIL: intermediate result here https://github.com/sctemme/openssl/tree/rescue-chil and I AM NOT PROUD OF THIS but have no cycles to clean it up for at least a couple of days to come. It builds now but doesn't work: my privkey loading routine doesn't get called and that may be an API change I missed. 

Can we resurrect CHIL for 1.1 along these lines? Then I'd be delighted to join the discussion about p11 for down the road. 

S. 

Sent from my iPhone

> On Feb 22, 2016, at 10:00 AM, Richard Levitte <levitte at openssl.org> wrote:
> 
> In message <347004c001fd430aadadceac908e68a2 at ustx2ex-dag1mb1.msg.corp.akamai.com> on Mon, 22 Feb 2016 14:46:28 +0000, "Salz, Rich" <rsalz at akamai.com> said:
> 
> rsalz> > If we integrate the support natively into OpenSSL, then PKCS#11 URIs (see
> rsalz> > RFC7512) can be first-class citizens throughout the crypto and SSL APIs. Any
> rsalz> > function which takes a filename for a cert or key should also accept? a
> rsalz> > PKCS#11 URI.
> rsalz> 
> rsalz> It'd be great to see a crypto/pkcs11 directory with full native support (as much as possible).
> rsalz> 
> rsalz> But really doubtful to happen in 1.1 as the API freeze is in a month.
> 
> Yeah, 1.1 is unrealistic, I'm sorry to say.
> 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/

From steve at openssl.org  Tue Feb 23 17:26:37 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 23 Feb 2016 17:26:37 +0000
Subject: [openssl-users] Is the structure of this CMS object correct?
In-Reply-To: <56CC1927.7050701@pdflib.com>
References: <56B9AE22.6000501@pdflib.com>
 <AF40454C-E74A-4359-B53C-E694AE1FC590@docusign.com>
 <56B9CD84.7020207@pdflib.com>
 <74002D90-1437-45F0-96F3-401B27B8569A@docusign.com>
 <56CC1927.7050701@pdflib.com>
Message-ID: <20160223172637.GA15299@openssl.org>

On Tue, Feb 23, 2016, Stephan M?hlstrasser wrote:

> I tried again to map the structure of the CMS object to the
> definitions in RFC 5652 (comments added with a '%'):
> 
> 1: SEQUENCE {
> 2:   OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
>                                                    % ContentType
> 3:   [0] {  % eContent
> 4:     SEQUENCE {
> 5:       INTEGER 0 % CMSVersion
>           % no OriginatorInfo
> 6:       SET { % RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
> 7:         SEQUENCE {
>        % SEQUENCE tag should not be present because of implicit tagging?

Yes, because it is using the key agreement choice type it should be
tagged [1] IMPLICIT but it is not which is why OpenSSL thinks it is key
transport.

> 8:           INTEGER 3
>          % version 3 only applicable to KeyAgreeRecipientInfo
> 9:           [0] {

Assume this is KeyAgreeRecipientInfo.. the above tag would indicate the
"originator" field.

> 10:             SEQUENCE {

Here it is wrong again. The untagged form is "IssuerAndSerialNumber" which
the fields below certainly aren't. It looks like originatorKey which should be
tagged [1] IMPLICIT.

> 11:               SEQUENCE {
> 12:                 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
> 13:                 OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
> 14:                 }
> 

So yes it's pretty broken.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From cloud.force858 at gmail.com  Wed Feb 24 00:48:54 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Tue, 23 Feb 2016 16:48:54 -0800
Subject: [openssl-users] Helps needed regarding the error "fingerprint does
	not match:fips.c:232:"
Message-ID: <CAEsYawxW28Oah1v31eYMT6ckrcO0w1=fx0SUa+Gz_j8nkF6L6w@mail.gmail.com>

Hi All:

I built the FIPS modules on Ubuntu platform and was trying to build the
FIPS capable OpenSSL library.

The build went fine but when I ran the following test, the fingerprint
error showed up:

*OPENSSL_FIPS=1 openssl md5*



*139728296724128:error:2D06B06F:FIPS
routines:FIPS_check_incore_fingerprint:fingerprint does not
match:fips.c:232:*

Not sure what I did wrong here. I built the OpenSSL library using Ubuntu
OpenSSL package build script. I also attached the Makefile.

Any helps and suggestions are greatly appreciated.

-- 
Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160223/4ae1c9b7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 25917 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160223/4ae1c9b7/attachment-0001.obj>

From steve at openssl.org  Wed Feb 24 01:01:34 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 24 Feb 2016 01:01:34 +0000
Subject: [openssl-users] Helps needed regarding the error "fingerprint
 does not match:fips.c:232:"
In-Reply-To: <CAEsYawxW28Oah1v31eYMT6ckrcO0w1=fx0SUa+Gz_j8nkF6L6w@mail.gmail.com>
References: <CAEsYawxW28Oah1v31eYMT6ckrcO0w1=fx0SUa+Gz_j8nkF6L6w@mail.gmail.com>
Message-ID: <20160224010134.GA26349@openssl.org>

On Tue, Feb 23, 2016, cloud force wrote:

> Hi All:
> 
> I built the FIPS modules on Ubuntu platform and was trying to build the
> FIPS capable OpenSSL library.
> 
> The build went fine but when I ran the following test, the fingerprint
> error showed up:
> 
> *OPENSSL_FIPS=1 openssl md5*
> 

I suggest you first try building the FIPS capable OpenSSL in the standard way
i.e.

./config fips
make

and see if you get the same problem.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From datta.pm at gmail.com  Wed Feb 24 01:06:26 2016
From: datta.pm at gmail.com (Datta Prabhu Maddikunta)
Date: Tue, 23 Feb 2016 17:06:26 -0800
Subject: [openssl-users] Assembly code errors while building
	openssl-1.0.2f on Ubuntu 14.04
In-Reply-To: <CAHqqAKUL8u2SV+0E7VCgsAU-2BN=bR=Cd8522FWNxL0dq6CnZg@mail.gmail.com>
References: <CAHqqAKUL8u2SV+0E7VCgsAU-2BN=bR=Cd8522FWNxL0dq6CnZg@mail.gmail.com>
Message-ID: <CAHqqAKWQQ3NhhihTJ1fcECLJAGnjn2SpHjEZCrdjwndiupfQTg@mail.gmail.com>

>
> Hi Team,
>
> I am trying to build 'openssl-1.0.2f' on my Ubuntu 14.04 and I end up
> seeing the "
> Error: no such instruction: `vpclmulqdq $0,%xmm6,%xmm14,%xmm0'" errors on
> my machine(Please see the complete error at the end of this mail.).
>
> The o/p of uname is as below:
>
> -----------
> $ uname -a
> Linux <my_host_name> 3.13.0-74-generic #118-Ubuntu SMP Thu Dec 17 22:52:10
> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> -----------
> My GNU assembler version is as below:
>

================
$gcc -Wa,-v -c -o /dev/null -x assembler /dev/null
GNU assembler version 2.24 (x86_64-linux-gnu) using BFD version (GNU
Binutils for Ubuntu) 2.24
=================


> I can provide any further information required .
>
> Can anyone guess the reason why this error is being thrown on my machine?
>
> Any inputs would be appreciated .,
>
> Thanks.,
> Datta M
>
>
> =============================================
> ......
> /usr/bin/perl asm/ghash-x86_64.pl elf > ghash-x86_64.s
> <my_path_to_compiler>/bin/gcc -I.. -I../.. -I../modes -I../asn1 -I../evp
> -I../../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT
> -DDSO_DLFCN -DHAVE_DLFCN_H -DSSL_ALLOW_ADH -m64 -DL_ENDIAN -O3 -Wall
> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
> -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
> -DECP_NISTZ256_ASM -c  -o ghash-x86_64.o ghash-x86_64.s
> <my_path_to_cross_compiler>/bin/as: Execution
> of <my_path_to_cross_compiler>/bin/compat-as/as failed with error code 0
> ghash-x86_64.s: Assembler messages:
> `vpclmulqdq $17,%xmm2,%xmm0,%xmm1'
> ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq
> $0,%xmm2,%xmm0,%xmm0'
> ghash-x86_64.s:1283: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm3,%xmm3'
> ghash-x86_64.s:1312: Error: no such instruction: `vpclmulqdq
> $17,%xmm2,%xmm0,%xmm1'
> ghash-x86_64.s:1313: Error: no such instruction: `vpclmulqdq
> $0,%xmm2,%xmm0,%xmm0'
> ghash-x86_64.s:1314: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm3,%xmm3'
> ghash-x86_64.s:1383: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm14,%xmm0'
> ghash-x86_64.s:1386: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm14,%xmm1'
> ghash-x86_64.s:1390: Error: no such instruction: `vpclmulqdq
> $0,%xmm7,%xmm9,%xmm2'
> ghash-x86_64.s:1394: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm15,%xmm3'
> ghash-x86_64.s:1396: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm15,%xmm4'
> ghash-x86_64.s:1400: Error: no such instruction: `vpclmulqdq
> $16,%xmm7,%xmm8,%xmm5'
> ghash-x86_64.s:1405: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm14,%xmm0'
> ghash-x86_64.s:1408: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm14,%xmm1'
> ghash-x86_64.s:1411: Error: no such instruction: `vpclmulqdq
> $0,%xmm7,%xmm9,%xmm2'
> ghash-x86_64.s:1416: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm15,%xmm3'
> ghash-x86_64.s:1419: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm15,%xmm4'
> ghash-x86_64.s:1423: Error: no such instruction: `vpclmulqdq
> $16,%xmm7,%xmm8,%xmm5'
> ghash-x86_64.s:1429: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm14,%xmm0'
> ghash-x86_64.s:1432: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm14,%xmm1'
> ghash-x86_64.s:1436: Error: no such instruction: `vpclmulqdq
> $0,%xmm7,%xmm9,%xmm2'
> ghash-x86_64.s:1441: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm15,%xmm3'
> ghash-x86_64.s:1444: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm15,%xmm4'
> ghash-x86_64.s:1448: Error: no such instruction: `vpclmulqdq
> $16,%xmm7,%xmm8,%xmm5'
> ghash-x86_64.s:1454: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm14,%xmm0'
> ghash-x86_64.s:1457: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm14,%xmm1'
> ghash-x86_64.s:1460: Error: no such instruction: `vpclmulqdq
> $16,%xmm7,%xmm9,%xmm2'
> ghash-x86_64.s:1476: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm15,%xmm10'
> ghash-x86_64.s:1479: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm15,%xmm11'
> ghash-x86_64.s:1483: Error: no such instruction: `vpclmulqdq
> $0,%xmm7,%xmm8,%xmm12'
> ghash-x86_64.s:1488: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm14,%xmm0'
> ghash-x86_64.s:1491: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm14,%xmm1'
> ghash-x86_64.s:1495: Error: no such instruction: `vpclmulqdq
> $0,%xmm7,%xmm9,%xmm2'
> ghash-x86_64.s:1501: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm15,%xmm3'
> ghash-x86_64.s:1505: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm15,%xmm4'
> ghash-x86_64.s:1513: Error: no such instruction: `vpclmulqdq
> $16,%xmm7,%xmm8,%xmm5'
> ghash-x86_64.s:1520: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm14,%xmm0'
> ghash-x86_64.s:1523: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm14,%xmm1'
> ghash-x86_64.s:1527: Error: no such instruction: `vpclmulqdq
> $0,%xmm7,%xmm9,%xmm2'
> ghash-x86_64.s:1532: Error: no such instruction: `vpclmulqdq
> $16,(%r10),%xmm10,%xmm10'
> ghash-x86_64.s:1533: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm15,%xmm3'
> ghash-x86_64.s:1536: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm15,%xmm4'
> ghash-x86_64.s:1540: Error: no such instruction: `vpclmulqdq
> $16,%xmm7,%xmm8,%xmm5'
> ghash-x86_64.s:1546: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm14,%xmm0'
> ghash-x86_64.s:1549: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm14,%xmm1'
> ghash-x86_64.s:1553: Error: no such instruction: `vpclmulqdq
> $0,%xmm7,%xmm9,%xmm2'
> ghash-x86_64.s:1560: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm15,%xmm3'
> ghash-x86_64.s:1563: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm15,%xmm4'
> ghash-x86_64.s:1565: Error: no such instruction: `vpclmulqdq
> $16,(%r10),%xmm10,%xmm10'
> ghash-x86_64.s:1569: Error: no such instruction: `vpclmulqdq
> $16,%xmm7,%xmm8,%xmm5'
> ghash-x86_64.s:1575: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm14,%xmm0'
> ghash-x86_64.s:1577: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm14,%xmm1'
> ghash-x86_64.s:1580: Error: no such instruction: `vpclmulqdq
> $16,%xmm7,%xmm9,%xmm2'
> ghash-x86_64.s:1606: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm15,%xmm0'
> ghash-x86_64.s:1610: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm15,%xmm1'
> ghash-x86_64.s:1614: Error: no such instruction: `vpclmulqdq
> $0,%xmm7,%xmm8,%xmm2'
> ghash-x86_64.s:1621: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm15,%xmm0'
> ghash-x86_64.s:1625: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm15,%xmm1'
> ghash-x86_64.s:1629: Error: no such instruction: `vpclmulqdq
> $0,%xmm7,%xmm8,%xmm2'
> ghash-x86_64.s:1636: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm15,%xmm0'
> ghash-x86_64.s:1640: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm15,%xmm1'
> ghash-x86_64.s:1644: Error: no such instruction: `vpclmulqdq
> $0,%xmm7,%xmm8,%xmm2'
> ghash-x86_64.s:1651: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm15,%xmm0'
> ghash-x86_64.s:1655: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm15,%xmm1'
> ghash-x86_64.s:1659: Error: no such instruction: `vpclmulqdq
> $0,%xmm7,%xmm8,%xmm2'
> ghash-x86_64.s:1666: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm15,%xmm0'
> ghash-x86_64.s:1670: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm15,%xmm1'
> ghash-x86_64.s:1674: Error: no such instruction: `vpclmulqdq
> $0,%xmm7,%xmm8,%xmm2'
> ghash-x86_64.s:1681: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm15,%xmm0'
> ghash-x86_64.s:1685: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm15,%xmm1'
> ghash-x86_64.s:1689: Error: no such instruction: `vpclmulqdq
> $0,%xmm7,%xmm8,%xmm2'
> ghash-x86_64.s:1700: Error: no such instruction: `vpclmulqdq
> $0,%xmm6,%xmm15,%xmm0'
> ghash-x86_64.s:1703: Error: no such instruction: `vpclmulqdq
> $17,%xmm6,%xmm15,%xmm1'
> ghash-x86_64.s:1705: Error: no such instruction: `vpclmulqdq
> $0,%xmm7,%xmm8,%xmm2'
> ghash-x86_64.s:1720: Error: no such instruction: `vpclmulqdq
> $16,%xmm12,%xmm10,%xmm9'
> ghash-x86_64.s:1724: Error: no such instruction: `vpclmulqdq
> $16,%xmm12,%xmm10,%xmm9'
> make[2]: *** [ghash-x86_64.o] Error 1
> make[2]: Leaving directory `/openssl/openssl-1.0.2e/crypto/modes'
> make[1]: *** [subdirs] Error 1
> make[1]: Leaving directory /openssl/openssl-1.0.2e/crypto'
> make: *** [build_crypto] Error 1
> scons: *** Error 2
> scons: *** [/openssl/.build] Error 2
> scons: building terminated because of errors.
>
> =============================================
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160223/28dc2fe5/attachment.html>

From security.veteran at gmail.com  Wed Feb 24 01:11:12 2016
From: security.veteran at gmail.com (security veteran)
Date: Tue, 23 Feb 2016 17:11:12 -0800
Subject: [openssl-users] Helps needed regarding the error "fingerprint
 does not match:fips.c:232:"
In-Reply-To: <20160224010134.GA26349@openssl.org>
References: <CAEsYawxW28Oah1v31eYMT6ckrcO0w1=fx0SUa+Gz_j8nkF6L6w@mail.gmail.com>
 <20160224010134.GA26349@openssl.org>
Message-ID: <CAC5owtGYQV4Fn3+0J5CuNpnVFWT+PXsmyeJCJ7KN+p+CBDTRGg@mail.gmail.com>

Hi Steve,

Thanks. Yes I first built it using the standard way (./config fips shared)
and it went fine.
It's just when I switched to using the debian/ ubuntu build script (which
generated a slightly different Makefile compared to the standard one).

Not sure what could cause this problem.

I also ran the "fips_algvs fips_test_suite post" test and it went fine.

What could be causing this error?

Thanks and I truly appreciate your helps.

Rich

On Tue, Feb 23, 2016 at 5:01 PM, Dr. Stephen Henson <steve at openssl.org>
wrote:

> On Tue, Feb 23, 2016, cloud force wrote:
>
> > Hi All:
> >
> > I built the FIPS modules on Ubuntu platform and was trying to build the
> > FIPS capable OpenSSL library.
> >
> > The build went fine but when I ran the following test, the fingerprint
> > error showed up:
> >
> > *OPENSSL_FIPS=1 openssl md5*
> >
>
> I suggest you first try building the FIPS capable OpenSSL in the standard
> way
> i.e.
>
> ./config fips
> make
>
> and see if you get the same problem.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160223/754a822d/attachment-0001.html>

From stm at pdflib.com  Wed Feb 24 07:20:42 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Wed, 24 Feb 2016 08:20:42 +0100
Subject: [openssl-users] Is the structure of this CMS object correct?
In-Reply-To: <20160223172637.GA15299@openssl.org>
References: <56B9AE22.6000501@pdflib.com>
 <AF40454C-E74A-4359-B53C-E694AE1FC590@docusign.com>
 <56B9CD84.7020207@pdflib.com>
 <74002D90-1437-45F0-96F3-401B27B8569A@docusign.com>
 <56CC1927.7050701@pdflib.com> <20160223172637.GA15299@openssl.org>
Message-ID: <56CD59CA.9000905@pdflib.com>

Am 23.02.16 um 18:26 schrieb Dr. Stephen Henson:
> On Tue, Feb 23, 2016, Stephan M?hlstrasser wrote:
>
> ...
>
> So yes it's pretty broken.
>
> Steve.

Thank you for taking the time to analyse this, Steve.

-- 
Stephan

From michal at x-net.pl  Wed Feb 24 10:15:29 2016
From: michal at x-net.pl (michal michal)
Date: Wed, 24 Feb 2016 11:15:29 +0100 (CET)
Subject: [openssl-users] automatic renegotiation
Message-ID: <51472192.12783.458adbdc-527e-4cfe-8246-769483c1a8a4.open-xchange@webmail.home-whs.pl>

Hi,

I'm looking for automatic periodical renegotiation code example.

I found one in group archives:

SSL_CTX* ctx;
BIO* bio = BIO_new_ssl(ctx, false);
BIO_push(bio, BIO_new_socket((int)fd, 0);
BIO_set_ssl_renegotiate_bytes(bio, bytes);
BIO_set_ssl_renegotiate_timeout(bio, seconds);

but it is not working for me - BIO_get_num_renegotiates(bio) always returns 0.

Are there any specific prerequisites to get it working? Or do you have any other
example.

--

Michal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160224/b42ce9d6/attachment.html>

From rsalz at akamai.com  Wed Feb 24 15:31:07 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 24 Feb 2016 15:31:07 +0000
Subject: [openssl-users] automatic renegotiation
In-Reply-To: <51472192.12783.458adbdc-527e-4cfe-8246-769483c1a8a4.open-xchange@webmail.home-whs.pl>
References: <51472192.12783.458adbdc-527e-4cfe-8246-769483c1a8a4.open-xchange@webmail.home-whs.pl>
Message-ID: <c52c7441f71640ffa9403cc5bd4c7042@ustx2ex-dag1mb1.msg.corp.akamai.com>

I don't believe OpenSSL actually does automatic renegotiation, but I could be wrong.

From lists at rustichelli.net  Wed Feb 24 16:22:08 2016
From: lists at rustichelli.net (lists)
Date: Wed, 24 Feb 2016 17:22:08 +0100
Subject: [openssl-users] upgrade to 1.0.1r breaks script that worked for
	years. Config issue?
Message-ID: <56CDD8B0.3040109@rustichelli.net>


Hi all,

recently I have upgraded from OpenSSL 1.0.1e to 1.0.1r (system packages 
on Slackware 14.1) but a CA script that I have been using for years, 
with countless OpenSSL versions, stopped working.
It also relies on the pkcs11 engine to sign but my first guess is that 
the issue is in the OpenSSL configuration files (handled differently in 
the new version?) and not some engine issue.
Re-installing the OpenSSL 1.0.1e pack makes things work again.

Here is what happens. First, I run (nothing special here)

/usr/bin/openssl genrsa -rand blahblahblah -out 
./CERTS/depot/Ubi2016.key 1024
/usr/bin/openssl req -sha1 -config /tmp/Ubi.gendata.tmp -new -key 
./CERTS/depot/Ubi2016.key -out ./CERTS/depot/Ubi2016.csr

This is one sample CSR (openssl req -verify tells the signature is fine):

-----BEGIN CERTIFICATE REQUEST-----
MIIB1TCCAT4CAQAwgZQxCzAJBgNVBAYTAklUMQ4wDAYDVQQIDAVJdGFseTENMAsG
A1UEBwwEUm9tZTENMAsGA1UECgwER1Q1MDEMMAoGA1UECwwDRGV2MRwwGgYDVQQD
DBNVbWJlcnRvIFJ1c3RpY2hlbGxpMSswKQYJKoZIhvcNAQkBFhx1bWJlcnRvLnJ1
c3RpY2hlbGxpQGd0NTAub3JnMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+
6vSzIWKaAy0OYa/Er6B6ZdmlZDFHXHW7p9Tnvhg+QmwETQ/XSjwbz/3WZVcp3DnD
bYWoNK3LibEWon8Vhhcu2wPMfTg8Oj98NX1ExFtk7Va+XrZdJreKX9tK3qbFRWTg
Y2giYQHzAH99IQKjHQEzVQ5zJ8W+OLpqmVXmmdr3YQIDAQABoAAwDQYJKoZIhvcN
AQEFBQADgYEAFaT2sx5U6STFSBC828iPUDCUkIfTAH5GKirWzBHbFlhNsD7aaWb1
DnzgfRVErkPoZcw7xiRqitnHC8BO9wrtR3cJBX8zAlvbQV4/yTUTO4b4X6OaLN+k
dfL/2lDx605XGtgf3fmqQgmlD+KBhzVQU6j+pkIaHdpC5CqC4srgdVw=
-----END CERTIFICATE REQUEST-----

and when it is time to sign the CSR using a smart card containing the CA 
certificate:

export OPENSSL_CONF=/tmp/my.conf

/usr/bin/openssl x509 -extfile ./ETC/OSSL.default_x509_auth.cfg \
     -days 2000 -sha256 \
     -CAserial ./ETC/CA.serial -CA ./ETC/CA.2048.crt \
     -in ./CERTS/depot/Ubi2016.csr \
     -req -out ./CERTS/depot/Ubi2016.crt \
     -engine pkcs11 -CAkey slot_0-id_aaaa \
     -CAkeyform engine -passin pass:***

where I have this extension file (OSSL.default_x509_auth.cfg):

----

extensions = x509v3

[ x509v3 ]
keyUsage              = digitalSignature
extendedKeyUsage      = clientAuth,emailProtection
crlDistributionPoints = URI:http://ldap.secure-edge.com/secure-edge-ca.crl
subjectAltName        = email:copy
basicConstraints      = CA:false,pathlen:0
nsComment             = "Certificato X.509 v3 FIRMA generato da Secure 
Edge Global Root CA"
nsCertType            = client,email

subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
issuerAltName=issuer:copy

---

and this /tmp/my.conf:

openssl_conf = openssl_def
[openssl_def]
engines = engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id    = pkcs11
dynamic_path = "/usr/local/lib/engines/engine_pkcs11.so"
MODULE_PATH  = "./ETC/libbit4ipki.Venice.so"
init         = 0


Now, with OpenSSL 1.0.1e all is fine (first two are just warnings):

openssl (lock_dbg_cb): already locked (mode=9, type=30) at eng_list.c:284
openssl (lock_dbg_cb): not locked (mode=10, type=30) at eng_table.c:186
engine "pkcs11" set.
Signature ok
subject=/C=IT/ST=Italy/L=Rome/O=GT50/OU=Dev/CN=Umberto 
Rustichelli/emailAddress=umberto.rustichelli at gt50.org


With OpenSSL 1.0.1r I get:

openssl (lock_dbg_cb): already locked (mode=9, type=30) at eng_list.c:265
openssl (lock_dbg_cb): not locked (mode=10, type=30) at eng_table.c:187
engine "pkcs11" set.
Signature did not match the certificate request


For completeness, I have installed engine_pkcs11 1.0.8, libp11 0.2.8, 
pcsc-lite 1.8.11, ccid 1.4.17.

Before I try some heavy debugging, does anybody know of a change from 
version 1.0.1e to 1.0.1r that would prevent the commands above from working?
If so, is it something that goes away with newer versions?
If not so (no clue), where should I look for?

Thanks a lot

   Umberto Rustichelli aka Ubi


From pdrotter at us.ibm.com  Wed Feb 24 16:31:42 2016
From: pdrotter at us.ibm.com (Neptune)
Date: Wed, 24 Feb 2016 09:31:42 -0700 (MST)
Subject: [openssl-users] RSA_generate_key fails in FIPS Mode with key size
	2048
Message-ID: <1456331502308-63989.post@n7.nabble.com>

Using:
FIPS Object Module 2.0.9
OpenSSL 1.0.1l

When I call RSA_generate_key:
if (rsa = RSA_generate_key(keySize, RSA_F4, NULL, NULL))

I get the following error string:
(OPENSSL error:04081078:rsa routines:RSA_BUILTIN_KEYGEN:key size too small)

As I understand, RSA Key size must be 2048 or greater in FIPS mode, so I
printed out the key size just before calling the above function:

******** KEYSIZE = 2048.

What else could cause this function to report a key size too small if it is
2048 bits? Is 2048 still FIPS-compliant? 
BTW: this works if FIPS mode is off.

Thanks!





--
View this message in context: http://openssl.6102.n7.nabble.com/RSA-generate-key-fails-in-FIPS-Mode-with-key-size-2048-tp63989.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From kurt at roeckx.be  Wed Feb 24 18:46:17 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Wed, 24 Feb 2016 19:46:17 +0100
Subject: [openssl-users] upgrade to 1.0.1r breaks script that worked for
 years. Config issue?
In-Reply-To: <56CDD8B0.3040109@rustichelli.net>
References: <56CDD8B0.3040109@rustichelli.net>
Message-ID: <20160224184617.GA26884@roeckx.be>

On Wed, Feb 24, 2016 at 05:22:08PM +0100, lists wrote:
> 
> Before I try some heavy debugging, does anybody know of a change from
> version 1.0.1e to 1.0.1r that would prevent the commands above from working?

Can you try reverting commit
23a58779f53a9060c823d00d76b3070cad61d9a3?  I've attached a patch.

This is something that will get reverted in the next release.  But
if that fixes something, it's actually something in the engine
that's broken.


Kurt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: revert_RSA_FLAG_SIGN_VER.patch
Type: text/x-diff
Size: 868 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160224/b2ad5513/attachment.patch>

From gagandeep209 at gmail.com  Wed Feb 24 19:03:32 2016
From: gagandeep209 at gmail.com (Gagandeep Singh Panesar)
Date: Thu, 25 Feb 2016 00:33:32 +0530
Subject: [openssl-users] Problem getting actual Client protocol version on
	server side
Message-ID: <CACDzQtb5izQCrmXVt-ix1UVHhs53M=KsWPcjr-0YL4bczbcpRQ@mail.gmail.com>

Hi Team,

I am trying to retrieve client SSL protocol version in case of handshake
failure on server side but couldn't get actual protocol version.

Eg:
Server supports TLSv1.1 and client supports SSLv3.
When I query from client and try to decrypt client protocol it shows
TLSv1.2 but it should give SSLv3 as client protocol.

I am using SSL_get_version() to get client protocol.

How can I get actual protocol sent by client at server side...?

Thanks,
Gagandeep Singh Panesar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160225/8e31bb6d/attachment.html>

From rsalz at akamai.com  Wed Feb 24 19:05:25 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 24 Feb 2016 19:05:25 +0000
Subject: [openssl-users] Problem getting actual Client protocol version
	on	server side
In-Reply-To: <CACDzQtb5izQCrmXVt-ix1UVHhs53M=KsWPcjr-0YL4bczbcpRQ@mail.gmail.com>
References: <CACDzQtb5izQCrmXVt-ix1UVHhs53M=KsWPcjr-0YL4bczbcpRQ@mail.gmail.com>
Message-ID: <9d209e18d3f14c38919a0ee712b94844@ustx2ex-dag1mb1.msg.corp.akamai.com>

> How can I get actual protocol sent by client at server side...?

If the handshake fails, the server doesn't send a version.

--  
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz

From gagandeep209 at gmail.com  Wed Feb 24 19:09:18 2016
From: gagandeep209 at gmail.com (Gagandeep Singh Panesar)
Date: Thu, 25 Feb 2016 00:39:18 +0530
Subject: [openssl-users] Problem getting actual Client protocol version
 on server side
In-Reply-To: <9d209e18d3f14c38919a0ee712b94844@ustx2ex-dag1mb1.msg.corp.akamai.com>
References: <CACDzQtb5izQCrmXVt-ix1UVHhs53M=KsWPcjr-0YL4bczbcpRQ@mail.gmail.com>
 <9d209e18d3f14c38919a0ee712b94844@ustx2ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CACDzQtbQP1qrg7REB0tpaHqAUXxxCcxOym2Lxga3iBOz3oO_vQ@mail.gmail.com>

So is there any way of identifying client protocol info at server side.
I want to log why handshake failed at server side.
On Feb 25, 2016 12:36 AM, "Salz, Rich" <rsalz at akamai.com> wrote:

> > How can I get actual protocol sent by client at server side...?
>
> If the handshake fails, the server doesn't send a version.
>
> --
> Senior Architect, Akamai Technologies
> IM: richsalz at jabber.at Twitter: RichSalz
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160225/e7e55fcb/attachment.html>

From steve at openssl.org  Wed Feb 24 19:50:18 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 24 Feb 2016 19:50:18 +0000
Subject: [openssl-users] upgrade to 1.0.1r breaks script that worked for
 years. Config issue?
In-Reply-To: <56CDD8B0.3040109@rustichelli.net>
References: <56CDD8B0.3040109@rustichelli.net>
Message-ID: <20160224195018.GA14592@openssl.org>

On Wed, Feb 24, 2016, lists wrote:

> 
> extensions = x509v3
> 
> [ x509v3 ]
> keyUsage              = digitalSignature
> extendedKeyUsage      = clientAuth,emailProtection
> crlDistributionPoints = URI:http://ldap.secure-edge.com/secure-edge-ca.crl
> subjectAltName        = email:copy
> basicConstraints      = CA:false,pathlen:0

While this isn't the cause of your problem you should NOT use pathelen if you
have CA:false. An application might reject such a certificate due to
inconsistent extension values.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From openssl-users at dukhovni.org  Wed Feb 24 20:37:51 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 24 Feb 2016 20:37:51 +0000
Subject: [openssl-users] Problem getting actual Client protocol version
 on server side
In-Reply-To: <CACDzQtb5izQCrmXVt-ix1UVHhs53M=KsWPcjr-0YL4bczbcpRQ@mail.gmail.com>
References: <CACDzQtb5izQCrmXVt-ix1UVHhs53M=KsWPcjr-0YL4bczbcpRQ@mail.gmail.com>
Message-ID: <20160224203750.GN12869@mournblade.imrryr.org>

On Thu, Feb 25, 2016 at 12:33:32AM +0530, Gagandeep Singh Panesar wrote:

> I am trying to retrieve client SSL protocol version in case of handshake
> failure on server side but couldn't get actual protocol version.
> 
> Eg:
> Server supports TLSv1.1 and client supports SSLv3.
> When I query from client and try to decrypt client protocol it shows
> TLSv1.2 but it should give SSLv3 as client protocol.
> 
> I am using SSL_get_version() to get client protocol.
> 
> How can I get actual protocol sent by client at server side...?

There is no public interface for this.  Wireshark is your best bet.

-- 
	Viktor.

From steve at openssl.org  Wed Feb 24 23:14:03 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 24 Feb 2016 23:14:03 +0000
Subject: [openssl-users] RSA_generate_key fails in FIPS Mode with key
 size 2048
In-Reply-To: <1456331502308-63989.post@n7.nabble.com>
References: <1456331502308-63989.post@n7.nabble.com>
Message-ID: <20160224231403.GA19424@openssl.org>

On Wed, Feb 24, 2016, Neptune wrote:

> Using:
> FIPS Object Module 2.0.9
> OpenSSL 1.0.1l
> 
> When I call RSA_generate_key:
> if (rsa = RSA_generate_key(keySize, RSA_F4, NULL, NULL))
> 
> I get the following error string:
> (OPENSSL error:04081078:rsa routines:RSA_BUILTIN_KEYGEN:key size too small)
> 
> As I understand, RSA Key size must be 2048 or greater in FIPS mode, so I
> printed out the key size just before calling the above function:
> 
> ******** KEYSIZE = 2048.
> 
> What else could cause this function to report a key size too small if it is
> 2048 bits? Is 2048 still FIPS-compliant? 
> BTW: this works if FIPS mode is off.
> 

That isn't the error I'd expect if it was rejecting the key size straight
away. Do you have a small program that can reproduce this?

What happens if you do:

OPENSSL_FIPS=1 openssl genrsa 2048

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From cloud.force858 at gmail.com  Thu Feb 25 01:59:25 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Wed, 24 Feb 2016 17:59:25 -0800
Subject: [openssl-users] Helps needed regarding the error "fingerprint
 does not match:fips.c:232:"
In-Reply-To: <20160224010134.GA26349@openssl.org>
References: <CAEsYawxW28Oah1v31eYMT6ckrcO0w1=fx0SUa+Gz_j8nkF6L6w@mail.gmail.com>
 <20160224010134.GA26349@openssl.org>
Message-ID: <CAEsYawyQSyjPKYVEJoNYWyxm1qg3fb-RzQJ-WprYSxycEjTV-w@mail.gmail.com>

I built the FIPS capable OpenSSL in the standard way (i.e. ./config fips; make;
make install) and it worked.

After some tracing on the source code of fips.c I found that the mismatch
error was due to the fact that the content of the two variables "sig" and
"FIPS_SIGNATURE" are different when the OpenSSL lib was built using the
Ubuntu build script. When building the lib using the standard way, the
content of "sig" and "FIPS_SIGNATURE" are the same.

Does anyone know what could cause the content of "sig" and "FIPS_SIGNATURE"
 to be different (and hence causes the "fingerprint does not match" error)?

Thanks and any suggestions are truly appreciated.



On Tue, Feb 23, 2016 at 5:01 PM, Dr. Stephen Henson <steve at openssl.org>
wrote:

> On Tue, Feb 23, 2016, cloud force wrote:
>
> > Hi All:
> >
> > I built the FIPS modules on Ubuntu platform and was trying to build the
> > FIPS capable OpenSSL library.
> >
> > The build went fine but when I ran the following test, the fingerprint
> > error showed up:
> >
> > *OPENSSL_FIPS=1 openssl md5*
> >
>
> I suggest you first try building the FIPS capable OpenSSL in the standard
> way
> i.e.
>
> ./config fips
> make
>
> and see if you get the same problem.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160224/4cf1fe9f/attachment.html>

From cloud.force858 at gmail.com  Thu Feb 25 02:11:41 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Wed, 24 Feb 2016 18:11:41 -0800
Subject: [openssl-users] Helps needed regarding the error "fingerprint
 does not match:fips.c:232:"
In-Reply-To: <CAEsYawyQSyjPKYVEJoNYWyxm1qg3fb-RzQJ-WprYSxycEjTV-w@mail.gmail.com>
References: <CAEsYawxW28Oah1v31eYMT6ckrcO0w1=fx0SUa+Gz_j8nkF6L6w@mail.gmail.com>
 <20160224010134.GA26349@openssl.org>
 <CAEsYawyQSyjPKYVEJoNYWyxm1qg3fb-RzQJ-WprYSxycEjTV-w@mail.gmail.com>
Message-ID: <CAEsYawxrC0S57cagtD_PzuC2xUpyGc+ihv-eTLkqCH_M3p=kQw@mail.gmail.com>

Actually it looks like when I ran the tests using the OpenSSL FIPS library
which I built using Ubuntu build script, the content of FIPS_SIGNATURE
seemed to be empty.

Can anyone tell me how was the value of sig and FIPS_SIGNATURE (near fips.c
line 222) was computed and assigned?

Thanks.

On Wed, Feb 24, 2016 at 5:59 PM, cloud force <cloud.force858 at gmail.com>
wrote:

> I built the FIPS capable OpenSSL in the standard way (i.e. ./config fips; make;
> make install) and it worked.
>
> After some tracing on the source code of fips.c I found that the mismatch
> error was due to the fact that the content of the two variables "sig" and
> "FIPS_SIGNATURE" are different when the OpenSSL lib was built using the
> Ubuntu build script. When building the lib using the standard way, the
> content of "sig" and "FIPS_SIGNATURE" are the same.
>
> Does anyone know what could cause the content of "sig" and
> "FIPS_SIGNATURE"  to be different (and hence causes the "fingerprint does
> not match" error)?
>
> Thanks and any suggestions are truly appreciated.
>
>
>
> On Tue, Feb 23, 2016 at 5:01 PM, Dr. Stephen Henson <steve at openssl.org>
> wrote:
>
>> On Tue, Feb 23, 2016, cloud force wrote:
>>
>> > Hi All:
>> >
>> > I built the FIPS modules on Ubuntu platform and was trying to build the
>> > FIPS capable OpenSSL library.
>> >
>> > The build went fine but when I ran the following test, the fingerprint
>> > error showed up:
>> >
>> > *OPENSSL_FIPS=1 openssl md5*
>> >
>>
>> I suggest you first try building the FIPS capable OpenSSL in the standard
>> way
>> i.e.
>>
>> ./config fips
>> make
>>
>> and see if you get the same problem.
>>
>> Steve.
>> --
>> Dr Stephen N. Henson. OpenSSL project core developer.
>> Commercial tech support now available see: http://www.openssl.org
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
>
> --
> Thanks,
> Rich
>
>


-- 
Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160224/212069d6/attachment.html>

From steve at openssl.org  Thu Feb 25 02:36:40 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 25 Feb 2016 02:36:40 +0000
Subject: [openssl-users] Helps needed regarding the error "fingerprint
 does not match:fips.c:232:"
In-Reply-To: <CAEsYawxrC0S57cagtD_PzuC2xUpyGc+ihv-eTLkqCH_M3p=kQw@mail.gmail.com>
References: <CAEsYawxW28Oah1v31eYMT6ckrcO0w1=fx0SUa+Gz_j8nkF6L6w@mail.gmail.com>
 <20160224010134.GA26349@openssl.org>
 <CAEsYawyQSyjPKYVEJoNYWyxm1qg3fb-RzQJ-WprYSxycEjTV-w@mail.gmail.com>
 <CAEsYawxrC0S57cagtD_PzuC2xUpyGc+ihv-eTLkqCH_M3p=kQw@mail.gmail.com>
Message-ID: <20160225023640.GA22529@openssl.org>

On Wed, Feb 24, 2016, cloud force wrote:

> Actually it looks like when I ran the tests using the OpenSSL FIPS library
> which I built using Ubuntu build script, the content of FIPS_SIGNATURE
> seemed to be empty.
> 
> Can anyone tell me how was the value of sig and FIPS_SIGNATURE (near fips.c
> line 222) was computed and assigned?
> 

They are set using the fipsld linker script. If you have changed the build
process so fipsld is no longer called that will cause the signature test to
fail.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From vikas.tm at gmail.com  Thu Feb 25 07:32:55 2016
From: vikas.tm at gmail.com (Vikas TM)
Date: Thu, 25 Feb 2016 13:02:55 +0530
Subject: [openssl-users] glibc detected *** xxx: double free or corruption
	(!prev): 0x097b8750
In-Reply-To: <8ACFF8299C8F504F87EDE3DAA1FCA84D14F49592@chn-hclt-mbs06.HCLT.CORP.HCL.IN>
References: <8ACFF8299C8F504F87EDE3DAA1FCA84D14F49592@chn-hclt-mbs06.HCLT.CORP.HCL.IN>
Message-ID: <CA+5R-ah1WbS-AL1HX5EieuMRodwgvEMfSkv=vNwrD7k+2cNnSQ@mail.gmail.com>

Hi,

While running my application with openSSL 102d and I encountered double
free error or corruption.

As per few threads suggestion, I have changed getpid() with pthread_self()
in CRYPTO_thread_id(). Still the result is same.

Please let me know if any fix available to this issue.

*** glibc detected *** xxx: double free or corruption (!prev): 0x097b8750
***

======= Backtrace: =========

/lib/libc.so.6[0x1768b6]

/lib/libc.so.6(cfree+0x90)[0x179e00]

xxx(CRYPTO_free+0x3a)[0x81b89be]

xxx(ssl_cert_free+0x13f)[0x826fa23]

xxx(SSL_free+0x14d)[0x81d7e08]

Thanks & Regards,
Vikas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160225/359b4dab/attachment.html>

From akihana at gmail.com  Thu Feb 25 08:50:01 2016
From: akihana at gmail.com (Mike Mohr)
Date: Thu, 25 Feb 2016 00:50:01 -0800
Subject: [openssl-users] glibc detected *** xxx: double free or
 corruption (!prev): 0x097b8750
In-Reply-To: <CA+5R-ah1WbS-AL1HX5EieuMRodwgvEMfSkv=vNwrD7k+2cNnSQ@mail.gmail.com>
References: <8ACFF8299C8F504F87EDE3DAA1FCA84D14F49592@chn-hclt-mbs06.HCLT.CORP.HCL.IN>
 <CA+5R-ah1WbS-AL1HX5EieuMRodwgvEMfSkv=vNwrD7k+2cNnSQ@mail.gmail.com>
Message-ID: <CAJe-LUiV792wMv7fNGsgi7f3TBQ_iBtM3QOdAqq-++6j+KbdXQ@mail.gmail.com>

You'll need to rebuild your application and openssl with debugging symbols
and no optimization, then run it inside gdb to produce a more useful stack
trace. Since you don't include any context or source code snippets it isn't
really possible to help. Can you produce a reduced test case with source
code which reproduces the bug?

As long as politics is the shadow cast on society by big business, the
attenuation of the shadow will not change the substance.

John Dewey: The Later Works, 1925-1953; Volume 6, pp. 163
On Feb 24, 2016 11:33 PM, "Vikas TM" <vikas.tm at gmail.com> wrote:

> Hi,
>
> While running my application with openSSL 102d and I encountered double
> free error or corruption.
>
> As per few threads suggestion, I have changed getpid() with pthread_self()
> in CRYPTO_thread_id(). Still the result is same.
>
> Please let me know if any fix available to this issue.
>
> *** glibc detected *** xxx: double free or corruption (!prev): 0x097b8750
> ***
>
> ======= Backtrace: =========
>
> /lib/libc.so.6[0x1768b6]
>
> /lib/libc.so.6(cfree+0x90)[0x179e00]
>
> xxx(CRYPTO_free+0x3a)[0x81b89be]
>
> xxx(ssl_cert_free+0x13f)[0x826fa23]
>
> xxx(SSL_free+0x14d)[0x81d7e08]
>
> Thanks & Regards,
> Vikas
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160225/d63485b8/attachment.html>

From mark at openssl.org  Thu Feb 25 09:29:25 2016
From: mark at openssl.org (Mark J Cox)
Date: Thu, 25 Feb 2016 09:29:25 +0000
Subject: [openssl-users] Forthcoming OpenSSL releases
Message-ID: <CABU6YObG1SL8StWncaMDN3Pyoio9cUOVuqT-13iYupMK645ouw@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Forthcoming OpenSSL releases
============================

The OpenSSL project team would like to announce the forthcoming release of
OpenSSL versions 1.0.2g, 1.0.1s.

These releases will be made available on 1st March 2016 between approximately
1300-1700 UTC.  They will fix several security defects with maximum severity
"high".

Please see the following page for further details of severity levels:
https://www.openssl.org/policies/secpolicy.html

Please also note that, as per our previous announcements, support for 1.0.1
will end on 31st December 2016.

Yours

The OpenSSL Project Team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJWzsjbAAoJEAEKUEB8TIy9ukoH/A+KQh0TPuC5CulMeFd4OiGy
7HV9bX/nCe4sKmW5IGYt6GDPFRnhup9WR9Dvz0C/sBjwttsnF+UZOUUfYbDw2liO
YG46kiS95zbeU4yYFQwHr9Sf01o89ogEGrxCIlKQiA4aXSZwn9liI0a51y7izWUC
xdj2GEgQ/fnVnlN/AyToVmoQxlrphXJx9FigLxTuXi1X6nvSNdEYB1VtOuqjanRu
8sR4UDCWYRZNT0L3as0IEU49X7ncwm5a85NR02SkVimevdbJw0mBT1ru4Zjddo88
oO5xpgSKy2a56xC8yQXURkVPvuFqUpfvyojLwOULUnWHCpnDhzn+ygdko2Pii3o=
=XURc
-----END PGP SIGNATURE-----

From steve at openssl.org  Thu Feb 25 12:16:40 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 25 Feb 2016 12:16:40 +0000
Subject: [openssl-users] Is the structure of this CMS object correct?
In-Reply-To: <20160223172637.GA15299@openssl.org>
References: <56B9AE22.6000501@pdflib.com>
 <AF40454C-E74A-4359-B53C-E694AE1FC590@docusign.com>
 <56B9CD84.7020207@pdflib.com>
 <74002D90-1437-45F0-96F3-401B27B8569A@docusign.com>
 <56CC1927.7050701@pdflib.com> <20160223172637.GA15299@openssl.org>
Message-ID: <20160225121640.GA27267@openssl.org>

On Tue, Feb 23, 2016, Dr. Stephen Henson wrote:

> On Tue, Feb 23, 2016, Stephan M?hlstrasser wrote:
> 
> > I tried again to map the structure of the CMS object to the
> > definitions in RFC 5652 (comments added with a '%'):
> > 
> > 1: SEQUENCE {
> > 2:   OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
> >                                                    % ContentType
> > 3:   [0] {  % eContent
> > 4:     SEQUENCE {
> > 5:       INTEGER 0 % CMSVersion
> >           % no OriginatorInfo
> > 6:       SET { % RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
> > 7:         SEQUENCE {
> >        % SEQUENCE tag should not be present because of implicit tagging?
> 
> Yes, because it is using the key agreement choice type it should be
> tagged [1] IMPLICIT but it is not which is why OpenSSL thinks it is key
> transport.
> 
> > 8:           INTEGER 3
> >          % version 3 only applicable to KeyAgreeRecipientInfo
> > 9:           [0] {
> 
> Assume this is KeyAgreeRecipientInfo.. the above tag would indicate the
> "originator" field.
> 
> > 10:             SEQUENCE {
> 
> Here it is wrong again. The untagged form is "IssuerAndSerialNumber" which
> the fields below certainly aren't. It looks like originatorKey which should be
> tagged [1] IMPLICIT.
> 
> > 11:               SEQUENCE {
> > 12:                 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
> > 13:                 OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
> > 14:                 }
> > 
> 
> So yes it's pretty broken.
> 

Just as a quick followup. If you change the two tags I mentioned above the
result does then parse. However I've no idea if it will actually decrypt: the
key derivation might be broken too.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From mail at jens-maus.de  Thu Feb 25 16:42:50 2016
From: mail at jens-maus.de (Jens Maus)
Date: Thu, 25 Feb 2016 17:42:50 +0100
Subject: [openssl-users] "digest check failure" with AmigaOS3/m68k port of
	OpenSSL 1.0.x
Message-ID: <80027BA9-155E-4191-9D8C-97B4EF03C7CA@jens-maus.de>

Hello,

I am the current maintainer of a still active port of OpenSSL to the AmigaOS platform which tries to wrap the OpenSSL library API into a full fledged Amiga shared library for applications requiring cryptographic functionality (see https://github.com/jens-maus/amissl). So yes, the Amiga platform is still alive ;)

While for some Amiga platforms (e.g. AmigaOS4/PPC) the current OpenSSL 1.0.2f kernel of this library seems to behave fine and all our tests are not reporting any problem we are still facing some trouble with one of the older Amiga platforms (AmigaOS3) which utilizes Motorola m68k processors. While all of the openssl test binaries are not outputting any error, we are facing some trouble in receiving ?digest check failed? messages, e.g. when executing the following ?openssl? test command:

openssl s_client -connect pop.gmail.com:995 -tls1_2 -cipher ECDHE-RSA-AES128-GCM-SHA256

The problem vanishes, however, immediately when using a SHA384 using cipher:

openssl s_client -connect pop.gmail.com:995 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384

The error output we are receiving when using SHA256 digest ciphers is:

error:1408C095:SSL routines:ssl3_get_finished:digest check failed

Please note, however, that the ?sha256t? openssl test programs doesn?t output any error nor does a ?openssl dgst -sha256? command produce any broken SHA256 digest outputs.

After having tracked down the problem in the OpenSSL source code we have traced down the problem to the following CRYPTO_memcmp() failing for some unknown reason:

https://github.com/openssl/openssl/blob/OpenSSL_1_0_2f/ssl/s3_both.c#L271

So in this case either s->init_msg or s->s3->tmp.peer_finish_md seems to be incorrectly calculated. Commenting out the whole CRYPTO_memcmp() check results, however, in a succeeding TLS connection where s_client can then properly communicate with the server in question.

Our current difficulty in trying to debug if either init_msg or peer_finish_md is incorrectly calculated is, that the corresponding code passages are of course using random values and thus each connection produces differences we can hardly compare to each other.

I would like to therefore ask if there is any possibility or defined way of debugging/analyzing TLS connection handshakes with the exact same handshake procedure so that successive uses of ?openssl s_client? will always produce the same output? Or how do I have to manually calculate the SHA256 digest based on the TLS handshake data I am receiving via ?openssl s_client -msg? output? In addition, I would like to ask if anyone has another idea how I could debug why the SHA256 digest seems to be incorrectly calculated when performing a TLS1.2 connection?!?

If anyone is interested, here is the corresponding github ticket which we are maintaining to track down the problem:
https://github.com/jens-maus/amissl/issues/2

Any help of course very appreciated!

Best Regards,
Jens
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/

*** Content is authentic only with digital signature  ***

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2605 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160225/5d7ad225/attachment.bin>

From cloud.force858 at gmail.com  Thu Feb 25 19:03:42 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Thu, 25 Feb 2016 11:03:42 -0800
Subject: [openssl-users] Helps needed regarding the error "fingerprint
 does not match:fips.c:232:"
In-Reply-To: <20160225023640.GA22529@openssl.org>
References: <CAEsYawxW28Oah1v31eYMT6ckrcO0w1=fx0SUa+Gz_j8nkF6L6w@mail.gmail.com>
 <20160224010134.GA26349@openssl.org>
 <CAEsYawyQSyjPKYVEJoNYWyxm1qg3fb-RzQJ-WprYSxycEjTV-w@mail.gmail.com>
 <CAEsYawxrC0S57cagtD_PzuC2xUpyGc+ihv-eTLkqCH_M3p=kQw@mail.gmail.com>
 <20160225023640.GA22529@openssl.org>
Message-ID: <CAEsYawxb_Xrmm7cc5y7s5a-to8HSiQyjnu9s6kXee9aEjW2Jdg@mail.gmail.com>

Thanks for the information.

I checked the Makefile and build logs of both cases (i.e. built with Ubuntu
packaging script and built with the standard way), and I saw the fipsld was
run in both cases:

Makefile for both:














*libcrypto$(SHLIB_EXT): libcrypto.a fips_premain_dso$(EXE_EXT)    @if [
"$(SHLIB_TARGET)" != "" ]; then \        if [ "$(FIPSCANLIB)" = "libcrypto"
]; then \            FIPSLD_LIBCRYPTO=libcrypto.a ; \
FIPSLD_CC="$(CC)"; CC=$(FIPSDIR)/bin/fipsld; \            export CC
FIPSLD_CC FIPSLD_LIBCRYPTO; \        fi; \        $(MAKE) -e
SHLIBDIRS=crypto  CC="$${CC:-$(CC)}" build-shared && \        (touch -c
fips_premain_dso$(EXE_EXT) || :); \        echo "CC is $(CC)"; \    else
\        echo "There's no support for shared libraries on this platform"
>&2; \        exit 1; \    fi*


Although it seemed like the FIPSLD_CC wasn't set in both cases, but I did
see that the fipsld eventually got executed in both cases.


I saw the following in both the build logs:









*if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \        (cd ..; make
libcrypto.so.1.0.0); \    fimake[3]: Entering directory
`/home/Development/precise/amd64/openssl/openssl-1.0.1'[ -z "libcrypto" ]
|| gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN  -O3   -Wformat
-Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2
-Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT  -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM
-DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
-Iinclude \        -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso
\        /usr/local/ssl/fips-2.0/lib/fips_premain.c
/usr/local/ssl/fips-2.0/lib/fipscanister.o \        libcrypto.a -ldl -lz*

Also if I removed the fipsld binary from the /usr/local/ssl/fips-2.0/bin/
directory, I saw the fipsld "File not found" errors in both cases, which
also proved that the fipsld was ran.

One major differences I could see was, in Ubuntu Makefile it uses *-Wl,
--version-script=openssl.ld* in the *SHARED_LDFLAGS* and all the symbols
were included in the openssl.ld file. I also added all the FIPS related
symbols to this file as well, otherwise they all showed up as "t" instead
of "T" when running nm on the libcrypto.so


How does fipsld set the sig and FIPS_SIGNATURE and what's the right way to
call it in the build script? e.g. How do I use it to set these signature in
the command line?
In addition to the fipsld command, is there any other possible reasons
which would cause the signature not set correctly?

Thanks and I truly appreciate the helps and suggestions.



On Wed, Feb 24, 2016 at 6:36 PM, Dr. Stephen Henson <steve at openssl.org>
wrote:

> On Wed, Feb 24, 2016, cloud force wrote:
>
> > Actually it looks like when I ran the tests using the OpenSSL FIPS
> library
> > which I built using Ubuntu build script, the content of FIPS_SIGNATURE
> > seemed to be empty.
> >
> > Can anyone tell me how was the value of sig and FIPS_SIGNATURE (near
> fips.c
> > line 222) was computed and assigned?
> >
>
> They are set using the fipsld linker script. If you have changed the build
> process so fipsld is no longer called that will cause the signature test to
> fail.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160225/6aa40fa8/attachment-0001.html>

From nounou.dadoun at avigilon.com  Thu Feb 25 22:42:05 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Thu, 25 Feb 2016 22:42:05 +0000
Subject: [openssl-users] Failed TLSv1.2 handshake with error 67702888--bad
	signature
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E155CC@mbx027-w1-ca-4.exch027.domain.local>

  I'm trying to troubleshoot some development code which is enabling TLSv1.1 and 1.2 and failing. Have an odd tls handshake failure, with an error number that I can find any documentation about (is there any?) that indicates "67702888--bad signature" which is being logged on the server side; and I'm trying to see where in the handshake things are falling apart.

Looks like it's negotiating tls1.2 and agreeing on TLS_RSA_WITH_AES_256_CBC_SHA256 but the client seems to be sending a certificate although I don't see it requesting mutual authentication.

I've attached a very short wireshark capture - does anyone know what that error code might be related to or can give me a hint as to what's going awry here?  Thanks ... N


Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 
Support: 888.281.5182 ?|? avigilon.com
Follow?Twitter ?|? Follow?LinkedIn


This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: jkcapture.pcapng
Type: application/octet-stream
Size: 13520 bytes
Desc: jkcapture.pcapng
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160225/ac911309/attachment.obj>

From BYan at visa.com  Thu Feb 25 23:10:25 2016
From: BYan at visa.com (Yan, Bob)
Date: Thu, 25 Feb 2016 23:10:25 +0000
Subject: [openssl-users] How to retrieve the revoked certificate list when
 X509_LOOKUP_hash_dir() method used
Message-ID: <c1cf2882f4084b5ba69805a150c57277@SW550EXP003.visa.com>

H All,

I used the following methods to load CRL hashed-directory into a SSL_CTX object to verify the client certificate against the CRL. The code works fine and it's able to verify the client certificate against the loaded CRLs.  

           X509_STORE *x509Store = SSL_CTX_get_cert_store(sslCtx);
           X509_LOOKUP *lookup = X509_STORE_add_lookup(x509Store, X509_LOOKUP_hash_dir());
           X509_LOOKUP_add_dir(lookup, crlDirectory, X509_FILETYPE_PEM);
                
My question is that, is there any method to retrieve the CRL list or print all revoked certificate list?

Thanks
Bob


From cloud.force858 at gmail.com  Thu Feb 25 23:27:51 2016
From: cloud.force858 at gmail.com (cloud force)
Date: Thu, 25 Feb 2016 15:27:51 -0800
Subject: [openssl-users] Helps needed regarding the error "fingerprint
 does not match:fips.c:232:"
In-Reply-To: <CAEsYawxb_Xrmm7cc5y7s5a-to8HSiQyjnu9s6kXee9aEjW2Jdg@mail.gmail.com>
References: <CAEsYawxW28Oah1v31eYMT6ckrcO0w1=fx0SUa+Gz_j8nkF6L6w@mail.gmail.com>
 <20160224010134.GA26349@openssl.org>
 <CAEsYawyQSyjPKYVEJoNYWyxm1qg3fb-RzQJ-WprYSxycEjTV-w@mail.gmail.com>
 <CAEsYawxrC0S57cagtD_PzuC2xUpyGc+ihv-eTLkqCH_M3p=kQw@mail.gmail.com>
 <20160225023640.GA22529@openssl.org>
 <CAEsYawxb_Xrmm7cc5y7s5a-to8HSiQyjnu9s6kXee9aEjW2Jdg@mail.gmail.com>
Message-ID: <CAEsYawy1tm+sNUjFbN-jQAtkhDHTMCH+weVEo3ZEQPu3KfWJ5g@mail.gmail.com>

By running the command fips_premain.dso, I found that my lib crypto.so
library file does not have the following two symbols:

FINGERPRINT_ascii_value
FINGERPRINT_remain

Could the missing of these two symbols caused the problems of fingerprint
mismatch which I ran into (during the run time)?

Where do these two symbols come from and what could cause them not being
added to the libcrypto.so?


Thanks for any suggestions and helps.


On Thu, Feb 25, 2016 at 11:03 AM, cloud force <cloud.force858 at gmail.com>
wrote:

> Thanks for the information.
>
> I checked the Makefile and build logs of both cases (i.e. built with
> Ubuntu packaging script and built with the standard way), and I saw the
> fipsld was run in both cases:
>
> Makefile for both:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *libcrypto$(SHLIB_EXT): libcrypto.a fips_premain_dso$(EXE_EXT)    @if [
> "$(SHLIB_TARGET)" != "" ]; then \        if [ "$(FIPSCANLIB)" = "libcrypto"
> ]; then \            FIPSLD_LIBCRYPTO=libcrypto.a ; \
> FIPSLD_CC="$(CC)"; CC=$(FIPSDIR)/bin/fipsld; \            export CC
> FIPSLD_CC FIPSLD_LIBCRYPTO; \        fi; \        $(MAKE) -e
> SHLIBDIRS=crypto  CC="$${CC:-$(CC)}" build-shared && \        (touch -c
> fips_premain_dso$(EXE_EXT) || :); \        echo "CC is $(CC)"; \    else
> \        echo "There's no support for shared libraries on this platform"
> >&2; \        exit 1; \    fi*
>
>
> Although it seemed like the FIPSLD_CC wasn't set in both cases, but I did
> see that the fipsld eventually got executed in both cases.
>
>
> I saw the following in both the build logs:
>
>
>
>
>
>
>
>
>
> *if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \        (cd ..;
> make libcrypto.so.1.0.0); \    fimake[3]: Entering directory
> `/home/Development/precise/amd64/openssl/openssl-1.0.1'[ -z "libcrypto" ]
> || gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT
> -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN  -O3   -Wformat
> -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2
> -Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT  -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM
> -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
> -Iinclude \        -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso
> \        /usr/local/ssl/fips-2.0/lib/fips_premain.c
> /usr/local/ssl/fips-2.0/lib/fipscanister.o \        libcrypto.a -ldl -lz*
>
> Also if I removed the fipsld binary from the /usr/local/ssl/fips-2.0/bin/
> directory, I saw the fipsld "File not found" errors in both cases, which
> also proved that the fipsld was ran.
>
> One major differences I could see was, in Ubuntu Makefile it uses *-Wl,
> --version-script=openssl.ld* in the *SHARED_LDFLAGS* and all the symbols
> were included in the openssl.ld file. I also added all the FIPS related
> symbols to this file as well, otherwise they all showed up as "t" instead
> of "T" when running nm on the libcrypto.so
>
>
> How does fipsld set the sig and FIPS_SIGNATURE and what's the right way to
> call it in the build script? e.g. How do I use it to set these signature in
> the command line?
> In addition to the fipsld command, is there any other possible reasons
> which would cause the signature not set correctly?
>
> Thanks and I truly appreciate the helps and suggestions.
>
>
>
> On Wed, Feb 24, 2016 at 6:36 PM, Dr. Stephen Henson <steve at openssl.org>
> wrote:
>
>> On Wed, Feb 24, 2016, cloud force wrote:
>>
>> > Actually it looks like when I ran the tests using the OpenSSL FIPS
>> library
>> > which I built using Ubuntu build script, the content of FIPS_SIGNATURE
>> > seemed to be empty.
>> >
>> > Can anyone tell me how was the value of sig and FIPS_SIGNATURE (near
>> fips.c
>> > line 222) was computed and assigned?
>> >
>>
>> They are set using the fipsld linker script. If you have changed the build
>> process so fipsld is no longer called that will cause the signature test
>> to
>> fail.
>>
>> Steve.
>> --
>> Dr Stephen N. Henson. OpenSSL project core developer.
>> Commercial tech support now available see: http://www.openssl.org
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
>
> --
> Thanks,
> Rich
>
>


-- 
Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160225/ccd809fe/attachment-0001.html>

From jb-openssl at wisemo.com  Fri Feb 26 01:43:41 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 26 Feb 2016 02:43:41 +0100
Subject: [openssl-users] Is anyone else getting spammed by
 databreachtoday.com, or is it just me?
Message-ID: <56CFADCD.8050307@wisemo.com>

Over the last many months, I have received a constant flow of
"newsletters" from databreachtoday.com to my OpenSSL posting
address.

I am wondering if this is specific to me, or if they are
sending to most other subscribers too.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 	


From nounou.dadoun at avigilon.com  Fri Feb 26 01:44:02 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Fri, 26 Feb 2016 01:44:02 +0000
Subject: [openssl-users] Failed TLSv1.2 handshake with error
 67702888--bad	signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E155CC@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E155CC@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E15717@mbx027-w1-ca-4.exch027.domain.local>

Curiouser and curiouser - I have attached two minimal packet captures in which the only difference in the server build was a change in one line (using boost with openssl):
               : m_context(pIoService->GetNative(), boost::asio::ssl::context::tlsv1)
to
               : m_context(pIoService->GetNative(), boost::asio::ssl::context::sslv23)

They both disable sslv2 and sslv3.
The former resulted in a handshake that completed, the latter failed with the aforementioned "67702888--bad signature" logged error.  The respective packet captures are attached.

This one has me pretty puzzled, any idea why tls1 succeeds and tls1.2 fails?

Is tls1.2 more strict about accepting the client certificate since it's complaining about a "bad signature" where tlsv1 doesn't?

Anybody have any ideas? ... N

Nou Dadoun
Senior Firmware Developer, Security Specialist


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun
Sent: Thursday, February 25, 2016 2:42 PM
To: openssl-users at openssl.org
Subject: [openssl-users] Failed TLSv1.2 handshake with error 67702888--bad signature

  I'm trying to troubleshoot some development code which is enabling TLSv1.1 and 1.2 and failing. Have an odd tls handshake failure, with an error number that I can find any documentation about (is there any?) that indicates "67702888--bad signature" which is being logged on the server side; and I'm trying to see where in the handshake things are falling apart.

Looks like it's negotiating tls1.2 and agreeing on TLS_RSA_WITH_AES_256_CBC_SHA256 but the client seems to be sending a certificate although I don't see it requesting mutual authentication.

I've attached a very short wireshark capture - does anyone know what that error code might be related to or can give me a hint as to what's going awry here?  Thanks ... N


Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 
Support: 888.281.5182 ?|? avigilon.com
Follow?Twitter ?|? Follow?LinkedIn


This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlsv1_successful_handshake.pcapng
Type: application/octet-stream
Size: 12728 bytes
Desc: tlsv1_successful_handshake.pcapng
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160226/b8bd0e46/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlsv1.2_failed_handshake.pcapng
Type: application/octet-stream
Size: 7932 bytes
Desc: tlsv1.2_failed_handshake.pcapng
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160226/b8bd0e46/attachment-0003.obj>

From erik at efca.com  Fri Feb 26 02:15:10 2016
From: erik at efca.com (Erik Forsberg)
Date: Thu, 25 Feb 2016 18:15:10 -0800
Subject: [openssl-users] Is anyone else getting spammed by
 databreachtoday.com, or is it just me?
In-Reply-To: <56CFADCD.8050307@wisemo.com>
References: <56CFADCD.8050307@wisemo.com>
Message-ID: <cw3AIc1kBLOSifr@srv.efca.com>

Havent seen any.

>-- Original Message --
>
>Over the last many months, I have received a constant flow of
>"newsletters" from databreachtoday.com to my OpenSSL posting
>address.
>
>I am wondering if this is specific to me, or if they are
>sending to most other subscribers too.
>
>Enjoy
>
>Jakob
>-- 
>Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
>Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
>This public discussion message is non-binding and may contain errors.
>WiseMo - Remote Service Management for PCs, Phones and Embedded 	
>
>-- 
>openssl-users mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



From shubham13099 at iiitd.ac.in  Fri Feb 26 06:34:03 2016
From: shubham13099 at iiitd.ac.in (Shubham Chauhan)
Date: Fri, 26 Feb 2016 12:04:03 +0530
Subject: [openssl-users] Maintaining a file for session cache - server side
Message-ID: <CAP=zTkMRKWPg3YVpX=a0Ru0iFhN+R40T+1HEU-v01vftcLe9AQ@mail.gmail.com>

Hey,

I wanted to store sessions to a file (on the server side), every time a
session is negotiated, and then eventually read that file for the presence
of a particular session. If the session is present, I would like to do an
abbreviated handshake, i.e. session resumption.

So, basically maintaining a server side external cache.
Any ideas on how to go about it?
A small code snippet would be really useful,

Thanks
--
Regards
Shubham Chauhan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160226/e544a736/attachment.html>

From matt at openssl.org  Fri Feb 26 08:56:58 2016
From: matt at openssl.org (Matt Caswell)
Date: Fri, 26 Feb 2016 08:56:58 +0000
Subject: [openssl-users] Is anyone else getting spammed by
 databreachtoday.com, or is it just me?
In-Reply-To: <56CFADCD.8050307@wisemo.com>
References: <56CFADCD.8050307@wisemo.com>
Message-ID: <56D0135A.10208@openssl.org>



On 26/02/16 01:43, Jakob Bohm wrote:
> Over the last many months, I have received a constant flow of
> "newsletters" from databreachtoday.com to my OpenSSL posting
> address.
> 
> I am wondering if this is specific to me, or if they are
> sending to most other subscribers too.

I'm not getting it.

Matt


From janjust at nikhef.nl  Fri Feb 26 10:17:18 2016
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Fri, 26 Feb 2016 11:17:18 +0100
Subject: [openssl-users] How to retrieve the revoked certificate list
 when X509_LOOKUP_hash_dir() method used
In-Reply-To: <c1cf2882f4084b5ba69805a150c57277@SW550EXP003.visa.com>
References: <c1cf2882f4084b5ba69805a150c57277@SW550EXP003.visa.com>
Message-ID: <56D0262E.3050500@nikhef.nl>

Hi Bob,

Yan, Bob wrote:
> H All,
>
> I used the following methods to load CRL hashed-directory into a SSL_CTX object to verify the client certificate against the CRL. The code works fine and it's able to verify the client certificate against the loaded CRLs.  
>
>            X509_STORE *x509Store = SSL_CTX_get_cert_store(sslCtx);
>            X509_LOOKUP *lookup = X509_STORE_add_lookup(x509Store, X509_LOOKUP_hash_dir());
>            X509_LOOKUP_add_dir(lookup, crlDirectory, X509_FILETYPE_PEM);
>                 
> My question is that, is there any method to retrieve the CRL list or print all revoked certificate list?
>   

did you try the X509_CRL_print function?

(this is what "openssl crl -text" uses)

JJK

From shubham13099 at iiitd.ac.in  Fri Feb 26 11:50:32 2016
From: shubham13099 at iiitd.ac.in (Shubham Chauhan)
Date: Fri, 26 Feb 2016 17:20:32 +0530
Subject: [openssl-users] PEM_read and write SSL_SESSION
Message-ID: <CAP=zTkNeds-vxsuidO0NgTL4-QpNRqTqEB9-MGrhbQ0PXKo=tw@mail.gmail.com>

If anyone is familiar with the PEM_read_SSL_SESSION and
PEM_write_SSL_SESSION functions, please let me know about the arguments and
the usage of these functions, in a bit detailed fashion.
It'll be really helpful.
Thanks

-- 
Regards
Shubham Chauhan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160226/ad7dee0f/attachment.html>

From marquess at openssl.com  Fri Feb 26 14:32:02 2016
From: marquess at openssl.com (Steve Marquess)
Date: Fri, 26 Feb 2016 09:32:02 -0500
Subject: [openssl-users] FIPS 140-2 red letter puzzle resolved
Message-ID: <56D061E2.80309@openssl.com>

As always, if you don't know or care what FIPS 140-2 is then rejoice at
your good fortune and move on.

The "red letter" message for the #1747 validation listing noted in my
E-mail last Monday was confirmed as an error by the CMVP and has now
been removed from the web site entry:

  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747

So once again all three of the OpenSSL FIPS Object Module v2.0
validations are shown as successfully surviving the "RNG transition".

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From sugu.ece28 at gmail.com  Fri Feb 26 16:29:44 2016
From: sugu.ece28 at gmail.com (Sugumar)
Date: Fri, 26 Feb 2016 09:29:44 -0700 (MST)
Subject: [openssl-users] Need information on AES encryption and decryption
	Key and IV type
Message-ID: <1456504184469-64055.post@n7.nabble.com>

Hi,,

I am using Openssl for encryption and decryption.
I need some information on AES encryption and decryption key and iv type.
My doubt is when we are using a openssl in command line we need to pass key
and iv as hex strings right?
and same when we are EVP calls in C/C++ programming what is the type of Key
and Iv. i mean it should a hex string or raw binary values?

I saw, openssl command line interface code of openssl in that the hex
strings are converted into hex values.
But in EVP calls the Key and Iv are used directly.





--
View this message in context: http://openssl.6102.n7.nabble.com/Need-information-on-AES-encryption-and-decryption-Key-and-IV-type-tp64055.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From c.holper at ades.at  Fri Feb 26 18:33:36 2016
From: c.holper at ades.at (c.holper at ades.at)
Date: Fri, 26 Feb 2016 19:33:36 +0100
Subject: [openssl-users]  SMIME: 1.0.0e vs. 1.0.1e
Message-ID: <56D09A80.5060106@ades.at>

Hi!

I'd like to finish the thread I started.

- My first statement was wrong. Also 1.0.0e is not able to process my 
SMIME-sample.
The reason was that I had a smime-binary-patch installed at the 1.0.0e 
some years ago and I did not remember about it.
Without the patch installed in the 1.0.1e it looks like a change in 
functionality between the version.

- Many thanks to Dr. Stephen Henson for his help and support.
This solution (parse it externally and verify it with openssl-cms) works 
fine.

Best regards,
Chris

From nounou.dadoun at avigilon.com  Fri Feb 26 20:29:30 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Fri, 26 Feb 2016 20:29:30 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>

I've extracted the certificates from the exchange to verify that the (tlsv1) successful handshake and the (tlsv1.2) failed handshake certificates are identical (they are) and I've also checked to make sure that the CA certificate that the server has for signature verification is the same as the CA certificate handed over by the client in the exchange (it is).

I've also used the command line openssl verify to verify the certificate against the CA: 
"client_cert_success.pem: OK"

However it succeeds in TLSv1 and fails in TLSv1.2 (the one line change noted below).

I've now attached the certificates for quick reference - can anyone see what might be causing the different behavior between TLSv1 and TLSv1.2?

Quite puzzling!

Nou Dadoun
Senior Firmware Developer, Security Specialist

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Nounou Dadoun
Sent: Friday, February 26, 2016 9:34 AM
To: openssl-dev at openssl.org
Subject: [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

Trying to upgrade from TLSv1 to TLSv1.1 and 1.2 has been more problematic than I might have suspected.
I have a TLS server using openssl 1.0.2d  doing mutual authentication and a one line change from TLSv1 (only) to TLSv1.2 breaks the connection where in the latter the server rejects the client certificate with "error 67702888--bad signature" (and the former happily accepts it).  

Given that description (and the fact that it's literally a one-line change), it's hard to believe that I'm doing something wrong.

Can anyone tell me why TLSv1 accepts it and TLSv1.2 doesn't?  Packet capture attached and more details below, certificate is in the packet capture but I can provide it separately if it will help, thanks ... N

Nou Dadoun
Senior Firmware Developer, Security Specialist


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun
Sent: Thursday, February 25, 2016 5:44 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Failed TLSv1.2 handshake with error 67702888--bad signature

Curiouser and curiouser - I have attached two minimal packet captures in which the only difference in the server build was a change in one line (using boost with openssl):
               : m_context(pIoService->GetNative(), boost::asio::ssl::context::tlsv1) to
               : m_context(pIoService->GetNative(), boost::asio::ssl::context::sslv23)

They both disable sslv2 and sslv3.
The former resulted in a handshake that completed, the latter failed with the aforementioned "67702888--bad signature" logged error.  The respective packet captures are attached.

This one has me pretty puzzled, any idea why tls1 succeeds and tls1.2 fails?

Is tls1.2 more strict about accepting the client certificate since it's complaining about a "bad signature" where tlsv1 doesn't?

Anybody have any ideas? ... N

Nou Dadoun
Senior Firmware Developer, Security Specialist


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun
Sent: Thursday, February 25, 2016 2:42 PM
To: openssl-users at openssl.org
Subject: [openssl-users] Failed TLSv1.2 handshake with error 67702888--bad signature

  I'm trying to troubleshoot some development code which is enabling TLSv1.1 and 1.2 and failing. Have an odd tls handshake failure, with an error number that I can find any documentation about (is there any?) that indicates "67702888--bad signature" which is being logged on the server side; and I'm trying to see where in the handshake things are falling apart.

Looks like it's negotiating tls1.2 and agreeing on TLS_RSA_WITH_AES_256_CBC_SHA256 but the client seems to be sending a certificate although I don't see it requesting mutual authentication.

I've attached a very short wireshark capture - does anyone know what that error code might be related to or can give me a hint as to what's going awry here?  Thanks ... N


Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632
Support: 888.281.5182 ?|? avigilon.com
Follow?Twitter ?|? Follow?LinkedIn


This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: client_cert_success.pem
Type: application/octet-stream
Size: 1310 bytes
Desc: client_cert_success.pem
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160226/ef962b4b/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client_cert_CA_success.pem
Type: application/octet-stream
Size: 1692 bytes
Desc: client_cert_CA_success.pem
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160226/ef962b4b/attachment-0003.obj>

From steve at openssl.org  Fri Feb 26 23:06:07 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 26 Feb 2016 23:06:07 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <20160226230607.GA21238@openssl.org>

On Fri, Feb 26, 2016, Nounou Dadoun wrote:

> I've extracted the certificates from the exchange to verify that the (tlsv1) successful handshake and the (tlsv1.2) failed handshake certificates are identical (they are) and I've also checked to make sure that the CA certificate that the server has for signature verification is the same as the CA certificate handed over by the client in the exchange (it is).
> 
> I've also used the command line openssl verify to verify the certificate against the CA: 
> "client_cert_success.pem: OK"
> 
> However it succeeds in TLSv1 and fails in TLSv1.2 (the one line change noted below).
> 
> I've now attached the certificates for quick reference - can anyone see what might be causing the different behavior between TLSv1 and TLSv1.2?
> 

The signature TLS uses for Client auth is different in TLS 1.2. For TLS < 1.2
the TLS signature is a combined MD5+SHA1 form for RSA. For TLS 1.2 it is the
more standard DigestInfo signature which can use other algorithms such as
SHA512 or SHA256.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From michel.sales at free.fr  Fri Feb 26 23:07:36 2016
From: michel.sales at free.fr (Michel)
Date: Sat, 27 Feb 2016 00:07:36 +0100
Subject: [openssl-users] Need information on AES encryption and
	decryption	Key and IV type
In-Reply-To: <1456504184469-64055.post@n7.nabble.com>
References: <1456504184469-64055.post@n7.nabble.com>
Message-ID: <005d01d170ea$7bafec00$730fc400$@sales@free.fr>

As Rich already answered : "The IV, key, and ciphertext are all binary
arrays of bytes."
This is not specific to AES.
Converting from or to hex (or Base64) strings is needed only to read from or
print to outside your C program.
Values passed to EVP_*() calls are expected to be raw (binary) data :
unsigned char *key, unsigned char *iv, as documented in
https://www.openssl.org/docs/manmaster/crypto/EVP_EncryptInit.html
(and do not rely on the 'bogus' key and IV values in the do_crypt()
example).
 
-----Message d'origine-----
De?: openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de
Sugumar
Envoy??: vendredi 26 f?vrier 2016 17:30
??: openssl-users at openssl.org
Objet?: [openssl-users] Need information on AES encryption and decryption
Key and IV type

Hi,,

I am using Openssl for encryption and decryption.
I need some information on AES encryption and decryption key and iv type.
My doubt is when we are using a openssl in command line we need to pass key
and iv as hex strings right?
and same when we are EVP calls in C/C++ programming what is the type of Key
and Iv. i mean it should a hex string or raw binary values?

I saw, openssl command line interface code of openssl in that the hex
strings are converted into hex values.
But in EVP calls the Key and Iv are used directly.



From nounou.dadoun at avigilon.com  Sat Feb 27 02:23:36 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Sat, 27 Feb 2016 02:23:36 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <20160226230607.GA21238@openssl.org>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>,
 <20160226230607.GA21238@openssl.org>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>

Thanks for the response,

I'm not sure what you're saying here other than TLS 1.2 client cert auth processing is different from TLS x (where x<1.2); I would assume that the range of mechanisms would expand to include more robust algorithms as time goes on.  However, here something is breaking backward compatibility with a client certificate that is still valid and otherwise correct as far as I can tell.  Our (many) deployed clients support TLSv1.2 and this certificate is widely distributed - we are trying to upgrade the server side from TLSv1 to TLSv1.2 and this appears to be a blocker.

Any recommendations?  I'm still not clear what it is about this certificate that fails in TLSv1.2; I would define a server callback for the certificate verification (I might experiment with that anyway) but it's not clear to me that it would call the callback if the signature is failing.

N.
________________________________________
From: openssl-users [openssl-users-bounces at openssl.org] on behalf of Dr. Stephen Henson [steve at openssl.org]
Sent: February 26, 2016 3:06 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

On Fri, Feb 26, 2016, Nounou Dadoun wrote:

> I've extracted the certificates from the exchange to verify that the (tlsv1) successful handshake and the (tlsv1.2) failed handshake certificates are identical (they are) and I've also checked to make sure that the CA certificate that the server has for signature verification is the same as the CA certificate handed over by the client in the exchange (it is).
>
> I've also used the command line openssl verify to verify the certificate against the CA:
> "client_cert_success.pem: OK"
>
> However it succeeds in TLSv1 and fails in TLSv1.2 (the one line change noted below).
>
> I've now attached the certificates for quick reference - can anyone see what might be causing the different behavior between TLSv1 and TLSv1.2?
>

The signature TLS uses for Client auth is different in TLS 1.2. For TLS < 1.2
the TLS signature is a combined MD5+SHA1 form for RSA. For TLS 1.2 it is the
more standard DigestInfo signature which can use other algorithms such as
SHA512 or SHA256.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From michel.sales at free.fr  Sat Feb 27 14:12:14 2016
From: michel.sales at free.fr (Michel)
Date: Sat, 27 Feb 2016 15:12:14 +0100
Subject: [openssl-users] PEM_read and write SSL_SESSION
In-Reply-To: <CAP=zTkNeds-vxsuidO0NgTL4-QpNRqTqEB9-MGrhbQ0PXKo=tw@mail.gmail.com>
References: <CAP=zTkNeds-vxsuidO0NgTL4-QpNRqTqEB9-MGrhbQ0PXKo=tw@mail.gmail.com>
Message-ID: <000001d17168$dc197b50$944c71f0$@sales@free.fr>

Hi,

 

Quoting Andy  about applink : "New code should rather abstain from using above mentioned subset of OpenSSL API (whatever using FILE*)".

 

So using the bio* version instead,

PEM_write_bio_SSL_SESSION( bio_st*, ssl_session_st*)

PEM_read_bio_SSL_SESSION( bio_st*, ssl_session_st**, int (char*, int, int, void*) *, void* )

are declared and implemented using macros as you can see in include\openssl\pem.h, starting line 156

(or search for "PEM_read/PEM_write functions")

 

You can use them as simply as (s_server.c, s_client.c ) :

SSL_SESSION *sess = PEM_read_bio_SSL_SESSION( pBIO, NULL, 0, NULL );

PEM_write_bio_SSL_SESSION( pBIO, SSL_get_session( pSSL ) );

 

They finally call :

PEM_ASN1_write_bio()

PEM_ASN1_read_bio()

about which more info can be found on http://www.umich.edu/~x509/ssleay/pem_io.html

 

Hope this helps,

 

Michel

 

 

De : openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de Shubham Chauhan
Envoy? : vendredi 26 f?vrier 2016 12:51
? : openssl-users at openssl.org
Objet : [openssl-users] PEM_read and write SSL_SESSION

 

If anyone is familiar with the PEM_read_SSL_SESSION and PEM_write_SSL_SESSION functions, please let me know about the arguments and the usage of these functions, in a bit detailed fashion.

It'll be really helpful.

Thanks


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160227/9b49accb/attachment.html>

From shubham13099 at iiitd.ac.in  Sat Feb 27 15:02:47 2016
From: shubham13099 at iiitd.ac.in (Shubham Chauhan)
Date: Sat, 27 Feb 2016 20:32:47 +0530
Subject: [openssl-users] PEM_read and write SSL_SESSION
In-Reply-To: <56d1aefe.4a2f1c0a.d948d.ffffb126SMTPIN_ADDED_BROKEN@mx.google.com>
References: <CAP=zTkNeds-vxsuidO0NgTL4-QpNRqTqEB9-MGrhbQ0PXKo=tw@mail.gmail.com>
 <56d1aefe.4a2f1c0a.d948d.ffffb126SMTPIN_ADDED_BROKEN@mx.google.com>
Message-ID: <CAP=zTkOqVU4CA0uzXSH2pa1BpFQZDAN2W_WB0g9RZJkWM2XNkg@mail.gmail.com>

great!
Thanks, I'll give it a try, this looks promising enough :)

On Sat, Feb 27, 2016 at 7:42 PM, Michel <michel.sales at free.fr> wrote:

> Hi,
>
>
>
> Quoting Andy  about applink : "New code should rather abstain from using
> above mentioned subset of OpenSSL API (whatever using FILE*)".
>
>
>
> So using the bio* version instead,
>
> PEM_write_bio_SSL_SESSION( bio_st*, ssl_session_st*)
>
> PEM_read_bio_SSL_SESSION( bio_st*, ssl_session_st**, int (char*, int, int,
> void*) *, void* )
>
> are declared and implemented using macros as you can see in include\openssl\pem.h,
> starting line 156
>
> (or search for "PEM_read/PEM_write functions")
>
>
>
> You can use them as simply as (s_server.c, s_client.c ) :
>
> SSL_SESSION *sess = PEM_read_bio_SSL_SESSION( pBIO, NULL, 0, NULL );
>
> PEM_write_bio_SSL_SESSION( pBIO, SSL_get_session( pSSL ) );
>
>
>
> They finally call :
>
> PEM_ASN1_write_bio()
>
> PEM_ASN1_read_bio()
>
> about which more info can be found on
> http://www.umich.edu/~x509/ssleay/pem_io.html
>
>
>
> Hope this helps,
>
>
>
> Michel
>
>
>
>
>
> *De :* openssl-users [mailto:openssl-users-bounces at openssl.org] *De la
> part de* Shubham Chauhan
> *Envoy? :* vendredi 26 f?vrier 2016 12:51
> *? :* openssl-users at openssl.org
> *Objet :* [openssl-users] PEM_read and write SSL_SESSION
>
>
>
> If anyone is familiar with the PEM_read_SSL_SESSION and
> PEM_write_SSL_SESSION functions, please let me know about the arguments and
> the usage of these functions, in a bit detailed fashion.
>
> It'll be really helpful.
>
> Thanks
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
Regards
Shubham Chauhan
2013099
B.Tech CSE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160227/4ac1b329/attachment-0001.html>

From steve at openssl.org  Sat Feb 27 18:23:43 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sat, 27 Feb 2016 18:23:43 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <20160227182343.GA9223@openssl.org>

On Sat, Feb 27, 2016, Nounou Dadoun wrote:

> Thanks for the response,
> 
> I'm not sure what you're saying here other than TLS 1.2 client cert auth
> processing is different from TLS x (where x<1.2); I would assume that the
> range of mechanisms would expand to include more robust algorithms as time
> goes on.  However, here something is breaking backward compatibility with a
> client certificate that is still valid and otherwise correct as far as I can
> tell.  Our (many) deployed clients support TLSv1.2 and this certificate is
> widely distributed - we are trying to upgrade the server side from TLSv1 to
> TLSv1.2 and this appears to be a blocker.
> 
> Any recommendations?  I'm still not clear what it is about this certificate
> that fails in TLSv1.2; I would define a server callback for the certificate
> verification (I might experiment with that anyway) but it's not clear to me
> that it would call the callback if the signature is failing.
> 

Well which version of OpenSSL is being used by the server and what software is
the client using?

When client auth is enabled the client presents its certificate chain to the
server. It also signs some data using the private key corresponsing to the
public key in the client certificate and the server verifies that signature.

It looks like it is this latter signature which is causing the problems and
nothing to do with the certificates (though they have some odd fields in there
OpenSSL wouldn't reject them). As I mentioned the type of signature a client
generates during client auth changed in TLS 1.2. It is possible that the
client is sending an invalid signature which the server is rejecting while
the different form used for TLS 1.1 and earlier is fine.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From kurt at roeckx.be  Sat Feb 27 19:13:04 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 27 Feb 2016 20:13:04 +0100
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <20160227182343.GA9223@openssl.org>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
Message-ID: <20160227191303.GA23651@roeckx.be>

On Sat, Feb 27, 2016 at 06:23:43PM +0000, Dr. Stephen Henson wrote:
> On Sat, Feb 27, 2016, Nounou Dadoun wrote:
> 
> > Thanks for the response,
> > 
> > I'm not sure what you're saying here other than TLS 1.2 client cert auth
> > processing is different from TLS x (where x<1.2); I would assume that the
> > range of mechanisms would expand to include more robust algorithms as time
> > goes on.  However, here something is breaking backward compatibility with a
> > client certificate that is still valid and otherwise correct as far as I can
> > tell.  Our (many) deployed clients support TLSv1.2 and this certificate is
> > widely distributed - we are trying to upgrade the server side from TLSv1 to
> > TLSv1.2 and this appears to be a blocker.
> > 
> > Any recommendations?  I'm still not clear what it is about this certificate
> > that fails in TLSv1.2; I would define a server callback for the certificate
> > verification (I might experiment with that anyway) but it's not clear to me
> > that it would call the callback if the signature is failing.
> > 
> 
> Well which version of OpenSSL is being used by the server and what software is
> the client using?

>From looking at the packet captures, I would guess that both sides
are OpenSSL.

> When client auth is enabled the client presents its certificate chain to the
> server. It also signs some data using the private key corresponsing to the
> public key in the client certificate and the server verifies that signature.
> 
> It looks like it is this latter signature which is causing the problems and
> nothing to do with the certificates (though they have some odd fields in there
> OpenSSL wouldn't reject them). As I mentioned the type of signature a client
> generates during client auth changed in TLS 1.2. It is possible that the
> client is sending an invalid signature which the server is rejecting while
> the different form used for TLS 1.1 and earlier is fine.

It's using RSA/SHA512 (0x0601), which the server offered.


Kurt


From nounou.dadoun at avigilon.com  Sat Feb 27 19:45:18 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Sat, 27 Feb 2016 19:45:18 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <20160227182343.GA9223@openssl.org>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>,
 <20160227182343.GA9223@openssl.org>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>

That gives me something to work with, the server is using openssl 1.0.2d, the client openssl 1.0.1h

I'd actually had an earlier interop problem between them (which I had a mailing list discussion about here: http://openssl.6102.n7.nabble.com/Failed-TLSv1-2-handshake-td61528.html#a61630 ) where server and client were negotiating TLSv1.2 with TLS_RSA_WITH_AES_256_GCM_SHA384 and the handshake failed with the error "decryption failed or bad record mac" - (that scenario was not doing mutual authentication) and my eventual workaround was to disable AESGCM from the cipher list  - which got things going again - with the intention of figuring out what the interop issue was later.  There's a packet capture of a sample failed exchange and more information about that overall scenario in that email thread.

>From that earlier thread:

----
BTW, the client uses OpenSSL 1.0.1h, in boost it's configured with: 
SslContextPtr_t pSslContext = std::make_shared<Net::SslContext>(pIoService, boost::asio::ssl::context::sslv23); 

With no other options. 
Client-side configure header is: 

VERSION=1.0.1h 
MAJOR=1 
MINOR=0.1 
SHLIB_VERSION_NUMBER=1.0.0 
SHLIB_VERSION_HISTORY= 
SHLIB_MAJOR=1 
SHLIB_MINOR=0.0 
SHLIB_EXT= 
PLATFORM=VC-WIN64A 
OPTIONS=enable-rsa enable-md5 enable-sha enable-sha1 enable-dsa enable-des enable-rc4 enable-dh no-bf no-camellia no-cast no-ec_nistp_64_gcc_128 no-gmp no-idea no-jpake no-krb5 no-md2 no-md4 no-mdc2 no-rc2 no-rc5 no-rfc3779 no-ripemd no-sctp no-shared no-store no-zlib no-zlib-dynamic 
CONFIGURE_ARGS=no-idea no-rc5 enable-rsa no-md2 no-md4 enable-md5 enable-sha enable-sha1 enable-dsa no-ripemd enable-des enable-rc4 no-rc2 no-bf no-camellia no-cast no-mdc2 enable-dh VC-WIN64A 
SHLIB_TARGET= 

And as I mentioned earlier, the server uses OpenSSL 1.0.2d which makes for an unusual interop problem! 
---

The openssl versions and ciphers are the same here except now the context has been changed to add mutual authentication (this is a configuration/control channel and we want to make sure that only authenticated clients can get in).   After the cipher change the negotiated cipher is now TLS_RSA_WITH_AES_256_CBC_SHA256.

The fact that they're both fairly recent versions of openssl negotiating TLSv1.2 (as I noted with a one-line change on the server side) makes things very mysterious.  Given the wide distributions of both these versions, I'm a little surprised that our setup seems to be having these fundamental issues in what I expect should be a very common scenario.  

Unfortunately at this point, I'm limited to making changes on the server and that's where my investigation needs to be.    Any breadcrumbs you could drop to help with that investigation would be much appreciated, (and I'd be happy to supply any artifacts that might help track down the issue(s)) thanks ... N

________________________________________
From: openssl-users [openssl-users-bounces at openssl.org] on behalf of Dr. Stephen Henson [steve at openssl.org]
Sent: February 27, 2016 10:23 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

On Sat, Feb 27, 2016, Nounou Dadoun wrote:

> Thanks for the response,
>
> I'm not sure what you're saying here other than TLS 1.2 client cert auth
> processing is different from TLS x (where x<1.2); I would assume that the
> range of mechanisms would expand to include more robust algorithms as time
> goes on.  However, here something is breaking backward compatibility with a
> client certificate that is still valid and otherwise correct as far as I can
> tell.  Our (many) deployed clients support TLSv1.2 and this certificate is
> widely distributed - we are trying to upgrade the server side from TLSv1 to
> TLSv1.2 and this appears to be a blocker.
>
> Any recommendations?  I'm still not clear what it is about this certificate
> that fails in TLSv1.2; I would define a server callback for the certificate
> verification (I might experiment with that anyway) but it's not clear to me
> that it would call the callback if the signature is failing.
>

Well which version of OpenSSL is being used by the server and what software is
the client using?

When client auth is enabled the client presents its certificate chain to the
server. It also signs some data using the private key corresponsing to the
public key in the client certificate and the server verifies that signature.

It looks like it is this latter signature which is causing the problems and
nothing to do with the certificates (though they have some odd fields in there
OpenSSL wouldn't reject them). As I mentioned the type of signature a client
generates during client auth changed in TLS 1.2. It is possible that the
client is sending an invalid signature which the server is rejecting while
the different form used for TLS 1.1 and earlier is fine.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From kurt at roeckx.be  Sat Feb 27 20:49:06 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 27 Feb 2016 21:49:06 +0100
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <20160227204906.GA31402@roeckx.be>

On Sat, Feb 27, 2016 at 07:45:18PM +0000, Nounou Dadoun wrote:
> PLATFORM=VC-WIN64A 

Can you try a build with no-asm?


Kurt


From nounou.dadoun at avigilon.com  Sat Feb 27 21:02:26 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Sat, 27 Feb 2016 21:02:26 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <20160227204906.GA31402@roeckx.be>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>,
 <20160227204906.GA31402@roeckx.be>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E17AF8@mbx027-w1-ca-4.exch027.domain.local>

That's the client side configuration (the server is actually running on arm) but I can get the client team to try it ... N
________________________________________
From: openssl-users [openssl-users-bounces at openssl.org] on behalf of Kurt Roeckx [kurt at roeckx.be]
Sent: February 27, 2016 12:49 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

On Sat, Feb 27, 2016 at 07:45:18PM +0000, Nounou Dadoun wrote:
> PLATFORM=VC-WIN64A

Can you try a build with no-asm?


Kurt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From openssl-users at dukhovni.org  Sat Feb 27 21:14:21 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 27 Feb 2016 16:14:21 -0500
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
	error 67702888--bad signature
In-Reply-To: <20160227204906.GA31402@roeckx.be>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
 <20160227204906.GA31402@roeckx.be>
Message-ID: <6D70C4AD-3ABB-4766-ABE0-A537EC71F230@dukhovni.org>


> On Feb 27, 2016, at 3:49 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
> 
> On Sat, Feb 27, 2016 at 07:45:18PM +0000, Nounou Dadoun wrote:
>> PLATFORM=VC-WIN64A 
> 
> Can you try a build with no-asm?

Or perhaps with 1.0.1r, why stick with 1.0.1h???

-- 
	Viktor.


From noloader at gmail.com  Sat Feb 27 21:22:22 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 27 Feb 2016 16:22:22 -0500
Subject: [openssl-users] Is verification supposed to fail with
 SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT without
 SSL_CTX_set_client_CA_list?
Message-ID: <CAH8yC8nnRQSkpfOssfH-fpGFZks2jUU4hM_LELgjObA2Z0Vmew@mail.gmail.com>

This came up recently on Stack Overflow. The server code specified
SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, but failed to call
SSL_CTX_set_client_CA_list. The connection did not fail as expected.

Looking at the man page for SSL_CTX_set_verify [1] and
SSL_CTX_set_client_CA_list [2] it looks like the connection is
supposed to fail. From [1]:

    SSL_VERIFY_FAIL_IF_NO_PEER_CERT

        Server mode: if the client did not return a certificate,
        the TLS/SSL handshake is immediately terminated
        with a "handshake failure" alert...

Is verification supposed to fail with SSL_VERIFY_PEER |
SSL_VERIFY_FAIL_IF_NO_PEER_CERT regardless of the interactions with
SSL_CTX_set_client_CA_list? Or is there a hidden dependency on
SSL_CTX_set_client_CA_list?

[1] http://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_verify.html
[2] http://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_client_CA_list.html

From nounou.dadoun at avigilon.com  Sat Feb 27 21:25:54 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Sat, 27 Feb 2016 21:25:54 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake
	with	error 67702888--bad signature
In-Reply-To: <6D70C4AD-3ABB-4766-ABE0-A537EC71F230@dukhovni.org>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
 <20160227204906.GA31402@roeckx.be>,
 <6D70C4AD-3ABB-4766-ABE0-A537EC71F230@dukhovni.org>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E17B1A@mbx027-w1-ca-4.exch027.domain.local>

I agree but that's not the side I'm working on; the client is already widely distributed and if we can identify that as the interop problem then I can make an argument to the client team to upgrade but that doesn't solve the currently deployed problem ... N
________________________________________
From: openssl-users [openssl-users-bounces at openssl.org] on behalf of Viktor Dukhovni [openssl-users at dukhovni.org]
Sent: February 27, 2016 1:14 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with        error 67702888--bad signature

> On Feb 27, 2016, at 3:49 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
>
> On Sat, Feb 27, 2016 at 07:45:18PM +0000, Nounou Dadoun wrote:
>> PLATFORM=VC-WIN64A
>
> Can you try a build with no-asm?

Or perhaps with 1.0.1r, why stick with 1.0.1h???

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From openssl-users at dukhovni.org  Sat Feb 27 21:28:23 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 27 Feb 2016 16:28:23 -0500
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake
	with	error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E17B1A@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
 <20160227204906.GA31402@roeckx.be>
 <6D70C4AD-3ABB-4766-ABE0-A537EC71F230@dukhovni.org>
 <8149AB08BCB1F54F92680ED6104891A0E17B1A@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <89EC0C43-7628-4A33-9F92-4624AD6F3D67@dukhovni.org>


> On Feb 27, 2016, at 4:25 PM, Nounou Dadoun <nounou.dadoun at avigilon.com> wrote:
> 
> I agree but that's not the side I'm working on; the client is already widely distributed and if we can identify that as the interop problem then I can make an argument to the client team to upgrade but that doesn't solve the currently deployed problem ... N

Given that your server is on ARM, which is not yet a widely used platform for OpenSSL 1.0.2, most
likely the issue is there.  So disabling ASM on the server side is worth a try.

Also test your client against non-ARM 1.0.2d servers...

-- 
	Viktor.


From nounou.dadoun at avigilon.com  Sat Feb 27 22:10:32 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Sat, 27 Feb 2016 22:10:32 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2
	handshake	with	error 67702888--bad signature
In-Reply-To: <89EC0C43-7628-4A33-9F92-4624AD6F3D67@dukhovni.org>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
 <20160227204906.GA31402@roeckx.be>
 <6D70C4AD-3ABB-4766-ABE0-A537EC71F230@dukhovni.org>
 <8149AB08BCB1F54F92680ED6104891A0E17B1A@mbx027-w1-ca-4.exch027.domain.local>,
 <89EC0C43-7628-4A33-9F92-4624AD6F3D67@dukhovni.org>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E17B43@mbx027-w1-ca-4.exch027.domain.local>

That's a useful thing to try - given the earlier mismatch, I suspect that it may be something in the hash calculation that's not quite lining up and causing the signature match to fail.  thanks for the suggestion .. N
________________________________________
From: openssl-users [openssl-users-bounces at openssl.org] on behalf of Viktor Dukhovni [openssl-users at dukhovni.org]
Sent: February 27, 2016 1:28 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake     with    error 67702888--bad signature

> On Feb 27, 2016, at 4:25 PM, Nounou Dadoun <nounou.dadoun at avigilon.com> wrote:
>
> I agree but that's not the side I'm working on; the client is already widely distributed and if we can identify that as the interop problem then I can make an argument to the client team to upgrade but that doesn't solve the currently deployed problem ... N

Given that your server is on ARM, which is not yet a widely used platform for OpenSSL 1.0.2, most
likely the issue is there.  So disabling ASM on the server side is worth a try.

Also test your client against non-ARM 1.0.2d servers...

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From michel.sales at free.fr  Sat Feb 27 22:41:57 2016
From: michel.sales at free.fr (Michel)
Date: Sat, 27 Feb 2016 23:41:57 +0100
Subject: [openssl-users] Is verification supposed to fail with
	SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT without
	SSL_CTX_set_client_CA_list?
In-Reply-To: <CAH8yC8nnRQSkpfOssfH-fpGFZks2jUU4hM_LELgjObA2Z0Vmew@mail.gmail.com>
References: <CAH8yC8nnRQSkpfOssfH-fpGFZks2jUU4hM_LELgjObA2Z0Vmew@mail.gmail.com>
Message-ID: <001701d171b0$1161cd20$34256760$@sales@free.fr>

Really ? 
As your post alarmed me, I tried my tests programs again and didn't noticed
anything wrong.
I have a server code whose context is configured with SSL_VERIFY_PEER |
SSL_VERIFY_FAIL_IF_NO_PEER_CERT and which do not call
SSL_CTX_set_client_CA_list().
In this case, handshake is failing as expected when clients didn't send a
certificate.
OpenSSL Windows 32 bits version 1.1 from git repo yesterday.

-----Message d'origine-----
De?: openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de
Jeffrey Walton
Envoy??: samedi 27 f?vrier 2016 22:22
??: OpenSSL Users List
Objet?: [openssl-users] Is verification supposed to fail with
SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT without
SSL_CTX_set_client_CA_list?

This came up recently on Stack Overflow. The server code specified
SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, but failed to call
SSL_CTX_set_client_CA_list. The connection did not fail as expected.

Looking at the man page for SSL_CTX_set_verify [1] and
SSL_CTX_set_client_CA_list [2] it looks like the connection is supposed to
fail. From [1]:

    SSL_VERIFY_FAIL_IF_NO_PEER_CERT

        Server mode: if the client did not return a certificate,
        the TLS/SSL handshake is immediately terminated
        with a "handshake failure" alert...

Is verification supposed to fail with SSL_VERIFY_PEER |
SSL_VERIFY_FAIL_IF_NO_PEER_CERT regardless of the interactions with
SSL_CTX_set_client_CA_list? Or is there a hidden dependency on
SSL_CTX_set_client_CA_list?


From noloader at gmail.com  Sat Feb 27 22:48:10 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 27 Feb 2016 17:48:10 -0500
Subject: [openssl-users] Is verification supposed to fail with
 SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT without
 SSL_CTX_set_client_CA_list?
In-Reply-To: <56d22645.42891c0a.1c295.ffffd1f7SMTPIN_ADDED_BROKEN@mx.google.com>
References: <CAH8yC8nnRQSkpfOssfH-fpGFZks2jUU4hM_LELgjObA2Z0Vmew@mail.gmail.com>
 <56d22645.42891c0a.1c295.ffffd1f7SMTPIN_ADDED_BROKEN@mx.google.com>
Message-ID: <CAH8yC8kKtKQs61wONQsxKGMMo__OjonwVi34stNp7BLrh3f=tA@mail.gmail.com>

> I have a server code whose context is configured with SSL_VERIFY_PEER |
> SSL_VERIFY_FAIL_IF_NO_PEER_CERT and which do not call
> SSL_CTX_set_client_CA_list().
> In this case, handshake is failing as expected when clients didn't send a
> certificate.

Thanks Michel.

Does your server use the default verify callback? Or does it have a
custom callback? (The original question uses the default verify
callback).

Jeff

From michel.sales at free.fr  Sat Feb 27 23:01:55 2016
From: michel.sales at free.fr (Michel)
Date: Sun, 28 Feb 2016 00:01:55 +0100
Subject: [openssl-users] Is verification supposed to fail with
	SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT without
	SSL_CTX_set_client_CA_list?
In-Reply-To: <CAH8yC8kKtKQs61wONQsxKGMMo__OjonwVi34stNp7BLrh3f=tA@mail.gmail.com>
References: <CAH8yC8nnRQSkpfOssfH-fpGFZks2jUU4hM_LELgjObA2Z0Vmew@mail.gmail.com>	<56d22645.42891c0a.1c295.ffffd1f7SMTPIN_ADDED_BROKEN@mx.google.com>
 <CAH8yC8kKtKQs61wONQsxKGMMo__OjonwVi34stNp7BLrh3f=tA@mail.gmail.com>
Message-ID: <001801d171b2$db6baf80$92430e80$@sales@free.fr>

Hi Jeff,

The test I just ran was done with NO custom callback :
SSL_CTX_set_verify( pCtx, AUTH_REQUIRE, NULL );
with AUTH_REQUIRE defined as ( SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT )

-----Message d'origine-----
De : Jeffrey Walton [mailto:noloader at gmail.com] 
Envoy? : samedi 27 f?vrier 2016 23:48

Does your server use the default verify callback? Or does it have a custom callback? 
(The original question uses the default verify callback).



From steve at openssl.org  Sat Feb 27 23:25:31 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sat, 27 Feb 2016 23:25:31 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <20160227232531.GA16633@openssl.org>

On Sat, Feb 27, 2016, Nounou Dadoun wrote:

> That gives me something to work with, the server is using openssl 1.0.2d, the client openssl 1.0.1h
> 
> I'd actually had an earlier interop problem between them (which I had a mailing list discussion about here: http://openssl.6102.n7.nabble.com/Failed-TLSv1-2-handshake-td61528.html#a61630 ) where server and client were negotiating TLSv1.2 with TLS_RSA_WITH_AES_256_GCM_SHA384 and the handshake failed with the error "decryption failed or bad record mac" - (that scenario was not doing mutual authentication) and my eventual workaround was to disable AESGCM from the cipher list  - which got things going again - with the intention of figuring out what the interop issue was later.  There's a packet capture of a sample failed exchange and more information about that overall scenario in that email thread.
> 

That might be a problem with SHA384/SHA512. You can configure OpenSSL 1.0.2
server side to not request RSA+SHA384/RSA+SHA512 and see if that helps. If
TLS v1.2 works other than that then it's likely that SHA256 is OK.

See for example SSL_CTX_set1_client_sigalgs_list() et al at:

https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set1_client_sigalgs.html

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Sat Feb 27 23:37:02 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sat, 27 Feb 2016 23:37:02 +0000
Subject: [openssl-users] Is verification supposed to fail with
 SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT without
 SSL_CTX_set_client_CA_list?
In-Reply-To: <CAH8yC8nnRQSkpfOssfH-fpGFZks2jUU4hM_LELgjObA2Z0Vmew@mail.gmail.com>
References: <CAH8yC8nnRQSkpfOssfH-fpGFZks2jUU4hM_LELgjObA2Z0Vmew@mail.gmail.com>
Message-ID: <20160227233702.GA17525@openssl.org>

On Sat, Feb 27, 2016, Jeffrey Walton wrote:

> This came up recently on Stack Overflow. The server code specified
> SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, but failed to call
> SSL_CTX_set_client_CA_list. The connection did not fail as expected.
> 
> Looking at the man page for SSL_CTX_set_verify [1] and
> SSL_CTX_set_client_CA_list [2] it looks like the connection is
> supposed to fail. From [1]:
> 
>     SSL_VERIFY_FAIL_IF_NO_PEER_CERT
> 
>         Server mode: if the client did not return a certificate,
>         the TLS/SSL handshake is immediately terminated
>         with a "handshake failure" alert...
> 
> Is verification supposed to fail with SSL_VERIFY_PEER |
> SSL_VERIFY_FAIL_IF_NO_PEER_CERT regardless of the interactions with
> SSL_CTX_set_client_CA_list? Or is there a hidden dependency on
> SSL_CTX_set_client_CA_list?
> 

The function SSL_CTX_set_client_CA_list() sets a list of supportied CA names.
This list is sent to the client during client authentication.
The client can then use that (if it wishes) to decide which certificate
to use for client authentication.

A client may not filter the CAs based on that list: it might give the
user the option to send any client certificate it has available. Also when
presented with an empty list the client might decide that all certificates are
permissible or that it's some kind of error and it can't send any.

So not setting SSL_CTX_set_client_CA_list() is not guaranteed to fail and what
happens depends on the client.

The set of certificates the server trusts for client authentication can be a
separate list though if you don't trust any certificate chains you sent in the
client CA list that would be somewhat odd.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Sun Feb 28 01:24:21 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sun, 28 Feb 2016 01:24:21 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <20160228012421.GA19697@openssl.org>

On Sat, Feb 27, 2016, Nounou Dadoun wrote:

> That gives me something to work with, the server is using openssl 1.0.2d, the client openssl 1.0.1h
> 

Also does the server side pass "make test"? Especially test/sha512t

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From nounou.dadoun at avigilon.com  Sun Feb 28 08:25:23 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Sun, 28 Feb 2016 08:25:23 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <20160228012421.GA19697@openssl.org>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>,
 <20160228012421.GA19697@openssl.org>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E17BE1@mbx027-w1-ca-4.exch027.domain.local>


________________________________________
From: openssl-users [openssl-users-bounces at openssl.org] on behalf of Dr. Stephen Henson [steve at openssl.org]
Sent: February 27, 2016 5:24 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

On Sat, Feb 27, 2016, Nounou Dadoun wrote:

> That gives me something to work with, the server is using openssl 1.0.2d, the client openssl 1.0.1h
>

Also does the server side pass "make test"? Especially test/sha512t

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

We're cross-compiling on a linux x86 vm, does "make test" produce something that I can run on the target?

From steve at openssl.org  Sun Feb 28 12:57:50 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sun, 28 Feb 2016 12:57:50 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E17BE1@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
 <20160228012421.GA19697@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E17BE1@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <20160228125750.GA29658@openssl.org>

On Sun, Feb 28, 2016, Nounou Dadoun wrote:

> 
> We're cross-compiling on a linux x86 vm, does "make test" produce something that I can run on the target?

"make test" wont be very useful then. The binary test/sha512t you can copy to
the target and run it. I'd be interested in the output.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From shubham13099 at iiitd.ac.in  Sun Feb 28 13:02:47 2016
From: shubham13099 at iiitd.ac.in (Shubham Chauhan)
Date: Sun, 28 Feb 2016 18:32:47 +0530
Subject: [openssl-users] PEM_read and write SSL_SESSION
In-Reply-To: <CAP=zTkOqVU4CA0uzXSH2pa1BpFQZDAN2W_WB0g9RZJkWM2XNkg@mail.gmail.com>
References: <CAP=zTkNeds-vxsuidO0NgTL4-QpNRqTqEB9-MGrhbQ0PXKo=tw@mail.gmail.com>
 <56d1aefe.4a2f1c0a.d948d.ffffb126SMTPIN_ADDED_BROKEN@mx.google.com>
 <CAP=zTkOqVU4CA0uzXSH2pa1BpFQZDAN2W_WB0g9RZJkWM2XNkg@mail.gmail.com>
Message-ID: <CAP=zTkPBVtaOgQJ2bM3pRyYfvOLRzStxfa8hmGG38-3ZXUH_Wg@mail.gmail.com>

Okay so I have been trying to store session details in a file, haven't used
BIO for now, but I guess my present method should work fine.
This is on the server side -


        FILE * filePtr;
        char fileString[128];
        sprintf(fileString, "/home/session_id");

        if ((filePtr = fopen(fileString,  "r")) != NULL)
        {
            session = PEM_read_SSL_SESSION(filePtr, NULL, NULL, NULL);
            int added =0;
            added = SSL_CTX_add_session(ctx, session);
            printf("\n::: %d :::\n", added);  /* it is returning 1 always
which means that it succeeds */

            fclose(filePtr);
        }

        ssl = SSL_new(ctx);
        SSL_set_fd(ssl, clntfd);
        SSL_accept(ssl);


        session = SSL_get1_session(ssl);
        FILE* filePtr2;

        char fileString2[128];
        sprintf(fileString2, "/home/session_id");

        if ((filePtr2 = fopen(fileString2,  "r+")) != NULL)
        {
                // write the data to the file
                PEM_write_SSL_SESSION(filePtr2, session);
                // close the file
                fclose(filePtr2);
        }


Everytime a new session is negotiated, the session_id file gets updated
with the new session details. I am able to write and read from a file.
This means that the session should always be re-used, even if the session
gets timed-out from the internal cache, it will get loaded from the
external file, and the session must always be reused. BUT THIS IS NOT
HAPPENING FOR NOW.
Any problem in the code!? Please let me know


On Sat, Feb 27, 2016 at 8:32 PM, Shubham Chauhan <shubham13099 at iiitd.ac.in>
wrote:

> great!
> Thanks, I'll give it a try, this looks promising enough :)
>
> On Sat, Feb 27, 2016 at 7:42 PM, Michel <michel.sales at free.fr> wrote:
>
>> Hi,
>>
>>
>>
>> Quoting Andy  about applink : "New code should rather abstain from using
>> above mentioned subset of OpenSSL API (whatever using FILE*)".
>>
>>
>>
>> So using the bio* version instead,
>>
>> PEM_write_bio_SSL_SESSION( bio_st*, ssl_session_st*)
>>
>> PEM_read_bio_SSL_SESSION( bio_st*, ssl_session_st**, int (char*, int,
>> int, void*) *, void* )
>>
>> are declared and implemented using macros as you can see in include\openssl\pem.h,
>> starting line 156
>>
>> (or search for "PEM_read/PEM_write functions")
>>
>>
>>
>> You can use them as simply as (s_server.c, s_client.c ) :
>>
>> SSL_SESSION *sess = PEM_read_bio_SSL_SESSION( pBIO, NULL, 0, NULL );
>>
>> PEM_write_bio_SSL_SESSION( pBIO, SSL_get_session( pSSL ) );
>>
>>
>>
>> They finally call :
>>
>> PEM_ASN1_write_bio()
>>
>> PEM_ASN1_read_bio()
>>
>> about which more info can be found on
>> http://www.umich.edu/~x509/ssleay/pem_io.html
>>
>>
>>
>> Hope this helps,
>>
>>
>>
>> Michel
>>
>>
>>
>>
>>
>> *De :* openssl-users [mailto:openssl-users-bounces at openssl.org] *De la
>> part de* Shubham Chauhan
>> *Envoy? :* vendredi 26 f?vrier 2016 12:51
>> *? :* openssl-users at openssl.org
>> *Objet :* [openssl-users] PEM_read and write SSL_SESSION
>>
>>
>>
>> If anyone is familiar with the PEM_read_SSL_SESSION and
>> PEM_write_SSL_SESSION functions, please let me know about the arguments and
>> the usage of these functions, in a bit detailed fashion.
>>
>> It'll be really helpful.
>>
>> Thanks
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>
>
> --
> Regards
> Shubham Chauhan
> 2013099
> B.Tech CSE
>



-- 
Regards
Shubham Chauhan
2013099
B.Tech CSE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160228/4ae398dd/attachment.html>

From zhjwpku at gmail.com  Sun Feb 28 13:10:50 2016
From: zhjwpku at gmail.com (John Hunter)
Date: Sun, 28 Feb 2016 21:10:50 +0800
Subject: [openssl-users] default cipher suit
Message-ID: <CAEG8a3L51KA6ZEkQNJBCA65Td9+D4BnYzmd4=-hj2WoFur91nA@mail.gmail.com>

Hi guys,
I have noticed that SPICE protocol use the openssl to provide secure
transfer, and it can be named a cipher-suit, I'm wondering if I didn't
specify any cipher-suit, which cipher suit will be used in that scene.

BR,
Zhao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160228/63b3ec7d/attachment.html>

From rsalz at akamai.com  Sun Feb 28 14:33:27 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 28 Feb 2016 14:33:27 +0000
Subject: [openssl-users] default cipher suit
In-Reply-To: <CAEG8a3L51KA6ZEkQNJBCA65Td9+D4BnYzmd4=-hj2WoFur91nA@mail.gmail.com>
References: <CAEG8a3L51KA6ZEkQNJBCA65Td9+D4BnYzmd4=-hj2WoFur91nA@mail.gmail.com>
Message-ID: <2a20d946b9bc47f6bd8506c87d7aff1a@usma1ex-dag1mb1.msg.corp.akamai.com>

If no cipher suite is named, then the value of DEFAULT will be used.  What that is depends on which version of OpenSSL is used.

--
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz

From: John Hunter [mailto:zhjwpku at gmail.com]
Sent: Sunday, February 28, 2016 8:11 AM
To: openssl-users at openssl.org
Subject: [openssl-users] default cipher suit

Hi guys,
I have noticed that SPICE protocol use the openssl to provide secure
transfer, and it can be named a cipher-suit, I'm wondering if I didn't
specify any cipher-suit, which cipher suit will be used in that scene.

BR,
Zhao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160228/c4afe989/attachment-0001.html>

From lists at rustichelli.net  Sun Feb 28 16:24:51 2016
From: lists at rustichelli.net (lists)
Date: Sun, 28 Feb 2016 17:24:51 +0100
Subject: [openssl-users] upgrade to 1.0.1r breaks script that worked for
 years. Config issue?
In-Reply-To: <20160224184617.GA26884@roeckx.be>
References: <56CDD8B0.3040109@rustichelli.net>
 <20160224184617.GA26884@roeckx.be>
Message-ID: <56D31F53.3050204@rustichelli.net>

On 02/24/2016 07:46 PM, Kurt Roeckx wrote:
> On Wed, Feb 24, 2016 at 05:22:08PM +0100, lists wrote:
>> Before I try some heavy debugging, does anybody know of a change from
>> version 1.0.1e to 1.0.1r that would prevent the commands above from working?
> Can you try reverting commit
> 23a58779f53a9060c823d00d76b3070cad61d9a3?  I've attached a patch.
>
> This is something that will get reverted in the next release.  But
> if that fixes something, it's actually something in the engine
> that's broken.
>
>
> Kurt

Thanks Kurt, actually that fixed the issue, so I must look into the 
engine or better post this information to the proper list.


From lists at rustichelli.net  Sun Feb 28 16:25:30 2016
From: lists at rustichelli.net (lists)
Date: Sun, 28 Feb 2016 17:25:30 +0100
Subject: [openssl-users] upgrade to 1.0.1r breaks script that worked for
 years. Config issue?
In-Reply-To: <20160224195018.GA14592@openssl.org>
References: <56CDD8B0.3040109@rustichelli.net>
 <20160224195018.GA14592@openssl.org>
Message-ID: <56D31F7A.3010503@rustichelli.net>

On 02/24/2016 08:50 PM, Dr. Stephen Henson wrote:
> On Wed, Feb 24, 2016, lists wrote:
>
>> extensions = x509v3
>>
>> [ x509v3 ]
>> keyUsage              = digitalSignature
>> extendedKeyUsage      = clientAuth,emailProtection
>> crlDistributionPoints = URI:http://ldap.secure-edge.com/secure-edge-ca.crl
>> subjectAltName        = email:copy
>> basicConstraints      = CA:false,pathlen:0
> While this isn't the cause of your problem you should NOT use pathelen if you
> have CA:false. An application might reject such a certificate due to
> inconsistent extension values.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org

You're definitely right. Thanks.


From rsalz at akamai.com  Mon Feb 29 01:40:34 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 29 Feb 2016 01:40:34 +0000
Subject: [openssl-users] "These are not the patches you are looking for"
Message-ID: <e135ed9aa42b4b5da59e9fd7525a4a8f@usma1ex-dag1mb1.msg.corp.akamai.com>

We recently posted some patches to to our public repo.  Since they came out just before the announced security release, many people have been confused and thought that perhaps we posted CVE fixes prematurely.  This is not the case.  The commit were for fixing low-priority CVE issues, and according to our security policy (https://www.openssl.org/policies/secpolicy.html) were pushed as commits.

The release we pre-announced addresses other, more serious, issues.

--
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160229/ffbc7e33/attachment.html>

From zhjwpku at gmail.com  Mon Feb 29 06:03:07 2016
From: zhjwpku at gmail.com (John Hunter)
Date: Mon, 29 Feb 2016 14:03:07 +0800
Subject: [openssl-users] default cipher suit
In-Reply-To: <2a20d946b9bc47f6bd8506c87d7aff1a@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAEG8a3L51KA6ZEkQNJBCA65Td9+D4BnYzmd4=-hj2WoFur91nA@mail.gmail.com>
 <2a20d946b9bc47f6bd8506c87d7aff1a@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAEG8a3+AG7OLNn9nP+XejvxppfPJ3nU4sM-ubQvuvXvqKY1Mng@mail.gmail.com>

ok, thanks :)

On Sun, Feb 28, 2016 at 10:33 PM, Salz, Rich <rsalz at akamai.com> wrote:

> If no cipher suite is named, then the value of DEFAULT will be used.  What
> that is depends on which version of OpenSSL is used.
>
>
>
> --
>
> Senior Architect, Akamai Technologies
>
> IM: richsalz at jabber.at Twitter: RichSalz
>
>
>
> *From:* John Hunter [mailto:zhjwpku at gmail.com]
> *Sent:* Sunday, February 28, 2016 8:11 AM
> *To:* openssl-users at openssl.org
> *Subject:* [openssl-users] default cipher suit
>
>
>
> Hi guys,
>
> I have noticed that SPICE protocol use the openssl to provide secure
>
> transfer, and it can be named a cipher-suit, I'm wondering if I didn't
>
> specify any cipher-suit, which cipher suit will be used in that scene.
>
>
>
> BR,
>
> Zhao
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160229/e6c776c4/attachment.html>

From stm at pdflib.com  Mon Feb 29 08:35:44 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Mon, 29 Feb 2016 09:35:44 +0100
Subject: [openssl-users] Is the structure of this CMS object correct?
In-Reply-To: <20160225121640.GA27267@openssl.org>
References: <56B9AE22.6000501@pdflib.com>
 <AF40454C-E74A-4359-B53C-E694AE1FC590@docusign.com>
 <56B9CD84.7020207@pdflib.com>
 <74002D90-1437-45F0-96F3-401B27B8569A@docusign.com>
 <56CC1927.7050701@pdflib.com> <20160223172637.GA15299@openssl.org>
 <20160225121640.GA27267@openssl.org>
Message-ID: <56D402E0.10007@pdflib.com>

Am 25.02.16 um 13:16 schrieb Dr. Stephen Henson:

>> So yes it's pretty broken.
>>
>
> Just as a quick followup. If you change the two tags I mentioned above the
> result does then parse. However I've no idea if it will actually decrypt: the
> key derivation might be broken too.

Thanks for the follow-up. As this is a problem in Adobe Acrobat, we 
can't do anything about it. The problem was now reported to Adobe, and 
hopefully they will fix it.

-- 
Stephan

From rhermann at centurioncares.com  Mon Feb 29 17:01:18 2016
From: rhermann at centurioncares.com (Rob Hermann)
Date: Mon, 29 Feb 2016 11:01:18 -0600
Subject: [openssl-users] Building OpenSSL: OpenSSL-Release,
	expired certificates
In-Reply-To: <56D450E8.6090101@centurioncares.com>
References: <56D44FC4.1020702@centurioncares.com>
 <56D450E8.6090101@centurioncares.com>
Message-ID: <56D4795E.5000201@centurioncares.com>


I'm running in a linux-elf environment as the su.

when I run "make tests"   at the tail end of  the tests I get some 
errors about expired certificates:


testing pkcs7 conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing pkcs7 conversions (2)
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
The following command should have some OK's and some failures
There are definitly a few expired certificates
../util/shlib_wrap.sh ../apps/openssl verify -CApath ../certs/demo 
../certs/demo/*.pem
../certs/demo/ca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty 
Ltd, CN = Test CA (1024 bit)
error 20 at 0 depth lookup:unable to get local issuer certificate
../certs/demo/dsa-ca.pem: C = AU, ST = Some-State, O = Internet Widgits 
Pty Ltd, CN = CA
error 20 at 0 depth lookup:unable to get local issuer certificate
3077822616:error:0B06E06B:x509 certificate 
routines:X509_get_pubkey_parameters:unable to find parameters in 
chain:x509_vfy.c:1966:
../certs/demo/dsa-pca.pem: C = AU, ST = Some-State, O = Internet Widgits 
Pty Ltd, CN = PCA
error 18 at 0 depth lookup:self signed certificate
C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = PCA
error 10 at 0 depth lookup:certificate has expired
OK
../certs/demo/pca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty 
Ltd, CN = Test PCA (1024 bit)
error 18 at 0 depth lookup:self signed certificate
C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN = Test PCA (1024 bit)
error 10 at 0 depth lookup:certificate has expired
OK
_make[1]: *** [test_verify] Error 2__
__make[1]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'__
__make: *** [tests] Error 2__
_[root at rhlinuxdev OpenSSLWork]#



what do the underlined statements mean ? is there an expired certificate 
that needs to get updated ?


Rob Hermann




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160229/f7d66553/attachment-0001.html>

From nounou.dadoun at avigilon.com  Mon Feb 29 19:39:03 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Mon, 29 Feb 2016 19:39:03 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <20160228125750.GA29658@openssl.org>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
 <20160228012421.GA19697@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E17BE1@mbx027-w1-ca-4.exch027.domain.local>
 <20160228125750.GA29658@openssl.org>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E18DB3@mbx027-w1-ca-4.exch027.domain.local>

Back in the office today - the sha1 and sha256 tests passed but the sha512 failed immediately as below.

# ./sha1test
test 1 ok
test 2 ok
test 3 ok
# ./sha256t
Testing SHA-256 ... passed.
Testing SHA-224 ... passed.
# ./sha512t
Testing SHA-512
TEST 1 of 3 failed.
#

Took a quick look at the code and it looks pretty straightforward, do you have a version you'd like me to run that dumps the result over and above doing a straight memcmp (funny that it doesn't do that anyway on failure) or just let me know what you'd like dumped and what format you'd like it in.  And maybe remove the returns so it goes through all the tests?  

Happy to help root cause this issue if I can.

Haven't tried the no-asm option yet, I might try that next.

Nou Dadoun
Senior Firmware Developer, Security Specialist

Office: 604.629.5182 ext 2632 

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Sunday, February 28, 2016 4:58 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

On Sun, Feb 28, 2016, Nounou Dadoun wrote:

> 
> We're cross-compiling on a linux x86 vm, does "make test" produce something that I can run on the target?

"make test" wont be very useful then. The binary test/sha512t you can copy to the target and run it. I'd be interested in the output.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From nounou.dadoun at avigilon.com  Mon Feb 29 20:12:10 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Mon, 29 Feb 2016 20:12:10 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E18DB3@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
 <20160228012421.GA19697@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E17BE1@mbx027-w1-ca-4.exch027.domain.local>
 <20160228125750.GA29658@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E18DB3@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E18DCA@mbx027-w1-ca-4.exch027.domain.local>

For the record, I added no-asm to the config options and got exactly the same result on the sha512t test.  Open to other suggestions ... N


Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 
Support: 888.281.5182 ?|? avigilon.com
Follow?Twitter ?|? Follow?LinkedIn


This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide.



-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun
Sent: Monday, February 29, 2016 11:39 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

Back in the office today - the sha1 and sha256 tests passed but the sha512 failed immediately as below.

# ./sha1test
test 1 ok
test 2 ok
test 3 ok
# ./sha256t
Testing SHA-256 ... passed.
Testing SHA-224 ... passed.
# ./sha512t
Testing SHA-512
TEST 1 of 3 failed.
#

Took a quick look at the code and it looks pretty straightforward, do you have a version you'd like me to run that dumps the result over and above doing a straight memcmp (funny that it doesn't do that anyway on failure) or just let me know what you'd like dumped and what format you'd like it in.  And maybe remove the returns so it goes through all the tests?  

Happy to help root cause this issue if I can.

Haven't tried the no-asm option yet, I might try that next.

Nou Dadoun
Senior Firmware Developer, Security Specialist

Office: 604.629.5182 ext 2632 

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Sunday, February 28, 2016 4:58 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

On Sun, Feb 28, 2016, Nounou Dadoun wrote:

> 
> We're cross-compiling on a linux x86 vm, does "make test" produce something that I can run on the target?

"make test" wont be very useful then. The binary test/sha512t you can copy to the target and run it. I'd be interested in the output.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From kurt at roeckx.be  Mon Feb 29 20:23:27 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 29 Feb 2016 21:23:27 +0100
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E18DCA@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
 <20160228012421.GA19697@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E17BE1@mbx027-w1-ca-4.exch027.domain.local>
 <20160228125750.GA29658@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E18DB3@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18DCA@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <20160229202327.GA29289@roeckx.be>

Which compiler and version are you using?


Kurt

On Mon, Feb 29, 2016 at 08:12:10PM +0000, Nounou Dadoun wrote:
> For the record, I added no-asm to the config options and got exactly the same result on the sha512t test.  Open to other suggestions ... N
> 
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> 
> Office: 604.629.5182 ext 2632 
> Support: 888.281.5182 ?|? avigilon.com
> Follow?Twitter ?|? Follow?LinkedIn
> 
> 
> This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide.
> 
> 
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun
> Sent: Monday, February 29, 2016 11:39 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature
> 
> Back in the office today - the sha1 and sha256 tests passed but the sha512 failed immediately as below.
> 
> # ./sha1test
> test 1 ok
> test 2 ok
> test 3 ok
> # ./sha256t
> Testing SHA-256 ... passed.
> Testing SHA-224 ... passed.
> # ./sha512t
> Testing SHA-512
> TEST 1 of 3 failed.
> #
> 
> Took a quick look at the code and it looks pretty straightforward, do you have a version you'd like me to run that dumps the result over and above doing a straight memcmp (funny that it doesn't do that anyway on failure) or just let me know what you'd like dumped and what format you'd like it in.  And maybe remove the returns so it goes through all the tests?  
> 
> Happy to help root cause this issue if I can.
> 
> Haven't tried the no-asm option yet, I might try that next.
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> Office: 604.629.5182 ext 2632 
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Dr. Stephen Henson
> Sent: Sunday, February 28, 2016 4:58 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature
> 
> On Sun, Feb 28, 2016, Nounou Dadoun wrote:
> 
> > 
> > We're cross-compiling on a linux x86 vm, does "make test" produce something that I can run on the target?
> 
> "make test" wont be very useful then. The binary test/sha512t you can copy to the target and run it. I'd be interested in the output.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 

From nounou.dadoun at avigilon.com  Mon Feb 29 20:31:03 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Mon, 29 Feb 2016 20:31:03 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <20160229202327.GA29289@roeckx.be>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
 <20160228012421.GA19697@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E17BE1@mbx027-w1-ca-4.exch027.domain.local>
 <20160228125750.GA29658@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E18DB3@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18DCA@mbx027-w1-ca-4.exch027.domain.local>
 <20160229202327.GA29289@roeckx.be>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E18DED@mbx027-w1-ca-4.exch027.domain.local>

It's arm-linux-gnueabihf-4.9.1

... N

Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Kurt Roeckx
Sent: Monday, February 29, 2016 12:23 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

Which compiler and version are you using?

Kurt

On Mon, Feb 29, 2016 at 08:12:10PM +0000, Nounou Dadoun wrote:
> For the record, I added no-asm to the config options and got exactly 
> the same result on the sha512t test.  Open to other suggestions ... N
> 
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> 
> Office: 604.629.5182 ext 2632
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> Behalf Of Nounou Dadoun
> Sent: Monday, February 29, 2016 11:39 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake 
> with error 67702888--bad signature
> 
> Back in the office today - the sha1 and sha256 tests passed but the sha512 failed immediately as below.
> 
> # ./sha1test
> test 1 ok
> test 2 ok
> test 3 ok
> # ./sha256t
> Testing SHA-256 ... passed.
> Testing SHA-224 ... passed.
> # ./sha512t
> Testing SHA-512
> TEST 1 of 3 failed.
> #
> 
> Took a quick look at the code and it looks pretty straightforward, do you have a version you'd like me to run that dumps the result over and above doing a straight memcmp (funny that it doesn't do that anyway on failure) or just let me know what you'd like dumped and what format you'd like it in.  And maybe remove the returns so it goes through all the tests?  
> 
> Happy to help root cause this issue if I can.
> 
> Haven't tried the no-asm option yet, I might try that next.
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> Office: 604.629.5182 ext 2632
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> Behalf Of Dr. Stephen Henson
> Sent: Sunday, February 28, 2016 4:58 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake 
> with error 67702888--bad signature
> 
> On Sun, Feb 28, 2016, Nounou Dadoun wrote:
> 
> > 
> > We're cross-compiling on a linux x86 vm, does "make test" produce something that I can run on the target?
> 
> "make test" wont be very useful then. The binary test/sha512t you can copy to the target and run it. I'd be interested in the output.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org

From nounou.dadoun at avigilon.com  Mon Feb 29 20:41:26 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Mon, 29 Feb 2016 20:41:26 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E18DED@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
 <20160228012421.GA19697@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E17BE1@mbx027-w1-ca-4.exch027.domain.local>
 <20160228125750.GA29658@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E18DB3@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18DCA@mbx027-w1-ca-4.exch027.domain.local>
 <20160229202327.GA29289@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18DED@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E18E02@mbx027-w1-ca-4.exch027.domain.local>

Sorry, that may be the name of one of the associated libraries, in any event it's a Linaro arm toolchain version 4.9.1 running on a linux x-64 vm ... N


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun
Sent: Monday, February 29, 2016 12:31 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

It's arm-linux-gnueabihf-4.9.1

... N

Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Kurt Roeckx
Sent: Monday, February 29, 2016 12:23 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

Which compiler and version are you using?

Kurt

On Mon, Feb 29, 2016 at 08:12:10PM +0000, Nounou Dadoun wrote:
> For the record, I added no-asm to the config options and got exactly 
> the same result on the sha512t test.  Open to other suggestions ... N
> 
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> 
> Office: 604.629.5182 ext 2632
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> Behalf Of Nounou Dadoun
> Sent: Monday, February 29, 2016 11:39 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake 
> with error 67702888--bad signature
> 
> Back in the office today - the sha1 and sha256 tests passed but the sha512 failed immediately as below.
> 
> # ./sha1test
> test 1 ok
> test 2 ok
> test 3 ok
> # ./sha256t
> Testing SHA-256 ... passed.
> Testing SHA-224 ... passed.
> # ./sha512t
> Testing SHA-512
> TEST 1 of 3 failed.
> #
> 
> Took a quick look at the code and it looks pretty straightforward, do you have a version you'd like me to run that dumps the result over and above doing a straight memcmp (funny that it doesn't do that anyway on failure) or just let me know what you'd like dumped and what format you'd like it in.  And maybe remove the returns so it goes through all the tests?  
> 
> Happy to help root cause this issue if I can.
> 
> Haven't tried the no-asm option yet, I might try that next.
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> Office: 604.629.5182 ext 2632
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> Behalf Of Dr. Stephen Henson
> Sent: Sunday, February 28, 2016 4:58 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake 
> with error 67702888--bad signature
> 
> On Sun, Feb 28, 2016, Nounou Dadoun wrote:
> 
> > 
> > We're cross-compiling on a linux x86 vm, does "make test" produce something that I can run on the target?
> 
> "make test" wont be very useful then. The binary test/sha512t you can copy to the target and run it. I'd be interested in the output.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From nounou.dadoun at avigilon.com  Mon Feb 29 20:55:34 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Mon, 29 Feb 2016 20:55:34 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E18E02@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
 <20160228012421.GA19697@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E17BE1@mbx027-w1-ca-4.exch027.domain.local>
 <20160228125750.GA29658@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E18DB3@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18DCA@mbx027-w1-ca-4.exch027.domain.local>
 <20160229202327.GA29289@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18DED@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E02@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E18E46@mbx027-w1-ca-4.exch027.domain.local>

And I should add a reminder that the negotiated cipher that's failing is actually TLS_RSA_WITH_AES_256_CBC_SHA256

Which does seem a little odd with sha256t passing and sha512t failing ... N


Nou Dadoun
Senior Firmware Developer, Security Specialist

Office: 604.629.5182 ext 2632 

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun
Sent: Monday, February 29, 2016 12:41 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

Sorry, that may be the name of one of the associated libraries, in any event it's a Linaro arm toolchain version 4.9.1 running on a linux x-64 vm ... N


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun
Sent: Monday, February 29, 2016 12:31 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

It's arm-linux-gnueabihf-4.9.1

... N

Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Kurt Roeckx
Sent: Monday, February 29, 2016 12:23 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

Which compiler and version are you using?

Kurt

On Mon, Feb 29, 2016 at 08:12:10PM +0000, Nounou Dadoun wrote:
> For the record, I added no-asm to the config options and got exactly 
> the same result on the sha512t test.  Open to other suggestions ... N
> 
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> 
> Office: 604.629.5182 ext 2632
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> Behalf Of Nounou Dadoun
> Sent: Monday, February 29, 2016 11:39 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake 
> with error 67702888--bad signature
> 
> Back in the office today - the sha1 and sha256 tests passed but the sha512 failed immediately as below.
> 
> # ./sha1test
> test 1 ok
> test 2 ok
> test 3 ok
> # ./sha256t
> Testing SHA-256 ... passed.
> Testing SHA-224 ... passed.
> # ./sha512t
> Testing SHA-512
> TEST 1 of 3 failed.
> #
> 
> Took a quick look at the code and it looks pretty straightforward, do you have a version you'd like me to run that dumps the result over and above doing a straight memcmp (funny that it doesn't do that anyway on failure) or just let me know what you'd like dumped and what format you'd like it in.  And maybe remove the returns so it goes through all the tests?  
> 
> Happy to help root cause this issue if I can.
> 
> Haven't tried the no-asm option yet, I might try that next.
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> Office: 604.629.5182 ext 2632
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> Behalf Of Dr. Stephen Henson
> Sent: Sunday, February 28, 2016 4:58 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake 
> with error 67702888--bad signature
> 
> On Sun, Feb 28, 2016, Nounou Dadoun wrote:
> 
> > 
> > We're cross-compiling on a linux x86 vm, does "make test" produce something that I can run on the target?
> 
> "make test" wont be very useful then. The binary test/sha512t you can copy to the target and run it. I'd be interested in the output.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From openssl-users at dukhovni.org  Mon Feb 29 21:30:13 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 29 Feb 2016 16:30:13 -0500
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
	error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E18E46@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local>
 <20160226230607.GA21238@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E161C9@mbx027-w1-ca-4.exch027.domain.local>
 <20160227182343.GA9223@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
 <20160228012421.GA19697@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E17BE1@mbx027-w1-ca-4.exch027.domain.local>
 <20160228125750.GA29658@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E18DB3@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18DCA@mbx027-w1-ca-4.exch027.domain.local>
 <20160229202327.GA29289@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18DED@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E02@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E46@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <037593B6-483E-4D97-BD39-6E8BDC236D10@dukhovni.org>


> On Feb 29, 2016, at 3:55 PM, Nounou Dadoun <nounou.dadoun at avigilon.com> wrote:
> 
> And I should add a reminder that the negotiated cipher that's failing is actually TLS_RSA_WITH_AES_256_CBC_SHA256
> 
> Which does seem a little odd with sha256t passing and sha512t failing ... N

There are no SHA512 TLS ciphersuites, and yet SHA512 can be used with TLS!
This is because it is used to sign handshake protocol messages, not the
encrypted traffic that follows.

The signature algorithm negotation in TLS 1.2 is separate from cipher selection.

-- 
	Viktor.


From kurt at roeckx.be  Mon Feb 29 21:35:05 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 29 Feb 2016 22:35:05 +0100
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E18E46@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
 <20160228012421.GA19697@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E17BE1@mbx027-w1-ca-4.exch027.domain.local>
 <20160228125750.GA29658@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E18DB3@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18DCA@mbx027-w1-ca-4.exch027.domain.local>
 <20160229202327.GA29289@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18DED@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E02@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E46@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <20160229213505.GA4202@roeckx.be>

The cipher is using SHA256, there is also a signature using SHA512
for the verification of the client certificate.  I think we've
already pointed out how to disable that.


Kurt

On Mon, Feb 29, 2016 at 08:55:34PM +0000, Nounou Dadoun wrote:
> And I should add a reminder that the negotiated cipher that's failing is actually TLS_RSA_WITH_AES_256_CBC_SHA256
> 
> Which does seem a little odd with sha256t passing and sha512t failing ... N
> 
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> Office: 604.629.5182 ext 2632 
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun
> Sent: Monday, February 29, 2016 12:41 PM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature
> 
> Sorry, that may be the name of one of the associated libraries, in any event it's a Linaro arm toolchain version 4.9.1 running on a linux x-64 vm ... N
> 
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun
> Sent: Monday, February 29, 2016 12:31 PM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature
> 
> It's arm-linux-gnueabihf-4.9.1
> 
> ... N
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> 
> Office: 604.629.5182 ext 2632 
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Kurt Roeckx
> Sent: Monday, February 29, 2016 12:23 PM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature
> 
> Which compiler and version are you using?
> 
> Kurt
> 
> On Mon, Feb 29, 2016 at 08:12:10PM +0000, Nounou Dadoun wrote:
> > For the record, I added no-asm to the config options and got exactly 
> > the same result on the sha512t test.  Open to other suggestions ... N
> > 
> > 
> > Nou Dadoun
> > Senior Firmware Developer, Security Specialist
> > 
> > 
> > Office: 604.629.5182 ext 2632
> > 
> > -----Original Message-----
> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> > Behalf Of Nounou Dadoun
> > Sent: Monday, February 29, 2016 11:39 AM
> > To: openssl-users at openssl.org
> > Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake 
> > with error 67702888--bad signature
> > 
> > Back in the office today - the sha1 and sha256 tests passed but the sha512 failed immediately as below.
> > 
> > # ./sha1test
> > test 1 ok
> > test 2 ok
> > test 3 ok
> > # ./sha256t
> > Testing SHA-256 ... passed.
> > Testing SHA-224 ... passed.
> > # ./sha512t
> > Testing SHA-512
> > TEST 1 of 3 failed.
> > #
> > 
> > Took a quick look at the code and it looks pretty straightforward, do you have a version you'd like me to run that dumps the result over and above doing a straight memcmp (funny that it doesn't do that anyway on failure) or just let me know what you'd like dumped and what format you'd like it in.  And maybe remove the returns so it goes through all the tests?  
> > 
> > Happy to help root cause this issue if I can.
> > 
> > Haven't tried the no-asm option yet, I might try that next.
> > 
> > Nou Dadoun
> > Senior Firmware Developer, Security Specialist
> > 
> > Office: 604.629.5182 ext 2632
> > 
> > -----Original Message-----
> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> > Behalf Of Dr. Stephen Henson
> > Sent: Sunday, February 28, 2016 4:58 AM
> > To: openssl-users at openssl.org
> > Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake 
> > with error 67702888--bad signature
> > 
> > On Sun, Feb 28, 2016, Nounou Dadoun wrote:
> > 
> > > 
> > > We're cross-compiling on a linux x86 vm, does "make test" produce something that I can run on the target?
> > 
> > "make test" wont be very useful then. The binary test/sha512t you can copy to the target and run it. I'd be interested in the output.
> > 
> > Steve.
> > --
> > Dr Stephen N. Henson. OpenSSL project core developer.
> > Commercial tech support now available see: http://www.openssl.org
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 

From nounou.dadoun at avigilon.com  Mon Feb 29 21:40:42 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Mon, 29 Feb 2016 21:40:42 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <20160229213505.GA4202@roeckx.be>
References: <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
 <20160228012421.GA19697@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E17BE1@mbx027-w1-ca-4.exch027.domain.local>
 <20160228125750.GA29658@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E18DB3@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18DCA@mbx027-w1-ca-4.exch027.domain.local>
 <20160229202327.GA29289@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18DED@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E02@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E46@mbx027-w1-ca-4.exch027.domain.local>
 <20160229213505.GA4202@roeckx.be>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E18E6D@mbx027-w1-ca-4.exch027.domain.local>

Ah, thanks Viktor and Kurt for the clarification, I didn't get that distinction/connection - I'll try that next ... N

Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Kurt Roeckx
Sent: Monday, February 29, 2016 1:35 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

The cipher is using SHA256, there is also a signature using SHA512 for the verification of the client certificate.  I think we've already pointed out how to disable that.


Kurt

On Mon, Feb 29, 2016 at 08:55:34PM +0000, Nounou Dadoun wrote:
> And I should add a reminder that the negotiated cipher that's failing 
> is actually TLS_RSA_WITH_AES_256_CBC_SHA256
> 
> Which does seem a little odd with sha256t passing and sha512t failing 
> ... N
> 
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> Office: 604.629.5182 ext 2632
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> Behalf Of Nounou Dadoun
> Sent: Monday, February 29, 2016 12:41 PM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake 
> with error 67702888--bad signature
> 
> Sorry, that may be the name of one of the associated libraries, in any 
> event it's a Linaro arm toolchain version 4.9.1 running on a linux 
> x-64 vm ... N
> 
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> Behalf Of Nounou Dadoun
> Sent: Monday, February 29, 2016 12:31 PM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake 
> with error 67702888--bad signature
> 
> It's arm-linux-gnueabihf-4.9.1
> 
> ... N
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> 
> Office: 604.629.5182 ext 2632
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> Behalf Of Kurt Roeckx
> Sent: Monday, February 29, 2016 12:23 PM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake 
> with error 67702888--bad signature
> 
> Which compiler and version are you using?
> 
> Kurt
> 
> On Mon, Feb 29, 2016 at 08:12:10PM +0000, Nounou Dadoun wrote:
> > For the record, I added no-asm to the config options and got exactly 
> > the same result on the sha512t test.  Open to other suggestions ... 
> > N
> > 
> > 
> > Nou Dadoun
> > Senior Firmware Developer, Security Specialist
> > 
> > 
> > Office: 604.629.5182 ext 2632
> > 
> > -----Original Message-----
> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> > Behalf Of Nounou Dadoun
> > Sent: Monday, February 29, 2016 11:39 AM
> > To: openssl-users at openssl.org
> > Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake 
> > with error 67702888--bad signature
> > 
> > Back in the office today - the sha1 and sha256 tests passed but the sha512 failed immediately as below.
> > 
> > # ./sha1test
> > test 1 ok
> > test 2 ok
> > test 3 ok
> > # ./sha256t
> > Testing SHA-256 ... passed.
> > Testing SHA-224 ... passed.
> > # ./sha512t
> > Testing SHA-512
> > TEST 1 of 3 failed.
> > #
> > 
> > Took a quick look at the code and it looks pretty straightforward, do you have a version you'd like me to run that dumps the result over and above doing a straight memcmp (funny that it doesn't do that anyway on failure) or just let me know what you'd like dumped and what format you'd like it in.  And maybe remove the returns so it goes through all the tests?  
> > 
> > Happy to help root cause this issue if I can.
> > 
> > Haven't tried the no-asm option yet, I might try that next.
> > 
> > Nou Dadoun
> > Senior Firmware Developer, Security Specialist
> > 
> > Office: 604.629.5182 ext 2632
> > 
> > -----Original Message-----
> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> > Behalf Of Dr. Stephen Henson
> > Sent: Sunday, February 28, 2016 4:58 AM
> > To: openssl-users at openssl.org
> > Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake 
> > with error 67702888--bad signature
> > 
> > On Sun, Feb 28, 2016, Nounou Dadoun wrote:
> > 
> > > 
> > > We're cross-compiling on a linux x86 vm, does "make test" produce something that I can run on the target?
> > 
> > "make test" wont be very useful then. The binary test/sha512t you can copy to the target and run it. I'd be interested in the output.
> > 
> > Steve.
> > --
> > Dr Stephen N. Henson. OpenSSL project core developer.
> > Commercial tech support now available see: http://www.openssl.org

From nounou.dadoun at avigilon.com  Mon Feb 29 22:48:22 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Mon, 29 Feb 2016 22:48:22 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E18E6D@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E16AC2@mbx027-w1-ca-4.exch027.domain.local>
 <20160228012421.GA19697@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E17BE1@mbx027-w1-ca-4.exch027.domain.local>
 <20160228125750.GA29658@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E18DB3@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18DCA@mbx027-w1-ca-4.exch027.domain.local>
 <20160229202327.GA29289@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18DED@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E02@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E46@mbx027-w1-ca-4.exch027.domain.local>
 <20160229213505.GA4202@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18E6D@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E18EB2@mbx027-w1-ca-4.exch027.domain.local>

That worked!  The addition of (boost-speak)

		SSL_CTX_set1_client_sigalgs_list(
			GetNativeRef().impl(),
			"RSA+SHA256");

completed the handshake and got everything going again.  Thanks for all your assistance.

But this demonstrates that my headaches have been coming from the fact that sha384 and sha512 are broken in our build somehow.  The no-asm configure directive didn't make a difference so maybe a compiler bug or something?

Still happy to provide traces or diagnostics if anyone there wants to try to track down the issue, just let me know, thanks again ... N

Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun
Sent: Monday, February 29, 2016 1:41 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

Ah, thanks Viktor and Kurt for the clarification, I didn't get that distinction/connection - I'll try that next ... N

Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Kurt Roeckx
Sent: Monday, February 29, 2016 1:35 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

The cipher is using SHA256, there is also a signature using SHA512 for the verification of the client certificate.  I think we've already pointed out how to disable that.


Kurt


From uri at ll.mit.edu  Mon Feb 29 22:51:52 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Mon, 29 Feb 2016 22:51:52 +0000
Subject: [openssl-users] How to properly use ui_method in
	ENGINE_load_private_key()?
Message-ID: <D2FA35B4.2488C%uri@ll.mit.edu>

I am writing an app that needs to use RSA keys on a PKCS11-accessible
token to encrypt and decrypt symmetric keys. For the context (no pun
intended :) think of creating or mounting an existing encrypted file
system.

To begin with, and to grasp the finer details of the programmatic
interface of libcrypto, I?m ?sculpting? my code after apps/pkeyutl.c and
apps/apps.c.

When I use ?init_ctx()? that in turn calls ?load_key()? method in ?apps.o?
(and link my code with ?apps.o? in addition to ?-lcrypto?), everything
works fine:

We expect an RSA token for this demo...
Input buffer:
01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10
10 0f 0e 0d 0c 0b 0a 09 08 07 06 05 04 03 02 01

encrypt: allocating 256 bytes (rv=1)
RSA encryption succeeded (rv=1 len=256):
10 e5 a6 95 63 48 54 3f e2 84 7f 9c 39 6f 8c cd
9a ef 18 3b 66 32 46 bf 9f d4 76 91 ce 98 5d 33
cd a7 cf 4e b7 d5 98 51 2d e3 8e 4f 09 52 1d 0f
.. .. .. .. .. .. .. .. .. ..
fc 46 db 1d 8e 1d 7e 7e a4 a1 e3 c8 60 43 28 26
ef c4 84 d2 0d cf 92 61 75 bc 0c d9 47 b1 bb 9e
78 00 32 b8 4b 35 c2 08 ad f6 f7 f8 bf e1 13 b1
PKCS#11 token PIN: xxxxxxxx

decrypt: allocating 256 bytes (rv=1)
RSA decryption succeeded (rv=1 len=32):
01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10
10 0f 0e 0d 0c 0b 0a 09 08 07 06 05 04 03 02 01

However when I try to call the EVP methods directly instead of going
through the routines provided in apps.c, the decryption fails:

??

Encrypted symmetric key (256 bytes):
76 f8 e9 b0 38 45 b5 fd b4 8e 96 f9 8a 86 ab 5a
83 42 a4 b8 7e 06 e0 b7 ae 8c 7f 6c 5e 68 bd eb
bf 3f 87 0c f8 0e 90 8f cd ec 01 f7 80 a8 71 00
3d 7a 5d 30 db 7f 7b 18 e2 de c0 c2 9e 07 ca 1f
.. .. .. .. .. .. .. .. .. ..

f2 c5 4b 0e 1d c7 57 3b 9f f4 a3 55 09 37 1a 47
68 0c e4 fc 86 1e d0 cc 3d 4d d7 25 7c 40 77 ba
74 a5 ce 60 03 ea d4 54 a2 58 52 b5 aa bf 4a d2

PKCS#11 token PIN: xxxxxxxx

unwrap: loaded privkey of size 256
unwrap: allocating 256 bytes...
unwrap: decrypt returned 1 (0 bytes)
unwrapping returned 1
Decrypted symmetric key (0 bytes):

You can see that up to the actual loading of the private key things are
the same, and both variants of the app (the one using apps.c, and the one
trying to directly call the EVP API) show the same prompt for the token
PIN, and in both cases it appears (though I?m not sure at all of that)
that the private key handle gets loaded.

The opens-debug.log file shows that there was a problem with the
authentication to the token:

 [opensc-pkcs11] card-piv.c:2221:piv_set_security_env: called
 [opensc-pkcs11] card-piv.c:2252:piv_set_security_env: returning with: 0
(Success)
 [opensc-pkcs11] sec.c:72:sc_set_security_env: returning with: 0 (Success)
 [opensc-pkcs11] card-piv.c:2417:piv_decipher: called
 [opensc-pkcs11] card-piv.c:2281:piv_validate_general_authentication:
called
 [opensc-pkcs11] card-piv.c:2310:piv_validate_general_authentication:
returning with: -1208 (Card does not support the requested operation)
 [opensc-pkcs11] card-piv.c:2419:piv_decipher: returning with: -1208 (Card
does not support the requested operation)
 [opensc-pkcs11] sec.c:44:sc_decipher: returning with: -1208 (Card does
not support the requested operation)


This differs from what the log shows when the private key was loaded with
?load_key()?:
...
 [opensc-pkcs11] sec.c:206:sc_pin_cmd: returning with: 0 (Success)
 [opensc-pkcs11] sec.c:206:sc_pin_cmd: returning with: 0 (Success)
 [opensc-pkcs11] card-piv.c:2221:piv_set_security_env: called
 [opensc-pkcs11] card-piv.c:2252:piv_set_security_env: returning with: 0
(Success)
 [opensc-pkcs11] sec.c:72:sc_set_security_env: returning with: 0 (Success)
 [opensc-pkcs11] card-piv.c:2417:piv_decipher: called
 [opensc-pkcs11] card-piv.c:2281:piv_validate_general_authentication:
called
 [opensc-pkcs11] card-piv.c:454:piv_general_io: called
 [opensc-pkcs11] card-piv.c:2419:piv_decipher: returning with: 256
 [opensc-pkcs11] sec.c:44:sc_decipher: returning with: 256
 [opensc-pkcs11] card-piv.c:2819:piv_finish: called
 [opensc-pkcs11] ctx.c:818:sc_release_context: called


Here?s the relevant excerpt from the code that fails:

 /* Retrieve the handle to private key on the token */
 /* Here need to get user PIN somehow ... */
 PW_CB_DATA cb_data;
 cb_data.password = NULL;
 cb_data.prompt_info = "id_03";
 privkey = ENGINE_load_private_key(*e, "id_03", NULL, &cb_data);
 if (privkey == NULL) {
   fprintf(stderr, "unwrap: failed to get handle to privkey id_03\n");
   goto end;
 }
 printf("unwrap: loaded privkey of size %1d\n", EVP_PKEY_size(privkey));

 /* Create context */
 ctx = EVP_PKEY_CTX_new(privkey, NULL);
 EVP_PKEY_free(privkey);
 if (ctx == NULL) {
   fprintf(stderr, "unwrap: failed to create context\n");
   goto end;
 }
 rv = EVP_PKEY_decrypt_init(ctx);
 EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING);
 if (rv <= 0) {
   fprintf(stderr, "unwrap: failed to initialize decrypt_ctx (rv=%d\n",
rv);
   goto end;
 }

 /* Unwrap the encrypted key */
 *olen = 0;
 rv = EVP_PKEY_decrypt(ctx, NULL, olen, in, inlen);
 if ((rv <= 0) || (*olen == 0)) {
   fprintf(stderr, "unwrap: failed to get required output buf len
(rv=%d)\n", rv);
   goto end;
 }
 printf("unwrap: allocating %1lu bytes...\n", *olen);
 *out = OPENSSL_malloc(*olen);
 if (*out == NULL) {
   fprintf(stderr, "unwrap: failed to allocate output buf (%1lu bytes)\n",
*olen);
   rv = -1;
   goto end;
 }
 rv = EVP_PKEY_decrypt(ctx, *out, olen, in, inlen);
 if (rv <= 0) {
   OPENSSL_free(*out);
   fprintf(stderr, "unwrap: failed to decrypt (rv=%d)\n", rv);
   goto end;
 }
 printf("unwrap: decrypt returned %d (%1lu bytes)\n", rv, *olen);


I tried, but could not figure out from looking at ?apps.c? what structures
and methods I need to pass to ?ENGINE_load_private_key()?, and how to
properly initialize them. Web searches did not help.

I?d appreciate guidance, as I?d rather not pull the entire ?apps.c? into
the app I?m building, it it can be avoided.

Thanks!
--
Regards,
Uri Blumenthal


From kurt at roeckx.be  Mon Feb 29 23:47:00 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 1 Mar 2016 00:47:00 +0100
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E18EB2@mbx027-w1-ca-4.exch027.domain.local>
References: <20160228125750.GA29658@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E18DB3@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18DCA@mbx027-w1-ca-4.exch027.domain.local>
 <20160229202327.GA29289@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18DED@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E02@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E46@mbx027-w1-ca-4.exch027.domain.local>
 <20160229213505.GA4202@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18E6D@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18EB2@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <20160229234659.GA7477@roeckx.be>

On Mon, Feb 29, 2016 at 10:48:22PM +0000, Nounou Dadoun wrote:
> But this demonstrates that my headaches have been coming from the fact that sha384 and sha512 are broken in our build somehow.  The no-asm configure directive didn't make a difference so maybe a compiler bug or something?

I'm assuming you build using -O3.  Can you try different levels?
I don't know of any problems on Debian using -O2.

From uri at ll.mit.edu  Sun Feb 28 22:31:39 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Sun, 28 Feb 2016 22:31:39 +0000
Subject: [openssl-users] How to properly use ui_method in
	ENGINE_load_private_key()?
Message-ID: <D2F8DFA4.24720%uri@ll.mit.edu>

I am writing an app that needs to use RSA keys on a PKCS11-accessible token to encrypt and decrypt symmetric keys. For the context (no pun intended :) think of creating or mounting an existing encrypted file system.

To begin with, and to grasp the finer details of the programmatic interface of libcrypto, I?m ?sculpting? my code after apps/pkeyutl.c and apps/apps.c.

When I use ?init_cx()? that in turn calls ?load_key()? method in ?apps.o? (and link my code with ?apps.o? in addition to ?-lcrypto?), everything works fine:

We expect an RSA token for this demo...
Input buffer:
01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10
10 0f 0e 0d 0c 0b 0a 09 08 07 06 05 04 03 02 01

encrypt: allocating 256 bytes (rv=1)
RSA encryption succeeded (rv=1 len=256):
10 e5 a6 95 63 48 54 3f e2 84 7f 9c 39 6f 8c cd
9a ef 18 3b 66 32 46 bf 9f d4 76 91 ce 98 5d 33
cd a7 cf 4e b7 d5 98 51 2d e3 8e 4f 09 52 1d 0f
fa 3f 33 5c d9 d3 3b 2f a4 4f 87 17 73 09 c0 23
c7 56 40 ce 5f 3f 61 b1 b7 94 43 98 9f d0 cc c0
cd 38 e2 94 c4 64 a0 8f 3d fe e4 03 18 5f 83 9d
da 04 42 3a f3 ad c1 3b 0c f3 60 f9 f8 c8 bc 95
83 2f 67 9b b7 3a 38 fe 79 66 30 80 7f 17 00 31
71 ee 2e c6 cd 7b 09 f3 09 eb c0 bd 45 4b 88 a9
36 23 87 71 a0 12 78 ba c5 34 be 8e ca c4 07 73
cd ea a9 90 c2 bf 31 aa ee ba 49 18 74 2e 9b 8c
97 94 cb 11 5e cd fc 24 e5 84 e4 9f 17 5a ac 2b
6d a5 61 bf 5d 3e 00 49 99 b0 90 32 33 02 42 ac
fc 46 db 1d 8e 1d 7e 7e a4 a1 e3 c8 60 43 28 26
ef c4 84 d2 0d cf 92 61 75 bc 0c d9 47 b1 bb 9e
78 00 32 b8 4b 35 c2 08 ad f6 f7 f8 bf e1 13 b1
PKCS#11 token PIN: xxxxxxxx

decrypt: allocating 256 bytes (rv=1)
RSA decryption succeeded (rv=1 len=32):
01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10
10 0f 0e 0d 0c 0b 0a 09 08 07 06 05 04 03 02 01

However when I try to call the EVP methods directly instead of going through the routines provided in apps.c, the decryption fails:

??

Encrypted symmetric key (256 bytes):
76 f8 e9 b0 38 45 b5 fd b4 8e 96 f9 8a 86 ab 5a
83 42 a4 b8 7e 06 e0 b7 ae 8c 7f 6c 5e 68 bd eb
bf 3f 87 0c f8 0e 90 8f cd ec 01 f7 80 a8 71 00
3d 7a 5d 30 db 7f 7b 18 e2 de c0 c2 9e 07 ca 1f
6c 9e dc 13 82 19 cd 49 7a fc 2c f0 52 ad 74 4a
da f5 e5 71 50 d3 f9 e6 fc eb 67 6c 82 fa 00 e6
8f 2f 0a a0 9d c7 a6 85 5f 8e 93 07 53 9c e5 b3
23 9b fe 36 88 e5 7f f4 cf 81 13 dc 58 de e6 e1
d5 fe bf 5b db 5d a1 63 29 3e 96 13 d2 1a b6 b2
1f 95 73 90 97 86 ce e3 de 08 8d bc a3 11 9f 04
f5 f4 8d 8f 32 29 2c 91 74 0f 85 ab 75 3a c3 58
3e e9 30 48 f2 ae 67 08 f7 14 ce 0c 73 50 3b d4
94 aa 15 a3 79 e1 5b 27 a4 80 b9 71 53 5b 46 13
f2 c5 4b 0e 1d c7 57 3b 9f f4 a3 55 09 37 1a 47
68 0c e4 fc 86 1e d0 cc 3d 4d d7 25 7c 40 77 ba
74 a5 ce 60 03 ea d4 54 a2 58 52 b5 aa bf 4a d2

PKCS#11 token PIN: xxxxxxxx

unwrap: loaded privkey of size 256
unwrap: allocating 256 bytes...
unwrap: decrypt returned 1 (0 bytes)
unwrapping returned 1
Decrypted symmetric key (0 bytes):

You can see that up to the actual loading of the private key things are the same, and both variants of the app (the one using apps.c, and the one trying to directly call the EVP API) show the same prompt for the token PIN, and in both cases it appears (though I?m not sure at all of that) that the private key handle gets loaded.

The opens-debug.log file shows that there was a problem with the authentication to the token:

0x7fff739f3000 16:10:25.4294968080 [opensc-pkcs11] card-piv.c:2310:piv_validate_general_authentication: returning with: -1208 (Card does not support the requested operation)
0x7fff739f3000 16:10:25.784 [opensc-pkcs11] card-piv.c:2419:piv_decipher: returning with: -1208 (Card does not support the requested operation)
0x7fff739f3000 16:10:25.784 [opensc-pkcs11] sec.c:44:sc_decipher: returning with: -1208 (Card does not support the requested operation)
0x7fff739f3000 16:10:25.784 [opensc-pkcs11] card-piv.c:2221:piv_set_security_env: called
0x7fff739f3000 16:10:25.784 [opensc-pkcs11] card-piv.c:2252:piv_set_security_env: returning with: 0 (Success)
0x7fff739f3000 16:10:25.140552804762384 [opensc-pkcs11] sec.c:72:sc_set_security_env: returning with: 0 (Success)
0x7fff739f3000 16:10:25.784 [opensc-pkcs11] card-piv.c:2417:piv_decipher: called
0x7fff739f3000 16:10:25.4294968080 [opensc-pkcs11] card-piv.c:2281:piv_validate_general_authentication: called
0x7fff739f3000 16:10:25.4294968080 [opensc-pkcs11] card-piv.c:2310:piv_validate_general_authentication: returning with: -1208 (Card does not support the requested operation)
0x7fff739f3000 16:10:25.784 [opensc-pkcs11] card-piv.c:2419:piv_decipher: returning with: -1208 (Card does not support the requested operation)
0x7fff739f3000 16:10:25.784 [opensc-pkcs11] sec.c:44:sc_decipher: returning with: -1208 (Card does not support the requested operation)

This differs from what the log shows when the private key was loaded with ?load_key()?:

0x7fff739f3000 16:12:35.132 [opensc-pkcs11] reader-pcsc.c:313:refresh_attributes: returning with: 0 (Success)
0x7fff739f3000 16:12:35.140733193388164 [opensc-pkcs11] reader-pcsc.c:389:pcsc_detect_card_presence: returning with: 5
0x7fff739f3000 16:12:35.4294967435 [opensc-pkcs11] sec.c:206:sc_pin_cmd: returning with: 0 (Success)
0x7fff739f3000 16:12:37.939 [opensc-pkcs11] sec.c:206:sc_pin_cmd: returning with: 0 (Success)
0x7fff739f3000 16:12:37.940 [opensc-pkcs11] card-piv.c:2221:piv_set_security_env: called
0x7fff739f3000 16:12:37.940 [opensc-pkcs11] card-piv.c:2252:piv_set_security_env: returning with: 0 (Success)
0x7fff739f3000 16:12:37.140295106724780 [opensc-pkcs11] sec.c:72:sc_set_security_env: returning with: 0 (Success)
0x7fff739f3000 16:12:37.940 [opensc-pkcs11] card-piv.c:2417:piv_decipher: called
0x7fff739f3000 16:12:37.140733193388972 [opensc-pkcs11] card-piv.c:2281:piv_validate_general_authentication: called
0x7fff739f3000 16:12:37.4294968236 [opensc-pkcs11] card-piv.c:454:piv_general_io: called
0x7fff739f3000 16:12:38.608 [opensc-pkcs11] card-piv.c:2419:piv_decipher: returning with: 256
0x7fff739f3000 16:12:38.608 [opensc-pkcs11] sec.c:44:sc_decipher: returning with: 256
0x7fff739f3000 16:12:38.609 [opensc-pkcs11] card-piv.c:2819:piv_finish: called
0x7fff739f3000 16:12:38.140295106724457 [opensc-pkcs11] ctx.c:818:sc_release_context: called

Here?s the relevant excerpt from the code that fails:

/* Retrieve the handle to private key on the token */
/* Here need to get user PIN somehow ... */
PW_CB_DATA cb_data;
cb_data.password = NULL;
cb_data.prompt_info = "id_03";
privkey = ENGINE_load_private_key(*e, "id_03", NULL, &cb_data);
if (privkey == NULL) {
fprintf(stderr, "unwrap: failed to get handle to privkey id_03\n");
goto end;
}
printf("unwrap: loaded privkey of size %1d\n", EVP_PKEY_size(privkey));

/* Create context */
ctx = EVP_PKEY_CTX_new(privkey, NULL);
EVP_PKEY_free(privkey);
if (ctx == NULL) {
fprintf(stderr, "unwrap: failed to create context\n");
goto end;
}
rv = EVP_PKEY_decrypt_init(ctx);
EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING);
if (rv <= 0) {
fprintf(stderr, "unwrap: failed to initialize decrypt_ctx (rv=%d\n", rv);
goto end;
}

/* Unwrap the encrypted key */
*olen = 0;
rv = EVP_PKEY_decrypt(ctx, NULL, olen, in, inlen);
if ((rv <= 0) || (*olen == 0)) {
fprintf(stderr, "unwrap: failed to get required output buf len (rv=%d)\n", rv);
goto end;
}
printf("unwrap: allocating %1lu bytes...\n", *olen);
*out = OPENSSL_malloc(*olen);
if (*out == NULL) {
fprintf(stderr, "unwrap: failed to allocate output buf (%1lu bytes)\n", *olen);
rv = -1;
goto end;
}
rv = EVP_PKEY_decrypt(ctx, *out, olen, in, inlen);
if (rv <= 0) {
OPENSSL_free(*out);
fprintf(stderr, "unwrap: failed to decrypt (rv=%d)\n", rv);
goto end;
}
printf("unwrap: decrypt returned %d (%1lu bytes)\n", rv, *olen);


I tried, but could not figure out from looking at ?apps.c? what structures and methods I need to pass to ?ENGINE_load_private_key()?, and how to properly initialize them. Web searches did not help.

I?d appreciate guidance, as I?d rather not pull the entire ?apps.c? into the app I?m building, it it can be avoided.

Thanks!
--
Regards,
Uri Blumenthal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160228/d9782b61/attachment-0001.html>

From rhermann at centurioncares.com  Mon Feb 29 14:08:40 2016
From: rhermann at centurioncares.com (Rob Hermann)
Date: Mon, 29 Feb 2016 08:08:40 -0600
Subject: [openssl-users] Building OpenSSL: OpenSSL-Release Permission denied
In-Reply-To: <56D44FC4.1020702@centurioncares.com>
References: <56D44FC4.1020702@centurioncares.com>
Message-ID: <56D450E8.6090101@centurioncares.com>




In my linux-elf environment,   I'm running as su and I have a permission 
denied problem during my build:

[root at rhlinuxdev OpenSSLWork]# ant OpenSSL-Release
Buildfile: build.xml
      [echo] CVIS root: /home/rhermann/artifacts/Lib_Work/CVIS

OpenSSL-config:

OpenSSL-generate:

vsvars32:

OpenSSL-Release:
      [exec] making all in crypto...
      [exec] make[1]: Entering directory 
`/home/rhermann/src/OpenSSLWork/crypto'
      [exec] /usr/bin/perl ../util/mkbuildinf.pl "gcc -I. -I.. 
-I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H 
-Wa,--noexecstack -DL_ENDIAN -O3 -fomit-frame-pointer -Wall 
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM" 
"linux-elf" >buildinf.h
      [exec] making all in crypto/objects...
      [exec] make[2]: Entering directory 
`/home/rhermann/src/OpenSSLWork/crypto/objects'
      [exec] make[2]: Nothing to be done for `all'.
      [exec] make[2]: Leaving directory 
`/home/rhermann/src/OpenSSLWork/crypto/objects'
      [exec] making all in crypto/md4...
      [exec] make[2]: Entering directory 
`/home/rhermann/src/OpenSSLWork/crypto/md4'
      [exec] make[2]: Nothing to be done for `all'.
      [exec] make[2]: Leaving directory 
`/home/rhermann/src/OpenSSLWork/crypto/md4'
      [exec] making all in crypto/md5...

  ..........................   no problems during the build except when 
I get to this point:

     [exec] testing...
      [exec] make[1]: Entering directory 
`/home/rhermann/src/OpenSSLWork/test'
      [exec] make[2]: Entering directory `/home/rhermann/src/OpenSSLWork'
      [exec] making all in apps...
      [exec] make[3]: Entering directory 
`/home/rhermann/src/OpenSSLWork/apps'
      [exec] make[3]: Nothing to be done for `all'.
      [exec] make[3]: Leaving directory 
`/home/rhermann/src/OpenSSLWork/apps'
      [exec] make[2]: Leaving directory `/home/rhermann/src/OpenSSLWork'
      [exec] ../util/shlib_wrap.sh ./destest
      [exec] make[1]: execvp: ../util/shlib_wrap.sh: Permission denied
      [exec] make[1]: *** [test_des] Error 127
      [exec] make[1]: Leaving directory 
`/home/rhermann/src/OpenSSLWork/test'
      [exec] make: *** [tests] Error 2


    the ../util/shlib_wrap.sh script is invoked from many places.   Can 
some tell me what the build is trying to accomplish at this point ?  Is 
it trying to run a unit test ??


-- 
*Rob Hermann *
Senior Software Engineer
Centurion, Inc.
1605 Manhattan Drive
Waukesha, WI 53186

rhermann at centurioncares.com
www.centurioncares.com <http://www.centurioncares.com>

*Confidentiality Statement
* This email and/or any attached files are intended solely for the 
individual or entity to whom they are addressed. If you have received 
this message in error, please notify us by sending a reply email to the 
sender and remove this message and any associated attachments from your 
computer system(s). Unauthorized use, distribution, or disclosure of 
such messages may be a violation of the law. Centurion would like to 
remind you to refrain from sending private or personal information, such 
as account numbers, social security numbers, passwords, or any other 
confidential financial, credit card or business information via email or 
email attachments. For your security, you are encouraged to contact us 
via phone with any sensitive information rather than use email.





-- 
*Rob Hermann *
Senior Software Engineer
Centurion, Inc.
1605 Manhattan Drive
Waukesha, WI 53186
123-456-7890 Direct

rhermann at centurioncares.com
www.centurioncares.com <http://www.centurioncares.com>

*Confidentiality Statement
* This email and/or any attached files are intended solely for the 
individual or entity to whom they are addressed. If you have received 
this message in error, please notify us by sending a reply email to the 
sender and remove this message and any associated attachments from your 
computer system(s). Unauthorized use, distribution, or disclosure of 
such messages may be a violation of the law. Centurion would like to 
remind you to refrain from sending private or personal information, such 
as account numbers, social security numbers, passwords, or any other 
confidential financial, credit card or business information via email or 
email attachments. For your security, you are encouraged to contact us 
via phone with any sensitive information rather than use email.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160229/944ab5d9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 102049 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160229/944ab5d9/attachment-0002.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 102049 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160229/944ab5d9/attachment-0003.jpe>