From reichert at numachi.com  Sun Mar  1 07:56:03 2015
From: reichert at numachi.com (Brian Reichert)
Date: Sun, 1 Mar 2015 02:56:03 -0500
Subject: [openssl-users] has anyone developed a standalone test
	for	CVE-2014-8730?
In-Reply-To: <867253b170bb4cc7a0e76bba5554da5c@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <20150227183128.GC44176@numachi.com>
 <867253b170bb4cc7a0e76bba5554da5c@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150301075603.GF44176@numachi.com>

On Sat, Feb 28, 2015 at 10:16:58PM +0000, Salz, Rich wrote:
> 
> > I've found one on-line tester for CVE-2014-8730 here:
> 
> You sure that's the one you want?  That is only for F5.  See
>  https://support.f5.com/kb/en-us/solutions/public/15000/800/sol15882.html

I don't think it's only for F5:

  https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8730

I really don't think is effects us (openssl, openjdk statcks), but
it'd be nice to have an explcit test in the toolbox.

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

-- 
Brian Reichert				<reichert at numachi.com>
BSD admin/developer at large	

From de.techno at gmail.com  Sun Mar  1 11:09:31 2015
From: de.techno at gmail.com (dE)
Date: Sun, 01 Mar 2015 16:39:31 +0530
Subject: [openssl-users] SSL_CTX_check_private_key:no certificate assigned
Message-ID: <54F2F36B.2050307@gmail.com>

Hi!

I'm trying to create a certificate using openssl library. Here is the 
code --

void main () {
     SSL_library_init();
     SSL_load_error_strings();
     OpenSSL_add_all_algorithms();
     char err[1000];
     RSA* keypair = RSA_new();
     BIGNUM *e = BN_new();
     X509 *certificate = X509_new();
     EVP_PKEY *certkeypair = EVP_PKEY_new();

     BN_set_word(e, 65537);
     if (!RSA_generate_key_ex(keypair, 1024, e, NULL))
         printf ("key generation failed");
     BN_free(e);
     e = NULL;

     EVP_PKEY_assign_RSA(certkeypair,keypair);

     X509_set_version (certificate  , 3);
     ASN1_INTEGER_set(X509_get_serialNumber(certificate), 1);

     X509_NAME * certnames;
     certnames = X509_get_subject_name(certificate);
     X509_NAME_add_entry_by_txt(certnames, "C",  MBSTRING_ASC, (unsigned 
char *)"global", -1, -1, 0);
     X509_NAME_add_entry_by_txt(certnames, "O",  MBSTRING_ASC, (unsigned 
char *)"BIGcoin", -1, -1, 0);
     X509_NAME_add_entry_by_txt(certnames, "CN", MBSTRING_ASC, (unsigned 
char *)"My IP", -1, -1, 0);

     X509_set_issuer_name(certificate,certnames);

     X509_gmtime_adj(X509_get_notBefore(certificate), -(24*60*60));
     X509_gmtime_adj(X509_get_notAfter(certificate), (366*24*60*60));

     X509_sign(certificate, certkeypair, EVP_sha512());

     const SSL_METHOD* meth;
     meth = TLSv1_method();
     SSL_CTX* ctx;
     ctx = SSL_CTX_new(meth);

     SSL_CTX_use_certificate (ctx, certificate);
     SSL_CTX_use_PrivateKey (ctx, certkeypair);

     if (!SSL_CTX_check_private_key (ctx))
         printf ("Signature could not be verified\n");

     ERR_error_string(ERR_peek_last_error(), err);
         printf ("Error is %s\n", err);
}

I cant get the created certificate to be verified. It always results in --

error:140A80B1:SSL routines:SSL_CTX_check_private_key:no certificate 
assigned

From steve at openssl.org  Sun Mar  1 14:13:32 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sun, 1 Mar 2015 14:13:32 +0000
Subject: [openssl-users] SSL_CTX_check_private_key:no certificate
	assigned
In-Reply-To: <54F2F36B.2050307@gmail.com>
References: <54F2F36B.2050307@gmail.com>
Message-ID: <20150301141332.GA6890@openssl.org>

On Sun, Mar 01, 2015, dE wrote:

> Hi!
> 
> I'm trying to create a certificate using openssl library. Here is
> the code --
> 
> void main () {
>     SSL_library_init();
>     SSL_load_error_strings();
>     OpenSSL_add_all_algorithms();
>     char err[1000];
>     RSA* keypair = RSA_new();
>     BIGNUM *e = BN_new();
>     X509 *certificate = X509_new();
>     EVP_PKEY *certkeypair = EVP_PKEY_new();
> 
>     BN_set_word(e, 65537);
>     if (!RSA_generate_key_ex(keypair, 1024, e, NULL))
>         printf ("key generation failed");
>     BN_free(e);
>     e = NULL;
> 
>     EVP_PKEY_assign_RSA(certkeypair,keypair);
> 
>     X509_set_version (certificate  , 3);
>     ASN1_INTEGER_set(X509_get_serialNumber(certificate), 1);
> 
>     X509_NAME * certnames;
>     certnames = X509_get_subject_name(certificate);
>     X509_NAME_add_entry_by_txt(certnames, "C",  MBSTRING_ASC,
> (unsigned char *)"global", -1, -1, 0);
>     X509_NAME_add_entry_by_txt(certnames, "O",  MBSTRING_ASC,
> (unsigned char *)"BIGcoin", -1, -1, 0);
>     X509_NAME_add_entry_by_txt(certnames, "CN", MBSTRING_ASC,
> (unsigned char *)"My IP", -1, -1, 0);
> 
>     X509_set_issuer_name(certificate,certnames);
> 
>     X509_gmtime_adj(X509_get_notBefore(certificate), -(24*60*60));
>     X509_gmtime_adj(X509_get_notAfter(certificate), (366*24*60*60));
> 
>     X509_sign(certificate, certkeypair, EVP_sha512());
> 
>     const SSL_METHOD* meth;
>     meth = TLSv1_method();
>     SSL_CTX* ctx;
>     ctx = SSL_CTX_new(meth);
> 
>     SSL_CTX_use_certificate (ctx, certificate);
>     SSL_CTX_use_PrivateKey (ctx, certkeypair);
> 
>     if (!SSL_CTX_check_private_key (ctx))
>         printf ("Signature could not be verified\n");
> 
>     ERR_error_string(ERR_peek_last_error(), err);
>         printf ("Error is %s\n", err);
> }
> 
> I cant get the created certificate to be verified. It always results in --
> 
> error:140A80B1:SSL routines:SSL_CTX_check_private_key:no certificate
> assigned

You're missing a call to X509_set_pubkey. Since the certificate doesn't
contain a public key it is not valid and the TLS code can't check a public key
which doesn't exist. In fact it wont even get there: if there is no key on a
certificate OpenSSL will refuse to add it as a certificate in the first place
(which is why you get the "no certificate" error).

If you checked some of your other functions for errors you'd see what was
happening: there are probably many more errors in the whole queue but you're
only seeing the last one.

Check out demos/x509/mkcert.c for an example of how to create a certificate.

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

From de.techno at gmail.com  Sun Mar  1 14:53:57 2015
From: de.techno at gmail.com (dE)
Date: Sun, 01 Mar 2015 20:23:57 +0530
Subject: [openssl-users] SSL_CTX_check_private_key:no certificate
	assigned
In-Reply-To: <20150301141332.GA6890@openssl.org>
References: <54F2F36B.2050307@gmail.com> <20150301141332.GA6890@openssl.org>
Message-ID: <54F32805.3040302@gmail.com>

On 03/01/15 19:43, Dr. Stephen Henson wrote:
> On Sun, Mar 01, 2015, dE wrote:
>
>> Hi!
>>
>> I'm trying to create a certificate using openssl library. Here is
>> the code --
>>
>> void main () {
>>      SSL_library_init();
>>      SSL_load_error_strings();
>>      OpenSSL_add_all_algorithms();
>>      char err[1000];
>>      RSA* keypair = RSA_new();
>>      BIGNUM *e = BN_new();
>>      X509 *certificate = X509_new();
>>      EVP_PKEY *certkeypair = EVP_PKEY_new();
>>
>>      BN_set_word(e, 65537);
>>      if (!RSA_generate_key_ex(keypair, 1024, e, NULL))
>>          printf ("key generation failed");
>>      BN_free(e);
>>      e = NULL;
>>
>>      EVP_PKEY_assign_RSA(certkeypair,keypair);
>>
>>      X509_set_version (certificate  , 3);
>>      ASN1_INTEGER_set(X509_get_serialNumber(certificate), 1);
>>
>>      X509_NAME * certnames;
>>      certnames = X509_get_subject_name(certificate);
>>      X509_NAME_add_entry_by_txt(certnames, "C",  MBSTRING_ASC,
>> (unsigned char *)"global", -1, -1, 0);
>>      X509_NAME_add_entry_by_txt(certnames, "O",  MBSTRING_ASC,
>> (unsigned char *)"BIGcoin", -1, -1, 0);
>>      X509_NAME_add_entry_by_txt(certnames, "CN", MBSTRING_ASC,
>> (unsigned char *)"My IP", -1, -1, 0);
>>
>>      X509_set_issuer_name(certificate,certnames);
>>
>>      X509_gmtime_adj(X509_get_notBefore(certificate), -(24*60*60));
>>      X509_gmtime_adj(X509_get_notAfter(certificate), (366*24*60*60));
>>
>>      X509_sign(certificate, certkeypair, EVP_sha512());
>>
>>      const SSL_METHOD* meth;
>>      meth = TLSv1_method();
>>      SSL_CTX* ctx;
>>      ctx = SSL_CTX_new(meth);
>>
>>      SSL_CTX_use_certificate (ctx, certificate);
>>      SSL_CTX_use_PrivateKey (ctx, certkeypair);
>>
>>      if (!SSL_CTX_check_private_key (ctx))
>>          printf ("Signature could not be verified\n");
>>
>>      ERR_error_string(ERR_peek_last_error(), err);
>>          printf ("Error is %s\n", err);
>> }
>>
>> I cant get the created certificate to be verified. It always results in --
>>
>> error:140A80B1:SSL routines:SSL_CTX_check_private_key:no certificate
>> assigned
> You're missing a call to X509_set_pubkey. Since the certificate doesn't
> contain a public key it is not valid and the TLS code can't check a public key
> which doesn't exist. In fact it wont even get there: if there is no key on a
> certificate OpenSSL will refuse to add it as a certificate in the first place
> (which is why you get the "no certificate" error).
>
> If you checked some of your other functions for errors you'd see what was
> happening: there are probably many more errors in the whole queue but you're
> only seeing the last one.
>
> Check out demos/x509/mkcert.c for an example of how to create a certificate.
>
> 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

Thank you!

From p.mrunal at gmail.com  Mon Mar  2 09:18:14 2015
From: p.mrunal at gmail.com (Mrunal Nerpawar)
Date: Mon, 2 Mar 2015 14:48:14 +0530
Subject: [openssl-users] FIPSLD 2.0.5 (HP-UX AI64 11.23) fails to link
 with pthread error
In-Reply-To: <CFA3D59B-C7D4-41FD-A48A-4069E81FF0F9@pobox.com>
References: <CAF5AerH_+p_Fo0tb3o6Yh2V1Heqx3vxw=hgUY4sRHtEdihnzJQ@mail.gmail.com>
 <CFA3D59B-C7D4-41FD-A48A-4069E81FF0F9@pobox.com>
Message-ID: <CAF5AerESoWO=r5vFFSSKNV82-b-_Svz5qT1Wp6mqsdVCou3i7Q@mail.gmail.com>

Thanks Tom for the reply.

I know I am replying really late, but the option you mentioned is tried but
is not working either. :(

Anything else i can try?

-Mrunal

On Wed, Feb 25, 2015 at 8:31 AM, Tom Francis <thomas.francis.jr at pobox.com>
wrote:

> Have you tried changing FIPSLD_CC and FIPSLD_LINK to include the necessary
> options (e.g. -mt)?  Note: it might be simpler to modify fipsld instead,
> depending on how easy/hard it is to maintain spaces properly when settings
> FIPSLD_CC and FIPSLD_LINK.  Since the fipsld script is just a convenience
> script to help you meet the requirements of the security policy, you?re
> free to modify it.  Just don?t modify it such that the security policy is
> no longer followed.  Generally speaking, adding more options to the compile
> and link steps will be safe.
>
> TOM
>
> > On Feb 23, 2015, at 4:36 AM, Mrunal Nerpawar <p.mrunal at gmail.com> wrote:
> >
> > Details
> > ======
> > Fips 2.0.5 configured with no-asm and threads.
> > Openssl 1.0.1H configured with shared, fips, threads no-asm (many alogos
> omitted)
> > compiler -  using aCC 6.25 on HPUX-IA64 11.23.
> >
> > bash-2.05$ aCC --version
> > aCC: HP C/aC++ B3910B A.06.25.02 [Nov 25 2010]
> > bash-2.05$
> >
> > product linking with fipsld fails with error ...
> > =================================
> > :DLFCN_LOAD:could not load the shared
> library:dso_dlfcn.c:187:filename(./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0):
> Cannot dlopen load module '/usr/lib/hpux32/libpthread.so.1' because it
> contains thread specific data.
> >
> > Options tried
> > ==========
> > * Compiling Cxx sources with -mt.
> > * Linking with -lpthread,
> > * setting LD_PRELOAD.
> > None worked effectively. with LD_PRELOAD option, ended up getting error
> - undefined symbol Ztil, etc.
> >
> > complete error is as follows.
> > =====================
> >
> > Building shared library
> objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0
> > FIPSLD_CC=aCC FIPSLD_LINK=aCC
> /unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/fipsld
> +Z -b -g -O2 -AA -Wl,+s +tls=dynamic -o
> objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0
> objs/HP-UX-B.11.23-ia64-64/stdafx.o objs/HP-UX-B.11.23-ia64-64/UserUtil.o
> objs/HP-UX-B.11.23-ia64-64/LSSpawner.o
> objs/HP-UX-B.11.23-ia64-64/LSFilter.o
> objs/HP-UX-B.11.23-ia64-64/LSCmdOutputParser.o
> objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor.o
> objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor_1.o
> objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor_2.o
> objs/HP-UX-B.11.23-ia64-64/GroupUtil.o
> objs/HP-UX-B.11.23-ia64-64/ShadowHelper.o
> objs/HP-UX-B.11.23-ia64-64/BlockedFiles.o
> objs/HP-UX-B.11.23-ia64-64/NISUtil.o objs/HP-UX-B.11.23-ia64-64/Utilities.o
> objs/HP-UX-B.11.23-ia64-64/MachineUtil.o
> objs/HP-UX-B.11.23-ia64-64/BvNetworkInfo.o
> objs/HP-UX-B.11.23-ia64-64/NSSwitch.o
> objs/HP-UX-B.11.23-ia64-64/FileUtil_1.o
> objs/HP-UX-B.11.23-ia64-64/FileUtil_2.o
> objs/HP-UX-B.11.23-ia64-64/SecurityThreatCheck.o
> objs/HP-UX-B.11.23-ia64-64/UserEnumerator.o
> objs/HP-UX-B.11.23-ia64-64/LocalUserEnumerator.o
> objs/HP-UX-B.11.23-ia64-64/UnixUserEnumerator.o
> objs/HP-UX-B.11.23-ia64-64/WinUserEnumerator.o
> objs/HP-UX-B.11.23-ia64-64/GetEntHandler.o
> objs/HP-UX-B.11.23-ia64-64/UnixShadowReader.o
> objs/HP-UX-B.11.23-ia64-64/EtcShadowReader.o
> objs/HP-UX-B.11.23-ia64-64/UnixEtcShadowReader.o
> objs/HP-UX-B.11.23-ia64-64/AIXShadowHelper.o
> objs/HP-UX-B.11.23-ia64-64/HPLoginsShadowHelper.o
> objs/HP-UX-B.11.23-ia64-64/HPTcbShadowHelper.o
> objs/HP-UX-B.11.23-ia64-64/UnixHPShadowReader.o
> objs/HP-UX-B.11.23-ia64-64/ProcessUtil.o
> objs/HP-UX-B.11.23-ia64-64/FieldUtils.o
> objs/HP-UX-B.11.23-ia64-64/LoggedInUserInfo.o
> objs/HP-UX-B.11.23-ia64-64/TcpdRulesParser.o
> objs/HP-UX-B.11.23-ia64-64/DirectoryUtil.o
> objs/HP-UX-B.11.23-ia64-64/Timestamp.o
> objs/HP-UX-B.11.23-ia64-64/Timespan.o
> objs/HP-UX-B.11.23-ia64-64/NumberFormatter.o
> objs/HP-UX-B.11.23-ia64-64/DateTimeParser.o
> objs/HP-UX-B.11.23-ia64-64/DateTimeFormatter.o
> objs/HP-UX-B.11.23-ia64-64/DateTimeFormat.o
> objs/HP-UX-B.11.23-ia64-64/DateTime.o objs/HP-UX-B.11.23-ia64-64/Timezone.o
> objs/HP-UX-B.11.23-ia64-64/LocalDateTime.o
> objs/HP-UX-B.11.23-ia64-64/RFUtilities.o
> objs/HP-UX-B.11.23-ia64-64/OpenPortUtil.o
> objs/HP-UX-B.11.23-ia64-64/AIXStanzaReader.o
> objs/HP-UX-B.11.23-ia64-64/Bugcheck.o objs/HP-UX-B.11.23-ia64-64/DateTime.o
> objs/HP-UX-B.11.23-ia64-64/Debugger.o
> objs/HP-UX-B.11.23-ia64-64/Exception.o
> objs/HP-UX-B.11.23-ia64-64/GroupEnumerator.o
> objs/HP-UX-B.11.23-ia64-64/UnixGroupEnumerator.o
> objs/HP-UX-B.11.23-ia64-64/FileInfoFetcher.o
> objs/HP-UX-B.11.23-ia64-64/UnixFileInfoAccessor.o
> objs/HP-UX-B.11.23-ia64-64/FileStatSysCallProcessor.o
> objs/HP-UX-B.11.23-ia64-64/StatSysCallFileInfoFetcherImpl.o
> objs/HP-UX-B.11.23-ia64-64/FileInfoAccessor.o
> objs/HP-UX-B.11.23-ia64-64/FileProcessorObjectFactory.o
> objs/HP-UX-B.11.23-ia64-64/UUID.o objs/HP-UX-B.11.23-ia64-64/RandomStream.o
> objs/HP-UX-B.11.23-ia64-64/Random.o objs/HP-UX-B.11.23-ia64-64/SHA1Engine.o
> objs/HP-UX-B.11.23-ia64-64/DigestEngine.o
> objs/HP-UX-B.11.23-ia64-64/FileDescriptorUtil.o
> objs/HP-UX-B.11.23-ia64-64/PasswordInfo.o
> objs/HP-UX-B.11.23-ia64-64/DictionaryReader.o
> objs/HP-UX-B.11.23-ia64-64/PasswordCracker.o
> objs/HP-UX-B.11.23-ia64-64/md5crypt.o
> -L/unixhome/user/workspace/ontrolShared/UnixReusableClasses/lib/HP-UX-B.11.23-ia64-64
> -lReCpp -lReCommon
> -L/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/lib -lcrypto
> -L/unixhome/user/workspace/product/lib/HP-UX-B.11.23-ia64-64 -lAgentCommon
> -lReCoreClasses -lCommonLib  -lsec
> > fipsld:
> THERE=/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/..
> > fipsld: TARGET=./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0
> > fipsld:
> CANISTER_O=/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/../lib/fipscanister.o
> > fipsld:
> PREMAIN_C=/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/../lib/fips_premain.c
> > fipsld: PREMAIN_O=objs/HP-UX-B.11.23-ia64-64/fips_premain.o
> > fipsld: FIPSLIBDIR=
> > fipsld: FIPSLD_CC=aCC
> > fipsld: FIPSLD_LINK=aCC
> > fipsld: Linking shared library file.
> > fipsld: Compiling
> "/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/../lib/fips_premain.c".
> > fipsld: Linking
> "./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0" with FIPS
> libaries.
> > 2130621380:error:25066067:DSO support routines:DLFCN_LOAD:could not load
> the shared
> library:dso_dlfcn.c:187:filename(./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0):
> Cannot dlopen load module '/usr/lib/hpux32/libpthread.so.1' because it
> contains thread specific data.
> > 2130621380:error:25070067:DSO support routines:DSO_load:could not load
> the shared library:dso_lib.c:244:
> >
> /unixhome/user/workspace/product/Packages/BuildScripts/Makefiles/Make.inc.shlib.rules:73:
> recipe for target 'objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0'
> failed
> > gmake: *** [objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0]
> Error 1
> > bash-2.05$
> >
> >
> > We are running short of time. If anybody has any solutions/suggestions
> help, would be appreciated.
> >
> > Thanks in advance.
> >
> > Best regards,
> > Mrunal
> > _______________________________________________
> > 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/20150302/cd7b41eb/attachment.html>

From reichert at numachi.com  Mon Mar  2 16:28:14 2015
From: reichert at numachi.com (Brian Reichert)
Date: Mon, 2 Mar 2015 11:28:14 -0500
Subject: [openssl-users] has anyone developed a standalone test for
	CVE-2014-8730?
In-Reply-To: <CAMp7mVsaxOrXGkO2AaTqdT3GXdpYiPm9ihsw8vHPmPAH1Ze3UA@mail.gmail.com>
References: <20150227183128.GC44176@numachi.com>
 <CAMp7mVsaxOrXGkO2AaTqdT3GXdpYiPm9ihsw8vHPmPAH1Ze3UA@mail.gmail.com>
Message-ID: <20150302162814.GH44176@numachi.com>

On Sat, Feb 28, 2015 at 10:50:27PM +0000, Richard Moore wrote:
> I wrote a test using tlslite - only a few lines of code, so it should be
> pretty easy to reproduce.

Is your test something you could share?  :)

Coding, per se, doesn't scare me, but assuring I have a correct
grasp of the specifics what I'm implementing would take a while...

> 
> Rich.

-- 
Brian Reichert				<reichert at numachi.com>
BSD admin/developer at large	

From jonetsu at teksavvy.com  Mon Mar  2 17:18:06 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Mon, 02 Mar 2015 12:18:06 -0500
Subject: [openssl-users] Testing FIPS mode using 0 randomness
Message-ID: <bcc759af5db5319772eef47195cda9f7@teksavvy.com>

Hello,

? I tried a simple test to see if FIPS mode would fail, using the example given in the FIPS user guide 2.0.? The test consisted of replacing the /dev/random and /dev/urandom with /dev/zero.? I would have expected that no source of randomness would make the tests ran at the call of FIPS_mode_set(1) fail.

ex.:

cd dev
rm random
mknod -m 666 /dev/random c 1 5

Verify presence of zeroes all over:
cat /dev/random | xxd

./fips_hmac fips_hmac.o

If added a ret value to catch the return code from FIPS_mode_set(1).? Random or no random, it always returns 1.? 

Shouldn't randomness be an important part of the power-up tests ?? I understand there are continuous RNG tests within OpenSSL FIPS mode, although 'later on' (eg. continuous). Wouldn't these tests be part of the power-up sequence as called by FIPS_mode_set(1) also ?

Thanks.



From erwann.abalea at opentrust.com  Mon Mar  2 17:27:25 2015
From: erwann.abalea at opentrust.com (Erwann Abalea)
Date: Mon, 02 Mar 2015 18:27:25 +0100
Subject: [openssl-users] [openssl-dev] [openssl.org #3726] Cocoapods
	install BUG
In-Reply-To: <rt-4.0.4-24611-1425315966-554.3726-21-0@openssl.org>
References: <RT-Ticket-3726@openssl.org>
 <6AD89B1B-8C41-4A1F-BAA2-7030E7AD2531@gmail.com>
 <rt-4.0.4-24611-1425315966-554.3726-21-0@openssl.org>
Message-ID: <54F49D7D.8000204@opentrust.com>

It seems all the tarballs have disappeared.

-- 
Erwann ABALEA

Le 02/03/2015 18:06, Alex Sklyar via RT a ?crit :
> Hello guys. There is a issue with openssl pod installing with cocoapods tool. The URL ?https://www.openssl.org/source/openssl-1.0.2.tar.gz? is dead.
>


From thomas.francis.jr at pobox.com  Mon Mar  2 21:13:11 2015
From: thomas.francis.jr at pobox.com (Tom Francis)
Date: Mon, 2 Mar 2015 16:13:11 -0500
Subject: [openssl-users] Testing FIPS mode using 0 randomness
In-Reply-To: <bcc759af5db5319772eef47195cda9f7@teksavvy.com>
References: <bcc759af5db5319772eef47195cda9f7@teksavvy.com>
Message-ID: <A41FF52B-E408-4A11-9F2B-D4AF7BC82739@pobox.com>


> On Mar 2, 2015, at 12:18 PM, jonetsu <jonetsu at teksavvy.com> wrote:
> 
> Hello,
> 
>   I tried a simple test to see if FIPS mode would fail, using the example given in the FIPS user guide 2.0.  The test consisted of replacing the /dev/random and /dev/urandom with /dev/zero.  I would have expected that no source of randomness would make the tests ran at the call of FIPS_mode_set(1) fail.
> 
> ex.:
> 
> cd dev
> rm random
> mknod -m 666 /dev/random c 1 5
> 
> Verify presence of zeroes all over:
> cat /dev/random | xxd
> 
> ./fips_hmac fips_hmac.o
> 
> If added a ret value to catch the return code from FIPS_mode_set(1).  Random or no random, it always returns 1.  
> 
> Shouldn't randomness be an important part of the power-up tests ?  I understand there are continuous RNG tests within OpenSSL FIPS mode, although 'later on' (eg. continuous). Wouldn't these tests be part of the power-up sequence as called by FIPS_mode_set(1) also ?

No.  The self-tests verify the output of the algorithms matches for given input.  This means when the PRNG is tested, it?s seeded with known values, and the output is checked against the correct output for the way it was seeded.  Inputs from /dev/random, /dev/urandom, or any other ?random? source are not used.

Remember, the goal of FIPS 140 is NOT ?good security?, it?s ?verifying that known cryptographic algorithms are used?.  If the input and output are not predictably the same, then how can you verify the algorithm used is the algorithm that?s supposed to be used?  And attempting to account in the tests for every possible input (what you?d have to do if you didn?t only test a small number of known inputs) would be impractical, at best. :)

TOM

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


From thomas.francis.jr at pobox.com  Mon Mar  2 21:14:21 2015
From: thomas.francis.jr at pobox.com (Tom Francis)
Date: Mon, 2 Mar 2015 16:14:21 -0500
Subject: [openssl-users] FIPSLD 2.0.5 (HP-UX AI64 11.23) fails to link
	with pthread error
In-Reply-To: <CAF5AerESoWO=r5vFFSSKNV82-b-_Svz5qT1Wp6mqsdVCou3i7Q@mail.gmail.com>
References: <CAF5AerH_+p_Fo0tb3o6Yh2V1Heqx3vxw=hgUY4sRHtEdihnzJQ@mail.gmail.com>
 <CFA3D59B-C7D4-41FD-A48A-4069E81FF0F9@pobox.com>
 <CAF5AerESoWO=r5vFFSSKNV82-b-_Svz5qT1Wp6mqsdVCou3i7Q@mail.gmail.com>
Message-ID: <67EC874D-4B49-4E6E-BABB-CE428483B4AB@pobox.com>


> On Mar 2, 2015, at 4:18 AM, Mrunal Nerpawar <p.mrunal at gmail.com> wrote:
> 
> Thanks Tom for the reply.
> 
> I know I am replying really late, but the option you mentioned is tried but is not working either. :(
> 
> Anything else i can try?

Since I no longer have access to that compiler, and I don?t generally bother with FIPS 140 anymore, I can?t be sure, but I suspect the problem is described here:

http://h21007.www2.hp.com/portal/download/files/prot/files/linker/onlinehelp/compileandlink.htm (see ?Linker Thread-safe features?).

Originally, I was thinking this was an actual link error, but now that I think about it, it?s probably coming from when fips_premain_dso is run to determine the signature to be embedded.  And if that?s the case, you?re pretty much out of luck ? there?s no way to modify fips_premain_dso to avoid the shl_load() call (not and still be following the security policy), and there?s no way to make shl_load() succeed. shl_load() simply doesn?t work with TLS.  If you could somehow change your use of OpenSSL and the FIPS Object Module such that OpenSSL is linked statically into an executable (that is, a complete executable, not a shared library) then you could probably make it work. :(

You can verify if that?s the case by adding more output to your fipsld script; I suspect you?ll see the failure from the line:

SIG=`?${PREMAIN_DSO}? ?${TARGET}?`

There should be code in fipsld to error out if that failed, but perhaps that was disabled?  Anyway, if the error is not from invoking fips_premain_dso, then something else is wrong, and I?d suggest opening a support case with HP.

TOM

> -Mrunal
> 
> On Wed, Feb 25, 2015 at 8:31 AM, Tom Francis <thomas.francis.jr at pobox.com> wrote:
> Have you tried changing FIPSLD_CC and FIPSLD_LINK to include the necessary options (e.g. -mt)?  Note: it might be simpler to modify fipsld instead, depending on how easy/hard it is to maintain spaces properly when settings FIPSLD_CC and FIPSLD_LINK.  Since the fipsld script is just a convenience script to help you meet the requirements of the security policy, you?re free to modify it.  Just don?t modify it such that the security policy is no longer followed.  Generally speaking, adding more options to the compile and link steps will be safe.
> 
> TOM
> 
> > On Feb 23, 2015, at 4:36 AM, Mrunal Nerpawar <p.mrunal at gmail.com> wrote:
> >
> > Details
> > ======
> > Fips 2.0.5 configured with no-asm and threads.
> > Openssl 1.0.1H configured with shared, fips, threads no-asm (many alogos omitted)
> > compiler -  using aCC 6.25 on HPUX-IA64 11.23.
> >
> > bash-2.05$ aCC --version
> > aCC: HP C/aC++ B3910B A.06.25.02 [Nov 25 2010]
> > bash-2.05$
> >
> > product linking with fipsld fails with error ...
> > =================================
> > :DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:187:filename(./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0):  Cannot dlopen load module '/usr/lib/hpux32/libpthread.so.1' because it contains thread specific data.
> >
> > Options tried
> > ==========
> > * Compiling Cxx sources with -mt.
> > * Linking with -lpthread,
> > * setting LD_PRELOAD.
> > None worked effectively. with LD_PRELOAD option, ended up getting error - undefined symbol Ztil, etc.
> >
> > complete error is as follows.
> > =====================
> >
> > Building shared library objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0
> > FIPSLD_CC=aCC FIPSLD_LINK=aCC /unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/fipsld  +Z -b -g -O2 -AA -Wl,+s +tls=dynamic -o objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0 objs/HP-UX-B.11.23-ia64-64/stdafx.o objs/HP-UX-B.11.23-ia64-64/UserUtil.o objs/HP-UX-B.11.23-ia64-64/LSSpawner.o objs/HP-UX-B.11.23-ia64-64/LSFilter.o objs/HP-UX-B.11.23-ia64-64/LSCmdOutputParser.o objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor.o objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor_1.o objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor_2.o objs/HP-UX-B.11.23-ia64-64/GroupUtil.o objs/HP-UX-B.11.23-ia64-64/ShadowHelper.o objs/HP-UX-B.11.23-ia64-64/BlockedFiles.o objs/HP-UX-B.11.23-ia64-64/NISUtil.o objs/HP-UX-B.11.23-ia64-64/Utilities.o objs/HP-UX-B.11.23-ia64-64/MachineUtil.o objs/HP-UX-B.11.23-ia64-64/BvNetworkInfo.o objs/HP-UX-B.11.23-ia64-64/NSSwitch.o objs/HP-UX-B.11.23-ia64-64/FileUtil_1.o objs/HP-UX-B.11.23-ia64-64/FileUtil_2.o objs/HP-UX-B.11.23-ia64-64/SecurityThreatCheck.o objs/HP-UX-B.11.23-ia64-64/UserEnumerator.o objs/HP-UX-B.11.23-ia64-64/LocalUserEnumerator.o objs/HP-UX-B.11.23-ia64-64/UnixUserEnumerator.o objs/HP-UX-B.11.23-ia64-64/WinUserEnumerator.o objs/HP-UX-B.11.23-ia64-64/GetEntHandler.o objs/HP-UX-B.11.23-ia64-64/UnixShadowReader.o objs/HP-UX-B.11.23-ia64-64/EtcShadowReader.o objs/HP-UX-B.11.23-ia64-64/UnixEtcShadowReader.o objs/HP-UX-B.11.23-ia64-64/AIXShadowHelper.o objs/HP-UX-B.11.23-ia64-64/HPLoginsShadowHelper.o objs/HP-UX-B.11.23-ia64-64/HPTcbShadowHelper.o objs/HP-UX-B.11.23-ia64-64/UnixHPShadowReader.o objs/HP-UX-B.11.23-ia64-64/ProcessUtil.o objs/HP-UX-B.11.23-ia64-64/FieldUtils.o objs/HP-UX-B.11.23-ia64-64/LoggedInUserInfo.o objs/HP-UX-B.11.23-ia64-64/TcpdRulesParser.o objs/HP-UX-B.11.23-ia64-64/DirectoryUtil.o objs/HP-UX-B.11.23-ia64-64/Timestamp.o objs/HP-UX-B.11.23-ia64-64/Timespan.o objs/HP-UX-B.11.23-ia64-64/NumberFormatter.o objs/HP-UX-B.11.23-ia64-64/DateTimeParser.o objs/HP-UX-B.11.23-ia64-64/DateTimeFormatter.o objs/HP-UX-B.11.23-ia64-64/DateTimeFormat.o objs/HP-UX-B.11.23-ia64-64/DateTime.o objs/HP-UX-B.11.23-ia64-64/Timezone.o objs/HP-UX-B.11.23-ia64-64/LocalDateTime.o objs/HP-UX-B.11.23-ia64-64/RFUtilities.o objs/HP-UX-B.11.23-ia64-64/OpenPortUtil.o objs/HP-UX-B.11.23-ia64-64/AIXStanzaReader.o objs/HP-UX-B.11.23-ia64-64/Bugcheck.o objs/HP-UX-B.11.23-ia64-64/DateTime.o objs/HP-UX-B.11.23-ia64-64/Debugger.o objs/HP-UX-B.11.23-ia64-64/Exception.o objs/HP-UX-B.11.23-ia64-64/GroupEnumerator.o objs/HP-UX-B.11.23-ia64-64/UnixGroupEnumerator.o objs/HP-UX-B.11.23-ia64-64/FileInfoFetcher.o objs/HP-UX-B.11.23-ia64-64/UnixFileInfoAccessor.o objs/HP-UX-B.11.23-ia64-64/FileStatSysCallProcessor.o objs/HP-UX-B.11.23-ia64-64/StatSysCallFileInfoFetcherImpl.o objs/HP-UX-B.11.23-ia64-64/FileInfoAccessor.o objs/HP-UX-B.11.23-ia64-64/FileProcessorObjectFactory.o objs/HP-UX-B.11.23-ia64-64/UUID.o objs/HP-UX-B.11.23-ia64-64/RandomStream.o objs/HP-UX-B.11.23-ia64-64/Random.o objs/HP-UX-B.11.23-ia64-64/SHA1Engine.o objs/HP-UX-B.11.23-ia64-64/DigestEngine.o objs/HP-UX-B.11.23-ia64-64/FileDescriptorUtil.o objs/HP-UX-B.11.23-ia64-64/PasswordInfo.o objs/HP-UX-B.11.23-ia64-64/DictionaryReader.o objs/HP-UX-B.11.23-ia64-64/PasswordCracker.o objs/HP-UX-B.11.23-ia64-64/md5crypt.o -L/unixhome/user/workspace/ontrolShared/UnixReusableClasses/lib/HP-UX-B.11.23-ia64-64 -lReCpp -lReCommon -L/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/lib -lcrypto -L/unixhome/user/workspace/product/lib/HP-UX-B.11.23-ia64-64 -lAgentCommon -lReCoreClasses -lCommonLib  -lsec
> > fipsld: THERE=/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/..
> > fipsld: TARGET=./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0
> > fipsld: CANISTER_O=/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/../lib/fipscanister.o
> > fipsld: PREMAIN_C=/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/../lib/fips_premain.c
> > fipsld: PREMAIN_O=objs/HP-UX-B.11.23-ia64-64/fips_premain.o
> > fipsld: FIPSLIBDIR=
> > fipsld: FIPSLD_CC=aCC
> > fipsld: FIPSLD_LINK=aCC
> > fipsld: Linking shared library file.
> > fipsld: Compiling "/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/../lib/fips_premain.c".
> > fipsld: Linking "./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0" with FIPS libaries.
> > 2130621380:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:187:filename(./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0): Cannot dlopen load module '/usr/lib/hpux32/libpthread.so.1' because it contains thread specific data.
> > 2130621380:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244:
> > /unixhome/user/workspace/product/Packages/BuildScripts/Makefiles/Make.inc.shlib.rules:73: recipe for target 'objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0' failed
> > gmake: *** [objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0] Error 1
> > bash-2.05$
> >
> >
> > We are running short of time. If anybody has any solutions/suggestions help, would be appreciated.
> >
> > Thanks in advance.
> >
> > Best regards,
> > Mrunal
> > _______________________________________________
> > 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 lionkimbro at gmail.com  Tue Mar  3 02:43:41 2015
From: lionkimbro at gmail.com (Lion Kimbro)
Date: Tue, 03 Mar 2015 02:43:41 +0000
Subject: [openssl-users] Getting General SSL Help
References: <CAEmWhShR816GGEzLMHX+YJF4=tO1EfCcDBNKjBW0feEvbJ0=9Q@mail.gmail.com>
Message-ID: <CAEmWhSh7TKdL49yqoXvg0PbSFeKr-AFibs2DYy6=VnBd2+H+Cg@mail.gmail.com>

Thank you everybody for your recommendations!  I've ordered a used copy of
Eric Rescorla's SSL and TLS, and have wishlisted Bulletproof SSL and TLS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150303/0bacb623/attachment.html>

From Isaac.Hailperin at lcsystems.ch  Tue Mar  3 13:21:49 2015
From: Isaac.Hailperin at lcsystems.ch (Isaac Hailperin)
Date: Tue, 3 Mar 2015 13:21:49 +0000
Subject: [openssl-users] building 0.9.8ze with fipscanister on solaris
 10	fails
In-Reply-To: <E47948B37D787D4EA0D3014A45A0D092C80CCBDC@tgw00i-1401.lcsys.ch>
References: <E47948B37D787D4EA0D3014A45A0D092C80CC5C8@tgw00i-1401.lcsys.ch>
 <E47948B37D787D4EA0D3014A45A0D092C80CCBDC@tgw00i-1401.lcsys.ch>
Message-ID: <E47948B37D787D4EA0D3014A45A0D092C80CDE8A@tgw00i-1401.lcsys.ch>

Just for the record: I managed to work around this by moving to the 1.0.1 branch.
It's also not straight forward (name clashes with fipscanister, see http://openssl.6102.n7.nabble.com/bn-mul-mont-fpu-multiply-defined-error-td45771.html), but I managed to get it running in fips compliant mode.

Isaac

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Isaac Hailperin
Sent: Mittwoch, 25. Februar 2015 08:58
To: openssl-users at openssl.org
Subject: [openssl-users] building 0.9.8ze with fipscanister on solaris 10 fails

Hi,
I am trying to build openssl 0.9.8ze with fipscansiter on solaris 10 (latest patches installed). I configure like this:
./config fipscanisterbuild --prefix=${OPENSSL_BASE} --openssldir=${OPENSSL_BASE} shared

This worked until 0.9.8x, but stopped at 0.9.8y. When I try to build (make), I get

make[2]: Entering directory `/local/src/openssl-0.9.8ze/test'
Undefined                       first referenced
symbol                             in file
CRYPTO_memcmp                       ../fips/fipscanister.o
ld: fatal: symbol referencing errors. No output written to fips_shatest
collect2: ld returned 1 exit status
make[2]: *** [link_app.solaris] Error 1
make[2]: Leaving directory `/local/src/openssl-0.9.8ze/test'

It looks like it is connected to the following change in the code:
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=270881316664396326c461ec7a124aec2c6cc081

Building without the fipscanister option works fine - but client regulations dictate that I use this option.

Does anyone know how I get this to work? What am I missing?

Isaac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150303/5386c25b/attachment.html>

From roger_no_spam at hotmail.com  Tue Mar  3 13:22:47 2015
From: roger_no_spam at hotmail.com (Roger No-Spam)
Date: Tue, 3 Mar 2015 14:22:47 +0100
Subject: [openssl-users] openssl-tpm-engine
Message-ID: <DUB122-W43CFCE94EAAB1109C05051AC110@phx.gbl>

Hi,

I'm
 experimenting a bit with the tpm engine (openssl_tpm_engine-0.4.2). My 
objective is to see how easy it is use this engine with openssl-1.0.1. 
Since the README file states that openssl-0.9.8 is a requirement I 
started using that openssl version. However, I have tried to use the tpm
 engine with three different openssl-0.9.8 versions, but all three 
crashes with different call stacks, when using the basic example from 
the README file (Create a self-signed cert using the TPM engine). I'm 
starting to suspect that I have overseen something fundamental. Is the 
openssl-tpm-engine supposed to work on 64 bit machines? Or is there 
something else I need to consider?

Below is some additional info on the crashes I'm seeing. All crashes are for step 2, 
openssl req -keyform engine -engine tpm -key <keyfilename> -new -x509 -days 365 -out <certfilename>

openssl-0.9.8zb:
0  in BN_num_bits of bn_lib.c:232
1  in bn_i2c of x_bignum.c:117
2  in asn1_ex_i2c of tasn_enc.c:582
3  in asn1_i2d_ex_primitive of tasn_enc.c:523
4  in ASN1_item_ex_i2d of tasn_enc.c:154
5  in asn1_template_ex_i2d of tasn_enc.c:413
6  in ASN1_item_ex_i2d of tasn_enc.c:231
7  in asn1_item_flags_i2d of tasn_enc.c:122
8  in ASN1_item_i2d of tasn_enc.c:91
9  in i2d_RSAPublicKey of rsa_asn1.c:111
10 in i2d_PublicKey of i2d_pu.c:80
11 in X509_PUBKEY_set of x_pubkey.c:223
12 in X509_REQ_set_pubkey of x509rset.c:81
13 in make_REQ of req.c:1257
14 in req_main of req.c:914
15 in do_cmd of openssl.c:400
16 in main of openssl.c:318

openssl-0.9.8x:
0  in raise of /lib/x86_64-linux-gnu/libc.so.6
1  in abort of /lib/x86_64-linux-gnu/libc.so.6
2  in ?? of /lib/x86_64-linux-gnu/libc.so.6
3  in ?? of /lib/x86_64-linux-gnu/libc.so.6
4  in CRYPTO_free of mem.c:406
5  in asn1_item_combine_free of tasn_fre.c:176
6  in ASN1_item_free of tasn_fre.c:71
7  in X509_ATTRIBUTE_free of x_attrib.c:96
8  in sk_pop_free of stack.c:290
9  in EVP_PKEY_free of p_lib.c:468
10 in req_main of req.c:1183
11 in do_cmd of openssl.c:400
12 in main of openssl.c:318

I also tried openssl-0.9.8, but I didn't save the call stack of that crash.

I'm using ubuntu 14.04.

Regards Roger

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

From ivan.ristic at gmail.com  Tue Mar  3 19:14:50 2015
From: ivan.ristic at gmail.com (Ivan Ristic)
Date: Tue, 03 Mar 2015 19:14:50 +0000
Subject: [openssl-users] [ANNOUNCE] OpenSSL Cookbook 2nd Edition released
Message-ID: <54F6082A.1000906@gmail.com>

Today I'm releasing the second edition of OpenSSL Cookbook, my free
OpenSSL book. This edition is a major update, with improvements to the
existing text as well as new content. This new edition has about 95
pages, which is an increase of about 35 pages comparing to the previous
release.

Get it here: https://www.feistyduck.com/books/openssl-cookbook/

Here?s a brief overview of what?s new:

- New chapter "Testing with OpenSSL", which focuses on secure server
assessment.

- New section "Recommended Configuration", which contains a list of
recommended cipher suites. I now prefer to configure OpenSSL by
explicitly listing all the suites I wish to enable.

- New section "Creating a Private Certification Authority", which
contains a step-by-step guide to creating and deploying a private CA.

- Updated "SSL/TLS Deployment Best Practices" to v1.4. Important changes
in this version include SHA1 deprecation and SSL v3 weaknesses (POODLE).

Another important improvement is that I am switching from updating
OpenSSL Cookbook once in a while (the previous edition was released in
October 2013) to making small changes as the need arises. There still
might be further editions, but only when and if new content is added.

OpenSSL Cookbook draws from the content written for my bigger work,
Bulletproof SSL and TLS. If you?re looking for a complete guide to the
world of SSL/TLS and Internet PKI, give this bigger book a try.

That said, the main goals of OpenSSL Cookbook are to be useful, short,
and contain documentation for everything you might want to do with
OpenSSL as a user (i.e., no programming). If you?re looking for
something and you can?t find it in this book, please get in touch to
propose improvements.

Thanks!

-- 
Ivan

From npmccallum at redhat.com  Tue Mar  3 19:59:35 2015
From: npmccallum at redhat.com (Nathaniel McCallum)
Date: Tue, 03 Mar 2015 14:59:35 -0500
Subject: [openssl-users] Security properties of EVP_Seal*()
Message-ID: <1425412775.5595.21.camel@redhat.com>

1. Does it provide a confounder? If no, this is easy to work around.

2. Does it provide a MAC? If no, this is more difficult. Since the 
actual key is never exposed by EVP_SealInit(), no MAC can be performed 
after the fact.

Nathaniel

From dave_nirav84 at yahoo.com  Wed Mar  4 07:43:16 2015
From: dave_nirav84 at yahoo.com (dave nirav)
Date: Wed, 4 Mar 2015 07:43:16 +0000 (UTC)
Subject: [openssl-users] Openssl upgrade
Message-ID: <2107724993.2420090.1425454996683.JavaMail.yahoo@mail.yahoo.com>

Hi Users,
This is probably the first mail in this group.
I am upgrading my openssl product from 0.9.8e openssl which is having base as centos 5.6 to 1.0.1e openssl which has base os as centos 7.0. 

I have successfully compiled my code with ssl Lib API's which was used with 0.9.8 e. 

I am facing unknown digest error from ASN1 while verifying certificate from client using PKCS7_verify. 

Thanks,Nirav Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150304/6c873510/attachment.html>

From rsalz at akamai.com  Wed Mar  4 15:39:23 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 4 Mar 2015 15:39:23 +0000
Subject: [openssl-users] Openssl upgrade
In-Reply-To: <2107724993.2420090.1425454996683.JavaMail.yahoo@mail.yahoo.com>
References: <2107724993.2420090.1425454996683.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <c4f3f7d421854c99b8e7568f3c3809d5@ustx2ex-dag1mb2.msg.corp.akamai.com>


> I am facing unknown digest error from ASN1 while verifying certificate from client using PKCS7_verify. 

Is this a cert you generated with the old openssl code?  I believe there is an issue with OID's, but am not sure.  Maybe somebody else can recall.

From openssl-users at dukhovni.org  Wed Mar  4 17:26:30 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 4 Mar 2015 17:26:30 +0000
Subject: [openssl-users] Openssl upgrade
In-Reply-To: <2107724993.2420090.1425454996683.JavaMail.yahoo@mail.yahoo.com>
References: <2107724993.2420090.1425454996683.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <20150304172630.GW1260@mournblade.imrryr.org>

On Wed, Mar 04, 2015 at 07:43:16AM +0000, dave nirav wrote:

> This is probably the first mail in this group.
> I am upgrading my openssl product from 0.9.8e openssl which is having base as centos 5.6 to 1.0.1e openssl which has base os as centos 7.0. 
> 
> I have successfully compiled my code with ssl Lib API's which was used with 0.9.8 e. 
> 
> I am facing unknown digest error from ASN1 while verifying certificate from client using PKCS7_verify. 

Post the problem certificate (obviously without its associated
private key).

-- 
	Viktor.

From CONRAD.G.WELLING at leidos.com  Wed Mar  4 22:33:52 2015
From: CONRAD.G.WELLING at leidos.com (Welling, Gerhart Gerhart)
Date: Wed, 4 Mar 2015 22:33:52 +0000
Subject: [openssl-users] Is Pre-1.0.1k Client in FIPS Mode Vulnerable To
 CVE-2015-0204 (RSA silently downgrades to EXPORT_RSA)?
Message-ID: <ACAC08F2C2EBB74D821A378304FD5ECE43EE502C@EMP-EXMR102.corp.leidos.com>

I'm partly into researching FREAK, then, realize an answer - or, better, an explanation - might be available at hand.  My first assumption was that FIPS-mode makes "International Step-Up" impossible.  Right?

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

From amit.chaudhuri at bt.com  Thu Mar  5 10:16:39 2015
From: amit.chaudhuri at bt.com (amit.chaudhuri at bt.com)
Date: Thu, 5 Mar 2015 10:16:39 +0000
Subject: [openssl-users] Cross compiling openssl 1.0.1j for an imx53 ARM
	processor
Message-ID: <1425550599222.7110@bt.com>

Hi,


First attempt to cross compile openssl 1.0.1j for an imx53 ARM target. We use -march=armv7-a -mfpu=neon flags when compiling other libraries and our own apps. Looking at the Configure script the closest match I could find is linux-armv4 so my configure line is:

./Configure --prefix=<path> threads no-shared linux-armv4

I get repeated link errors citing undefined references to gcm_gmult_neon and gcm_ghash_neon. The offending code is in gcm128.c. I can see these symbols are defined in ghash-armv4.S but I don't understand why I'm in this position. Strong suspicion is that I've done something wrong. Are there special configure options that I am missing?

Regards,
Amit


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

From dave_nirav84 at yahoo.com  Thu Mar  5 11:11:10 2015
From: dave_nirav84 at yahoo.com (dave nirav)
Date: Thu, 5 Mar 2015 11:11:10 +0000 (UTC)
Subject: [openssl-users] Openssl upgrade
In-Reply-To: <20150304172630.GW1260@mournblade.imrryr.org>
References: <20150304172630.GW1260@mournblade.imrryr.org>
Message-ID: <812468969.3252543.1425553871139.JavaMail.yahoo@mail.yahoo.com>

Hi Victor,
I? am getting following error while verifying the certificate:?"error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm ,handle_error"
PKCS7_verify call is getting failed.

I have attached the certificate.
Thanks,Nirav Dave
 

     On Wednesday, March 4, 2015 11:04 PM, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
   

 On Wed, Mar 04, 2015 at 07:43:16AM +0000, dave nirav wrote:

> This is probably the first mail in this group.
> I am upgrading my openssl product from 0.9.8e openssl which is having base as centos 5.6 to 1.0.1e openssl which has base os as centos 7.0. 
> 
> I have successfully compiled my code with ssl Lib API's which was used with 0.9.8 e. 
> 
> I am facing unknown digest error from ASN1 while verifying certificate from client using PKCS7_verify. 

Post the problem certificate (obviously without its associated
private key).

-- 
??? Viktor.
_______________________________________________
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/20150305/0e66ae6f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sslcert.cer
Type: application/octet-stream
Size: 627 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150305/0e66ae6f/attachment.obj>

From minfrin at sharp.fm  Thu Mar  5 11:28:00 2015
From: minfrin at sharp.fm (Graham Leggett)
Date: Thu, 5 Mar 2015 13:28:00 +0200
Subject: [openssl-users] OpenSSL and detecting whether bugs have been patched
Message-ID: <8B1ED467-BD6B-4FB6-8553-FC5D16DA64BC@sharp.fm>

Hi all,

I just tried out the most recent version of freeradius (v3.0.7), and it failed to start up with the following message:

Thu Mar  5 11:12:33 2015 : Info: Debugger not attached
Thu Mar  5 11:12:33 2015 : Error: Refusing to start with libssl version OpenSSL 1.0.1e-fips 11 Feb 2013 0x1000105f (1.0.1e release) (in range 1.0.1 dev - 1.0.1f release)
Thu Mar  5 11:12:33 2015 : Error: Security advisory CVE-2014-0160 (Heartbleed)
Thu Mar  5 11:12:33 2015 : Error: For more information see http://heartbleed.com
Thu Mar  5 11:12:33 2015 : Info: Once you have verified libssl has been correctly patched, set security.allow_vulnerable_openssl = 'CVE-2014-0160?

While the idea behind the check is sound (it would be great if people cared about this stuff) the implementation is rather crude - all freeradius has to go on to implement a check like this is to compare version numbers, and in this case the version numbers tell us it is unpatched when in reality this CentOS7 provided openssl package actually is patched.

Would it be a good idea to add a simple API to the openssl code that define whether specific security flaws are patched or not, allowing other software to explicitly check for them? A vendor like Redhat then has the chance to patch the older version and add the extra detail to indicate that the particular vulnerability is patched in this particular version, like this:

int openssl_is_patched(const char *cve);

if (!openssl_is_patched("CVE-2014-0160?)) {
   complain_vociferously();
}

Thoughts? Glaring holes I have not thought of?

Regards,
Graham
?


From dave_nirav84 at yahoo.com  Thu Mar  5 11:57:34 2015
From: dave_nirav84 at yahoo.com (dave nirav)
Date: Thu, 5 Mar 2015 11:57:34 +0000 (UTC)
Subject: [openssl-users] Fw:  Openssl upgrade
In-Reply-To: <1138036752.1425554463946@ace.smi>
References: <1138036752.1425554463946@ace.smi>
Message-ID: <585020733.3283064.1425556654280.JavaMail.yahoo@mail.yahoo.com>



      On Thursday, March 5, 2015 4:51 PM, "postmaster at disney.com" <postmaster at disney.com> wrote:
   

 550 5.1.2 ... Message Not delivered due to restricted attachment

***? NOTICE? ***? ? ***? NOTICE? ***? ? ***? NOTICE? ***? ? ***? NOTICE ***? ? 

The message you sent:
RECIPIENT(s):? Steven.Seed at disney.com
SUBJECT: Re: [openssl-users] Openssl upgrade
Message ID: ,message]

has been trapped and automatically deleted due to its attachments.

Due to the risk posed by e-mail viruses we are not accepting messages that have any of the following attachment types:? 

ade adp app asp aspx asx bas

bat cer chm cmd com cpl csh

dll exe hlp hta htmlx inf ins isp 

its js jse ksh lnk mad maf mag 

mam maq mar mas mat mau 

mav maw mda mde mdt mdw 

mdz mht mhtml msc msi msp 

mst ops pcd pif prf prg pst reg 

scf scr sct shb shs tmp url vb 

vbe vbs vsmacro vss vst vsw 

ws wsc wsf wsh? 

disney/mh/emt/ 192.195.66.36


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

From rsalz at akamai.com  Thu Mar  5 12:23:41 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 5 Mar 2015 12:23:41 +0000
Subject: [openssl-users] OpenSSL and detecting whether bugs have been
 patched
In-Reply-To: <8B1ED467-BD6B-4FB6-8553-FC5D16DA64BC@sharp.fm>
References: <8B1ED467-BD6B-4FB6-8553-FC5D16DA64BC@sharp.fm>
Message-ID: <fe02a280c26e4f76813aae053c42b1e4@ustx2ex-dag1mb2.msg.corp.akamai.com>


> if (!openssl_is_patched("CVE-2014-0160?)) {
>    complain_vociferously();
> }

That's an interesting idea.  Of course the CVE list would grow, so perhaps arrays of ints are better
	Int OPENSSL_cve_fixed(int year, int vuln);;

?


From steve at openssl.org  Thu Mar  5 12:43:15 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 5 Mar 2015 12:43:15 +0000
Subject: [openssl-users] Is Pre-1.0.1k Client in FIPS Mode Vulnerable To
 CVE-2015-0204 (RSA silently downgrades to EXPORT_RSA)?
In-Reply-To: <ACAC08F2C2EBB74D821A378304FD5ECE43EE502C@EMP-EXMR102.corp.leidos.com>
References: <ACAC08F2C2EBB74D821A378304FD5ECE43EE502C@EMP-EXMR102.corp.leidos.com>
Message-ID: <20150305124315.GA16420@openssl.org>

On Wed, Mar 04, 2015, Welling, Gerhart Gerhart wrote:

> I'm partly into researching FREAK, then, realize an answer - or, better, an explanation - might be available at hand.  My first assumption was that FIPS-mode makes "International Step-Up" impossible.  Right?
> 

Among other things FIPS mode prohibits operations on RSA keys smaller than
1024 bits so a client would not accept a SKE message using a 512 bit RSA
temporary key.

For servers all export ciphersuites are disabled in FIPS mode.

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

From devel at jasonwoods.me.uk  Thu Mar  5 13:28:54 2015
From: devel at jasonwoods.me.uk (Jason Woods)
Date: Thu, 5 Mar 2015 13:28:54 +0000
Subject: [openssl-users] OpenSSL and detecting whether bugs have been
	patched
In-Reply-To: <fe02a280c26e4f76813aae053c42b1e4@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8B1ED467-BD6B-4FB6-8553-FC5D16DA64BC@sharp.fm>
 <fe02a280c26e4f76813aae053c42b1e4@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <406DF7C7-ED5F-44D9-A6DB-BF332D4B3D80@jasonwoods.me.uk>


> On 5 Mar 2015, at 12:23, Salz, Rich <rsalz at akamai.com> wrote:
>> if (!openssl_is_patched("CVE-2014-0160?)) {
>>   complain_vociferously();
>> }
> 
> That's an interesting idea.  Of course the CVE list would grow, so perhaps arrays of ints are better
> 	Int OPENSSL_cve_fixed(int year, int vuln);;
> 
> ?

This feels onerous... I think this would only affect vendors who release their own patched versions. OpenSSL team should probably not have to deal with their problems; using latest version of upstream OpenSSL you'd be fine to verify the version number.
Maybe it's just a case of the vendor (RedHat etc.) should come up with a solution - a /usr/share/openssl/heartbleed_fixed file added to the package, or a /usr/share/openssl/patchlist file containing list of patches applied. Freeradius can then check this based on the distribution's way of dealing with it.

Jason

From steved499 at yahoo.com  Thu Mar  5 15:05:51 2015
From: steved499 at yahoo.com (Steve d)
Date: Thu, 5 Mar 2015 15:05:51 +0000 (UTC)
Subject: [openssl-users] 1.0.2 FIPS help
Message-ID: <519286779.4968082.1425567951732.JavaMail.yahoo@mail.yahoo.com>

Hi,
We are trying to upgrade from 0.9.8 to 1.0.2 and it seems that the fips process has changed.

Based on the user guide if I can get the canister to build on any platform with no changes, I can make the the user affirmation from page 59 even if that platform is not on the supported platform list?
We need to build a 32 bit FIPS canister for some legacy code but we don't have any 32 bit hardware. The way I'm reading the section on cross-compiling is that I can set whatever environment variables I want to get the configure script to take the right branch as long as I don't modify it. If the resulting platform is not supported then I can add an affirmation to my documentation and be on my way?
Thank you in advance for your time


?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150305/526ba772/attachment-0001.html>

From marquess at openssl.com  Thu Mar  5 16:04:50 2015
From: marquess at openssl.com (Steve Marquess)
Date: Thu, 05 Mar 2015 11:04:50 -0500
Subject: [openssl-users] 1.0.2 FIPS help
In-Reply-To: <519286779.4968082.1425567951732.JavaMail.yahoo@mail.yahoo.com>
References: <519286779.4968082.1425567951732.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <54F87EA2.4010602@openssl.com>

On 03/05/2015 10:05 AM, Steve d wrote:
> Hi,
> 
> We are trying to upgrade from 0.9.8 to 1.0.2 and it seems that the fips
> process has changed.
> 
> Based on the user guide if I can get the canister to build on any
> platform with no changes, I can make the the user affirmation from page
> 59 even if that platform is not on the supported platform list?

Yes, that's a typical use of the I.G. G.5 "user affirmation".

Note that not all USG/DoD customers will accept user affirmation, but it
is a legitimate option per FIPS 140-2 scripture.

> We need to build a 32 bit FIPS canister for some legacy code but we
> don't have any 32 bit hardware. The way I'm reading the section on
> cross-compiling is that I can set whatever environment variables I want
> to get the configure script to take the right branch as long as I don't
> modify it. If the resulting platform is not supported then I can add an
> affirmation to my documentation and be on my way?

The "32-bit" and "64-bit" references you see in the list of platforms
("Operational Environments") are to the object code word size, not
necessarily the processor word size. Note the multiple 32-bit platform
entries for 64-bit x86-64 processors.

Also note the nature of the build system used for cross-compilations
(processor, OS, etc.) is irrelevant. What does matter is that during
that build process you use the canonical incantation, e.g.:

  gunzip -c openssl-fips-2.0.9.tar.gz | tar xf -
  cd openssl-fips-2.0.9
  ./config
  make
  make install

exactly as documented.

-Steve M.

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

From christian.georg at cologne-intelligence.de  Fri Mar  6 14:05:34 2015
From: christian.georg at cologne-intelligence.de (Christian Georg)
Date: Fri, 6 Mar 2015 14:05:34 +0000
Subject: [openssl-users] Getting info on the ciphers supported by a client
Message-ID: <2817978485862A44A634556C7E6914847D2A19@w2k8-sys-dc01.co-in.local>

Hi all,

I am trying to get detailed info on the protocols and cipher suites supported by a client app. Main goal is to verify that the constraints on protocols versions and cipher suites we are using within an app are working correctly. (so it is not about the cipher suites that are theoretically available on a mobile device)
I was planning to use openssl s_server for this task. I am opening s_server on different ports each with a specific protocol version (-ssl2, -ssl3, -tls1...). On some of the ports a handshake should be successful on others not.

The tricky part are the supported cipher suites. When using the -www option I can return a website to the client showing the cipher suites that provide a match, which gets pretty close to what I want in a browser. Now here are my challenges.

Challenge 1: Getting a list of ALL Ciphersuites
I would like to get info on all cipher suites supported (preferred) by the client . The -www option does only show the cipher suites with a match. So any cipher suite not supported by openssl will not be listed. When checking my browser with qualys SSl Lab I noticed that the following three ciphersuites are showing up on the qualys report but not on the s_server page.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

I do not see them as a risk, but what if some exotic weak ciphers are enabled within the app. It is my understanding that during a handshake a list of all preferred ciphers is send from the client to the server. How can I get access to this info?

Challenge 2: How do I get the info into a log file on the server rather than sending it back as a website?
The approach described above is working fine for browsers but what about consuming webservices? I am able to redirect the webservices to my openssl s_server and perform the handshake (even so the SOAP or REST Interface will then throw an error). But I could not find an option on getting the info written into the Logfile (in a human readable way) even with all logging I found enabled (-state -debug -msg -tlsextdebug -trace) I could not find the info in a human readable way.

Any recommendations on how I can solve my issues without changing the openssl code and add this manually?

Cheers

Chris

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

From zakkir.kharim at gmail.com  Fri Mar  6 10:17:16 2015
From: zakkir.kharim at gmail.com (zakkir hussain Kharim)
Date: Fri, 6 Mar 2015 15:47:16 +0530
Subject: [openssl-users] openssl_tpm_engine - create_tpm_key failed when
 tried to wrap key
In-Reply-To: <mcpst0$o77$1@ger.gmane.org>
References: <CAP0K13-FoyycEVXhuVKh+y4yT72a==2Wjv4uC+dYi3LxOw0jkA@mail.gmail.com>
 <mcpst0$o77$1@ger.gmane.org>
Message-ID: <CAP0K138KbTWguv0YK7+oKu=T5Y8dfcnBvpZPuCvRVQpLd77Tdg@mail.gmail.com>

We ran the same command with both software TPM and hardware TPM.

Please find the detailed debug logs from the tcsd attached. Also copied the
relevant portions.  For API  GetPubKey, software TPM works fine and in thsi
case it seems an 'ioctl' call is made compared to a write in case of actual
TPM.







Software TPM:



TCSD TCS tcs_key_mem_cache.c:167 keySlot is 40000000

TCSD TCS tcs_key_mem_cache.c:874 mc_update_time_stamp: TCSD mem_cached
handle: 0x40000000

TCSD TCS tcs_key_mem_cache.c:192 ensureKeyIsLoaded: Exit

TCSD TCS tcsi_key.c:254 GetPubKey: handle: 0x40000000, slot: 0x40000000

TCSD TCS tcsi_key.c:260

My Log: tcsi_key.c:tpm_rqu_buildtpm_rqu_build :result=0



To TPM: 00 C2 00 00 00 3B 00 00 00 21 40 00 00 00 02 00

To TPM: 00 00 7E 3D AE A9 13 CF 83 D7 27 56 A3 F3 C4 09

To TPM: 4F 81 FB 81 F8 C0 00 D4 C0 ED C4 68 67 45 FB FF

To TPM: B2 FC 51 B7 5A 7B DB E1 64 3D 73

TCSD TDDL tddl.c:171 Calling write to driver

TCSD TDDL tddl.c:183  Transmit Type: TDDL_TRANSMIT_IOCTL

>From TPM: 00 C5 00 00 01 4F 00 00 00 00 00 00 00 01 00 03

>From TPM: 00 01 00 00 00 0C 00 00 08 00 00 00 00 02 00 00





Hareware TPM:



TCSD TCS tcsi_key.c:254 GetPubKey: handle: 0x40000000, slot: 0x40000000

TCSD TCS tcsi_key.c:260

My Log: tcsi_key.c:tpm_rqu_buildtpm_rqu_build :result=0



To TPM: 00 C2 00 00 00 3B 00 00 00 21 40 00 00 00 00 4F

To TPM: F1 C6 5A 89 4D D3 43 81 32 CC CA B7 C0 BB 8A F4

To TPM: BC 98 C9 BC 8A 01 00 C6 FB 7D 86 4D 0E 9F E5 62

To TPM: 12 85 E3 04 73 C1 56 20 01 B0 48

TCSD TDDL tddl.c:171 Calling write to driver

TCSD TDDL tddl.c:193  Transmit Type: TDDL_TRANSMIT_RW

>From TPM: 00 C4 00 00 00 0A 00 00 00 0C

TCSD TCS tcsi_key.c:265

My Log: tcsi_key.c:req_mgr_submit_req :result=0



LOG_RETERR TPM tcsi_key.c:267: 0xc

TCSD TCS tcsi_key.c:268

My Log: tcsi_key.c:UnloadBlob_Header : result=12



To TPM: 00 C1 00 00 00 12 00 00 00 BA 00 4F F1 C6 00 00

To TPM: 00 02

TCSD TDDL tddl.c:171 Calling write to driver

TCSD TDDL tddl.c:193  Transmit Type: TDDL_TRANSMIT_RW

>From TPM: 00 C4 00 00 00 0A 00 00 00 22

LOG_RETERR TPM tcsi_admin.c:464: 0x22

TCSD TCS tcs_auth_mgr.c:287 Tried to close an invalid auth handle: 4ff1c6





src/tddl/tddl.c : Tddli_TransmitData



switch (opened_device->transmit) {

                case TDDL_UNDEF:

                        /* fall through */

                case TDDL_TRANSMIT_IOCTL:

                        LogDebug(" Transmit Type: TDDL_TRANSMIT_IOCTL");

                        errno = 0;

                        if ((sizeResult = ioctl(opened_device->fd,
TPMIOC_TRANSMIT, txBuffer)) != -1) {

                                opened_device->transmit =
TDDL_TRANSMIT_IOCTL;

                                break;

                        }

                        LogWarn("ioctl: (%d) %s", errno, strerror(errno));

                        LogInfo("Falling back to Read/Write device
support.");

                        /* fall through */

                case TDDL_TRANSMIT_RW:

                        LogDebug(" Transmit Type: TDDL_TRANSMIT_RW");

                        if ((sizeResult = write(opened_device->fd,

                                                txBuffer,

                                                TransmitBufLen)) ==
(int)TransmitBufLen) {

                                opened_device->transmit = TDDL_TRANSMIT_RW;

                                sizeResult = read(opened_device->fd,
txBuffer,

                                                  TDDL_TXBUF_SIZE);

                                break;



On Fri, Feb 27, 2015 at 7:23 PM, Ken Goldman <kgoldman at us.ibm.com> wrote:

> I don't know  trousers very well, but there is a mailing list specifically
> for it.
>
> trousers supports the software TPM from
>
>         http://sourceforge.net/projects/ibmswtpm/
>
> If you run with that, it traces the TPM operation in detail.  Send me the
> trace and I can probably tell you what's wrong.
>
> On 2/27/2015 12:16 AM, zakkir hussain Kharim wrote:
>
>> *Problem*
>>
>> We are trying to wrap a private key using storage root key using the
>> "create_tpm_key" tool which is part of openssl tpm engine. But it is
>> failing. We tried to debug this in multiple ways, but not able to
>> understand what is wrong*. * We are trying to wrap using Storage root
>> key. Input private key is a 2048 bit length RSA key without any
>> passphrase. The failure seems to related to getting public key of SRK
>> from the SRK handle loaded.
>>
>
>
> _______________________________________________
> 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/20150306/d1e5a871/attachment-0001.html>
-------------- next part --------------
TCSD svrside.c:556 accepted socket 7
TCSD svrside.c:531 Waiting for connections
TCSD tcsd_threads.c:232 total_recv_size 28, buf_size 1024, recd_so_far 28
TCSD tcsd_threads.c:284 Rx'd packet
TCSD TCS rpc/tcstp/rpc.c:582 Dispatching ordinal 1 (OpenContext)
TCSD TCS rpc/tcstp/rpc_context.c:37 tcs_wrap_OpenContext: thread 140136657467136
TCSD TCS rpc/tcstp/rpc_context.c:53 New context is 0xa0d3ec03
TCSD tcsd_threads.c:313 Sending 0x26 bytes back
TCSD tcsd_threads.c:232 total_recv_size 168, buf_size 1024, recd_so_far 28
TCSD tcsd_threads.c:277 recv_chunk_size 140 recd_so_far 28
TCSD tcsd_threads.c:284 Rx'd packet
TCSD TCS rpc/tcstp/rpc.c:582 Dispatching ordinal 12 (LoadKeyByUUID)
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 0 .
TCSD TCS rpc/tcstp/rpc_ps.c:181 tcs_wrap_LoadKeyByUUID: thread 140136657467136 context a0d3ec03
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 1 .
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 2 .
TCSD TCS tcsi_ps.c:518 TCSP_LoadKeyByUUID_Internal: Enter: uuid: 0x7f741bb02d80 auth? 0x0 ***********
TCSD TCS tcs_key_mem_cache.c:639 key_mgr_inc_ref_count: TCSD mem_cached handle: 0x40000000
TCSD TCS tcs_ps.c:170 Key successfully loaded by UUID w/ TCS handle: 0x40000000
TCSD tcsd_threads.c:313 Sending 0x97 bytes back
TCSD tcsd_threads.c:232 total_recv_size 50, buf_size 1024, recd_so_far 28
TCSD tcsd_threads.c:277 recv_chunk_size 22 recd_so_far 28
TCSD tcsd_threads.c:284 Rx'd packet
TCSD TCS rpc/tcstp/rpc.c:582 Dispatching ordinal 9 (GetRegisteredKeyBlob)
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 0 .
TCSD TCS rpc/tcstp/rpc_ps.c:140 tcs_wrap_GetRegisteredKeyBlob: thread 140136657467136 context a0d3ec03
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 1 .
TCSD TCS ps/tcsps.c:191 psfile_get_key_by_uuid: Version: 1.1.0.0
TCSD TCS ps/tcsps.c:191 psfile_get_key_by_uuid: keyUsage: 0x11
TCSD TCS ps/tcsps.c:191 psfile_get_key_by_uuid: keyFlags: 0x0
TCSD TCS ps/tcsps.c:191 psfile_get_key_by_uuid: authDatausage: 1
TCSD TCS ps/tcsps.c:191 psfile_get_key_by_uuid: pcrInfosize: 0
TCSD TCS ps/tcsps.c:191 psfile_get_key_by_uuid: encDataSize: 0
TCSD tcsd_threads.c:313 Sending 0x151 bytes back
TCSD tcsd_threads.c:232 total_recv_size 33, buf_size 1024, recd_so_far 28
TCSD tcsd_threads.c:277 recv_chunk_size 5 recd_so_far 28
TCSD tcsd_threads.c:284 Rx'd packet
TCSD TCS rpc/tcstp/rpc.c:582 Dispatching ordinal 23 (OIAP)
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 0 .
TCSD TCS rpc/tcstp/rpc_auth.c:44 tcs_wrap_OIAP: thread 140136657467136 context a0d3ec03
TCSD TCS tcsi_auth.c:40 Entering TCSI_OIAP
To TPM: 00 C1 00 00 00 0A 00 00 00 0A 
TCSD TDDL tddl.c:171 Calling write to driver
TCSD TDDL tddl.c:183  Transmit Type: TDDL_TRANSMIT_IOCTL
From TPM: 00 C4 00 00 00 22 00 00 00 00 02 00 00 00 80 ED 
From TPM: 36 4D 00 F4 F0 81 3B C3 45 38 81 A2 CC 61 58 F8 
From TPM: 58 FB 
TCSD TCS tcs_auth_mgr.c:383 added auth for TCS a0d3ec03 TPM 2000000
TCSD tcsd_threads.c:313 Sending 0x36 bytes back
TCSD tcsd_threads.c:232 total_recv_size 84, buf_size 1024, recd_so_far 28
TCSD tcsd_threads.c:277 recv_chunk_size 56 recd_so_far 28
TCSD tcsd_threads.c:284 Rx'd packet
TCSD TCS rpc/tcstp/rpc.c:582 Dispatching ordinal 15 (GetPubkey)
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 0 .
TCSD TCS rpc/tcstp/rpc_key.c:78 tcs_wrap_GetPubkey: thread 140136657467136 context a0d3ec03
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 1 .
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 2 .
TCSD TCS tcsi_key.c:237 Entering Get pub key
TCSD TCS tcsi_key.c:242 Auth Used
TCSD TCS tcs_key_mem_cache.c:159 ensureKeyIsLoaded: 0x40000000
TCSD TCS tcs_key_mem_cache.c:718 mc_get_slot_by_handle: TCSD mem_cached handle: 0x40000000
TCSD TCS tcs_key_mem_cache.c:167 keySlot is 40000000
TCSD TCS tcs_key_mem_cache.c:874 mc_update_time_stamp: TCSD mem_cached handle: 0x40000000
TCSD TCS tcs_key_mem_cache.c:192 ensureKeyIsLoaded: Exit
TCSD TCS tcsi_key.c:254 GetPubKey: handle: 0x40000000, slot: 0x40000000
TCSD TCS tcsi_key.c:260 
My Log: tcsi_key.c:tpm_rqu_buildtpm_rqu_build :result=0

To TPM: 00 C2 00 00 00 3B 00 00 00 21 40 00 00 00 02 00 
To TPM: 00 00 7E 3D AE A9 13 CF 83 D7 27 56 A3 F3 C4 09 
To TPM: 4F 81 FB 81 F8 C0 00 D4 C0 ED C4 68 67 45 FB FF 
To TPM: B2 FC 51 B7 5A 7B DB E1 64 3D 73 
TCSD TDDL tddl.c:171 Calling write to driver
TCSD TDDL tddl.c:183  Transmit Type: TDDL_TRANSMIT_IOCTL
From TPM: 00 C5 00 00 01 4F 00 00 00 00 00 00 00 01 00 03 
From TPM: 00 01 00 00 00 0C 00 00 08 00 00 00 00 02 00 00 
From TPM: 00 00 00 00 01 00 A5 21 5D 78 0F 06 7C AF EF 97 
From TPM: 4F 0A ED 71 5B C0 33 E1 A9 26 13 59 F1 4A 66 13 
From TPM: 9A DF CF 41 E5 E0 BF 65 50 4A 65 F5 B0 23 F7 CF 
From TPM: AC 75 E9 71 DA 31 18 E0 BD E3 D0 48 97 B1 9A 1C 
From TPM: 13 0F 5D CC B2 9D 46 95 EB CB 0E AE D8 27 59 A3 
From TPM: BA C9 44 97 0A AF 74 95 00 86 45 6D 15 34 2D 9A 
From TPM: 2D DE 3C E0 85 20 EB 08 18 99 25 02 3F 86 3F 9E 
From TPM: 15 16 E9 9F 0E C9 CF 0D AB 1F 28 F0 A9 E9 80 2D 
From TPM: 03 C9 92 35 7F 73 7F 44 29 EF A8 58 E4 9D 7E 20 
From TPM: 89 48 92 0B 20 63 20 D2 6D 56 CD B1 47 B6 07 0D 
From TPM: D0 17 BD CD 64 92 1D B8 EA AE 44 40 E5 85 12 F1 
From TPM: 0A 7B 82 FC 8C 6F E0 41 0A F5 82 81 7E 45 26 75 
From TPM: D1 A4 8E 73 AC 21 D5 E4 58 F7 4C F1 08 95 37 38 
From TPM: C7 CC F7 7C F0 3B A4 64 42 13 AD 68 C7 EB 46 AD 
From TPM: 5E 8E 1F B9 84 6A 62 F7 B8 8C 17 9E 12 35 08 84 
From TPM: 3E BD 6C 25 05 DB C1 8C 86 50 08 8F 69 D3 9A E5 
From TPM: 80 67 4D DD 7C DB 13 00 6F 17 3E 5D 82 A9 1B 81 
From TPM: 05 C4 D5 DE BA 62 D1 B9 66 31 00 8F 48 06 65 84 
From TPM: 90 38 9A 97 84 A2 DA 60 6A AC 4E 0F C1 8E DF 
TCSD TCS tcsi_key.c:265 
My Log: tcsi_key.c:req_mgr_submit_req :result=0

TCSD TCS tcsi_key.c:268 
My Log: tcsi_key.c:UnloadBlob_Header : result=0

TCSD TCS tcsi_key.c:271 
My Log: tcsi_key.c:UnloadBlob_Header :result=0

TCSD TCS tcsi_key.c:274 
My Log: tcsi_key.c:tpm_rsp_parse :result=0

To TPM: 00 C1 00 00 00 12 00 00 00 BA 02 00 00 00 00 00 
To TPM: 00 02 
TCSD TDDL tddl.c:171 Calling write to driver
TCSD TDDL tddl.c:183  Transmit Type: TDDL_TRANSMIT_IOCTL
From TPM: 00 C4 00 00 00 0A 00 00 00 00 
TCSD TCS tcs_auth_mgr.c:294 released auth for TCS a0d3ec03 TPM 2000000
TCSD TCS tcs_auth_mgr.c:118 no threads need to be signaled.
TCSD tcsd_threads.c:313 Sending 0x168 bytes back
TCSD tcsd_threads.c:232 total_recv_size 33, buf_size 1024, recd_so_far 28
TCSD tcsd_threads.c:277 recv_chunk_size 5 recd_so_far 28
TCSD tcsd_threads.c:284 Rx'd packet
TCSD TCS rpc/tcstp/rpc.c:582 Dispatching ordinal 2 (CloseContext)
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 0 .
TCSD TCS rpc/tcstp/rpc_context.c:71 tcs_wrap_CloseContext: thread 140136657467136 context a0d3ec03
TCSD TCS tcsi_context.c:39 Closing context A0D3EC03
TCSD TCS tcs_key_mem_cache.c:663 key_mgr_dec_ref_count: decrementing ref cnt for key 0x40000000
TCSD TCS tcsi_context.c:51 Context A0D3EC03 closed
TCSD tcsd_threads.c:313 Sending 0x1C bytes back
TCSD TCS rpc/tcstp/rpc.c:68 Socket connection closed.
TCSD tcsd_threads.c:325 Thread exiting.
-------------- next part --------------
TCSD TCS tcs_caps.c:138 get_max_auths reports 20 auth contexts found
TCSD TCS tcsi_caps_tpm.c:43 Entering Get Cap
To TPM: 00 C1 00 00 00 12 00 00 00 65 00 00 00 07 00 00 
To TPM: 00 00 
TCSD TDDL tddl.c:171 Calling write to driver
TCSD TDDL tddl.c:193  Transmit Type: TDDL_TRANSMIT_RW
From TPM: 00 C4 00 00 00 10 00 00 00 00 00 00 00 02 00 00 
TCSD svrside.c:493 trousers 0.3.13: TCSD up and running.
TCSD svrside.c:531 Waiting for connections
TCSD svrside.c:556 accepted socket 7
TCSD svrside.c:531 Waiting for connections
TCSD tcsd_threads.c:232 total_recv_size 28, buf_size 1024, recd_so_far 28
TCSD tcsd_threads.c:284 Rx'd packet
TCSD TCS rpc/tcstp/rpc.c:582 Dispatching ordinal 1 (OpenContext)
TCSD TCS rpc/tcstp/rpc_context.c:37 tcs_wrap_OpenContext: thread 140507518138112
TCSD TCS rpc/tcstp/rpc_context.c:53 New context is 0xa0751200
TCSD tcsd_threads.c:313 Sending 0x26 bytes back
TCSD tcsd_threads.c:232 total_recv_size 168, buf_size 1024, recd_so_far 28
TCSD tcsd_threads.c:277 recv_chunk_size 140 recd_so_far 28
TCSD tcsd_threads.c:284 Rx'd packet
TCSD TCS rpc/tcstp/rpc.c:582 Dispatching ordinal 12 (LoadKeyByUUID)
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 0 .
TCSD TCS rpc/tcstp/rpc_ps.c:181 tcs_wrap_LoadKeyByUUID: thread 140507518138112 context a0751200
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 1 .
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 2 .
TCSD TCS tcsi_ps.c:518 TCSP_LoadKeyByUUID_Internal: Enter: uuid: 0x7fca74b4ed80 auth? 0x0 ***********
TCSD TCS tcs_key_mem_cache.c:639 key_mgr_inc_ref_count: TCSD mem_cached handle: 0x40000000
TCSD TCS tcs_ps.c:170 Key successfully loaded by UUID w/ TCS handle: 0x40000000
TCSD tcsd_threads.c:313 Sending 0x97 bytes back
TCSD tcsd_threads.c:232 total_recv_size 50, buf_size 1024, recd_so_far 28
TCSD tcsd_threads.c:277 recv_chunk_size 22 recd_so_far 28
TCSD tcsd_threads.c:284 Rx'd packet
TCSD TCS rpc/tcstp/rpc.c:582 Dispatching ordinal 9 (GetRegisteredKeyBlob)
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 0 .
TCSD TCS rpc/tcstp/rpc_ps.c:140 tcs_wrap_GetRegisteredKeyBlob: thread 140507518138112 context a0751200
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 1 .
TCSD TCS ps/tcsps.c:191 psfile_get_key_by_uuid: Version: 1.1.0.0
TCSD TCS ps/tcsps.c:191 psfile_get_key_by_uuid: keyUsage: 0x11
TCSD TCS ps/tcsps.c:191 psfile_get_key_by_uuid: keyFlags: 0x0
TCSD TCS ps/tcsps.c:191 psfile_get_key_by_uuid: authDatausage: 1
TCSD TCS ps/tcsps.c:191 psfile_get_key_by_uuid: pcrInfosize: 0
TCSD TCS ps/tcsps.c:191 psfile_get_key_by_uuid: encDataSize: 0
TCSD tcsd_threads.c:313 Sending 0x151 bytes back
TCSD tcsd_threads.c:232 total_recv_size 33, buf_size 1024, recd_so_far 28
TCSD tcsd_threads.c:277 recv_chunk_size 5 recd_so_far 28
TCSD tcsd_threads.c:284 Rx'd packet
TCSD TCS rpc/tcstp/rpc.c:582 Dispatching ordinal 23 (OIAP)
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 0 .
TCSD TCS rpc/tcstp/rpc_auth.c:44 tcs_wrap_OIAP: thread 140507518138112 context a0751200
TCSD TCS tcsi_auth.c:40 Entering TCSI_OIAP
To TPM: 00 C1 00 00 00 0A 00 00 00 0A 
TCSD TDDL tddl.c:171 Calling write to driver
TCSD TDDL tddl.c:193  Transmit Type: TDDL_TRANSMIT_RW
From TPM: 00 C4 00 00 00 22 00 00 00 00 00 4F F1 C6 CE C6 
From TPM: F7 14 6A BC A6 10 7E E3 E4 9C 55 11 DC 01 AE 1F 
From TPM: 8D 1C 
TCSD TCS tcs_auth_mgr.c:383 added auth for TCS a0751200 TPM 4ff1c6
TCSD tcsd_threads.c:313 Sending 0x36 bytes back
TCSD tcsd_threads.c:232 total_recv_size 84, buf_size 1024, recd_so_far 28
TCSD tcsd_threads.c:277 recv_chunk_size 56 recd_so_far 28
TCSD tcsd_threads.c:284 Rx'd packet
TCSD TCS rpc/tcstp/rpc.c:582 Dispatching ordinal 15 (GetPubkey)
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 0 .
TCSD TCS rpc/tcstp/rpc_key.c:78 tcs_wrap_GetPubkey: thread 140507518138112 context a0751200
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 1 .
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 2 .
TCSD TCS tcsi_key.c:237 Entering Get pub key
TCSD TCS tcsi_key.c:242 Auth Used
TCSD TCS tcs_key_mem_cache.c:159 ensureKeyIsLoaded: 0x40000000
TCSD TCS tcs_key_mem_cache.c:718 mc_get_slot_by_handle: TCSD mem_cached handle: 0x40000000
TCSD TCS tcs_key_mem_cache.c:167 keySlot is 40000000
TCSD TCS tcs_key_mem_cache.c:874 mc_update_time_stamp: TCSD mem_cached handle: 0x40000000
TCSD TCS tcs_key_mem_cache.c:192 ensureKeyIsLoaded: Exit
TCSD TCS tcsi_key.c:254 GetPubKey: handle: 0x40000000, slot: 0x40000000
TCSD TCS tcsi_key.c:260 
My Log: tcsi_key.c:tpm_rqu_buildtpm_rqu_build :result=0

To TPM: 00 C2 00 00 00 3B 00 00 00 21 40 00 00 00 00 4F 
To TPM: F1 C6 5A 89 4D D3 43 81 32 CC CA B7 C0 BB 8A F4 
To TPM: BC 98 C9 BC 8A 01 00 C6 FB 7D 86 4D 0E 9F E5 62 
To TPM: 12 85 E3 04 73 C1 56 20 01 B0 48 
TCSD TDDL tddl.c:171 Calling write to driver
TCSD TDDL tddl.c:193  Transmit Type: TDDL_TRANSMIT_RW
From TPM: 00 C4 00 00 00 0A 00 00 00 0C 
TCSD TCS tcsi_key.c:265 
My Log: tcsi_key.c:req_mgr_submit_req :result=0

LOG_RETERR TPM tcsi_key.c:267: 0xc
TCSD TCS tcsi_key.c:268 
My Log: tcsi_key.c:UnloadBlob_Header : result=12

To TPM: 00 C1 00 00 00 12 00 00 00 BA 00 4F F1 C6 00 00 
To TPM: 00 02 
TCSD TDDL tddl.c:171 Calling write to driver
TCSD TDDL tddl.c:193  Transmit Type: TDDL_TRANSMIT_RW
From TPM: 00 C4 00 00 00 0A 00 00 00 22 
LOG_RETERR TPM tcsi_admin.c:464: 0x22
TCSD TCS tcs_auth_mgr.c:287 Tried to close an invalid auth handle: 4ff1c6
TCSD TCS tcs_auth_mgr.c:118 no threads need to be signaled.
TCSD tcsd_threads.c:313 Sending 0x1C bytes back
TCSD tcsd_threads.c:232 total_recv_size 33, buf_size 1024, recd_so_far 28
TCSD tcsd_threads.c:277 recv_chunk_size 5 recd_so_far 28
TCSD tcsd_threads.c:284 Rx'd packet
TCSD TCS rpc/tcstp/rpc.c:582 Dispatching ordinal 2 (CloseContext)
TCSD TCS rpc/tcstp/rpc.c:234 My log: ******** Data type of TCS packet element 0 .
TCSD TCS rpc/tcstp/rpc_context.c:71 tcs_wrap_CloseContext: thread 140507518138112 context a0751200
TCSD TCS tcsi_context.c:39 Closing context A0751200
TCSD TCS tcs_key_mem_cache.c:663 key_mgr_dec_ref_count: decrementing ref cnt for key 0x40000000
TCSD TCS tcsi_context.c:51 Context A0751200 closed
TCSD tcsd_threads.c:313 Sending 0x1C bytes back
TCSD TCS rpc/tcstp/rpc.c:68 Socket connection closed.
TCSD tcsd_threads.c:325 Thread exiting.

From ivan.ristic at gmail.com  Fri Mar  6 19:19:57 2015
From: ivan.ristic at gmail.com (Ivan Ristic)
Date: Fri, 6 Mar 2015 19:19:57 +0000
Subject: [openssl-users] Getting info on the ciphers supported by a
	client
In-Reply-To: <2817978485862A44A634556C7E6914847D2A19@w2k8-sys-dc01.co-in.local>
References: <2817978485862A44A634556C7E6914847D2A19@w2k8-sys-dc01.co-in.local>
Message-ID: <CANHgQ8FzgqovLF0h=dwG=U5LCNrxD4FObrY7kPeXvHcYROUFAw@mail.gmail.com>

On Fri, Mar 6, 2015 at 2:05 PM, Christian Georg <
christian.georg at cologne-intelligence.de> wrote:

>  Hi all,
>

Christian,

I might be able to save you some time.

I wrote an SSL/TLS client test for the SSL Labs web site; you can find it
here: https://dev.ssllabs.com/ssltest/viewMyClient.html If you can visit
this page from the client/device and examine the output, you'll find there
everything you need to know. There are a couple of other similar services.
I keep a list here:
https://github.com/ssllabs/research/wiki/Assessment-Tools (look under
Client Assessment).

If you can't do that, you can install my Apache module called mod_sslhaf,
which will dump contents of ClientHello to the server log. This approach
isn't as good as the previous one, but might be good enough for your use
case. You can find the module here: https://github.com/ssllabs/sslhaf


 I am trying to get detailed info on the protocols and cipher suites
> supported by a client app. Main goal is to verify that the constraints on
> protocols versions and cipher suites we are using within an app are working
> correctly. (so it is not about the cipher suites that are theoretically
> available on a mobile device)
>
> I was planning to use openssl s_server for this task. I am opening
> s_server on different ports each with a specific protocol version (-ssl2,
> -ssl3, -tls1?). On some of the ports a handshake should be successful on
> others not.
>
>
>
> The tricky part are the supported cipher suites. When using the ?www
> option I can return a website to the client showing the cipher suites that
> provide a match, which gets pretty close to what I want in a browser. Now
> here are my challenges.
>
>
>
> Challenge 1: Getting a list of ALL Ciphersuites
>
> I would like to get info on all cipher suites supported (preferred) by the
> client . The ?www option does only show the cipher suites with a match. So
> any cipher suite not supported by openssl will not be listed. When checking
> my browser with qualys SSl Lab I noticed that the following three
> ciphersuites are showing up on the qualys report but not on the s_server
> page.
>
>
>
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>
> TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
>
> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
>
>
>
> I do not see them as a risk, but what if some exotic weak ciphers are
> enabled within the app. It is my understanding that during a handshake a
> list of all preferred ciphers is send from the client to the server. How
> can I get access to this info?
>
>
>
> Challenge 2: How do I get the info into a log file on the server rather
> than sending it back as a website?
>
> The approach described above is working fine for browsers but what about
> consuming webservices? I am able to redirect the webservices to my openssl
> s_server and perform the handshake (even so the SOAP or REST Interface will
> then throw an error). But I could not find an option on getting the info
> written into the Logfile (in a human readable way) even with all logging I
> found enabled (-state -debug -msg ?tlsextdebug -trace) I could not find the
> info in a human readable way.
>
>
>
> Any recommendations on how I can solve my issues without changing the
> openssl code and add this manually?
>
>
>
> Cheers
>
>
> Chris
>
>
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150306/420a86d8/attachment.html>

From steve at openssl.org  Fri Mar  6 20:04:48 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 6 Mar 2015 20:04:48 +0000
Subject: [openssl-users] Getting info on the ciphers supported by a
	client
In-Reply-To: <2817978485862A44A634556C7E6914847D2A19@w2k8-sys-dc01.co-in.local>
References: <2817978485862A44A634556C7E6914847D2A19@w2k8-sys-dc01.co-in.local>
Message-ID: <20150306200448.GA1692@openssl.org>

On Fri, Mar 06, 2015, Christian Georg wrote:

> 
> Any recommendations on how I can solve my issues without changing the openssl code and add this manually?
> 

I'm not sure OpenSSL can do exactly what you want: 1.0.2 has an option to
return the raw ciphersuite list sent by the client. The s_server utility
will print this out if you set the -brief option. Ciphersuites OpenSSL
doesn't recognise are then printed out in hex form.

For example a recent version of Chrome shows:

ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:0xCC14:0xCC13:0xCC15:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:ECDHE-ECDSA-RC4-SHA:ECDHE-RSA-RC4-SHA:AES128-GCM-SHA256:AES256-SHA:AES128-SHA:RC4-SHA:RC4-MD5:DES-CBC3-SHA:SCSV

The three hex values correspond to:

   TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256   = {0xcc, 0x13}
   TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = {0xcc, 0x14}
   TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 =     {0xcc, 0x15}

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

From de.techno at gmail.com  Sat Mar  7 10:58:40 2015
From: de.techno at gmail.com (dE)
Date: Sat, 07 Mar 2015 16:28:40 +0530
Subject: [openssl-users] SSL_read preserving message boundaries.
Message-ID: <54FAD9E0.1050406@gmail.com>

It appears that SSL_read does not work like a stream protocol.

This is the server part of the program --

char c[] = "Hello";
SSL_write (sslconnection, &c[0], 1);
SSL_write (sslconnection, &c[1], 1);
SSL_write (sslconnection, &c[2], 1);
SSL_write (sslconnection, &c[3], 1);
SSL_write (sslconnection, &c[4], 1);
SSL_write (sslconnection, &c[5], 1);

And this's the client part --

char c[15];
sleep(2);
SSL_read (sslconnection, c, sizeof(c));
printf ("%s\n", c);

With the TCP implementation, I get a complete 'Hello', with SSL_read, 
I'm only getting 'H', under the next call I get 'e', then the next gives 
'l' etc...

So this is preserving message boundaries. How do I get the complete 
message just like with TCP?

From richmoore44 at gmail.com  Sat Mar  7 11:47:33 2015
From: richmoore44 at gmail.com (Richard Moore)
Date: Sat, 7 Mar 2015 11:47:33 +0000
Subject: [openssl-users] Getting info on the ciphers supported by a
	client
In-Reply-To: <2817978485862A44A634556C7E6914847D2A19@w2k8-sys-dc01.co-in.local>
References: <2817978485862A44A634556C7E6914847D2A19@w2k8-sys-dc01.co-in.local>
Message-ID: <CAMp7mVuvFv2sU8SqjhpGMaE6QmXDnjvZqdwyMbERRv99-zyf-g@mail.gmail.com>

On 6 March 2015 at 14:05, Christian Georg <
christian.georg at cologne-intelligence.de> wrote:

>  The tricky part are the supported cipher suites. When using the -www
> option I can return a website to the client showing the cipher suites that
> provide a match, which gets pretty close to what I want in a browser. Now
> here are my challenges.
>
>
>
Personally I do this with wireshark and simply take a look at what the
client said in the ClientHello.

Cheers

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

From rsalz at akamai.com  Sat Mar  7 11:47:12 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 7 Mar 2015 11:47:12 +0000
Subject: [openssl-users] SSL_read preserving message boundaries.
In-Reply-To: <54FAD9E0.1050406@gmail.com>
References: <54FAD9E0.1050406@gmail.com>
Message-ID: <bc9233f805f94afdad6630d73e49957e@ustx2ex-dag1mb4.msg.corp.akamai.com>


> So this is preserving message boundaries. How do I get the complete
> message just like with TCP?

No, it just happened that way.  TLS does not preserve message boundaries.

From kurt at roeckx.be  Sat Mar  7 13:16:55 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 7 Mar 2015 14:16:55 +0100
Subject: [openssl-users] SSL_read preserving message boundaries.
In-Reply-To: <bc9233f805f94afdad6630d73e49957e@ustx2ex-dag1mb4.msg.corp.akamai.com>
References: <54FAD9E0.1050406@gmail.com>
 <bc9233f805f94afdad6630d73e49957e@ustx2ex-dag1mb4.msg.corp.akamai.com>
Message-ID: <20150307131655.GA14494@roeckx.be>

On Sat, Mar 07, 2015 at 11:47:12AM +0000, Salz, Rich wrote:
> 
> > So this is preserving message boundaries. How do I get the complete
> > message just like with TCP?
> 
> No, it just happened that way.  TLS does not preserve message boundaries.

As far as I know SSL_read will only return data from 1 record.


Kurt


From rsalz at akamai.com  Sat Mar  7 14:13:39 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 7 Mar 2015 14:13:39 +0000
Subject: [openssl-users] SSL_read preserving message boundaries.
In-Reply-To: <20150307131655.GA14494@roeckx.be>
References: <54FAD9E0.1050406@gmail.com>
 <bc9233f805f94afdad6630d73e49957e@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <20150307131655.GA14494@roeckx.be>
Message-ID: <622e1bd72af846ed83f9cb0cd248e7fd@ustx2ex-dag1mb4.msg.corp.akamai.com>


> As far as I know SSL_read will only return data from 1 record.

But there is no requirement that each write translates into one record.

From de.techno at gmail.com  Sat Mar  7 14:25:46 2015
From: de.techno at gmail.com (dE)
Date: Sat, 07 Mar 2015 19:55:46 +0530
Subject: [openssl-users] SSL_read preserving message boundaries.
In-Reply-To: <20150307131655.GA14494@roeckx.be>
References: <54FAD9E0.1050406@gmail.com>
 <bc9233f805f94afdad6630d73e49957e@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <20150307131655.GA14494@roeckx.be>
Message-ID: <54FB0A6A.7010106@gmail.com>

On 03/07/15 18:46, Kurt Roeckx wrote:
> On Sat, Mar 07, 2015 at 11:47:12AM +0000, Salz, Rich wrote:
>>> So this is preserving message boundaries. How do I get the complete
>>> message just like with TCP?
>> No, it just happened that way.  TLS does not preserve message boundaries.
> As far as I know SSL_read will only return data from 1 record.
>
>
> Kurt
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Suppose, I write a small amount of data with SSL_write. Will openssl 
accumulate these writes to make a single big fragment and then send it, 
or will it send it the moment it receives the data, as a single fragment?

From de.techno at gmail.com  Sat Mar  7 14:28:10 2015
From: de.techno at gmail.com (dE)
Date: Sat, 07 Mar 2015 19:58:10 +0530
Subject: [openssl-users] SSL_read preserving message boundaries.
In-Reply-To: <622e1bd72af846ed83f9cb0cd248e7fd@ustx2ex-dag1mb4.msg.corp.akamai.com>
References: <54FAD9E0.1050406@gmail.com>
 <bc9233f805f94afdad6630d73e49957e@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <20150307131655.GA14494@roeckx.be>
 <622e1bd72af846ed83f9cb0cd248e7fd@ustx2ex-dag1mb4.msg.corp.akamai.com>
Message-ID: <54FB0AFA.5030802@gmail.com>

On 03/07/15 19:43, Salz, Rich wrote:
>> As far as I know SSL_read will only return data from 1 record.
> But there is no requirement that each write translates into one record.
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

But that's what's happening here.

Instead of getting 'hello', I'm getting 'h'.

From steve at openssl.org  Sat Mar  7 17:03:56 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sat, 7 Mar 2015 17:03:56 +0000
Subject: [openssl-users] SSL_read preserving message boundaries.
In-Reply-To: <54FB0A6A.7010106@gmail.com>
References: <54FAD9E0.1050406@gmail.com>
 <bc9233f805f94afdad6630d73e49957e@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <20150307131655.GA14494@roeckx.be> <54FB0A6A.7010106@gmail.com>
Message-ID: <20150307170356.GA17403@openssl.org>

On Sat, Mar 07, 2015, dE wrote:

> 
> Suppose, I write a small amount of data with SSL_write. Will openssl
> accumulate these writes to make a single big fragment and then send
> it, or will it send it the moment it receives the data, as a single
> fragment?

No it tries to send the data with each call. That's because you might (for
example) be using a character mode application which should send each keypress
as soon as possible.

If you use BIOs you can make use of a buffering BIO which will accumulate
writes until either the buffer is full or you explicitly flush it.

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

From de.techno at gmail.com  Sun Mar  8 05:11:57 2015
From: de.techno at gmail.com (dE)
Date: Sun, 08 Mar 2015 10:41:57 +0530
Subject: [openssl-users] SSL_read preserving message boundaries.
In-Reply-To: <20150307170356.GA17403@openssl.org>
References: <54FAD9E0.1050406@gmail.com>
 <bc9233f805f94afdad6630d73e49957e@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <20150307131655.GA14494@roeckx.be> <54FB0A6A.7010106@gmail.com>
 <20150307170356.GA17403@openssl.org>
Message-ID: <54FBDA1D.1090604@gmail.com>

On 03/07/15 22:33, Dr. Stephen Henson wrote:
> On Sat, Mar 07, 2015, dE wrote:
>
>> Suppose, I write a small amount of data with SSL_write. Will openssl
>> accumulate these writes to make a single big fragment and then send
>> it, or will it send it the moment it receives the data, as a single
>> fragment?
> No it tries to send the data with each call. That's because you might (for
> example) be using a character mode application which should send each keypress
> as soon as possible.
>
> If you use BIOs you can make use of a buffering BIO which will accumulate
> writes until either the buffer is full or you explicitly flush it.
>
> 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, I'll try this.

From nospam.waldin at yopmail.com  Sun Mar  8 08:14:31 2015
From: nospam.waldin at yopmail.com (Waldin)
Date: Sun, 08 Mar 2015 09:14:31 +0100
Subject: [openssl-users] Getting info on the ciphers supported by a
	client
In-Reply-To: <20150306200448.GA1692@openssl.org>
References: <2817978485862A44A634556C7E6914847D2A19@w2k8-sys-dc01.co-in.local>
 <20150306200448.GA1692@openssl.org>
Message-ID: <54FC04E7.4060302@yopmail.com>

Sorry for chiming in with a related question.

Am 06.03.2015 um 21:04 schrieb Dr. Stephen Henson:

> I'm not sure OpenSSL can do exactly what you want: 1.0.2 has an option to
> return the raw ciphersuite list sent by the client. The s_server utility
> will print this out if you set the -brief option.

I'm not an experienced OpenSSL user, but managed to create certificates
and to make OpenSSL 1.0.2 listen on port 443 for incoming requests.
Works great for checking ciphers enabled in browsers.

Now, I also want to check ciphers enabled in (mobile) mail clients.
I've tried to make OpenSSL listen on port 110 (for POP with TLS) and
redirected the client to the OpenSSL server.  But when trying to pull
mail I can't see any handshake information:

> >openssl s_server -cert public.pem -key ca-key.pem -accept 110 -debug
> Enter pass phrase for ca-key.pem:
> Loading 'screen' into random state - done
> Using default temp DH parameters
> ACCEPT
> read from 0x4c0df0 [0x4c63e0] (11 bytes => 6 (0x6))
> 0000 - 51 55 49 54 0d 0a                                 QUIT..
> read from 0x4c0df0 [0x4c63e6] (5 bytes => 0 (0x0))
> ERROR
> shutting down SSL
> CONNECTION CLOSED
> ACCEPT

I'm obviously missing something.  Could anyone please enlighten me?

Wald


From rasjv at yandex.com  Sun Mar  8 20:38:01 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Sun, 08 Mar 2015 23:38:01 +0300
Subject: [openssl-users] SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE
In-Reply-To: <9DBCE555-B4A6-44C9-B52D-523ED3195209@sharp.fm>
References: <2185001424516315@web24h.yandex.ru>
 <9DBCE555-B4A6-44C9-B52D-523ED3195209@sharp.fm>
Message-ID: <6419191425847081@web8o.yandex.ru>


Thanks, Graham. 
Sorry for too late answer ))
Now i am testing...

21.02.2015, 14:42, "Graham Leggett" <minfrin at sharp.fm>:
> On 21 Feb 2015, at 12:58 PM, Serj Rakitov <rasjv at yandex.com> wrote:
>> ?I set socket to non-blocking mode.
>>
>> ?1. If I do SSL_read() and get result <=0 and then SSL_get_error() returns SSL_ERROR_WANT_WRITE what must I to do?
>> ?Is it enough to call SSL_write(ssl,0,0) one time and then again call SSL_read() untill it successed. Is this right?
>>
>> ?2. ?If I do SSL_write() and get result <=0 and then SSL_get_error() returns SSL_ERROR_WANT_READ what must I to do?
>> ?If I must read some data can it be application data or no? So, if I call SSL_read(ssl,buf,buf_size) must I waiting in buf some application data or never?
>> ?And after I did SSL_read(ssl,buf,buf_size) then I must again call SSL_write() untill it returns with success?
>>
>> ?3. Can be this situation: SSL_write() returns <=0 and then SSL_get_error() returns SSL_ERROR_WANT_WRITE?
>> ?What to do in this case for non-blocking socket?
>
> In both cases you return back to your poll and ask the OS to wait for the event that openssl asked for. If openssl asked for read, you poll until the socket is readable. If openssl asked for a write, you poll until the socket is writable.
>
> When you get the event you asked for, you just run whatever you were running again. For example, if you were running SSL_read, run SSL_read again. If you were running SSL_write, run SSL write again.
>
> So to write it out:
>
> - Call SSL_read(), it returns SSL_ERROR_WANT_WRITE
> - Poll for the socket being writable.
> - It?s writable! call SSL_read() again. it might return SSL_ERROR_WANT_READ
> - Poll for the socket being readable.
> - It?s readable! Call SSL_read() again, and so on.
>
> If openssl wants read, poll for read. If openssl wants write, poll for write. Don?t arbitrarily swap round SSL_read and SSL_write, those two calls are what *you* want to do, not what openssl wants to do.
>
> Regards,
> Graham


--
Best Regards,

Serj Rakitov

From rasjv at yandex.com  Sun Mar  8 20:42:48 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Sun, 08 Mar 2015 23:42:48 +0300
Subject: [openssl-users] How to make a rehandshake(renegotiation)?
Message-ID: <6424461425847368@web8o.yandex.ru>

Hello

I want to test SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE.
I have client and server. Server is sending data to the client. Client is reading data.
After some bytes sent server initiates a rehandshake to cause SSL_ERROR_WANT_WRITE on client. But there is no rehandshake. On server SSL_do_handshake returns <0 and SSL_get_error returns SSL_ERROR_WANT_READ. And on client SSL_read returns<0 and SSL_get_error also returns SSL_ERROR_WANT_READ. 

The code to rehandshake is:
SSL_set_session_id_context(...);
SSL_renegotiate(...)
SSL_do_handshake(...);
ssl->state=SSL_ST_ACCEPT;
//process SSL_do_handshake (WANT_READ/WANT_WRITE)

How to make a rehandshake from server side?


--
Best Regards,

Serj Rakitov

From christian.georg at cologne-intelligence.de  Mon Mar  9 08:22:59 2015
From: christian.georg at cologne-intelligence.de (Christian Georg)
Date: Mon, 9 Mar 2015 08:22:59 +0000
Subject: [openssl-users] Getting info on the ciphers supported by
	a	client
In-Reply-To: <CANHgQ8FzgqovLF0h=dwG=U5LCNrxD4FObrY7kPeXvHcYROUFAw@mail.gmail.com>
References: <2817978485862A44A634556C7E6914847D2A19@w2k8-sys-dc01.co-in.local>
 <CANHgQ8FzgqovLF0h=dwG=U5LCNrxD4FObrY7kPeXvHcYROUFAw@mail.gmail.com>
Message-ID: <2817978485862A44A634556C7E6914847D2B96@w2k8-sys-dc01.co-in.local>

Hi Ivan,

I know the SSL Labs site. Great work you are doing there and I am using it frequently for server checks.
For the client side I do however need to get the output on the server as I want to check our production mobile app, so no chance for me to get my hands on the content that was delivered back to the client.
I will definitely check on the Apache Module.  Sounds like this is solving my issue

Thanks a lot

Chris

Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Ivan Ristic
Gesendet: Freitag, 6. M?rz 2015 20:20
An: openssl-users at openssl.org
Betreff: Re: [openssl-users] Getting info on the ciphers supported by a client

On Fri, Mar 6, 2015 at 2:05 PM, Christian Georg <christian.georg at cologne-intelligence.de<mailto:christian.georg at cologne-intelligence.de>> wrote:
Hi all,

Christian,
I might be able to save you some time.
I wrote an SSL/TLS client test for the SSL Labs web site; you can find it here: https://dev.ssllabs.com/ssltest/viewMyClient.html If you can visit this page from the client/device and examine the output, you'll find there everything you need to know. There are a couple of other similar services. I keep a list here: https://github.com/ssllabs/research/wiki/Assessment-Tools (look under Client Assessment).
If you can't do that, you can install my Apache module called mod_sslhaf, which will dump contents of ClientHello to the server log. This approach isn't as good as the previous one, but might be good enough for your use case. You can find the module here: https://github.com/ssllabs/sslhaf

I am trying to get detailed info on the protocols and cipher suites supported by a client app. Main goal is to verify that the constraints on protocols versions and cipher suites we are using within an app are working correctly. (so it is not about the cipher suites that are theoretically available on a mobile device)
I was planning to use openssl s_server for this task. I am opening s_server on different ports each with a specific protocol version (-ssl2, -ssl3, -tls1?). On some of the ports a handshake should be successful on others not.

The tricky part are the supported cipher suites. When using the ?www option I can return a website to the client showing the cipher suites that provide a match, which gets pretty close to what I want in a browser. Now here are my challenges.

Challenge 1: Getting a list of ALL Ciphersuites
I would like to get info on all cipher suites supported (preferred) by the client . The ?www option does only show the cipher suites with a match. So any cipher suite not supported by openssl will not be listed. When checking my browser with qualys SSl Lab I noticed that the following three ciphersuites are showing up on the qualys report but not on the s_server page.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

I do not see them as a risk, but what if some exotic weak ciphers are enabled within the app. It is my understanding that during a handshake a list of all preferred ciphers is send from the client to the server. How can I get access to this info?

Challenge 2: How do I get the info into a log file on the server rather than sending it back as a website?
The approach described above is working fine for browsers but what about consuming webservices? I am able to redirect the webservices to my openssl s_server and perform the handshake (even so the SOAP or REST Interface will then throw an error). But I could not find an option on getting the info written into the Logfile (in a human readable way) even with all logging I found enabled (-state -debug -msg ?tlsextdebug -trace) I could not find the info in a human readable way.

Any recommendations on how I can solve my issues without changing the openssl code and add this manually?

Cheers

Chris


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



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

From christian.georg at cologne-intelligence.de  Mon Mar  9 08:35:55 2015
From: christian.georg at cologne-intelligence.de (Christian Georg)
Date: Mon, 9 Mar 2015 08:35:55 +0000
Subject: [openssl-users] Getting info on the ciphers supported by
	a	client
In-Reply-To: <20150306200448.GA1692@openssl.org>
References: <2817978485862A44A634556C7E6914847D2A19@w2k8-sys-dc01.co-in.local>
 <20150306200448.GA1692@openssl.org>
Message-ID: <2817978485862A44A634556C7E6914847D2BBC@w2k8-sys-dc01.co-in.local>

Hi Steve,

thanks for the feedback. I was trying this again this morning and noticed a mistake I made. Not sure if this is intended behaviour. 
When combining the -www and -brief option in one call -brief does not create any output to stdout.

So when using this:	/usr/local/openssl-1.0.2/bin/openssl  s_server -brief  -key server.pem -cert server.pem -accept 6011
I got the expected output on stdout (including the unknown ciphers)

When using this: /usr/local/openssl-1.0.2/bin/openssl  s_server -brief -www  -key server.pem -cert server.pem -accept 6011
I am not getting the output expected from -brief on stdout and the unknown ciphersuites are also not showing up. I thought that by using -www I would getting back a proper http response (with an info page) and in addition all output on the server. This does not seem to be the case.

As I do not need both outputs at the same time I can open separate servers for output to browser based systems and Apps calling a webservice

Cheers
Chris

-----------------------------------------------
-----Urspr?ngliche Nachricht-----
Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Dr. Stephen Henson
Gesendet: Freitag, 6. M?rz 2015 21:05
An: openssl-users at openssl.org
Betreff: Re: [openssl-users] Getting info on the ciphers supported by a client

On Fri, Mar 06, 2015, Christian Georg wrote:

> 
> Any recommendations on how I can solve my issues without changing the openssl code and add this manually?
> 

I'm not sure OpenSSL can do exactly what you want: 1.0.2 has an option to return the raw ciphersuite list sent by the client. The s_server utility will print this out if you set the -brief option. Ciphersuites OpenSSL doesn't recognise are then printed out in hex form.

For example a recent version of Chrome shows:

ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:0xCC14:0xCC13:0xCC15:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:ECDHE-ECDSA-RC4-SHA:ECDHE-RSA-RC4-SHA:AES128-GCM-SHA256:AES256-SHA:AES128-SHA:RC4-SHA:RC4-MD5:DES-CBC3-SHA:SCSV

The three hex values correspond to:

   TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256   = {0xcc, 0x13}
   TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = {0xcc, 0x14}
   TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 =     {0xcc, 0x15}

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 dpb795795 at gmail.com  Mon Mar  9 08:53:53 2015
From: dpb795795 at gmail.com (Deepak)
Date: Mon, 9 Mar 2015 14:23:53 +0530
Subject: [openssl-users] How to disable all EXPORT Ciphers?
In-Reply-To: <CAGg4YWEGYHXadt7Obbvn3HEy7ZgDk_2pQNhVtM=PGSjZonAwUw@mail.gmail.com>
References: <CAGg4YWEGYHXadt7Obbvn3HEy7ZgDk_2pQNhVtM=PGSjZonAwUw@mail.gmail.com>
Message-ID: <CAGg4YWGsmEbd_8DLqhJ2kHgs1pa1Ss2fMR5uF0oHVM26p21fVQ@mail.gmail.com>

Hi,

How to I disable all EXPORT Ciphers from OpenSSL?

Will the use of string "kEDH:ALL:!ADH:!DES:!LOW:!EXPORT:+SSLv2:@STRENGTH"
with
SSL_CTX_set_cipher_list() be good enough to disable EXPORT40, 56 and 1024?

Thank you,
Deepak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150309/15eda9ed/attachment.html>

From rasjv at yandex.com  Mon Mar  9 09:43:41 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Mon, 09 Mar 2015 12:43:41 +0300
Subject: [openssl-users] How to make a rehandshake(renegotiation)?
In-Reply-To: <6424461425847368@web8o.yandex.ru>
References: <6424461425847368@web8o.yandex.ru>
Message-ID: <7906161425894221@web10m.yandex.ru>


I can't start rehandshake even from client side.
If I try something like this on client side:

SSL_renegotiate(...)
//process SSL_do_handshake(SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE)

nothing happens.

Neither client nor server can't start a new handshake!
How to do a rehandshake?


Best Regards,
Serj Rakitov

From rasjv at yandex.com  Mon Mar  9 12:21:19 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Mon, 09 Mar 2015 15:21:19 +0300
Subject: [openssl-users] SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE
In-Reply-To: <9DBCE555-B4A6-44C9-B52D-523ED3195209@sharp.fm>
References: <2185001424516315@web24h.yandex.ru>
 <9DBCE555-B4A6-44C9-B52D-523ED3195209@sharp.fm>
Message-ID: <8189421425903679@web28m.yandex.ru>

I have to open discussion again.

I want to test situations when SSL_read WANT_WRITE and SSL_write WANT_READ. But I can't do this. SSL_read never wants write and SSL_write never wants read!

I don't know how to catch these situations. I don't know how to rehandshake. I tried after connect and handshake to send data simultaneously both to server and to client and never got one of those situations, SSL_read  only wanted to read and  SSL_write  only wanted to write, all data was received by both client and server.

I don't even understand how SSL_write can want to read? In what cases?
I can understand when SSL_read wants to write, for example when client got HelloRequest or server got a new ClientHello while reading data. But I can't test it, because I don't know how to start handshake again, how to perform a rehandshake(renegotiation).

Can anybody help me? How to test these situations or how to perform a rehandshake?

Best Regards,
Serj Rakitov

From nospam.waldin at yopmail.com  Mon Mar  9 13:13:37 2015
From: nospam.waldin at yopmail.com (Waldin)
Date: Mon, 09 Mar 2015 14:13:37 +0100
Subject: [openssl-users] Getting info on the ciphers supported by a
	client
In-Reply-To: <54FC04E7.4060302@yopmail.com>
References: <2817978485862A44A634556C7E6914847D2A19@w2k8-sys-dc01.co-in.local>
 <20150306200448.GA1692@openssl.org> <54FC04E7.4060302@yopmail.com>
Message-ID: <54FD9C81.4060207@yopmail.com>

Am 08.03.2015 um 09:14 schrieb Waldin:

> Now, I also want to check ciphers enabled in (mobile) mail clients.
> I've tried to make OpenSSL listen on port 110 (for POP with TLS) and
> redirected the client to the OpenSSL server.  But when trying to pull
> mail I can't see any handshake information:

FTR, I've now managed to check my mobile mail client.  The hint was the
argument to the s_client command's -starttls option, which made me
realize that for handshaking with starttls a minimum understanding of
the protocol is needed.  OpenSSL probably doesn't include a POP or IMAP
server.  But it works without starttls, when listening on port 993:

> >openssl s_server -cert public.pem -key ca-key.pem -accept 993
> Enter pass phrase for ca-key.pem:
> Loading 'screen' into random state - done
> Using default temp DH parameters
> ACCEPT
> -----BEGIN SSL SESSION PARAMETERS-----
> MFUCAQECAgMBBAIAOQQABDAM5TDoa/9vlS6pUsqtlPWpgpMc1L7bvwCS5UGiIhut
> 13A4uf0Zm8T2/q3ULkxnkPKhBgIEVP2ataIEAgIBLKQGBAQBAAAA
> -----END SSL SESSION PARAMETERS-----
> Shared ciphers:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3
> -SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES
> 128-SHA:IDEA-CBC-SHA:RC4-SHA
> CIPHER is DHE-RSA-AES256-SHA
> Secure Renegotiation IS NOT supported
> ~A1 LOGIN "MYLOGIN" "MYPASSWORD"
> ERROR
> shutting down SSL
> CONNECTION CLOSED
> ACCEPT

Hurray!  But wait, a plain text password?  And no server certificate
pinning?  Oh, no!

Wald


From rsalz at akamai.com  Mon Mar  9 15:00:45 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 9 Mar 2015 15:00:45 +0000
Subject: [openssl-users] How to disable all EXPORT Ciphers?
In-Reply-To: <CAGg4YWGsmEbd_8DLqhJ2kHgs1pa1Ss2fMR5uF0oHVM26p21fVQ@mail.gmail.com>
References: <CAGg4YWEGYHXadt7Obbvn3HEy7ZgDk_2pQNhVtM=PGSjZonAwUw@mail.gmail.com>
 <CAGg4YWGsmEbd_8DLqhJ2kHgs1pa1Ss2fMR5uF0oHVM26p21fVQ@mail.gmail.com>
Message-ID: <6043505847694a2fbe7cde034c5fae70@usma1ex-dag1mb2.msg.corp.akamai.com>

>How to I disable all EXPORT Ciphers from OpenSSL?
> Will the use of string "kEDH:ALL:!ADH:!DES:!LOW:!EXPORT:+SSLv2:@STRENGTH"

	; openssl ciphers -v kEDH:ALL:!ADH:!DES:!LOW:!EXPORT:+SSLv2:@STRENGTH | grep EXP
	;
Yes.

But really, SSLv2?  Really?  You have clients that haven't been updated since the last century?

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

From openssl-users at dukhovni.org  Mon Mar  9 16:46:45 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 9 Mar 2015 16:46:45 +0000
Subject: [openssl-users] How to disable all EXPORT Ciphers?
In-Reply-To: <CAGg4YWGsmEbd_8DLqhJ2kHgs1pa1Ss2fMR5uF0oHVM26p21fVQ@mail.gmail.com>
References: <CAGg4YWEGYHXadt7Obbvn3HEy7ZgDk_2pQNhVtM=PGSjZonAwUw@mail.gmail.com>
 <CAGg4YWGsmEbd_8DLqhJ2kHgs1pa1Ss2fMR5uF0oHVM26p21fVQ@mail.gmail.com>
Message-ID: <20150309164645.GW1260@mournblade.imrryr.org>

On Mon, Mar 09, 2015 at 02:23:53PM +0530, Deepak wrote:

> How to I disable all EXPORT Ciphers from OpenSSL?
> 
> Will the use of string "kEDH:ALL:!ADH:!DES:!LOW:!EXPORT:+SSLv2:@STRENGTH"
> with SSL_CTX_set_cipher_list() be good enough to disable EXPORT40, 56 and 1024?

Note that doing so does not address the FREAK CVE in SSL clients.  Even
with EXPORT ciphers disabled they are still vulnerable, unless patched!

As for your proposed cipherlist it is too exotic.

    * ALL:!ADH is simply DEFAULT.  DEFAULT already prefers PFS (including
      ECDHE) and is sorted by strength.

    * DES is a subset of LOW 

    * I would also disable SSLv2, which is a subset of MD5, so I generally
      disable that instead which also drops the SSLv3's RC4-MD5 leaving RC4-SHA
      for interop.  Note for many applications RC4 is no longer supposed to be
      used, consider whether disabling RC4 is appropriate for you.

Therefore, I'd suggest:

	DEFAULT:!EXPORT:!LOW:!MD5

Which keeps things simple by starting with DEFAULT and removing
what you want to disable.

-- 
	Viktor.

From mikec1404 at gmail.com  Mon Mar  9 17:56:25 2015
From: mikec1404 at gmail.com (Mike Collins)
Date: Mon, 9 Mar 2015 12:56:25 -0500
Subject: [openssl-users] 1.0.1 upgrade issue
Message-ID: <CABQOMtba1715A91n7cH08HByErDLFYw_FnADNqD15-Lu-tCXxw@mail.gmail.com>

Created a new toolchain with crosstool-ng using glibc 2.13, gcc 4.9.1,
binutils 2.22 and headers 2.6.27.

Using the new toolchain v1.0.1l seems to now work on my board although I
will have to do some more in depth testing. My guess is it was a glibc
issue but am not positive. I am limited to glibc 2.13 due to constraints
with the Busybox version I am using.

Thanks for the help and suggestions.

Mike


On 2/18/2015 8:03 AM, Mike Collins wrote:

My build script is doing the same.

Not sure where to go next except to update libc to a newer version. Due to
the toolchain (not created by me) it may be a major undertaking.

Mike

From: Jay Foster <jayf0ster at roadrunner.com>
To: openssl-users at openssl.org
Cc:
Date: Wed, 18 Feb 2015 10:30:40 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I'm building against libc6 (glibc 2.9) and kernel 3.2.6.  Are you skipping
the 'make depend' step?  My build script does, './Configure <args>', 'make
depend', 'make'.

Jay

On 2/18/2015 8:03 AM, Mike Collins wrote:

Thanks for the suggestions Jay but am still not having much luck.

Does 1.0.1 have any minimum requirements for the libc version or kernel
version? I am currently building against libc version 2.5 with the kernel
at 2.6.30.

Mike

---------- Forwarded message ----------
From: Jay Foster <jayf0ster at roadrunner.com>
To: openssl-users at openssl.org
Cc:
Date: Fri, 13 Feb 2015 08:48:12 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I have successfully built OpenSSL 1.0.0..., 1.0.1..., and 1.0.2 also on an
ARM926EJ linux based system.  I used the 'no-ssl2 no-ssl3 linux-armv4
shared' options (plus some others).  I found that it works with and without
the ARM assembly accelerations (no-asm option), even though the ARM926EJ is
an arm5te.  It works fine with lighttpd and passes the OpenSSL tests.  I
assume you are also using the appropriate '--cross-compile-prefix=<prefix>'
option.   You might try adding "-mlittle-endian -mcpu=arm926ej-s
-DL_ENDIAN" to the CFLAGS, although that should be redundant (the compiler
should already know this).  Also, make sure there are no '-nostdinc' (or
similar) type compiler options creeping in.  These change the search order
of header files, which can cause OpenSSL to be built against the (old)
headers in your tool chain, rather than it's local (current) headers.

I did discover that with 1.0.2, I also needed to add
'-DOPENSSL_USE_BUILD_DATE' to the CFLAGS to get the 'openssl version -a'
command to report a useful build date.

Jay


On 2/13/2015 7:29 AM, Mike Collins wrote:

I am upgrading an embedded linux board's BSP from 1.0.0m to 1.0.1l due to a
requirement for TLS v1.1. Version 1.0.1 will cross compile without errors
using my 1.0.0 configuration but I have identified the following errors on
the board (so far) with the build using 1.0.1:
1.) Cannot create a RSA key
2.) Trying to connect to the board's Lighttpd web server via https will
timeout with PKCS #11 error
3.) Curl https POST calls fail with RSA padding error.

Board has a ARM926EJ based processor and I am using a Codesourcery Lite
toolchain. Configure settings (besides --prefix, etc) are shared, no-asm,
linux-generic32, no-ssl2. All the other packages on the board have been
rebuilt against the new openssl version.

I am looking at the key creation first since that may be causing the other
issues. If I try to create a key from the board command line using "openssl
genrsa -out testkey.pem 2048" I get a response of "Generating RSA private
key, 2048 bit long modulus". At this point it seems to get stuck in a loop;
I am seeing the progress indicators (".") but it will never finish creating
the key. I have let it run 10-15 minutes without completion; it just keeps
displaying successive progress indicators. I can do Ctrl-C and it will
exit.

I don't think so but are there any dependency changes from 1.0.0 to 1.0.1?

I noticed 1.0.2 has been released so tried that as well but have the same
result as 1.0.1

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150309/7d0efd26/attachment-0001.html>

From christian.georg at cologne-intelligence.de  Tue Mar 10 08:44:57 2015
From: christian.georg at cologne-intelligence.de (Christian Georg)
Date: Tue, 10 Mar 2015 08:44:57 +0000
Subject: [openssl-users] How to disable all EXPORT Ciphers?
In-Reply-To: <20150309164645.GW1260@mournblade.imrryr.org>
References: <CAGg4YWEGYHXadt7Obbvn3HEy7ZgDk_2pQNhVtM=PGSjZonAwUw@mail.gmail.com>
 <CAGg4YWGsmEbd_8DLqhJ2kHgs1pa1Ss2fMR5uF0oHVM26p21fVQ@mail.gmail.com>
 <20150309164645.GW1260@mournblade.imrryr.org>
Message-ID: <2817978485862A44A634556C7E6914847D3008@w2k8-sys-dc01.co-in.local>

Hi Viktor,

please help me to understand your sentence:

	"Note that doing so does not address the FREAK CVE in SSL clients.  Even with EXPORT ciphers disabled they are still vulnerable, unless patched!"

I understand that the downgrading of the ciphersuites is a bug in the library that should be patched. Doing this can however be dificult when talking about mobile apps that use OS Libraries. 
>From my understanding the bug only works within the limit of chipersuites permitted by both the client and the server.

Therefore my asumption is if the server side does only offer strong ciphers I do not have to worry too much about the ability to exploit the FREAK vulnerability e.g. in android clients.
I am very aware that on older Androids there are other things to worry about like missing TLS 1.2 support,... but with regards to freak SSL a quick fix to secure the communication between a mobile app and the server side webservice should be disabeling weak ciphers on the server.

Is this assumption wrong ?

Thanks for your help

Chris


-----------------------------------------------
-----Urspr?ngliche Nachricht-----
Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Viktor Dukhovni
Gesendet: Montag, 9. M?rz 2015 17:47
An: openssl-users at openssl.org
Betreff: Re: [openssl-users] How to disable all EXPORT Ciphers?

On Mon, Mar 09, 2015 at 02:23:53PM +0530, Deepak wrote:

> How to I disable all EXPORT Ciphers from OpenSSL?
> 
> Will the use of string "kEDH:ALL:!ADH:!DES:!LOW:!EXPORT:+SSLv2:@STRENGTH"
> with SSL_CTX_set_cipher_list() be good enough to disable EXPORT40, 56 and 1024?

Note that doing so does not address the FREAK CVE in SSL clients.  Even with EXPORT ciphers disabled they are still vulnerable, unless patched!

As for your proposed cipherlist it is too exotic.

    * ALL:!ADH is simply DEFAULT.  DEFAULT already prefers PFS (including
      ECDHE) and is sorted by strength.

    * DES is a subset of LOW 

    * I would also disable SSLv2, which is a subset of MD5, so I generally
      disable that instead which also drops the SSLv3's RC4-MD5 leaving RC4-SHA
      for interop.  Note for many applications RC4 is no longer supposed to be
      used, consider whether disabling RC4 is appropriate for you.

Therefore, I'd suggest:

	DEFAULT:!EXPORT:!LOW:!MD5

Which keeps things simple by starting with DEFAULT and removing what you want to disable.

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

From openssl-users at dukhovni.org  Tue Mar 10 10:53:40 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 10 Mar 2015 10:53:40 +0000
Subject: [openssl-users] How to disable all EXPORT Ciphers?
In-Reply-To: <2817978485862A44A634556C7E6914847D3008@w2k8-sys-dc01.co-in.local>
References: <CAGg4YWEGYHXadt7Obbvn3HEy7ZgDk_2pQNhVtM=PGSjZonAwUw@mail.gmail.com>
 <CAGg4YWGsmEbd_8DLqhJ2kHgs1pa1Ss2fMR5uF0oHVM26p21fVQ@mail.gmail.com>
 <20150309164645.GW1260@mournblade.imrryr.org>
 <2817978485862A44A634556C7E6914847D3008@w2k8-sys-dc01.co-in.local>
Message-ID: <20150310105340.GE18819@mournblade.imrryr.org>

On Tue, Mar 10, 2015 at 08:44:57AM +0000, Christian Georg wrote:

> I understand that the downgrading of the ciphersuites is a bug in the
> library that should be patched. Doing this can however be dificult when
> talking about mobile apps that use OS Libraries.  From my understanding
> the bug only works within the limit of chipersuites permitted by both the
> client and the server.

That understanding is I believe wrong.  Only the server needs to
support EXPORT ciphers.  The client just needs a vulnerable library.

> Therefore my asumption is if the server side does only offer strong ciphers
> I do not have to worry too much about the ability to exploit the FREAK
> vulnerability e.g. in android clients.

Yes, if the server disables EXPORT ciphers the clients are safe
with *that* server, but will remain vulnerable with other servers.
The clients do need to be patched.

-- 
	Viktor.

From jonetsu at teksavvy.com  Tue Mar 10 12:20:58 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 10 Mar 2015 08:20:58 -0400
Subject: [openssl-users] FIPS: Common method executed in case of error
Message-ID: <04c6239e88f8df86942c8a25030c90b3@teksavvy.com>

Hello,

? Is there a method that is always in the path of execution when a crypto error occurs ?? The reason for asking is that I would like to very slightly modify the OpenSSL FIPS version so that it will write a file in tmpfs when an error occurs.? That place will be observed by another app using inotify.? Granted, modifying OpenSSL FIPS will void its FIPS certification.? But then, the whole unit will be validated.? Having a single place to modify would be quite an extraordinary thing.? I have asked recently about a related topic and got some replies regarding the modification of applications, although modifying the library would provide a single package to modify.? Steve has replied that indeed the validation will be lost - I wonder if that would have any impact on the total validation costs for a whole unit, OS and apps ?? Would a non-modified FIPS OpenSSL library reduce the
validation costs ?

Any comments and suggestions welcomed, regards.




From marquess at openssl.com  Tue Mar 10 12:56:15 2015
From: marquess at openssl.com (Steve Marquess)
Date: Tue, 10 Mar 2015 08:56:15 -0400
Subject: [openssl-users] FIPS: Common method executed in case of error
In-Reply-To: <04c6239e88f8df86942c8a25030c90b3@teksavvy.com>
References: <04c6239e88f8df86942c8a25030c90b3@teksavvy.com>
Message-ID: <54FEE9EF.3040309@openssl.com>

On 03/10/2015 08:20 AM, jonetsu wrote:
> ...
> Steve has replied that indeed the validation will be lost - I wonder
> if that would have any impact on the total validation costs for a
> whole unit, OS and apps ? 

You're talking about a Level 2 validation (or higher)? You most
definitely do *not* want to include the OS or applications in the
"cryptographic module boundary" for Level 1.

> Would a non-modified FIPS OpenSSL library
> reduce the validation costs ?

I think you're going to be shocked at the cost (in time and money) to
validate a hacked OpenSSL FIPS module, compared to using it as-is or a
"change letter" update. That's because the CMVP has introduced a number
of new requirements since the current FIPS module was validated (in
2012), and any new validation will now need to satisfy those. That means
not only non-trivial code hacks unrelated to yours, but also a new paper
shuffle for the "arm waving" (DTR) components of the validation process.
The cost of the latter dwarfs the former; which is why we have not
attempted a new validation ourselves.

But, that cost could be dwarfed in turn by that of a Level 2 or 3
validation of a turnkey system including OS and apps.

-Steve M.

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

From jonetsu at teksavvy.com  Tue Mar 10 13:10:06 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 10 Mar 2015 09:10:06 -0400
Subject: [openssl-users] FIPS: Common method executed in case of error
In-Reply-To: <04c6239e88f8df86942c8a25030c90b3@teksavvy.com>
References: <04c6239e88f8df86942c8a25030c90b3@teksavvy.com>
Message-ID: <f4bfee212ce7c9064f1a158ae8457d45@teksavvy.com>



> Is there a method that is always in the path of execution when a crypto error occurs ?? 

It looks like fips_set_selftest_fail() would be a likely candidate where to create an empty file on a tmpfs in order to let the OS know about the error.

Comments and suggestions welcomed.? Based on your experience with FIPS validation process, and many customers/sponsors, do you think that having a ever so slightly modified OpenSSL FIPS code would increase validation costs for a whole unit (OS and apps) ?? Recently Steve, I think, has mentioned that the cost for an initial OpenSSL FIPS validation was well into the 6 numbers.? Would this type of figure be added to a project if OpenSSL FIPS is modified ?? I think the labs could go with a diff and see how simple the modification is.

Regards.




From jonetsu at teksavvy.com  Tue Mar 10 13:28:41 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 10 Mar 2015 09:28:41 -0400
Subject: [openssl-users] FIPS: Common method executed in case of error
In-Reply-To: <54FEE9EF.3040309@openssl.com>
References: <04c6239e88f8df86942c8a25030c90b3@teksavvy.com>
 <54FEE9EF.3040309@openssl.com>
Message-ID: <5b72f5a9542edfa3b97608930dc9ce2d@teksavvy.com>



> From: "Steve Marquess" <marquess at openssl.com> 
> Date: 03/10/15 08:56 

Hello,

? Thanks for your reply.

> You're talking about a Level 2 validation (or higher)? You most
> definitely do *not* want to include the OS or applications in the
> "cryptographic module boundary" for Level 1.

It's a level 2.? The behaviour of the unit as a whole is
validated.? As an example amongst many, there will be no Linux
console prompt available in FIPS mode.

> I think you're going to be shocked at the cost (in time and money) to
> validate a hacked OpenSSL FIPS module, compared to using it as-is or a
> "change letter" update.

That brings a question.? I'm currently using 1.0.1k with the 2.0
FIPS module for development purposes.? This may seem a bit blunt,
but, is it possible at all to use 1.0.1k to benefit from the FIPS
validation ?? Based on recent comments I would think not.? Going
back to a pre-heartbleed version ?? Is there any way to benefit
from the gained OpenSSL FIPS validation at all ?

> That's because the CMVP has introduced a number of new
> requirements since the current FIPS module was validated (in
> 2012), and any new validation will now need to satisfy
> those.

Again, is there any benefit to be gained from using a once
validated OpenSSL FIPS ?? What would be the bugs fixed/ security
updates trade-off ?

> That means not only non-trivial code hacks unrelated to yours,
> but also a new paper shuffle for the "arm waving" (DTR)
> components of the validation process.? The cost of the latter
> dwarfs the former; which is why we have not attempted a new
> validation ourselves.

Hmmm... If this goes through, would it be possible for OpenSSL to
benefit from any validation our unit can get ?

> But, that cost could be dwarfed in turn by that of a Level 2 or 3
> validation of a turnkey system including OS and apps.

Thanks again for your comments, much appreciated.

Regards.








From steve at openssl.org  Tue Mar 10 13:29:38 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 10 Mar 2015 13:29:38 +0000
Subject: [openssl-users] FIPS: Common method executed in case of error
In-Reply-To: <04c6239e88f8df86942c8a25030c90b3@teksavvy.com>
References: <04c6239e88f8df86942c8a25030c90b3@teksavvy.com>
Message-ID: <20150310132938.GA10807@openssl.org>

On Tue, Mar 10, 2015, jonetsu wrote:

> Hello,
> 
> ? Is there a method that is always in the path of execution when a crypto
> error occurs ?? The reason for asking is that I would like to very slightly
> modify the OpenSSL FIPS version so that it will write a file in tmpfs when
> an error occurs.? That place will be observed by another app using inotify.?
> Granted, modifying OpenSSL FIPS will void its FIPS certification.? But then,
> the whole unit will be validated.? Having a single place to modify would be
> quite an extraordinary thing.? I have asked recently about a related topic
> and got some replies regarding the modification of applications, although
> modifying the library would provide a single package to modify.? Steve has
> replied that indeed the validation will be lost - I wonder if that would
> have any impact on the total validation costs for a whole unit, OS and apps
> ?? Would a non-modified FIPS OpenSSL library reduce the validation costs ?
> 
> Any comments and suggestions welcomed, regards.
> 

Although you cannot modify the FIPS module itself without voiding the
validation you *can* change the FIPS capable OpenSSL.

You might (for example) change FIPS_mode_set() to always add a callback
which logs any errors.

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

From Michael.Wojcik at microfocus.com  Tue Mar 10 13:28:45 2015
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 10 Mar 2015 13:28:45 +0000
Subject: [openssl-users] How to disable all EXPORT Ciphers?
In-Reply-To: <20150310105340.GE18819@mournblade.imrryr.org>
References: <CAGg4YWEGYHXadt7Obbvn3HEy7ZgDk_2pQNhVtM=PGSjZonAwUw@mail.gmail.com>
 <CAGg4YWGsmEbd_8DLqhJ2kHgs1pa1Ss2fMR5uF0oHVM26p21fVQ@mail.gmail.com>
 <20150309164645.GW1260@mournblade.imrryr.org>
 <2817978485862A44A634556C7E6914847D3008@w2k8-sys-dc01.co-in.local>,
 <20150310105340.GE18819@mournblade.imrryr.org>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088014BAB4D71@Rock-Exchange1.microfocus.com>

Viktor's description agrees with Matthew Green's explanation.[1] The FREAK attack can work against non-patched OpenSSL clients even if they disable export-grade ciphers; in fact, that's precisely the problem.

The attack works like this:

1. Client sends ClientHello with a suite list that includes strong RSA suites.
2. MITM modifies ClientHello to request export-grade RSA.
3. If the server supports export-grade RSA, it replies with a 512-bit RSA key.
4. The client incorrectly accepts the short RSA key, even though it didn't ask for one. That's the bug.
5. Attacker factors the 512-bit RSA key. This relies on the second problem described by the FREAK authors: many servers (eg Apache) just generate one 512-bit RSA key pair at startup, and don't create a new one for each export-grade request, because it's expensive. So if you factor it once, you're good to break a whole bunch of sessions.

If you always control both ends of the conversation, and can disable the export suites on both, then you shouldn't be vulnerable. If you have to talk to third-party servers, though, you don't know which ones might be vulnerable. FREAK testing has revealed that an awful lot still support the export suites.

[1] http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html

________________________________________
From: openssl-users [openssl-users-bounces at openssl.org] on behalf of Viktor Dukhovni [openssl-users at dukhovni.org]
Sent: Tuesday, March 10, 2015 06:53
To: openssl-users at openssl.org
Subject: Re: [openssl-users] How to disable all EXPORT Ciphers?

On Tue, Mar 10, 2015 at 08:44:57AM +0000, Christian Georg wrote:

> I understand that the downgrading of the ciphersuites is a bug in the
> library that should be patched. Doing this can however be dificult when
> talking about mobile apps that use OS Libraries.  From my understanding
> the bug only works within the limit of chipersuites permitted by both the
> client and the server.

That understanding is I believe wrong.  Only the server needs to
support EXPORT ciphers.  The client just needs a vulnerable library.

> Therefore my asumption is if the server side does only offer strong ciphers
> I do not have to worry too much about the ability to exploit the FREAK
> vulnerability e.g. in android clients.

Yes, if the server disables EXPORT ciphers the clients are safe
with *that* server, but will remain vulnerable with other servers.
The clients do need to be patched.

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

This message has been scanned for malware by Websense. www.websense.com

From rasjv at yandex.com  Tue Mar 10 13:55:22 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Tue, 10 Mar 2015 16:55:22 +0300
Subject: [openssl-users] SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE
In-Reply-To: <8189421425903679@web28m.yandex.ru>
References: <2185001424516315@web24h.yandex.ru>
 <9DBCE555-B4A6-44C9-B52D-523ED3195209@sharp.fm>
 <8189421425903679@web28m.yandex.ru>
Message-ID: <1737371425995722@web6o.yandex.ru>

Nobody knows? 


09.03.2015, 15:30, "Serj Rakitov" <rasjv at yandex.com>:
> ?I have to open discussion again.
>
> ?I want to test situations when SSL_read WANT_WRITE and SSL_write WANT_READ. But I can't do this. SSL_read never wants write and SSL_write never wants read!
>
> ?I don't know how to catch these situations. I don't know how to rehandshake. I tried after connect and handshake to send data simultaneously both to server and to client and never got one of those situations, SSL_read ?only wanted to read and ?SSL_write ?only wanted to write, all data was received by both client and server.
>
> ?I don't even understand how SSL_write can want to read? In what cases?
> ?I can understand when SSL_read wants to write, for example when client got HelloRequest or server got a new ClientHello while reading data. But I can't test it, because I don't know how to start handshake again, how to perform a rehandshake(renegotiation).
>
> ?Can anybody help me? How to test these situations or how to perform a rehandshake?


Best Regards,
Serj Rakitov

From jb-openssl at wisemo.com  Tue Mar 10 14:14:25 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 10 Mar 2015 15:14:25 +0100
Subject: [openssl-users] SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE
In-Reply-To: <8189421425903679@web28m.yandex.ru>
References: <2185001424516315@web24h.yandex.ru>
 <9DBCE555-B4A6-44C9-B52D-523ED3195209@sharp.fm>
 <8189421425903679@web28m.yandex.ru>
Message-ID: <54FEFC41.30807@wisemo.com>

On 09/03/2015 13:21, Serj Rakitov wrote:
> I have to open discussion again.
>
> I want to test situations when SSL_read WANT_WRITE and SSL_write WANT_READ. But I can't do this. SSL_read never wants write and SSL_write never wants read!
>
> I don't know how to catch these situations. I don't know how to rehandshake. I tried after connect and handshake to send data simultaneously both to server and to client and never got one of those situations, SSL_read  only wanted to read and  SSL_write  only wanted to write, all data was received by both client and server.
>
> I don't even understand how SSL_write can want to read? In what cases?
> I can understand when SSL_read wants to write, for example when client got HelloRequest or server got a new ClientHello while reading data. But I can't test it, because I don't know how to start handshake again, how to perform a rehandshake(renegotiation).
>
> Can anybody help me? How to test these situations or how to perform a rehandshake?
Not having tested or read the relevant OpenSSL code, I
presume that SSL_write could want a read if it has sent
a handshake message, but not yet received the reply, thus
it cannot (encrypt and) send user data until it has
received and acted on the handshake reply message.

Maybe the easier scenarios are at the start of a session,
where the initial handshake has not yet completed, as
happens in a HTTPS client (always writes a request before
the first read) or a simple SMTPS server (always writes a
banner line before the first read of client commands,
except in some servers that do an early read to check if
a broken/spammer client is trying to send before receiving
the banner).

-- 

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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 rasjv at yandex.com  Tue Mar 10 13:53:25 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Tue, 10 Mar 2015 16:53:25 +0300
Subject: [openssl-users] How to make a rehandshake(renegotiation)?
In-Reply-To: <6424461425847368@web8o.yandex.ru>
References: <6424461425847368@web8o.yandex.ru>
Message-ID: <2380441425995605@web6j.yandex.ru>


Nobody knows? 
Does OpenSSL support renegotiation? 
I will be very grateful for answers because there is no any info about this in the net.


09.03.2015, 00:36, "Serj Rakitov" <rasjv at yandex.com>:
> Hello
>
> I want to test SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE.
> I have client and server. Server is sending data to the client. Client is reading data.
> After some bytes sent server initiates a rehandshake to cause SSL_ERROR_WANT_WRITE on client. But there is no rehandshake. On server SSL_do_handshake returns <0 and SSL_get_error returns SSL_ERROR_WANT_READ. And on client SSL_read returns<0 and SSL_get_error also returns SSL_ERROR_WANT_READ.
>
> The code to rehandshake is:
> SSL_set_session_id_context(...);
> SSL_renegotiate(...)
> SSL_do_handshake(...);
> ssl->state=SSL_ST_ACCEPT;
> //process SSL_do_handshake (WANT_READ/WANT_WRITE)
>
> How to make a rehandshake from server side?


Best Regards,
Serj Rakitov

From jb-openssl at wisemo.com  Tue Mar 10 14:24:18 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 10 Mar 2015 15:24:18 +0100
Subject: [openssl-users] Getting info on the ciphers supported by a
	client
In-Reply-To: <54FD9C81.4060207@yopmail.com>
References: <2817978485862A44A634556C7E6914847D2A19@w2k8-sys-dc01.co-in.local>
 <20150306200448.GA1692@openssl.org> <54FC04E7.4060302@yopmail.com>
 <54FD9C81.4060207@yopmail.com>
Message-ID: <54FEFE92.5030304@wisemo.com>

On 09/03/2015 14:13, Waldin wrote:
> Am 08.03.2015 um 09:14 schrieb Waldin:
>
>> Now, I also want to check ciphers enabled in (mobile) mail clients.
>> I've tried to make OpenSSL listen on port 110 (for POP with TLS) and
>> redirected the client to the OpenSSL server.  But when trying to pull
>> mail I can't see any handshake information:
> FTR, I've now managed to check my mobile mail client.  The hint was the
> argument to the s_client command's -starttls option, which made me
> realize that for handshaking with starttls a minimum understanding of
> the protocol is needed.  OpenSSL probably doesn't include a POP or IMAP
> server.  But it works without starttls, when listening on port 993:
>
>>> openssl s_server -cert public.pem -key ca-key.pem -accept 993
>> Enter pass phrase for ca-key.pem:
>> Loading 'screen' into random state - done
>> Using default temp DH parameters
>> ACCEPT
>> -----BEGIN SSL SESSION PARAMETERS-----
>> MFUCAQECAgMBBAIAOQQABDAM5TDoa/9vlS6pUsqtlPWpgpMc1L7bvwCS5UGiIhut
>> 13A4uf0Zm8T2/q3ULkxnkPKhBgIEVP2ataIEAgIBLKQGBAQBAAAA
>> -----END SSL SESSION PARAMETERS-----
>> Shared ciphers:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3
>> -SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES
>> 128-SHA:IDEA-CBC-SHA:RC4-SHA
>> CIPHER is DHE-RSA-AES256-SHA
>> Secure Renegotiation IS NOT supported
>> ~A1 LOGIN "MYLOGIN" "MYPASSWORD"
>> ERROR
>> shutting down SSL
>> CONNECTION CLOSED
>> ACCEPT
> Hurray!  But wait, a plain text password?  And no server certificate
> pinning?  Oh, no!
Yep, that is essentially what the e-mail protocols allowin
most real world scenarios.  Note however that the password
is SSL/TLS encrypted, which is why some mail clients and
servers are quite insistant on having that enabled.  For
example, the usual configuration of the e-mail servers
recommended by the Debian distribution (exim SMTP and courier
POP3/IMAP), the default configuration is for the server to
not even ask for a password until SSL/TLS is active, the only
thing a client can do in plaintext is to ask for STARTTLS, or
deliver remote mail (which obviously doesn't require a password).

But at least the client should refuse if the certificate does
not match the DNS name or IP address it was trying to contact
(not to be confused with whatever name the server returns in
protocol messages such as the SMTP banner).

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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 jonetsu at teksavvy.com  Tue Mar 10 15:25:29 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 10 Mar 2015 11:25:29 -0400
Subject: [openssl-users] FIPS: Common method executed in case of error
In-Reply-To: <20150310132938.GA10807@openssl.org>
References: <04c6239e88f8df86942c8a25030c90b3@teksavvy.com>
 <20150310132938.GA10807@openssl.org>
Message-ID: <54578be7664722b9dc3e2f49c5b51d4b@teksavvy.com>



> From: "Dr. Stephen Henson" <steve at openssl.org> 
> Date: 03/10/15 10:21 

> Although you cannot modify the FIPS module itself without voiding the
> validation you *can* change the FIPS capable OpenSSL.

> You might (for example) change FIPS_mode_set() to always add a callback
> which logs any errors.

I see.? So this would actually enable benefiting (saving
validation costs) from an intact recent OpenSSL 1.0.1k with all
security fixes.

FIPS_mode_set() is very straightforward to patch although it
would only catch startup errors.? Not the eventual errors from
tests that are executed before each crypto use.? And not the
continuous RNG tests.

Within the scope of OpenSSL itself, there is a
fips_cipher_abort() that is called for each algo.? That macro
could perhaps be a good place.? Although it would still not catch
continuous RNG test failures.

Regards.







From jetson23 at hotmail.com  Tue Mar 10 16:01:53 2015
From: jetson23 at hotmail.com (Jason Schultz)
Date: Tue, 10 Mar 2015 16:01:53 +0000
Subject: [openssl-users] FIPS_module_version_text()
Message-ID: <COL126-W458B8A10B768A206E7656C7180@phx.gbl>

Is this function available to call in OpenSSL 1.0.1? I'm trying to call it from my application running a FIPS capable version of OpenSSL (everything else works, turning FIPS on, etc), but I include fips.h but I get a compile error saying the function was not declared.
I did find something in the CVS repository that says it was added to 1.1.0:
http://marc.info/?l=openssl-cvs&m=130982270901165
I feel like I'm missing something obvious... 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150310/8642c84c/attachment.html>

From rsalz at akamai.com  Tue Mar 10 17:32:12 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 10 Mar 2015 17:32:12 +0000
Subject: [openssl-users] How to make a rehandshake(renegotiation)?
In-Reply-To: <2380441425995605@web6j.yandex.ru>
References: <6424461425847368@web8o.yandex.ru>
 <2380441425995605@web6j.yandex.ru>
Message-ID: <81c2aa44efbf47d38def31be1a91f4bd@ustx2ex-dag1mb2.msg.corp.akamai.com>

> Does OpenSSL support renegotiation?

Yes.

You probably need more than that. :) Take a look at the apps/s_client and look for the 'R' constant to see how to do client-initiated reneg.



From jetson23 at hotmail.com  Tue Mar 10 18:54:31 2015
From: jetson23 at hotmail.com (Jason Schultz)
Date: Tue, 10 Mar 2015 18:54:31 +0000
Subject: [openssl-users] FIPS_module_version_text()
In-Reply-To: <COL126-W458B8A10B768A206E7656C7180@phx.gbl>
References: <COL126-W458B8A10B768A206E7656C7180@phx.gbl>
Message-ID: <COL126-W224D125BCEDD14ADAFFA4BC7180@phx.gbl>

I guess I didn't have the correct fips.h file in my include path when I couldn't get it to compile. But I don't think it will work for my purposes since if I install my application on another system, that entry point is not defined in libcrypto.so or libssl.so. 
Does anyone know if it's really going to be added to 1.1.0?

From: jetson23 at hotmail.com
To: openssl-users at openssl.org
Subject: FIPS_module_version_text()
Date: Tue, 10 Mar 2015 16:01:53 +0000




Is this function available to call in OpenSSL 1.0.1? I'm trying to call it from my application running a FIPS capable version of OpenSSL (everything else works, turning FIPS on, etc), but I include fips.h but I get a compile error saying the function was not declared.
I did find something in the CVS repository that says it was added to 1.1.0:
http://marc.info/?l=openssl-cvs&m=130982270901165
I feel like I'm missing something obvious... 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150310/d2bddbe8/attachment-0001.html>

From rasjv at yandex.com  Tue Mar 10 19:10:11 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Tue, 10 Mar 2015 22:10:11 +0300
Subject: [openssl-users] SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE
In-Reply-To: <54FEFC41.30807@wisemo.com>
References: <2185001424516315@web24h.yandex.ru>
 <9DBCE555-B4A6-44C9-B52D-523ED3195209@sharp.fm>
 <8189421425903679@web28m.yandex.ru> <54FEFC41.30807@wisemo.com>
Message-ID: <3498301426014611@web5j.yandex.ru>


Hi, Jakob. Thanks for reply.

Now I have seen OpenSSL code and something clear for me.

WANT_READ/WANT_WRITE it's just an implementation for "WOULDBLOCK": not fatal error for non-blocking IO. So, for example for socket and Windows it's just WSAEWOULDBLOCK returns by WSAGetLastError. Peforms by BIO_sock_should_retry/BIO_sock_non_fatal_error in sock_read/sock_write.

There was some incomprehension for me because I forgot that SSL_read/SSL_write can perform a handshake if it didn't happen before. This is the key, because if handshake took place when SSL_write never will want read(to my mind), because it's just perform writesocket(send) operation. 

But with Rehandshaking (renegotiation) still incomprehension... I don't know why there is a silence about this here and in the net! 

I have read Eric Rescorla's old(January 10, 2002) article and there he told about Rehandshaking on the Server and on the Client, so it's possible with OpenSSL, but maybe in newer versions of OpenSSL it is not possible?

Jakob, can you tell me: is it possible to renegotiate a connection in OpenSSL? And if yes how to do it right?



10.03.2015, 19:06, "Jakob Bohm" <jb-openssl at wisemo.com>:
> Not having tested or read the relevant OpenSSL code, I
> presume that SSL_write could want a read if it has sent
> a handshake message, but not yet received the reply, thus
> it cannot (encrypt and) send user data until it has
> received and acted on the handshake reply message.
>
> Maybe the easier scenarios are at the start of a session,
> where the initial handshake has not yet completed, as
> happens in a HTTPS client (always writes a request before
> the first read) or a simple SMTPS server (always writes a
> banner line before the first read of client commands,
> except in some servers that do an early read to check if
> a broken/spammer client is trying to send before receiving
> the banner).

From rasjv at yandex.com  Tue Mar 10 19:23:41 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Tue, 10 Mar 2015 22:23:41 +0300
Subject: [openssl-users] Delay of email delivery for the list
Message-ID: <3689971426015421@web16m.yandex.ru>

Hello,

I see some delay about 30-40 min for my emails. They arrive and I see them in the incoming messages in the list only after 30-40 min.  And one email was delivered for 2 hours. Is it normal for the openssl-users at openssl.org?

Some time ago I see an email with message: Welcome to the openssl-users at mta.opensslfoundation.net mailing list!

Maybe now when something have changed we must send emails to the openssl-users at mta.opensslfoundation.net not to the openssl-users at openssl.org?

Regards.

From dthompson at prinpay.com  Tue Mar 10 21:07:47 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Tue, 10 Mar 2015 17:07:47 -0400
Subject: [openssl-users] How to disable all EXPORT Ciphers?
In-Reply-To: <20150309164645.GW1260@mournblade.imrryr.org>
References: <CAGg4YWEGYHXadt7Obbvn3HEy7ZgDk_2pQNhVtM=PGSjZonAwUw@mail.gmail.com>
 <CAGg4YWGsmEbd_8DLqhJ2kHgs1pa1Ss2fMR5uF0oHVM26p21fVQ@mail.gmail.com>
 <20150309164645.GW1260@mournblade.imrryr.org>
Message-ID: <003901d05b76$43d73430$cb859c90$@prinpay.com>

> From: openssl-users On Behalf Of Viktor Dukhovni
> Sent: Monday, March 09, 2015 12:47

> On Mon, Mar 09, 2015 at 02:23:53PM +0530, Deepak wrote:
> > "kEDH:ALL:!ADH:!DES:!LOW:!EXPORT:+SSLv2:@STRENGTH"
> > with SSL_CTX_set_cipher_list() be good enough to disable EXPORT40, 56
> and 1024?
> 
You only need worry about the original exports retronymed EXPORT40.
EXPORT56 was a draft RFC that was not adopted, and the SSL_CIPHER 
blocks still in source are disabled by a macro hardcoded in tls1.h (q.v.).
"EXP1024-blah" would be the names of the nonexistent EXPORT56 ciphers.

> Note that doing so does not address the FREAK CVE in SSL clients.  Even
> with EXPORT ciphers disabled they are still vulnerable, unless patched!
> 
Yes.

> As for your proposed cipherlist it is too exotic.
> 
>     * ALL:!ADH is simply DEFAULT.  DEFAULT already prefers PFS (including
>       ECDHE) and is sorted by strength.
> 
For 1.0.0+ DEFAULT is ALL:!aNULL:!eNULL:!SSLv2; !aNULL disables both 
ADH and AECDH. (0.9.8 excludes all ECC, including AECDH, unless ECCdraft.)
!eNULL actually has no effect because ALL already excludes it; if you want 
eNULL (you shouldn't) you need the absurd-looking COMPLEMENTOFALL.

>     * DES is a subset of LOW
> 
In fact DES is the only algorithm in LOW. (In math a set is a subset of
itself
and also a superset of itself but laypeople often don't expect that.)

>     * I would also disable SSLv2, which is a subset of MD5, so I generally
>       disable that instead which also drops the SSLv3's RC4-MD5 leaving
RC4-
> SHA
>       for interop.  Note for many applications RC4 is no longer supposed
to be
>       used, consider whether disabling RC4 is appropriate for you.
> 
And disabling SSLv2 *ciphers* has the good effect of disabling SSLv2
*protocol* 
even if old or poor code calls SSLv23 and doesn't explicitly OP_NO_SSLv2. 

> Therefore, I'd suggest:
> 
> 	DEFAULT:!EXPORT:!LOW:!MD5
> 
> Which keeps things simple by starting with DEFAULT and removing
> what you want to disable.
> 



From rsalz at akamai.com  Tue Mar 10 22:03:30 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 10 Mar 2015 22:03:30 +0000
Subject: [openssl-users] Delay of email delivery for the list
In-Reply-To: <3689971426015421@web16m.yandex.ru>
References: <3689971426015421@web16m.yandex.ru>
Message-ID: <76e6f82ee0ef428a91c545b1046f66ab@ustx2ex-dag1mb2.msg.corp.akamai.com>

> I see some delay about 30-40 min for my emails. They arrive and I see them
> in the incoming messages in the list only after 30-40 min.  And one email was
> delivered for 2 hours. Is it normal for the openssl-users at openssl.org?

It happens sometimes.

> Some time ago I see an email with message: Welcome to the openssl-
> users at mta.opensslfoundation.net mailing list!

The OpenSSL domains got shuffled around a bit.  Everything should be openssl.org now.

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



From steve at openssl.org  Tue Mar 10 23:58:13 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 10 Mar 2015 23:58:13 +0000
Subject: [openssl-users] FIPS: Common method executed in case of error
In-Reply-To: <54578be7664722b9dc3e2f49c5b51d4b@teksavvy.com>
References: <04c6239e88f8df86942c8a25030c90b3@teksavvy.com>
 <20150310132938.GA10807@openssl.org>
 <54578be7664722b9dc3e2f49c5b51d4b@teksavvy.com>
Message-ID: <20150310235813.GA28210@openssl.org>

On Tue, Mar 10, 2015, jonetsu wrote:

> 
> 
> > From: "Dr. Stephen Henson" <steve at openssl.org> 
> > Date: 03/10/15 10:21 
> 
> > Although you cannot modify the FIPS module itself without voiding the
> > validation you *can* change the FIPS capable OpenSSL.
> 
> > You might (for example) change FIPS_mode_set() to always add a callback
> > which logs any errors.
> 
> I see.? So this would actually enable benefiting (saving
> validation costs) from an intact recent OpenSSL 1.0.1k with all
> security fixes.
> 

Only the FIPS module is validated: the FIPS capable OpenSSL uses it.

So you can modify (within reason) the FIPS capable OpenSSL without affecting
the validation . So you can use OpenSSL 1.0.1l or 1.0.2 with the FIPS module.

> FIPS_mode_set() is very straightforward to patch although it
> would only catch startup errors.? Not the eventual errors from
> tests that are executed before each crypto use.? And not the
> continuous RNG tests.
> 

I mean you could add a callback to FIPS_mode_set using FIPS_post_set_callback:
see the fips_test_suite.c application for an example. The supplied callback is
called during each POST, continuous RNG and pairwise consistency checks. The
"op" value is set to FIPS_POST_FAIL if any test fails.

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

From steve at openssl.org  Wed Mar 11 00:09:16 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 11 Mar 2015 00:09:16 +0000
Subject: [openssl-users] FIPS_module_version_text()
In-Reply-To: <COL126-W458B8A10B768A206E7656C7180@phx.gbl>
References: <COL126-W458B8A10B768A206E7656C7180@phx.gbl>
Message-ID: <20150311000916.GA30952@openssl.org>

On Tue, Mar 10, 2015, Jason Schultz wrote:

> Is this function available to call in OpenSSL 1.0.1? I'm trying to call it from my application running a FIPS capable version of OpenSSL (everything else works, turning FIPS on, etc), but I include fips.h but I get a compile error saying the function was not declared.

That's odd. I just compiled OpenSSL 1.0.1 and FIPS_module_version_text was
present in libcrypto.so. Are you linking against the FIPS capable OpenSSL or
the system supplied one?

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

From jetson23 at hotmail.com  Wed Mar 11 00:31:19 2015
From: jetson23 at hotmail.com (Jason Schultz)
Date: Tue, 10 Mar 2015 19:31:19 -0500
Subject: [openssl-users] FIPS_module_version_text()
In-Reply-To: <20150311000916.GA30952@openssl.org>
References: <COL126-W458B8A10B768A206E7656C7180@phx.gbl>
 <20150311000916.GA30952@openssl.org>
Message-ID: <COL401-EAS1008F3A752EDE4782C728CDC7190@phx.gbl>

Hmm. I am pretty sure I was linking against the FIPS capable OpenSSL but I will double check tomorrow to make sure I did it right. 

Thanks. 



> On Mar 10, 2015, at 7:28 PM, Dr. Stephen Henson <steve at openssl.org> wrote:
> 
>> On Tue, Mar 10, 2015, Jason Schultz wrote:
>> 
>> Is this function available to call in OpenSSL 1.0.1? I'm trying to call it from my application running a FIPS capable version of OpenSSL (everything else works, turning FIPS on, etc), but I include fips.h but I get a compile error saying the function was not declared.
> 
> That's odd. I just compiled OpenSSL 1.0.1 and FIPS_module_version_text was
> present in libcrypto.so. Are you linking against the FIPS capable OpenSSL or
> the system supplied one?
> 
> 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  Wed Mar 11 05:07:22 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Wed, 11 Mar 2015 06:07:22 +0100
Subject: [openssl-users] Delay of email delivery for the list
In-Reply-To: <3689971426015421@web16m.yandex.ru>
References: <3689971426015421@web16m.yandex.ru>
Message-ID: <20150311050722.GA8089@roeckx.be>

On Tue, Mar 10, 2015 at 10:23:41PM +0300, Serj Rakitov wrote:
> Hello,
> 
> I see some delay about 30-40 min for my emails. They arrive and I see them in the incoming messages in the list only after 30-40 min.  And one email was delivered for 2 hours. Is it normal for the openssl-users at openssl.org?
> 
> Some time ago I see an email with message: Welcome to the openssl-users at mta.opensslfoundation.net mailing list!
> 
> Maybe now when something have changed we must send emails to the openssl-users at mta.opensslfoundation.net not to the openssl-users at openssl.org?

The mta.opensslfoundation.net was only very temporary and should
not be used.  openssl-users at openssl.org works just fine and
doesn't have any delay for me.  You can always check the headers
why or where it has any delay.


Kurt


From tejaswini.s2 at hp.com  Wed Mar 11 08:51:54 2015
From: tejaswini.s2 at hp.com (Tejaswini)
Date: Wed, 11 Mar 2015 01:51:54 -0700 (MST)
Subject: [openssl-users] =?utf-8?q?Handling_=E2=80=9COpenSSL_internal_erro?=
 =?utf-8?q?r=2C_assertion_failed=E2=80=9D?=
Message-ID: <1426063914223-56907.post@n7.nabble.com>

When MD5 (or any non FIPS compliant) algorithm is used in FIPS mode, OpenSSL
gives following error and application aborts.

fips_md.c(146): OpenSSL internal error, assertion failed: Digest update
previous FIPS forbidden algorithm error ignored
Aborted (core dumped)

In our application we want to handle this error and gracefully exit by
logging appropriate error message. 
For which, we are looking out for an OpenSSL API or mechanism which can say
whether the algorithm is FIPS compliant or not.
And would not like to have hard coded algorithm list to check if its FIPS
compliant or not.

Can anyone help me out on this.

Thanks!!



--
View this message in context: http://openssl.6102.n7.nabble.com/Handling-OpenSSL-internal-error-assertion-failed-tp56907.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From bbrumley at gmail.com  Wed Mar 11 11:00:16 2015
From: bbrumley at gmail.com (Billy Brumley)
Date: Wed, 11 Mar 2015 13:00:16 +0200
Subject: [openssl-users] Delay of email delivery for the list
In-Reply-To: <20150311050722.GA8089@roeckx.be>
References: <3689971426015421@web16m.yandex.ru>
 <20150311050722.GA8089@roeckx.be>
Message-ID: <CAFeDd5ZLWEW20kLnpC1CP7Rurp_nJPXHOMhmvtWfPoBVZnpC=w@mail.gmail.com>

> The mta.opensslfoundation.net was only very temporary and should
> not be used.  openssl-users at openssl.org works just fine and
> doesn't have any delay for me.  You can always check the headers
> why or where it has any delay.

Guess I'll mention this here. After the mailing list changes, MARC
stopped archiving the OpenSSL lists, e.g.

http://openssl.org/support/community.html

Those don't have anything since January. I emailed MARC about it but
got no reply. Maybe the list owners should try?

BBB

From steve at openssl.org  Wed Mar 11 12:25:44 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 11 Mar 2015 12:25:44 +0000
Subject: [openssl-users] Handling ???OpenSSL internal error,
 assertion failed???
In-Reply-To: <1426063914223-56907.post@n7.nabble.com>
References: <1426063914223-56907.post@n7.nabble.com>
Message-ID: <20150311122544.GA30452@openssl.org>

On Wed, Mar 11, 2015, Tejaswini wrote:

> When MD5 (or any non FIPS compliant) algorithm is used in FIPS mode, OpenSSL
> gives following error and application aborts.
> 
> fips_md.c(146): OpenSSL internal error, assertion failed: Digest update
> previous FIPS forbidden algorithm error ignored
> Aborted (core dumped)
> 
> In our application we want to handle this error and gracefully exit by
> logging appropriate error message. 
> For which, we are looking out for an OpenSSL API or mechanism which can say
> whether the algorithm is FIPS compliant or not.
> And would not like to have hard coded algorithm list to check if its FIPS
> compliant or not.
> 
> Can anyone help me out on this.
> 

You get an error code from EVP_DigestInit* if you attempt to use a non-FIPS
algorithm in FIPS mode. You only get the above condition if you ignore that
initial error.

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

From rsalz at akamai.com  Wed Mar 11 13:36:08 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Mar 2015 13:36:08 +0000
Subject: [openssl-users] Delay of email delivery for the list
In-Reply-To: <CAFeDd5ZLWEW20kLnpC1CP7Rurp_nJPXHOMhmvtWfPoBVZnpC=w@mail.gmail.com>
References: <3689971426015421@web16m.yandex.ru>
 <20150311050722.GA8089@roeckx.be>
 <CAFeDd5ZLWEW20kLnpC1CP7Rurp_nJPXHOMhmvtWfPoBVZnpC=w@mail.gmail.com>
Message-ID: <18d0d123d9704444a2bf803423318cc4@ustx2ex-dag1mb2.msg.corp.akamai.com>

> Guess I'll mention this here. After the mailing list changes, MARC stopped
> archiving the OpenSSL lists, e.g.

Thanks, I'll get in touch with them.

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



From jonetsu at teksavvy.com  Wed Mar 11 15:14:25 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Wed, 11 Mar 2015 11:14:25 -0400
Subject: [openssl-users] FIPS: Common method executed in case of error
In-Reply-To: <20150310235813.GA28210@openssl.org>
References: <04c6239e88f8df86942c8a25030c90b3@teksavvy.com>
 <20150310132938.GA10807@openssl.org>
 <54578be7664722b9dc3e2f49c5b51d4b@teksavvy.com>
 <20150310235813.GA28210@openssl.org>
Message-ID: <b354c650bfab20d3761baf7e1d7c4c65@teksavvy.com>



> From: "Dr. Stephen Henson" <steve at openssl.org> 
> Date: 03/10/15 20:04 

> I mean you could add a callback to FIPS_mode_set using
> FIPS_post_set_callback: see the fips_test_suite.c application
> for an example. The supplied callback is called during each
> POST, continuous RNG and pairwise consistency checks. The "op"
> value is set to FIPS_POST_FAIL if any test fails.

This is basically what was also suggested by Henrik in a related
thread recently, which I understood being implemented in an
application.? The variation here would be that the callback is
part of the library, located in FIPS_mode_set() in o_fips.c, with
the callback itself being defined elsewhere in the same file.

A potentially useful case for some applications that do not need
to be further modified would be for the library to automatically
know that it has to run in FIPS mode.? Eg. to automatically call
FIPS_mode_set() at load time, based on a env. var. or some other
external sign.





From aroman at alienvault.com  Wed Mar 11 15:40:03 2015
From: aroman at alienvault.com (Alberto Roman Linacero)
Date: Wed, 11 Mar 2015 16:40:03 +0100
Subject: [openssl-users] FIPS mode uses /dev/urandom ?
Message-ID: <CAL9uvPctBe=1=iDiY78+kU3s7vOg2144vtbFHRFoC4mSmMej3w@mail.gmail.com>

Dear all, I'm doing an strace to the FIPS validated version of
openssl, and I'm seeing that is uses /dev/urandom. I thought that the
FIPS validated module always use /dev/random, isn't this the case, or
am I doing something wrong?.

If it uses /dev/urandom, is it possible/advisable to change it to
/dev/random (how?), and still the module being FIPS validated?

Thanks for your help in advance and best regards,
Alberto.

From rasjv at yandex.com  Wed Mar 11 16:02:30 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Wed, 11 Mar 2015 19:02:30 +0300
Subject: [openssl-users] How to make a rehandshake(renegotiation)?
In-Reply-To: <81c2aa44efbf47d38def31be1a91f4bd@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <6424461425847368@web8o.yandex.ru>
 <2380441425995605@web6j.yandex.ru>
 <81c2aa44efbf47d38def31be1a91f4bd@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <7561321426089750@web8g.yandex.ru>


10.03.2015, 21:40, "Salz, Rich" <rsalz at akamai.com>:
> Yes.
> You probably need more than that. :) Take a look at the apps/s_client and look for the 'R' constant to see how to do client-initiated reneg.

I have took a look at the apps/s_client.
I see only several lines of code about renegotiation:
//...............
                static int iiii;
                if (++iiii == 52) {
                    SSL_renegotiate(con);
                    iiii = 0;
                }
//...............
            if ((!c_ign_eof) && (cbuf[0] == 'R')) {
                BIO_printf(bio_err, "RENEGOTIATING\n");
                SSL_renegotiate(con);
                cbuf_len = 0;
            }
//...............

So only one function is used: SSL_renegotiate
I also use it - but nothing happens or error:

OpenSSL error: 5044:error:140940F5:SSL routines:ssl3_read_bytes:unexpected record:.\ssl\s3_pkt.c:1611:

NO renegotioation!

More than that I tested s_client on several domains. I typed "R" after s_client was connected but got a error:

2992:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:.\ssl\s3_pkt.c:644: error in s_client

I also have took a look at the s_server and saw only one function: SSL_renegotiate that seems to be must make a renegotioation. I do some else in code but:  NO renegotioation happens! Why?

Can anybody help and though explain about renegotiation at all? Maybe I don't know something...
When it can be used? Maybe it's disable by default for security reasons in OpenSSL? 
There is a function SSL_get_secure_renegotiation_support. Seems to be renegotiation can be secure or no. Maybe something else.... 

But right now I want to perform ANY type of renegotiation )) Nothing happens or error...


Regards.

From kgoldman at us.ibm.com  Wed Mar 11 16:24:37 2015
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Wed, 11 Mar 2015 12:24:37 -0400
Subject: [openssl-users] Dynamic link openssl with Visual Studio
Message-ID: <mdpq84$6gc$1@ger.gmane.org>

I would like to use the Shining Light precompiled openssl binaries 
within Visual Studio.

I can dynamic link with gcc and the libraries in OpenSSL/lib/MinGW

I can static link with VS and the libraries in OpenSSL/lib/VC/static

When I dynamic link with VS and the libraries in OpenSSL/lib/VC, it 
crashes on a call to PEM_read_PUBKEY(), and appears the stack is corrupted.

I believe that the libeay32MDd.lib matches the VS /MDd setting.  I tried 
with and without applink.c.

Static link would not be the end of the world, but shouldn't it work?




From rsalz at akamai.com  Wed Mar 11 16:35:32 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Mar 2015 16:35:32 +0000
Subject: [openssl-users] How to make a rehandshake(renegotiation)?
In-Reply-To: <7561321426089750@web8g.yandex.ru>
References: <6424461425847368@web8o.yandex.ru>
 <2380441425995605@web6j.yandex.ru>
 <81c2aa44efbf47d38def31be1a91f4bd@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <7561321426089750@web8g.yandex.ru>
Message-ID: <35348fc7abb043cd9bf9968f237d10be@ustx2ex-dag1mb2.msg.corp.akamai.com>

Many servers have disabled client-initiated renegotation.

I thought you were testing your client/server.


From jb-openssl at wisemo.com  Wed Mar 11 16:54:34 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 11 Mar 2015 17:54:34 +0100
Subject: [openssl-users] SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE
In-Reply-To: <3498301426014611@web5j.yandex.ru>
References: <2185001424516315@web24h.yandex.ru>
 <9DBCE555-B4A6-44C9-B52D-523ED3195209@sharp.fm>
 <8189421425903679@web28m.yandex.ru> <54FEFC41.30807@wisemo.com>
 <3498301426014611@web5j.yandex.ru>
Message-ID: <5500734A.3000204@wisemo.com>

On 10/03/2015 20:10, Serj Rakitov wrote:
> Hi, Jakob. Thanks for reply.
>
> Now I have seen OpenSSL code and something clear for me.
>
> WANT_READ/WANT_WRITE it's just an implementation for "WOULDBLOCK": not fatal error for non-blocking IO. So, for example for socket and Windows it's just WSAEWOULDBLOCK returns by WSAGetLastError. Peforms by BIO_sock_should_retry/BIO_sock_non_fatal_error in sock_read/sock_write.
>
> There was some incomprehension for me because I forgot that SSL_read/SSL_write can perform a handshake if it didn't happen before. This is the key, because if handshake took place when SSL_write never will want read(to my mind), because it's just perform writesocket(send) operation.
>
> But with Rehandshaking (renegotiation) still incomprehension... I don't know why there is a silence about this here and in the net!
>
> I have read Eric Rescorla's old(January 10, 2002) article and there he told about Rehandshaking on the Server and on the Client, so it's possible with OpenSSL, but maybe in newer versions of OpenSSL it is not possible?
>
> Jakob, can you tell me: is it possible to renegotiate a connection in OpenSSL? And if yes how to do it right?
>
There is lots of mention of renegotiation (what you call
rehandshaking) in the OpenSSL documents and discussions,
so I am reasonably sure it can be done.  It also seems
there are secure and insecure ways to do it.  I don't
know the details though.

This implies that the general rules about applications
using non-blocking sockets having to always handle the
possibility of WANT_READ/WANT_WRITE at any time might be
invoked by renegotiation scenarios at any time.  Because
the rules say "at any time", there is no specific
discussion of applying those rules at specific times
(such as during renegotiation).

>
> 10.03.2015, 19:06, "Jakob Bohm" <jb-openssl at wisemo.com>:
>> Not having tested or read the relevant OpenSSL code, I
>> presume that SSL_write could want a read if it has sent
>> a handshake message, but not yet received the reply, thus
>> it cannot (encrypt and) send user data until it has
>> received and acted on the handshake reply message.
>>
>> Maybe the easier scenarios are at the start of a session,
>> where the initial handshake has not yet completed, as
>> happens in a HTTPS client (always writes a request before
>> the first read) or a simple SMTPS server (always writes a
>> banner line before the first read of client commands,
>> except in some servers that do an early read to check if
>> a broken/spammer client is trying to send before receiving
>> the banner).
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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 rasjv at yandex.com  Wed Mar 11 17:29:34 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Wed, 11 Mar 2015 20:29:34 +0300
Subject: [openssl-users] Delay of email delivery for the list
In-Reply-To: <20150311050722.GA8089@roeckx.be>
References: <3689971426015421@web16m.yandex.ru>
 <20150311050722.GA8089@roeckx.be>
Message-ID: <6719111426094974@web3o.yandex.ru>


11.03.2015, 08:20, "Kurt Roeckx" <kurt at roeckx.be>:
> The mta.opensslfoundation.net was only very temporary and should
> not be used. ?openssl-users at openssl.org works just fine and
> doesn't have any delay for me. 
Ok.


>?You can always check the headers
> why or where it has any delay.

It's not so important for me as for example "How to make a rehandshake(renegotiation)" )) but let's see in my email's headers:

Was sent:
Date: Wed, 11 Mar 2015 19:02:30 +0300

The path:
Received: by web8g.yandex.ru with HTTP;
	Wed, 11 Mar 2015 19:02:30 +0300
................
Received: from forward20.mail.yandex.net (forward20.mail.yandex.net
 by mta.openssl.org (Postfix) with ESMTPS id E6E9D2015F
 for <openssl-users at openssl.org>; Wed, 11 Mar 2015 16:10:20 +0000 (UTC) [for my timezone 19:10:20 +0300]
.................
Received: by mta.openssl.org (Postfix, from userid 106)
	id 7505E2044B; Wed, 11 Mar 2015 16:50:48 +0000 (UTC) [for my timezone 19:50:48 +0300]
.................
Received: from mta.openssl.org (mta.openssl.org [194.97.150.230])
	by mxfront7j.mail.yandex.net (nwsmtp/Yandex) with ESMTPS id yN2OVojEOL-onhON31U;
	Wed, 11 Mar 2015 19:50:49 +0300
................
Received: from mxfront7j.mail.yandex.net ([127.0.0.1])
	by mxfront7j.mail.yandex.net with LMTP id nT56hQSL
	for <rasjv at yandex.com>; Wed, 11 Mar 2015 19:50:50 +0300

So, it was sent by me at 19:02 (GMT+3). It was received by mta.openssl.org from my mail server already at 19:10 (GMT+3). And was delayed "there" until 19:50 (GMT+3). My mail server received it only at 19:50 (GMT+3).


Once again, it's not so important. But the delay is on the mta.openssl.org mail server(s).

Regards.

From rasjv at yandex.com  Wed Mar 11 17:34:15 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Wed, 11 Mar 2015 20:34:15 +0300
Subject: [openssl-users] Dynamic link openssl with Visual Studio
In-Reply-To: <mdpq84$6gc$1@ger.gmane.org>
References: <mdpq84$6gc$1@ger.gmane.org>
Message-ID: <6730611426095255@web3o.yandex.ru>



11.03.2015, 20:22, "Ken Goldman" <kgoldman at us.ibm.com>:
> I would like to use the Shining Light precompiled openssl binaries
> within Visual Studio.
>
> I can dynamic link with gcc and the libraries in OpenSSL/lib/MinGW
>
> I can static link with VS and the libraries in OpenSSL/lib/VC/static
>
> When I dynamic link with VS and the libraries in OpenSSL/lib/VC, it
> crashes on a call to PEM_read_PUBKEY(), and appears the stack is corrupted.
>
> I believe that the libeay32MDd.lib matches the VS /MDd setting. ?I tried
> with and without applink.c.
>
> Static link would not be the end of the world, but shouldn't it work?

I think you must simply build static libraries yourself  with Visual C++. And it will work.

Regards.

From rasjv at yandex.com  Wed Mar 11 17:39:54 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Wed, 11 Mar 2015 20:39:54 +0300
Subject: [openssl-users] Dynamic link openssl with Visual Studio
In-Reply-To: <mdpq84$6gc$1@ger.gmane.org>
References: <mdpq84$6gc$1@ger.gmane.org>
Message-ID: <8690701426095594@web20h.yandex.ru>


11.03.2015, 20:22, "Ken Goldman" <kgoldman at us.ibm.com>:
> I would like to use the Shining Light precompiled openssl binaries
> within Visual Studio.
>
> I can dynamic link with gcc and the libraries in OpenSSL/lib/MinGW
>
> I can static link with VS and the libraries in OpenSSL/lib/VC/static
>
> When I dynamic link with VS and the libraries in OpenSSL/lib/VC, it
> crashes on a call to PEM_read_PUBKEY(), and appears the stack is corrupted.
>
> I believe that the libeay32MDd.lib matches the VS /MDd setting. ?I tried
> with and without applink.c.
>
> Static link would not be the end of the world, but shouldn't it work?

I think you must simply build static or dynamic libraries(as you need) with Visual C++ yourself.  And they will work.

Regards.

From rasjv at yandex.com  Wed Mar 11 17:42:19 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Wed, 11 Mar 2015 20:42:19 +0300
Subject: [openssl-users] How to make a rehandshake(renegotiation)?
In-Reply-To: <35348fc7abb043cd9bf9968f237d10be@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <6424461425847368@web8o.yandex.ru>
 <2380441425995605@web6j.yandex.ru>
 <81c2aa44efbf47d38def31be1a91f4bd@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <7561321426089750@web8g.yandex.ru>
 <35348fc7abb043cd9bf9968f237d10be@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <8697561426095739@web20h.yandex.ru>


11.03.2015, 20:38, "Salz, Rich" <rsalz at akamai.com>:
> Many servers have disabled client-initiated renegotation.
>
> I thought you were testing your client/server.

Yes I want to test my own client and server. I don't disable renegotation manually. I don't know how to do this.  Maybe it disabled by default?

Regards.

From thomas.francis.jr at pobox.com  Wed Mar 11 20:10:34 2015
From: thomas.francis.jr at pobox.com (Tom Francis)
Date: Wed, 11 Mar 2015 16:10:34 -0400
Subject: [openssl-users] FIPS mode uses /dev/urandom ?
In-Reply-To: <CAL9uvPctBe=1=iDiY78+kU3s7vOg2144vtbFHRFoC4mSmMej3w@mail.gmail.com>
References: <CAL9uvPctBe=1=iDiY78+kU3s7vOg2144vtbFHRFoC4mSmMej3w@mail.gmail.com>
Message-ID: <FB6CFE12-33C4-47EA-8E9B-694735DC0338@pobox.com>


> On Mar 11, 2015, at 11:40 AM, Alberto Roman Linacero <aroman at alienvault.com> wrote:
> 
> Dear all, I'm doing an strace to the FIPS validated version of
> openssl, and I'm seeing that is uses /dev/urandom. I thought that the
> FIPS validated module always use /dev/random, isn't this the case, or
> am I doing something wrong?.
> 
> If it uses /dev/urandom, is it possible/advisable to change it to
> /dev/random (how?), and still the module being FIPS validated?

It would depend on what code is reading from /dev/urandom.  If it?s the FIPS Object Module that?s doing the reading, then no, absolutely not.  If it?s the FIPS-capable OpenSSL that reads from /dev/urandom, you can probably change it.  But I?m curious as to why you would want to do this.  Most systems with /dev/random and /dev/urandom are similar to Linux, in that /dev/urandom is the preferred source for ?random data?, including when seeding a PRNG (which is how it?s used by OpenSSL).  And because /dev/random can block, you might have ridiculously poor performance (and worse, it?ll be unpredictably poor performance, i.e. sometimes it?ll work great, and other times it?ll be horrible, and you never which you?ll get).  This page, http://www.2uo.de/myths-about-urandom/ , is specific to Linux, but at a high-level, It?s also true for AIX, HP-UX, Solaris, FreeBSD, and NetBSD (OpenBSD is more complex).  I?m not about other UNIX-like systems, as I stopped using those before any of them ever provided such devices. :)

TOM

> Thanks for your help in advance and best regards,
> Alberto.
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 


From tejaswini.s2 at hp.com  Thu Mar 12 04:43:17 2015
From: tejaswini.s2 at hp.com (Tejaswini)
Date: Wed, 11 Mar 2015 21:43:17 -0700 (MST)
Subject: [openssl-users] Handling ???OpenSSL internal error,
 assertion failed???
In-Reply-To: <20150311122544.GA30452@openssl.org>
References: <1426063914223-56907.post@n7.nabble.com>
 <20150311122544.GA30452@openssl.org>
Message-ID: <1426135397875-56930.post@n7.nabble.com>


Thanks Steve, for the input.
It helps me in handling the error.



--
View this message in context: http://openssl.6102.n7.nabble.com/Handling-OpenSSL-internal-error-assertion-failed-tp56907p56930.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From rasjv at yandex.com  Thu Mar 12 15:15:07 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Thu, 12 Mar 2015 18:15:07 +0300
Subject: [openssl-users] How to make a rehandshake(renegotiation)?
In-Reply-To: <8697561426095739@web20h.yandex.ru>
References: <6424461425847368@web8o.yandex.ru>
 <2380441425995605@web6j.yandex.ru>
 <81c2aa44efbf47d38def31be1a91f4bd@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <7561321426089750@web8g.yandex.ru>
 <35348fc7abb043cd9bf9968f237d10be@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <8697561426095739@web20h.yandex.ru>
Message-ID: <13253711426173307@web13h.yandex.ru>

Hi,

I managed to do a renegotiation. 
My mistake was that I start renegotiation when not all data were received or sended. 
Probably there was a situation when not all packets(records) were processed and i got a error: unexpected record or bad length.

Really only one function SSL_renegotiate and flag SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION are quite enough. Seems to be all others was for old OpenSLL versions.

Only one question remain, it's opposite to the first one: if i want don't use renegotiation at all, how to disable it?
I see that insecure renegotiation can be disabled by: 
SSL_CTX_clear_options(ctx,SSL_OP_LEGACY_SERVER_CONNECT)
that is enabled by default. 

But what about secure renegotiation? Is it possible to disable it at all for client and server. So, Server rejects queries on secure renegotiation from client and client rejects queries on secure renegotiation from server.

Regards.

From aroman at alienvault.com  Thu Mar 12 16:06:51 2015
From: aroman at alienvault.com (Alberto Roman Linacero)
Date: Thu, 12 Mar 2015 17:06:51 +0100
Subject: [openssl-users] FIPS mode uses /dev/urandom ?
In-Reply-To: <FB6CFE12-33C4-47EA-8E9B-694735DC0338@pobox.com>
References: <CAL9uvPctBe=1=iDiY78+kU3s7vOg2144vtbFHRFoC4mSmMej3w@mail.gmail.com>
 <FB6CFE12-33C4-47EA-8E9B-694735DC0338@pobox.com>
Message-ID: <CAL9uvPeSq+cr8Ysh503HSEDWE31jBi-iwkWWitbb639SgGM8Qw@mail.gmail.com>

Well... I'm just trying, for the test, to do something like:

debian:~/openssl# strace -xe trace=file,read,write,close
/usr/local/ssl/bin/openssl rand 10
[...]
open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3
read(3, "\xa9\xea\xf3\x6e\x08\x14\xe7\xeb\x11\x9c\x72\x64\x69\x54\x0d\x96\x43\x34\x68\x25\xe3\x45\x8b\xe8\xe6\x36\xde\x9b\x33\x3a\x6a\xe2",
32) = 32
close(3)                                = 0

I know that it will have poor performance, and in fact I don't want to
do this... but we're going to pass SP800 56b and they are asking us to
use blocking to be sure that the entropy generated before the openssl
seed is enough (256 entropy bits).

My understanding of how OpenSSL seeds DRBGs is as follows:

When initialization function is called, first the non-approved
hash-based DRBG that is part of the baseline library is seeded. This
DRBG is seeded according to library's settings (in e_os.h DEVRANDOM),
and it defaults to /dev/urandom. After that approved FIPS-mode DRBG
with 256-bit AES-CTR is seeded by calling the bytes() method. This
way, output of the first non-approved DRBG is used to seed FIPS-mode
DRBG. This is why module settings (e_os.h DEVRANDOM) are ignored.

So, I'm not sure if I'm thinking it fine, or if I could change e_os.h
to do that and still being FIPS certified, or...

Alberto.


2015-03-11 21:10 GMT+01:00 Tom Francis <thomas.francis.jr at pobox.com>:
>
>> On Mar 11, 2015, at 11:40 AM, Alberto Roman Linacero <aroman at alienvault.com> wrote:
>>
>> Dear all, I'm doing an strace to the FIPS validated version of
>> openssl, and I'm seeing that is uses /dev/urandom. I thought that the
>> FIPS validated module always use /dev/random, isn't this the case, or
>> am I doing something wrong?.
>>
>> If it uses /dev/urandom, is it possible/advisable to change it to
>> /dev/random (how?), and still the module being FIPS validated?
>
> It would depend on what code is reading from /dev/urandom.  If it?s the FIPS Object Module that?s doing the reading, then no, absolutely not.  If it?s the FIPS-capable OpenSSL that reads from /dev/urandom, you can probably change it.  But I?m curious as to why you would want to do this.  Most systems with /dev/random and /dev/urandom are similar to Linux, in that /dev/urandom is the preferred source for ?random data?, including when seeding a PRNG (which is how it?s used by OpenSSL).  And because /dev/random can block, you might have ridiculously poor performance (and worse, it?ll be unpredictably poor performance, i.e. sometimes it?ll work great, and other times it?ll be horrible, and you never which you?ll get).  This page, http://www.2uo.de/myths-about-urandom/ , is specific to Linux, but at a high-level, It?s also true for AIX, HP-UX, Solaris, FreeBSD, and NetBSD (OpenBSD is more complex).  I?m not about other UNIX-like systems, as I stopped using those before any of them ever provided such devices. :)
>
> TOM
>
>> Thanks for your help in advance and best regards,
>> Alberto.
>> _______________________________________________
>> 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



-- 
Alberto Rom?n

Engineering team
http://www.alienvault.com

Mobile:  +34 605804179
Phone: + 91 5151344
Email: aroman at alienvault.com

From foleyj at cisco.com  Thu Mar 12 16:33:40 2015
From: foleyj at cisco.com (John Foley)
Date: Thu, 12 Mar 2015 12:33:40 -0400
Subject: [openssl-users] FIPS mode uses /dev/urandom ?
In-Reply-To: <CAL9uvPeSq+cr8Ysh503HSEDWE31jBi-iwkWWitbb639SgGM8Qw@mail.gmail.com>
References: <CAL9uvPctBe=1=iDiY78+kU3s7vOg2144vtbFHRFoC4mSmMej3w@mail.gmail.com>
 <FB6CFE12-33C4-47EA-8E9B-694735DC0338@pobox.com>
 <CAL9uvPeSq+cr8Ysh503HSEDWE31jBi-iwkWWitbb639SgGM8Qw@mail.gmail.com>
Message-ID: <5501BFE4.4080005@cisco.com>

You don't even need to modify e_os.h.  You can just pass in a new value
for DEVRANDOM using the gcc -D compiler option.  For instance, maybe you
have a hardware device mapped to a Linux device file called
/dev/entropy1.  You can override DEVRANDOM to use this device without
modifying any OpenSSL code.




On 03/12/2015 12:06 PM, Alberto Roman Linacero wrote:
> Well... I'm just trying, for the test, to do something like:
>
> debian:~/openssl# strace -xe trace=file,read,write,close
> /usr/local/ssl/bin/openssl rand 10
> [...]
> open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3
> read(3, "\xa9\xea\xf3\x6e\x08\x14\xe7\xeb\x11\x9c\x72\x64\x69\x54\x0d\x96\x43\x34\x68\x25\xe3\x45\x8b\xe8\xe6\x36\xde\x9b\x33\x3a\x6a\xe2",
> 32) = 32
> close(3)                                = 0
>
> I know that it will have poor performance, and in fact I don't want to
> do this... but we're going to pass SP800 56b and they are asking us to
> use blocking to be sure that the entropy generated before the openssl
> seed is enough (256 entropy bits).
>
> My understanding of how OpenSSL seeds DRBGs is as follows:
>
> When initialization function is called, first the non-approved
> hash-based DRBG that is part of the baseline library is seeded. This
> DRBG is seeded according to library's settings (in e_os.h DEVRANDOM),
> and it defaults to /dev/urandom. After that approved FIPS-mode DRBG
> with 256-bit AES-CTR is seeded by calling the bytes() method. This
> way, output of the first non-approved DRBG is used to seed FIPS-mode
> DRBG. This is why module settings (e_os.h DEVRANDOM) are ignored.
>
> So, I'm not sure if I'm thinking it fine, or if I could change e_os.h
> to do that and still being FIPS certified, or...
>
> Alberto.
>
>
> 2015-03-11 21:10 GMT+01:00 Tom Francis <thomas.francis.jr at pobox.com>:
>>> On Mar 11, 2015, at 11:40 AM, Alberto Roman Linacero <aroman at alienvault.com> wrote:
>>>
>>> Dear all, I'm doing an strace to the FIPS validated version of
>>> openssl, and I'm seeing that is uses /dev/urandom. I thought that the
>>> FIPS validated module always use /dev/random, isn't this the case, or
>>> am I doing something wrong?.
>>>
>>> If it uses /dev/urandom, is it possible/advisable to change it to
>>> /dev/random (how?), and still the module being FIPS validated?
>> It would depend on what code is reading from /dev/urandom.  If it?s the FIPS Object Module that?s doing the reading, then no, absolutely not.  If it?s the FIPS-capable OpenSSL that reads from /dev/urandom, you can probably change it.  But I?m curious as to why you would want to do this.  Most systems with /dev/random and /dev/urandom are similar to Linux, in that /dev/urandom is the preferred source for ?random data?, including when seeding a PRNG (which is how it?s used by OpenSSL).  And because /dev/random can block, you might have ridiculously poor performance (and worse, it?ll be unpredictably poor performance, i.e. sometimes it?ll work great, and other times it?ll be horrible, and you never which you?ll get).  This page, http://www.2uo.de/myths-about-urandom/ , is specific to Linux, but at a high-level, It?s also true for AIX, HP-UX, Solaris, FreeBSD, and NetBSD (OpenBSD is more complex).  I?m not about other UNIX-like systems, as I stopped using those before any of them ever provided such devices. :)
>>
>> TOM
>>
>>> Thanks for your help in advance and best regards,
>>> Alberto.
>>> _______________________________________________
>>> 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 kgoldman at us.ibm.com  Thu Mar 12 16:34:10 2015
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Thu, 12 Mar 2015 12:34:10 -0400
Subject: [openssl-users] Dynamic link openssl with Visual Studio
In-Reply-To: <8690701426095594@web20h.yandex.ru>
References: <mdpq84$6gc$1@ger.gmane.org> <8690701426095594@web20h.yandex.ru>
Message-ID: <mdsf5v$qv0$1@ger.gmane.org>

On 3/11/2015 1:39 PM, Serj Rakitov wrote:
>
> 11.03.2015, 20:22, "Ken Goldman" <kgoldman at us.ibm.com>:
>> I would like to use the Shining Light precompiled openssl binaries
>> within Visual Studio.
>
> I think you must simply build static or dynamic libraries(as you need) with Visual C++ yourself.  And they will work.

Shining Light provides the dynamic libraries for gcc and Visual Studio. 
  I presume that they work or someone would have reported a bug.

I'd rather not go through that process again.  I'd like some advice on 
how to use what they already provide.



From pbellino at mrv.com  Thu Mar 12 17:06:59 2015
From: pbellino at mrv.com (Philip Bellino)
Date: Thu, 12 Mar 2015 17:06:59 +0000
Subject: [openssl-users] HMAC-SHA1-96 in FIPS
Message-ID: <AM3PR03MB0824C86E75605A0243A91F3CC3060@AM3PR03MB0824.eurprd03.prod.outlook.com>


Hello,
I am using the Openssl-1.0.2 with openssl-fips-2.0.9 and have a question.

In the FIPS-198-1 document, Chapter 5 discusses truncation with MACs.

http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf


I believe HMAC-SHA1-96 falls under this category, but I do not see its specifically  listed in Table 4a(Approved Algorithms) of the OpenSSL FIPS 140-2 Security Policy document.

Is it considered approved for use with FIPs?

Thanks,
Phil
Phil Bellino
Principal Software Engineer | MRV Communications Inc.
300 Apollo Drive |  Chelmsford, MA 01824
Phone: 978-674-6870  |   Fax: 978-674-6799
www.mrv.com


[MRV-email]


[E-Banner]<http://www.mrv.com/landing/video-datasheet-mrvs-optidriver-platform>


The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150312/6cabeba8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6563 bytes
Desc: image001.png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150312/6cabeba8/attachment.png>

From shinelight at shininglightpro.com  Fri Mar 13 02:27:57 2015
From: shinelight at shininglightpro.com (Thomas J. Hruska)
Date: Thu, 12 Mar 2015 19:27:57 -0700
Subject: [openssl-users] Dynamic link openssl with Visual Studio
In-Reply-To: <mdsf5v$qv0$1@ger.gmane.org>
References: <mdpq84$6gc$1@ger.gmane.org> <8690701426095594@web20h.yandex.ru>
 <mdsf5v$qv0$1@ger.gmane.org>
Message-ID: <55024B2D.3060900@shininglightpro.com>

On 3/12/2015 9:34 AM, Ken Goldman wrote:
> On 3/11/2015 1:39 PM, Serj Rakitov wrote:
>>
>> 11.03.2015, 20:22, "Ken Goldman" <kgoldman at us.ibm.com>:
>>> I would like to use the Shining Light precompiled openssl binaries
>>> within Visual Studio.
>>
>> I think you must simply build static or dynamic libraries(as you need)
>> with Visual C++ yourself.  And they will work.
>
> Shining Light provides the dynamic libraries for gcc and Visual Studio.
>   I presume that they work or someone would have reported a bug.
>
> I'd rather not go through that process again.  I'd like some advice on
> how to use what they already provide.

Install the full version, which comes with .h and .lib files.  Write 
C/C++ code as one does to use third-party libraries.  Make sure the 
correct .lib files are included in the project's linker settings (e.g. 
if you build with /MD, then use the MD versions).

-- 
Thomas Hruska
Shining Light Productions

Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/

From John.Unsworth at owmessaging.com  Fri Mar 13 07:57:37 2015
From: John.Unsworth at owmessaging.com (John Unsworth)
Date: Fri, 13 Mar 2015 07:57:37 +0000
Subject: [openssl-users] Solaris 64 bit build of 1.0.2 fails fbe internal
	error
Message-ID: <CO1PR02MB1588452C9C03E1CDBCEF209F0070@CO1PR02MB158.namprd02.prod.outlook.com>

I am trying to build 1.0.2 on Solaris 10 64 bit with Studio 12.4 (12.3 failed too).

./Configure solaris64-sparcv9-cc no-shared -m64 -xcode=pic32 -xldscope=hidden
./make

cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -xcode=pic32 -xldscope=hidden -xtarget=ultra -xarch=v9 -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c   -c -o md5-sparcv9.o md5-sparcv9.S
cc: Warning: -xarch=v9 is deprecated, use -m64 to create 64-bit programs
/opt/solarisstudio12.4/bin/fbe: "/tmp/cpp.1426232079.27660.01.s": , approx line 1041: internal error: pic_relocs(): hh reltype?

Reading around, it seems to be caused by setting -xcode=pic32 but I need to set that because I am building a static library that will be linked into a shared library and that requires relocation.

Changing the makefile so that the -xcode=pic32 flag is not passed when compiling .s files solves the problem but I am unsure if I will have an invalid build.

Previous OpenSSL versions have compiled cleanly with this flag set.

Can anyone advise please?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150313/b748ebe0/attachment-0001.html>

From jonetsu at teksavvy.com  Fri Mar 13 14:44:31 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Fri, 13 Mar 2015 10:44:31 -0400
Subject: [openssl-users] EVP_EncryptInit_ex() with EVP__idea_* in FIPS mode
Message-ID: <f4724b7a6d27983d101ab51e9f2f60fd@teksavvy.com>

Hello,

Using fips_hmac.c and the do_crypt() example, compiling
EVP_EncryptInit_ex() with EVP__idea_* in FIPS mode yields:


fips_hmac.c:58:2: warning: passing argument 2 of
?EVP_EncryptInit_ex? makes pointer from integer without a cast
[enabled by default]

? EVP_EncryptInit_ex(&ctx, EVP_idea_cbc(), NULL, key, iv);
? ^

/usr/include/openssl/evp.h:582:5: note: expected ?const struct
EVP_CIPHER *? but argument is of type ?int?

?int EVP_EncryptInit_ex(EVP_CIPHER_CTX *ctx,const EVP_CIPHER
?*cipher, ENGINE *impl,


Others I've tried so far such as EVP_aes_256_cbc(), EVP_rc4(),
EVP_cast5_ecb(), EVP_aes_192_cbc, EVP_bf_cbc() compiles fine
without warning (I've thrown some non-FIPS in there only for
trying).

Regards.






From de.techno at gmail.com  Fri Mar 13 15:02:28 2015
From: de.techno at gmail.com (dE)
Date: Fri, 13 Mar 2015 20:32:28 +0530
Subject: [openssl-users] TLS 1.2 message hiding.
Message-ID: <5502FC04.9080503@gmail.com>

Hi!

I'm using TLS 1.2 with compression and was wondering if OpenSSL 
implements ways to hide the exact length of the message (may be using 
RFC 6066).

Thanks for any hints.

From rsalz at akamai.com  Fri Mar 13 15:26:16 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 13 Mar 2015 15:26:16 +0000
Subject: [openssl-users] TLS 1.2 message hiding.
In-Reply-To: <5502FC04.9080503@gmail.com>
References: <5502FC04.9080503@gmail.com>
Message-ID: <20dbec497eb14eaf83bdbfc9737ef07a@ustx2ex-dag1mb2.msg.corp.akamai.com>

 > I'm using TLS 1.2 with compression and was wondering if OpenSSL
> implements ways to hide the exact length of the message (may be using RFC
> 6066).

No.  What in 6066 were you thinking of trying to use?


From doctor at doctor.nl2k.ab.ca  Fri Mar 13 17:14:18 2015
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Fri, 13 Mar 2015 11:14:18 -0600
Subject: [openssl-users] SNAPSHOT updates
Message-ID: <20150313171418.GA19850@doctor.nl2k.ab.ca>

What is happening?

In the Moutain Time Zone:

It was at 22:22 MST then 23:22 MDT then 00:22 MDT !!


-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
 Never compare your inside with somebody else's outside.  -Hugh Macleod

From kurt at roeckx.be  Sat Mar 14 10:22:56 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 14 Mar 2015 11:22:56 +0100
Subject: [openssl-users] SNAPSHOT updates
In-Reply-To: <20150313171418.GA19850@doctor.nl2k.ab.ca>
References: <20150313171418.GA19850@doctor.nl2k.ab.ca>
Message-ID: <20150314102256.GA8368@roeckx.be>

On Fri, Mar 13, 2015 at 11:14:18AM -0600, The Doctor wrote:
> What is happening?
> 
> In the Moutain Time Zone:
> 
> It was at 22:22 MST then 23:22 MDT then 00:22 MDT !!

Do you mean when the snapshot is made?  The machine runs in UTC,
and the files seem to be made at 6:22 UTC.


Kurt


From doctor at doctor.nl2k.ab.ca  Sat Mar 14 23:43:37 2015
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Sat, 14 Mar 2015 17:43:37 -0600
Subject: [openssl-users] SNAPSHOT updates
In-Reply-To: <20150314102256.GA8368@roeckx.be>
References: <20150313171418.GA19850@doctor.nl2k.ab.ca>
 <20150314102256.GA8368@roeckx.be>
Message-ID: <20150314234336.GA16107@doctor.nl2k.ab.ca>

On Sat, Mar 14, 2015 at 11:22:56AM +0100, Kurt Roeckx wrote:
> On Fri, Mar 13, 2015 at 11:14:18AM -0600, The Doctor wrote:
> > What is happening?
> > 
> > In the Moutain Time Zone:
> > 
> > It was at 22:22 MST then 23:22 MDT then 00:22 MDT !!
> 
> Do you mean when the snapshot is made?  The machine runs in UTC,
> and the files seem to be made at 6:22 UTC.
> 
>

How many times did they change the time release?
 
> Kurt
> 
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Know how to listen, and you will profit even from those who talk badly.-Plutarch

From Alex.Samad at yieldbroker.com  Mon Mar 16 01:46:48 2015
From: Alex.Samad at yieldbroker.com (Alex Samad - Yieldbroker)
Date: Mon, 16 Mar 2015 01:46:48 +0000
Subject: [openssl-users] question about resigning a certificate
Message-ID: <A3FB5D9FD28C50429DF7692DC31054E655391335@DC1INTADCW8201.yieldbroker.com>

Hi

I had a sha1 signed CA and I issued other  identity and CA certificates from this CA.

With the deprecation of sha1 coming, I resigned my original CA (self signed) as sha512, with the same creation and expiry dates. I believe the only thing changed was the signature and serial number.

But when I go to verify older certs that were signed by the original CA (the sha1 signed one), they are no longer valid.

I thought if I used the same private and public key I should be okay. I thought the only relevant issue was the issuer field and that the CA keys where the same . Was I wrong.

Alex





From jonetsu at teksavvy.com  Mon Mar 16 17:17:39 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Mon, 16 Mar 2015 13:17:39 -0400
Subject: [openssl-users] FIPS: Converting AES_ctr128_encrypt() to EVP_
	methods
Message-ID: <7d000521f61381e6bb71635d9f7326c3@teksavvy.com>

Hello,

An application that needs converting to FIPS is currently using
AES_ctr128_encrypt().? That function calls in turn
CRYPTO_ctr128_encrypt() which then does some internal
computations.? They are not documented in the 'full list of
crypto APIs'.? What would be the FIPS-compatible EVP
equivalent(s) ?

Regards.





From jonetsu at teksavvy.com  Mon Mar 16 17:55:20 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Mon, 16 Mar 2015 13:55:20 -0400
Subject: [openssl-users] FIPS: ECC licensing
Message-ID: <7335f2e56a6fc87c04bdff1088c4ce9f@teksavvy.com>

Hello,

? The licenses, patents for ECC was noticed.? In short, if we do not care about this in the sense of not willing to be in any patent infringement situation down the road, the -ecb archive should be used, is that right ?? Also, there is a mention of a NSA-PLA.pdf agreemnet statement.? The file is not found.? Is this still valid in some ways ?

Regards.




From steve at openssl.org  Mon Mar 16 18:19:17 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Mon, 16 Mar 2015 18:19:17 +0000
Subject: [openssl-users] FIPS: Converting AES_ctr128_encrypt() to EVP_
 methods
In-Reply-To: <7d000521f61381e6bb71635d9f7326c3@teksavvy.com>
References: <7d000521f61381e6bb71635d9f7326c3@teksavvy.com>
Message-ID: <20150316181917.GA5909@openssl.org>

On Mon, Mar 16, 2015, jonetsu wrote:

> Hello,
> 
> An application that needs converting to FIPS is currently using
> AES_ctr128_encrypt().? That function calls in turn
> CRYPTO_ctr128_encrypt() which then does some internal
> computations.? They are not documented in the 'full list of
> crypto APIs'.? What would be the FIPS-compatible EVP
> equivalent(s) ?
> 

The EVP cipher is called EVP_aes_128_ctr(): once you pass that as the
EVP_CIPHER argument (for example to EVP_EncryptInit_ex) you can use EVP like
any other cipher.

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

From marquess at openssl.com  Mon Mar 16 18:44:02 2015
From: marquess at openssl.com (Steve Marquess)
Date: Mon, 16 Mar 2015 14:44:02 -0400
Subject: [openssl-users] FIPS: ECC licensing
In-Reply-To: <7335f2e56a6fc87c04bdff1088c4ce9f@teksavvy.com>
References: <7335f2e56a6fc87c04bdff1088c4ce9f@teksavvy.com>
Message-ID: <55072472.6080309@openssl.com>

On 03/16/2015 01:55 PM, jonetsu wrote:
> Hello,
> 
> The licenses, patents for ECC was noticed.  In short, if we do not
> care about this in the sense of not willing to be in any patent
> infringement situation down the road, the -ecb archive should be
> used, is that right ?

It's "ecp", not "ecb". But yes, the "ecp" version omits binary curve ECC
for those concerned about those patents.

> Also, there is a mention of a NSA-PLA.pdf
> agreemnet statement.  The file is not found.  Is this still valid in
> some ways ?

Still valid:

  http://openssl.com/testing/validation-2.0/docs/NSA-PLA.pdf

-Steve M.

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

From matt at openssl.org  Mon Mar 16 19:05:31 2015
From: matt at openssl.org (Matt Caswell)
Date: Mon, 16 Mar 2015 19:05:31 +0000
Subject: [openssl-users] Forthcoming OpenSSL releases
Message-ID: <5507297B.8040505@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Forthcoming OpenSSL releases
============================

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf.

These releases will be made available on 19th March. They will fix a
number of security defects. The highest severity defect fixed by these
releases is classified as "high" severity.

Yours

The OpenSSL Project Team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVByl7AAoJENnE0m0OYESRm5MIAJV4ElRSS575QkYwPcOw7VTK
8Ulc6TMHsy2s5UvTXl/THqEoy5n92v99Cm69Y69TSWOgK9FK8aV0BuKkVZVYp3Ko
MYV4VMr8a7YiNh/16HctRLfEPH8bg5AkY76Y4RM5i1AXafSR6wMuwlJl21TmqMI+
J+HA39UvlWZ9zI7Lzz0v1BMoGAXg0cr8//QRcrFFgZZuUVtscwRRA9nRS65+AJhX
ogd3ncUPUI3YEzxqv0kDfUre/2XeUNOM+N+u9pyfjoXHaMVsSX3A1HtpmEAMyzhE
DqF+kmhTEyK0HYCVLnl6PLnBdHpPKY3qNFYd8trFyC2hpB9U6Qsut4KeKNtAi2g=
=Uwpw
-----END PGP SIGNATURE-----

From jacques.p.florence at gmail.com  Mon Mar 16 21:10:26 2015
From: jacques.p.florence at gmail.com (Jacques FLORENCE)
Date: Mon, 16 Mar 2015 17:10:26 -0400
Subject: [openssl-users] How to select supported signature algorithms
Message-ID: <CAAb_8sGYQFs6RuxtStYZePRgYdToSqpovU7L4XDBCiwN1ZPLNA@mail.gmail.com>

Hello,
I am developing a simple client/server application with openSSL.

Using wireshark, I can see in the Client Hello message that there is an
extension signature_algorithms, in which are fields Signature Hash
Algorithms.
I can see a lot of supported algorithms, such as RSA, DSA, ECDSA in the
fields *Signature Hash Algorithm Signature* ,and SHA1, SHA256, MD5,
... for *Signature
Hash Algorithm Hash*.

The same behavior happens in the Server Key Exchange message.
My question is: how can I restrict this list of algorithms to use only one?
Note that I am already using the function set_cipher_list(), and as a
consequence, the field *Cipher Suites* in those messages only contains the
suite I want to use. So I don't know what is the API function to use
instead of ssl_ctx_set_cipher_list().

I didn't find anything in the documentation.

Thank you for your help,
Jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150316/4aa34b76/attachment.html>

From steve at openssl.org  Mon Mar 16 22:11:40 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Mon, 16 Mar 2015 22:11:40 +0000
Subject: [openssl-users] How to select supported signature algorithms
In-Reply-To: <CAAb_8sGYQFs6RuxtStYZePRgYdToSqpovU7L4XDBCiwN1ZPLNA@mail.gmail.com>
References: <CAAb_8sGYQFs6RuxtStYZePRgYdToSqpovU7L4XDBCiwN1ZPLNA@mail.gmail.com>
Message-ID: <20150316221140.GA21306@openssl.org>

On Mon, Mar 16, 2015, Jacques FLORENCE wrote:

> Hello,
> I am developing a simple client/server application with openSSL.
> 
> Using wireshark, I can see in the Client Hello message that there is an
> extension signature_algorithms, in which are fields Signature Hash
> Algorithms.
> I can see a lot of supported algorithms, such as RSA, DSA, ECDSA in the
> fields *Signature Hash Algorithm Signature* ,and SHA1, SHA256, MD5,
> ... for *Signature
> Hash Algorithm Hash*.
> 
> The same behavior happens in the Server Key Exchange message.
> My question is: how can I restrict this list of algorithms to use only one?
> Note that I am already using the function set_cipher_list(), and as a
> consequence, the field *Cipher Suites* in those messages only contains the
> suite I want to use. So I don't know what is the API function to use
> instead of ssl_ctx_set_cipher_list().
> 
> I didn't find anything in the documentation.
> 

You need OpenSSL 1.0.2 to set a custom supported signature algorithms
extension. You can use the macro SSL_CTX_set1_sigalgs_list(ctx, sigstring)
where "sigstring" has the format of SignatureAlgorithms documented at:

https://www.openssl.org/docs/ssl/SSL_CONF_cmd.html

For example  SSL_CTX_set1_sigalgs_list(ctx, "RSA+SHA256");

For the signature algorithm associated with client authentication you use
SSL_CTX_set1_client_sigalgs_list instead.

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

From secaficionado at gmail.com  Tue Mar 17 00:32:16 2015
From: secaficionado at gmail.com (Sec_Aficionado)
Date: Mon, 16 Mar 2015 20:32:16 -0400
Subject: [openssl-users] Forthcoming OpenSSL releases
In-Reply-To: <5507297B.8040505@openssl.org>
References: <5507297B.8040505@openssl.org>
Message-ID: <2FF4A9E2-7862-4A9E-B580-622DBF3E4770@gmail.com>

Thanks for the heads up. Just to confirm, is this "highest severity defect" a yet-to-be-disclosed vulnerability, or a fix for an already known one?

Sent from my mobile

> On Mar 16, 2015, at 3:05 PM, Matt Caswell <matt at openssl.org> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Forthcoming OpenSSL releases
> ============================
> 
> The OpenSSL project team would like to announce the forthcoming release
> of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf.
> 
> These releases will be made available on 19th March. They will fix a
> number of security defects. The highest severity defect fixed by these
> releases is classified as "high" severity.
> 
> Yours
> 
> The OpenSSL Project Team
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJVByl7AAoJENnE0m0OYESRm5MIAJV4ElRSS575QkYwPcOw7VTK
> 8Ulc6TMHsy2s5UvTXl/THqEoy5n92v99Cm69Y69TSWOgK9FK8aV0BuKkVZVYp3Ko
> MYV4VMr8a7YiNh/16HctRLfEPH8bg5AkY76Y4RM5i1AXafSR6wMuwlJl21TmqMI+
> J+HA39UvlWZ9zI7Lzz0v1BMoGAXg0cr8//QRcrFFgZZuUVtscwRRA9nRS65+AJhX
> ogd3ncUPUI3YEzxqv0kDfUre/2XeUNOM+N+u9pyfjoXHaMVsSX3A1HtpmEAMyzhE
> DqF+kmhTEyK0HYCVLnl6PLnBdHpPKY3qNFYd8trFyC2hpB9U6Qsut4KeKNtAi2g=
> =Uwpw
> -----END PGP SIGNATURE-----
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From nhess at Brocade.COM  Tue Mar 17 00:51:51 2015
From: nhess at Brocade.COM (Narada Hess)
Date: Tue, 17 Mar 2015 00:51:51 +0000
Subject: [openssl-users] SSL_ERROR_WANT_READ but nothing to read
Message-ID: <80e64ea1fcf94ab684684d7b63c304a7@BRMWP-EXMB12.corp.brocade.com>

HI,
I have a client application using a single read-write socket in non-blocking mode. In C, on Linux, using openssl 1.0.1e.  After the connection is established and all the initial handshaking is done, the client issues SSL_read(), then enters a loop of:

-          Interpret results (such as break upon socket close)

-          select() on the socket

-          SSL_read() again
. . . until the expected number of bytes have been read.

The first SSL_read() returns SSL_ERROR_WANT_READ and loops to attempt to retry the operation.  But select() indicates that the socket is not readable, so we block forever and the server times out (the server had written a record which the client never reads).

I experimented by skipping the select() and just sleeping a little, but in that case, infinite retries of SSL_read() did not help.  Another experiment was to try writing some arbitrary data.  That _DID_ seem to help and moved the protocol forwards a bit.  But I shouldn't have to do that - we have nothing to write until we have received the full read record.

In case it matters, the server on the other end is an OpenDaylight controller.  Its logs indicate successful handshake, appropriate cipher suite, etc.  And my test client-server application using this logic works just fine.  Also, no SSL_writes() are happening during this, or any other operation that would change the SSL* object state, AFAIK.

I've tried Wireshark on this, but I have not been able to glean too much from it, as everything is encrypted and also it seems to be showing transport sized packets of 15xx bytes instead of application sized records - could that be pointing at the problem?  I did not set the read_ahead option.

Any ideas?  I have spent hours reading the SSL documentation (such as SSL_get_error) and many, many posts and answers, plus several SSL books.  It seems that I am doing the right thing here.  So why is select() blocking?  There is no outstanding write operation, so shouldn't a retry of SSL_read() clear any handshake/renegotiation stuff?

Thanks for any thoughts.  N
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150317/3e5d66e1/attachment.html>

From sins at cisco.com  Tue Mar 17 04:01:49 2015
From: sins at cisco.com (Sindhu S. (sins))
Date: Tue, 17 Mar 2015 04:01:49 +0000
Subject: [openssl-users] Reg : SCEP using OPENSSL
Message-ID: <27B269D567EA2F42A1BD5540889DBA4E18C38F00@xmb-rcd-x09.cisco.com>

Hi all,

I need guidance in understanding as to how SCEP server can be used & integrated with OpenSSL.
My understanding is that SCEP can be used to enroll devices & then it communicates to Certificate Authority that generate certificates.
Can some one point me in right direction ? Basically i am trying to achieve following: Using SCEP to enroll devices & then generate Certificates usingCA.

Any reference to opensource SCEP will be helpful...
I'm also exploring few opensource SCEP implementation, like openscep, sscep, autosscep.. etc....

Thanks,
Sindhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150317/c130f86d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 43 bytes
Desc: image001.gif
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150317/c130f86d/attachment-0001.gif>

From matt at openssl.org  Tue Mar 17 10:22:38 2015
From: matt at openssl.org (Matt Caswell)
Date: Tue, 17 Mar 2015 10:22:38 +0000
Subject: [openssl-users] Forthcoming OpenSSL releases
In-Reply-To: <2FF4A9E2-7862-4A9E-B580-622DBF3E4770@gmail.com>
References: <5507297B.8040505@openssl.org>
 <2FF4A9E2-7862-4A9E-B580-622DBF3E4770@gmail.com>
Message-ID: <5508006E.6010100@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 17/03/15 00:32, Sec_Aficionado wrote:
> Thanks for the heads up. Just to confirm, is this "highest severity
> defect" a yet-to-be-disclosed vulnerability, or a fix for an
> already known one?

This is a previously undisclosed vulnerability.

Matt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVCABuAAoJENnE0m0OYESRmtQH/RJMDjBTBfEY/Va6sM49TYlh
Zn4BVV9a6PLOtPlGS9J23bonolC63Aqgh7SWrMTl+Vosrlw2ZL8kXFCgT9ROpPYh
woX5nzrt1aLMLDf1AahjY2shnsOsp6glCVSH2YnvkUIot4OKhDaXhjxf44er/qFZ
Tc3RTtfTOjcamu/2uhpRnegaZM5QGLm9/5Rkb+iPBVFgAGCaDmIR4KqWSl5VxsV/
xhe7PU/KCXUXgWe9Wou5KrvsWKW02kuJvz5CMMSE6BcYPLaNZEbrtkyaOj5VoSBH
2qDSR4nJeMGXH+uChJSDf90q8yRhnp3Uyha0uEabxo2lzQksaDCL3Tz87NfMPkI=
=Uygc
-----END PGP SIGNATURE-----

From matt at openssl.org  Tue Mar 17 11:03:21 2015
From: matt at openssl.org (Matt Caswell)
Date: Tue, 17 Mar 2015 11:03:21 +0000
Subject: [openssl-users] SSL_ERROR_WANT_READ but nothing to read
In-Reply-To: <80e64ea1fcf94ab684684d7b63c304a7@BRMWP-EXMB12.corp.brocade.com>
References: <80e64ea1fcf94ab684684d7b63c304a7@BRMWP-EXMB12.corp.brocade.com>
Message-ID: <550809F9.5020009@openssl.org>



On 17/03/15 00:51, Narada Hess wrote:
> HI,
> 
> I have a client application using a single read-write socket in
> non-blocking mode. In C, on Linux, using openssl 1.0.1e.  After the
> connection is established and all the initial handshaking is done, the
> client issues SSL_read(), then enters a loop of:
> 
> -          Interpret results (such as break upon socket close)
> 
> -          select() on the socket
> 
> -          SSL_read() again
> 
> . . . until the expected number of bytes have been read.
> 
>  
> 
> The first SSL_read() returns SSL_ERROR_WANT_READ and loops to attempt to
> retry the operation.  But select() indicates that the socket is not
> readable, so we block forever and the server times out (the server had
> written a record which the client never reads).
> 
>  
> 
> I experimented by skipping the select() and just sleeping a little, but
> in that case, infinite retries of SSL_read() did not help.  Another
> experiment was to try writing some arbitrary data.  That _/DID/_ seem to
> help and moved the protocol forwards a bit.  But I shouldn?t have to do
> that ? we have nothing to write until we have received the full read record.
> 
>  
> 
> In case it matters, the server on the other end is an OpenDaylight
> controller.  Its logs indicate successful handshake, appropriate cipher
> suite, etc.  And my test client-server application using this logic
> works just fine.  Also, no SSL_writes() are happening during this, or
> any other operation that would change the SSL* object state, AFAIK.
> 
>  
> 
> I?ve tried Wireshark on this, but I have not been able to glean too much
> from it, as everything is encrypted and also it seems to be showing
> transport sized packets of 15xx bytes instead of application sized
> records ? could that be pointing at the problem?  I did not set the
> read_ahead option.
> 
>  
> 
> Any ideas?  I have spent hours reading the SSL documentation (such as
> SSL_get_error) and many, many posts and answers, plus several SSL
> books.  It seems that I am doing the right thing here.  So why is
> select() blocking?  There is no outstanding write operation, so
> shouldn?t a retry of SSL_read() clear any handshake/renegotiation stuff?
> 

Are you sure the record that the server wrote actually got sent across
the network?

Have you tried connecting to the server using s_client? Does that succeed?

Matt


From foleyj at cisco.com  Tue Mar 17 12:15:47 2015
From: foleyj at cisco.com (John Foley)
Date: Tue, 17 Mar 2015 08:15:47 -0400
Subject: [openssl-users] Reg : SCEP using OPENSSL
In-Reply-To: <27B269D567EA2F42A1BD5540889DBA4E18C38F00@xmb-rcd-x09.cisco.com>
References: <27B269D567EA2F42A1BD5540889DBA4E18C38F00@xmb-rcd-x09.cisco.com>
Message-ID: <55081AF3.5050109@cisco.com>

If it fits your needs, you may want to look into using EST (RFC 7030)
instead of SCEP.  EST is the replacement for SCEP.  The SCEP draft was
never ratified.  The libest open source project implements RFC 7030 and
uses OpenSSL.  It's available at https://github.com/cisco/libest.



On 03/17/2015 12:01 AM, Sindhu S. (sins) wrote:
>
> Hi all,
>
> I need guidance in understanding as to how SCEP server can be used &
> integrated with OpenSSL.
> My understanding is that SCEP can be used to enroll devices & then it
> communicates to Certificate Authority that generate certificates.
> Can some one point me in right direction ? Basically i am trying to
> achieve following: Using SCEP to enroll devices & then generate
> Certificates usingCA.
>
>  
>
> Any reference to opensource SCEP will be helpful?
>
> I?m also exploring few opensource SCEP implementation, like openscep,
> sscep, autosscep.. etc?.
>
> https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif
>
> Thanks,
>
> Sindhu
>
>
>
> _______________________________________________
> 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/20150317/9d74f8c0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 43 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150317/9d74f8c0/attachment.gif>

From mas2 at grtbooks.com  Tue Mar 17 13:28:04 2015
From: mas2 at grtbooks.com (Michael Stickles)
Date: Tue, 17 Mar 2015 09:28:04 -0400
Subject: [openssl-users] What is the format for a parameter file (-paramfile
	option)?
Message-ID: <27f5d7a6$569a5004$38dfc200$@com>

I am attempting to generate keys using genpkey, with the RSA options 
specified in a parameter file:


openssl genpkey -paramfile keygen.params -out ftest.key -outform PEM


However, I'm constantly getting the following error:


Error reading parameter file keygen.params


I can't find any documentation or examples on what format the parameter 
file should be in. Can someone either provide an example of what the 
parameter file should look like, or point to me to one online? I'm not 
having any trouble getting it to work with the parameters specified on the 
command line, but for various reasons would like to have them in a file.


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

From steve at openssl.org  Tue Mar 17 14:29:31 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 17 Mar 2015 14:29:31 +0000
Subject: [openssl-users] What is the format for a parameter file
 (-paramfile option)?
In-Reply-To: <27f5d7a6$569a5004$38dfc200$@com>
References: <27f5d7a6$569a5004$38dfc200$@com>
Message-ID: <20150317142931.GA10419@openssl.org>

On Tue, Mar 17, 2015, Michael Stickles wrote:

> I am attempting to generate keys using genpkey, with the RSA options 
> specified in a parameter file:
> 
> 
> openssl genpkey -paramfile keygen.params -out ftest.key -outform PEM
> 
> 
> However, I'm constantly getting the following error:
> 
> 
> Error reading parameter file keygen.params
> 
> 
> I can't find any documentation or examples on what format the parameter 
> file should be in. Can someone either provide an example of what the 
> parameter file should look like, or point to me to one online? I'm not 
> having any trouble getting it to work with the parameters specified on the 
> command line, but for various reasons would like to have them in a file.
> 

The parameter file is a set of parameters associated with the algorithm and is
typically generated using the -genparam command line option.

For RSA there is no associated parameter file which is why you get errors.

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

From jonetsu at teksavvy.com  Tue Mar 17 14:43:59 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 17 Mar 2015 10:43:59 -0400
Subject: [openssl-users] FIPS: Problem building 1.0.1e : 'T' vs. 't'
Message-ID: <76e0ef0a1bea11b368746d7b19c06ad8@teksavvy.com>

Hello,

There is a problem with compiling the openssl-1.0.1e.tar.gz
sources against the FIPS 2.0 canister.

On my machine the following is declared global:

00000000000dd3c0 T private_AES_set_decrypt_key
00000000000dd0f0 T private_AES_set_encrypt_key

On another machine, they are declared local and the apps build
fails:

00000000000dd3c0 t private_AES_set_decrypt_key
00000000000dd0f0 t private_AES_set_encrypt_key

What is the mecanism that determines which is global and which is
local and what does it depend on to make its decision ?

Regards.




From jonetsu at teksavvy.com  Tue Mar 17 14:46:23 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 17 Mar 2015 10:46:23 -0400
Subject: [openssl-users] FIPS: Error compiling 1.0.1e: 'T' vs. 't'
Message-ID: <db1456450844ed323dbd696a2f7b1eb6@teksavvy.com>

Hello,

There is a problem with compiling the openssl-1.0.1e.tar.gz
sources against the FIPS 2.0 canister.

On my machine the following is declared global:

00000000000dd3c0 T private_AES_set_decrypt_key
00000000000dd0f0 T private_AES_set_encrypt_key

On another machine, they are declared local and the apps build
fails:

00000000000dd3c0 t private_AES_set_decrypt_key
00000000000dd0f0 t private_AES_set_encrypt_key

What is the mecanism that determines which is global and which is
local and what does it depend on to make its decision ?

Regards.





From jonetsu at teksavvy.com  Tue Mar 17 14:54:12 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 17 Mar 2015 10:54:12 -0400
Subject: [openssl-users] FIPS: Error compiling 1.0.1e: 'T' vs. 't'
Message-ID: <32fdccae8bc933b42895936f32e2dcd8@teksavvy.com>

Hello,

There is a problem with compiling the openssl-1.0.1e.tar.gz
sources against the FIPS 2.0 canister.

On my machine the following is declared global:

?00000000000dd3c0 T private_AES_set_decrypt_key
?00000000000dd0f0 T private_AES_set_encrypt_key

On another machine, they are declared local and the apps build
fails:

?00000000000dd3c0 t private_AES_set_decrypt_key
?00000000000dd0f0 t private_AES_set_encrypt_key

What is the mechanism that determines which is global and which is
local and what does it depend on to make its decision ?

Regards.





From jonetsu at teksavvy.com  Tue Mar 17 14:57:23 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 17 Mar 2015 10:57:23 -0400
Subject: [openssl-users] FIPS: Error compiling 1.0.1e: 'T' vs. 't'
Message-ID: <84f4a3b2c185c3f7f006c7e63ac2b937@teksavvy.com>


Hello,

There is a problem with compiling the openssl-1.0.1e.tar.gz
sources against the FIPS 2.0 canister.

On my machine the following is declared global:

?00000000000dd3c0 T private_AES_set_decrypt_key
?00000000000dd0f0 T private_AES_set_encrypt_key

On another machine, they are declared local and the apps build
fails:

?00000000000dd3c0 t private_AES_set_decrypt_key
?00000000000dd0f0 t private_AES_set_encrypt_key

What is the mecanism that determines which is global and which is
local and what does it depend on to make its decision ?

Regards.



From steve at openssl.org  Tue Mar 17 15:13:24 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 17 Mar 2015 15:13:24 +0000
Subject: [openssl-users] FIPS: Problem building 1.0.1e : 'T' vs. 't'
In-Reply-To: <76e0ef0a1bea11b368746d7b19c06ad8@teksavvy.com>
References: <76e0ef0a1bea11b368746d7b19c06ad8@teksavvy.com>
Message-ID: <20150317151324.GA21235@openssl.org>

On Tue, Mar 17, 2015, jonetsu wrote:

> Hello,
> 
> There is a problem with compiling the openssl-1.0.1e.tar.gz
> sources against the FIPS 2.0 canister.
> 
> On my machine the following is declared global:
> 
> 00000000000dd3c0 T private_AES_set_decrypt_key
> 00000000000dd0f0 T private_AES_set_encrypt_key
> 
> On another machine, they are declared local and the apps build
> fails:
> 
> 00000000000dd3c0 t private_AES_set_decrypt_key
> 00000000000dd0f0 t private_AES_set_encrypt_key
> 
> What is the mecanism that determines which is global and which is
> local and what does it depend on to make its decision ?
> 

What are the two platforms? That is what does:

	./config -t

output?

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

From h15234 at mailas.com  Tue Mar 17 15:22:09 2015
From: h15234 at mailas.com (h15234 at mailas.com)
Date: Tue, 17 Mar 2015 08:22:09 -0700
Subject: [openssl-users] openssl 1.0.2 shared build's linking is not
 consistent - bin and libs linked to different libcrypto.so's
Message-ID: <1426605729.1719828.241558337.16F10CB8@webmail.messagingengine.com>

I'm trying to build a library self-consistent instance of openssl 1.0.2 on linux/64.

Setting *FLAGS & rpath, although the openssl binary links correctly against its own {libcrypto,libssl}.so, the libssl.so links against *system*, not its own, libcrypto.

I've tried a bunch of combinations of *FLAGS.  Always the same result.  The current env/result is:

	cd ./openssl-1.0.2

	export SHARED_LDFLAGS="-L/usr/local/sslTEST/lib64 -Wl,-rpath,/usr/local/sslTEST/lib64 -lssl -lcrypto"
	export LDFLAGS=${SHARED_LDFLAGS}
	export LIBDEPS=${SHARED_LDFLAGS}


	./config \
	 --openssldir=/usr/local/sslTEST \
	 --libdir=lib64 \
	threads shared zlib \
	enable-ec_nistp_64_gcc_128 \
	no-idea \
	no-ssl2 \
	no-rc5 \
	no-mdc2 \
	no-hw \
	no-ec2m \
	enable-rfc3779

	make depend
	make
	make install

There are no apparent errors in the build output.

The build results in

	/usr/local/sslTEST/bin/openssl version
		OpenSSL 1.0.2 22 Jan 2015

	ldd \
	 /usr/local/sslTEST/bin/openssl \
	 /usr/local/sslTEST/lib64/libssl.so.1.0.0 \
	 /usr/local/sslTEST/lib64/libcrypto.so.1.0.0

		/usr/local/sslTEST/bin/openssl:
			linux-vdso.so.1 (0x00007ffefffd7000)
			libssl.so.1.0.0 => /usr/local/sslTEST/lib64/libssl.so.1.0.0 (0x00007f93cbe0e000)
!!			libcrypto.so.1.0.0 => /usr/local/sslTEST/lib64/libcrypto.so.1.0.0 (0x00007f93cb9ce000)
			libdl.so.2 => /lib64/libdl.so.2 (0x00007f93cb77f000)
			libz.so.1 => /lib64/libz.so.1 (0x00007f93cb569000)
			libc.so.6 => /lib64/libc.so.6 (0x00007f93cb1c1000)
			/lib64/ld-linux-x86-64.so.2 (0x00007f93cc07a000)

		/usr/local/sslTEST/lib64/libssl.so.1.0.0:
			linux-vdso.so.1 (0x00007ffd01636000)
!!			libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007ff4abf33000)
			libdl.so.2 => /lib64/libdl.so.2 (0x00007ff4abd2f000)
			libz.so.1 => /lib64/libz.so.1 (0x00007ff4abb18000)
			libc.so.6 => /lib64/libc.so.6 (0x00007ff4ab771000)
			/lib64/ld-linux-x86-64.so.2 (0x00007ff4ac60d000)

		/usr/local/sslTEST/lib64/libcrypto.so.1.0.0:
			linux-vdso.so.1 (0x00007ffe1f55d000)
			libdl.so.2 => /lib64/libdl.so.2 (0x00007f9a10f46000)
			libz.so.1 => /lib64/libz.so.1 (0x00007f9a10d30000)
			libc.so.6 => /lib64/libc.so.6 (0x00007f9a10988000)
			/lib64/ld-linux-x86-64.so.2 (0x00007f9a115d5000)


where you can see the different libcrypto's are linked.

Wht specific combination and settings of FLAGS are required to ensure that the bins & libs are all self-consistently linked/rpath'd only against this build's libs?

From de.techno at gmail.com  Tue Mar 17 15:50:50 2015
From: de.techno at gmail.com (dE)
Date: Tue, 17 Mar 2015 21:20:50 +0530
Subject: [openssl-users] TLS 1.2 message hiding.
In-Reply-To: <20dbec497eb14eaf83bdbfc9737ef07a@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <5502FC04.9080503@gmail.com>
 <20dbec497eb14eaf83bdbfc9737ef07a@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <55084D5A.6030303@gmail.com>

On 03/13/15 20:56, Salz, Rich wrote:
>   > I'm using TLS 1.2 with compression and was wondering if OpenSSL
>> implements ways to hide the exact length of the message (may be using RFC
>> 6066).
> No.  What in 6066 were you thinking of trying to use?
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Ok, so TLS does not handle this.

From rsalz at akamai.com  Tue Mar 17 16:59:45 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 17 Mar 2015 16:59:45 +0000
Subject: [openssl-users] TLS 1.2 message hiding.
In-Reply-To: <55084D5A.6030303@gmail.com>
References: <5502FC04.9080503@gmail.com>
 <20dbec497eb14eaf83bdbfc9737ef07a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <55084D5A.6030303@gmail.com>
Message-ID: <35d534d9c5894476a1255f98c5ba2edf@usma1ex-dag1mb2.msg.corp.akamai.com>

> Ok, so TLS does not handle this.

The current draft of the TLS 1.3 specification includes a field to pad every data record.

From jonetsu at teksavvy.com  Tue Mar 17 17:03:28 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 17 Mar 2015 13:03:28 -0400
Subject: [openssl-users] FIPS: Problem building 1.0.1e: 'T' vs. 't'
In-Reply-To: <20150317151324.GA21235@openssl.org>
References: <76e0ef0a1bea11b368746d7b19c06ad8@teksavvy.com>
 <20150317151324.GA21235@openssl.org>
Message-ID: <e7e95524c1ce3cd98493de359c683e4d@teksavvy.com>



> From: "Dr. Stephen Henson" <steve at openssl.org> 
> Date: 03/17/15 12:28 

> What are the two platforms? That is what does:

First of all, I'm very, very sorry to have posted duplicates of the question.? The web-access email client is, was, a bit on the fuzzy side, stalling and reporting errors.

It turns out, at the end of much puzzling and searching, that the difference is in the Debian packaging.? The Debian folks have added some per-method version mechanism to be assured that the APIs are still compatible between OpenSSL number versions.? That mechanism does not recognize the FIPS renaming of some methods hence tags them as local.? We fixed that and it could be that the fix can be given to Debian as it should be transparent to non-FIPS OpenSSL Debian builds.

Again, sorry for the multiple posts !

Regards.




From jb-openssl at wisemo.com  Tue Mar 17 19:49:57 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 17 Mar 2015 20:49:57 +0100
Subject: [openssl-users] question about resigning a certificate
In-Reply-To: <A3FB5D9FD28C50429DF7692DC31054E655391335@DC1INTADCW8201.yieldbroker.com>
References: <A3FB5D9FD28C50429DF7692DC31054E655391335@DC1INTADCW8201.yieldbroker.com>
Message-ID: <55088565.8060505@wisemo.com>

On 16/03/2015 02:46, Alex Samad - Yieldbroker wrote:
> Hi
>
> I had a sha1 signed CA and I issued other  identity and CA certificates from this CA.
>
> With the deprecation of sha1 coming, I resigned my original CA (self signed) as sha512, with the same creation and expiry dates. I believe the only thing changed was the signature and serial number.
>
> But when I go to verify older certs that were signed by the original CA (the sha1 signed one), they are no longer valid.
>
> I thought if I used the same private and public key I should be okay. I thought the only relevant issue was the issuer field and that the CA keys where the same . Was I wrong.
>
> Alex
Run openssl x509 -noout -text -in OneOfYourIssuedCerts.pem| more

Look at what aspects of your CA are mentioned.  For example,
does it include the "X509v3 Authority Key Identifier"
extension, and if so, which fields from the CA cert are
included?


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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/20150317/7470a31c/attachment.html>

From nhess at Brocade.COM  Tue Mar 17 22:47:31 2015
From: nhess at Brocade.COM (Narada Hess)
Date: Tue, 17 Mar 2015 22:47:31 +0000
Subject: [openssl-users] SSL_ERROR_WANT_READ but nothing to read
In-Reply-To: <550809F9.5020009@openssl.org>
References: <80e64ea1fcf94ab684684d7b63c304a7@BRMWP-EXMB12.corp.brocade.com>
 <550809F9.5020009@openssl.org>
Message-ID: <2c25483b60fe4d34b8a0512dda6fd2fa@BRMWP-EXMB12.corp.brocade.com>

In case anyone is following this thread, Matt's suggestion led to the solution.  It turns out we weren't getting a packet from the remote end and all my angst was for naught.  Thanks, Matt, for your help.  N

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell
Sent: Tuesday, March 17, 2015 4:03 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] SSL_ERROR_WANT_READ but nothing to read

On 17/03/15 00:51, Narada Hess wrote:
> HI,
> 
> I have a client application using a single read-write socket in 
> non-blocking mode. In C, on Linux, using openssl 1.0.1e.  After the 
> connection is established and all the initial handshaking is done, the 
> client issues SSL_read(), then enters a loop of:
> 
> -          Interpret results (such as break upon socket close)
> 
> -          select() on the socket
> 
> -          SSL_read() again
> 
> . . . until the expected number of bytes have been read.
> 
>  
> 
> The first SSL_read() returns SSL_ERROR_WANT_READ and loops to attempt 
> to retry the operation.  But select() indicates that the socket is not 
> readable, so we block forever and the server times out (the server had 
> written a record which the client never reads).
> 
>  
> 
> I experimented by skipping the select() and just sleeping a little, 
> but in that case, infinite retries of SSL_read() did not help.  
> Another experiment was to try writing some arbitrary data.  That 
> _/DID/_ seem to help and moved the protocol forwards a bit.  But I 
> shouldn't have to do that - we have nothing to write until we have received the full read record.
> 
>  
> 
> In case it matters, the server on the other end is an OpenDaylight 
> controller.  Its logs indicate successful handshake, appropriate 
> cipher suite, etc.  And my test client-server application using this 
> logic works just fine.  Also, no SSL_writes() are happening during 
> this, or any other operation that would change the SSL* object state, AFAIK.
> 
>  
> 
> I've tried Wireshark on this, but I have not been able to glean too 
> much from it, as everything is encrypted and also it seems to be 
> showing transport sized packets of 15xx bytes instead of application 
> sized records - could that be pointing at the problem?  I did not set 
> the read_ahead option.
> 
>  
> 
> Any ideas?  I have spent hours reading the SSL documentation (such as
> SSL_get_error) and many, many posts and answers, plus several SSL 
> books.  It seems that I am doing the right thing here.  So why is
> select() blocking?  There is no outstanding write operation, so 
> shouldn't a retry of SSL_read() clear any handshake/renegotiation stuff?
> 

Are you sure the record that the server wrote actually got sent across the network?

Have you tried connecting to the server using s_client? Does that succeed?

Matt

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

From Alex.Samad at yieldbroker.com  Wed Mar 18 03:20:49 2015
From: Alex.Samad at yieldbroker.com (Alex Samad - Yieldbroker)
Date: Wed, 18 Mar 2015 03:20:49 +0000
Subject: [openssl-users] question about resigning a certificate
In-Reply-To: <55088565.8060505@wisemo.com>
References: <A3FB5D9FD28C50429DF7692DC31054E655391335@DC1INTADCW8201.yieldbroker.com>
 <55088565.8060505@wisemo.com>
Message-ID: <A3FB5D9FD28C50429DF7692DC31054E655394559@DC1INTADCW8201.yieldbroker.com>

Hi

I have done that and compared the output with diff


The only differences are
Serial number
Signature algo
Comment
Signature.

Alex

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jakob Bohm
Sent: Wednesday, 18 March 2015 6:50 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] question about resigning a certificate

On 16/03/2015 02:46, Alex Samad - Yieldbroker wrote:

Hi



I had a sha1 signed CA and I issued other  identity and CA certificates from this CA.



With the deprecation of sha1 coming, I resigned my original CA (self signed) as sha512, with the same creation and expiry dates. I believe the only thing changed was the signature and serial number.



But when I go to verify older certs that were signed by the original CA (the sha1 signed one), they are no longer valid.



I thought if I used the same private and public key I should be okay. I thought the only relevant issue was the issuer field and that the CA keys where the same . Was I wrong.



Alex
Run openssl x509 -noout -text -in OneOfYourIssuedCerts.pem | more

Look at what aspects of your CA are mentioned.  For example,
does it include the "X509v3 Authority Key Identifier"
extension, and if so, which fields from the CA cert are
included?





Enjoy



Jakob

--

Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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/20150318/9050594f/attachment.html>

From prashant at apigee.com  Wed Mar 18 07:36:40 2015
From: prashant at apigee.com (Prashant Bapat)
Date: Wed, 18 Mar 2015 13:06:40 +0530
Subject: [openssl-users] base64 decode in C
Message-ID: <CAN9aUrimja56hz1FrP6=U081j5Dh4zkxqd0=dFw3oyaydWiQFw@mail.gmail.com>

Hi,

Most likely this has been answered before, please bear with me.

I'm trying to use the base64 decode function in C. Below is the function.

char *b64_decode(unsigned char *input, int length)
{
    BIO *b64, *bmem;
    char *buffer = (char *)malloc(length);
    memset(buffer, 0, length);
    b64 = BIO_new(BIO_f_base64());
    bmem = BIO_new_mem_buf((void*)input, length);
    bmem = BIO_push(b64, bmem);
    BIO_set_flags(bmem, BIO_FLAGS_BASE64_NO_NL);
    BIO_read(bmem, buffer, length);
    BIO_free_all(bmem);
    return buffer;
}

This works well for simple b64 encoded strings like "hello world!" etc. But
when I want to b64 decode the contents of a SSH public key, it fails.
Returns nothing.

What I'm trying to get to is the SSH public key fingerprint which is the
MD5 hash of the base64 decoded part of the public key.

This decodes fine.

"dGhpcyBpcyBhd2Vzb21lCg=="  : "this is awesome"

This does not.
"AAAAB3NzaC1yc2EAAAADAQABAAABAQC/KdcFv09+f+tJK9IZ8I+L0zG7dUINClI5v8FlHJsBPSM3DDO2DpwIg/KqZKCRH9y6lEO+QAJt2DTEq/LBZcBUCdeiX1TXPFRorX+VdZigj7av/S/UHkq2EH6hfkJB3oLA5ZOZioMOAuDv1ng/DE4pRBr+KZ2oVhGjf3wa0hWi21vTZqb3s7vh+bPf6C2eUmAQJKHvFhtBK8Xx7FxN0b7igsGbk7ObwcItfMxdzkMvuiuU/UnthFVpa8wZIObFDi3MxJuf3/R+h6R1lFMvEIrU6CWRupS7Pqkm4X3qWQfhAWbdgdbD5KAk5JLA2eWIPQQA5Uay5CeH+GXz8gCa4zaz"

What I'm I doing wrong ?

Btw in the command line both decode. Using "echo string | openssl enc
-base64 -d -A"

Any help appreciated.

Thanks in advance.

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

From jb-openssl at wisemo.com  Wed Mar 18 07:59:01 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 18 Mar 2015 08:59:01 +0100
Subject: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
In-Reply-To: <5507297B.8040505@openssl.org>
References: <5507297B.8040505@openssl.org>
Message-ID: <55093045.5070602@wisemo.com>

(Resend due to MUA bug sending this to -announce)

On 16/03/2015 20:05, Matt Caswell wrote:
> Forthcoming OpenSSL releases
> ============================
>
> The OpenSSL project team would like to announce the forthcoming release
> of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf.
>
> These releases will be made available on 19th March. They will fix a
> number of security defects. The highest severity defect fixed by these
> releases is classified as "high" severity.
Just for clarity in preparing to use the forthcoming
update:

Has the 1.0.1m source code been mangled by the script that
made it near-impossible to port local changes to 1.0.2, or
will it retain the same code formatting as in the rest of
the 1.0.1 series?

Similarly, will 1.0.0r be mangled or will it retain the
same code formatting as in the rest of the 1.0.0 series?

Similarly, will 0.9.8zf be mangled or will it retain the
same code formatting as in the rest of the 0.9.8 series?

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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  Wed Mar 18 09:14:29 2015
From: matt at openssl.org (Matt Caswell)
Date: Wed, 18 Mar 2015 09:14:29 +0000
Subject: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
In-Reply-To: <55093045.5070602@wisemo.com>
References: <5507297B.8040505@openssl.org> <55093045.5070602@wisemo.com>
Message-ID: <550941F5.5040106@openssl.org>



On 18/03/15 07:59, Jakob Bohm wrote:
> (Resend due to MUA bug sending this to -announce)
> 
> On 16/03/2015 20:05, Matt Caswell wrote:
>> Forthcoming OpenSSL releases
>> ============================
>>
>> The OpenSSL project team would like to announce the forthcoming release
>> of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf.
>>
>> These releases will be made available on 19th March. They will fix a
>> number of security defects. The highest severity defect fixed by these
>> releases is classified as "high" severity.
> Just for clarity in preparing to use the forthcoming
> update:
> 
> Has the 1.0.1m source code been mangled by the script that
> made it near-impossible to port local changes to 1.0.2, or
> will it retain the same code formatting as in the rest of
> the 1.0.1 series?
> 
> Similarly, will 1.0.0r be mangled or will it retain the
> same code formatting as in the rest of the 1.0.0 series?
> 
> Similarly, will 0.9.8zf be mangled or will it retain the
> same code formatting as in the rest of the 0.9.8 series?

I prefer the term "improved" over "mangled"! ;-)

The answer is, yes, all branches (including 1.0.1, 1.0.0 and 0.9.8) have
been reformatted according to the new coding style.

It is perfectly possible, if a little fiddly, to reformat your local
patches to the new style. I have done so myself for a number of my own
patches. I included some outline instructions on how to do it in my
recent blog post on the reformat:

https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/

Regards

Matt


From jb-openssl at wisemo.com  Wed Mar 18 10:45:40 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 18 Mar 2015 11:45:40 +0100
Subject: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
In-Reply-To: <550941F5.5040106@openssl.org>
References: <5507297B.8040505@openssl.org> <55093045.5070602@wisemo.com>
 <550941F5.5040106@openssl.org>
Message-ID: <55095754.9020703@wisemo.com>

On 18/03/2015 10:14, Matt Caswell wrote:
> On 18/03/15 07:59, Jakob Bohm wrote:
>> (Resend due to MUA bug sending this to -announce)
>>
>> On 16/03/2015 20:05, Matt Caswell wrote:
>>> Forthcoming OpenSSL releases
>>> ============================
>>>
>>> The OpenSSL project team would like to announce the forthcoming release
>>> of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf.
>>>
>>> These releases will be made available on 19th March. They will fix a
>>> number of security defects. The highest severity defect fixed by these
>>> releases is classified as "high" severity.
>> Just for clarity in preparing to use the forthcoming
>> update:
>>
>> Has the 1.0.1m source code been mangled by the script that
>> made it near-impossible to port local changes to 1.0.2, or
>> will it retain the same code formatting as in the rest of
>> the 1.0.1 series?
>>
>> Similarly, will 1.0.0r be mangled or will it retain the
>> same code formatting as in the rest of the 1.0.0 series?
>>
>> Similarly, will 0.9.8zf be mangled or will it retain the
>> same code formatting as in the rest of the 0.9.8 series?
> I prefer the term "improved" over "mangled"! ;-)
>
> The answer is, yes, all branches (including 1.0.1, 1.0.0 and 0.9.8) have
> been reformatted according to the new coding style.
>
> It is perfectly possible, if a little fiddly, to reformat your local
> patches to the new style. I have done so myself for a number of my own
> patches. I included some outline instructions on how to do it in my
> recent blog post on the reformat:
>
> https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/
Long read, and lots of internal details of how your script
doesn't even work for yourown code...

However the patch rebasing instructions are *completely
useless* for those of us whomaintain private patches
against releases tarballs.  We *don't* have any of this
in a clone of your gitand we *have no way* to access
intermediary git steps from your partially botched
freeze-reformat-unfreeze-other-work-oopsmorereformat-
other-work sequence.

I guess each of us will have to spend weeks (or more)
manually recreating all our hard work before we can apply
whatever security fixes are hidden in tomorrows tarball.

And it also seems that it is nearly impossible to turn the
changes into a reviewable patch that can be applied to an
existing tree, like the various distributions (on and off
the vendor-sec lists) will need to.

So let's all hope one of the vendors will do your job for
you and transform the new releases into patches against
the previous tarballs, before the embargo is lifted
tomorrow, or soon after.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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/20150318/86c30803/attachment-0001.html>

From matt at openssl.org  Wed Mar 18 11:04:29 2015
From: matt at openssl.org (Matt Caswell)
Date: Wed, 18 Mar 2015 11:04:29 +0000
Subject: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
In-Reply-To: <55095754.9020703@wisemo.com>
References: <5507297B.8040505@openssl.org> <55093045.5070602@wisemo.com>
 <550941F5.5040106@openssl.org> <55095754.9020703@wisemo.com>
Message-ID: <55095BBD.2030600@openssl.org>



On 18/03/15 10:45, Jakob Bohm wrote:
> However the patch rebasing instructions are *completely
> useless* for those of us whomaintain private patches
> against releases tarballs.  We *don't* have any of this
> in a clone of your gitand we *have no way* to access
> intermediary git steps from your partially botched
> freeze-reformat-unfreeze-other-work-oopsmorereformat-
> other-work sequence.

There should be no reason why the instructions cannot be adapted to
patch files, if that is what you are using. You will still need access
to git to do it - but the git repository is publicly accessible.

Matt


From matt at openssl.org  Wed Mar 18 11:07:59 2015
From: matt at openssl.org (Matt Caswell)
Date: Wed, 18 Mar 2015 11:07:59 +0000
Subject: [openssl-users] Forthcoming OpenSSL releases
In-Reply-To: <5507297B.8040505@openssl.org>
References: <5507297B.8040505@openssl.org>
Message-ID: <55095C8F.2020804@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/03/15 19:05, Matt Caswell wrote:
> 
> Forthcoming OpenSSL releases ============================
> 
> The OpenSSL project team would like to announce the forthcoming
> release of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf.
> 
> These releases will be made available on 19th March. They will fix
> a number of security defects. The highest severity defect fixed by
> these releases is classified as "high" severity.

I have received a number of queries regarding the timing of Thursday's
release. To clarify, we are aiming to have the release available
sometime between 1100-1500 GMT.

Regards

Matt

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVCVyPAAoJENnE0m0OYESROvYH/1BdqjzpgiTMhAIYsJjDb0xt
eWM5GdqwiATa+1FqvYXN1pa3Wencl0UVAKsUh0tsC/6MaQVSqyUVkpJZNvvwTrqt
Fmn8sYrF4vFdGNCWoMWWCm0roW9r7V/BGRJrXol0O6b/t5+QrRkVTlEsHTVi3PKD
ujQS5heKS5HPNlZEkhWz+MH3i5RcWx7TVTLVGtsKhIlkc0bM5tSKiynMYQyOhkh2
dLfnNvHGC/g7qIeWg3cGXa4P5Y78SrBvKGj5Bu7IouaT2bC01RfAfYH7pJwpISbZ
3qwwKqGuNF31AC8xBM4CPFU+7MJQtRDtcDzQURHud4Vqn4C/rtmnI0r+tkxDi9I=
=99aY
-----END PGP SIGNATURE-----

From dthompson at prinpay.com  Wed Mar 18 11:34:41 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Wed, 18 Mar 2015 07:34:41 -0400
Subject: [openssl-users] base64 decode in C
In-Reply-To: <CAN9aUrimja56hz1FrP6=U081j5Dh4zkxqd0=dFw3oyaydWiQFw@mail.gmail.com>
References: <CAN9aUrimja56hz1FrP6=U081j5Dh4zkxqd0=dFw3oyaydWiQFw@mail.gmail.com>
Message-ID: <001801d0616f$875cbb90$961632b0$@prinpay.com>

> From: openssl-users On Behalf Of Prashant Bapat
> Sent: Wednesday, March 18, 2015 03:37

> I'm trying to use the base64 decode function in C. <snip>

> This works well for simple b64 encoded strings like "hello world!" etc. 
> But when I want to b64 decode the contents of a SSH public key, it fails. Returns nothing. 

It returns pointer to a buffer containing the pubkey, but no indication of 
the length. You don't show the caller, but if the caller tries to treat it as a 
C string with strlen()fputs() etc that won't work because it isn't a C string.
A C string can't contain any zero-bits aka null byte, and SSH pubkey contains 
many of them; it even starts with *three* consecutive nulls, which 
makes it appear to be empty if treated as a C string.

Use the length returned from (successful) BIO_read (b64bio,...).

> This decodes fine. 
> "dGhpcyBpcyBhd2Vzb21lCg=="  : "this is awesome"

Actually that decodes as "this is awesome" PLUS A NEWLINE, or in 
C source notation "this is awesome\n". Yes that matters. 



From foleyj at cisco.com  Wed Mar 18 12:55:14 2015
From: foleyj at cisco.com (John Foley)
Date: Wed, 18 Mar 2015 08:55:14 -0400
Subject: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
In-Reply-To: <55095754.9020703@wisemo.com>
References: <5507297B.8040505@openssl.org> <55093045.5070602@wisemo.com>
 <550941F5.5040106@openssl.org> <55095754.9020703@wisemo.com>
Message-ID: <550975B2.7050809@cisco.com>

We maintain our own derivative of OpenSSL and haven't had any
significant issues due to the code reformat.  We simply run the reformat
script on our downstream derivative.  We can then generate patch files
of our changes and reapply them to new OpenSSL releases.  It was fairly
straight forward.

IMHO, the code reformat was long overdue.  The prior lack of consistent
coding style was an abomination, making the code more difficult to read
and maintain.  Sometimes taking a step forward results in some pain. 
This was a good investment for the future.

+1 for the reformat.



On 03/18/2015 06:45 AM, Jakob Bohm wrote:
> On 18/03/2015 10:14, Matt Caswell wrote:
>> On 18/03/15 07:59, Jakob Bohm wrote:
>>> (Resend due to MUA bug sending this to -announce)
>>>
>>> On 16/03/2015 20:05, Matt Caswell wrote:
>>>> Forthcoming OpenSSL releases
>>>> ============================
>>>>
>>>> The OpenSSL project team would like to announce the forthcoming release
>>>> of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf.
>>>>
>>>> These releases will be made available on 19th March. They will fix a
>>>> number of security defects. The highest severity defect fixed by these
>>>> releases is classified as "high" severity.
>>> Just for clarity in preparing to use the forthcoming
>>> update:
>>>
>>> Has the 1.0.1m source code been mangled by the script that
>>> made it near-impossible to port local changes to 1.0.2, or
>>> will it retain the same code formatting as in the rest of
>>> the 1.0.1 series?
>>>
>>> Similarly, will 1.0.0r be mangled or will it retain the
>>> same code formatting as in the rest of the 1.0.0 series?
>>>
>>> Similarly, will 0.9.8zf be mangled or will it retain the
>>> same code formatting as in the rest of the 0.9.8 series?
>> I prefer the term "improved" over "mangled"! ;-)
>>
>> The answer is, yes, all branches (including 1.0.1, 1.0.0 and 0.9.8) have
>> been reformatted according to the new coding style.
>>
>> It is perfectly possible, if a little fiddly, to reformat your local
>> patches to the new style. I have done so myself for a number of my own
>> patches. I included some outline instructions on how to do it in my
>> recent blog post on the reformat:
>>
>> https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/
> Long read, and lots of internal details of how your script
> doesn't even work for yourown code...
>
> However the patch rebasing instructions are *completely
> useless* for those of us whomaintain private patches
> against releases tarballs.  We *don't* have any of this
> in a clone of your gitand we *have no way* to access
> intermediary git steps from your partially botched
> freeze-reformat-unfreeze-other-work-oopsmorereformat-
> other-work sequence.
>
> I guess each of us will have to spend weeks (or more)
> manually recreating all our hard work before we can apply
> whatever security fixes are hidden in tomorrows tarball.
>
> And it also seems that it is nearly impossible to turn the
> changes into a reviewable patch that can be applied to an
> existing tree, like the various distributions (on and off
> the vendor-sec lists) will need to.
>
> So let's all hope one of the vendors will do your job for
> you and transform the new releases into patches against
> the previous tarballs, before the embargo is lifted
> tomorrow, or soon after.
>
>
> Enjoy
>
> Jakob
> -- 
> Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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

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

From Walter.H at mathemainzel.info  Wed Mar 18 12:34:55 2015
From: Walter.H at mathemainzel.info (Walter H.)
Date: Wed, 18 Mar 2015 13:34:55 +0100
Subject: [openssl-users] base64 decode in C
In-Reply-To: <CAN9aUrimja56hz1FrP6=U081j5Dh4zkxqd0=dFw3oyaydWiQFw@mail.gmail.com>
References: <CAN9aUrimja56hz1FrP6=U081j5Dh4zkxqd0=dFw3oyaydWiQFw@mail.gmail.com>
Message-ID: <550970EF.6010908@mathemainzel.info>

Hi,

before calling this function,
remove any whitespace;

Walter


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5971 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150318/f65209cf/attachment-0001.bin>

From andreas.magana.ctr at us.af.mil  Wed Mar 18 14:05:01 2015
From: andreas.magana.ctr at us.af.mil (MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT)
Date: Wed, 18 Mar 2015 14:05:01 +0000
Subject: [openssl-users] Solaris 11.2 openssl
Message-ID: <6ABA33135553E04E978A5ECCC07560D2319F381C@52ZHTX-D07-03C.area52.afnoapps.usaf.mil>

I have BMC BladeLogic and recently downloaded a password change script that
uses openssl and I am seeing an error message of the script unable for
openssl to generate hash for password. Can I attach the script for someone
to help me? 

Thank you, 

Respectfully

//SIGNED//

Andy Maga?a
UNIX Systems Administrator
Diligent Contractor, 72nd Air Base Wing
Tinker Air Force Base, Oklahoma 
Commercial: (405) 734-0341


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
openssl-users-request at openssl.org
Sent: Tuesday, March 17, 2015 5:30 PM
To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT
Subject: Welcome to the "openssl-users" mailing list (Digest mode)

Welcome to the openssl-users at openssl.org mailing list!

To post to this list, send your message to:

  openssl-users at openssl.org

General information about the mailing list is at:

  https://mta.openssl.org/mailman/listinfo/openssl-users

If you ever want to unsubscribe or change your options (eg, switch to or
from digest mode, change your password, etc.), visit your subscription page
at:

 
https://mta.openssl.org/mailman/options/openssl-users/andreas.magana.ctr%40u
s.af.mil


You can also make such adjustments via email by sending a message to:

  openssl-users-request at openssl.org

with the word `help' in the subject or body (don't include the quotes), and
you will get back a message with instructions.

You must know your password to change your options (including changing the
password, itself) or to unsubscribe without confirmation.  It is:

  monster35

Normally, Mailman will remind you of your openssl.org mailing list passwords
once every month, although you can disable this if you prefer.  This
reminder will also include instructions on how to unsubscribe or change your
account options.  There is also a button on your options page that will
email your current password to you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3357 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150318/a82c5f12/attachment.bin>

From jb-openssl at wisemo.com  Wed Mar 18 14:38:54 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 18 Mar 2015 15:38:54 +0100
Subject: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
In-Reply-To: <550975B2.7050809@cisco.com>
References: <5507297B.8040505@openssl.org> <55093045.5070602@wisemo.com>
 <550941F5.5040106@openssl.org> <55095754.9020703@wisemo.com>
 <550975B2.7050809@cisco.com>
Message-ID: <55098DFE.3050604@wisemo.com>

Nice, so the extra work is minimal for complete forks of
OpenSSL.

The extra work is also documented (in a place not linked from
the wiki) for those who maintain a git fork of the OpenSSL
repository.

But I have not yet seen a meaningful recipe for those of us
who maintain a traditional set of feature patches against
the released tarballs, nicely organized for future
contribution.

Maybe they want us all to fork OpenSSL :-)

On 18/03/2015 13:55, John Foley wrote:
> We maintain our own derivative of OpenSSL and haven't had any 
> significant issues due to the code reformat.  We simply run the 
> reformat script on our downstream derivative.  We can then generate 
> patch files of our changes and reapply them to new OpenSSL releases.  
> It was fairly straight forward.
>
> IMHO, the code reformat was long overdue.  The prior lack of 
> consistent coding style was an abomination, making the code more 
> difficult to read and maintain.  Sometimes taking a step forward 
> results in some pain.  This was a good investment for the future.
>
> +1 for the reformat.
>
>
>
> On 03/18/2015 06:45 AM, Jakob Bohm wrote:
>> On 18/03/2015 10:14, Matt Caswell wrote:
>>> On 18/03/15 07:59, Jakob Bohm wrote:
>>>> (Resend due to MUA bug sending this to -announce)
>>>>
>>>> On 16/03/2015 20:05, Matt Caswell wrote:
>>>>> Forthcoming OpenSSL releases
>>>>> ============================
>>>>>
>>>>> The OpenSSL project team would like to announce the forthcoming release
>>>>> of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf.
>>>>>
>>>>> These releases will be made available on 19th March. They will fix a
>>>>> number of security defects. The highest severity defect fixed by these
>>>>> releases is classified as "high" severity.
>>>> Just for clarity in preparing to use the forthcoming
>>>> update:
>>>>
>>>> Has the 1.0.1m source code been mangled by the script that
>>>> made it near-impossible to port local changes to 1.0.2, or
>>>> will it retain the same code formatting as in the rest of
>>>> the 1.0.1 series?
>>>>
>>>> Similarly, will 1.0.0r be mangled or will it retain the
>>>> same code formatting as in the rest of the 1.0.0 series?
>>>>
>>>> Similarly, will 0.9.8zf be mangled or will it retain the
>>>> same code formatting as in the rest of the 0.9.8 series?
>>> I prefer the term "improved" over "mangled"! ;-)
>>>
>>> The answer is, yes, all branches (including 1.0.1, 1.0.0 and 0.9.8) have
>>> been reformatted according to the new coding style.
>>>
>>> It is perfectly possible, if a little fiddly, to reformat your local
>>> patches to the new style. I have done so myself for a number of my own
>>> patches. I included some outline instructions on how to do it in my
>>> recent blog post on the reformat:
>>>
>>> https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/
>> Long read, and lots of internal details of how your script
>> doesn't even work for yourown code...
>>
>> However the patch rebasing instructions are *completely
>> useless* for those of us whomaintain private patches
>> against releases tarballs.  We *don't* have any of this
>> in a clone of your gitand we *have no way* to access
>> intermediary git steps from your partially botched
>> freeze-reformat-unfreeze-other-work-oopsmorereformat-
>> other-work sequence.
>>
>> I guess each of us will have to spend weeks (or more)
>> manually recreating all our hard work before we can apply
>> whatever security fixes are hidden in tomorrows tarball.
>>
>> And it also seems that it is nearly impossible to turn the
>> changes into a reviewable patch that can be applied to an
>> existing tree, like the various distributions (on and off
>> the vendor-sec lists) will need to.
>>
>> So let's all hope one of the vendors will do your job for
>> you and transform the new releases into patches against
>> the previous tarballs, before the embargo is lifted
>> tomorrow, or soon after.
>>

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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 prashant at apigee.com  Wed Mar 18 15:08:29 2015
From: prashant at apigee.com (Prashant Bapat)
Date: Wed, 18 Mar 2015 20:38:29 +0530
Subject: [openssl-users] base64 decode in C
In-Reply-To: <550970EF.6010908@mathemainzel.info>
References: <CAN9aUrimja56hz1FrP6=U081j5Dh4zkxqd0=dFw3oyaydWiQFw@mail.gmail.com>
 <550970EF.6010908@mathemainzel.info>
Message-ID: <CAN9aUriQoHZ1S_w3tHvVRNTqe9YTwHTSRXGEFDQmHBDafjTzRQ@mail.gmail.com>

Hi Dave and Walter,

Thanks for our reply.

I'm not doing anything different for the ssh pubkey. I'm able to decode it
using the "openssl enc -base64 -d -A" command. But not using the C program.

Attaching my entire code here. After getting the base64 decoded I'm
calculating the MD5 sum and printing it. This works for a regular string
but not for SSH pubkey.

Thanks again.

--Prashant

On 18 March 2015 at 18:04, Walter H. <Walter.H at mathemainzel.info> wrote:

> Hi,
>
> before calling this function,
> remove any whitespace;
>
> Walter
>
>
>
> _______________________________________________
> 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/20150318/43fb4f62/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: base64.c
Type: text/x-csrc
Size: 1658 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150318/43fb4f62/attachment.c>

From rsalz at akamai.com  Wed Mar 18 15:32:37 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 18 Mar 2015 15:32:37 +0000
Subject: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
In-Reply-To: <55098DFE.3050604@wisemo.com>
References: <5507297B.8040505@openssl.org> <55093045.5070602@wisemo.com>
 <550941F5.5040106@openssl.org> <55095754.9020703@wisemo.com>
 <550975B2.7050809@cisco.com> <55098DFE.3050604@wisemo.com>
Message-ID: <4bc84fca022345c5806790ce725a9754@usma1ex-dag1mb2.msg.corp.akamai.com>

> The extra work is also documented (in a place not linked from the wiki) for
> those who maintain a git fork of the OpenSSL repository.

I just tossed together https://wiki.openssl.org/index.php/Code_reformatting
Found off the main page, https://wiki.openssl.org/index.php/Main_Page#Internals_and_Development 

> But I have not yet seen a meaningful recipe for those of us who maintain a
> traditional set of feature patches against the released tarballs, nicely
> organized for future contribution.

Folks had months of warning that this was going to happen.  And, frankly, patches did not come flooding into the team. 

But I hope the above link helps.

	/r$


From kgoldman at us.ibm.com  Wed Mar 18 16:25:56 2015
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Wed, 18 Mar 2015 12:25:56 -0400
Subject: [openssl-users] base64 decode in C
In-Reply-To: <CAN9aUriQoHZ1S_w3tHvVRNTqe9YTwHTSRXGEFDQmHBDafjTzRQ@mail.gmail.com>
References: <CAN9aUrimja56hz1FrP6=U081j5Dh4zkxqd0=dFw3oyaydWiQFw@mail.gmail.com>
 <550970EF.6010908@mathemainzel.info>
 <CAN9aUriQoHZ1S_w3tHvVRNTqe9YTwHTSRXGEFDQmHBDafjTzRQ@mail.gmail.com>
Message-ID: <mec8ui$bai$1@ger.gmane.org>

As someone already posted, you can't use strlen on an array that is not 
a string.

On 3/18/2015 11:08 AM, Prashant Bapat wrote:
> Hi Dave and Walter,
>
> Thanks for our reply.
>
> I'm not doing anything different for the ssh pubkey. I'm able to decode
> it using the "openssl enc -base64 -d -A" command. But not using the C
> program.
>
> Attaching my entire code here. After getting the base64 decoded I'm
> calculating the MD5 sum and printing it. This works for a regular string
> but not for SSH pubkey.
>
>
>



From jb-openssl at wisemo.com  Wed Mar 18 16:33:41 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 18 Mar 2015 17:33:41 +0100
Subject: [openssl-users] base64 decode in C
In-Reply-To: <CAN9aUriQoHZ1S_w3tHvVRNTqe9YTwHTSRXGEFDQmHBDafjTzRQ@mail.gmail.com>
References: <CAN9aUrimja56hz1FrP6=U081j5Dh4zkxqd0=dFw3oyaydWiQFw@mail.gmail.com>
 <550970EF.6010908@mathemainzel.info>
 <CAN9aUriQoHZ1S_w3tHvVRNTqe9YTwHTSRXGEFDQmHBDafjTzRQ@mail.gmail.com>
Message-ID: <5509A8E5.1060104@wisemo.com>

Please refer to Dave Thompson's answer, it describes your problem.

On 18/03/2015 16:08, Prashant Bapat wrote:
> Hi Dave and Walter,
>
> Thanks for our reply.
>
> I'm not doing anything different for the ssh pubkey. I'm able to 
> decode it using the "openssl enc -base64 -d -A" command. But not using 
> the C program.
>
> Attaching my entire code here. After getting the base64 decoded I'm 
> calculating the MD5 sum and printing it. This works for a regular 
> string but not for SSH pubkey.
>
> Thanks again.
>
> --Prashant
>
Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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 Walter.H at mathemainzel.info  Wed Mar 18 16:40:06 2015
From: Walter.H at mathemainzel.info (Walter H.)
Date: Wed, 18 Mar 2015 17:40:06 +0100
Subject: [openssl-users] base64 decode in C
In-Reply-To: <CAN9aUriQoHZ1S_w3tHvVRNTqe9YTwHTSRXGEFDQmHBDafjTzRQ@mail.gmail.com>
References: <CAN9aUrimja56hz1FrP6=U081j5Dh4zkxqd0=dFw3oyaydWiQFw@mail.gmail.com>
 <550970EF.6010908@mathemainzel.info>
 <CAN9aUriQoHZ1S_w3tHvVRNTqe9YTwHTSRXGEFDQmHBDafjTzRQ@mail.gmail.com>
Message-ID: <5509AA66.4070504@mathemainzel.info>

On 18.03.2015 16:08, Prashant Bapat wrote:
> printf("Base64 decoded string is : %s\n", b64_decode(str, strlen(str))); // This should print binary for a ssh key.
not really, because the return of b64_decode is not a C string; and the 
format specfier %s expects a C string;

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5971 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150318/f066e416/attachment.bin>

From Matthias.St.Pierre at ncp-e.com  Wed Mar 18 16:59:59 2015
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Wed, 18 Mar 2015 17:59:59 +0100
Subject: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
In-Reply-To: <4bc84fca022345c5806790ce725a9754@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <5507297B.8040505@openssl.org> <55093045.5070602@wisemo.com>
 <550941F5.5040106@openssl.org> <55095754.9020703@wisemo.com>
 <550975B2.7050809@cisco.com> <55098DFE.3050604@wisemo.com>
 <4bc84fca022345c5806790ce725a9754@usma1ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <5509AF0F.7060900@ncp-e.com>

Thanks for the three line upgracde recipe in https://wiki.openssl.org/index.php/Code_reformatting
It's as simple as you stated, indeed.

The reformatting was a good thing to do. Also, it makes sense to me to apply it to all
stable branches uniformly, in order to simplify cross-branch merging.

msp




On 03/18/2015 04:32 PM, Salz, Rich wrote:
>> The extra work is also documented (in a place not linked from the wiki) for
>> those who maintain a git fork of the OpenSSL repository.
> 
> I just tossed together https://wiki.openssl.org/index.php/Code_reformatting
> Found off the main page, https://wiki.openssl.org/index.php/Main_Page#Internals_and_Development 
> 
>> But I have not yet seen a meaningful recipe for those of us who maintain a
>> traditional set of feature patches against the released tarballs, nicely
>> organized for future contribution.
> 
> Folks had months of warning that this was going to happen.  And, frankly, patches did not come flooding into the team. 
> 
> But I hope the above link helps.
> 
> 	/r$
> 
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 

From scott_n at xypro.com  Wed Mar 18 17:26:39 2015
From: scott_n at xypro.com (Scott Neugroschl)
Date: Wed, 18 Mar 2015 17:26:39 +0000
Subject: [openssl-users] base64 decode in C
In-Reply-To: <CAN9aUriQoHZ1S_w3tHvVRNTqe9YTwHTSRXGEFDQmHBDafjTzRQ@mail.gmail.com>
References: <CAN9aUrimja56hz1FrP6=U081j5Dh4zkxqd0=dFw3oyaydWiQFw@mail.gmail.com>
 <550970EF.6010908@mathemainzel.info>
 <CAN9aUriQoHZ1S_w3tHvVRNTqe9YTwHTSRXGEFDQmHBDafjTzRQ@mail.gmail.com>
Message-ID: <D358E5B1511A314F8160ADC6F3754987069FD9F8@XYSVEX01.XYPRO-23.LOCAL>

I believe the SSH pubkey is binary data, not ASCII, so strlen() will not work on it if it has embedded NUL chars.
As Dave Thompson suggested, instead of strlen(), use the length returned from BIO_read.


From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Prashant Bapat
Sent: Wednesday, March 18, 2015 8:08 AM
To: openssl-users
Subject: Re: [openssl-users] base64 decode in C

Hi Dave and Walter,

Thanks for our reply.

I'm not doing anything different for the ssh pubkey. I'm able to decode it using the "openssl enc -base64 -d -A" command. But not using the C program.

Attaching my entire code here. After getting the base64 decoded I'm calculating the MD5 sum and printing it. This works for a regular string but not for SSH pubkey.

Thanks again.

--Prashant

On 18 March 2015 at 18:04, Walter H. <Walter.H at mathemainzel.info<mailto:Walter.H at mathemainzel.info>> wrote:
Hi,

before calling this function,
remove any whitespace;

Walter



_______________________________________________
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/20150318/a6cff623/attachment-0001.html>

From marquess at openssl.com  Wed Mar 18 18:44:04 2015
From: marquess at openssl.com (Steve Marquess)
Date: Wed, 18 Mar 2015 14:44:04 -0400
Subject: [openssl-users] FIPS 140-2 hostage rescue underway
Message-ID: <5509C774.5040804@openssl.com>

As always, if you don't know or care what FIPS 140-2 is then count
yourself lucky and move on (in this case, count yourself *very* lucky).

We have -- we think -- a workaround for the "hostage" issue that was
blocking the addition of new platforms to the OpenSSL FIPS module
validation via "change letter" updates. That issue impacted several
platform updates that were already in process (the "hostages").

The workaround is messy, ugly, and complex in the finest tradition of
bureaucratic molehill-to-mountain obfuscation. An attempt to describe it
can be found here:

  http://openssl.com/fips/ransom.html

The TL;DR is that the current #1747 validation becomes three validations
that share the same OpenSSL FIPS module (more or less). So, actual use
and deployment of the FIPS module will be the same as before and all
previously tested platforms remain available (that's the big win).
Compliance paperwork will require some careful attention to the multiple
validations which will overlap the same module (the downside). Confusion
is inevitable, feel free to post questions to this list.

-Steve M.

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

From Matthias.St.Pierre at ncp-e.com  Thu Mar 19 01:22:12 2015
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Thu, 19 Mar 2015 02:22:12 +0100
Subject: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
In-Reply-To: <55098DFE.3050604@wisemo.com>
References: <5507297B.8040505@openssl.org> <55093045.5070602@wisemo.com>
 <550941F5.5040106@openssl.org> <55095754.9020703@wisemo.com>
 <550975B2.7050809@cisco.com> <55098DFE.3050604@wisemo.com>
Message-ID: <1E23EFC52F00C649B69F652AFD284ABD37856A7158@ex07.ncp.local>

Hello,

Here is a recipe to guide you through the reformatting.
It worked nicely for me. I wrote a small bash shell script
which helped me do the bulk conversion, see attachment
Hope you'll find this information helpful.

In following I briefly describe the steps how you can

 1) get your patches into git (if not yet done)
 2) do the reformatting of the commits in git, with the
    help of my script
 3) rebase your patches to the current release
 4) recreate the patches using 'git format-patch'


If your patches are already maintained in a git repository,
you may skip step 1)


1) If you only have patches, it's a good idea to get
your own clone of the git repository

   git clone git://git.openssl.org/openssl.git
   cd openssl

now create a branch off the vanilla release to
which your patches apply (say, OpenSSL 1.0.1k)

   git checkout -b mypatches OpenSSL_1_0_1k

apply your patches one after the other, creating
a single commit for each with meaningful commit
messages

  (If you don't know how to do this in git, you may
   want to see http://git-scm.com/doc)


2) Now we assume that
  a) you already have an OpenSSL git repository
  b) your patches are on a branch called 'mypatches',
     which were branched from one of the stable branches
	 before the reformatting (say OpenSSL_1_0_1-stable)
  c) your working copy is clean (no local changes or
     untracked files)
  d) you're running linux (if not, get yourself a Linux VM)


The attached script shows an example of how to automate
the procedure of reformatting every single commit on your
branch and recommitting it. It contains a lot of comments
to explain what it is doing. PLEASE READ THE COMMENTS
CAREFULLY BEFORE RUNNING THE SCRIPT! 

You just have to set the two variables 'branch' and 'upstream' 
at the beginning of the script (marked 'todo') to the name
of your branch and its upstream branch, respectively.

3) After the script has succeeded, you can rebase your
reformatted branch to the head of the stable branch (or
to the tag of the most recent release), e.g.

git checkout -b mypatches-reformatted mypatches-post-auto-reformat
git rebase OpenSSL_1_0_1-stable


4) Now you can have git recreate your patches automatically
with a single command:

git format-patch $(git merge-base HEAD OpenSSL_1_0_1-stable)..HEAD
 
[5) Now you can keep using the git repository to manage new patches.
	Due the rebasing capabilites of git, your patches will always
	be up to date ]




DISCLAIMER

The script is not 100% fool-proof, it's a demonstration
which may serve as a starting point for you.
In particular, there is no error recovery and no guarantee,
if there are any conflicts or errors in the middle of the
reformating procedure.

So you'll better try it on a copy of your git repository
first.



-----Urspr?ngliche Nachricht-----
Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von
Jakob Bohm
Gesendet: Mittwoch, 18. M?rz 2015 15:39
An: openssl-users at openssl.org
Betreff: Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases

Nice, so the extra work is minimal for complete forks of OpenSSL.

The extra work is also documented (in a place not linked from the wiki) for
those who maintain a git fork of the OpenSSL repository.

But I have not yet seen a meaningful recipe for those of us who maintain a
traditional set of feature patches against the released tarballs, nicely
organized for future contribution.

Maybe they want us all to fork OpenSSL :-)

On 18/03/2015 13:55, John Foley wrote:
> We maintain our own derivative of OpenSSL and haven't had any 
> significant issues due to the code reformat.  We simply run the 
> reformat script on our downstream derivative.  We can then generate 
> patch files of our changes and reapply them to new OpenSSL releases.
> It was fairly straight forward.
>
> IMHO, the code reformat was long overdue.  The prior lack of 
> consistent coding style was an abomination, making the code more 
> difficult to read and maintain.  Sometimes taking a step forward 
> results in some pain.  This was a good investment for the future.
>
> +1 for the reformat.
>
>
>
> On 03/18/2015 06:45 AM, Jakob Bohm wrote:
>> On 18/03/2015 10:14, Matt Caswell wrote:
>>> On 18/03/15 07:59, Jakob Bohm wrote:
>>>> (Resend due to MUA bug sending this to -announce)
>>>>
>>>> On 16/03/2015 20:05, Matt Caswell wrote:
>>>>> Forthcoming OpenSSL releases
>>>>> ============================
>>>>>
>>>>> The OpenSSL project team would like to announce the forthcoming 
>>>>> release of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf.
>>>>>
>>>>> These releases will be made available on 19th March. They will fix 
>>>>> a number of security defects. The highest severity defect fixed by 
>>>>> these releases is classified as "high" severity.
>>>> Just for clarity in preparing to use the forthcoming
>>>> update:
>>>>
>>>> Has the 1.0.1m source code been mangled by the script that made it 
>>>> near-impossible to port local changes to 1.0.2, or will it retain 
>>>> the same code formatting as in the rest of the 1.0.1 series?
>>>>
>>>> Similarly, will 1.0.0r be mangled or will it retain the same code 
>>>> formatting as in the rest of the 1.0.0 series?
>>>>
>>>> Similarly, will 0.9.8zf be mangled or will it retain the same code 
>>>> formatting as in the rest of the 0.9.8 series?
>>> I prefer the term "improved" over "mangled"! ;-)
>>>
>>> The answer is, yes, all branches (including 1.0.1, 1.0.0 and 0.9.8) 
>>> have been reformatted according to the new coding style.
>>>
>>> It is perfectly possible, if a little fiddly, to reformat your local 
>>> patches to the new style. I have done so myself for a number of my 
>>> own patches. I included some outline instructions on how to do it in 
>>> my recent blog post on the reformat:
>>>
>>> https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/
>> Long read, and lots of internal details of how your script doesn't 
>> even work for yourown code...
>>
>> However the patch rebasing instructions are *completely
>> useless* for those of us whomaintain private patches against releases 
>> tarballs.  We *don't* have any of this in a clone of your gitand we 
>> *have no way* to access intermediary git steps from your partially 
>> botched
>> freeze-reformat-unfreeze-other-work-oopsmorereformat-
>> other-work sequence.
>>
>> I guess each of us will have to spend weeks (or more) manually 
>> recreating all our hard work before we can apply whatever security 
>> fixes are hidden in tomorrows tarball.
>>
>> And it also seems that it is nearly impossible to turn the changes 
>> into a reviewable patch that can be applied to an existing tree, like 
>> the various distributions (on and off the vendor-sec lists) will need 
>> to.
>>
>> So let's all hope one of the vendors will do your job for you and 
>> transform the new releases into patches against the previous 
>> tarballs, before the embargo is lifted tomorrow, or soon after.
>>

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reformat.sh
Type: application/octet-stream
Size: 2200 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150319/a3ab5c37/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4328 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150319/a3ab5c37/attachment.bin>

From noloader at gmail.com  Thu Mar 19 06:27:02 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 19 Mar 2015 02:27:02 -0400
Subject: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
In-Reply-To: <550941F5.5040106@openssl.org>
References: <5507297B.8040505@openssl.org> <55093045.5070602@wisemo.com>
 <550941F5.5040106@openssl.org>
Message-ID: <CAH8yC8=dAJ2hsk6-B1=Zrz0Q4zkfn+G08WTMO5oXE+yFEpOt8A@mail.gmail.com>

On Wed, Mar 18, 2015 at 5:14 AM, Matt Caswell <matt at openssl.org> wrote:
>
>
> On 18/03/15 07:59, Jakob Bohm wrote:
>> (Resend due to MUA bug sending this to -announce)
>>
>> On 16/03/2015 20:05, Matt Caswell wrote:
>>> Forthcoming OpenSSL releases
>>> ============================
>>>
>>> The OpenSSL project team would like to announce the forthcoming release
>>> of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf.
>>>
>>> These releases will be made available on 19th March. They will fix a
>>> number of security defects. The highest severity defect fixed by these
>>> releases is classified as "high" severity.
>> Just for clarity in preparing to use the forthcoming
>> update:
>>
>> Has the 1.0.1m source code been mangled by the script that
>> made it near-impossible to port local changes to 1.0.2, or
>> will it retain the same code formatting as in the rest of
>> the 1.0.1 series?
>>
>> Similarly, will 1.0.0r be mangled or will it retain the
>> same code formatting as in the rest of the 1.0.0 series?
>>
>> Similarly, will 0.9.8zf be mangled or will it retain the
>> same code formatting as in the rest of the 0.9.8 series?
>
> I prefer the term "improved" over "mangled"! ;-)
>
> The answer is, yes, all branches (including 1.0.1, 1.0.0 and 0.9.8) have
> been reformatted according to the new coding style.

+1 on the reformatting. My eyes no longer bleed when looking at some
of the sources.

Its an unfortunate side effect that its going to negatively affect
some folks in the short term, but its a good long term decision for
the health of the project.

Jeff

From Matthias.St.Pierre at ncp-e.com  Thu Mar 19 08:40:00 2015
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Thu, 19 Mar 2015 09:40:00 +0100
Subject: [openssl-users] Minimizing the pain of reformatting your OpenSSL
	patches
Message-ID: <550A8B60.9070802@ncp-e.com>


Hello,

the upcoming security update imposes a special challenge to
all OpenSSL users who maintain their own patch sets.

The reason is the code reformat which has taken place in between
the last and the upcoming release, which renders existing patches
useless.
<https://www.openssl.org/blog/blog/2015/01/05/source-code-reformat>

Matt Caswell has posted a detailed article explaining how you can
reformat your patches, see
<https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished>

This article inspired me to the following solution and I extended his
ideas a little. Here is the recipe which worked for me. It is a little
bit simpler than the solution of the blog, because it does not involve
cherry-picking. Also, I wrote a script helping me to do the bulk
conversion of many patches:

  Assuming, you have a branch "${branch}" containing all your
  patches, The script creates a copy of your branch, named
  "${branch}-pre-auto-reformat" which it then rebases to
  "${upstream}-pre-auto-reformat".
  
  For every commit on the rebased branch, it does an automatic
  conversion, placing the results onto a new branch
  "${upstream}-pre-auto-reformat"

Finally, you can rebase a copy "${upstream}-reformatted" of the
reformatted branch "${upstream}-post-auto-reformat" to the
upcoming release (say, 1.0.1m).

More details at the end of the mail.


Regards,
msp


DISCLAIMER
The script is merely a demonstration which may serve as a starting
point for you and may not be 100% fool-proof. I hope it will turn out
to be useful for some of you. However, I don't take any
responsibilities if anything goes wrong. Use it at your own risk!




--

In following I describe the steps in more detail how you can

 1) get your patches into git (if you havn't done it yet)
 2) do the reformatting in git, with the help of the script
 3) rebase your patches to the current release
 4) recreate the patches using 'git format-patch'


If your patches are already maintained in a git repository,
you may skip step 1)


1) If you only have patches, no git repository, it's a good idea
to get your own clone of the git repository, in which you have an
own branch to maintain your patches.

   git clone git://git.openssl.org/openssl.git
   cd openssl

This will not only ease the transition, but also pay back in the future,
since the powerful capabilities features of git will make it easy in the
future to rebase your patches using just two commands, 'git rebase' and
'git format-patch'.


Just create a branch off the vanilla release from which your
patches depart (say, OpenSSL 1.0.1k)

   git checkout -b mypatches OpenSSL_1_0_1k

Apply your patches one-after-the-other, creating a single commit
for each patch with meaningful commit messages. Note that the header
line of your commit message will be used by 'git format-patch' to create
a filename for the patch. 

(If you don't know how to do this in git, you may want to consult
http://git-scm.com/doc)


2) Now we assume that

  a) you already have an OpenSSL git repository
  b) your patches are on a branch called 'mypatches',
     which were branched from one of the stable branches
     before the reformatting (say OpenSSL_1_0_1-stable)
  c) your working copy is clean (no local changes or
     untracked files)
  d) you're running linux (if not, get yourself a Linux VM)


The attached script shows an example of how to automate
the procedure of reformatting every single commit on your
branch and recommitting it. It contains a lot of comments
to explain what it is doing. PLEASE READ THE COMMENTS
CAREFULLY BEFORE RUNNING THE SCRIPT! 

You just have to set the two variables 'branch' and 'upstream' 
at the beginning of the script (marked 'todo') to the name
of your branch and its upstream branch, respectively.

The script may fail on the first run when attempting to rebase
"${branch}-pre-auto-reformat". This case is anticipated, just
fix your conflicts, and run the script again
(see <http://git-scm.com/book/en/v2/Git-Branching-Rebasing>)

If any other error occurs, you are on your own ;-)

However, the script does not move existing branch labels, it operates
on new branches. So you may restart as often as you like, as long
as you remove the intermediate branches created by the script
(using 'git branch -D')

If you're still anxious to do this on your production repository, try
it on a copy of repository first.

3) After the script has succeeded, you can rebase your
reformatted branch to the head of the stable branch or
to the tag of the most recent release, e.g. to OpenSSL_1_0_1k:

git checkout -b mypatches-reformatted mypatches-post-auto-reformat
git rebase OpenSSL_1_0_1k


4) Now you can have git recreate your patches automatically
with a single command:

   git format-patch OpenSSL_1_0_1k..HEAD

or, more generally:

   git format-patch $(git merge-base HEAD OpenSSL_1_0_1-stable)..HEAD
 




-------------- next part --------------
A non-text attachment was scrubbed...
Name: reformat.sh
Type: application/x-shellscript
Size: 2432 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150319/7552a309/attachment-0001.bin>

From Matthias.St.Pierre at ncp-e.com  Thu Mar 19 08:41:57 2015
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Thu, 19 Mar 2015 09:41:57 +0100
Subject: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases
In-Reply-To: <1E23EFC52F00C649B69F652AFD284ABD37856A7158@ex07.ncp.local>
References: <5507297B.8040505@openssl.org> <55093045.5070602@wisemo.com>
 <550941F5.5040106@openssl.org> <55095754.9020703@wisemo.com>
 <550975B2.7050809@cisco.com> <55098DFE.3050604@wisemo.com>
 <1E23EFC52F00C649B69F652AFD284ABD37856A7158@ex07.ncp.local>
Message-ID: <550A8BD5.1070803@ncp-e.com>

I just posted an updated version of my script in a new
thread, titled 

 Minimizing the pain of reformatting your OpenSSL patches

Regards,
msp



On 03/19/2015 02:22 AM, Dr. Matthias St. Pierre wrote:
> Hello,
> 
> Here is a recipe to guide you through the reformatting.
> It worked nicely for me. I wrote a small bash shell script
> which helped me do the bulk conversion, see attachment
> Hope you'll find this information helpful.

From prashant at apigee.com  Thu Mar 19 08:54:38 2015
From: prashant at apigee.com (Prashant Bapat)
Date: Thu, 19 Mar 2015 14:24:38 +0530
Subject: [openssl-users] base64 decode in C
In-Reply-To: <D358E5B1511A314F8160ADC6F3754987069FD9F8@XYSVEX01.XYPRO-23.LOCAL>
References: <CAN9aUrimja56hz1FrP6=U081j5Dh4zkxqd0=dFw3oyaydWiQFw@mail.gmail.com>
 <550970EF.6010908@mathemainzel.info>
 <CAN9aUriQoHZ1S_w3tHvVRNTqe9YTwHTSRXGEFDQmHBDafjTzRQ@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F3754987069FD9F8@XYSVEX01.XYPRO-23.LOCAL>
Message-ID: <CAN9aUrhMcBL587cxq3qMGt_YhcOc9C3EjrL0CX7TpDfb6iPAFQ@mail.gmail.com>

Hi,

My problem is if the string that I want to decode start with null
terminated char (as in a SSH pubkey), the base64_decode does not return
anything at all. The encoded string itself does not have null terminated
chars but rather the decoded result. The "buffer" being returned is empty.
How to overcome this ?

Also my C is relatively rusty, it would be great help if someone could look
look at my code and suggest what I'm doing wrong.

Also, I tried to use the EVP_DecodeBlock function with same result. It
decodes everything except the SSH pubkey.

Thanks.
--Prashant

On 18 March 2015 at 22:56, Scott Neugroschl <scott_n at xypro.com> wrote:

>  I believe the SSH pubkey is binary data, not ASCII, so strlen() will not
> work on it if it has embedded NUL chars.
>
> As Dave Thompson suggested, instead of strlen(), use the length returned
> from BIO_read.
>
>
>
>
>
> *From:* openssl-users [mailto:openssl-users-bounces at openssl.org] *On
> Behalf Of *Prashant Bapat
> *Sent:* Wednesday, March 18, 2015 8:08 AM
> *To:* openssl-users
> *Subject:* Re: [openssl-users] base64 decode in C
>
>
>
> Hi Dave and Walter,
>
>
>
> Thanks for our reply.
>
>
>
> I'm not doing anything different for the ssh pubkey. I'm able to decode it
> using the "openssl enc -base64 -d -A" command. But not using the C program.
>
>
>
> Attaching my entire code here. After getting the base64 decoded I'm
> calculating the MD5 sum and printing it. This works for a regular string
> but not for SSH pubkey.
>
>
>
> Thanks again.
>
>
>
> --Prashant
>
>
>
> On 18 March 2015 at 18:04, Walter H. <Walter.H at mathemainzel.info> wrote:
>
> Hi,
>
> before calling this function,
> remove any whitespace;
>
> Walter
>
>
>
> _______________________________________________
> 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/20150319/e505addb/attachment.html>

From Matthias.St.Pierre at ncp-e.com  Thu Mar 19 09:22:10 2015
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Thu, 19 Mar 2015 10:22:10 +0100
Subject: [openssl-users] Minimizing the pain of reformatting your
 OpenSSL patches
In-Reply-To: <550A8B60.9070802@ncp-e.com>
References: <550A8B60.9070802@ncp-e.com>
Message-ID: <550A9542.8090202@ncp-e.com>

Copy & Paste error:

The name of the new branch is
   "${upstream}-post-auto-reformat"
not
   "${upstream}-pre-auto-reformat"

msp

On 03/19/2015 09:40 AM, Dr. Matthias St. Pierre wrote:
>   For every commit on the rebased branch, it does an automatic
>   conversion, placing the results onto a new branch
>   "${upstream}-pre-auto-reformat"

From Matthias.St.Pierre at ncp-e.com  Thu Mar 19 09:27:49 2015
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Thu, 19 Mar 2015 10:27:49 +0100
Subject: [openssl-users] Minimizing the pain of reformatting your
 OpenSSL patches
In-Reply-To: <550A8B60.9070802@ncp-e.com>
References: <550A8B60.9070802@ncp-e.com>
Message-ID: <550A9695.9090704@ncp-e.com>

Sorry for that, another typo:

Please replace OpenSSL_1_0_1k by OpenSSL_1_0_1m below.

On 03/19/2015 09:40 AM, Dr. Matthias St. Pierre wrote:
> 3) After the script has succeeded, you can rebase your
> reformatted branch to the head of the stable branch or
> to the tag of the most recent release, e.g. to OpenSSL_1_0_1k:
> 
> git checkout -b mypatches-reformatted mypatches-post-auto-reformat
> git rebase OpenSSL_1_0_1k

From stevenx.linsell at intel.com  Thu Mar 19 11:18:08 2015
From: stevenx.linsell at intel.com (Linsell, StevenX)
Date: Thu, 19 Mar 2015 11:18:08 +0000
Subject: [openssl-users] Failure using ECDH-RSA-AES256-SHA with ssl3 on
	Master Branch
Message-ID: <BC6016DA3A27864486295F6D844656F132ACD2BF@irsmsx105.ger.corp.intel.com>

I am trying to use ECDH-RSA-AES256-SHA with ssl3 with s_client and s_server on the master branch. (cloned at commit f7683aaf36341dc65672ac2ccdbfd4a232e3626d) and then retested ?with a more recent clone: (commit da27006df06853a33b132133699a7aa9d4277920).
We are running a test suite that tests all supported cipher and protocol combinations and this test is part of that suite.
Our test suite is failing with an unmodified build of OpenSSL with the following commands:-

s_server:
./openssl s_server -cert prime256v1-rsaTestServer.cert.pem -key prime256v1-rsaTestServer.key.pem -WWW -accept 4411 -cipher ECDH-RSA-AES256-SHA -nbio -ssl3 -debug -state

s_client:
echo "GET /file_1byte.html HTTP/1.0" | ./openssl s_client ?-host localhost -port 4411 -cipher ECDH-RSA-AES256-SHA -ssl3 -ign_eof -debug -state

The output from s_client is:-

SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL3 alert read:fatal:handshake failure
SSL_connect:failed in SSLv3 read server hello A
139749978326688:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1482:SSL alert number 40
139749978326688:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:664:
CONNECTED(00000003)
write to 0x1284120 [0x128e913] (52 bytes => 52 (0x34))
0000 - 16 03 00 00 2f 01 00 00-2b 03 00 af 73 f8 85 b4?? ..../...+...s...
0010 - 01 5f d4 79 66 4e 94 fa-bf e7 5e 5b 19 75 c8 5f?? ._.yfN....^[.u._
0020 - 44 73 bb bd 47 8c 23 57-01 c0 1a 00 00 04 c0 0f?? Ds..G.#W........
0030 - 00 ff 01????????????????????????????????????????? ...
0034 - <SPACES/NULS>
read from 0x1284120 [0x128a3c3] (5 bytes => 5 (0x5))
0000 - 15 03 00 00 02??????????????????????????????????? .....
read from 0x1284120 [0x128a3c8] (2 bytes => 2 (0x2))
0000 - 02 28???????????????????????????????????????????? .(
---
no peer certificate available

The output from s_server is:-

Using default temp DH parameters
ACCEPT
turning on non blocking io
SSL_accept:before/accept initialization
read from 0x21b32b0 [0x21b7993] (5 bytes => 5 (0x5))
0000 - 16 03 00 00 2f??????????????????????????????????? ..../
read from 0x21b32b0 [0x21b7998] (47 bytes => 47 (0x2F))
0000 - 01 00 00 2b 03 00 aa 75-39 f4 b5 78 46 3e 8c cb?? ...+...u9..xF>..
0010 - a9 18 92 01 cd 24 cf fd-7b a7 de 29 7c b8 d9 bc?? .....$..{..)|...
0020 - c4 62 1c c5 33 7f 00 00-04 c0 0f 00 ff 01???????? .b..3.........
002f - <SPACES/NULS>
0:[00000020:00000010:00000188:00000084]0x6055a0:ECDH-RSA-AES256-SHA
write to 0x21b32b0 [0x21c6910] (7 bytes => 7 (0x7))
0000 - 15 03 00 00 02 02 28????????????????????????????? ......(
SSL3 alert write:fatal:handshake failure
SSL_accept:error in SSLv3 read client hello C
139792107542176:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1366:
ACCEPT

I am using an ECC test certificate that uses curve prime256v1 and is signed with an rsa2k key.
The cert/key were generated using RSAcertgen.sh followed by ECC-RSAcertgen.sh modified only for the curve and RSA key size I am using.
Here is a dump of the certificate:
./openssl x509 -in prime256v1-rsaTestServer.cert.pem -text -noout
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 16838786626002069798 (0xe9af63387b73a926)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=CA, L=Mountain View, O=Sun Microsystems, Inc., OU=Sun Microsystems Laboratories, CN=Test CA (2048 bit RSA)
        Validity
            Not Before: Mar 13 11:38:21 2015 GMT
            Not After : Apr 21 11:38:21 2019 GMT
        Subject: C=US, ST=CA, L=Mountain View, O=Sun Microsystems, Inc., OU=Sun Microsystems Laboratories, CN=Test Server (prime256v1 key signed with RSA)
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub: 
                    04:0d:a6:16:d8:43:25:dc:83:6d:18:fb:f0:b7:41:
                    bc:05:88:a2:f2:56:8a:76:7a:d0:2b:7f:de:0a:44:
                    33:4b:de:5b:30:44:ff:34:0e:17:c6:38:77:d7:53:
                    b2:c2:fa:9f:7f:d5:e3:a4:b5:de:ce:29:9d:74:e6:
                    59:76:9f:e6:eb
                ASN1 OID: prime256v1
                NIST CURVE: P-256
    Signature Algorithm: sha256WithRSAEncryption
         d0:1c:97:60:b9:14:cf:5a:c8:ea:8d:65:63:75:50:f2:63:68:
         82:06:0c:47:f5:52:13:a5:61:4b:cd:99:ab:d0:56:81:a7:92:
         21:c7:07:e3:12:25:4a:a8:c7:83:7a:bd:57:11:c7:55:88:28:
         74:f1:37:bb:cd:0b:5b:7b:6f:45:e6:8d:1a:be:1a:fd:e0:d2:
         5b:e5:ee:39:2e:73:c8:d6:03:5c:f6:f9:37:4a:81:e4:41:5a:
         87:d5:0d:da:48:67:14:bb:75:3b:ae:68:b9:c4:25:2d:19:a7:
         05:90:a2:fb:b4:d3:00:4f:40:19:e9:2d:83:75:db:3c:53:fe:
         08:ae:ca:ba:3d:a5:4d:6e:f6:14:af:ee:7e:6d:dc:45:96:91:
         92:6d:37:52:b6:b7:ad:70:02:d0:11:0d:84:1b:f1:3b:82:be:
         66:af:a6:3c:17:33:d0:98:c3:cb:d3:22:39:d1:66:6e:94:ce:
         7e:70:3c:02:29:6a:b6:87:e9:c4:e9:44:b4:9b:f1:8e:47:82:
         2d:20:79:0e:f6:91:b1:e9:cf:83:66:8f:ff:e1:4f:2f:a1:ab:
         ca:2d:81:53:7d:7f:69:b5:11:59:7e:9a:47:1c:6a:c8:83:54:
         83:0a:7d:46:ec:2e:e9:82:f3:b4:d4:f6:04:57:bc:a5:b2:c5:
         0c:ed:a6:fa

Running the exact same s_server/s_client commands above with either the system openssl (1.0.0o) or the baseline we normally release against (1.0.1l) works fine.
Running on the master branch with the same certificate and commands above but with tls1, tls1_1 or tls1_2 works perfectly, only ssl3 fails.
Running with a sect163r1 curve signed with an rsa1k key also produces the same failure.
My build is as follows:
./openssl version -a
OpenSSL 1.1.0-dev xx XXX xxxx
built on: reproducible build, date unspecified
platform: linux-x86_64
options:? bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) 
compiler: gcc -g -I. -I.. -I../include? -DOPENSSL_TLS_SECURITY_LEVEL=0 -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -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
OPENSSLDIR: "/usr/local/ssl"

As you can see the only flag I have enabled (apart from -g while debugging) is -DOPENSSL_TLS_SECURITY_LEVEL=0. We need this flag to allow some of the older cipher suites we test against but the issue is seen with or without that flag defined.

I'm not overly familiar with the master branch as we do not normally build against it so my real question is whether I am doing something wrong in terms of configuration on the master branch (is there a flag I need to enable to allow ECDH-RSA with ssl3 that I haven't spotted?) or is this a genuine bug?

Single stepping through the code I can see the failure is occurring in tls1_check_ec_key when it is called from tls1_check_cert_param.
It appears to go around a for loop (j) twice. The first time through it correctly matches the curve it is looking for. The second time round the list is empty and 0 is returned. This failure causes the Elliptical curve cert not to be declared as valid and consequently the handshake fails with the no shared cipher message.
I don't have a good understanding of how the certificate code works so I haven't managed to debug any further than that in order to determine why the second time round the loop the list is empty.

-- 
Steve Linsell                                     Intel Shannon DCG/CID Software Development Team
Stevenx.Linsell at intel.com                              


--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.



From prashant at apigee.com  Thu Mar 19 11:54:21 2015
From: prashant at apigee.com (Prashant Bapat)
Date: Thu, 19 Mar 2015 17:24:21 +0530
Subject: [openssl-users] base64 decode in C
In-Reply-To: <CAN9aUrhMcBL587cxq3qMGt_YhcOc9C3EjrL0CX7TpDfb6iPAFQ@mail.gmail.com>
References: <CAN9aUrimja56hz1FrP6=U081j5Dh4zkxqd0=dFw3oyaydWiQFw@mail.gmail.com>
 <550970EF.6010908@mathemainzel.info>
 <CAN9aUriQoHZ1S_w3tHvVRNTqe9YTwHTSRXGEFDQmHBDafjTzRQ@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F3754987069FD9F8@XYSVEX01.XYPRO-23.LOCAL>
 <CAN9aUrhMcBL587cxq3qMGt_YhcOc9C3EjrL0CX7TpDfb6iPAFQ@mail.gmail.com>
Message-ID: <CAN9aUrghXRu3BStUbEc6FXxJa=_ig_jC2MUZUSC2mR05EQE7=w@mail.gmail.com>

Hey I got this. Sorry I was confused with the length. BIO_read returns the
length which I was able to use to get the MD5. Problem solved!!!

Many thanks.
--Pashant

On 19 March 2015 at 14:24, Prashant Bapat <prashant at apigee.com> wrote:

> Hi,
>
> My problem is if the string that I want to decode start with null
> terminated char (as in a SSH pubkey), the base64_decode does not return
> anything at all. The encoded string itself does not have null terminated
> chars but rather the decoded result. The "buffer" being returned is empty.
> How to overcome this ?
>
> Also my C is relatively rusty, it would be great help if someone could
> look look at my code and suggest what I'm doing wrong.
>
> Also, I tried to use the EVP_DecodeBlock function with same result. It
> decodes everything except the SSH pubkey.
>
> Thanks.
> --Prashant
>
> On 18 March 2015 at 22:56, Scott Neugroschl <scott_n at xypro.com> wrote:
>
>>  I believe the SSH pubkey is binary data, not ASCII, so strlen() will
>> not work on it if it has embedded NUL chars.
>>
>> As Dave Thompson suggested, instead of strlen(), use the length returned
>> from BIO_read.
>>
>>
>>
>>
>>
>> *From:* openssl-users [mailto:openssl-users-bounces at openssl.org] *On
>> Behalf Of *Prashant Bapat
>> *Sent:* Wednesday, March 18, 2015 8:08 AM
>> *To:* openssl-users
>> *Subject:* Re: [openssl-users] base64 decode in C
>>
>>
>>
>> Hi Dave and Walter,
>>
>>
>>
>> Thanks for our reply.
>>
>>
>>
>> I'm not doing anything different for the ssh pubkey. I'm able to decode
>> it using the "openssl enc -base64 -d -A" command. But not using the C
>> program.
>>
>>
>>
>> Attaching my entire code here. After getting the base64 decoded I'm
>> calculating the MD5 sum and printing it. This works for a regular string
>> but not for SSH pubkey.
>>
>>
>>
>> Thanks again.
>>
>>
>>
>> --Prashant
>>
>>
>>
>> On 18 March 2015 at 18:04, Walter H. <Walter.H at mathemainzel.info> wrote:
>>
>> Hi,
>>
>> before calling this function,
>> remove any whitespace;
>>
>> Walter
>>
>>
>>
>> _______________________________________________
>> 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/20150319/dfc30218/attachment.html>

From Matthias.St.Pierre at ncp-e.com  Thu Mar 19 12:19:48 2015
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Thu, 19 Mar 2015 13:19:48 +0100
Subject: [openssl-users] FIXED: Minimizing the pain of reformatting your
 OpenSSL patches
In-Reply-To: <550A8B60.9070802@ncp-e.com>
References: <550A8B60.9070802@ncp-e.com>
Message-ID: <550ABEE4.9080305@ncp-e.com>


Hello,

my original post contained two typos. Also, the script reversed the order
of the commits due to a forgotten '--reverse'. (Probably, it was too late,
last night ;)

So here comes a repost with all corrections. Sorry for the inconveniences.

Regards,

msp



--

Hello,


the upcoming security update imposes a special challenge to
all OpenSSL users who maintain their own patch sets.

The reason is the code reformat which has taken place in between
the last and the upcoming release, which renders existing patches
useless.
<https://www.openssl.org/blog/blog/2015/01/05/source-code-reformat>

Matt Caswell has posted a detailed article explaining how you can
reformat your patches, see
<https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished>

This article inspired me to the following solution and I extended his
ideas a little. Here is the recipe which worked for me. It is a little
bit simpler than the solution of the blog, because it does not involve
cherry-picking. Also, I wrote a script helping me to do the bulk
conversion of many patches:

  Assuming, you have a branch "${branch}" containing all your
  patches, The script creates a copy of your branch, named
  "${branch}-pre-auto-reformat" which it then rebases to
  "${upstream}-pre-auto-reformat".
  
  For every commit on the rebased branch, it does an automatic
  conversion, placing the results onto a new branch
  "${upstream}-post-auto-reformat"

Finally, you can rebase a copy "${upstream}-reformatted" of the
reformatted branch "${upstream}-post-auto-reformat" to the
upcoming release (say, 1.0.1m).

More details at the end of the mail.


Regards,
msp


DISCLAIMER
The script is merely a demonstration which may serve as a starting
point for you and may not be 100% fool-proof. I hope it will turn out
to be useful for some of you. However, I don't take any
responsibilities if anything goes wrong. Use it at your own risk!




--

In following I describe the steps in more detail how you can

 1) get your patches into git (if you havn't done it yet)
 2) do the reformatting in git, with the help of the script
 3) rebase your patches to the current release
 4) recreate the patches using 'git format-patch'


If your patches are already maintained in a git repository,
you may skip step 1)


1) If you only have patches, no git repository, it's a good idea
to get your own clone of the git repository, in which you have an
own branch to maintain your patches.

   git clone git://git.openssl.org/openssl.git
   cd openssl

This will not only ease the transition, but also pay back in the future,
since the powerful capabilities features of git will make it easy in the
future to rebase your patches using just two commands, 'git rebase' and
'git format-patch'.


Just create a branch off the vanilla release from which your
patches depart (say, OpenSSL 1.0.1k)

   git checkout -b mypatches OpenSSL_1_0_1k

Apply your patches one-after-the-other, creating a single commit
for each patch with meaningful commit messages. Note that the header
line of your commit message will be used by 'git format-patch' to create
a filename for the patch. 

(If you don't know how to do this in git, you may want to consult
http://git-scm.com/doc)


2) Now we assume that

  a) you already have an OpenSSL git repository
  b) your patches are on a branch called 'mypatches',
     which were branched from one of the stable branches
     before the reformatting (say OpenSSL_1_0_1-stable)
  c) your working copy is clean (no local changes or
     untracked files)
  d) you're running linux (if not, get yourself a Linux VM)


The attached script shows an example of how to automate
the procedure of reformatting every single commit on your
branch and recommitting it. It contains a lot of comments
to explain what it is doing. PLEASE READ THE COMMENTS
CAREFULLY BEFORE RUNNING THE SCRIPT! 

You just have to set the two variables 'branch' and 'upstream' 
at the beginning of the script (marked 'todo') to the name
of your branch and its upstream branch, respectively.

The script may fail on the first run when attempting to rebase
"${branch}-pre-auto-reformat". This case is anticipated, just
fix your conflicts, and run the script again
(see <http://git-scm.com/book/en/v2/Git-Branching-Rebasing>)

If any other error occurs, you are on your own 

However, the script does not move existing branch labels, it operates
on new branches. So you may restart as often as you like, as long
as you remove the intermediate branches created by the script
(using 'git branch -D')

If you're still anxious to do this on your production repository, try
it on a copy of repository first.

3) After the script has succeeded, you can rebase your
reformatted branch to the head of the stable branch or
to the tag of the most recent release, e.g. to OpenSSL_1_0_1m:

git checkout -b mypatches-reformatted mypatches-post-auto-reformat
git rebase OpenSSL_1_0_1m


4) Now you can have git recreate your patches automatically
with a single command:

   git format-patch OpenSSL_1_0_1m..HEAD

or, more generally:

   git format-patch $(git merge-base HEAD OpenSSL_1_0_1-stable)..HEAD
 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: reformat.sh
Type: application/x-shellscript
Size: 2424 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150319/95b46852/attachment.bin>

From openssl-users at openssl.org  Thu Mar 19 02:00:30 2015
From: openssl-users at openssl.org (xe)
Date: Thu, 19 Mar 2015 10:00:30 +0800
Subject: [openssl-users] The most beautiful handbag LouisVuitton
Message-ID: <20150319100044264548@smtp2.baogaoning.com>


L o uis V ui t t on online World All B rands
Lo uisV uitton Onlineha ndbag
We have been here, Our pursuit of the perfect quality handbags, we never change, producing the highest quality handbags Louis Vuitton All productsBest -! New & Up To 70 - 90 % O F F, F ree ship ping on all orders!



Online h an db ags a LL b a gs iam have,
You just need to tell me
bgas worldwide shipping free! buy now! 

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

From openssl-users at openssl.org  Thu Mar 19 04:35:23 2015
From: openssl-users at openssl.org (xe)
Date: Thu, 19 Mar 2015 12:35:23 +0800
Subject: [openssl-users] Australia exhibition handbags,
	waiting for your purchase LouisVuitton
Message-ID: <20150319123534723677@smtp2.baogaoning.com>


L o uis V ui t t on online World All B rands
Lo uisV uitton Onlineha ndbag
We have been here, Our pursuit of the perfect quality handbags, we never change, producing the highest quality handbags Louis Vuitton All productsBest -! New & Up To 70 - 90 % O F F, F ree ship ping on all orders!



Online h an db ags a LL b a gs iam have,
You just need to tell me
We are seeking high quality Louis Vuitton? 

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

From openssl at openssl.org  Thu Mar 19 14:09:15 2015
From: openssl at openssl.org (OpenSSL)
Date: Thu, 19 Mar 2015 14:09:15 +0000
Subject: [openssl-users] OpenSSL version 1.0.2a released
Message-ID: <20150319140915.GA544@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 1.0.2a released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.2a of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        http://www.openssl.org/news/openssl-1.0.2-notes.html

   OpenSSL 1.0.2a 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.0.2a.tar.gz
      Size: 5262089
      MD5 checksum: a06c547dac9044161a477211049f60ef
      SHA1 checksum: 46ecd325b8e587fa491f6bb02ad4a9fb9f382f5f

   The checksums were calculated using the following commands:

    openssl md5 openssl-1.0.2a.tar.gz
    openssl sha1 openssl-1.0.2a.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVCs+pAAoJENnE0m0OYESRxPAH/RnASp6tS9gdV3luvD4FbAr9
EoASYKCPWAnlNdVYobRaAPVreoNC1xGrV2YwpFwh0z3D19Nz7O7utzrEEAgtlTa3
/H3jm91cNOJWldPh+fNIAerfESghf96tVrPFAzHZ2PpGSDvX/oNV8IWgqixtChCe
cQLa/EYT1VnFSiLOyoWWVFfICmzqk2Ke+aWKnnXgkS2gEOKTdCgdmkfmzTdRYGok
eVHzoFXN5AMY/zxvv4LVbpfdYmp0zynI2HWDRo2F5S3AQ+olVj3qmtJERW4DRlNT
ctZ9YStZzT39hbvOFVtE0XhhaERkO/tZMcso4Ouq8CU6qg4A6e7+X3gz2maWjfI=
=Qbok
-----END PGP SIGNATURE-----

From openssl at openssl.org  Thu Mar 19 14:09:28 2015
From: openssl at openssl.org (OpenSSL)
Date: Thu, 19 Mar 2015 14:09:28 +0000
Subject: [openssl-users] OpenSSL version 1.0.1m released
Message-ID: <20150319140928.GA640@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 1.0.1m released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.1m of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        http://www.openssl.org/news/openssl-1.0.1-notes.html

   OpenSSL 1.0.1m 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.0.1m.tar.gz
      Size: 4533406
      MD5 checksum: d143d1555d842a069cb7cc34ba745a06
      SHA1 checksum: 4ccaf6e505529652f9fdafa01d1d8300bd9f3179

   The checksums were calculated using the following commands:

    openssl md5 openssl-1.0.1m.tar.gz
    openssl sha1 openssl-1.0.1m.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVCtFhAAoJENnE0m0OYESRqp0H/jPPpLlFSwsSn7IASUzQL9/r
9e7KWLaHw1u2OH9MjgdfvWFSJAczNsc6l/UizpmJNcv26KVMzGcfk+wEGwNS6erO
SxlO3IYkQA8HJhRIyOlbkq75NbmOMO/ECfY+yc6NY1uciQpuO5sSk6GKuDiTvh03
d4VyubmKx55ITlmXnj2YTY2igFA1WY+QmHKVAtGN/b0OdakhjCFXY+IdZpbJujw+
UmkjwWrpBngBz/jJ0mRln7i47gT+tAlAw/O/bGLxHb4pMLtRLnT9QkeyKduOCNp8
S/2s+fHs7y2yEQ+hyPVwnp7IaRj+q/bIyg5+kpL/viT7FczXrfEqnbNmRjNumQA=
=umSV
-----END PGP SIGNATURE-----

From openssl at openssl.org  Thu Mar 19 14:09:46 2015
From: openssl at openssl.org (OpenSSL)
Date: Thu, 19 Mar 2015 14:09:46 +0000
Subject: [openssl-users] OpenSSL version 1.0.0r released
Message-ID: <20150319140946.GA810@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 1.0.0r released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.0r of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        http://www.openssl.org/news/openssl-1.0.0-notes.html

   OpenSSL 1.0.0r 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.0.0r.tar.gz
      Size: 4095201
      MD5 checksum: ea48d0ad53e10f06a9475d8cdc209dfa
      SHA1 checksum: 24508ff8c4ad94bcf1070441a737097f04480c6b

   The checksums were calculated using the following commands:

    openssl md5 openssl-1.0.0r.tar.gz
    openssl sha1 openssl-1.0.0r.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVCtJnAAoJENnE0m0OYESRX3AH/1erQLZ5BkGvGE+6yFkB0/Kv
0sDk3GrGEu1NjH3Fwg7ibnfrggr3m8XUc9oO89+cFWdu2pX0m2JC5wBqsGnXWBdu
H0kdS6C1v/vDUDZOUfozlnZjop8kwNtXFWpc7K3ALuKHssTyJi/ZH7+PfFUXwyDq
d+FVBmishi8UIcxk5Wltg+YrFZkCe7098AL2Yf1wQ3t3aa9zCR5zsHFnsY6nSViI
m12a8PIyrJLbKG7gLdxWAZ6y8Irs2avWnegcFomlB1vLmTm2yU302/vYW3DD3qUf
hQK7W63NUQ4bKDY1wieWroB8GfnZyf5EXHJaWRf3ECONhSIxMTimAR3YlI5Qsws=
=3kWK
-----END PGP SIGNATURE-----

From openssl at openssl.org  Thu Mar 19 14:09:54 2015
From: openssl at openssl.org (OpenSSL)
Date: Thu, 19 Mar 2015 14:09:54 +0000
Subject: [openssl-users] OpenSSL version 0.9.8zf released
Message-ID: <20150319140954.GA972@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 0.9.8zf released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 0.9.8zf of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        http://www.openssl.org/news/openssl-0.9.8-notes.html

   OpenSSL 0.9.8zf 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-0.9.8zf.tar.gz
      Size: 3822386
      MD5 checksum: c69a4a679233f7df189e1ad6659511ec
      SHA1 checksum: 3f2f4ca864b13a237ae063cd34d01bbdbc8f108f

   The checksums were calculated using the following commands:

    openssl md5 openssl-0.9.8zf.tar.gz
    openssl sha1 openssl-0.9.8zf.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVCtNyAAoJENnE0m0OYESRylAH/RYLoFCCjLXCQUzLcwI2d3gq
6Hysl+GiOixeqEaHwMbAyrhkvym8sRGHuCUL94lAos6yhlePrAkcGMk8J5sVfNKN
tczUswpQj8EZYTPsb0JdnOEQnBrezauhJphwDMwDPXjR5KGYzYTBpGL4AZIvJ9OT
xIodpg/ACqI8Tk6wnc+LHROMjUpAEkpUqbZbW6NilXT0Ajh6NjmDIYy/OT74Y/Cj
YzDb4V8pch/WhoF0t62dmOlq4cuBWYDNkw6oKPa5koBCURB2MsoZzF6H/grVgdU6
ADkw8ZSORVsESjVGhSRU9Ptni37BHx9DaIEsj2hLfGzAAcNgf6zUE9/u7iK/uJo=
=wJnL
-----END PGP SIGNATURE-----

From openssl at openssl.org  Thu Mar 19 14:12:02 2015
From: openssl at openssl.org (OpenSSL)
Date: Thu, 19 Mar 2015 14:12:02 +0000
Subject: [openssl-users] OpenSSL Security Advisory
Message-ID: <20150319141202.GA1887@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OpenSSL Security Advisory [19 Mar 2015]
=======================================

OpenSSL 1.0.2 ClientHello sigalgs DoS (CVE-2015-0291)
=====================================================

Severity: High

If a client connects to an OpenSSL 1.0.2 server and renegotiates with an
invalid signature algorithms extension a NULL pointer dereference will occur.
This can be exploited in a DoS attack against the server.

This issue affects OpenSSL version: 1.0.2

OpenSSL 1.0.2 users should upgrade to 1.0.2a.

This issue was was reported to OpenSSL on 26th February 2015 by David Ramos
of Stanford University. The fix was developed by Stephen Henson and Matt
Caswell of the OpenSSL development team.

Reclassified: RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204)
============================================================================

Severity: High

This security issue was previously announced by the OpenSSL project and
classified as "low" severity. This severity rating has now been changed to
"high".

This was classified low because it was originally thought that server RSA
export ciphersuite support was rare: a client was only vulnerable to a MITM
attack against a server which supports an RSA export ciphersuite. Recent
studies have shown that RSA export ciphersuites support is far more common.

This issue affects OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.1 users should upgrade to 1.0.1k.
OpenSSL 1.0.0 users should upgrade to 1.0.0p.
OpenSSL 0.9.8 users should upgrade to 0.9.8zd.

This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan
Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen
Henson of the OpenSSL core team. It was previously announced in the OpenSSL
security advisory on 8th January 2015.

Multiblock corrupted pointer (CVE-2015-0290)
============================================

Severity: Moderate

OpenSSL 1.0.2 introduced the "multiblock" performance improvement. This feature
only applies on 64 bit x86 architecture platforms that support AES NI
instructions. A defect in the implementation of "multiblock" can cause OpenSSL's
internal write buffer to become incorrectly set to NULL when using non-blocking
IO. Typically, when the user application is using a socket BIO for writing, this
will only result in a failed connection. However if some other BIO is used then
it is likely that a segmentation fault will be triggered, thus enabling a
potential DoS attack.

This issue affects OpenSSL version: 1.0.2

OpenSSL 1.0.2 users should upgrade to 1.0.2a.

This issue was reported to OpenSSL on 13th February 2015 by Daniel Danner and
Rainer Mueller. The fix was developed by Matt Caswell of the OpenSSL development
team.

Segmentation fault in DTLSv1_listen (CVE-2015-0207)
===================================================

Severity: Moderate

The DTLSv1_listen function is intended to be stateless and processes the initial
ClientHello from many peers. It is common for user code to loop over the call to
DTLSv1_listen until a valid ClientHello is received with an associated cookie. A
defect in the implementation of DTLSv1_listen means that state is preserved in
the SSL object from one invocation to the next that can lead to a segmentation
fault. Errors processing the initial ClientHello can trigger this scenario. An
example of such an error could be that a DTLS1.0 only client is attempting to
connect to a DTLS1.2 only server.

This issue affects OpenSSL version: 1.0.2

OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2a.

This issue was reported to OpenSSL on 27th January 2015 by Per Allansson. The
fix was developed by Matt Caswell of the OpenSSL development team.

Segmentation fault in ASN1_TYPE_cmp (CVE-2015-0286)
===================================================

Severity: Moderate

The function ASN1_TYPE_cmp will crash with an invalid read if an attempt is
made to compare ASN.1 boolean types. Since ASN1_TYPE_cmp is used to check
certificate signature algorithm consistency this can be used to crash any
certificate verification operation and exploited in a DoS attack. Any
application which performs certificate verification is vulnerable including
OpenSSL clients and servers which enable client authentication.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2a
OpenSSL 1.0.1 users should upgrade to 1.0.1m.
OpenSSL 1.0.0 users should upgrade to 1.0.0r.
OpenSSL 0.9.8 users should upgrade to 0.9.8zf.

This issue was discovered and fixed by Stephen Henson of the OpenSSL
development team.

Segmentation fault for invalid PSS parameters (CVE-2015-0208)
=============================================================

Severity: Moderate

The signature verification routines will crash with a NULL pointer
dereference if presented with an ASN.1 signature using the RSA PSS
algorithm and invalid parameters. Since these routines are used to verify
certificate signature algorithms this can be used to crash any
certificate verification operation and exploited in a DoS attack. Any
application which performs certificate verification is vulnerable including
OpenSSL clients and servers which enable client authentication.

This issue affects OpenSSL version: 1.0.2

OpenSSL 1.0.2 users should upgrade to 1.0.2a

This issue was was reported to OpenSSL on 31st January 2015 by Brian Carpenter
and a fix developed by Stephen Henson of the OpenSSL development team.

ASN.1 structure reuse memory corruption (CVE-2015-0287)
=======================================================

Severity: Moderate

Reusing a structure in ASN.1 parsing may allow an attacker to cause
memory corruption via an invalid write. Such reuse is and has been
strongly discouraged and is believed to be rare.

Applications that parse structures containing CHOICE or ANY DEFINED BY
components may be affected. Certificate parsing (d2i_X509 and related
functions) are however not affected. OpenSSL clients and servers are
not affected.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0
and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2a
OpenSSL 1.0.1 users should upgrade to 1.0.1m.
OpenSSL 1.0.0 users should upgrade to 1.0.0r.
OpenSSL 0.9.8 users should upgrade to 0.9.8zf.

This issue was discovered by Emilia K??sper and a fix developed by
Stephen Henson of the OpenSSL development team.

PKCS7 NULL pointer dereferences (CVE-2015-0289)
===============================================

Severity: Moderate

The PKCS#7 parsing code does not handle missing outer ContentInfo correctly.
An attacker can craft malformed ASN.1-encoded PKCS#7 blobs with
missing content and trigger a NULL pointer dereference on parsing.

Applications that verify PKCS#7 signatures, decrypt PKCS#7 data or
otherwise parse PKCS#7 structures from untrusted sources are
affected. OpenSSL clients and servers are not affected.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0
and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2a
OpenSSL 1.0.1 users should upgrade to 1.0.1m.
OpenSSL 1.0.0 users should upgrade to 1.0.0r.
OpenSSL 0.9.8 users should upgrade to 0.9.8zf.

This issue was reported to OpenSSL on February 16th 2015 by Michal
Zalewski (Google) and a fix developed by Emilia K??sper of the OpenSSL
development team.

Base64 decode (CVE-2015-0292)
=============================

Severity: Moderate

A vulnerability existed in previous versions of OpenSSL related to the
processing of base64 encoded data. Any code path that reads base64 data from an
untrusted source could be affected (such as the PEM processing routines).
Maliciously crafted base 64 data could trigger a segmenation fault or memory
corruption. This was addressed in previous versions of OpenSSL but has not been
included in any security advisory until now.

This issue affects OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.1 users should upgrade to 1.0.1h.
OpenSSL 1.0.0 users should upgrade to 1.0.0m.
OpenSSL 0.9.8 users should upgrade to 0.9.8za.

The fix for this issue can be identified by commits d0666f289a (1.0.1),
84fe686173 (1.0.0) and 9febee0272 (0.9.8). This issue was originally reported by
Robert Dugal and subsequently by David Ramos.

DoS via reachable assert in SSLv2 servers (CVE-2015-0293)
=========================================================

Severity: Moderate

A malicious client can trigger an OPENSSL_assert (i.e., an abort) in
servers that both support SSLv2 and enable export cipher suites by sending
a specially crafted SSLv2 CLIENT-MASTER-KEY message.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0
and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2a
OpenSSL 1.0.1 users should upgrade to 1.0.1m.
OpenSSL 1.0.0 users should upgrade to 1.0.0r.
OpenSSL 0.9.8 users should upgrade to 0.9.8zf.

This issue was discovered by Sean Burford (Google) and Emilia K??sper
(OpenSSL development team) in March 2015 and the fix was developed by
Emilia K??sper.

Empty CKE with client auth and DHE (CVE-2015-1787)
==================================================

Severity: Moderate

If client auth is used then a server can seg fault in the event of a DHE
ciphersuite being selected and a zero length ClientKeyExchange message being
sent by the client. This could be exploited in a DoS attack.

This issue affects OpenSSL version: 1.0.2

OpenSSL 1.0.2 users should upgrade to 1.0.2a.

This issue was discovered and the fix was developed by Matt Caswell of the
OpenSSL development team.

Handshake with unseeded PRNG (CVE-2015-0285)
============================================

Severity: Low

Under certain conditions an OpenSSL 1.0.2 client can complete a handshake with
an unseeded PRNG. The conditions are:
- - The client is on a platform where the PRNG has not been seeded automatically,
and the user has not seeded manually
- - A protocol specific client method version has been used (i.e. not
SSL_client_methodv23)
- - A ciphersuite is used that does not require additional random data from the
PRNG beyond the initial ClientHello client random (e.g. PSK-RC4-SHA).

If the handshake succeeds then the client random that has been used will have
been generated from a PRNG with insufficient entropy and therefore the output
may be predictable.

For example using the following command with an unseeded openssl will succeed on
an unpatched platform:

openssl s_client -psk 1a2b3c4d -tls1_2 -cipher PSK-RC4-SHA

This issue affects OpenSSL version: 1.0.2

OpenSSL 1.0.2 users should upgrade to 1.0.2a.

This issue was discovered and the fix was developed by Matt Caswell of the
OpenSSL development team.

Use After Free following d2i_ECPrivatekey error (CVE-2015-0209)
===============================================================

Severity: Low

A malformed EC private key file consumed via the d2i_ECPrivateKey function could
cause a use after free condition. This, in turn, could cause a double
free in several private key parsing functions (such as d2i_PrivateKey
or EVP_PKCS82PKEY) and could lead to a DoS attack or memory corruption
for applications that receive EC private keys from untrusted
sources. This scenario is considered rare.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2a
OpenSSL 1.0.1 users should upgrade to 1.0.1m.
OpenSSL 1.0.0 users should upgrade to 1.0.0r.
OpenSSL 0.9.8 users should upgrade to 0.9.8zf.

This issue was discovered by the BoringSSL project and fixed in their commit
517073cd4b. The OpenSSL fix was developed by Matt Caswell of the OpenSSL
development team.

X509_to_X509_REQ NULL pointer deref (CVE-2015-0288)
===================================================

Severity: Low

The function X509_to_X509_REQ will crash with a NULL pointer dereference if
the certificate key is invalid. This function is rarely used in practice.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0
and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2a
OpenSSL 1.0.1 users should upgrade to 1.0.1m.
OpenSSL 1.0.0 users should upgrade to 1.0.0r.
OpenSSL 0.9.8 users should upgrade to 0.9.8zf.

This issue was discovered by Brian Carpenter and a fix developed by Stephen
Henson of the OpenSSL development team.

Note
====

As per our previous announcements and our Release Strategy
(https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions
1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these
releases will be provided after that date. Users of these releases are advised
to upgrade.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv_20150319.txt

Note: the online version of the advisory may be updated with additional
details over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/about/secpolicy.html

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVCs3bAAoJENnE0m0OYESRxuYH/iQAugnk+JYPe14KVYAoIHWS
W63200SoPK4v6Sl6v7CbBzWPXLUe16n4ESlycrmiowAviOAroZKL+yk7iv/SHStL
cQN8tx26vzESIgKKWUyMKUsm82JF08dJiZjiw/l+I7ntM+jMkXmvf1bMF2FqmzYl
5dBJmZqUK5sz6sue78iQT5yznJkJ+106oJUVXTHb3NVya4WMDzQ9IFgYFtfaZCQI
kRy355VZcEl1ePVYFxE0fDQ2mzBeEejsv8eeOs9VRv5yMnV5dV35RQeKS5YxFXsP
sT+ToTkNBF6yMt1HEAMR+2viisUvJDQHePLCodJSqGlfsgOVlM8N3pY6NPT8fDM=
=I76k
-----END PGP SIGNATURE-----

From Isaac.Hailperin at lcsystems.ch  Thu Mar 19 14:37:38 2015
From: Isaac.Hailperin at lcsystems.ch (Isaac Hailperin)
Date: Thu, 19 Mar 2015 14:37:38 +0000
Subject: [openssl-users] Automatische Antwort: *****SPAM***** The most
 beautiful handbag LouisVuitton
In-Reply-To: <20150319100044264548@smtp2.baogaoning.com>
References: <20150319100044264548@smtp2.baogaoning.com>
Message-ID: <b9efb3350303462493e91b2038e1b6e3@TGW00I-1401.lcsys.ch>

Hello,

I am currently out of office and will not read your email untill Monday, the 23rd of January. In urgent cases please contact managed.service at lcsystems.ch.

Best regards,
Isaac Hailperin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150319/e4b5b2ee/attachment.html>

From openssl-users at openssl.org  Fri Mar 20 08:28:27 2015
From: openssl-users at openssl.org (openssl-users at openssl.org)
Date: Fri, 20 Mar 2015 05:28:27 -0300
Subject: [openssl-users] Acompanhamento de Entrega - 6469455
Message-ID: <c33264049eaf2c31664c322e632b6487@openssl.org>

An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150320/534aedb2/attachment.html>

From pbellino at mrv.com  Fri Mar 20 12:01:54 2015
From: pbellino at mrv.com (Philip Bellino)
Date: Fri, 20 Mar 2015 12:01:54 +0000
Subject: [openssl-users] AES CBC approved encryption algorithm/option in FIPS
Message-ID: <AM3PR03MB0824BF42C70045DB6CB7E3D1C30E0@AM3PR03MB0824.eurprd03.prod.outlook.com>

Hello,
I am using the Openssl-1.0.2 with openssl-fips-2.0.9 and have a question?

If AES CBC Encryption is considered vulnerable to an attacker with the capability to inject arbitrary traffic into the plain-text stream, then why is it listed as an approved algorithm/option in table 4A on page 14 of the OpenSSL Security Policy:  http://openssl.org/docs/fips/SecurityPolicy-2.0.9.pdf

I am just looking for a clarification.
Thanks,
Phil

Phil Bellino
Principal Software Engineer | MRV Communications Inc.
300 Apollo Drive |  Chelmsford, MA 01824
Phone: 978-674-6870  |   Fax: 978-674-6799
www.mrv.com


[MRV-email]
-209

[E-Banner]<http://www.mrv.com/landing/video-datasheet-mrvs-optidriver-platform>


The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150320/aaccf61b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6563 bytes
Desc: image001.png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150320/aaccf61b/attachment-0001.png>

From stevenx.linsell at intel.com  Fri Mar 20 12:44:24 2015
From: stevenx.linsell at intel.com (Linsell, StevenX)
Date: Fri, 20 Mar 2015 12:44:24 +0000
Subject: [openssl-users] Failure using ECDH-RSA-AES256-SHA with ssl3 on
	Master Branch
In-Reply-To: <BC6016DA3A27864486295F6D844656F132ACD2BF@irsmsx105.ger.corp.intel.com>
References: <BC6016DA3A27864486295F6D844656F132ACD2BF@irsmsx105.ger.corp.intel.com>
Message-ID: <BC6016DA3A27864486295F6D844656F132ACDEE6@irsmsx105.ger.corp.intel.com>

On Thu, Mar 19, 2015, Steve Linsell wrote:
> 
> I am trying to use ECDH-RSA-AES256-SHA with ssl3 with s_client and s_server on
> the master branch. (cloned at commit
> f7683aaf36341dc65672ac2ccdbfd4a232e3626d) and then retested ?with a more
> recent clone: (commit da27006df06853a33b132133699a7aa9d4277920).

Following further testing I see identical failures in the master branch using the following cipher/protocol combinations:

ECDH-ECDSA-AES128-SHA      ssl3 
ECDH-ECDSA-AES256-SHA      ssl3            
ECDH-ECDSA-DES-CBC3-SHA    ssl3          
ECDH-ECDSA-RC4-SHA         ssl3               
ECDH-RSA-AES128-SHA        ssl3                    
ECDH-RSA-AES256-SHA        ssl3         
ECDH-RSA-DES-CBC3-SHA      ssl3          
ECDH-RSA-RC4-SHA           ssl3                
ECDHE-ECDSA-AES128-SHA     ssl3         
ECDHE-ECDSA-AES256-SHA     ssl3          
ECDHE-ECDSA-DES-CBC3-SHA   ssl3                
ECDHE-ECDSA-RC4-SHA        ssl3             

The issue appears to be anywhere an elliptical curve certificate (whether signed with rsa or ecdsa) is used with ssl3.
The error produced looks very similar to that produced when you generate a certificate without the OPENSSL_EC_NAMED_CURVE flag as described on the OpenSSL wiki, but as you can see from the dump of the certificate below in this case the ASN1 OID: prime256v1 line is present. The certificates also function fine with tls1, tls1.1 and tls1.2.

Is there anyone that can confirm that they see the same behaviour, to rule out my setup and certificate generation?

> Here is a dump of the certificate:
> ./openssl x509 -in prime256v1-rsaTestServer.cert.pem -text -noout
> Certificate:
>     Data:
>         Version: 1 (0x0)
>         Serial Number: 16838786626002069798 (0xe9af63387b73a926)
>     Signature Algorithm: sha256WithRSAEncryption
>         Issuer: C=US, ST=CA, L=Mountain View, O=Sun Microsystems, Inc., OU=Sun
> Microsystems Laboratories, CN=Test CA (2048 bit RSA)
>         Validity
>             Not Before: Mar 13 11:38:21 2015 GMT
>             Not After : Apr 21 11:38:21 2019 GMT
>         Subject: C=US, ST=CA, L=Mountain View, O=Sun Microsystems, Inc.,
> OU=Sun Microsystems Laboratories, CN=Test Server (prime256v1 key signed
> with RSA)
>         Subject Public Key Info:
>             Public Key Algorithm: id-ecPublicKey
>                 Public-Key: (256 bit)
>                 pub:
>                     04:0d:a6:16:d8:43:25:dc:83:6d:18:fb:f0:b7:41:
>                     bc:05:88:a2:f2:56:8a:76:7a:d0:2b:7f:de:0a:44:
>                     33:4b:de:5b:30:44:ff:34:0e:17:c6:38:77:d7:53:
>                     b2:c2:fa:9f:7f:d5:e3:a4:b5:de:ce:29:9d:74:e6:
>                     59:76:9f:e6:eb
>                 ASN1 OID: prime256v1
>                 NIST CURVE: P-256
>     Signature Algorithm: sha256WithRSAEncryption
>          d0:1c:97:60:b9:14:cf:5a:c8:ea:8d:65:63:75:50:f2:63:68:
>          82:06:0c:47:f5:52:13:a5:61:4b:cd:99:ab:d0:56:81:a7:92:
>          21:c7:07:e3:12:25:4a:a8:c7:83:7a:bd:57:11:c7:55:88:28:
>          74:f1:37:bb:cd:0b:5b:7b:6f:45:e6:8d:1a:be:1a:fd:e0:d2:
>          5b:e5:ee:39:2e:73:c8:d6:03:5c:f6:f9:37:4a:81:e4:41:5a:
>          87:d5:0d:da:48:67:14:bb:75:3b:ae:68:b9:c4:25:2d:19:a7:
>          05:90:a2:fb:b4:d3:00:4f:40:19:e9:2d:83:75:db:3c:53:fe:
>          08:ae:ca:ba:3d:a5:4d:6e:f6:14:af:ee:7e:6d:dc:45:96:91:
>          92:6d:37:52:b6:b7:ad:70:02:d0:11:0d:84:1b:f1:3b:82:be:
>          66:af:a6:3c:17:33:d0:98:c3:cb:d3:22:39:d1:66:6e:94:ce:
>          7e:70:3c:02:29:6a:b6:87:e9:c4:e9:44:b4:9b:f1:8e:47:82:
>          2d:20:79:0e:f6:91:b1:e9:cf:83:66:8f:ff:e1:4f:2f:a1:ab:
>          ca:2d:81:53:7d:7f:69:b5:11:59:7e:9a:47:1c:6a:c8:83:54:
>          83:0a:7d:46:ec:2e:e9:82:f3:b4:d4:f6:04:57:bc:a5:b2:c5:
>          0c:ed:a6:fa
> 
> Single stepping through the code I can see the failure is occurring in
> tls1_check_ec_key when it is called from tls1_check_cert_param.
> It appears to go around a for loop (j) twice. The first time through it correctly
> matches the curve it is looking for. The second time round the list is empty and 0
> is returned. This failure causes the Elliptical curve cert not to be declared as valid
> and consequently the handshake fails with the no shared cipher message.
> I don't have a good understanding of how the certificate code works so I
> haven't managed to debug any further than that in order to determine why the
> second time round the loop the list is empty.
> 
> --
> Steve Linsell                                     Intel Shannon DCG/CID Software Development
> Team
> Stevenx.Linsell at intel.com
> 
Steve Linsell                                     Intel Shannon DCG/CID Software Development Team
Stevenx.Linsell at intel.com

--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.



From matt at openssl.org  Fri Mar 20 15:51:17 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 20 Mar 2015 15:51:17 +0000
Subject: [openssl-users] Failure using ECDH-RSA-AES256-SHA with ssl3 on
 Master Branch
In-Reply-To: <BC6016DA3A27864486295F6D844656F132ACDEE6@irsmsx105.ger.corp.intel.com>
References: <BC6016DA3A27864486295F6D844656F132ACD2BF@irsmsx105.ger.corp.intel.com>
 <BC6016DA3A27864486295F6D844656F132ACDEE6@irsmsx105.ger.corp.intel.com>
Message-ID: <550C41F5.1070906@openssl.org>



On 20/03/15 12:44, Linsell, StevenX wrote:
> On Thu, Mar 19, 2015, Steve Linsell wrote:
>>
>> I am trying to use ECDH-RSA-AES256-SHA with ssl3 with s_client and s_server on
>> the master branch. (cloned at commit
>> f7683aaf36341dc65672ac2ccdbfd4a232e3626d) and then retested  with a more
>> recent clone: (commit da27006df06853a33b132133699a7aa9d4277920).
> 
> Following further testing I see identical failures in the master branch using the following cipher/protocol combinations:
> 
> ECDH-ECDSA-AES128-SHA      ssl3 
> ECDH-ECDSA-AES256-SHA      ssl3            
> ECDH-ECDSA-DES-CBC3-SHA    ssl3          
> ECDH-ECDSA-RC4-SHA         ssl3               
> ECDH-RSA-AES128-SHA        ssl3                    
> ECDH-RSA-AES256-SHA        ssl3         
> ECDH-RSA-DES-CBC3-SHA      ssl3          
> ECDH-RSA-RC4-SHA           ssl3                
> ECDHE-ECDSA-AES128-SHA     ssl3         
> ECDHE-ECDSA-AES256-SHA     ssl3          
> ECDHE-ECDSA-DES-CBC3-SHA   ssl3                
> ECDHE-ECDSA-RC4-SHA        ssl3             
> 


Hi Steve

Looks like a bug. Try the attached patch. Let me know how you get on.

Thanks

Matt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: curves-check.patch
Type: text/x-patch
Size: 1034 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150320/1f4d3664/attachment.bin>

From jonetsu at teksavvy.com  Fri Mar 20 16:19:22 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Fri, 20 Mar 2015 12:19:22 -0400
Subject: [openssl-users] Runtime list of FIPS ciphers
Message-ID: <ebb18857a72dd396a11c6f6d09d97493@teksavvy.com>

Hello,

? I have the impression that the 'ciphers -v' option to openssl, when OpenSSL is compiled in FIPS mode, lists more than FIPS-only.? There are RC5 and RC4 in there, for instance.? Is there a specific openssl command that will list only the ones that are FIPS-allowed? ?

Regards.



From steve at openssl.org  Fri Mar 20 16:47:58 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 20 Mar 2015 16:47:58 +0000
Subject: [openssl-users] Runtime list of FIPS ciphers
In-Reply-To: <ebb18857a72dd396a11c6f6d09d97493@teksavvy.com>
References: <ebb18857a72dd396a11c6f6d09d97493@teksavvy.com>
Message-ID: <20150320164758.GA1308@openssl.org>

On Fri, Mar 20, 2015, jonetsu wrote:

> Hello,
> 
> ? I have the impression that the 'ciphers -v' option to openssl, when OpenSSL is compiled in FIPS mode, lists more than FIPS-only.? There are RC5 and RC4 in there, for instance.? Is there a specific openssl command that will list only the ones that are FIPS-allowed? ?
> 

If you are in FIPS mode it will only list FIPS ciphersuites in the default
cipher string:

	OPENSSL_FIPS=1 openssl ciphers -v

If outside FIPS mode you can use the cipher string "FIPS":

	openssl ciphers -v FIPS

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

From jonetsu at teksavvy.com  Fri Mar 20 17:25:06 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Fri, 20 Mar 2015 13:25:06 -0400
Subject: [openssl-users] Runtime list of FIPS ciphers
In-Reply-To: <20150320164758.GA1308@openssl.org>
References: <ebb18857a72dd396a11c6f6d09d97493@teksavvy.com>
 <20150320164758.GA1308@openssl.org>
Message-ID: <96e763a9c98e6facc4cc85cc71f63149@teksavvy.com>



> From: "Dr. Stephen Henson" <steve at openssl.org> 
> Date: 03/20/15 12:48 
?
> ?????OPENSSL_FIPS=1 openssl ciphers -v
> ?????openssl ciphers -v FIPS

Thanks, this works great, on the workstation where I have installed at default development location /usr/loca/ssl/, using OpenSSL 1.0.1.k.? 

However, we have built Debian packages for the target unit, using 1.0.1e.? While the example fips_hmac runs fine, we have a problem with openssl itself, which seems to be that the openssl shared object is somehow not FIPS enabled, or, is 1.0.1e lacking in any respect to FIPS mode ? :

% ./fips_hmac -v gcrypt_pkglist

?FIPS mode enabled
?ret: 1
?51dedc633485ccb55f4624763e9d118d6df15b3c


% OPENSSL_FIPS=1 openssl ciphers -v

?3069818064:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips mode:ssl_lib.c:1729:


% ldd fips_hmac

?libcrypto.so.1.0.0 => /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 (0xb6dbc000)

% ldd /usr/bin/openssl

?libssl.so.1.0.0 => /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0 (0xb6f5e000)
?libcrypto.so.1.0.0 => /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 (0xb6e03000)


% openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013



  


From steve at openssl.org  Fri Mar 20 17:43:25 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 20 Mar 2015 17:43:25 +0000
Subject: [openssl-users] Runtime list of FIPS ciphers
In-Reply-To: <96e763a9c98e6facc4cc85cc71f63149@teksavvy.com>
References: <ebb18857a72dd396a11c6f6d09d97493@teksavvy.com>
 <20150320164758.GA1308@openssl.org>
 <96e763a9c98e6facc4cc85cc71f63149@teksavvy.com>
Message-ID: <20150320174325.GA5071@openssl.org>

On Fri, Mar 20, 2015, jonetsu wrote:

> 
> 
> > From: "Dr. Stephen Henson" <steve at openssl.org> 
> > Date: 03/20/15 12:48 
> ?
> > ?????OPENSSL_FIPS=1 openssl ciphers -v
> > ?????openssl ciphers -v FIPS
> 
> Thanks, this works great, on the workstation where I have installed at default development location /usr/loca/ssl/, using OpenSSL 1.0.1.k.? 
> 
> However, we have built Debian packages for the target unit, using 1.0.1e.? While the example fips_hmac runs fine, we have a problem with openssl itself, which seems to be that the openssl shared object is somehow not FIPS enabled, or, is 1.0.1e lacking in any respect to FIPS mode ? :
> 

Some of the apps used to default to SSLv3 if OpenSSL was compiled with
no-ssl2. This is fixed in later versions of OpenSSL. Try manually adding the
-tls1 option to the ciphers command.

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

From jeremy.farrell at oracle.com  Fri Mar 20 19:51:04 2015
From: jeremy.farrell at oracle.com (Jeremy Farrell)
Date: Fri, 20 Mar 2015 19:51:04 +0000
Subject: [openssl-users] AES CBC approved encryption algorithm/option in
 FIPS
In-Reply-To: <AM3PR03MB0824BF42C70045DB6CB7E3D1C30E0@AM3PR03MB0824.eurprd03.prod.outlook.com>
References: <AM3PR03MB0824BF42C70045DB6CB7E3D1C30E0@AM3PR03MB0824.eurprd03.prod.outlook.com>
Message-ID: <550C7A28.3060800@oracle.com>

I assume it says it is a FIPS 140-2 approved mode because it is approved 
by FIPS 140-2 ;). Don't confuse the concepts of being 'FIPS approved' or 
'FIPS compliant' with being 'secure'. They are not the same thing, and 
can sometimes conflict.

On 20/03/2015 12:01, Philip Bellino wrote:
>
> Hello,
>
> I am using the Openssl-1.0.2 with openssl-fips-2.0.9 and have a question?
>
> If AES CBC Encryption is considered vulnerable to an attacker with the 
> capability to inject arbitrary traffic into the plain-text stream, 
> then why is it listed as an approved algorithm/option in table 4A on 
> page 14 of the OpenSSL Security Policy: 
> http://openssl.org/docs/fips/SecurityPolicy-2.0.9.pdf
>
> I am just looking for a clarification.
>
> Thanks,
>
> Phil
>
> *Phil Bellino*
>
> *Principal Software Engineer****| **MRV Communications Inc.*
>
> 300 Apollo Drive *| *Chelmsford, MA 01824
>
> Phone: 978-674-6870*| *Fax: 978-674-6799
>
> www.mrv.com
>

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

From openssl-users at dukhovni.org  Sat Mar 21 06:58:38 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 21 Mar 2015 06:58:38 +0000
Subject: [openssl-users] Failure using ECDH-RSA-AES256-SHA with ssl3 on
 Master Branch
In-Reply-To: <550C41F5.1070906@openssl.org>
References: <BC6016DA3A27864486295F6D844656F132ACD2BF@irsmsx105.ger.corp.intel.com>
 <BC6016DA3A27864486295F6D844656F132ACDEE6@irsmsx105.ger.corp.intel.com>
 <550C41F5.1070906@openssl.org>
Message-ID: <20150321065838.GC9387@mournblade.imrryr.org>

On Fri, Mar 20, 2015 at 03:51:17PM +0000, Matt Caswell wrote:

> >> I am trying to use ECDH-RSA-AES256-SHA with ssl3 with s_client and s_server on
> >> the master branch. (cloned at commit
> >> f7683aaf36341dc65672ac2ccdbfd4a232e3626d) and then retested  with a more
> >> recent clone: (commit da27006df06853a33b132133699a7aa9d4277920).
> 
> Looks like a bug. Try the attached patch. Let me know how you get on.

> Subject: [PATCH] Don't check curves that haven't been sent
> 
> Don't check that the curve appears in the list of acceptable curves for the
> peer, if they didn't send us such a list (for example this will always be
> the case in SSL3)

Are you sure that's a bug.  I recall a recent discussion that
specifically pointed out that we should not negotiate ECDH when
the relevant extension is not sent.  We have no idea which curves
the client supports, and therefore can't choose any.

IIRC the current behaviour is a bug fix, and any prior use of ECDH
with SSLv3 was wrong.

-- 
	Viktor.

From openssl-users at dukhovni.org  Sat Mar 21 08:19:30 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 21 Mar 2015 08:19:30 +0000
Subject: [openssl-users] Failure using ECDH-RSA-AES256-SHA with ssl3 on
 Master Branch
In-Reply-To: <20150321065838.GC9387@mournblade.imrryr.org>
References: <BC6016DA3A27864486295F6D844656F132ACD2BF@irsmsx105.ger.corp.intel.com>
 <BC6016DA3A27864486295F6D844656F132ACDEE6@irsmsx105.ger.corp.intel.com>
 <550C41F5.1070906@openssl.org>
 <20150321065838.GC9387@mournblade.imrryr.org>
Message-ID: <20150321081930.GE9387@mournblade.imrryr.org>

On Sat, Mar 21, 2015 at 06:58:38AM +0000, Viktor Dukhovni wrote:

> > Don't check that the curve appears in the list of acceptable curves for the
> > peer, if they didn't send us such a list (for example this will always be
> > the case in SSL3)
> 
> Are you sure that's a bug.  I recall a recent discussion that
> specifically pointed out that we should not negotiate ECDH when
> the relevant extension is not sent.  We have no idea which curves
> the client supports, and therefore can't choose any.
> 
> IIRC the current behaviour is a bug fix, and any prior use of ECDH
> with SSLv3 was wrong.

Perhaps I recall incorrectly.  Looking at RFC 4492, it seems that
if the client sends no information, the server is free to choose
any supported curve.  Still clients that support EC really should
send the relevant extensions.

-- 
	Viktor.

From de.techno at gmail.com  Sat Mar 21 11:00:29 2015
From: de.techno at gmail.com (dE)
Date: Sat, 21 Mar 2015 16:30:29 +0530
Subject: [openssl-users] TLS 1.2 message hiding.
In-Reply-To: <35d534d9c5894476a1255f98c5ba2edf@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <5502FC04.9080503@gmail.com>
 <20dbec497eb14eaf83bdbfc9737ef07a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <55084D5A.6030303@gmail.com>
 <35d534d9c5894476a1255f98c5ba2edf@usma1ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <550D4F4D.3070104@gmail.com>

On 03/17/15 22:29, Salz, Rich wrote:
>> Ok, so TLS does not handle this.
> The current draft of the TLS 1.3 specification includes a field to pad every data record.
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Thanks for the info.

From xxiao8 at fosiao.com  Sat Mar 21 18:48:15 2015
From: xxiao8 at fosiao.com (xxiao8)
Date: Sat, 21 Mar 2015 13:48:15 -0500
Subject: [openssl-users] SP800-90 DRBG in OpenSSL FIPS 140 for SP800-90A?
Message-ID: <550DBCEF.6070906@fosiao.com>

At the moment OpenSSL FIPS validation supports ANSI X9.31 with AES128 
for RNG, however it will be outdated in 2015.

Another alternative RNG in OpenSSL FIPS is SP800-90 DRBG, however the 
new requirement is to use DRBG per SP800-90A.

Are the DRBGs in SP800-90/OpenSSL-FIPS-2.0.9 the same as what SP800-90A 
requires? Otherwise how can OpenSSL 2.0 FIPS be used in any new validations?

Thanks,
xxiao


From tanner at gmx.net  Sat Mar 21 19:31:08 2015
From: tanner at gmx.net (Thomas Tanner)
Date: Sat, 21 Mar 2015 20:31:08 +0100
Subject: [openssl-users] overriding v3 extensions
Message-ID: <550DC6FC.2020608@gmx.net>

Hello,

I'd like to set individual v3 extensions (in particular subjectAltname)
when signing certificate requests (CSR) and use CA defaults for the
other extensions.
Is it possible to achieve this without passing the complete list of
extensions for the certificate via -config or -extfile ?

Example:
I have a certificate request with subj=/CN=foo/emailAddress=foo at bar.com/
and subjectAltname=email:foo at bar.com,DNS:bar.com
and a default section for extensions v3_ext in openssl.cnf
(authorityInfoAccess etc).
I can change the subject of the CSR using "openssl req -subj newsubj".
However, changing the extensions isn't that easy:

I have tried to change the subjectAltname of the CSR to no avail with
"openssl req -config extcfg -reqexts ext" with extcfg:
[ext]
subjAltname=newaltname

If this was working, I would have added copy_extensions=copy in
openssl.cnf and removed subjectAltname from the v3_ext section,
so that subjectAltName would be copied from the modified CSR and merged
with the defaults.

It seems I need copy the whole v3_ext section from openssl.cnf, replace
subjectAltname with the desired value and run "openssl ca -extfile
extcfg -extensions v3_ext"

Is there any other solution that does not require extracting v3_ext from
openssl.cnf?

Thank you!

From gswan3 at bigpond.net.au  Sat Mar 21 23:49:53 2015
From: gswan3 at bigpond.net.au (Geoff Swan)
Date: Sun, 22 Mar 2015 10:49:53 +1100
Subject: [openssl-users] LMDB use of sparse or non-sparse data file
In-Reply-To: <550E0327.3000909@bigpond.net.au>
References: <550E0327.3000909@bigpond.net.au>
Message-ID: <550E03A1.4040004@bigpond.net.au>

Sorry, wrong mailing list!

On 22/03/2015 10:47 AM, Geoff Swan wrote:
> I had to duplicate an LMDB database for replication recently, and used
> mdb_copy to do so.
> One server is using the original data.mdb database (which is sparse) and
> the other is using the mdb_copy non-sparse data.mdb file.
> The two servers are identical (hardware, OS, software and
> configuration). OpenLDAP-2.4.39 is being used, 64 bit Linux OS.
> mdb_stat shows the map size as the same, which is expected.
>
> Will the use of the non-sparse file cause any performance issues?
>
> The reason for asking is that I am seeing a difference in search times
> between the two.
> With 20 million objects, a search on modifyTimestamp (which is indexed)
> gives:
> server 1: approx 1s
> server 2: approx 60s
>
> server 2 started with the same search time as server 1 when the
> databases were originally copied, but has slowly increased its search
> time over about a week for this same search.


From gswan3 at bigpond.net.au  Sat Mar 21 23:47:51 2015
From: gswan3 at bigpond.net.au (Geoff Swan)
Date: Sun, 22 Mar 2015 10:47:51 +1100
Subject: [openssl-users] LMDB use of sparse or non-sparse data file
Message-ID: <550E0327.3000909@bigpond.net.au>

I had to duplicate an LMDB database for replication recently, and used
mdb_copy to do so.
One server is using the original data.mdb database (which is sparse) and
the other is using the mdb_copy non-sparse data.mdb file.
The two servers are identical (hardware, OS, software and
configuration). OpenLDAP-2.4.39 is being used, 64 bit Linux OS.
mdb_stat shows the map size as the same, which is expected.

Will the use of the non-sparse file cause any performance issues?

The reason for asking is that I am seeing a difference in search times
between the two.
With 20 million objects, a search on modifyTimestamp (which is indexed)
gives:
server 1: approx 1s
server 2: approx 60s

server 2 started with the same search time as server 1 when the
databases were originally copied, but has slowly increased its search
time over about a week for this same search.





From nirajsorathiya101 at gmail.com  Sun Mar 22 04:14:14 2015
From: nirajsorathiya101 at gmail.com (Niraj Sorathiya)
Date: Sun, 22 Mar 2015 09:44:14 +0530
Subject: [openssl-users] Location of main function in openssl source code.
Message-ID: <CAFT0Dp0_0anV+Z2V+qgPF9T4PMPUGRJPXhJnJJarb8meBtj_sw@mail.gmail.com>

Hi,

Can anyone tell me starting point or location of main method in openssl
source code which starts openssl command line toolkit ?

Have a  good  day !

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

From matt at openssl.org  Sun Mar 22 14:30:06 2015
From: matt at openssl.org (Matt Caswell)
Date: Sun, 22 Mar 2015 14:30:06 +0000
Subject: [openssl-users] Location of main function in openssl source
	code.
In-Reply-To: <CAFT0Dp0_0anV+Z2V+qgPF9T4PMPUGRJPXhJnJJarb8meBtj_sw@mail.gmail.com>
References: <CAFT0Dp0_0anV+Z2V+qgPF9T4PMPUGRJPXhJnJJarb8meBtj_sw@mail.gmail.com>
Message-ID: <550ED1EE.8060905@openssl.org>



On 22/03/15 04:14, Niraj Sorathiya wrote:
> Hi,
> 
> Can anyone tell me starting point or location of main method in openssl
> source code which starts openssl command line toolkit ? 
> 

Hi Niraj

"main" is located in apps/openssl.c

Matt

From nirajsorathiya101 at gmail.com  Sun Mar 22 18:29:53 2015
From: nirajsorathiya101 at gmail.com (Niraj Sorathiya)
Date: Sun, 22 Mar 2015 23:59:53 +0530
Subject: [openssl-users] JAR file of openssl source code.
Message-ID: <CAFT0Dp0p+yePgGNUb5ZZGXFpY4DQZ3em0uPmuH_grpgx4m-K=g@mail.gmail.com>

Hi,

Thanks Matt and  jar file of openssl source code is available  ?
I searched a lot but didn't get.

Regards,
Niraj.
On 22-Mar-2015 8:01 PM, "Matt Caswell" <matt at openssl.org> wrote:

>
>
> On 22/03/15 04:14, Niraj Sorathiya wrote:
> > Hi,
> >
> > Can anyone tell me starting point or location of main method in openssl
> > source code which starts openssl command line toolkit ?
> >
>
> Hi Niraj
>
> "main" is located in apps/openssl.c
>
> 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/20150322/b421f6c3/attachment-0001.html>

From amarendra.godbole at gmail.com  Sun Mar 22 19:20:16 2015
From: amarendra.godbole at gmail.com (ag@gmail)
Date: Sun, 22 Mar 2015 12:20:16 -0700
Subject: [openssl-users] JAR file of openssl source code.
In-Reply-To: <CAFT0Dp0p+yePgGNUb5ZZGXFpY4DQZ3em0uPmuH_grpgx4m-K=g@mail.gmail.com>
References: <CAFT0Dp0p+yePgGNUb5ZZGXFpY4DQZ3em0uPmuH_grpgx4m-K=g@mail.gmail.com>
Message-ID: <FEC63350-5E34-48DE-8F21-89A0BD19654C@gmail.com>

RTFM.

-Amarendra

--
sent via 100% recycled electrons from my mobile command center.

> On Mar 22, 2015, at 11:29 AM, Niraj Sorathiya <nirajsorathiya101 at gmail.com> wrote:
> 
> Hi,
> 
> Thanks Matt and  jar file of openssl source code is available  ? 
> I searched a lot but didn't get.
> 
> Regards,
> Niraj.
> 
>> On 22-Mar-2015 8:01 PM, "Matt Caswell" <matt at openssl.org> wrote:
>> 
>> 
>> On 22/03/15 04:14, Niraj Sorathiya wrote:
>> > Hi,
>> >
>> > Can anyone tell me starting point or location of main method in openssl
>> > source code which starts openssl command line toolkit ?
>> >
>> 
>> Hi Niraj
>> 
>> "main" is located in apps/openssl.c
>> 
>> Matt
>> _______________________________________________
>> 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/20150322/e1ec50e9/attachment.html>

From h15234 at mailas.com  Sun Mar 22 19:34:52 2015
From: h15234 at mailas.com (h15234 at mailas.com)
Date: Sun, 22 Mar 2015 12:34:52 -0700
Subject: [openssl-users] JAR file of openssl source code.
In-Reply-To: <FEC63350-5E34-48DE-8F21-89A0BD19654C@gmail.com>
References: <CAFT0Dp0p+yePgGNUb5ZZGXFpY4DQZ3em0uPmuH_grpgx4m-K=g@mail.gmail.com>
 <FEC63350-5E34-48DE-8F21-89A0BD19654C@gmail.com>
Message-ID: <1427052892.4128234.243716914.3E6E4B27@webmail.messagingengine.com>



On Sun, Mar 22, 2015, at 12:20 PM, ag at gmail wrote:
> RTFM.
> 
> -Amarendra

Is it really so hard to keep it civil, and not go out of your way to be a jerk?  If you don't like the OPs question, don't bother with it.

From marquess at openssl.com  Sun Mar 22 19:50:23 2015
From: marquess at openssl.com (Steve Marquess)
Date: Sun, 22 Mar 2015 15:50:23 -0400
Subject: [openssl-users] SP800-90 DRBG in OpenSSL FIPS 140 for SP800-90A?
In-Reply-To: <550DBCEF.6070906@fosiao.com>
References: <550DBCEF.6070906@fosiao.com>
Message-ID: <550F1CFF.6020503@openssl.com>

On 03/21/2015 02:48 PM, xxiao8 wrote:
> At the moment OpenSSL FIPS validation supports ANSI X9.31 with AES128
> for RNG, however it will be outdated in 2015.
> 
> Another alternative RNG in OpenSSL FIPS is SP800-90 DRBG, however the
> new requirement is to use DRBG per SP800-90A.
> 
> Are the DRBGs in SP800-90/OpenSSL-FIPS-2.0.9 the same as what SP800-90A
> requires? Otherwise how can OpenSSL 2.0 FIPS be used in any new
> validations?

The OpenSSL FIPS Object Module implements all three extant DRBGs (Dual
EC DRBG has been removed). The DRBGs are noted in the Security Policy
document:

  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf

which is worth referencing for any "does the OpenSSL FIPS Object Module
have X" questions.

-Steve M.

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

From pl at artisanlogiciel.net  Sun Mar 22 19:23:27 2015
From: pl at artisanlogiciel.net (pl)
Date: Sun, 22 Mar 2015 20:23:27 +0100
Subject: [openssl-users] JAR file of openssl source code.
In-Reply-To: <CAFT0Dp0p+yePgGNUb5ZZGXFpY4DQZ3em0uPmuH_grpgx4m-K=g@mail.gmail.com>
References: <CAFT0Dp0p+yePgGNUb5ZZGXFpY4DQZ3em0uPmuH_grpgx4m-K=g@mail.gmail.com>
Message-ID: <550F16AF.3060809@artisanlogiciel.net>

On 22/03/2015 19:29, Niraj Sorathiya wrote:
>
> Hi,
>
> Thanks Matt and  jar file of openssl source code is available  ?
> I searched a lot but didn't get.
>
> Regards,
> Niraj.
>
> On 22-Mar-2015 8:01 PM, "Matt Caswell" <matt at openssl.org 
> <mailto:matt at openssl.org>> wrote:
>
>
>
>     On 22/03/15 04:14, Niraj Sorathiya wrote:
>     > Hi,
>     >
>     > Can anyone tell me starting point or location of main method in
>     openssl
>     > source code which starts openssl command line toolkit ?
>     >
>
>     Hi Niraj
>
>     "main" is located in apps/openssl.c
>
>     Matt
>     _______________________________________________
>     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

http://wiki.openssl.org/index.php/Compilation_and_Installation#Retrieve_source_code

It is a git clone, not a jar since jar are mostly for java based 
projects, openssl is C code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150322/c87e8c4d/attachment.html>

From Alex.Samad at yieldbroker.com  Sun Mar 22 22:05:30 2015
From: Alex.Samad at yieldbroker.com (Alex Samad - Yieldbroker)
Date: Sun, 22 Mar 2015 22:05:30 +0000
Subject: [openssl-users] question about resigning a certificate
References: <A3FB5D9FD28C50429DF7692DC31054E655391335@DC1INTADCW8201.yieldbroker.com>
 <55088565.8060505@wisemo.com> 
Message-ID: <A3FB5D9FD28C50429DF7692DC31054E655397C1A@DC1INTADCW8201.yieldbroker.com>

Hi

Is this the right mailing list to ask this question ?

Can somebody suggest a better ML

Thanks


From: Alex Samad - Yieldbroker
Sent: Wednesday, 18 March 2015 2:21 PM
To: openssl-users at openssl.org
Subject: RE: [openssl-users] question about resigning a certificate

Hi

I have done that and compared the output with diff


The only differences are
Serial number
Signature algo
Comment
Signature.

Alex

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jakob Bohm
Sent: Wednesday, 18 March 2015 6:50 AM
To: openssl-users at openssl.org<mailto:openssl-users at openssl.org>
Subject: Re: [openssl-users] question about resigning a certificate

On 16/03/2015 02:46, Alex Samad - Yieldbroker wrote:

Hi



I had a sha1 signed CA and I issued other  identity and CA certificates from this CA.



With the deprecation of sha1 coming, I resigned my original CA (self signed) as sha512, with the same creation and expiry dates. I believe the only thing changed was the signature and serial number.



But when I go to verify older certs that were signed by the original CA (the sha1 signed one), they are no longer valid.



I thought if I used the same private and public key I should be okay. I thought the only relevant issue was the issuer field and that the CA keys where the same . Was I wrong.



Alex
Run openssl x509 -noout -text -in OneOfYourIssuedCerts.pem | more

Look at what aspects of your CA are mentioned.  For example,
does it include the "X509v3 Authority Key Identifier"
extension, and if so, which fields from the CA cert are
included?



Enjoy



Jakob

--

Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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/20150322/4f0c0cdb/attachment-0001.html>

From nirajsorathiya101 at gmail.com  Mon Mar 23 05:31:28 2015
From: nirajsorathiya101 at gmail.com (Niraj Sorathiya)
Date: Mon, 23 Mar 2015 11:01:28 +0530
Subject: [openssl-users] JAR file of openssl source code.
In-Reply-To: <550F16AF.3060809@artisanlogiciel.net>
References: <CAFT0Dp0p+yePgGNUb5ZZGXFpY4DQZ3em0uPmuH_grpgx4m-K=g@mail.gmail.com>
 <550F16AF.3060809@artisanlogiciel.net>
Message-ID: <CAFT0Dp0TCqfFGpYeyB1bhUJ3F0DM_ZnFs7WW-xejfJnJwL26NQ@mail.gmail.com>

Hi,

I was trying to  use openssl with java that's why I asked about jar file
for it.

I know source code is available in c.

Thanks,
Niraj.
On 23-Mar-2015 1:23 AM, "pl" <pl at artisanlogiciel.net> wrote:

>  On 22/03/2015 19:29, Niraj Sorathiya wrote:
>
> Hi,
>
> Thanks Matt and  jar file of openssl source code is available  ?
> I searched a lot but didn't get.
>
> Regards,
> Niraj.
> On 22-Mar-2015 8:01 PM, "Matt Caswell" <matt at openssl.org> wrote:
>
>>
>>
>> On 22/03/15 04:14, Niraj Sorathiya wrote:
>> > Hi,
>> >
>> > Can anyone tell me starting point or location of main method in openssl
>> > source code which starts openssl command line toolkit ?
>> >
>>
>> Hi Niraj
>>
>> "main" is located in apps/openssl.c
>>
>> Matt
>> _______________________________________________
>> 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
>
>
>
> http://wiki.openssl.org/index.php/Compilation_and_Installation#Retrieve_source_code
>
> It is a git clone, not a jar since jar are mostly for java based projects,
> openssl is C code.
>
> _______________________________________________
> 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/20150323/a57a0baa/attachment.html>

From jb-openssl at wisemo.com  Mon Mar 23 05:56:54 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 23 Mar 2015 06:56:54 +0100
Subject: [openssl-users] overriding v3 extensions
In-Reply-To: <550DC6FC.2020608@gmx.net>
References: <550DC6FC.2020608@gmx.net>
Message-ID: <550FAB26.2090600@wisemo.com>

On 21/03/2015 20:31, Thomas Tanner wrote:
> Hello,
>
> I'd like to set individual v3 extensions (in particular subjectAltname)
> when signing certificate requests (CSR) and use CA defaults for the
> other extensions.
> Is it possible to achieve this without passing the complete list of
> extensions for the certificate via -config or -extfile ?
>
> Example:
> I have a certificate request with subj=/CN=foo/emailAddress=foo at bar.com/
> and subjectAltname=email:foo at bar.com,DNS:bar.com
> and a default section for extensions v3_ext in openssl.cnf
> (authorityInfoAccess etc).
> I can change the subject of the CSR using "openssl req -subj newsubj".
> However, changing the extensions isn't that easy:
>
> I have tried to change the subjectAltname of the CSR to no avail with
> "openssl req -config extcfg -reqexts ext" with extcfg:
> [ext]
> subjAltname=newaltname
>
> If this was working, I would have added copy_extensions=copy in
> openssl.cnf and removed subjectAltname from the v3_ext section,
> so that subjectAltName would be copied from the modified CSR and merged
> with the defaults.
>
> It seems I need copy the whole v3_ext section from openssl.cnf, replace
> subjectAltname with the desired value and run "openssl ca -extfile
> extcfg -extensions v3_ext"
Assuming that you meant "openssl req"

You need to copy the relevant request extensions (not
certificate extensions) section from openssl.cnf, along
with the 5 other request related sections (globals,
[new_oids], [req], [req_attributes] and
[req_distinguished_name]).  In practice, you can set up
a template file that simply ends with the [v3_req] section
(containing only "basicConstraings = CA:FALSE"), then
simply append the desired extensions to a copy, something
like this:

( cat openssl_req_tpl.cnf
echo keyUsage = ...
echo extendedKeyUsage = ...
echo nsCertType = ...
echo subjectAltName = @alt_names
echo [alt_names]
echo DNS.0 = ...
echo DNS.1 = ...
...
) > temp_req.cnf
openssl req -config temp_req.cnf -new ...

On Windows simply change the first line to
( type openssl_req_tpl.cnf


>
> Is there any other solution that does not require extracting v3_ext from
> openssl.cnf?
See above for my recipe, which doesn't reference the
computers local "openssl.cnf" (which probably contains
junk from whatever installed openssl), but essentially
the answer is no.


As for the original problem of configuring an openssl-based
ca to copy some attributes from the incoming request, and
others from its own list of mandatory values, this is more
tricky, and I don't currently have a good solution.

Note in particular that the CA doesn't have a trusted copy
of the requestors config file, just the digitally signed
binary data in the request.

Possible solutions:

a) Display (with
     openssl req -noout -text -in somefile.req
) all the data in the request when prompting the CA
operator to accept or deny the signing request, then
just use "copy_extensions = copy" .  Also include any
mandatory extension values in the CA's openssl.cnf
(those will override the values in the request),
however there seems to be no config option to specify
a list of acceptable extensions or even a list of
extensions to not include at all.

b) Write a complex script which parses the output from
"openssl req -noout -text -in somefile.req" and writes
the acceptable extensions to a temporary CA config
file.  This is going to be hard.

c) Use the source code of "openssl ca" (apps/ca.c) to
create an enhanced ca app which has the missing feature.



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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 jb-openssl at wisemo.com  Mon Mar 23 06:27:04 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 23 Mar 2015 07:27:04 +0100
Subject: [openssl-users] JAR file of openssl source code.
In-Reply-To: <CAFT0Dp0TCqfFGpYeyB1bhUJ3F0DM_ZnFs7WW-xejfJnJwL26NQ@mail.gmail.com>
References: <CAFT0Dp0p+yePgGNUb5ZZGXFpY4DQZ3em0uPmuH_grpgx4m-K=g@mail.gmail.com>
 <550F16AF.3060809@artisanlogiciel.net>
 <CAFT0Dp0TCqfFGpYeyB1bhUJ3F0DM_ZnFs7WW-xejfJnJwL26NQ@mail.gmail.com>
Message-ID: <550FB238.8070703@wisemo.com>

The most common Java interface for openssl is to use an
openssllibrary wrapper as the JNI backend behind the
Java CryptographyExtensions (JCE).  For instance this
is how Android implements JCE.

Curiously Android returns the OID from the JCE name()
method, and then end up having to add alias names such
as"1.3.14.3.2.26with1.2.840.113549.1.1.1"=
"1.3.14.3.2.29" wherethey should have been processing
"sha1WithRsaEncryption" whichis already the name of
"1.3.14.2.2.29"

On 23/03/2015 06:31, Niraj Sorathiya wrote:
>
> Hi,
>
> I was trying to  use openssl with java that's why I asked about jar 
> file for it.
>
> I know source code is available in c.
>
> Thanks,
> Niraj.
>
> On 23-Mar-2015 1:23 AM, "pl" <pl at artisanlogiciel.net 
> <mailto:pl at artisanlogiciel.net>> wrote:
>
>     On 22/03/2015 19:29, Niraj Sorathiya wrote:
>>
>>     Hi,
>>
>>     Thanks Matt and  jar file of openssl source code is available  ?
>>     I searched a lot but didn't get.
>>
>>     Regards,
>>     Niraj.
>>
>>     On 22-Mar-2015 8:01 PM, "Matt Caswell" <matt at openssl.org
>>     <mailto:matt at openssl.org>> wrote:
>>
>>
>>
>>         On 22/03/15 04:14, Niraj Sorathiya wrote:
>>         > Hi,
>>         >
>>         > Can anyone tell me starting point or location of main
>>         method in openssl
>>         > source code which starts openssl command line toolkit ?
>>         >
>>
>>         Hi Niraj
>>
>>         "main" is located in apps/openssl.c
>>
>     http://wiki.openssl.org/index.php/Compilation_and_Installation#Retrieve_source_code
>
>     It is a git clone, not a jar since jar are mostly for java based
>     projects, openssl is C code.
>
Actually, it is a .tar.gz file unless working with bleeding
edge stuff.

The .tar.gz is signed with gpg not PKCS#7 like jar files.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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 jb-openssl at wisemo.com  Mon Mar 23 06:33:31 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 23 Mar 2015 07:33:31 +0100
Subject: [openssl-users] question about resigning a certificate
In-Reply-To: <A3FB5D9FD28C50429DF7692DC31054E655394559@DC1INTADCW8201.yieldbroker.com>
References: <A3FB5D9FD28C50429DF7692DC31054E655391335@DC1INTADCW8201.yieldbroker.com>
 <55088565.8060505@wisemo.com>
 <A3FB5D9FD28C50429DF7692DC31054E655394559@DC1INTADCW8201.yieldbroker.com>
Message-ID: <550FB3BB.8020802@wisemo.com>

(Resending because I accidentally sent this
reply from the wrong addresslast week, and
yes, this is the correct mailing list).

No, don't dump the CA certificate.  Dump one
of the *old* *issued*certificates.

There is nothing to diff against, you need to
see in what ways the *old**issued*
certificates referred to the *old* CA
certificate, and then makesure those values
remain the same in the new CA certificate.

On 18/03/2015 04:20, Alex Samad - Yieldbroker wrote:
>
> Hi
>
> I have done that and compared the output with diff
>
> The only differences are
>
> Serial number
>
> Signature algo
>
> Comment
>
> Signature.
>
> Alex
>
> *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On 
> Behalf Of *Jakob Bohm
> *Sent:* Wednesday, 18 March 2015 6:50 AM
> *To:* openssl-users at openssl.org
> *Subject:* Re: [openssl-users] question about resigning a certificate
>
> On 16/03/2015 02:46, Alex Samad - Yieldbroker wrote:
>
>     Hi
>
>       
>
>     I had a sha1 signed CA and I issued other  identity and CA certificates from this CA.
>
>       
>
>     With the deprecation of sha1 coming, I resigned my original CA (self signed) as sha512, with the same creation and expiry dates. I believe the only thing changed was the signature and serial number.
>
>       
>
>     But when I go to verify older certs that were signed by the original CA (the sha1 signed one), they are no longer valid.
>
>       
>
>     I thought if I used the same private and public key I should be okay. I thought the only relevant issue was the issuer field and that the CA keys where the same . Was I wrong.
>
>       
>
>     Alex
>
> Run openssl x509 -noout -text -in OneOfYourIssuedCerts.pem | more
>
> Look at what aspects of your CA are mentioned.  For example,
> does it include the "X509v3 Authority Key Identifier"
> extension, and if so, which fields from the CA cert are
> included?
>



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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 noloader at gmail.com  Mon Mar 23 08:44:41 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 23 Mar 2015 01:44:41 -0700
Subject: [openssl-users] ChaCha20/Poly1305 in OpenSSL?
In-Reply-To: <54344222.4040301@openssl.org>
References: <CAH8yC8=nh6GOVNineTo-9Jh6-0AsqDpaH+ewUDJyzduwWV-gpw@mail.gmail.com>
 <CADMhe6cXw9r3O2CAR467GrfPkoGYS_=UqFSwa6S4bw_MiqDxtQ@mail.gmail.com>
 <CAH8yC8kGpXDZ5dnqX2UYNkBnDZj2cCRoBLwxDzWLCeYni5kjhQ@mail.gmail.com>
 <54344222.4040301@openssl.org>
Message-ID: <CAH8yC8=Vv8Ht251_kjGNZd0wQ35vb2StphpTe5KDYbHxyG+4jg@mail.gmail.com>

On Tue, Oct 7, 2014 at 12:42 PM, Matt Caswell <matt at openssl.org> wrote:
>
>
> On 07/10/14 18:07, Jeffrey Walton wrote:
>>>> But I have not been able to find its trail:
>>>>
>>>>     $ cd openssl-git
>>>>     $ git pull
>>>>     Already up-to-date.
>>>>     $ grep -R -i chacha *
>>>>     $ grep -R -i poly1305 *
>>>>     $
>>>>
>>>> Where are the new cipher suites located in OpenSSL?
>>>
>>> $ git checkout 1.0.2-aead
>>>
>>> They are there... Just not merged into mainline. I would be also
>>> interested in knowing whether there is any ETA for that.
>>
>> I just checked the dev branch again, and I did not see them.
>
> The particular branch in question is not current:
> http://marc.info/?l=openssl-dev&m=140189910129029&w=2
>
Sorry to dig up an old thread...

I've been using 1.0.2 lately, and the cipher suites are not available
(or do not appear to be available):

$ /usr/local/ssl/darwin/bin/openssl ciphers | grep -i chacha
$ /usr/local/ssl/darwin/bin/openssl ciphers | grep -i poly
$ /usr/local/ssl/darwin/bin/openssl version
OpenSSL 1.0.2a 19 Mar 2015

Any ideas when these will make it into OpenSSL?

From jaya.nageswar at gmail.com  Mon Mar 23 10:50:29 2015
From: jaya.nageswar at gmail.com (Jaya Nageswar)
Date: Mon, 23 Mar 2015 16:20:29 +0530
Subject: [openssl-users] Need help on CVE-2015-0292
Message-ID: <CAGdAg4fGp09CsNwmy5TOa_hdi9CDYc264X4jepjjuuk0LYbUFA@mail.gmail.com>

Hi All,

As per openssl advisory http://www.openssl.org/news/secadv_20150319.txt,
the vulnerability CVE-2015-0292 is fixed in 0.9.8 za. Is this correct or
typo? Can some one point me to the code changes related to this fix on gib
hub. I really could not find the code changes related to the commit
9febee0272 (0.9.8) as per the advisory.

Appreciate your help on this.

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

From matt at openssl.org  Mon Mar 23 10:55:40 2015
From: matt at openssl.org (Matt Caswell)
Date: Mon, 23 Mar 2015 10:55:40 +0000
Subject: [openssl-users] Need help on CVE-2015-0292
In-Reply-To: <CAGdAg4fGp09CsNwmy5TOa_hdi9CDYc264X4jepjjuuk0LYbUFA@mail.gmail.com>
References: <CAGdAg4fGp09CsNwmy5TOa_hdi9CDYc264X4jepjjuuk0LYbUFA@mail.gmail.com>
Message-ID: <550FF12C.9090501@openssl.org>



On 23/03/15 10:50, Jaya Nageswar wrote:
> Hi All,
> 
> As per openssl advisory http://www.openssl.org/news/secadv_20150319.txt,
> the vulnerability CVE-2015-0292 is fixed in 0.9.8 za. Is this correct or
> typo?

It is correct. As the advisory states this is a historic bug that was
fixed in previous versions but had not appeared in a security advisory
until now.

> Can some one point me to the code changes related to this fix on
> gib hub. I really could not find the code changes related to the commit
> 9febee0272 (0.9.8) as per the advisory.
> 

https://github.com/openssl/openssl/commit/9febee0272

Matt

From stevenx.linsell at intel.com  Mon Mar 23 11:54:15 2015
From: stevenx.linsell at intel.com (Linsell, StevenX)
Date: Mon, 23 Mar 2015 11:54:15 +0000
Subject: [openssl-users] Failure using ECDH-RSA-AES256-SHA with ssl3 on
	Master Branch
Message-ID: <BC6016DA3A27864486295F6D844656F132ADF1E7@irsmsx105.ger.corp.intel.com>

On 20/0315 15:51, Matt Caswell wrote:
>On 20/03/15 12:44, Linsell, StevenX wrote:
>> On Thu, Mar 19, 2015, Steve Linsell wrote:
>> > 
>> Following further testing I see identical failures in the master branch using the \
>> following cipher/protocol combinations: 
>> ECDH-ECDSA-AES128-SHA      ssl3 
>> ECDH-ECDSA-AES256-SHA      ssl3            
>> ECDH-ECDSA-DES-CBC3-SHA    ssl3          
>> ECDH-ECDSA-RC4-SHA         ssl3               
>> ECDH-RSA-AES128-SHA        ssl3                    
>> ECDH-RSA-AES256-SHA        ssl3         
>> ECDH-RSA-DES-CBC3-SHA      ssl3          
>> ECDH-RSA-RC4-SHA           ssl3                
>> ECDHE-ECDSA-AES128-SHA     ssl3         
>> ECDHE-ECDSA-AES256-SHA     ssl3          
>> ECDHE-ECDSA-DES-CBC3-SHA   ssl3                
>> ECDHE-ECDSA-RC4-SHA        ssl3             
>> 

>Hi Steve
>
>Looks like a bug. Try the attached patch. Let me know how you get on.
>
>Thanks
>
>Matt

Thanks Matt that worked great.
I've retested all the above cipher/protocol combinations and all now pass with the fix in place.

Just to close out my understanding.
Within the tls1_check_ec_key function:
The first iteration round the loop is checking that the curve within the certificate matches one of the curves in the list of curves that this build of OpenSSL supports.
The second iteration round the loop is checking the curve within the certificate matches one of the curves in the list of curves sent from the peer via TLS extensions.
In the case of the cipher/protocol combinations above we are using ssl3 which does not support TLS extensions so the second list will always be empty.
As Viktor states RFC 4492 says if the client sends no TLS extension containing the curves supported then the server can choose any supported curve. So your fix is to continue when we reach the second iteration if there are no curves in the second list rather than flag an error.

Thanks again,

Steve Linsell                                     Intel Shannon DCG/CID Software Development Team
Stevenx.Linsell at intel.com




--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.



From matt at openssl.org  Mon Mar 23 13:01:29 2015
From: matt at openssl.org (Matt Caswell)
Date: Mon, 23 Mar 2015 13:01:29 +0000
Subject: [openssl-users] Failure using ECDH-RSA-AES256-SHA with ssl3 on
 Master Branch
In-Reply-To: <BC6016DA3A27864486295F6D844656F132ADF1E7@irsmsx105.ger.corp.intel.com>
References: <BC6016DA3A27864486295F6D844656F132ADF1E7@irsmsx105.ger.corp.intel.com>
Message-ID: <55100EA9.7040407@openssl.org>



On 23/03/15 11:54, Linsell, StevenX wrote:
> On 20/0315 15:51, Matt Caswell wrote:
>> On 20/03/15 12:44, Linsell, StevenX wrote:
>>> On Thu, Mar 19, 2015, Steve Linsell wrote:
>>>>
>>> Following further testing I see identical failures in the master branch using the \
>>> following cipher/protocol combinations: 
>>> ECDH-ECDSA-AES128-SHA      ssl3 
>>> ECDH-ECDSA-AES256-SHA      ssl3            
>>> ECDH-ECDSA-DES-CBC3-SHA    ssl3          
>>> ECDH-ECDSA-RC4-SHA         ssl3               
>>> ECDH-RSA-AES128-SHA        ssl3                    
>>> ECDH-RSA-AES256-SHA        ssl3         
>>> ECDH-RSA-DES-CBC3-SHA      ssl3          
>>> ECDH-RSA-RC4-SHA           ssl3                
>>> ECDHE-ECDSA-AES128-SHA     ssl3         
>>> ECDHE-ECDSA-AES256-SHA     ssl3          
>>> ECDHE-ECDSA-DES-CBC3-SHA   ssl3                
>>> ECDHE-ECDSA-RC4-SHA        ssl3             
>>>
> 
>> Hi Steve
>>
>> Looks like a bug. Try the attached patch. Let me know how you get on.
>>
>> Thanks
>>
>> Matt
> 
> Thanks Matt that worked great.
> I've retested all the above cipher/protocol combinations and all now pass with the fix in place.
> 
> Just to close out my understanding.
> Within the tls1_check_ec_key function:
> The first iteration round the loop is checking that the curve within the certificate matches one of the curves in the list of curves that this build of OpenSSL supports.
> The second iteration round the loop is checking the curve within the certificate matches one of the curves in the list of curves sent from the peer via TLS extensions.
> In the case of the cipher/protocol combinations above we are using ssl3 which does not support TLS extensions so the second list will always be empty.
> As Viktor states RFC 4492 says if the client sends no TLS extension containing the curves supported then the server can choose any supported curve. So your fix is to continue when we reach the second iteration if there are no curves in the second list rather than flag an error.

Essentially yes, although with the refinement that the first iteration
checks the list of available curves for this SSL. This may or may not be
the same as the complete list of curves available in this *build* (e.g.
if SSL_set1_curves_list() has been used).

Matt


From openssl-users at dukhovni.org  Mon Mar 23 13:45:05 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 23 Mar 2015 13:45:05 +0000
Subject: [openssl-users] Failure using ECDH-RSA-AES256-SHA with ssl3 on
 Master Branch
In-Reply-To: <55100EA9.7040407@openssl.org>
References: <BC6016DA3A27864486295F6D844656F132ADF1E7@irsmsx105.ger.corp.intel.com>
 <55100EA9.7040407@openssl.org>
Message-ID: <20150323134505.GC9387@mournblade.imrryr.org>

On Mon, Mar 23, 2015 at 01:01:29PM +0000, Matt Caswell wrote:

> > As Viktor states RFC 4492 says if the client sends no TLS extension
> > containing the curves supported then the server can choose any supported
> > curve. So your fix is to continue when we reach the second iteration if
> > there are no curves in the second list rather than flag an error.
> 
> Essentially yes, although with the refinement that the first iteration
> checks the list of available curves for this SSL. This may or may not be
> the same as the complete list of curves available in this *build* (e.g.
> if SSL_set1_curves_list() has been used).

I would expect that a client sending an *empty* list of supported
curves means no curves are supported by the client, and the server
would not enable EC.  The case where the server is free to choose
any curve is presumably when the client does not send a supported
curves extension at all.

-- 
	Viktor.

From matt at openssl.org  Mon Mar 23 13:48:52 2015
From: matt at openssl.org (Matt Caswell)
Date: Mon, 23 Mar 2015 13:48:52 +0000
Subject: [openssl-users] Failure using ECDH-RSA-AES256-SHA with ssl3 on
 Master Branch
In-Reply-To: <20150323134505.GC9387@mournblade.imrryr.org>
References: <BC6016DA3A27864486295F6D844656F132ADF1E7@irsmsx105.ger.corp.intel.com>
 <55100EA9.7040407@openssl.org> <20150323134505.GC9387@mournblade.imrryr.org>
Message-ID: <551019C4.7030901@openssl.org>



On 23/03/15 13:45, Viktor Dukhovni wrote:
> On Mon, Mar 23, 2015 at 01:01:29PM +0000, Matt Caswell wrote:
> 
>>> As Viktor states RFC 4492 says if the client sends no TLS extension
>>> containing the curves supported then the server can choose any supported
>>> curve. So your fix is to continue when we reach the second iteration if
>>> there are no curves in the second list rather than flag an error.
>>
>> Essentially yes, although with the refinement that the first iteration
>> checks the list of available curves for this SSL. This may or may not be
>> the same as the complete list of curves available in this *build* (e.g.
>> if SSL_set1_curves_list() has been used).
> 
> I would expect that a client sending an *empty* list of supported
> curves means no curves are supported by the client, and the server
> would not enable EC.  The case where the server is free to choose
> any curve is presumably when the client does not send a supported
> curves extension at all.

It is not valid to send an empty list. If the client uses the extension
then they *must* set at least one curve. Therefore if the client list is
empty then it can only be because the extension was not used.

Matt


From nirajsorathiya101 at gmail.com  Mon Mar 23 14:13:37 2015
From: nirajsorathiya101 at gmail.com (Niraj Sorathiya)
Date: Mon, 23 Mar 2015 19:43:37 +0530
Subject: [openssl-users] JAR file of openssl source code.
In-Reply-To: <550FB238.8070703@wisemo.com>
References: <CAFT0Dp0p+yePgGNUb5ZZGXFpY4DQZ3em0uPmuH_grpgx4m-K=g@mail.gmail.com>
 <550F16AF.3060809@artisanlogiciel.net>
 <CAFT0Dp0TCqfFGpYeyB1bhUJ3F0DM_ZnFs7WW-xejfJnJwL26NQ@mail.gmail.com>
 <550FB238.8070703@wisemo.com>
Message-ID: <CAFT0Dp2fQYV+HQFrEK_zjqRQ7tJEHxmBsBBz48A2KoUYFCs_fA@mail.gmail.com>

Thanks Jakob.
On 23-Mar-2015 11:58 AM, "Jakob Bohm" <jb-openssl at wisemo.com> wrote:

> The most common Java interface for openssl is to use an
> openssllibrary wrapper as the JNI backend behind the
> Java CryptographyExtensions (JCE).  For instance this
> is how Android implements JCE.
>
> Curiously Android returns the OID from the JCE name()
> method, and then end up having to add alias names such
> as"1.3.14.3.2.26with1.2.840.113549.1.1.1"=
> "1.3.14.3.2.29" wherethey should have been processing
> "sha1WithRsaEncryption" whichis already the name of
> "1.3.14.2.2.29"
>
> On 23/03/2015 06:31, Niraj Sorathiya wrote:
>
>>
>> Hi,
>>
>> I was trying to  use openssl with java that's why I asked about jar file
>> for it.
>>
>> I know source code is available in c.
>>
>> Thanks,
>> Niraj.
>>
>> On 23-Mar-2015 1:23 AM, "pl" <pl at artisanlogiciel.net <mailto:
>> pl at artisanlogiciel.net>> wrote:
>>
>>     On 22/03/2015 19:29, Niraj Sorathiya wrote:
>>
>>>
>>>     Hi,
>>>
>>>     Thanks Matt and  jar file of openssl source code is available  ?
>>>     I searched a lot but didn't get.
>>>
>>>     Regards,
>>>     Niraj.
>>>
>>>     On 22-Mar-2015 8:01 PM, "Matt Caswell" <matt at openssl.org
>>>     <mailto:matt at openssl.org>> wrote:
>>>
>>>
>>>
>>>         On 22/03/15 04:14, Niraj Sorathiya wrote:
>>>         > Hi,
>>>         >
>>>         > Can anyone tell me starting point or location of main
>>>         method in openssl
>>>         > source code which starts openssl command line toolkit ?
>>>         >
>>>
>>>         Hi Niraj
>>>
>>>         "main" is located in apps/openssl.c
>>>
>>>      http://wiki.openssl.org/index.php/Compilation_and_
>> Installation#Retrieve_source_code
>>
>>     It is a git clone, not a jar since jar are mostly for java based
>>     projects, openssl is C code.
>>
>>  Actually, it is a .tar.gz file unless working with bleeding
> edge stuff.
>
> The .tar.gz is signed with gpg not PKCS#7 like jar files.
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150323/a2e0108d/attachment.html>

From jb-openssl at wisemo.com  Mon Mar 23 14:19:11 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 23 Mar 2015 15:19:11 +0100
Subject: [openssl-users] Failure using ECDH-RSA-AES256-SHA with ssl3 on
 Master Branch
In-Reply-To: <551019C4.7030901@openssl.org>
References: <BC6016DA3A27864486295F6D844656F132ADF1E7@irsmsx105.ger.corp.intel.com>
 <55100EA9.7040407@openssl.org> <20150323134505.GC9387@mournblade.imrryr.org>
 <551019C4.7030901@openssl.org>
Message-ID: <551020DF.3000005@wisemo.com>

On 23/03/2015 14:48, Matt Caswell wrote:
> On 23/03/15 13:45, Viktor Dukhovni wrote:
>> On Mon, Mar 23, 2015 at 01:01:29PM +0000, Matt Caswell wrote:
>>
>>>> As Viktor states RFC 4492 says if the client sends no TLS extension
>>>> containing the curves supported then the server can choose any supported
>>>> curve. So your fix is to continue when we reach the second iteration if
>>>> there are no curves in the second list rather than flag an error.
>>> Essentially yes, although with the refinement that the first iteration
>>> checks the list of available curves for this SSL. This may or may not be
>>> the same as the complete list of curves available in this *build* (e.g.
>>> if SSL_set1_curves_list() has been used).
>> I would expect that a client sending an *empty* list of supported
>> curves means no curves are supported by the client, and the server
>> would not enable EC.  The case where the server is free to choose
>> any curve is presumably when the client does not send a supported
>> curves extension at all.
> It is not valid to send an empty list. If the client uses the extension
> then they *must* set at least one curve. Therefore if the client list is
> empty then it can only be because the extension was not used.
Is sending an empty list technically impossible in the
protocol, or just not currently permitted.  If it is
just not currently permitted then one needs to contemplate
whya client would (in a future "update" RFC for a backwards
compatible TLS version) beallowed to send an empty list
rather than simply not proposing any ECC cipher codes.

One possible interpretation could be "Not only don't I
support any of the currentlypublished ECC ciphers, I will
not accept ECC signatures in the cert chain either".

Another possible interpretation could be "I support arbitrary
curves, both thoseenumerated in the standards and those
explicitly specified".

The second interpretation happens to match what the proposed
patchdoes implicitly, while the first interpretation does not.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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  Mon Mar 23 14:35:22 2015
From: matt at openssl.org (Matt Caswell)
Date: Mon, 23 Mar 2015 14:35:22 +0000
Subject: [openssl-users] Failure using ECDH-RSA-AES256-SHA with ssl3 on
 Master Branch
In-Reply-To: <551020DF.3000005@wisemo.com>
References: <BC6016DA3A27864486295F6D844656F132ADF1E7@irsmsx105.ger.corp.intel.com>
 <55100EA9.7040407@openssl.org> <20150323134505.GC9387@mournblade.imrryr.org>
 <551019C4.7030901@openssl.org> <551020DF.3000005@wisemo.com>
Message-ID: <551024AA.7030607@openssl.org>



On 23/03/15 14:19, Jakob Bohm wrote:
> On 23/03/2015 14:48, Matt Caswell wrote:
>> On 23/03/15 13:45, Viktor Dukhovni wrote:
>>> On Mon, Mar 23, 2015 at 01:01:29PM +0000, Matt Caswell wrote:
>>>
>>>>> As Viktor states RFC 4492 says if the client sends no TLS extension
>>>>> containing the curves supported then the server can choose any
>>>>> supported
>>>>> curve. So your fix is to continue when we reach the second
>>>>> iteration if
>>>>> there are no curves in the second list rather than flag an error.
>>>> Essentially yes, although with the refinement that the first iteration
>>>> checks the list of available curves for this SSL. This may or may
>>>> not be
>>>> the same as the complete list of curves available in this *build* (e.g.
>>>> if SSL_set1_curves_list() has been used).
>>> I would expect that a client sending an *empty* list of supported
>>> curves means no curves are supported by the client, and the server
>>> would not enable EC.  The case where the server is free to choose
>>> any curve is presumably when the client does not send a supported
>>> curves extension at all.
>> It is not valid to send an empty list. If the client uses the extension
>> then they *must* set at least one curve. Therefore if the client list is
>> empty then it can only be because the extension was not used.
> Is sending an empty list technically impossible in the
> protocol, or just not currently permitted.

The extension is defined in RFC4492 as a list of NamedCurves with at
least one entry in that list:

        struct {
            NamedCurve elliptic_curve_list<1..2^16-1>
        } EllipticCurveList;

It would be technically feasible to send a zero length list (although
that would be in violation of the RFC). If a client did so then OpenSSL
would reject it with a decode error alert.

Matt


From jonetsu at teksavvy.com  Mon Mar 23 14:37:04 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Mon, 23 Mar 2015 10:37:04 -0400
Subject: [openssl-users] FIPS: Which DRBG ?
Message-ID: <752abb047da55d056f95490870eb3507@teksavvy.com>

Hello,

Following on the 'SP800-90 DRBG in OpenSSL FIPS 140 for SP800-90A?' topic, the OpenSSL source code does not seem to mention SP 800-90A.? Only SP 800-90.? So the certifications were made for SP 800-90, is that right ?

Also, does it depend on the application to choose which DRBG and moreover, for regular FIPS uses, does it matter which DRBG is used since they are all approved ?

One more question: is there a way for us to actually know/test which one id used by an application ?? I currently am using a FIPS_post_set_callback() placed in FIPS_mode_set() - can this be useful to identify which DRBG is used ?? Maybe FIPS_drbg_set_callbacks() could be more useful ?

Regards.




From rsalz at akamai.com  Mon Mar 23 14:36:00 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 23 Mar 2015 14:36:00 +0000
Subject: [openssl-users] ChaCha20/Poly1305 in OpenSSL?
In-Reply-To: <CAH8yC8=Vv8Ht251_kjGNZd0wQ35vb2StphpTe5KDYbHxyG+4jg@mail.gmail.com>
References: <CAH8yC8=nh6GOVNineTo-9Jh6-0AsqDpaH+ewUDJyzduwWV-gpw@mail.gmail.com>
 <CADMhe6cXw9r3O2CAR467GrfPkoGYS_=UqFSwa6S4bw_MiqDxtQ@mail.gmail.com>
 <CAH8yC8kGpXDZ5dnqX2UYNkBnDZj2cCRoBLwxDzWLCeYni5kjhQ@mail.gmail.com>
 <54344222.4040301@openssl.org>
 <CAH8yC8=Vv8Ht251_kjGNZd0wQ35vb2StphpTe5KDYbHxyG+4jg@mail.gmail.com>
Message-ID: <759a6b9a9e574a2e8d51150079ac0509@usma1ex-dag1mb2.msg.corp.akamai.com>

It's unlikely to appear in 1.0.2 as it's a new feature.

CloudFlare has posted patches that seem like they would drop in easily, for folks that want to do it; see https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/

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



From quentin.gouchet at gmail.com  Mon Mar 23 14:56:53 2015
From: quentin.gouchet at gmail.com (Q Gct)
Date: Mon, 23 Mar 2015 09:56:53 -0500
Subject: [openssl-users] FIPS: Which DRBG ?
In-Reply-To: <752abb047da55d056f95490870eb3507@teksavvy.com>
References: <752abb047da55d056f95490870eb3507@teksavvy.com>
Message-ID: <CACGCdch30a060EuSfQ-OyzAYh80Sqdam-2UBegUsQT6-hF=ALA@mail.gmail.com>

Hi,

For the second question any DRBG that are approved in FIPS SP 800-90A are
approved for any application. You can chose over tha Hash, HMAC or CTR DRBG
equivalently.

Best regards

Q Gouchet
Le 23 mars 2015 09:38, "jonetsu" <jonetsu at teksavvy.com> a ?crit :

> Hello,
>
> Following on the 'SP800-90 DRBG in OpenSSL FIPS 140 for SP800-90A?' topic,
> the OpenSSL source code does not seem to mention SP 800-90A.  Only SP
> 800-90.  So the certifications were made for SP 800-90, is that right ?
>
> Also, does it depend on the application to choose which DRBG and moreover,
> for regular FIPS uses, does it matter which DRBG is used since they are all
> approved ?
>
> One more question: is there a way for us to actually know/test which one
> id used by an application ?  I currently am using a
> FIPS_post_set_callback() placed in FIPS_mode_set() - can this be useful to
> identify which DRBG is used ?  Maybe FIPS_drbg_set_callbacks() could be
> more useful ?
>
> Regards.
>
>
>
> _______________________________________________
> 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/20150323/7a41b0bd/attachment.html>

From jaya.nageswar at gmail.com  Mon Mar 23 18:19:26 2015
From: jaya.nageswar at gmail.com (Jaya Nageswar)
Date: Mon, 23 Mar 2015 23:49:26 +0530
Subject: [openssl-users] Need help on CVE-2015-0292
In-Reply-To: <550FF12C.9090501@openssl.org>
References: <CAGdAg4fGp09CsNwmy5TOa_hdi9CDYc264X4jepjjuuk0LYbUFA@mail.gmail.com>
 <550FF12C.9090501@openssl.org>
Message-ID: <CAGdAg4cQY7CzCyBf4syte61m80-ogOcrqE75CA-bWTK5Ap2Kyg@mail.gmail.com>

Thanks Matt for a prompt response.

On Mon, Mar 23, 2015 at 4:25 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 23/03/15 10:50, Jaya Nageswar wrote:
> > Hi All,
> >
> > As per openssl advisory http://www.openssl.org/news/secadv_20150319.txt,
> > the vulnerability CVE-2015-0292 is fixed in 0.9.8 za. Is this correct or
> > typo?
>
> It is correct. As the advisory states this is a historic bug that was
> fixed in previous versions but had not appeared in a security advisory
> until now.
>
> > Can some one point me to the code changes related to this fix on
> > gib hub. I really could not find the code changes related to the commit
> > 9febee0272 (0.9.8) as per the advisory.
> >
>
> https://github.com/openssl/openssl/commit/9febee0272
>
> 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/20150323/8374ef4d/attachment.html>

From kevinm at objectivity.com  Mon Mar 23 16:51:53 2015
From: kevinm at objectivity.com (Kevin Moody)
Date: Mon, 23 Mar 2015 16:51:53 +0000
Subject: [openssl-users] openssl 1.0.2a vc++ 9 (VS 2008) 64-bit build failing
Message-ID: <BY1PR0801MB1112E6D5EB39C89D66ECCD3EC90D0@BY1PR0801MB1112.namprd08.prod.outlook.com>

Hi,

My apologies if I missed a post about this already, but I'm seeing the following when running `nmake -f ms\ntdll.mak` in the vc9x64 build of openssl 1.0.2a:

...
Assembling: tmp32dll\aesni-sha256-x86_64.asm
tmp32dll\aesni-sha256-x86_64.asm(109) : error A2006:undefined symbol : __imp_Rtl
VirtualUnwind
tmp32dll\aesni-sha256-x86_64.asm(127) : error A2006:undefined symbol : $L$SEH_be
gin_aesni_cbc_sha256_enc_xop
tmp32dll\aesni-sha256-x86_64.asm(128) : error A2006:undefined symbol : $L$SEH_en
d_aesni_cbc_sha256_enc_xop
tmp32dll\aesni-sha256-x86_64.asm(129) : error A2006:undefined symbol : $L$SEH_in
fo_aesni_cbc_sha256_enc_xop
tmp32dll\aesni-sha256-x86_64.asm(131) : error A2006:undefined symbol : $L$SEH_be
gin_aesni_cbc_sha256_enc_avx
tmp32dll\aesni-sha256-x86_64.asm(132) : error A2006:undefined symbol : $L$SEH_en
d_aesni_cbc_sha256_enc_avx
tmp32dll\aesni-sha256-x86_64.asm(133) : error A2006:undefined symbol : $L$SEH_in
fo_aesni_cbc_sha256_enc_avx
NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio 9.0\VC\BIN
\x86_amd64\ml64.EXE"' : return code '0x1'
Stop.

What's odd is that this has built in my vc9x32, vc10x32, vc10x64, vc11x32, and vc11x64 build configurations.  Just to rule out an environment issue, I built my previous version, 1.0.1g, within this same command prompt.  Any ideas or suggestions as to what might be breaking the VS 2008 64-bit build?  Has anyone seen this?

Obviously, I don't know enough about this project to really debug the build much further.  So, thanks in advance!

Regards,
Kevin


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

From xxiao8 at fosiao.com  Mon Mar 23 18:36:53 2015
From: xxiao8 at fosiao.com (xxiao8)
Date: Mon, 23 Mar 2015 13:36:53 -0500
Subject: [openssl-users] FIPS: Which DRBG ?
In-Reply-To: <mailman.497.1427135085.1333.openssl-users@openssl.org>
References: <mailman.497.1427135085.1333.openssl-users@openssl.org>
Message-ID: <55105D45.606@fosiao.com>

The key issue still remains, are the validated SP800-90 DRBGs the _same_ 
as SP800-90A's DRBGs? If yes then we can probably use Openssl-FIPS with 
SP800-90A, otherwise OpenSSL-FIPS 2.0.9 probably can no longer be used 
for any new validations?

Thanks,
xxiao
---
Hi,

For the second question any DRBG that are approved in FIPS SP 800-90A are
approved for any application. You can chose over tha Hash, HMAC or CTR DRBG
equivalently.

Best regards

Q Gouchet
Le 23 mars 2015 09:38, "jonetsu" <jonetsu at teksavvy.com> a ?crit :

 > Hello,
 >
 > Following on the 'SP800-90 DRBG in OpenSSL FIPS 140 for SP800-90A?' 
topic,
 > the OpenSSL source code does not seem to mention SP 800-90A.  Only SP
 > 800-90.  So the certifications were made for SP 800-90, is that right ?
 >
 > Also, does it depend on the application to choose which DRBG and 
moreover,
 > for regular FIPS uses, does it matter which DRBG is used since they 
are all
 > approved ?
 >
 > One more question: is there a way for us to actually know/test which one
 > id used by an application ?  I currently am using a
 > FIPS_post_set_callback() placed in FIPS_mode_set() - can this be 
useful to
 > identify which DRBG is used ?  Maybe FIPS_drbg_set_callbacks() could be
 > more useful ?
 >
 > Regards.
 >


From julien.kauffmann at freelan.org  Mon Mar 23 18:34:16 2015
From: julien.kauffmann at freelan.org (Julien Kauffmann)
Date: Mon, 23 Mar 2015 14:34:16 -0400
Subject: [openssl-users] =?utf-8?q?Fwd=3A_=5BBUG=5D_Crash_in_PEM_write_fun?=
 =?utf-8?q?ctions_with_generated_EC=5FKEY_on_Windows?=
Message-ID: <3580c3e4c991488cc0f176e450bf67c6@freelan.org>

Hi,

I'm facing a crash (heap corruption) on Windows ever since I updated 
OpenSSL to the version 1.0.2a. The same seems to happen in 1.0.1m.

I'm using Visual Studio 2013. I'm building the x64-static variant of 
OpenSSL like so:

perl Configure VC-WIN64A no-asm 
--prefix=F:\git\openssl_crash\third-party\install\x64
ms\do_win64a
nmake -f ms\nt.mak
nmake -f ms\nt.mak install

My sample code goes as follow:

----- main.cpp -----
#include <iostream>
#include <openssl/crypto.h>
#include <openssl/evp.h>
#include <openssl/err.h>
#include <openssl/pem.h>
#include <openssl/ecdh.h>

int main()
{
OpenSSL_add_all_algorithms();
ERR_load_crypto_strings();

EVP_PKEY_CTX* parameters_context = EVP_PKEY_CTX_new_id(EVP_PKEY_EC, 
NULL);

if (EVP_PKEY_paramgen_init(parameters_context) != 1) { return 1; }
if (EVP_PKEY_CTX_set_ec_paramgen_curve_nid(parameters_context, 
NID_sect571k1) != 1) { return 1; }

EVP_PKEY* cparameters = nullptr;

if (EVP_PKEY_paramgen(parameters_context, &cparameters) != 1) {	return 
1; }

EVP_PKEY_CTX* key_generation_context = EVP_PKEY_CTX_new(cparameters, 
NULL);

if (!key_generation_context) { return 1; }
if (EVP_PKEY_keygen_init(key_generation_context) != 1) { return 1; }

EVP_PKEY* private_key = nullptr;

if (EVP_PKEY_keygen(key_generation_context, &private_key) != 1) { return 
1; }

BIO* bio = BIO_new(BIO_s_mem());
PEM_write_bio_PUBKEY(bio, private_key); // <== CRASH HERE.

ERR_free_strings();
EVP_cleanup();
::CRYPTO_cleanup_all_ex_data();

return EXIT_SUCCESS;
}
----- end of main.cpp -----

Which is compiled with:

cl /Fomain.obj /c main.cpp /TP /EHsc /MT /nologo 
/Ithird-party\install\x64\include
link /nologo /OUT:crash.exe /LIBPATH:third-party\install\x64\lib 
libeay32.lib user32.lib gdi32.lib advapi32.lib main.obj

I tried this sample code with all of the /MD, /MT, /MDd, /MTd variants 
without success. The code seems to run fine on Linux and OSX (using gcc 
& clang).

Here is the stacktrace I'm getting when the heap corruption occurs:

> 	openssl_crash.exe!free(void * pBlock) Line 51	C
  	openssl_crash.exe!CRYPTO_free(void * str) Line 440	C
  	openssl_crash.exe!asn1_item_combine_free(ASN1_VALUE_st * * pval, const 
ASN1_ITEM_st * it, int combine) Line 172	C
  	openssl_crash.exe!asn1_item_combine_free(ASN1_VALUE_st * * pval, const 
ASN1_ITEM_st * it, int combine) Line 160	C
  	openssl_crash.exe!asn1_item_combine_free(ASN1_VALUE_st * * pval, const 
ASN1_ITEM_st * it, int combine) Line 160	C
  	openssl_crash.exe!asn1_item_combine_free(ASN1_VALUE_st * * pval, const 
ASN1_ITEM_st * it, int combine) Line 160	C
  	openssl_crash.exe!asn1_item_combine_free(ASN1_VALUE_st * * pval, const 
ASN1_ITEM_st * it, int combine) Line 130	C
  	openssl_crash.exe!ASN1_item_free(ASN1_VALUE_st * val, const 
ASN1_ITEM_st * it) Line 73	C
  	openssl_crash.exe!i2d_ECPKParameters(const ec_group_st * a, unsigned 
char * * out) Line 1010	C
  	openssl_crash.exe!eckey_param2type(int * pptype, void * * ppval, 
ec_key_st * ec_key) Line 93	C
  	openssl_crash.exe!eckey_pub_encode(X509_pubkey_st * pk, const 
evp_pkey_st * pkey) Line 113	C
  	openssl_crash.exe!X509_PUBKEY_set(X509_pubkey_st * * x, evp_pkey_st * 
pkey) Line 101	C
  	openssl_crash.exe!i2d_PUBKEY(evp_pkey_st * a, unsigned char * * pp) 
Line 211	C
  	openssl_crash.exe!PEM_ASN1_write_bio(int (void *, unsigned char * *) * 
i2d, const char * name, bio_st * bp, void * x, const evp_cipher_st * 
enc, unsigned char * kstr, int klen, int (char *, int, int, void *) * 
callback, void * u) Line 357	C
  	openssl_crash.exe!PEM_write_bio_PUBKEY(bio_st * bp, evp_pkey_st * x) 
Line 427	C
  	openssl_crash.exe!main() Line 40	C++

Is there anything wrong regarding my sample code ? If not, can anyone 
else reproduce the problem ? Is it a bug in OpenSSL ?

Regards,

-- 
Julien.

From shinelight at shininglightpro.com  Tue Mar 24 04:03:34 2015
From: shinelight at shininglightpro.com (Thomas J. Hruska)
Date: Mon, 23 Mar 2015 21:03:34 -0700
Subject: [openssl-users] openssl 1.0.2a vc++ 9 (VS 2008) 64-bit build
 failing
In-Reply-To: <BY1PR0801MB1112E6D5EB39C89D66ECCD3EC90D0@BY1PR0801MB1112.namprd08.prod.outlook.com>
References: <BY1PR0801MB1112E6D5EB39C89D66ECCD3EC90D0@BY1PR0801MB1112.namprd08.prod.outlook.com>
Message-ID: <5510E216.8080300@shininglightpro.com>

On 3/23/2015 9:51 AM, Kevin Moody wrote:
> Hi,
>
> My apologies if I missed a post about this already, but I'm seeing the following when running `nmake -f ms\ntdll.mak` in the vc9x64 build of openssl 1.0.2a:
>
> ...
> Assembling: tmp32dll\aesni-sha256-x86_64.asm
> tmp32dll\aesni-sha256-x86_64.asm(109) : error A2006:undefined symbol : __imp_Rtl
> VirtualUnwind
> tmp32dll\aesni-sha256-x86_64.asm(127) : error A2006:undefined symbol : $L$SEH_be
> gin_aesni_cbc_sha256_enc_xop
> tmp32dll\aesni-sha256-x86_64.asm(128) : error A2006:undefined symbol : $L$SEH_en
> d_aesni_cbc_sha256_enc_xop
> tmp32dll\aesni-sha256-x86_64.asm(129) : error A2006:undefined symbol : $L$SEH_in
> fo_aesni_cbc_sha256_enc_xop
> tmp32dll\aesni-sha256-x86_64.asm(131) : error A2006:undefined symbol : $L$SEH_be
> gin_aesni_cbc_sha256_enc_avx
> tmp32dll\aesni-sha256-x86_64.asm(132) : error A2006:undefined symbol : $L$SEH_en
> d_aesni_cbc_sha256_enc_avx
> tmp32dll\aesni-sha256-x86_64.asm(133) : error A2006:undefined symbol : $L$SEH_in
> fo_aesni_cbc_sha256_enc_avx
> NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio 9.0\VC\BIN
> \x86_amd64\ml64.EXE"' : return code '0x1'
> Stop.
>
> What's odd is that this has built in my vc9x32, vc10x32, vc10x64, vc11x32, and vc11x64 build configurations.  Just to rule out an environment issue, I built my previous version, 1.0.1g, within this same command prompt.  Any ideas or suggestions as to what might be breaking the VS 2008 64-bit build?  Has anyone seen this?
>
> Obviously, I don't know enough about this project to really debug the build much further.  So, thanks in advance!
>
> Regards,
> Kevin

Use NASM instead of MASM.  AES-NI instructions are not supported under 
the VC++ 2008 compiler.

-- 
Thomas Hruska
Shining Light Productions

Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/

From erwann.abalea at opentrust.com  Tue Mar 24 12:06:06 2015
From: erwann.abalea at opentrust.com (Erwann Abalea)
Date: Tue, 24 Mar 2015 13:06:06 +0100
Subject: [openssl-users] Fwd to openssl-users,
 Re: [openssl-dev] Reminder: OpenSSL's EC private key encoding is
 broken
In-Reply-To: <56423.141.39.13.45.1427195422.squirrel@www2.informatik.hu-berlin.de>
References: <56423.141.39.13.45.1427195422.squirrel@www2.informatik.hu-berlin.de>
Message-ID: <5511532E.8020309@opentrust.com>

The private key is a random integer in [1, p-1], not in [2^(log2(p)-1), 
(2^log2(p))-1].
In DER, an INTEGER is always expressed using the smallest possible 
number of octets. "001a" is an integer equal to "00000000001a", but it 
will be represented as "1a".

-- 
Erwann ABALEA

Le 24/03/2015 12:10, Annie Yousar a ?crit :
> Dear all,
> this should not have happened:
>
> $ for i in  `seq 1 1000` ; do if [ "x`openssl ecparam -genkey -name
> prime256v1 -noout > key.pem; ls -l key.pem | sed '/ 227 /d'`" != " x" ];
> then echo; cat key.pem;else echo -n "."; fi; done
> ....................................................................................
> -----BEGIN EC PRIVATE KEY-----
> MHYCAQEEH9gjg1X/Gn9X/2VTustsXS/OuWV9LU4ivfp5oewxbACgCgYIKoZIzj0D
> AQehRANCAARlO6sLkCzJl7khaT8Nj6z3WpcDnMALQ4nI8Toc4/oYHtgUopeSMEj8
> fgHw9Ym3/2GgClzweJXYLuTYRB7oR/MY
> -----END EC PRIVATE KEY-----
> ............................................................................
> ...
>
> Conforming to the standards the EC private key has always a fixed length,
> defined by the group order.
>
> Regards,
> Ann.
>
>
>
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


From marquess at openssl.com  Tue Mar 24 13:20:38 2015
From: marquess at openssl.com (Steve Marquess)
Date: Tue, 24 Mar 2015 09:20:38 -0400
Subject: [openssl-users] FIPS: Which DRBG ?
In-Reply-To: <55105D45.606@fosiao.com>
References: <mailman.497.1427135085.1333.openssl-users@openssl.org>
 <55105D45.606@fosiao.com>
Message-ID: <551164A6.1080704@openssl.com>

On 03/23/2015 02:36 PM, xxiao8 wrote:
> The key issue still remains, are the validated SP800-90 DRBGs the _same_
> as SP800-90A's DRBGs? If yes then we can probably use Openssl-FIPS with
> SP800-90A, otherwise OpenSSL-FIPS 2.0.9 probably can no longer be used
> for any new validations?

At the time that validation was obtained the four (at the time) DRBGs
were specified by SP800-90. That document was subsequently reissued in
several pieces; the current SP800-90A now contains the specifications
for the three surviving DRBGs (the fatally tainted Dual EC DRBG having
been removed from the formal standards and also from the OpenSSL FIPS
Object Module).

Now the code for the OpenSSL FIPS module can no longer be used as-is for
new "private label" or copycat validations, but that's for different
reasons and not because of the DRBGs.

-Steve M.

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

From jonetsu at teksavvy.com  Tue Mar 24 13:53:22 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 24 Mar 2015 09:53:22 -0400
Subject: [openssl-users] FIPS: Which DRBG ?
In-Reply-To: <551164A6.1080704@openssl.com>
References: <mailman.497.1427135085.1333.openssl-users@openssl.org>
 <55105D45.606@fosiao.com> <551164A6.1080704@openssl.com>
Message-ID: <d5a2d08cacf06e56748e19a1401bd4a7@teksavvy.com>



> From: "Steve Marquess" <marquess at openssl.com> 
> Date: 03/24/15 09:22 

> At the time that validation was obtained the four (at the time) DRBGs
> were specified by SP800-90. That document was subsequently reissued in
> several pieces; the current SP800-90A now contains the specifications
> for the three surviving DRBGs (the fatally tainted Dual EC DRBG having
> been removed from the formal standards and also from the OpenSSL FIPS
> Object Module).

If it concerns only the removal of the Dual EC, then it should be OK, technically.?? 
Not on paper.
?
> Now the code for the OpenSSL FIPS module can no longer be used as-is for
> new "private label" or copycat validations, but that's for different
> reasons and not because of the DRBGs.

I've read the User Guide bit on private label validations.? In the case of a product that consists of a dedicated unit, what would be the best approach ?? So far I have considered using the OpenSSL FIPS module as is, in the hope that its FIPS validation would save costs at the testing lab.? Is this still feasible ?

Regards.




From Pavel.Punsky at oovoo.com  Tue Mar 24 15:41:15 2015
From: Pavel.Punsky at oovoo.com (Pavel Punsky)
Date: Tue, 24 Mar 2015 15:41:15 +0000
Subject: [openssl-users] ChaCha20/Poly1305 in OpenSSL?
In-Reply-To: <759a6b9a9e574a2e8d51150079ac0509@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <CAH8yC8=nh6GOVNineTo-9Jh6-0AsqDpaH+ewUDJyzduwWV-gpw@mail.gmail.com>
 <CADMhe6cXw9r3O2CAR467GrfPkoGYS_=UqFSwa6S4bw_MiqDxtQ@mail.gmail.com>
 <CAH8yC8kGpXDZ5dnqX2UYNkBnDZj2cCRoBLwxDzWLCeYni5kjhQ@mail.gmail.com>
 <54344222.4040301@openssl.org>
 <CAH8yC8=Vv8Ht251_kjGNZd0wQ35vb2StphpTe5KDYbHxyG+4jg@mail.gmail.com>
 <759a6b9a9e574a2e8d51150079ac0509@usma1ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <AMSPR07MB455CBCD1583C55212D73144890A0@AMSPR07MB455.eurprd07.prod.outlook.com>

Following github repo has 1.0.2a with chacha20poly1305 patch from CloudFlare applied to it:
https://github.com/eakraly/openssl

And this one has chacha20poly1305 implementation from different source (1.0.2-aead branch in openssl)
https://github.com/PeterMosmans/openssl

Pavel Punsky

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich
Sent: Monday, March 23, 2015 4:36 PM
To: noloader at gmail.com; openssl-users at openssl.org
Subject: Re: [openssl-users] ChaCha20/Poly1305 in OpenSSL?

It's unlikely to appear in 1.0.2 as it's a new feature.

CloudFlare has posted patches that seem like they would drop in easily, for folks that want to do it; see https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/

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


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

From marquess at openssl.com  Tue Mar 24 16:37:07 2015
From: marquess at openssl.com (Steve Marquess)
Date: Tue, 24 Mar 2015 12:37:07 -0400
Subject: [openssl-users] FIPS: Which DRBG ?
In-Reply-To: <d5a2d08cacf06e56748e19a1401bd4a7@teksavvy.com>
References: <mailman.497.1427135085.1333.openssl-users@openssl.org>
 <55105D45.606@fosiao.com> <551164A6.1080704@openssl.com>
 <d5a2d08cacf06e56748e19a1401bd4a7@teksavvy.com>
Message-ID: <551192B3.7050803@openssl.com>

On 03/24/2015 09:53 AM, jonetsu wrote:
> 
> ...
> 
>> Now the code for the OpenSSL FIPS module can no longer be used
>> as-is for new "private label" or copycat validations, but that's
>> for different reasons and not because of the DRBGs.
> 
> I've read the User Guide bit on private label validations.  In the
> case of a product that consists of a dedicated unit, what would be
> the best approach ?  So far I have considered using the OpenSSL FIPS
> module as is, in the hope that its FIPS validation would save costs
> at the testing lab.  Is this still feasible ?

No, the OpenSSL FIPS module 2.0 code is no longer suitable (as of early
2014) for use as-is in doing copycat validations. Some non-trivial code
hacks will be necessary.

We'll do a new open source based validation to succeed the 2.0 FIPS
module (#1747 validation) at the first opportunity, but that opportunity
has not yet presented itself.

-Steve M.

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

From jonetsu at teksavvy.com  Tue Mar 24 17:27:55 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 24 Mar 2015 13:27:55 -0400
Subject: [openssl-users] FIPS: Which DRBG ?
In-Reply-To: <551192B3.7050803@openssl.com>
References: <mailman.497.1427135085.1333.openssl-users@openssl.org>
 <55105D45.606@fosiao.com> <551164A6.1080704@openssl.com>
 <d5a2d08cacf06e56748e19a1401bd4a7@teksavvy.com>
 <551192B3.7050803@openssl.com>
Message-ID: <8292ad8960fdc6d053836ebbf1a2a730@teksavvy.com>



> From: "Steve Marquess" <marquess at openssl.com> 
> Date: 03/24/15 12:38 

?
> No, the OpenSSL FIPS module 2.0 code is no longer suitable (as of early
> 2014) for use as-is in doing copycat validations. Some non-trivial code
> hacks will be necessary.
?
> We'll do a new open source based validation to succeed the 2.0 FIPS
> module (#1747 validation) at the first opportunity, but that opportunity
> has not yet presented itself.

I still do not know that much about the validation in practical terms. If our units go through validation, can this benefit OpenSSL ?

Also, to go back to the SP 800-90 vs. SP 800-90A regarding the DRBGs, do you know how would the OpenSSL SP 800-90 validation fare in a FIPS testing lab since the Dual EC was removed and the other three were not touched ?

Regards.



From marquess at openssl.com  Tue Mar 24 17:36:51 2015
From: marquess at openssl.com (Steve Marquess)
Date: Tue, 24 Mar 2015 13:36:51 -0400
Subject: [openssl-users] FIPS: Which DRBG ?
In-Reply-To: <8292ad8960fdc6d053836ebbf1a2a730@teksavvy.com>
References: <mailman.497.1427135085.1333.openssl-users@openssl.org>
 <55105D45.606@fosiao.com> <551164A6.1080704@openssl.com>
 <d5a2d08cacf06e56748e19a1401bd4a7@teksavvy.com>
 <551192B3.7050803@openssl.com>
 <8292ad8960fdc6d053836ebbf1a2a730@teksavvy.com>
Message-ID: <5511A0B3.6030509@openssl.com>

On 03/24/2015 01:27 PM, jonetsu wrote:
> 
> 
>> From: "Steve Marquess" <marquess at openssl.com> Date: 03/24/15 12:38
>> 
> 
> 
>> No, the OpenSSL FIPS module 2.0 code is no longer suitable (as of
>> early 2014) for use as-is in doing copycat validations. Some
>> non-trivial code hacks will be necessary.
> 
>> We'll do a new open source based validation to succeed the 2.0
>> FIPS module (#1747 validation) at the first opportunity, but that
>> opportunity has not yet presented itself.
> 
> I still do not know that much about the validation in practical
> terms. If our units go through validation, can this benefit OpenSSL
> ?

Not in the tiniest, unless you completely open source the entire thing
as we did (specifically in a validation that includes the
build-from-source part).

A FIPS 140-2 validation is like magical pixie dust in that you and I can
each take exactly the same source code and each build a binary FIPS
module from it in exactly the same way, for exactly the same platform,
and your module will be "validated" and mine won't (or vice-versa,
depending on the pixe dust).

> 
> Also, to go back to the SP 800-90 vs. SP 800-90A regarding the DRBGs,
> do you know how would the OpenSSL SP 800-90 validation fare in a FIPS
> testing lab since the Dual EC was removed and the other three were
> not touched ?

We "revalidate" the DRBGs every time we do a new "change letter"
platform addition, which is frequently.

-Steve M.

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

From kevinm at objectivity.com  Tue Mar 24 18:27:09 2015
From: kevinm at objectivity.com (Kevin Moody)
Date: Tue, 24 Mar 2015 18:27:09 +0000
Subject: [openssl-users] openssl 1.0.2a vc++ 9 (VS 2008) 64-bit build
 failing
In-Reply-To: <5510E216.8080300@shininglightpro.com>
References: <BY1PR0801MB1112E6D5EB39C89D66ECCD3EC90D0@BY1PR0801MB1112.namprd08.prod.outlook.com>
 <5510E216.8080300@shininglightpro.com>
Message-ID: <BY1PR0801MB11121EC7D49F814B3ECA6B26C90A0@BY1PR0801MB1112.namprd08.prod.outlook.com>

Switching to a more recent version of nasm did the trick.

As it turns out, before I posted, I had assumed that using nasm might resolve this.  However, it appears that I grabbed nasm 2.05 which doesn't support AES-NI instructions, either(?).  So, my intial switch to nasm failed with the same errors.  

After your reply, I upgraded to the latest version, 2.11.8, and it worked.  Thanks for reinforcing my assumption and putting me back on track.

Regards,
Kevin
-- 

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Thomas J. Hruska
Sent: Monday, March 23, 2015 9:04 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] openssl 1.0.2a vc++ 9 (VS 2008) 64-bit build failing

On 3/23/2015 9:51 AM, Kevin Moody wrote:
> Hi,
>
> My apologies if I missed a post about this already, but I'm seeing the following when running `nmake -f ms\ntdll.mak` in the vc9x64 build of openssl 1.0.2a:
>
> ...
> Assembling: tmp32dll\aesni-sha256-x86_64.asm
> tmp32dll\aesni-sha256-x86_64.asm(109) : error A2006:undefined symbol : 
> __imp_Rtl VirtualUnwind
> tmp32dll\aesni-sha256-x86_64.asm(127) : error A2006:undefined symbol : 
> $L$SEH_be gin_aesni_cbc_sha256_enc_xop
> tmp32dll\aesni-sha256-x86_64.asm(128) : error A2006:undefined symbol : 
> $L$SEH_en d_aesni_cbc_sha256_enc_xop
> tmp32dll\aesni-sha256-x86_64.asm(129) : error A2006:undefined symbol : 
> $L$SEH_in fo_aesni_cbc_sha256_enc_xop
> tmp32dll\aesni-sha256-x86_64.asm(131) : error A2006:undefined symbol : 
> $L$SEH_be gin_aesni_cbc_sha256_enc_avx
> tmp32dll\aesni-sha256-x86_64.asm(132) : error A2006:undefined symbol : 
> $L$SEH_en d_aesni_cbc_sha256_enc_avx
> tmp32dll\aesni-sha256-x86_64.asm(133) : error A2006:undefined symbol : 
> $L$SEH_in fo_aesni_cbc_sha256_enc_avx NMAKE : fatal error U1077: 
> '"c:\Program Files\Microsoft Visual Studio 9.0\VC\BIN 
> \x86_amd64\ml64.EXE"' : return code '0x1'
> Stop.
>
> What's odd is that this has built in my vc9x32, vc10x32, vc10x64, vc11x32, and vc11x64 build configurations.  Just to rule out an environment issue, I built my previous version, 1.0.1g, within this same command prompt.  Any ideas or suggestions as to what might be breaking the VS 2008 64-bit build?  Has anyone seen this?
>
> Obviously, I don't know enough about this project to really debug the build much further.  So, thanks in advance!
>
> Regards,
> Kevin

Use NASM instead of MASM.  AES-NI instructions are not supported under the VC++ 2008 compiler.

--
Thomas Hruska
Shining Light Productions

Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From oyljerry at gmail.com  Wed Mar 25 03:25:38 2015
From: oyljerry at gmail.com (Jerry OELoo)
Date: Wed, 25 Mar 2015 11:25:38 +0800
Subject: [openssl-users]  What global object I use in application lifetime
Message-ID: <CAEKwp_HSHZ0dT7tT5C5hS=gEL8+ubXYxO2WqCwWE1ewifK-4QA@mail.gmail.com>

Hi.
Now when my application running, I will use SSL_connect() to connect
1000 different URLs.

I want to keep some openssl object as global variable then I do not
need to initialize/uninitialize again and again.

Here is my sample code.

g_ctx = SSL_CTX_new(method);
g_ssl = SSL_new(g_ctx );

//SSL_connect will connect 1000 URLs 1 by 1.

...

//release g_ctx and g_ssl

>From document, I think CTX can be initialize only once. But I do not
know g_ssl can be initialize only once? I can reuse g_ssl  for 1000
differnt URLs? Please correct me if anything. Thanks!


Best Regards
Jerry

-- 
Rejoice,I Desire!

From rsalz at akamai.com  Wed Mar 25 03:33:50 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 25 Mar 2015 03:33:50 +0000
Subject: [openssl-users] What global object I use in application lifetime
In-Reply-To: <CAEKwp_HSHZ0dT7tT5C5hS=gEL8+ubXYxO2WqCwWE1ewifK-4QA@mail.gmail.com>
References: <CAEKwp_HSHZ0dT7tT5C5hS=gEL8+ubXYxO2WqCwWE1ewifK-4QA@mail.gmail.com>
Message-ID: <8969c490c29a4b1c9772356582e6ca5c@usma1ex-dag1mb2.msg.corp.akamai.com>

> From document, I think CTX can be initialize only once. But I do not know
> g_ssl can be initialize only once? I can reuse g_ssl  for 1000 differnt URLs?
> Please correct me if anything. Thanks!

You need to create a new SSL object every time you want to do a connect.

	/r$

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



From oyljerry at gmail.com  Wed Mar 25 03:38:30 2015
From: oyljerry at gmail.com (Jerry OELoo)
Date: Wed, 25 Mar 2015 11:38:30 +0800
Subject: [openssl-users] What global object I use in application lifetime
In-Reply-To: <8969c490c29a4b1c9772356582e6ca5c@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <CAEKwp_HSHZ0dT7tT5C5hS=gEL8+ubXYxO2WqCwWE1ewifK-4QA@mail.gmail.com>
 <8969c490c29a4b1c9772356582e6ca5c@usma1ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CAEKwp_FQj=9bxKg4NOQV2p8f_5-Yd6e-2ir8mYNE00ZEKAc-Rw@mail.gmail.com>

So, I can re-use g_ctx, but I need create a new g_ssl everytime, right?
BTW, X509_STORE *store = X509_STORE_new();  for store, Can I reuse it
as a global object?


On Wed, Mar 25, 2015 at 11:33 AM, Salz, Rich <rsalz at akamai.com> wrote:
>> From document, I think CTX can be initialize only once. But I do not know
>> g_ssl can be initialize only once? I can reuse g_ssl  for 1000 differnt URLs?
>> Please correct me if anything. Thanks!
>
> You need to create a new SSL object every time you want to do a connect.
>
>         /r$
>
> --
> 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



-- 
Rejoice,I Desire!

From noadsplease at web.de  Wed Mar 25 08:18:12 2015
From: noadsplease at web.de (Dirk Menstermann)
Date: Wed, 25 Mar 2015 09:18:12 +0100
Subject: [openssl-users] How to get encryption strength?
Message-ID: <55126F44.9010707@web.de>

Hello,

which API function can I use to obtain the bit strength of the key exchange
(size of the DH or ECDH parameters)?

There is the function SSL_get_cipher_bits, but this is only for the symmetric
cipher, not including the key exchange.

Thanks
Dirk

From sahib.jakhar at gmail.com  Wed Mar 25 15:27:31 2015
From: sahib.jakhar at gmail.com (Sahib Jakhar)
Date: Wed, 25 Mar 2015 20:57:31 +0530
Subject: [openssl-users] Regarding server side sessions support
Message-ID: <CAE+y=w56_8tvcDQRPP3dLe6EWkCJeAKeT+XkTV4OKk0c4eFafw@mail.gmail.com>

Hi,

I am trying to implement server side caching support for sessions by
using callback functions. However, the callback functions are never
being called, even though connection happens successfully without
session resumption. For your reference some of the sample code I am
pasting below:

ssl_session_ctx_id = 1;
SSL_CTX_set_session_id_context (c, (void *)&ssl_session_ctx_id, sizeof
(ssl_session_ctx_id));
SSL_CTX_set_session_cache_mode(c, SSL_SESS_CACHE_SERVER |
SSL_SESS_CACHE_NO_INTERNAL);
SSL_CTX_sess_set_new_cb (c, custom_new_session_cb );
SSL_CTX_sess_set_remove_cb (c, custom_remove_session_cb );
SSL_CTX_sess_set_get_cb (c, custom_get_session_cb);


Can somebody kindly help me as to what I am missing out here? What
could be the reason behind the callback functions not being called?


Thanks
Sahib

From steve at openssl.org  Wed Mar 25 15:32:08 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 25 Mar 2015 15:32:08 +0000
Subject: [openssl-users] Regarding server side sessions support
In-Reply-To: <CAE+y=w56_8tvcDQRPP3dLe6EWkCJeAKeT+XkTV4OKk0c4eFafw@mail.gmail.com>
References: <CAE+y=w56_8tvcDQRPP3dLe6EWkCJeAKeT+XkTV4OKk0c4eFafw@mail.gmail.com>
Message-ID: <20150325153208.GA22293@openssl.org>

On Wed, Mar 25, 2015, Sahib Jakhar wrote:

> Hi,
> 
> I am trying to implement server side caching support for sessions by
> using callback functions. However, the callback functions are never
> being called, even though connection happens successfully without
> session resumption. For your reference some of the sample code I am
> pasting below:
> 
> ssl_session_ctx_id = 1;
> SSL_CTX_set_session_id_context (c, (void *)&ssl_session_ctx_id, sizeof
> (ssl_session_ctx_id));
> SSL_CTX_set_session_cache_mode(c, SSL_SESS_CACHE_SERVER |
> SSL_SESS_CACHE_NO_INTERNAL);
> SSL_CTX_sess_set_new_cb (c, custom_new_session_cb );
> SSL_CTX_sess_set_remove_cb (c, custom_remove_session_cb );
> SSL_CTX_sess_set_get_cb (c, custom_get_session_cb);
> 
> 
> Can somebody kindly help me as to what I am missing out here? What
> could be the reason behind the callback functions not being called?
> 

The client could be using session tickets which don't use a session cache. You
can try disabling them by setting SSL_OP_NO_TICKET.

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

From steve at openssl.org  Wed Mar 25 15:35:06 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 25 Mar 2015 15:35:06 +0000
Subject: [openssl-users] How to get encryption strength?
In-Reply-To: <55126F44.9010707@web.de>
References: <55126F44.9010707@web.de>
Message-ID: <20150325153506.GB22293@openssl.org>

On Wed, Mar 25, 2015, Dirk Menstermann wrote:

> Hello,
> 
> which API function can I use to obtain the bit strength of the key exchange
> (size of the DH or ECDH parameters)?
> 
> There is the function SSL_get_cipher_bits, but this is only for the symmetric
> cipher, not including the key exchange.
> 

This is only supported in OpenSSL 1.0.2 and later. You can call
SSL_get_server_tmp_key() to get the peer temporary key. This returns an
EVP_PKEY structue which you can then analyse further.

Check out the function ssl_print_tmp_key() in apps/s_cb.c for a simple
example.

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 Mar 25 16:46:37 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 25 Mar 2015 16:46:37 +0000
Subject: [openssl-users] Regarding server side sessions support
In-Reply-To: <20150325153208.GA22293@openssl.org>
References: <CAE+y=w56_8tvcDQRPP3dLe6EWkCJeAKeT+XkTV4OKk0c4eFafw@mail.gmail.com>
 <20150325153208.GA22293@openssl.org>
Message-ID: <20150325164637.GK21586@mournblade.imrryr.org>

On Wed, Mar 25, 2015 at 03:32:08PM +0000, Dr. Stephen Henson wrote:

> > I am trying to implement server side caching support for sessions by
> > using callback functions. However, the callback functions are never
> > being called, even though connection happens successfully without
> > session resumption. For your reference some of the sample code I am
> > pasting below:
> > 
> > ssl_session_ctx_id = 1;
> > SSL_CTX_set_session_id_context (c, (void *)&ssl_session_ctx_id, sizeof
> > (ssl_session_ctx_id));
> > SSL_CTX_set_session_cache_mode(c, SSL_SESS_CACHE_SERVER |
> > SSL_SESS_CACHE_NO_INTERNAL);
> > SSL_CTX_sess_set_new_cb (c, custom_new_session_cb );
> > SSL_CTX_sess_set_remove_cb (c, custom_remove_session_cb );
> > SSL_CTX_sess_set_get_cb (c, custom_get_session_cb);
> > 
> > 
> > Can somebody kindly help me as to what I am missing out here? What
> > could be the reason behind the callback functions not being called?
> 
> The client could be using session tickets which don't use a session cache. You
> can try disabling them by setting SSL_OP_NO_TICKET.

I would NOT recommend disabling session tickets, they are better
than server-side caches.

That said, Postfix supports both, ahd the callbacks are called.  See lines
624-669 of:

	https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_server.c

-- 
	Viktor.

line 165:
    static const char server_session_id_context[] = "Postfix/TLS";

lines 624-669:

    if (cachable || ticketable || props->set_sessid) {

	/*
	 * Initialize the session cache.
	 * 
	 * With a large number of concurrent smtpd(8) processes, it is not a
	 * good idea to cache multiple large session objects in each process.
	 * We set the internal cache size to 1, and don't register a
	 * "remove_cb" so as to avoid deleting good sessions from the
	 * external cache prematurely (when the internal cache is full,
	 * OpenSSL removes sessions from the external cache also)!
	 * 
	 * This makes SSL_CTX_remove_session() not useful for flushing broken
	 * sessions from the external cache, so we must delete them directly
	 * (not via a callback).
	 * 
	 * Set a session id context to identify to what type of server process
	 * created a session. In our case, the context is simply the name of
	 * the mail system: "Postfix/TLS".
	 */
	SSL_CTX_sess_set_cache_size(server_ctx, 1);
	SSL_CTX_set_session_id_context(server_ctx,
				       (void *) &server_session_id_context,
				       sizeof(server_session_id_context));
	SSL_CTX_set_session_cache_mode(server_ctx,
				       SSL_SESS_CACHE_SERVER |
				       SSL_SESS_CACHE_NO_AUTO_CLEAR);
	if (cachable) {
	    app_ctx->cache_type = mystrdup(props->cache_type);

	    SSL_CTX_sess_set_get_cb(server_ctx, get_server_session_cb);
	    SSL_CTX_sess_set_new_cb(server_ctx, new_server_session_cb);
	}

	/*
	 * OpenSSL ignores timed-out sessions. We need to set the internal
	 * cache timeout at least as high as the external cache timeout. This
	 * applies even if no internal cache is used.  We set the session
	 * lifetime to twice the cache lifetime, which is also the issuing
	 * and retired key validation lifetime of session tickets keys. This
	 * way a session always lasts longer than the server's ability to
	 * decrypt its session ticket.  Otherwise, a bug in OpenSSL may fail
	 * to re-issue tickets when sessions decrypt, but are expired.
	 */
	SSL_CTX_set_timeout(server_ctx, 2 * scache_timeout);
    }

From noadsplease at web.de  Wed Mar 25 17:04:09 2015
From: noadsplease at web.de (Dirk Menstermann)
Date: Wed, 25 Mar 2015 18:04:09 +0100
Subject: [openssl-users] How to get encryption strength?
In-Reply-To: <20150325153506.GB22293@openssl.org>
References: <55126F44.9010707@web.de> <20150325153506.GB22293@openssl.org>
Message-ID: <5512EA89.7000802@web.de>

Very helpful. Thank you Steve.

Dirk

On 25.03.2015 16:35, Dr. Stephen Henson wrote:
> On Wed, Mar 25, 2015, Dirk Menstermann wrote:
> 
>> Hello,
>>
>> which API function can I use to obtain the bit strength of the key exchange
>> (size of the DH or ECDH parameters)?
>>
>> There is the function SSL_get_cipher_bits, but this is only for the symmetric
>> cipher, not including the key exchange.
>>
> 
> This is only supported in OpenSSL 1.0.2 and later. You can call
> SSL_get_server_tmp_key() to get the peer temporary key. This returns an
> EVP_PKEY structue which you can then analyse further.
> 
> Check out the function ssl_print_tmp_key() in apps/s_cb.c for a simple
> example.
> 
> 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 noloader at gmail.com  Wed Mar 25 19:14:17 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 25 Mar 2015 15:14:17 -0400
Subject: [openssl-users] ChaCha20/Poly1305 in OpenSSL?
In-Reply-To: <759a6b9a9e574a2e8d51150079ac0509@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <CAH8yC8=nh6GOVNineTo-9Jh6-0AsqDpaH+ewUDJyzduwWV-gpw@mail.gmail.com>
 <CADMhe6cXw9r3O2CAR467GrfPkoGYS_=UqFSwa6S4bw_MiqDxtQ@mail.gmail.com>
 <CAH8yC8kGpXDZ5dnqX2UYNkBnDZj2cCRoBLwxDzWLCeYni5kjhQ@mail.gmail.com>
 <54344222.4040301@openssl.org>
 <CAH8yC8=Vv8Ht251_kjGNZd0wQ35vb2StphpTe5KDYbHxyG+4jg@mail.gmail.com>
 <759a6b9a9e574a2e8d51150079ac0509@usma1ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CAH8yC8=UnUwNd58LurkwWAZ+x+BZDy3Uz5ZsSzrZL4bv_rz85g@mail.gmail.com>

On Mon, Mar 23, 2015 at 10:36 AM, Salz, Rich <rsalz at akamai.com> wrote:
> It's unlikely to appear in 1.0.2 as it's a new feature.
>
> CloudFlare has posted patches that seem like they would drop in easily, for folks that want to do it; see https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/
>
Thanks Rich.

I see Adam Langley's patch here:
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9a8646510b

Any ideas why it was not accepted or not merged? (I'm assuming it was
not merged because it was rejected for some reason).

Jeff

From rsalz at akamai.com  Wed Mar 25 19:36:41 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 25 Mar 2015 19:36:41 +0000
Subject: [openssl-users] ChaCha20/Poly1305 in OpenSSL?
In-Reply-To: <CAH8yC8=UnUwNd58LurkwWAZ+x+BZDy3Uz5ZsSzrZL4bv_rz85g@mail.gmail.com>
References: <CAH8yC8=nh6GOVNineTo-9Jh6-0AsqDpaH+ewUDJyzduwWV-gpw@mail.gmail.com>
 <CADMhe6cXw9r3O2CAR467GrfPkoGYS_=UqFSwa6S4bw_MiqDxtQ@mail.gmail.com>
 <CAH8yC8kGpXDZ5dnqX2UYNkBnDZj2cCRoBLwxDzWLCeYni5kjhQ@mail.gmail.com>
 <54344222.4040301@openssl.org>
 <CAH8yC8=Vv8Ht251_kjGNZd0wQ35vb2StphpTe5KDYbHxyG+4jg@mail.gmail.com>
 <759a6b9a9e574a2e8d51150079ac0509@usma1ex-dag1mb2.msg.corp.akamai.com>
 <CAH8yC8=UnUwNd58LurkwWAZ+x+BZDy3Uz5ZsSzrZL4bv_rz85g@mail.gmail.com>
Message-ID: <6d15fcf8ed80459292c7e7679f862911@usma1ex-dag1mb2.msg.corp.akamai.com>

> I see Adam Langley's patch here:
> https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9a8646510b
> 
> Any ideas why it was not accepted or not merged? (I'm assuming it was not
> merged because it was rejected for some reason).

I thought his patch came before the IETF final doc, which changed some things.


From jonetsu at teksavvy.com  Wed Mar 25 19:40:01 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Wed, 25 Mar 2015 15:40:01 -0400
Subject: [openssl-users] FIPS: Which DRBG is default ?
Message-ID: <944d45a3825440641ca2d86ae0aae030@teksavvy.com>

Hello,

? When an application does not define OPENSSL_DRBG_DEFAULT_TYPE nor OPENSSL_DRBG_DEFAULT_FLAGS nor any compilation options (if applicable), is the default DRBG the 256 bit CTR AES (+ deviation function) in FIPS mode ?

Regards.




From jonetsu at teksavvy.com  Wed Mar 25 20:12:40 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Wed, 25 Mar 2015 16:12:40 -0400
Subject: [openssl-users] FIPS Linux kernel documentation ?
Message-ID: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>

Hello,

? This is not about OpenSSL, although from experience, maybe some know the answer. Does anyone know if actual documentation exists for the Linux kernel FIPS mode apart from the source itself ?? There is nothing in Documentation/ as per 3.18.2.? - thanks.

Regards.



From noloader at gmail.com  Wed Mar 25 20:38:11 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 25 Mar 2015 16:38:11 -0400
Subject: [openssl-users] FIPS Linux kernel documentation ?
In-Reply-To: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>
References: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>
Message-ID: <CAH8yC8k59aBtZHBn4U10cKEWuMt312hg1GdPhDeizXkqj9=noQ@mail.gmail.com>

On Wed, Mar 25, 2015 at 4:12 PM, jonetsu <jonetsu at teksavvy.com> wrote:
> Hello,
>
>   This is not about OpenSSL, although from experience, maybe some know the answer. Does anyone know if actual documentation exists for the Linux kernel FIPS mode apart from the source itself ?  There is nothing in Documentation/ as per 3.18.2.  - thanks.
>
NIST should have a security policy on file. The security policy is
required documentation.

Jeff

From marquess at openssl.com  Wed Mar 25 21:03:04 2015
From: marquess at openssl.com (Steve Marquess)
Date: Wed, 25 Mar 2015 17:03:04 -0400
Subject: [openssl-users] FIPS Linux kernel documentation ?
In-Reply-To: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>
References: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>
Message-ID: <55132288.3040004@openssl.com>

On 03/25/2015 04:12 PM, jonetsu wrote:
> Hello,
> 
> This is not about OpenSSL, although from experience, maybe some know
> the answer. Does anyone know if actual documentation exists for the
> Linux kernel FIPS mode apart from the source itself ?  There is
> nothing in Documentation/ as per 3.18.2.  - thanks.

I wasn't aware the Linux kernel (the real one, not proprietary
commercial derivatives) had a "FIPS" mode. Please enlighten me.

-Steve M.

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

From jonetsu at teksavvy.com  Wed Mar 25 22:26:00 2015
From: jonetsu at teksavvy.com (jonetsu at teksavvy.com)
Date: Wed, 25 Mar 2015 18:26:00 -0400
Subject: [openssl-users] FIPS Linux kernel documentation ?
In-Reply-To: <55132288.3040004@openssl.com>
References: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>
 <55132288.3040004@openssl.com>
Message-ID: <20150325182600.6a67ba25@mevla>

On Wed, 25 Mar 2015 17:03:04 -0400
Steve Marquess <marquess at openssl.com> wrote:

> I wasn't aware the Linux kernel (the real one, not proprietary
> commercial derivatives) had a "FIPS" mode. Please enlighten me.

It could very well be that the word 'mode' is not the right one.
'option' would perhaps be better.  This article from 2009 sets the
foundation:

http://www.guerilla-ciso.com/archives/793

I wonder, 6 years later, what the kernel fips option implies.  Maybe I
could try to contact Neil Horman and?or look into the sources.


From write2mukesh84 at gmail.com  Thu Mar 26 05:12:21 2015
From: write2mukesh84 at gmail.com (Mukesh Yadav)
Date: Thu, 26 Mar 2015 10:42:21 +0530
Subject: [openssl-users] Is RC4-MD5 disabled on Openssl-1.0.1h
Message-ID: <CAGsjCKHZxFARSJE+X-6zaZF0+guTzGq_p=_e4uy2X-pnYA622A@mail.gmail.com>

HI,

I have a query for SSl cipher on Openssl-1.0.1h
Have an application which is using library compiled with openssl-1.0.1h.

Application is failing in func SSL_CTX_set_cipher_list() when input is "
RC4-MD5+RC4-SHA" and it gets succeed when input is "RC4-SHA".
Not sure whether "RC4-MD5" is disabled by default on openssl-1.0.1h.
Earlier application was using openssl-0.9.8d.
There it used to work fine..
If that is the case, is there a way to enable RC4-MD5 on openssl-1.0.1h.

Tried looking opensource link, couldn't find a way to explicitly enable
this algorithm or even if it is diabled by default.
Any Inputs for same will be appreciated..


Thanks
Mukesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150326/959f1554/attachment.html>

From piotr.lobacz at radmor.com.pl  Thu Mar 26 07:46:43 2015
From: piotr.lobacz at radmor.com.pl (Piotr =?UTF-8?Q?=C5=81obacz?=)
Date: Thu, 26 Mar 2015 08:46:43 +0100
Subject: [openssl-users] QNX cross-compiled openssl with fips
Message-ID: <1427356003.3211.9.camel@piotr-desktop>

Hello,
i have been able to cross-compile openssl with fips module and what i
want now is to use it within my project which is using C++. According to
the manual https://wiki.openssl.org/index.php/Fipsld_and_C%2B%2B i have
to modify fipsld to fipsld++. Everything works properly if i'm compiling
my own libraries which are being linked with static crypto.a but if i'm
going to compile some tests which are linking with those libraries i get
this error:

/usr/lib/fips_premain.o: In function `FINGERPRINT_premain()':
/usr/lib/fips_premain.c:103: undefined reference to `FIPS_text_start()'
/usr/lib/fips_premain.c:116: undefined reference to
`FIPS_incore_fingerprint(unsigned char*, unsigned int)'

According to the manual, problem occurs with C++ linker, but i have it
modified in fipsld++ so that now PREMAIN_DSO looks like:

-x c "${PREMAIN_C}" -x none \

and this does not help. On Linux with gcc this was helpful but on QNX
cross compilation it does not.

I would be pleased if somebody could point me what am i doing wrong...

-- 

________________________________________________________________________
Piotr ?obacz

Biuro System?w i Oprogramowania

RADMOR S.A.

tel. (58) 6996 929

e-mail: piotr.lobacz at radmor.com.pl

www.radmor.com.pl




RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia

NIP: 586-010-21-39

REGON: 190432077

KRS: 0000074029 (S?d Rejonowy Gda?sk-P??noc w Gda?sku)

Kapita? zak?adowy wp?acony: 9 282 830 PLN


From meissner at suse.de  Thu Mar 26 09:53:09 2015
From: meissner at suse.de (Marcus Meissner)
Date: Thu, 26 Mar 2015 10:53:09 +0100
Subject: [openssl-users] Is RC4-MD5 disabled on Openssl-1.0.1h
In-Reply-To: <CAGsjCKHZxFARSJE+X-6zaZF0+guTzGq_p=_e4uy2X-pnYA622A@mail.gmail.com>
References: <CAGsjCKHZxFARSJE+X-6zaZF0+guTzGq_p=_e4uy2X-pnYA622A@mail.gmail.com>
Message-ID: <20150326095308.GA25483@suse.de>

On Thu, Mar 26, 2015 at 10:42:21AM +0530, Mukesh Yadav wrote:
> HI,
> 
> I have a query for SSl cipher on Openssl-1.0.1h
> Have an application which is using library compiled with openssl-1.0.1h.
> 
> Application is failing in func SSL_CTX_set_cipher_list() when input is "
> RC4-MD5+RC4-SHA" and it gets succeed when input is "RC4-SHA".
> Not sure whether "RC4-MD5" is disabled by default on openssl-1.0.1h.
> Earlier application was using openssl-0.9.8d.
> There it used to work fine..
> If that is the case, is there a way to enable RC4-MD5 on openssl-1.0.1h.
> 
> Tried looking opensource link, couldn't find a way to explicitly enable
> this algorithm or even if it is diabled by default.
> Any Inputs for same will be appreciated..

You seem to be using invalid cipher string syntax.

: is a delimiter there.

openssl ciphers RC4-MD5:RC4-SHA  -v
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1



Ciao, Marcus

From noadsplease at web.de  Thu Mar 26 12:37:26 2015
From: noadsplease at web.de (Dirk Menstermann)
Date: Thu, 26 Mar 2015 13:37:26 +0100
Subject: [openssl-users] How to get encryption strength?
In-Reply-To: <20150325153506.GB22293@openssl.org>
References: <55126F44.9010707@web.de> <20150325153506.GB22293@openssl.org>
Message-ID: <5513FD86.3080305@web.de>

Hi Steve,

as far as I can see this works only if the application embedding openssl is the
ssl client; but how can this be achieved from the server's point of view?

Thanks
Dirk


On 25.03.2015 16:35, Dr. Stephen Henson wrote:
> On Wed, Mar 25, 2015, Dirk Menstermann wrote:
> 
>> Hello,
>>
>> which API function can I use to obtain the bit strength of the key exchange
>> (size of the DH or ECDH parameters)?
>>
>> There is the function SSL_get_cipher_bits, but this is only for the symmetric
>> cipher, not including the key exchange.
>>
> 
> This is only supported in OpenSSL 1.0.2 and later. You can call
> SSL_get_server_tmp_key() to get the peer temporary key. This returns an
> EVP_PKEY structue which you can then analyse further.
> 
> Check out the function ssl_print_tmp_key() in apps/s_cb.c for a simple
> example.
> 
> 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 write2mukesh84 at gmail.com  Thu Mar 26 12:50:44 2015
From: write2mukesh84 at gmail.com (Mukesh Yadav)
Date: Thu, 26 Mar 2015 18:20:44 +0530
Subject: [openssl-users] Is RC4-MD5 disabled on Openssl-1.0.1h
In-Reply-To: <20150326095308.GA25483@suse.de>
References: <CAGsjCKHZxFARSJE+X-6zaZF0+guTzGq_p=_e4uy2X-pnYA622A@mail.gmail.com>
 <20150326095308.GA25483@suse.de>
Message-ID: <CAGsjCKEj6ZbDcn4eMdhoNr-pO5racUyGAM+4n3f1dnAkDVa0sA@mail.gmail.com>

Thanks Marcus.
 It worked when changed + to :.
  I am wondering is this newly introduced?.
  Application compiled with openssl-0.9.8d used to work when Cipher string
has '+'.or ':'


On 26 March 2015 at 15:23, Marcus Meissner <meissner at suse.de> wrote:

> On Thu, Mar 26, 2015 at 10:42:21AM +0530, Mukesh Yadav wrote:
> > HI,
> >
> > I have a query for SSl cipher on Openssl-1.0.1h
> > Have an application which is using library compiled with openssl-1.0.1h.
> >
> > Application is failing in func SSL_CTX_set_cipher_list() when input is "
> > RC4-MD5+RC4-SHA" and it gets succeed when input is "RC4-SHA".
> > Not sure whether "RC4-MD5" is disabled by default on openssl-1.0.1h.
> > Earlier application was using openssl-0.9.8d.
> > There it used to work fine..
> > If that is the case, is there a way to enable RC4-MD5 on openssl-1.0.1h.
> >
> > Tried looking opensource link, couldn't find a way to explicitly enable
> > this algorithm or even if it is diabled by default.
> > Any Inputs for same will be appreciated..
>
> You seem to be using invalid cipher string syntax.
>
> : is a delimiter there.
>
> openssl ciphers RC4-MD5:RC4-SHA  -v
> RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
> RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
>
>
>
> Ciao, Marcus
> _______________________________________________
> 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/20150326/a4b20188/attachment.html>

From rsalz at akamai.com  Thu Mar 26 13:14:33 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 26 Mar 2015 13:14:33 +0000
Subject: [openssl-users] Is RC4-MD5 disabled on Openssl-1.0.1h
In-Reply-To: <CAGsjCKEj6ZbDcn4eMdhoNr-pO5racUyGAM+4n3f1dnAkDVa0sA@mail.gmail.com>
References: <CAGsjCKHZxFARSJE+X-6zaZF0+guTzGq_p=_e4uy2X-pnYA622A@mail.gmail.com>
 <20150326095308.GA25483@suse.de>
 <CAGsjCKEj6ZbDcn4eMdhoNr-pO5racUyGAM+4n3f1dnAkDVa0sA@mail.gmail.com>
Message-ID: <e714bec7d3d44f0593d40f7514285e8e@usma1ex-dag1mb2.msg.corp.akamai.com>

>  I am wondering is this newly introduced?. 

No it's not new.

 > Application compiled with openssl-0.9.8d used to work when Cipher string has '+'.or ':'

That release is nearly 10 years old (Sep 2006)  And are you sure it worked?  + tended to mean add, so :+ worked...

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



From raji.kotamraju at gmail.com  Thu Mar 26 13:15:29 2015
From: raji.kotamraju at gmail.com (Rajeswari K)
Date: Thu, 26 Mar 2015 18:45:29 +0530
Subject: [openssl-users] Memory leak issue
Message-ID: <CA+mfXPGRqFwY1N9+_zjwnSH=sMz9CG5=eaNaBu=WvBBEgejfyw@mail.gmail.com>

Hello Openssl Users,

Currently we are facing a memory leak issue in the following scenario.

We are allocating dynamic memory to a appctx and we are setting this appctx
to the session using the function
SSL_SESSION_set_app_data().

My understanding is that, this appctx will be updated as part of ex_data
present at SSL_SESSION data structure.

As part of SSL_SESSION_free(), i see that crypto_free_ex_data() gets
called. But, we are seeing that appctx is not being free'd through openssl.

Is there any function do i need to update for free_func() to get this
appctx to be free'd?

And my understanding is if SSL Caching is present, this ex_data also gets
saved as part of SSL_SESSION data. Hence, at application we are unable to
judge when to free this appctx. Hence, we would like to get this free'd
when openssl frees its SSL Session.

Please provide me appropriate function to call/to set at/to openssl to get
this appctx free'd by openssl when SSL_Session is being freed.

Thanks in advance.

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

From write2mukesh84 at gmail.com  Thu Mar 26 14:26:38 2015
From: write2mukesh84 at gmail.com (Mukesh Yadav)
Date: Thu, 26 Mar 2015 19:56:38 +0530
Subject: [openssl-users] Is RC4-MD5 disabled on Openssl-1.0.1h
In-Reply-To: <e714bec7d3d44f0593d40f7514285e8e@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <CAGsjCKHZxFARSJE+X-6zaZF0+guTzGq_p=_e4uy2X-pnYA622A@mail.gmail.com>
 <20150326095308.GA25483@suse.de>
 <CAGsjCKEj6ZbDcn4eMdhoNr-pO5racUyGAM+4n3f1dnAkDVa0sA@mail.gmail.com>
 <e714bec7d3d44f0593d40f7514285e8e@usma1ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CAGsjCKHs7Oy_4OePXegsZ1gwyoJBcY_gq3Ad9cwwME-+Wd3KgA@mail.gmail.com>

That's Right..
here is O/p



Openssl-0.9.8d:

:~/openssl-0.9.8d_install/usr/local/bin# ./openssl ciphers RC4-MD5:RC4-SHA
-v

RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5

RC4-MD5                 SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5

RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

:~/openssl-0.9.8d_install/usr/local/bin# ./openssl ciphers RC4-MD5+RC4-SHA
-v

RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5

RC4-MD5                 SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5

RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1



Openssl-1.0.1h:

:~/openssl-1.0.1h_install/usr/local/bin# ./openssl ciphers RC4-MD5:RC4-SHA
-v

RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5

RC4-MD5                 SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5

RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

:~/openssl-1.0.1h_install/usr/local/bin# ./openssl ciphers RC4-MD5+RC4-SHA
-v

Error in cipher list

4159309472:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher
match:ssl_lib.c:1314:


Thanks

Mukesh

On 26 March 2015 at 18:44, Salz, Rich <rsalz at akamai.com> wrote:

> >  I am wondering is this newly introduced?.
>
> No it's not new.
>
>  > Application compiled with openssl-0.9.8d used to work when Cipher
> string has '+'.or ':'
>
> That release is nearly 10 years old (Sep 2006)  And are you sure it
> worked?  + tended to mean add, so :+ worked...
>
> --
> 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/20150326/36a7274b/attachment.html>

From openssl-users at dukhovni.org  Thu Mar 26 14:54:52 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 26 Mar 2015 14:54:52 +0000
Subject: [openssl-users] Is RC4-MD5 disabled on Openssl-1.0.1h
In-Reply-To: <CAGsjCKHs7Oy_4OePXegsZ1gwyoJBcY_gq3Ad9cwwME-+Wd3KgA@mail.gmail.com>
References: <CAGsjCKHZxFARSJE+X-6zaZF0+guTzGq_p=_e4uy2X-pnYA622A@mail.gmail.com>
 <20150326095308.GA25483@suse.de>
 <CAGsjCKEj6ZbDcn4eMdhoNr-pO5racUyGAM+4n3f1dnAkDVa0sA@mail.gmail.com>
 <e714bec7d3d44f0593d40f7514285e8e@usma1ex-dag1mb2.msg.corp.akamai.com>
 <CAGsjCKHs7Oy_4OePXegsZ1gwyoJBcY_gq3Ad9cwwME-+Wd3KgA@mail.gmail.com>
Message-ID: <20150326145452.GB17637@mournblade.imrryr.org>

On Thu, Mar 26, 2015 at 07:56:38PM +0530, Mukesh Yadav wrote:

> :~/openssl-0.9.8d_install/usr/local/bin# ./openssl ciphers RC4-MD5+RC4-SHA
> -v
> 
> RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
> 
> RC4-MD5                 SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
> 
> RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

That's a bug.  Between two ciphers "+" means "AND".  Right after
":" a "+" means "move to the end".  No cipher is both RC4-MD5 AND
RC4-SHA.

-- 
	Viktor.

From marquess at openssl.com  Thu Mar 26 14:57:28 2015
From: marquess at openssl.com (Steve Marquess)
Date: Thu, 26 Mar 2015 10:57:28 -0400
Subject: [openssl-users] FIPS Linux kernel documentation ?
In-Reply-To: <20150325182600.6a67ba25@mevla>
References: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>
 <55132288.3040004@openssl.com> <20150325182600.6a67ba25@mevla>
Message-ID: <55141E58.7020709@openssl.com>

On 03/25/2015 06:26 PM, jonetsu at teksavvy.com wrote:
> On Wed, 25 Mar 2015 17:03:04 -0400
> Steve Marquess <marquess at openssl.com> wrote:
> 
>> I wasn't aware the Linux kernel (the real one, not proprietary
>> commercial derivatives) had a "FIPS" mode. Please enlighten me.
> 
> It could very well be that the word 'mode' is not the right one.
> 'option' would perhaps be better.  This article from 2009 sets the
> foundation:
> 
> http://www.guerilla-ciso.com/archives/793
> 
> I wonder, 6 years later, what the kernel fips option implies.  Maybe I
> could try to contact Neil Horman and?or look into the sources.

That reference gives a pretty good explanation. CONFIG_CRYPTO_FIPS
doesn't get you any closer to FIPS 140-2 validated kernel cryptography.

Unfortunately FIPS 140-2 validation conflicts rather violently with open
source software (and with software engineering best practice in general,
for that matter). Even if some benevolent benefactor ponied up the
quarter megabuck it would take to do an open source based kernel crypto
validation, it would be fossilized code obsolete before the validation
was even approved. Linux got to be as good as it is due to constant
refinement and improvement; FIPS validation presumes that it is possible
to write perfect code in one shot and that the environment that code
runs in never changes.

-Steve M.

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

From pbellino at mrv.com  Thu Mar 26 14:53:03 2015
From: pbellino at mrv.com (Philip Bellino)
Date: Thu, 26 Mar 2015 14:53:03 +0000
Subject: [openssl-users] Encryption length, OpenSSL_add_all_algorithms,
 and OpenSSL_add_all_ciphers questions
Message-ID: <AM3PR03MB0824C6480A0D7D7F28B46DE7C3080@AM3PR03MB0824.eurprd03.prod.outlook.com>

I am using OpenSSL-1.0.2a EVP routines to encrypt and decrypt passwords
with cipher des_ede3_cbc as follows:

encrypt routines:
EVP_CIPHER_CTX_init
EVP_EncryptInit_ex
EVP_EncryptUpdate
EVP_EncryptFinal_ex
EVP_CIPHER_CTX_cleanup

decrypt routines:
EVP_CIPHER_CTX_init
EVP_DecryptInit_ex
EVP_DecryptUpdate
EVP_DecryptFinal_ex
EVP_CIPHER_CTX_cleanup

similar to examples found here:
http://www.openssl.org/docs/crypto/EVP_CIPHER_CTX_init.html#EXAMPLES

Passwords are encrypted and stored when created, and decrypted
at a later time to compare against the password
given upon login. None of the examples show determining the length
of the encrypted information via an EVP call in order to pass
that information to the decryption routines. Should I assume it
is incumbent upon the coder to store the encrypted length when
storing the encrypted password, for retrieval later? Or is the encrypted
length put into the encrypted information so an EVP call is available to
retrieve it? I believe from all the information I see that it is the former.

Please confirm this for me.

Also, is calling OpenSSL_add_all_algorithms (or OpenSSL_add_all_ciphers)
and the corresponding EVP_cleanup call necessary for each encrypt and
decrypt? My encryption and decryption seem to be working without calling
those routines but after seeing them used (for examples in test/evp_test.c), I don't understand why.

Any insight that can be shared would be most appreciated.
Thank you.

Phil Bellino
Principal Software Engineer | MRV Communications Inc.
300 Apollo Drive |  Chelmsford, MA 01824
Phone: 978-674-6870  |   Fax: 978-674-6799
www.mrv.com


[MRV-email]


[E-Banner]<http://www.mrv.com/landing/video-datasheet-mrvs-optidriver-platform>


The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150326/3673f4e7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6563 bytes
Desc: image001.png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150326/3673f4e7/attachment-0001.png>

From jonetsu at teksavvy.com  Thu Mar 26 15:09:46 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Thu, 26 Mar 2015 11:09:46 -0400
Subject: [openssl-users] FIPS: Any setup required for using a default DRBG ?
Message-ID: <36e68e249c66398555e08844bfacbdf6@teksavvy.com>

Hello,

? Is FIPS_mode_set(1) taking care of setting up a default DRBG ?? Would a subsequent call to RAND_pseudo_bytes() for instance be using the default DRBG ( 256-bit CTR AES ?) There are quite a few DRBG-related FIPS methods described in the User Guide, and one that is called FIPS_get_default_drbg().? Does this have to be actually called ?? I'm asking since I added in crypto/o_fips.c a FIPS_post_set_callback() in FIPS_set_mode() with a case switch on FIPS_TEST_DRBG (amongst others).? SHA256, HMAC-SHA256, AES-128-CBC, AES-256-CTR amongst others are reported to be tested, although there's no sign of the FIPS_TEST_DRBG.? Nor FIPS_TEST_CONTINUOUS for that matter.? Wouldn't the DRBG be tested in a 'continuous' way before each use ?? - thanks.

Regards.




From foleyj at cisco.com  Thu Mar 26 15:30:57 2015
From: foleyj at cisco.com (John Foley)
Date: Thu, 26 Mar 2015 11:30:57 -0400
Subject: [openssl-users] FIPS Linux kernel documentation ?
In-Reply-To: <55141E58.7020709@openssl.com>
References: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>
 <55132288.3040004@openssl.com> <20150325182600.6a67ba25@mevla>
 <55141E58.7020709@openssl.com>
Message-ID: <55142631.4090407@cisco.com>

We looked at this very briefly a couple of years ago.  In theory, there 
may be a way to achieve the goal as a loadable kernel module (a.k.a. 
device driver).  The idea would be to have a kernel module that provides 
crypto support.  This kernel module would be the FIPS object module, 
with the FIPS boundary drawn around the kernel module.  This would be 
loaded at run time like any other device driver when FIPS mode needed to 
be enabled.

There is likely some kernel work required to allow the ciphers in the 
kernel module to be injected into the crypto flow within the kernel.  
The other issue is getting the kernel to automatically run the FIPS 
integrity test on the module at load time.



On 03/26/2015 10:57 AM, Steve Marquess wrote:
> On 03/25/2015 06:26 PM, jonetsu at teksavvy.com wrote:
>> On Wed, 25 Mar 2015 17:03:04 -0400
>> Steve Marquess <marquess at openssl.com> wrote:
>>
>>> I wasn't aware the Linux kernel (the real one, not proprietary
>>> commercial derivatives) had a "FIPS" mode. Please enlighten me.
>> It could very well be that the word 'mode' is not the right one.
>> 'option' would perhaps be better.  This article from 2009 sets the
>> foundation:
>>
>> http://www.guerilla-ciso.com/archives/793
>>
>> I wonder, 6 years later, what the kernel fips option implies.  Maybe I
>> could try to contact Neil Horman and?or look into the sources.
> That reference gives a pretty good explanation. CONFIG_CRYPTO_FIPS
> doesn't get you any closer to FIPS 140-2 validated kernel cryptography.
>
> Unfortunately FIPS 140-2 validation conflicts rather violently with open
> source software (and with software engineering best practice in general,
> for that matter). Even if some benevolent benefactor ponied up the
> quarter megabuck it would take to do an open source based kernel crypto
> validation, it would be fossilized code obsolete before the validation
> was even approved. Linux got to be as good as it is due to constant
> refinement and improvement; FIPS validation presumes that it is possible
> to write perfect code in one shot and that the environment that code
> runs in never changes.
>
> -Steve M.
>


From crashedmind at gmail.com  Thu Mar 26 15:48:52 2015
From: crashedmind at gmail.com (Chris Madden)
Date: Thu, 26 Mar 2015 15:48:52 +0000
Subject: [openssl-users] openssl 1.0.2a CMS encrypt with ECDH EnvelopedData
	fails?
Message-ID: <CAN-hSCzsoabSR+xZUZgEtMMTPan-7d3CA=xNYDMYLEovb_LmDQ@mail.gmail.com>

Hi,
I am playing with openssl 1.0.2a - specifically CMS support for ECC.
But what I think should work doesn't.
Commands used and parsed data shown.
(I gave an RSA example as a known good working example)

./openssl version
OpenSSL 1.0.2a 19 Mar 2015

echo -n 12345678123456781234567812345678 > sess.txt # 32 byte plaintext


#EC fails
================
  ./openssl ecparam -name prime192v1 -genkey -out ecc.key
  ./openssl req -x509 -new -key ecc.key -out ecc.crt
  ./openssl cms -encrypt -in sess.txt -out encsess.bin -outform PEM ecc.crt
  ./openssl cms -decrypt -in encsess.bin -out decsess.txt -inform PEM
-inkey ecc.key
Error decrypting CMS structure
error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad
decrypt:evp_enc.c:529:


EnvelopedData
----------------------
./openssl asn1parse -in encsess.bin
    0:d=0  hl=4 l= 312 cons: SEQUENCE
    4:d=1  hl=2 l=   9 prim: OBJECT            :pkcs7-envelopedData
   15:d=1  hl=4 l= 297 cons: cont [ 0 ]
   19:d=2  hl=4 l= 293 cons: SEQUENCE
   23:d=3  hl=2 l=   1 prim: INTEGER           :02
   26:d=3  hl=3 l= 234 cons: SET
   29:d=4  hl=3 l= 231 cons: cont [ 1 ]
   32:d=5  hl=2 l=   1 prim: INTEGER           :03
   35:d=5  hl=2 l=  65 cons: cont [ 0 ]
   37:d=6  hl=2 l=  63 cons: cont [ 1 ]
   39:d=7  hl=2 l=   9 cons: SEQUENCE
   41:d=8  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
   50:d=7  hl=2 l=  50 prim: BIT STRING
  102:d=5  hl=2 l=  28 cons: SEQUENCE
  104:d=6  hl=2 l=   9 prim: OBJECT
 :dhSinglePass-stdDH-sha1kdf-scheme
  115:d=6  hl=2 l=  15 cons: SEQUENCE
  117:d=7  hl=2 l=  11 prim: OBJECT            :id-smime-alg-CMS3DESwrap
  130:d=7  hl=2 l=   0 prim: NULL
  132:d=5  hl=3 l= 128 cons: SEQUENCE
  135:d=6  hl=2 l= 126 cons: SEQUENCE
  137:d=7  hl=2 l=  82 cons: SEQUENCE
  139:d=8  hl=2 l=  69 cons: SEQUENCE
  141:d=9  hl=2 l=  11 cons: SET
  143:d=10 hl=2 l=   9 cons: SEQUENCE
  145:d=11 hl=2 l=   3 prim: OBJECT            :countryName
  150:d=11 hl=2 l=   2 prim: PRINTABLESTRING   :AU
  154:d=9  hl=2 l=  19 cons: SET
  156:d=10 hl=2 l=  17 cons: SEQUENCE
  158:d=11 hl=2 l=   3 prim: OBJECT            :stateOrProvinceName
  163:d=11 hl=2 l=  10 prim: UTF8STRING        :Some-State
  175:d=9  hl=2 l=  33 cons: SET
  177:d=10 hl=2 l=  31 cons: SEQUENCE
  179:d=11 hl=2 l=   3 prim: OBJECT            :organizationName
  184:d=11 hl=2 l=  24 prim: UTF8STRING        :Internet Widgits Pty Ltd
  210:d=8  hl=2 l=   9 prim: INTEGER           :C09819AB3ECC9A05
  221:d=7  hl=2 l=  40 prim: OCTET STRING      [HEX
DUMP]:2511DF2DBEC0F758E8CE3F35ECDD84757DEEC011633478BF00C18226FEDCD19BE5ABECEB9A735F99
  263:d=3  hl=2 l=  51 cons: SEQUENCE
  265:d=4  hl=2 l=   9 prim: OBJECT            :pkcs7-data
  276:d=4  hl=2 l=  20 cons: SEQUENCE
  278:d=5  hl=2 l=   8 prim: OBJECT            :des-ede3-cbc
  288:d=5  hl=2 l=   8 prim: OCTET STRING      [HEX DUMP]:E924DA6FC08FC3AC
  298:d=4  hl=2 l=  16 prim: cont [ 0 ]
cmadden at ubuntu:~/openssl-1.0.2a/apps$



Private Key
----------------
cat ecc.key
-----BEGIN EC PARAMETERS-----
BggqhkjOPQMBAQ==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MF8CAQEEGM+L8hosGlnyrOjVsCfQ5kaj42XQ1182b6AKBggqhkjOPQMBAaE0AzIA
BMVGw0n/7hFdEkgi3wGOueh9P4FGBp1qL6ibDcaQUd9R6W+rFKM5LPnZ7awp2URt
sw==
-----END EC PRIVATE KEY-----


Public Key Cert
------------------------
./openssl asn1parse -in ecc.crt
    0:d=0  hl=4 l= 434 cons: SEQUENCE
    4:d=1  hl=4 l= 359 cons: SEQUENCE
    8:d=2  hl=2 l=   3 cons: cont [ 0 ]
   10:d=3  hl=2 l=   1 prim: INTEGER           :02
   13:d=2  hl=2 l=   9 prim: INTEGER           :C09819AB3ECC9A05
   24:d=2  hl=2 l=  10 cons: SEQUENCE
   26:d=3  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
   36:d=2  hl=2 l=  69 cons: SEQUENCE
   38:d=3  hl=2 l=  11 cons: SET
   40:d=4  hl=2 l=   9 cons: SEQUENCE
   42:d=5  hl=2 l=   3 prim: OBJECT            :countryName
   47:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :AU
   51:d=3  hl=2 l=  19 cons: SET
   53:d=4  hl=2 l=  17 cons: SEQUENCE
   55:d=5  hl=2 l=   3 prim: OBJECT            :stateOrProvinceName
   60:d=5  hl=2 l=  10 prim: UTF8STRING        :Some-State
   72:d=3  hl=2 l=  33 cons: SET
   74:d=4  hl=2 l=  31 cons: SEQUENCE
   76:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
   81:d=5  hl=2 l=  24 prim: UTF8STRING        :Internet Widgits Pty Ltd
  107:d=2  hl=2 l=  30 cons: SEQUENCE
  109:d=3  hl=2 l=  13 prim: UTCTIME           :150326134803Z
  124:d=3  hl=2 l=  13 prim: UTCTIME           :150425134803Z
  139:d=2  hl=2 l=  69 cons: SEQUENCE
  141:d=3  hl=2 l=  11 cons: SET
  143:d=4  hl=2 l=   9 cons: SEQUENCE
  145:d=5  hl=2 l=   3 prim: OBJECT            :countryName
  150:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :AU
  154:d=3  hl=2 l=  19 cons: SET
  156:d=4  hl=2 l=  17 cons: SEQUENCE
  158:d=5  hl=2 l=   3 prim: OBJECT            :stateOrProvinceName
  163:d=5  hl=2 l=  10 prim: UTF8STRING        :Some-State
  175:d=3  hl=2 l=  33 cons: SET
  177:d=4  hl=2 l=  31 cons: SEQUENCE
  179:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
  184:d=5  hl=2 l=  24 prim: UTF8STRING        :Internet Widgits Pty Ltd
  210:d=2  hl=2 l=  73 cons: SEQUENCE
  212:d=3  hl=2 l=  19 cons: SEQUENCE
  214:d=4  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
  223:d=4  hl=2 l=   8 prim: OBJECT            :prime192v1
  233:d=3  hl=2 l=  50 prim: BIT STRING
  285:d=2  hl=2 l=  80 cons: cont [ 3 ]
  287:d=3  hl=2 l=  78 cons: SEQUENCE
  289:d=4  hl=2 l=  29 cons: SEQUENCE
  291:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Key
Identifier
  296:d=5  hl=2 l=  22 prim: OCTET STRING      [HEX
DUMP]:0414E7FF07F301CFA245981893B949E46A68EF4FD1B7
  320:d=4  hl=2 l=  31 cons: SEQUENCE
  322:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Authority Key
Identifier
  327:d=5  hl=2 l=  24 prim: OCTET STRING      [HEX
DUMP]:30168014E7FF07F301CFA245981893B949E46A68EF4FD1B7
  353:d=4  hl=2 l=  12 cons: SEQUENCE
  355:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
  360:d=5  hl=2 l=   5 prim: OCTET STRING      [HEX DUMP]:30030101FF
  367:d=1  hl=2 l=  10 cons: SEQUENCE
  369:d=2  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
  379:d=1  hl=2 l=  57 prim: BIT STRING



#RSA works
================
./openssl genrsa -out rsa.key 2048
./openssl req -x509 -new -key rsa.key -out rsa.crt
./openssl cms -encrypt -in sess.txt -out rsaencsess.bin -outform PEM rsa.crt
./openssl cms -decrypt -in rsaencsess.bin -out rsadecsess.txt -inform PEM
-inkey rsa.key
#AOK.


thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150326/7b054748/attachment.html>

From write2mukesh84 at gmail.com  Thu Mar 26 15:48:52 2015
From: write2mukesh84 at gmail.com (Mukesh Yadav)
Date: Thu, 26 Mar 2015 21:18:52 +0530
Subject: [openssl-users] Is RC4-MD5 disabled on Openssl-1.0.1h
In-Reply-To: <20150326145452.GB17637@mournblade.imrryr.org>
References: <CAGsjCKHZxFARSJE+X-6zaZF0+guTzGq_p=_e4uy2X-pnYA622A@mail.gmail.com>
 <20150326095308.GA25483@suse.de>
 <CAGsjCKEj6ZbDcn4eMdhoNr-pO5racUyGAM+4n3f1dnAkDVa0sA@mail.gmail.com>
 <e714bec7d3d44f0593d40f7514285e8e@usma1ex-dag1mb2.msg.corp.akamai.com>
 <CAGsjCKHs7Oy_4OePXegsZ1gwyoJBcY_gq3Ad9cwwME-+Wd3KgA@mail.gmail.com>
 <20150326145452.GB17637@mournblade.imrryr.org>
Message-ID: <CAGsjCKFWqQLSwqSv6-oVW82-HQuWSqG5XtoN79C3NMedNAFXYg@mail.gmail.com>

Thanks Viktor for clarification.
So in  case we need to use SSL_CTX_set_cipher_list(), we should use : for
multiple Ciphers.
and + working in old releases for same scenario can be treated as bug..

Thanks
Mukesh

On 26 March 2015 at 20:24, Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Thu, Mar 26, 2015 at 07:56:38PM +0530, Mukesh Yadav wrote:
>
> > :~/openssl-0.9.8d_install/usr/local/bin# ./openssl ciphers
> RC4-MD5+RC4-SHA
> > -v
> >
> > RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
> >
> > RC4-MD5                 SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
> >
> > RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
>
> That's a bug.  Between two ciphers "+" means "AND".  Right after
> ":" a "+" means "move to the end".  No cipher is both RC4-MD5 AND
> RC4-SHA.
>
> --
>         Viktor.
> _______________________________________________
> 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/20150326/c7dfa248/attachment-0001.html>

From marquess at openssl.com  Thu Mar 26 15:56:28 2015
From: marquess at openssl.com (Steve Marquess)
Date: Thu, 26 Mar 2015 11:56:28 -0400
Subject: [openssl-users] FIPS Linux kernel documentation ?
In-Reply-To: <55142631.4090407@cisco.com>
References: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>
 <55132288.3040004@openssl.com> <20150325182600.6a67ba25@mevla>
 <55141E58.7020709@openssl.com> <55142631.4090407@cisco.com>
Message-ID: <55142C2C.7020802@openssl.com>

On 03/26/2015 11:30 AM, John Foley wrote:
> We looked at this very briefly a couple of years ago.  In theory, there
> may be a way to achieve the goal as a loadable kernel module (a.k.a.
> device driver).  The idea would be to have a kernel module that provides
> crypto support.  This kernel module would be the FIPS object module,
> with the FIPS boundary drawn around the kernel module.  This would be
> loaded at run time like any other device driver when FIPS mode needed to
> be enabled.
> 
> There is likely some kernel work required to allow the ciphers in the
> kernel module to be injected into the crypto flow within the kernel. 
> The other issue is getting the kernel to automatically run the FIPS
> integrity test on the module at load time.

We looked at it in quite a bit of detail about two years ago also, to
the point of developing a formal proposal for a prospective sponsor.

Yes, a loadable module is the way to go. We had worked out how to do the
POST at module load (including an actual implementation).

But, as with any open source based FIPS validation it would have been
expensive and risky, and the end result would still have been fossilized
code that would always be a painfully awkward fit in the Linux
ecosystem. We'd still consider tackling that, with financial
sponsorship, but we have no prospects for such.

-Steve M.

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

From meissner at suse.de  Thu Mar 26 17:00:55 2015
From: meissner at suse.de (Marcus Meissner)
Date: Thu, 26 Mar 2015 18:00:55 +0100
Subject: [openssl-users] FIPS Linux kernel documentation ?
In-Reply-To: <55141E58.7020709@openssl.com>
References: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>
 <55132288.3040004@openssl.com> <20150325182600.6a67ba25@mevla>
 <55141E58.7020709@openssl.com>
Message-ID: <20150326170055.GE5730@suse.de>

On Thu, Mar 26, 2015 at 10:57:28AM -0400, Steve Marquess wrote:
> On 03/25/2015 06:26 PM, jonetsu at teksavvy.com wrote:
> > On Wed, 25 Mar 2015 17:03:04 -0400
> > Steve Marquess <marquess at openssl.com> wrote:
> > 
> >> I wasn't aware the Linux kernel (the real one, not proprietary
> >> commercial derivatives) had a "FIPS" mode. Please enlighten me.
> > 
> > It could very well be that the word 'mode' is not the right one.
> > 'option' would perhaps be better.  This article from 2009 sets the
> > foundation:
> > 
> > http://www.guerilla-ciso.com/archives/793
> > 
> > I wonder, 6 years later, what the kernel fips option implies.  Maybe I
> > could try to contact Neil Horman and?or look into the sources.
> 
> That reference gives a pretty good explanation. CONFIG_CRYPTO_FIPS
> doesn't get you any closer to FIPS 140-2 validated kernel cryptography.
> 
> Unfortunately FIPS 140-2 validation conflicts rather violently with open
> source software (and with software engineering best practice in general,
> for that matter). Even if some benevolent benefactor ponied up the
> quarter megabuck it would take to do an open source based kernel crypto
> validation, it would be fossilized code obsolete before the validation
> was even approved. Linux got to be as good as it is due to constant
> refinement and improvement; FIPS validation presumes that it is possible
> to write perfect code in one shot and that the environment that code
> runs in never changes.

This is not true.

Both Redhat and SUSE have certified or are currently in the process of
certifying the Linux Kernel as a cryptographic module and it is not
as hard as you make it.

The scope is the cryptographic module abstraction layer and even includes
loadable modules. Integrity checking is done in the initrd for vmlinuz
and via the module signatures also used for UEFI secure boot.
crypto/testmgr.c contains the power up selftests.

CAVS testing is external, driven over a specific kernel module.

There is no binary only blob involved, the paper work will however list
an explicit version of a specific kernel release.

And the bucks are more in the low 5 digit bucks range.

FWIW, here is Redhats last security policy:
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1901.pdf

Ciao, Marcus

From marquess at openssl.com  Thu Mar 26 17:13:44 2015
From: marquess at openssl.com (Steve Marquess)
Date: Thu, 26 Mar 2015 13:13:44 -0400
Subject: [openssl-users] FIPS Linux kernel documentation ?
In-Reply-To: <20150326170055.GE5730@suse.de>
References: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>
 <55132288.3040004@openssl.com> <20150325182600.6a67ba25@mevla>
 <55141E58.7020709@openssl.com> <20150326170055.GE5730@suse.de>
Message-ID: <55143E48.3020106@openssl.com>

On 03/26/2015 01:00 PM, Marcus Meissner wrote:
> ...
>>
>> Unfortunately FIPS 140-2 validation conflicts rather violently with open
>> source software (and with software engineering best practice in general,
>> for that matter). Even if some benevolent benefactor ponied up the
>> quarter megabuck it would take to do an open source based kernel crypto
>> validation, it would be fossilized code obsolete before the validation
>> was even approved. Linux got to be as good as it is due to constant
>> refinement and improvement; FIPS validation presumes that it is possible
>> to write perfect code in one shot and that the environment that code
>> runs in never changes.
> 
> This is not true.
> 
> Both Redhat and SUSE have certified or are currently in the process of
> certifying the Linux Kernel as a cryptographic module and it is not
> as hard as you make it.
> 
> ...

As you note *binary* validations are a lot easier. Many such Level 1
software validations have been done (something like a thousand),
including ones by Red Hat, SuSE, and hundreds of "private label"
*binary* validations based on the OpenSSL FIPS Object Module (many using
that code verbatium). In fact the majority of all Level 1 software
validations are derived from OpenSSL code. We've done a number of those
private label vaildations ourselves, incidentally.

But, as someone who has been at ground zero of each of the only open
source based FIPS 140-2 validations that have ever been done I can tell
you that those are *much* harder.

-Steve M.

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

From jb-openssl at wisemo.com  Thu Mar 26 17:41:00 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 26 Mar 2015 18:41:00 +0100
Subject: [openssl-users] FIPS Linux kernel documentation ?
In-Reply-To: <55142C2C.7020802@openssl.com>
References: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>
 <55132288.3040004@openssl.com> <20150325182600.6a67ba25@mevla>
 <55141E58.7020709@openssl.com> <55142631.4090407@cisco.com>
 <55142C2C.7020802@openssl.com>
Message-ID: <551444AC.2020001@wisemo.com>

On 26/03/2015 16:56, Steve Marquess wrote:
> On 03/26/2015 11:30 AM, John Foley wrote:
>> We looked at this very briefly a couple of years ago.  In theory, there
>> may be a way to achieve the goal as a loadable kernel module (a.k.a.
>> device driver).  The idea would be to have a kernel module that provides
>> crypto support.  This kernel module would be the FIPS object module,
>> with the FIPS boundary drawn around the kernel module.  This would be
>> loaded at run time like any other device driver when FIPS mode needed to
>> be enabled.
>>
>> There is likely some kernel work required to allow the ciphers in the
>> kernel module to be injected into the crypto flow within the kernel.
>> The other issue is getting the kernel to automatically run the FIPS
>> integrity test on the module at load time.
> We looked at it in quite a bit of detail about two years ago also, to
> the point of developing a formal proposal for a prospective sponsor.
>
> Yes, a loadable module is the way to go. We had worked out how to do the
> POST at module load (including an actual implementation).
>
> But, as with any open source based FIPS validation it would have been
> expensive and risky, and the end result would still have been fossilized
> code that would always be a painfully awkward fit in the Linux
> ecosystem. We'd still consider tackling that, with financial
> sponsorship, but we have no prospects for such.
>
> -Steve M.
>
Hypothetically speaking, would it be possible to use the
OpenSSL FIPS module with an appropriate "outside the boundary"
kernel module wrapper around it to form "yet another platform"
for one of the validation numbers?

Technically, the kernel module wrapper would interact with the
same blob "API" that a FIPS-enabled OpenSSL uses, so there
would be little or no change to FIPS module build and "security
guide" for such additional kernel mode platforms.  "Inside the
boundary" changes would be needed only to the extent that the
FIPS blob makes direct system calls, since the kernel is not a
normal POSIX-like environment when seen from a kernel mode
module.

If the CMVP bureaucracy insists on a specific kernel version
for the platform number, this should be one of the "Long Term
Support" kernel releases to maximize longevity (assuming that
regular OS patching within a version number is still accepted
as "same platform").



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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/20150326/65e837ab/attachment.html>

From jonetsu at teksavvy.com  Thu Mar 26 18:57:30 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Thu, 26 Mar 2015 14:57:30 -0400
Subject: [openssl-users] FIPS: Any setup required for using a default
	DRBG ?
In-Reply-To: <36e68e249c66398555e08844bfacbdf6@teksavvy.com>
References: <36e68e249c66398555e08844bfacbdf6@teksavvy.com>
Message-ID: <5b30ac97481cbc666491a7a5fca33f28@teksavvy.com>



> From: jonetsu <jonetsu at teksavvy.com> 
> Date: 03/26/15 11:11 

> ? Is FIPS_mode_set(1) taking care of setting up a default DRBG ?? 

Yes. It does.? When using post_cb() from fips_test_suite.c in for instance the fips_hmac.c demo, with only but a FIPS_mode_set(1) call, it is reported that the four DRBGs are tested: DRBG AES-256-CTR DF, DRBG AES-256-CTR, DRBG SHA256 and DRBG HMAC-SHA256, amongst others.

After FIPS_mode_set(1) is executed along with the POST tests, a call to RAND_pseudo_bytes() will not run the tests again.? In this context, when do occur the DRBG continuous tests as shown in table 6b of the 2.0.9 Security Policy ?? Is there a need to actually call FIPS_selftest() ?

Regards.






From steve at openssl.org  Thu Mar 26 20:14:36 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 26 Mar 2015 20:14:36 +0000
Subject: [openssl-users] openssl 1.0.2a CMS encrypt with ECDH
 EnvelopedData fails?
In-Reply-To: <CAN-hSCzsoabSR+xZUZgEtMMTPan-7d3CA=xNYDMYLEovb_LmDQ@mail.gmail.com>
References: <CAN-hSCzsoabSR+xZUZgEtMMTPan-7d3CA=xNYDMYLEovb_LmDQ@mail.gmail.com>
Message-ID: <20150326201436.GA21856@openssl.org>

On Thu, Mar 26, 2015, Chris Madden wrote:

> Hi,
> I am playing with openssl 1.0.2a - specifically CMS support for ECC.
> But what I think should work doesn't.
> Commands used and parsed data shown.
> (I gave an RSA example as a known good working example)
> 
> ./openssl version
> OpenSSL 1.0.2a 19 Mar 2015
> 
> echo -n 12345678123456781234567812345678 > sess.txt # 32 byte plaintext
> 
> 
> #EC fails
> ================
>   ./openssl ecparam -name prime192v1 -genkey -out ecc.key
>   ./openssl req -x509 -new -key ecc.key -out ecc.crt
>   ./openssl cms -encrypt -in sess.txt -out encsess.bin -outform PEM ecc.crt
>   ./openssl cms -decrypt -in encsess.bin -out decsess.txt -inform PEM
> -inkey ecc.key
> Error decrypting CMS structure
> error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad
> decrypt:evp_enc.c:529:
> 

RSA can decrypt without knowing the certificate but currently EC cannot. So
try including the option -recip ecc.crt when you decrypt.

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

From marquess at openssl.com  Thu Mar 26 21:29:50 2015
From: marquess at openssl.com (Steve Marquess)
Date: Thu, 26 Mar 2015 17:29:50 -0400
Subject: [openssl-users] FIPS Linux kernel documentation ?
In-Reply-To: <551444AC.2020001@wisemo.com>
References: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>
 <55132288.3040004@openssl.com> <20150325182600.6a67ba25@mevla>
 <55141E58.7020709@openssl.com> <55142631.4090407@cisco.com>
 <55142C2C.7020802@openssl.com> <551444AC.2020001@wisemo.com>
Message-ID: <55147A4E.3060209@openssl.com>

On 03/26/2015 01:41 PM, Jakob Bohm wrote:
> On 26/03/2015 16:56, Steve Marquess wrote:
>> On 03/26/2015 11:30 AM, John Foley wrote:
>>> We looked at this very briefly a couple of years ago.  In theory, there
>>> may be a way to achieve the goal as a loadable kernel module (a.k.a.
>>> device driver).  The idea would be to have a kernel module that provides
>>> crypto support.  This kernel module would be the FIPS object module,
>>> with the FIPS boundary drawn around the kernel module.  This would be
>>> loaded at run time like any other device driver when FIPS mode needed to
>>> be enabled.
>>>
>>> There is likely some kernel work required to allow the ciphers in the
>>> kernel module to be injected into the crypto flow within the kernel.
>>> The other issue is getting the kernel to automatically run the FIPS
>>> integrity test on the module at load time.
>> We looked at it in quite a bit of detail about two years ago also, to
>> the point of developing a formal proposal for a prospective sponsor.
>>
>> Yes, a loadable module is the way to go. We had worked out how to do the
>> POST at module load (including an actual implementation).
>>
>> But, as with any open source based FIPS validation it would have been
>> expensive and risky, and the end result would still have been fossilized
>> code that would always be a painfully awkward fit in the Linux
>> ecosystem. We'd still consider tackling that, with financial
>> sponsorship, but we have no prospects for such.
>>
>> -Steve M.
>>
> Hypothetically speaking, would it be possible to use the
> OpenSSL FIPS module with an appropriate "outside the boundary"
> kernel module wrapper around it to form "yet another platform"
> for one of the validation numbers?

Possibly. The approach we tentatively settled on was to keep and
validate the existing kernel crypto code (non OpenSSL!) with the cruft
to satisfy FIPS 140-2 (the POST, and also the test suite software for
the algorithm testing). The hard part isn't the crypto code; it's
everything else. By keeping the existing interoperable crypto API we'd
get the most bank for the buck.

> Technically, the kernel module wrapper would interact with the
> same blob "API" that a FIPS-enabled OpenSSL uses, so there
> would be little or no change to FIPS module build and "security
> guide" for such additional kernel mode platforms.  "Inside the
> boundary" changes would be needed only to the extent that the
> FIPS blob makes direct system calls, since the kernel is not a
> normal POSIX-like environment when seen from a kernel mode
> module.

This could work if you weren't worried about compatibility with existing
kernel crypto usage. The current OpenSSL FIPS module code would still
need non-trivial massaging though.

> If the CMVP bureaucracy insists on a specific kernel version
> for the platform number, this should be one of the "Long Term
> Support" kernel releases to maximize longevity (assuming that
> regular OS patching within a version number is still accepted
> as "same platform").

Worse: it would need to be validated on every "Operational Environment"
(OE): meaning every Linux distribution: Debian N.M for every N and M,
Fedora N.M, Ubuntu N.M, CentOS N.M, ...

-Steve M.

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

From jb-openssl at wisemo.com  Thu Mar 26 21:44:51 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 26 Mar 2015 22:44:51 +0100
Subject: [openssl-users] FIPS Linux kernel documentation ?
In-Reply-To: <55147A4E.3060209@openssl.com>
References: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>
 <55132288.3040004@openssl.com> <20150325182600.6a67ba25@mevla>
 <55141E58.7020709@openssl.com> <55142631.4090407@cisco.com>
 <55142C2C.7020802@openssl.com> <551444AC.2020001@wisemo.com>
 <55147A4E.3060209@openssl.com>
Message-ID: <55147DD3.5080409@wisemo.com>

On 26/03/2015 22:29, Steve Marquess wrote:
> On 03/26/2015 01:41 PM, Jakob Bohm wrote:
>> On 26/03/2015 16:56, Steve Marquess wrote:
>>> On 03/26/2015 11:30 AM, John Foley wrote:
>>>> We looked at this very briefly a couple of years ago.  In theory, there
>>>> may be a way to achieve the goal as a loadable kernel module (a.k.a.
>>>> device driver).  The idea would be to have a kernel module that provides
>>>> crypto support.  This kernel module would be the FIPS object module,
>>>> with the FIPS boundary drawn around the kernel module.  This would be
>>>> loaded at run time like any other device driver when FIPS mode needed to
>>>> be enabled.
>>>>
>>>> There is likely some kernel work required to allow the ciphers in the
>>>> kernel module to be injected into the crypto flow within the kernel.
>>>> The other issue is getting the kernel to automatically run the FIPS
>>>> integrity test on the module at load time.
>>> We looked at it in quite a bit of detail about two years ago also, to
>>> the point of developing a formal proposal for a prospective sponsor.
>>>
>>> Yes, a loadable module is the way to go. We had worked out how to do the
>>> POST at module load (including an actual implementation).
>>>
>>> But, as with any open source based FIPS validation it would have been
>>> expensive and risky, and the end result would still have been fossilized
>>> code that would always be a painfully awkward fit in the Linux
>>> ecosystem. We'd still consider tackling that, with financial
>>> sponsorship, but we have no prospects for such.
>>>
>>> -Steve M.
>>>
>> Hypothetically speaking, would it be possible to use the
>> OpenSSL FIPS module with an appropriate "outside the boundary"
>> kernel module wrapper around it to form "yet another platform"
>> for one of the validation numbers?
> Possibly. The approach we tentatively settled on was to keep and
> validate the existing kernel crypto code (non OpenSSL!) with the cruft
> to satisfy FIPS 140-2 (the POST, and also the test suite software for
> the algorithm testing). The hard part isn't the crypto code; it's
> everything else. By keeping the existing interoperable crypto API we'd
> get the most bank for the buck.
>
>> Technically, the kernel module wrapper would interact with the
>> same blob "API" that a FIPS-enabled OpenSSL uses, so there
>> would be little or no change to FIPS module build and "security
>> guide" for such additional kernel mode platforms.  "Inside the
>> boundary" changes would be needed only to the extent that the
>> FIPS blob makes direct system calls, since the kernel is not a
>> normal POSIX-like environment when seen from a kernel mode
>> module.
> This could work if you weren't worried about compatibility with existing
> kernel crypto usage. The current OpenSSL FIPS module code would still
> need non-trivial massaging though.
The point would be that the wrapper takes calls in the
existing Linux kernel form and then implement each such
call in terms of the functionality exposed by the
existing OpenSSL FIPS blob.  For instance if the Linux
kernel has an API that sets up and performs AES CBC
encryption, this would get mapped to OpenSSL FIPS blob
calls that do AES CBC encryption.  This is all
facilitated by the existing ability of the Linux kernel
to support multiple implementations of each needed
primitive.
>> If the CMVP bureaucracy insists on a specific kernel version
>> for the platform number, this should be one of the "Long Term
>> Support" kernel releases to maximize longevity (assuming that
>> regular OS patching within a version number is still accepted
>> as "same platform").
> Worse: it would need to be validated on every "Operational Environment"
> (OE): meaning every Linux distribution: Debian N.M for every N and M,
> Fedora N.M, Ubuntu N.M, CentOS N.M, ...
As the (unpatched upstream) kernel does not rely on the
distribution above it, the platform would not include the
user mode.  This is similar to how a validation for running
inside the core of a virtualization platform such as VMWare
ESXi 5.1 or RedHat N.M libvirt/kvm does not include the
guest OS in the platform for its validation.

Of cause using the validation on a Vendor patched kernel
such as "RedHat N.M patched Linux kernel 3.2" or "Debian 7.8
patched Linux kernel 3.2" would obviously be a different
platform than "kernel.org vanilla Linux kernel 3.2".


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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/20150326/b0412769/attachment.html>

From crashedmind at gmail.com  Thu Mar 26 21:54:24 2015
From: crashedmind at gmail.com (Chris Madden)
Date: Thu, 26 Mar 2015 21:54:24 +0000
Subject: [openssl-users] openssl 1.0.2a CMS encrypt with ECDH
	EnvelopedData fails?
In-Reply-To: <CAN-hSCzsoabSR+xZUZgEtMMTPan-7d3CA=xNYDMYLEovb_LmDQ@mail.gmail.com>
References: <CAN-hSCzsoabSR+xZUZgEtMMTPan-7d3CA=xNYDMYLEovb_LmDQ@mail.gmail.com>
Message-ID: <CAN-hSCy-SOxLwcUa4MZHxJvDmQoFWWHKWydX6aQWxsvMc5TNcQ@mail.gmail.com>

>> Hi,
>> I am playing with openssl 1.0.2a - specifically CMS support for ECC.
>> But what I think should work doesn't.
>> Commands used and parsed data shown.
>> (I gave an RSA example as a known good working example)
>>
>> ./openssl version
>> OpenSSL 1.0.2a 19 Mar 2015
>>
>> echo -n 12345678123456781234567812345678 > sess.txt # 32 byte plaintext
>>
>>
>> #EC fails
>> ================
>>   ./openssl ecparam -name prime192v1 -genkey -out ecc.key
>>   ./openssl req -x509 -new -key ecc.key -out ecc.crt
>>   ./openssl cms -encrypt -in sess.txt -out encsess.bin -outform PEM
ecc.crt
>>   ./openssl cms -decrypt -in encsess.bin -out decsess.txt -inform PEM
>> -inkey ecc.key
>> Error decrypting CMS structure
>> error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad
>> decrypt:evp_enc.c:529:
>>
>
>RSA can decrypt without knowing the certificate but currently EC cannot. So
>try including the option -recip ecc.crt when you decrypt.
>
>Steve.
>--
>Dr Stephen N. Henson. OpenSSL project core developer.
>Commercial tech support now available see: http://www.openssl.org

Many thanks Steve for the prompt response!
That fixed it.
Chris

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

From michel.sales at free.fr  Thu Mar 26 22:02:11 2015
From: michel.sales at free.fr (Michel)
Date: Thu, 26 Mar 2015 23:02:11 +0100
Subject: [openssl-users] Encryption length, OpenSSL_add_all_algorithms,
	and OpenSSL_add_all_ciphers questions
In-Reply-To: <AM3PR03MB0824C6480A0D7D7F28B46DE7C3080@AM3PR03MB0824.eurprd03.prod.outlook.com>
References: <AM3PR03MB0824C6480A0D7D7F28B46DE7C3080@AM3PR03MB0824.eurprd03.prod.outlook.com>
Message-ID: <005b01d06810$83047fe0$890d7fa0$@sales@free.fr>

Hi Phil,

 

> "
 or is the encrypted length put into the encrypted information so an EVP
call is available to retrieve it?"

It is NOT the case.

 

May not be the answer you expected :

The encrypted length is length of clear text + size of 1 cipher block  if
padding is enabled.

https://www.openssl.org/docs/crypto/EVP_EncryptInit.html

 

> "is calling OpenSSL_add_all_algorithms (or OpenSSL_add_all_ciphers) and
the corresponding EVP_cleanup call necessary for each encrypt and  decrypt
?"

NO, and It should NOT, especially in multi-threaded applications  :

"A typical application will call OpenSSL_add_all_algorithms() initially and
EVP_cleanup() before exiting."

https://www.openssl.org/docs/crypto/OpenSSL_add_all_algorithms.html

 

Also :
https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption

 

Hope this helps,

 

Regards,

 

Michel.

 

De : openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de
Philip Bellino
Envoy? : jeudi 26 mars 2015 15:53
? : openssl-users at openssl.org
Objet : [openssl-users] Encryption length, OpenSSL_add_all_algorithms, and
OpenSSL_add_all_ciphers questions

 

I am using OpenSSL-1.0.2a EVP routines to encrypt and decrypt passwords

with cipher des_ede3_cbc as follows:

 

encrypt routines:

EVP_CIPHER_CTX_init

EVP_EncryptInit_ex

EVP_EncryptUpdate

EVP_EncryptFinal_ex

EVP_CIPHER_CTX_cleanup

 

decrypt routines:

EVP_CIPHER_CTX_init

EVP_DecryptInit_ex

EVP_DecryptUpdate

EVP_DecryptFinal_ex

EVP_CIPHER_CTX_cleanup

 

similar to examples found here:

http://www.openssl.org/docs/crypto/EVP_CIPHER_CTX_init.html#EXAMPLES

 

Passwords are encrypted and stored when created, and decrypted

at a later time to compare against the password

given upon login. None of the examples show determining the length

of the encrypted information via an EVP call in order to pass

that information to the decryption routines. Should I assume it

is incumbent upon the coder to store the encrypted length when

storing the encrypted password, for retrieval later? Or is the encrypted

length put into the encrypted information so an EVP call is available to

retrieve it? I believe from all the information I see that it is the former.

 

Please confirm this for me.

 

Also, is calling OpenSSL_add_all_algorithms (or OpenSSL_add_all_ciphers)

and the corresponding EVP_cleanup call necessary for each encrypt and

decrypt? My encryption and decryption seem to be working without calling

those routines but after seeing them used (for examples in test/evp_test.c),
I don't understand why.

 

Any insight that can be shared would be most appreciated.

Thank you.

 

Phil Bellino

Principal Software Engineer | MRV Communications Inc.

300 Apollo Drive |  Chelmsford, MA 01824 

Phone: 978-674-6870  |   Fax: 978-674-6799

www.mrv.com

 

MRV-email

 

 

 <http://www.mrv.com/landing/video-datasheet-mrvs-optidriver-platform> Image
supprim?e par l'exp?diteur. E-Banner
 

The contents of this message, together with any attachments, are intended
only for the use of the person(s) to whom they are addressed and may contain
confidential and/or privileged information. If you are not the intended
recipient, immediately advise the sender, delete this message and any
attachments and note that any distribution, or copying of this message, or
any attachment, is prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150326/680c82b8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150326/680c82b8/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6563 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150326/680c82b8/attachment-0001.png>

From richmoore44 at gmail.com  Thu Mar 26 22:46:13 2015
From: richmoore44 at gmail.com (Richard Moore)
Date: Thu, 26 Mar 2015 22:46:13 +0000
Subject: [openssl-users] Encryption length, OpenSSL_add_all_algorithms,
 and OpenSSL_add_all_ciphers questions
In-Reply-To: <AM3PR03MB0824C6480A0D7D7F28B46DE7C3080@AM3PR03MB0824.eurprd03.prod.outlook.com>
References: <AM3PR03MB0824C6480A0D7D7F28B46DE7C3080@AM3PR03MB0824.eurprd03.prod.outlook.com>
Message-ID: <CAMp7mVvF0=Owk-YTpGreyh6VoXLsWoL8=MSLQEbxRosJn4CwDg@mail.gmail.com>

On 26 March 2015 at 14:53, Philip Bellino <pbellino at mrv.com> wrote:

>  I am using OpenSSL-1.0.2a EVP routines to encrypt and decrypt passwords
>
> with cipher des_ede3_cbc as follows:
>
>
>
Your design is fundamentally flawed. You should be hashing passwords using
bcrypt, pbkdf or similar not encrypting them.

Regards

Rich.

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

From noloader at gmail.com  Fri Mar 27 05:05:59 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 26 Mar 2015 22:05:59 -0700
Subject: [openssl-users] ChaCha20/Poly1305 in OpenSSL?
In-Reply-To: <6d15fcf8ed80459292c7e7679f862911@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <CAH8yC8=nh6GOVNineTo-9Jh6-0AsqDpaH+ewUDJyzduwWV-gpw@mail.gmail.com>
 <CADMhe6cXw9r3O2CAR467GrfPkoGYS_=UqFSwa6S4bw_MiqDxtQ@mail.gmail.com>
 <CAH8yC8kGpXDZ5dnqX2UYNkBnDZj2cCRoBLwxDzWLCeYni5kjhQ@mail.gmail.com>
 <54344222.4040301@openssl.org>
 <CAH8yC8=Vv8Ht251_kjGNZd0wQ35vb2StphpTe5KDYbHxyG+4jg@mail.gmail.com>
 <759a6b9a9e574a2e8d51150079ac0509@usma1ex-dag1mb2.msg.corp.akamai.com>
 <CAH8yC8=UnUwNd58LurkwWAZ+x+BZDy3Uz5ZsSzrZL4bv_rz85g@mail.gmail.com>
 <6d15fcf8ed80459292c7e7679f862911@usma1ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CAH8yC8n9h16a0kFS5oNcJpgrKfmkp1fAfX5geiu+q4gusgbrmA@mail.gmail.com>

On Wed, Mar 25, 2015 at 12:36 PM, Salz, Rich <rsalz at akamai.com> wrote:
>> I see Adam Langley's patch here:
>> https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9a8646510b
>>
>> Any ideas why it was not accepted or not merged? (I'm assuming it was not
>> merged because it was rejected for some reason).
>
> I thought his patch came before the IETF final doc, which changed some things.
>
It appears we are also waiting on the cipher suite values. See "Cipher
suite values for ChaCha20/Poly1305?",
http://www.ietf.org/mail-archive/web/tls/current/msg15719.html.

From hgb at ifi.uio.no  Fri Mar 27 08:45:35 2015
From: hgb at ifi.uio.no (Henrik Grindal Bakken)
Date: Fri, 27 Mar 2015 09:45:35 +0100
Subject: [openssl-users] FIPS Linux kernel documentation ?
References: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>
 <55132288.3040004@openssl.com> <20150325182600.6a67ba25@mevla>
 <55141E58.7020709@openssl.com> <55142631.4090407@cisco.com>
 <55142C2C.7020802@openssl.com> <551444AC.2020001@wisemo.com>
 <55147A4E.3060209@openssl.com>
Message-ID: <x2emw2yesls.fsf@vetur.ifi.uio.no>

Steve Marquess <marquess at openssl.com>
writes:

>> If the CMVP bureaucracy insists on a specific kernel version
>> for the platform number, this should be one of the "Long Term
>> Support" kernel releases to maximize longevity (assuming that
>> regular OS patching within a version number is still accepted
>> as "same platform").
>
> Worse: it would need to be validated on every "Operational Environment"
> (OE): meaning every Linux distribution: Debian N.M for every N and M,
> Fedora N.M, Ubuntu N.M, CentOS N.M, ...

Are you certain?  For a user-space component like OpenSSL, this is
obviously true, but I think you could argue that a kernel module's
"Operational Environment" has no relation to the Linux distro, only to
the kernel it's loaded by and the hardware architecture (and perhaps the
compiler).

-- 
Henrik Grindal Bakken <hgb at ifi.uio.no>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52


From piotr.lobacz at radmor.com.pl  Fri Mar 27 10:04:21 2015
From: piotr.lobacz at radmor.com.pl (Piotr =?UTF-8?Q?=C5=81obacz?=)
Date: Fri, 27 Mar 2015 11:04:21 +0100
Subject: [openssl-users] QNX cross-compiled openssl with fips
In-Reply-To: <1427356003.3211.9.camel@piotr-desktop>
References: <1427356003.3211.9.camel@piotr-desktop>
Message-ID: <1427450661.3208.3.camel@piotr-desktop>

Another problem is that compiled cross-compiled OpenSSL with fips should
start in its own prompt but it only spews the expected signature and
exits. I have modified fipsld scripts as shown in the manual and this
does not help. Incore was used from the tarball but maybe i have to use
some special modifications for QNX incore?

Dnia 2015-03-26, czw o godzinie 08:46 +0100, Piotr ?obacz pisze:
> Hello,
> i have been able to cross-compile openssl with fips module and what i
> want now is to use it within my project which is using C++. According to
> the manual https://wiki.openssl.org/index.php/Fipsld_and_C%2B%2B i have
> to modify fipsld to fipsld++. Everything works properly if i'm compiling
> my own libraries which are being linked with static crypto.a but if i'm
> going to compile some tests which are linking with those libraries i get
> this error:
> 
> /usr/lib/fips_premain.o: In function `FINGERPRINT_premain()':
> /usr/lib/fips_premain.c:103: undefined reference to `FIPS_text_start()'
> /usr/lib/fips_premain.c:116: undefined reference to
> `FIPS_incore_fingerprint(unsigned char*, unsigned int)'
> 
> According to the manual, problem occurs with C++ linker, but i have it
> modified in fipsld++ so that now PREMAIN_DSO looks like:
> 
> -x c "${PREMAIN_C}" -x none \
> 
> and this does not help. On Linux with gcc this was helpful but on QNX
> cross compilation it does not.
> 
> I would be pleased if somebody could point me what am i doing wrong...
> 

-- 

________________________________________________________________________
Piotr ?obacz

Biuro System?w i Oprogramowania

RADMOR S.A.

tel. (58) 6996 929

e-mail: piotr.lobacz at radmor.com.pl

www.radmor.com.pl




RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia

NIP: 586-010-21-39

REGON: 190432077

KRS: 0000074029 (S?d Rejonowy Gda?sk-P??noc w Gda?sku)

Kapita? zak?adowy wp?acony: 9 282 830 PLN


From pbellino at mrv.com  Fri Mar 27 12:48:02 2015
From: pbellino at mrv.com (Philip Bellino)
Date: Fri, 27 Mar 2015 12:48:02 +0000
Subject: [openssl-users] Encryption length, OpenSSL_add_all_algorithm,
 and OpenSSL_add_all_ciphers questions
Message-ID: <AM3PR03MB0824F5D3FCDD2F9E1B35264BC3090@AM3PR03MB0824.eurprd03.prod.outlook.com>

Michel,
Thank you very much for your email.
The example given in your email works out fine if the encryption and decryption are performed in the same routine.
The problem we are having is that we perform the encryption and then at some in the future we need to do the decryption.
At that point, we do not have the clear text password available nor do we know the length that was the result of the previous
encryption so we don't have the correct encrypted length value to pass to the decryption routine.
Some passwords have encrypted results that have nulls embedded in them, so strlen() cannot be used on the
encrypted result  to get its length.

Have you come across a situation such as this or is there something else you can suggest to me?

Thanks,
Phil


From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Michel
Sent: Thursday, March 26, 2015 6:02 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Encryption length, OpenSSL_add_all_algorithms, and OpenSSL_add_all_ciphers questions

Hi Phil,

> "... or is the encrypted length put into the encrypted information so an EVP call is available to retrieve it?"
It is NOT the case.

May not be the answer you expected :
The encrypted length is length of clear text + size of 1 cipher block  if padding is enabled.
https://www.openssl.org/docs/crypto/EVP_EncryptInit.html

> "is calling OpenSSL_add_all_algorithms (or OpenSSL_add_all_ciphers) and the corresponding EVP_cleanup call necessary for each encrypt and  decrypt ?"
NO, and It should NOT, especially in multi-threaded applications  :
"A typical application will call OpenSSL_add_all_algorithms() initially and EVP_cleanup() before exiting."
https://www.openssl.org/docs/crypto/OpenSSL_add_all_algorithms.html

Also : https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption

Hope this helps,

Regards,

Michel.

De : openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de Philip Bellino
Envoy? : jeudi 26 mars 2015 15:53
? : openssl-users at openssl.org<mailto:openssl-users at openssl.org>
Objet : [openssl-users] Encryption length, OpenSSL_add_all_algorithms, and OpenSSL_add_all_ciphers questions

I am using OpenSSL-1.0.2a EVP routines to encrypt and decrypt passwords
with cipher des_ede3_cbc as follows:

encrypt routines:
EVP_CIPHER_CTX_init
EVP_EncryptInit_ex
EVP_EncryptUpdate
EVP_EncryptFinal_ex
EVP_CIPHER_CTX_cleanup

decrypt routines:
EVP_CIPHER_CTX_init
EVP_DecryptInit_ex
EVP_DecryptUpdate
EVP_DecryptFinal_ex
EVP_CIPHER_CTX_cleanup

similar to examples found here:
http://www.openssl.org/docs/crypto/EVP_CIPHER_CTX_init.html#EXAMPLES

Passwords are encrypted and stored when created, and decrypted
at a later time to compare against the password
given upon login. None of the examples show determining the length
of the encrypted information via an EVP call in order to pass
that information to the decryption routines. Should I assume it
is incumbent upon the coder to store the encrypted length when
storing the encrypted password, for retrieval later? Or is the encrypted
length put into the encrypted information so an EVP call is available to
retrieve it? I believe from all the information I see that it is the former.

Please confirm this for me.

Also, is calling OpenSSL_add_all_algorithms (or OpenSSL_add_all_ciphers)
and the corresponding EVP_cleanup call necessary for each encrypt and
decrypt? My encryption and decryption seem to be working without calling
those routines but after seeing them used (for examples in test/evp_test.c), I don't understand why.

Any insight that can be shared would be most appreciated.
Thank you.

Phil Bellino
Principal Software Engineer | MRV Communications Inc.
300 Apollo Drive |  Chelmsford, MA 01824
Phone: 978-674-6870  |   Fax: 978-674-6799
www.mrv.com

[MRV-email]


[Image supprim?e par l'exp?diteur. E-Banner]<http://www.mrv.com/landing/video-datasheet-mrvs-optidriver-platform>


The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited.

[E-Banner]<http://www.mrv.com/landing/video-datasheet-mrvs-optidriver-platform>


The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150327/115fa3ca/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6563 bytes
Desc: image001.png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150327/115fa3ca/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 823 bytes
Desc: image002.jpg
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150327/115fa3ca/attachment-0001.jpg>

From marquess at openssl.com  Fri Mar 27 13:03:07 2015
From: marquess at openssl.com (Steve Marquess)
Date: Fri, 27 Mar 2015 09:03:07 -0400
Subject: [openssl-users] FIPS Linux kernel documentation ?
In-Reply-To: <x2emw2yesls.fsf@vetur.ifi.uio.no>
References: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>
 <55132288.3040004@openssl.com> <20150325182600.6a67ba25@mevla>
 <55141E58.7020709@openssl.com> <55142631.4090407@cisco.com>
 <55142C2C.7020802@openssl.com> <551444AC.2020001@wisemo.com>
 <55147A4E.3060209@openssl.com> <x2emw2yesls.fsf@vetur.ifi.uio.no>
Message-ID: <5515550B.4070806@openssl.com>

On 03/27/2015 04:45 AM, Henrik Grindal Bakken wrote:
> Steve Marquess <marquess at openssl.com>
> writes:
> 
>>> If the CMVP bureaucracy insists on a specific kernel version
>>> for the platform number, this should be one of the "Long Term
>>> Support" kernel releases to maximize longevity (assuming that
>>> regular OS patching within a version number is still accepted
>>> as "same platform").
>>
>> Worse: it would need to be validated on every "Operational Environment"
>> (OE): meaning every Linux distribution: Debian N.M for every N and M,
>> Fedora N.M, Ubuntu N.M, CentOS N.M, ...
> 
> Are you certain?  For a user-space component like OpenSSL, this is
> obviously true, but I think you could argue that a kernel module's
> "Operational Environment" has no relation to the Linux distro, only to
> the kernel it's loaded by and the hardware architecture (and perhaps the
> compiler).
> 

Nope, been there done that with the CMVP. When an known distro is in use
(Debian, Fedora, ...) we're (generally) required to use that as the OE
"operating system" name. Which is a bit ironic as a given Linux distro
for a fixed major.minor version number may step through multiple kernel
versions (even from 2.x to 3.x, for instance) during the life cycle of
that major.minor release.

Take a look at table 2 of the #1747 Security Policy (or any other module
with large numbers of platforms, though there aren't many of those).
You'll see multiple Linux distros that share the same Linux kernel. We
didn't do that for fun.

We've only been able to use the Linux kernel version itself as the
"operating system" name and version number in the case of specialty
embedded systems where the product vendor builds their own kernel from
source.

Then ironically vendors are allowed to do "vanity branding" of a
standard distro, for example by rebranding stock "Ubuntu 12.04" as
"AcmeOS 1.1". That vendor can then choose to rebrand Ubuntu 14.04 as
"AcmeOS 1.1.1", which by the unwritten rule of OE equivalence is still
AcmeOS 1.1. That's several kinds of crazy, but it is what it is.

Note the point here holds for a hypothetical kernel module validation,
as it hinges on the CMVP conception of an "OE". You can see that from
the existing kernel module validations.

Incidentally, the trend for the past several years has been for the CMVP
to require ever more specificity in "OE" designations. For instance, the
exact same guest image running on ESXi 5.1 and on ESXi 5.2, for
identical hardware, now constitutes two separate "OEs".

Logic doesn't really apply here...

-Steve M.

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

From hgb at ifi.uio.no  Fri Mar 27 13:30:55 2015
From: hgb at ifi.uio.no (Henrik Grindal Bakken)
Date: Fri, 27 Mar 2015 14:30:55 +0100
Subject: [openssl-users] FIPS Linux kernel documentation ?
References: <94fe750c01a7fdc92b233304c46e8d31@teksavvy.com>
 <55132288.3040004@openssl.com> <20150325182600.6a67ba25@mevla>
 <55141E58.7020709@openssl.com> <55142631.4090407@cisco.com>
 <55142C2C.7020802@openssl.com> <551444AC.2020001@wisemo.com>
 <55147A4E.3060209@openssl.com> <x2emw2yesls.fsf@vetur.ifi.uio.no>
 <5515550B.4070806@openssl.com>
Message-ID: <x2efv8qefe8.fsf@vetur.ifi.uio.no>

Steve Marquess <marquess at openssl.com>
writes:

>> Are you certain?  For a user-space component like OpenSSL, this is
>> obviously true, but I think you could argue that a kernel module's
>> "Operational Environment" has no relation to the Linux distro, only to
>> the kernel it's loaded by and the hardware architecture (and perhaps the
>> compiler).

[...]

> Logic doesn't really apply here...

I can see that...  Oh well, thanks for the explanation.

-- 
Henrik Grindal Bakken <hgb at ifi.uio.no>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52


From michel.sales at free.fr  Fri Mar 27 16:15:01 2015
From: michel.sales at free.fr (Michel)
Date: Fri, 27 Mar 2015 17:15:01 +0100
Subject: [openssl-users] Encryption length, OpenSSL_add_all_algorithm,
	and OpenSSL_add_all_ciphers questions
In-Reply-To: <AM3PR03MB0824F5D3FCDD2F9E1B35264BC3090@AM3PR03MB0824.eurprd03.prod.outlook.com>
References: <AM3PR03MB0824F5D3FCDD2F9E1B35264BC3090@AM3PR03MB0824.eurprd03.prod.outlook.com>
Message-ID: <002101d068a9$2da4ef50$88eecdf0$@sales@free.fr>

Hi Phil,

First, let me emphasized that Richard was rigth in a previous post : it is
not good pratice to compare login info to decrypted password.
It is better NOT to keep user password when possible, and compare login to
salted hash password instead.

As you already know : the encrypted length is length of clear text + size of
1 cipher block if padding is enabled.
As a result, the length of the clear text is allways shorter (or equal) than
the length of the cipher text.
:-)
And the EVP_DecryptFinal() function will NOT count the number of padding
bytes it has removed in the value returned in the 'outl' parameter.
https://www.openssl.org/docs/crypto/EVP_EncryptInit.html
So, to retrieve the total clear text length, you can safely do like the
example at :
https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption
(in this example, it is obviously named 'plaintext_len')

I hope I did not misunderstand you,
And hope this helps,

Regards,

Michel



De?: openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de
Philip Bellino
Envoy??: vendredi 27 mars 2015 13:48
??: openssl-users at openssl.org
Objet?: Re: [openssl-users] Encryption length, OpenSSL_add_all_algorithm,
and OpenSSL_add_all_ciphers questions

Michel,
Thank you very much for your email.
The example given in your email works out fine if the encryption and
decryption are performed in the same routine.
The problem we are having is that we perform the encryption and then at some
in the future we need to do the decryption.
At that point, we do not have the clear text password available nor do we
know the length that was?the result of the previous
encryption so we don't have the correct encrypted length value to pass to
the?decryption?routine.
Some passwords have?encrypted results that?have nulls embedded in them, so
strlen() cannot be used on the
encrypted result??to?get its?length.
?
Have you come across a situation such as this or is there something else you
can suggest to me?
?
Thanks,
Phil


From michel.sales at free.fr  Fri Mar 27 17:26:47 2015
From: michel.sales at free.fr (Michel)
Date: Fri, 27 Mar 2015 18:26:47 +0100
Subject: [openssl-users] Encryption length, OpenSSL_add_all_algorithm,
	and OpenSSL_add_all_ciphers questions
In-Reply-To: <AM3PR03MB0824F5D3FCDD2F9E1B35264BC3090@AM3PR03MB0824.eurprd03.prod.outlook.com>
References: <AM3PR03MB0824F5D3FCDD2F9E1B35264BC3090@AM3PR03MB0824.eurprd03.prod.outlook.com>
Message-ID: <000001d068b3$3475bb70$9d613250$@sales@free.fr>

Hi again Phil,

May be I read your mail too quickly.
> 
 so we don't have the correct encrypted length value to pass to
the?decryption?routine.

How is it possible ?
If you stored the encrypted data, you should at least know the size of what
is in the file or the database column, don't you ?


From michel.sales at free.fr  Fri Mar 27 17:39:29 2015
From: michel.sales at free.fr (Michel)
Date: Fri, 27 Mar 2015 18:39:29 +0100
Subject: [openssl-users] Encryption length, OpenSSL_add_all_algorithm,
	and OpenSSL_add_all_ciphers questions
In-Reply-To: <000001d068b3$3475bb70$9d613250$@sales@free.fr>
References: <AM3PR03MB0824F5D3FCDD2F9E1B35264BC3090@AM3PR03MB0824.eurprd03.prod.outlook.com>
 <000001d068b3$3475bb70$9d613250$@sales@free.fr>
Message-ID: <000101d068b4$faaedc30$f00c9490$@sales@free.fr>

It's me again,
:-)

If you have to store binary data without a way to get the correct length
later, you should instead endode it in a 'textual' form before storage :
base64 or hexa.

Is it what you were asking for ?

-----Message d'origine-----
De?: openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de
Michel
Envoy??: vendredi 27 mars 2015 18:27
??: openssl-users at openssl.org
Objet?: Re: [openssl-users] Encryption length, OpenSSL_add_all_algorithm,
and OpenSSL_add_all_ciphers questions

Hi again Phil,

May be I read your mail too quickly.
> 
 so we don't have the correct encrypted length value to pass to
the?decryption?routine.

How is it possible ?
If you stored the encrypted data, you should at least know the size of what
is in the file or the database column, don't you ?

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


From ljkimmel99 at hotmail.com  Fri Mar 27 19:14:53 2015
From: ljkimmel99 at hotmail.com (Lesley Kimmel)
Date: Fri, 27 Mar 2015 14:14:53 -0500
Subject: [openssl-users] OpenSSL Compile Issues (and general knowledge
	questions)
Message-ID: <SNT147-W3891D5BCC9CA465D4F301C2090@phx.gbl>

All;

I'm an administrator/engineer responsible for compiling Apache with OpenSSL supporting FIPS mode. I've got a good process down that generally works. However, I am looking for a little help on some details because I am not a developer and am not about digging through the source code to figure out these issues.

a) I don't typically run 'make depend' and things seem to work. However, the OpenSSL compile wiki directs to run this command. What will this do for me?
b) I know that I can disable SSLv2 and SSLv3 via Apache itself but I see that there are options (no-ssl2, no-ssl3) that can be used during compilation of OpenSSL which will presumably disable them altogether. However, when compiling this way the 'make test' always fails with some useless error. For example, when compiling just with 'no-ssl2' I get the following:

../util/shlib_wrap.sh ./evp_extra_test
PASS
test SSL protocol
test ssl3 is forbidden in FIPS mode
*** IN FIPS MODE ***
Available compression methods:
  NONE
139934033385128:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips mode:ssl_lib.c:1716:
139934033385128:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips mode:ssl_lib.c:1716:
test ssl2 is forbidden in FIPS mode
Testing was requested for a disabled protocol. Skipping tests.
make[1]: *** [test_ssl] Error 1
make[1]: Leaving directory `/opt/apache_stage/httpd/srclib/openssl/test'
make: *** [tests] Error 2

Is this expected behavior? Is there any way to disable SSLv2/3 while still passing the tests? I feel that passing the tests is pretty important to my confidence in the final product.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150327/2db545ed/attachment.html>

From foleyj at cisco.com  Fri Mar 27 20:05:09 2015
From: foleyj at cisco.com (John Foley)
Date: Fri, 27 Mar 2015 16:05:09 -0400
Subject: [openssl-users] OpenSSL Compile Issues (and general knowledge
 questions)
In-Reply-To: <SNT147-W3891D5BCC9CA465D4F301C2090@phx.gbl>
References: <SNT147-W3891D5BCC9CA465D4F301C2090@phx.gbl>
Message-ID: <5515B7F5.5040308@cisco.com>

The 'make depend' regenerates the dependencies for the makefiles. The 
dependencies will change depending on the configuration options you've 
passed to OpenSSL.  If you're new to using GNU make, here's a decent 
explanation:

http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/

Your second question reflects a problem in the test/testssl script. This 
script is largely unaware of most configuration options (e.g. no-ssl3).  
This script is attempting to run the SSL3 unit tests even though you 
have omitted support for SSL3 in the library.  You may want to open a 
bug in the OpenSSL request tracker 
(https://www.openssl.org/support/rt.html).





On 03/27/2015 03:14 PM, Lesley Kimmel wrote:
> All;
>
> I'm an administrator/engineer responsible for compiling Apache with 
> OpenSSL supporting FIPS mode. I've got a good process down that 
> generally works. However, I am looking for a little help on some 
> details because I am not a developer and am not about digging through 
> the source code to figure out these issues.
>
> a) I don't typically run 'make depend' and things seem to work. 
> However, the OpenSSL compile wiki directs to run this command. What 
> will this do for me?
> b) I know that I can disable SSLv2 and SSLv3 via Apache itself but I 
> see that there are options (no-ssl2, no-ssl3) that can be used during 
> compilation of OpenSSL which will presumably disable them altogether. 
> However, when compiling this way the 'make test' always fails with 
> some useless error. For example, when compiling just with 'no-ssl2' I 
> get the following:
>
> ../util/shlib_wrap.sh ./evp_extra_test
> PASS
> test SSL protocol
> test ssl3 is forbidden in FIPS mode
> *** IN FIPS MODE ***
> Available compression methods:
>   NONE
> 139934033385128:error:140A9129:SSL routines:SSL_CTX_new:only tls 
> allowed in fips mode:ssl_lib.c:1716:
> 139934033385128:error:140A9129:SSL routines:SSL_CTX_new:only tls 
> allowed in fips mode:ssl_lib.c:1716:
> test ssl2 is forbidden in FIPS mode
> Testing was requested for a disabled protocol. Skipping tests.
> make[1]: *** [test_ssl] Error 1
> make[1]: Leaving directory `/opt/apache_stage/httpd/srclib/openssl/test'
> make: *** [tests] Error 2
>
> Is this expected behavior? Is there any way to disable SSLv2/3 while 
> still passing the tests? I feel that passing the tests is pretty 
> important to my confidence in the final product.
>
>
> _______________________________________________
> 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/20150327/b87ed44d/attachment-0001.html>

From tanner at gmx.net  Sat Mar 28 09:46:59 2015
From: tanner at gmx.net (Thomas Tanner)
Date: Sat, 28 Mar 2015 10:46:59 +0100
Subject: [openssl-users] Certification Path Building / non-hierachical PKI
Message-ID: <55167893.2030608@gmx.net>

Hello,
it seems to me OpenSSL does not support non-hybrid PKIs,
such as the mesh, hybrid or bridged structures described in RFC 4158
https://tools.ietf.org/html/rfc4158#section-1.5

Are there any plans or patches for such a feature?

cheers,

From rsalz at akamai.com  Sun Mar 29 13:30:56 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 29 Mar 2015 13:30:56 +0000
Subject: [openssl-users] Certification Path Building / non-hierachical
 PKI
In-Reply-To: <55167893.2030608@gmx.net>
References: <55167893.2030608@gmx.net>
Message-ID: <abdb10bfb31847d0b067708d79583e81@usma1ex-dag1mb2.msg.corp.akamai.com>

> Are there any plans or patches for such a feature?

We have no plans for this.

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



From Michael.Wojcik at microfocus.com  Sun Mar 29 15:08:38 2015
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Sun, 29 Mar 2015 15:08:38 +0000
Subject: [openssl-users] Certification Path Building / non-hierachical
 PKI
In-Reply-To: <abdb10bfb31847d0b067708d79583e81@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <55167893.2030608@gmx.net>
 <abdb10bfb31847d0b067708d79583e81@usma1ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088014BB1875E@Rock-Exchange1.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Salz, Rich
> Sent: Sunday, March 29, 2015 09:31
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Certification Path Building / non-hierachical PKI
> 
> > Are there any plans or patches for such a feature?
> 
> We have no plans for this.

It should be relatively straightforward to implement a non-hierarchical X.509 PKI in an OpenSSL-based application using the certificate verification callback, though.  The necessary graph algorithms are well-known and I believe there are existing open-source implementations (or it could be done in some language other than C that's more amenable to graph processing). It's not trivial, but between the RFC and a basic understanding of graph processing it's pretty clear what needs to be done.

A larger concern is probably the processing time for checking certification paths; as the RFC points out, this kind of graph-path processing grows quickly with the size of the graph.

-- 
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com

From v at tenable.com  Mon Mar 30 03:05:04 2015
From: v at tenable.com (K V)
Date: Mon, 30 Mar 2015 03:05:04 +0000 (UTC)
Subject: [openssl-users] =?utf-8?q?1=2E0=2E0=2Eo=3A_SIGSEGV_in_X509=5Fset?=
	=?utf-8?q?=5Fpubkey=28=29=2C_when_creating_a_self-signed_DSA_certi?=
	=?utf-8?q?ficate?=
Message-ID: <loom.20150330T044228-843@post.gmane.org>

LOG_OpenSSL() is my error-reporting macro/function.  Having set things up, as


    DH *dhParameters_512, *dhParameters_1024, *dhParameters_2048,
*dhParameters_4096;
    static constexpr long certValidityDuration_years{60};
    static constexpr unsigned nBytesToSeedPRNG{4};
    SSL_load_error_strings();
    SSL_library_init();
    OpenSSL_add_all_digests();
    OpenSSL_add_all_ciphers();
    OpenSSL_add_all_algorithms();
    if (RAND_load_file("/dev/random", nBytesToSeedPRNG) < (int)
nBytesToSeedPRNG)
        LOG_OpenSSL("Failed to seed PRNG");
    dhParameters_512   = get_dh512();
    dhParameters_1024  = get_dh1024();
    dhParameters_2048  = get_dh2048();
    dhParameters_4096  = get_dh4096();


, and generated an EVP_PKEY, as


    static constexpr u_short KEY_LEN{2048};

    EVP_PKEY_t *pkey_m;
    if (unlikely(! (pkey_m = EVP_PKEY_new())))
        LOG_OpenSSL("Cannot allocate an EVP_PKEY");

    DSA *keypair; // Also contains other stuff
    if (unlikely(! (keypair = DSA_new())))
        LOG_OpenSSL("Cannot allocate a DSA");

    if (0 == DSA_generate_parameters_ex(keypair, KEY_LEN,
                                        NULL, 0, NULL, NULL, NULL))
        LOG_OpenSSL("Cannot parameterize a %db DSA key", KEY_LEN);

    if (0 == DSA_generate_key(keypair))
        LOG_OpenSSL("Cannot generate a %db DSA key", KEY_LEN);

    if (unlikely(0 == EVP_PKEY_assign_DSA(pkey_m, &keypair)))
        LOG_OpenSSL("Cannot attach a DSA to an EVP_PKEY");


, then try to create a certificate, as


    X509_t *x509 = X509_new();
    if (unlikely(! x509))
        LOG_OpenSSL("Cannot allocate a X509");

    if (unlikely(0 == X509_set_version(x509, /*support X509v3*/ 2)))
        LOG_OpenSSL("Cannot set X.509 ver");

    if (unlikely(! ASN1_INTEGER_set(X509_get_serialNumber(x509), 1)))
        LOG_OpenSSL("Cannot set serial number");

    if (unlikely(! X509_gmtime_adj(X509_get_notBefore(x509), 0) ||
                 ! X509_gmtime_adj(X509_get_notAfter(x509),
                   certValidityDuration_years * 366 * 24 * 60 * 60)))
        LOG_OpenSSL("Cannot set validity period bounds");

    if (0 == X509_set_pubkey(x509, keypair.pkey_m))
        LOG_OpenSSL("Cannot set keypair");


Then follow calls to X509_NAME_add_entry_by_txt(), X509_set_issuer_name(),
and X509_sign(); but the program doesn't make it there.  Call stack:


Program received signal SIGSEGV, Segmentation fault.
0x00000000006e7c7f in BN_num_bits (a=0x5515bf5e) at bn_lib.c:250
(gdb) bt
#0  0x00000000006e7c7f in BN_num_bits (a=0x5515bf5e) at bn_lib.c:250
#1  0x0000000000714cfa in bn_i2c (pval=0x7fffffffdde8, cont=0x0,
putype=0x7fffffffd9b0, it=0x8de540 <BIGNUM_it>) at x_bignum.c:117
#2  0x0000000000718b1c in asn1_ex_i2c (pval=0x7fffffffdde8, cout=0x0,
putype=0x7fffffffd9b0, it=0x8de540 <BIGNUM_it>) at tasn_enc.c:583
#3  0x00000000007189db in asn1_i2d_ex_primitive (pval=0x7fffffffdde8,
out=0x0, it=0x8de540 <BIGNUM_it>, tag=-1, aclass=0) at tasn_enc.c:523
#4  0x0000000000717e09 in ASN1_item_ex_i2d (pval=0x7fffffffdde8, out=0x0,
it=0x8de540 <BIGNUM_it>, tag=-1, aclass=0) at tasn_enc.c:154
#5  0x0000000000718663 in asn1_template_ex_i2d (pval=0x7fffffffdde8,
out=0x0, tt=0x8d9900 <DSAPublicKey_ch_tt>, tag=-1, iclass=0) at tasn_enc.c:413
#6  0x0000000000717f12 in ASN1_item_ex_i2d (pval=0x7fffffffdbb8, out=0x0,
it=0x8d9960 <DSAPublicKey_it>, tag=-1, aclass=0) at tasn_enc.c:170
#7  0x0000000000717c48 in asn1_item_flags_i2d (val=0x7fffffffddb8,
out=0x7fffffffdc50, it=0x8d9960 <DSAPublicKey_it>, flags=0) at tasn_enc.c:110
#8  0x0000000000717bf4 in ASN1_item_i2d (val=0x7fffffffddb8,
out=0x7fffffffdc50, it=0x8d9960 <DSAPublicKey_it>) at tasn_enc.c:91
#9  0x00000000006f962f in i2d_DSAPublicKey (a=0x7fffffffddb8,
out=0x7fffffffdc50) at dsa_asn1.c:145
#10 0x00000000007719c9 in dsa_pub_encode (pk=0x192c89e0, pkey=0x192c8590) at
dsa_ameth.c:165
#11 0x000000000078249b in X509_PUBKEY_set (x=0x192c7960, pkey=0x192c8590) at
x_pubkey.c:102
#12 0x0000000000727e81 in X509_set_pubkey (x=0x192c8db0, pkey=0x192c8590) at
x509_set.c:146


Specifically, in frame #10, we have

(gdb) p pval
$86 = (ASN1_VALUE **) 0x7fffffffdc18
(gdb) p *pval
$87 = (ASN1_VALUE *) 0x7fffffffddb8

; but in frame #5, we call asn1_get_field_ptr(), which increments *pval by
48B, so then we have

(gdb) p pchval
$96 = (ASN1_VALUE **) 0x7fffffffdde8
(gdb) p *pchval
$97 = (ASN1_VALUE *) 0x5515bf5e

That 0x5515bf5e is outside of the program's virtual space, as we learn in
frame #0.


What am I doing wrong, please?  Many thanks in advance.

as a result of calling 


From openssl-users at dukhovni.org  Mon Mar 30 04:09:44 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 30 Mar 2015 04:09:44 +0000
Subject: [openssl-users] 1.0.0.o: SIGSEGV in X509_set_pubkey(),
 when creating a self-signed DSA certificate
In-Reply-To: <loom.20150330T044228-843@post.gmane.org>
References: <loom.20150330T044228-843@post.gmane.org>
Message-ID: <20150330040943.GQ17637@mournblade.imrryr.org>

On Mon, Mar 30, 2015 at 03:05:04AM +0000, K V wrote:

>     EVP_PKEY_t *pkey_m;
>     ...
>     DSA *keypair; // Also contains other stuff
>     ...
>     if (0 == X509_set_pubkey(x509, keypair.pkey_m))
>         LOG_OpenSSL("Cannot set keypair");


That second argument can't be "keypair.pkey_m"?  That won't even
compile.  The keypair variable is a pointer not a structure.

What's the actual code?  Make sure your source actually matches
your binaries.

-- 
	Viktor.

From piotr.lobacz at radmor.com.pl  Tue Mar 31 10:41:12 2015
From: piotr.lobacz at radmor.com.pl (Piotr =?UTF-8?Q?=C5=81obacz?=)
Date: Tue, 31 Mar 2015 12:41:12 +0200
Subject: [openssl-users] QNX cross-compiled openssl with fips
In-Reply-To: <1427450661.3208.3.camel@piotr-desktop>
References: <1427356003.3211.9.camel@piotr-desktop>
 <1427450661.3208.3.camel@piotr-desktop>
Message-ID: <1427798472.3082.6.camel@piotr-desktop>

Ok i have finally managed to cross-compile openssl with fips for QNX
platform. What i did wass modifing the fipsld script not to input this
magical number[ $? -ne 42 ] && exit $? and the returned output of
"${FIPS_SIG}" -exe "${TARGET}" was saved in SIG variable, because this
line SIG=`"${TARGET}" tried to execute QNX compiled code on linux, what
is rather impossible, to get the returned digest and recompile the
target with it. Now with these little changes i was finally able to run
openssl fips cross compiled app on qnx and i can gladly say that it
works.

Dnia 2015-03-27, pi? o godzinie 11:04 +0100, Piotr ?obacz pisze:
> Another problem is that compiled cross-compiled OpenSSL with fips should
> start in its own prompt but it only spews the expected signature and
> exits. I have modified fipsld scripts as shown in the manual and this
> does not help. Incore was used from the tarball but maybe i have to use
> some special modifications for QNX incore?
> 
> Dnia 2015-03-26, czw o godzinie 08:46 +0100, Piotr ?obacz pisze:
> > Hello,
> > i have been able to cross-compile openssl with fips module and what i
> > want now is to use it within my project which is using C++. According to
> > the manual https://wiki.openssl.org/index.php/Fipsld_and_C%2B%2B i have
> > to modify fipsld to fipsld++. Everything works properly if i'm compiling
> > my own libraries which are being linked with static crypto.a but if i'm
> > going to compile some tests which are linking with those libraries i get
> > this error:
> > 
> > /usr/lib/fips_premain.o: In function `FINGERPRINT_premain()':
> > /usr/lib/fips_premain.c:103: undefined reference to `FIPS_text_start()'
> > /usr/lib/fips_premain.c:116: undefined reference to
> > `FIPS_incore_fingerprint(unsigned char*, unsigned int)'
> > 
> > According to the manual, problem occurs with C++ linker, but i have it
> > modified in fipsld++ so that now PREMAIN_DSO looks like:
> > 
> > -x c "${PREMAIN_C}" -x none \
> > 
> > and this does not help. On Linux with gcc this was helpful but on QNX
> > cross compilation it does not.
> > 
> > I would be pleased if somebody could point me what am i doing wrong...
> > 
> 

-- 

________________________________________________________________________
Piotr ?obacz

Biuro System?w i Oprogramowania

RADMOR S.A.

tel. (58) 6996 929

e-mail: piotr.lobacz at radmor.com.pl

www.radmor.com.pl




RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia

NIP: 586-010-21-39

REGON: 190432077

KRS: 0000074029 (S?d Rejonowy Gda?sk-P??noc w Gda?sku)

Kapita? zak?adowy wp?acony: 9 282 830 PLN


From andreas.magana.ctr at us.af.mil  Tue Mar 31 14:19:53 2015
From: andreas.magana.ctr at us.af.mil (MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT)
Date: Tue, 31 Mar 2015 14:19:53 +0000
Subject: [openssl-users] expect.pm not updating password
Message-ID: <6ABA33135553E04E978A5ECCC07560D231A032EB@52ZHTX-D07-03C.area52.afnoapps.usaf.mil>

I have a expect.pm script that is supposed to ssh to remote host and change
my password on a Sparc Solaris 10 server. 

#!/usr/bin/perl
use strict;

use Expect;

my $ssh = Expect->new('ssh mylogin at remotehost');
$ssh->debug(0);
$ssh->expect("Password:\n");
$ssh->send("mycurrentpassword\n");
$ssh->expect('$');
$ssh->send("su - root\n");
$ssh->expect("Password:");
$ssh->send("myrootpassword\n");
$ssh->expect('#');
$ssh->send("passwd mylogin\n");
$ssh->expect("New Password:\n");
$ssh->send("mynewpassword\n");
$ssh->expect("Re-enter new Password:\n");
$ssh->send("mynewpassword\n");
#$ssh->expect
#$ssh->close();




//SIGNED//

Andy Maga?a
UNIX Systems Administrator
Diligent Contractor, 72nd Air Base Wing
Tinker Air Force Base, Oklahoma 
Commercial: (405) 734-0341

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
openssl-users-request at openssl.org
Sent: Wednesday, March 18, 2015 12:36 PM
To: openssl-users at openssl.org
Subject: openssl-users Digest, Vol 4, Issue 23

Send openssl-users mailing list submissions to
	openssl-users at openssl.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
	openssl-users-request at openssl.org

You can reach the person managing the list at
	openssl-users-owner at openssl.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of openssl-users digest..."


Today's Topics:

   1. Re: base64 decode in C (Jakob Bohm)
   2. Re: base64 decode in C (Walter H.)
   3. Re: [openssl-announce] Forthcoming OpenSSL releases
      (Dr. Matthias St. Pierre)
   4. Re: base64 decode in C (Scott Neugroschl)


----------------------------------------------------------------------

Message: 1
Date: Wed, 18 Mar 2015 17:33:41 +0100
From: Jakob Bohm <jb-openssl at wisemo.com>
To: openssl-users at openssl.org
Subject: Re: [openssl-users] base64 decode in C
Message-ID: <5509A8E5.1060104 at wisemo.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

Please refer to Dave Thompson's answer, it describes your problem.

On 18/03/2015 16:08, Prashant Bapat wrote:
> Hi Dave and Walter,
>
> Thanks for our reply.
>
> I'm not doing anything different for the ssh pubkey. I'm able to 
> decode it using the "openssl enc -base64 -d -A" command. But not using 
> the C program.
>
> Attaching my entire code here. After getting the base64 decoded I'm 
> calculating the MD5 sum and printing it. This works for a regular 
> string but not for SSH pubkey.
>
> Thanks again.
>
> --Prashant
>
Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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



------------------------------

Message: 2
Date: Wed, 18 Mar 2015 17:40:06 +0100
From: "Walter H." <Walter.H at mathemainzel.info>
To: openssl-users at openssl.org
Subject: Re: [openssl-users] base64 decode in C
Message-ID: <5509AA66.4070504 at mathemainzel.info>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 18.03.2015 16:08, Prashant Bapat wrote:
> printf("Base64 decoded string is : %s\n", b64_decode(str, strlen(str)));
// This should print binary for a ssh key.
not really, because the return of b64_decode is not a C string; and the 
format specfier %s expects a C string;

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5971 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://mta.openssl.org/pipermail/openssl-users/attachments/20150318/f066e41
6/attachment-0001.bin>

------------------------------

Message: 3
Date: Wed, 18 Mar 2015 17:59:59 +0100
From: "Dr. Matthias St. Pierre" <Matthias.St.Pierre at ncp-e.com>
To: <openssl-users at openssl.org>
Subject: Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL
	releases
Message-ID: <5509AF0F.7060900 at ncp-e.com>
Content-Type: text/plain; charset="windows-1252"

Thanks for the three line upgracde recipe in
https://wiki.openssl.org/index.php/Code_reformatting
It's as simple as you stated, indeed.

The reformatting was a good thing to do. Also, it makes sense to me to apply
it to all
stable branches uniformly, in order to simplify cross-branch merging.

msp




On 03/18/2015 04:32 PM, Salz, Rich wrote:
>> The extra work is also documented (in a place not linked from the wiki)
for
>> those who maintain a git fork of the OpenSSL repository.
> 
> I just tossed together
https://wiki.openssl.org/index.php/Code_reformatting
> Found off the main page,
https://wiki.openssl.org/index.php/Main_Page#Internals_and_Development 
> 
>> But I have not yet seen a meaningful recipe for those of us who maintain
a
>> traditional set of feature patches against the released tarballs, nicely
>> organized for future contribution.
> 
> Folks had months of warning that this was going to happen.  And, frankly,
patches did not come flooding into the team. 
> 
> But I hope the above link helps.
> 
> 	/r$
> 
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 


------------------------------

Message: 4
Date: Wed, 18 Mar 2015 17:26:39 +0000
From: Scott Neugroschl <scott_n at xypro.com>
To: "openssl-users at openssl.org" <openssl-users at openssl.org>
Subject: Re: [openssl-users] base64 decode in C
Message-ID:
	<D358E5B1511A314F8160ADC6F3754987069FD9F8 at XYSVEX01.XYPRO-23.LOCAL>
Content-Type: text/plain; charset="utf-8"

I believe the SSH pubkey is binary data, not ASCII, so strlen() will not
work on it if it has embedded NUL chars.
As Dave Thompson suggested, instead of strlen(), use the length returned
from BIO_read.


From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
Prashant Bapat
Sent: Wednesday, March 18, 2015 8:08 AM
To: openssl-users
Subject: Re: [openssl-users] base64 decode in C

Hi Dave and Walter,

Thanks for our reply.

I'm not doing anything different for the ssh pubkey. I'm able to decode it
using the "openssl enc -base64 -d -A" command. But not using the C program.

Attaching my entire code here. After getting the base64 decoded I'm
calculating the MD5 sum and printing it. This works for a regular string but
not for SSH pubkey.

Thanks again.

--Prashant

On 18 March 2015 at 18:04, Walter H.
<Walter.H at mathemainzel.info<mailto:Walter.H at mathemainzel.info>> wrote:
Hi,

before calling this function,
remove any whitespace;

Walter



_______________________________________________
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/20150318/a6cff62
3/attachment.html>

------------------------------

Subject: Digest Footer

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


------------------------------

End of openssl-users Digest, Vol 4, Issue 23
********************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3357 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150331/d879da74/attachment-0001.bin>

From sahib.jakhar at gmail.com  Tue Mar 31 17:43:17 2015
From: sahib.jakhar at gmail.com (Sahib Jakhar)
Date: Tue, 31 Mar 2015 23:13:17 +0530
Subject: [openssl-users] Regarding server side sessions support
In-Reply-To: <20150325164637.GK21586@mournblade.imrryr.org>
References: <CAE+y=w56_8tvcDQRPP3dLe6EWkCJeAKeT+XkTV4OKk0c4eFafw@mail.gmail.com>
 <20150325153208.GA22293@openssl.org>
 <20150325164637.GK21586@mournblade.imrryr.org>
Message-ID: <CAE+y=w6wC2mnYv9NvYHKPCRNKX4hfPEu+M=YLm8WN663DOEVYA@mail.gmail.com>

Thanks Dr Henson and Viktor your comment helped me immensely.

From sahib.jakhar at gmail.com  Tue Mar 31 17:51:02 2015
From: sahib.jakhar at gmail.com (Sahib Jakhar)
Date: Tue, 31 Mar 2015 23:21:02 +0530
Subject: [openssl-users] Openssl session resumption issue
Message-ID: <CAE+y=w6RKoSt=J62pQHaH++B=S-xKR5H5f2rqzC4=RrD0-3KYw@mail.gmail.com>

Hi,

I am trying to implement session resumption on a client/server model
using disk based session caching. I am facing couple of problems:

1. On the client side, even though saving of session using
PEM_ASN1_write_bio works, reading it again using PEM_ASN1_read_bio
always returns NULL pointer for SSL_SESSION. So reading doesn't work.
2. On the server side, even saving of session doesn't work and
PEM_ASN1_write_bio simply crashes, for some unknown reason, even
though the code for client and server is almost the same.

I am reproducing the code below, can somebody help me out as to what I
am doing wrong? Please forgive me if I am making some naive mistake.
Any other comments/observation will be helpful, as I am doing this the
first time.

    static int bl_openssl_io_encrypted_from_file (char
*session_save_path, int is_write, void *io_data)
    {
        .....

        fd = bl_openssl_open_and_lock_file (session_save_path,
is_write ? F_WRLCK : F_RDLCK);
        if (IS_FILE_HANDLE_INVALID(fd))
        { ... }

        if (!(bp = BL_BIO_new_fd (fd, is_write ? _O_WRONLY :
_O_RDONLY, BIO_NOCLOSE)))
        { ... }

        if (is_write)
        {
            enc = EVP_des_ede3_cbc ();
            PEM_ASN1_write_bio ((int (*)())i2d_SSL_SESSION,
PEM_STRING_SSL_SESSION, bp, (char *)io_data, enc, NULL, 0, NULL,
cachepass);
        }
        else
        {
            PEM_ASN1_read_bio ((char *(*)())d2i_SSL_SESSION,
PEM_STRING_SSL_SESSION, bp, (char **)io_data, NULL, cachepass);
        }

        BIO_flush (bp);
        BIO_free (bp);
        bl_openssl_close_and_unlock_file (fd);

        ret = 0;

        CLEANUP_CODE_AND_RETURN
    }

    /* This function is for reading session from file.  */
    static SSL_SESSION *bl_openssl_read_encrypted_session_from_file
(char *session_save_path, int *ref)
    {
        SSL_SESSION *sess = NULL;
        int ret;

        ret = bl_openssl_io_encrypted_from_file (session_save_path, 0, &sess);

        if (ref)
            *ref = ret;

        return sess;
    }

    /* This function is for writing session to file. */
    static int bl_openssl_write_encrypted_session_to_file (char
*session_save_path, SSL_SESSION *sess)
    {
        int ret = 0;

        ret = bl_openssl_io_encrypted_from_file (session_save_path, 1, sess);
        return ret;
    }

    /* This function is for reading session from file for client. This
always returns NULL. */
    SSL_SESSION *bl_openssl_client_load_session_information (server_info* bi)
    {
        ....

        return bl_openssl_read_encrypted_session_from_file (filePath, NULL);
    }

    /* This function is for writing session to file for client. This works. */
    void bl_openssl_client_save_session_information (server_info* bi,
SSL_SESSION *sess)
    {
        ....

        bl_openssl_write_encrypted_session_to_file (filePath, sess);
    }

    /* This is for server side caching. Used as
        SSL_CTX_sess_set_new_cb (c, bl_openssl_new_session_cb );
        This function crashes. */
    int bl_openssl_new_session_cb (SSL *ctx, SSL_SESSION *session)
    {
        char *session_save_path = NULL;

        session_save_path = bl_openssl_get_server_session_file_path
(session->session_id, session->session_id_length);
        return bl_openssl_write_encrypted_session_to_file
(session_save_path, session);
    }

    /* This is for server side retrieval of cached session. Used as,
        SSL_CTX_sess_set_get_cb (c, bl_openssl_get_session_cb); */
    SSL_SESSION *bl_openssl_get_session_cb (SSL *ctx, unsigned char
*id, int len, int *ref)
    {
        char *session_save_path = NULL;

        session_save_path = bl_openssl_get_server_session_file_path (id, len);
        return bl_openssl_read_encrypted_session_from_file
(session_save_path, ref);
    }


Thanks,
Sahib

From openssl-users at dukhovni.org  Tue Mar 31 18:53:44 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 31 Mar 2015 18:53:44 +0000
Subject: [openssl-users] Openssl session resumption issue
In-Reply-To: <CAE+y=w6RKoSt=J62pQHaH++B=S-xKR5H5f2rqzC4=RrD0-3KYw@mail.gmail.com>
References: <CAE+y=w6RKoSt=J62pQHaH++B=S-xKR5H5f2rqzC4=RrD0-3KYw@mail.gmail.com>
Message-ID: <20150331185344.GM17637@mournblade.imrryr.org>

On Tue, Mar 31, 2015 at 11:21:02PM +0530, Sahib Jakhar wrote:

> 1. On the client side, even though saving of session using
> PEM_ASN1_write_bio works,

Why are you using PEM_ASN1_write_bio()?

Serialize sessions using i2d_SSL_SESSION(), and then save the
resulting octet string ( not NUL terminated C string).  If you're
saving multiple sessions, you'll need some sort of suitable key/value
store that supports "binary" (byte array with length) values.

Why are client sessions persisted to disk?

If you must write to disk, make sure the disk file storing the
session data is not world-readable.

Do you really need a server-side session cache?  Or will session
tickets suffice?  If you do need one, something other than a
random-access database will perform very poorly, you need an LMDB
or SQLite store for a disk-based key-value server-side cache.
Something with fast lookups by session id.

> reading it again using PEM_ASN1_read_bio
> always returns NULL pointer for SSL_SESSION.

Why are you using PEM_ASN1_read_bio()?  Read back the byte array
and deserialize using d2i_SSL_SESSION().

-- 
	Viktor.