bn_ops not being used in Android recipes

[Jeffrey Walton]

Hi Everyone,

I have a custom 15-android.conf that is used with a custom
setenv-android.sh. setenv-android.sh sets the environment and exports
the necessary variables for a cross-compile. 15-android.conf was
copied from the OpenSSL library, and then modified to avoid some
problems with the one supplied with the library that leads to a failed
compile under NDK-r20.

 Android...
my %targets = (
"android" => {
inherit_from => [ "linux-generic32" ],
template => 1,
bin_cflags   => add("-fPIE"),
bin_lflags   => add("-pie"),
enable   => [ ],
},

"android-arm" => {
inherit_from => [ "android", asm("armv4_asm") ],
bn_ops   => add("BN_LLONG RC4_CHAR"),
},
"android-arm64" => {
inherit_from => [ "android", asm("aarch64_asm") ],
bn_ops   => add("SIXTY_FOUR_BIT_LONG RC4_CHAR"),
perlasm_scheme   => "linux64",
},

"android-x86" => {
inherit_from => [ "android", asm("x86_asm") ],
CFLAGS   => add(picker(release => "-fomit-frame-pointer")),
bn_ops   => add("BN_LLONG RC4_INT"),
perlasm_scheme   => "android",
},
"android-x86_64" => {
inherit_from => [ "android", asm("x86_64_asm") ],
bn_ops   => add("SIXTY_FOUR_BIT_LONG RC4_INT"),
perlasm_scheme   => "elf",
},
);

It looks like bn_ops are not being honored. For example, OpenSSL was
configured for android-x86_64, but SIXTY_FOUR_BIT_LONG and RC4_INT are
missing:

x86_64-linux-android23-clang -I. -Icrypto/include -Iinclude -fPIC
-pthread -march=x86-64 -msse4.2 -mpopcnt -mtune=intel -funwind-tables
-fexceptions 
--sysroot=/home/travis/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot
-DOPENSSL_USE_NODELETE -DOPENSSL_PIC
-DOPENSSLDIR="\"/home/travis/android23-x86_64\""
-DENGINESDIR="\"/home/travis/android23-x86_64/lib/engines-1.1\""
-DNDEBUG -D__ANDROID_API__=23 -MMD -MF crypto/bn/bn_add.d.tmp -MT
crypto/bn/bn_add.o -c -o crypto/bn/bn_add.o crypto/bn/bn_add.c

x86_64-linux-android23-clang  -I. -Icrypto/include -Iinclude -fPIC
-pthread -march=x86-64 -msse4.2 -mpopcnt -mtune=intel -funwind-tables
-fexceptions 
--sysroot=/home/travis/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot
-DOPENSSL_USE_NODELETE -DOPENSSL_PIC
-DOPENSSLDIR="\"/home/travis/android23-x86_64\""
-DENGINESDIR="\"/home/travis/android23-x86_64/lib/engines-1.1\""
-DNDEBUG -D__ANDROID_API__=23 -MMD -MF crypto/bn/bn_asm.d.tmp -MT
crypto/bn/bn_asm.o -c -o crypto/bn/bn_asm.o crypto/bn/bn_asm.c
crypto/bn/bn_asm.c:28:9: warning: shift count >= width of type
  [-Wshift-count-overflow]
mul_add(rp[0], ap[0], w, c1);
^~~~
crypto/bn/bn_lcl.h:475:14: note: expanded from macro 'mul_add'

(c)= Hw(t); \
 ^
crypto/bn/bn_lcl.h:469:36: note: expanded from macro 'Hw'
#  define Hw(t)(((BN_ULONG)((t)>>BN_BITS2))_MASK2)

The full build is available at
https://travis-ci.org/noloader/unbound/jobs/659771319.

How do I get the machinery to use bn_ops?

Jeff

What option is not recognized by OpenSSL 1.1.1d?

[Jeffrey Walton]

I'm trying to convert some scripts from OpenSSL 1.0.2 to OpenSSL 1.1.1d.

Configure is dying:

* Unsupported options: no-comp
--prefix=/home/jwalton/tmp/build-test
--libdir=/home/jwalton/tmp/build-test/lib

According to INSTALL at
https://github.com/openssl/openssl/blob/master/INSTALL, all the
options are supported.

Which option is not recognized by OpenSSL 1.1.1d?

Thanks in advance.

Re: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

[Jeffrey Walton]

On Tue, Jan 23, 2018 at 4:33 PM, Salz, Rich  wrote:
> On Tue, Jan 23, 2018 at 3:45 PM, Salz, Rich  wrote:
> > ➢ The docs have _not_ changed: 
> https://www.openssl.org/docs/standards.html.
> >
> > Nor is there any need for that page to change.  READ WHAT IT SAYS.
>
> ➢ I'm surprised you are arguing against clear documentation on behaviors.
>
> There is no need to be surprised, because I am not doing that.
>
> The webpage says “here’s a casually-maintained list of related standards or 
> other useful information.”  What on that webpage is wrong?
>
> You seem to be very very VERY upset by how OpenSSL implements one particular 
> part of RFC 5280.  Viktor has shown that it’s not just us, it’s other code as 
> well.  The original poster was able to live with OpenSSL’s implementation.  
> You don’t like that code.  So be it.

If that's your survey of the situation then it is wrong.

No wonder Henson and Marquess left the project. I would get tired of
the games, too.

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

Re: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

[Jeffrey Walton]

On Tue, Jan 23, 2018 at 3:45 PM, Salz, Rich  wrote:
> ➢ The docs have _not_ changed: 
> https://www.openssl.org/docs/standards.html.
>
> Nor is there any need for that page to change.  READ WHAT IT SAYS.

I'm surprised you are arguing against clear documentation on behaviors.

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

Re: [openssl-users] WG: TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

[Jeffrey Walton]

On Tue, Jan 23, 2018 at 12:43 PM, Viktor Dukhovni
 wrote:
>
>
>> On Jan 23, 2018, at 7:31 AM, Gladewitz, Robert via openssl-users 
>>  wrote:
>>
>> Despite being wrong it is also absolutely irrelevant, because FreeRADIUS
>> retrieves the OpenSSL rejection of the cacert.capf.pem before any end-entity
>> certifcate is ever seen.
>
> This is almost certainly not the case.  Why would FreeRADIUS be validating
> a stand-alone CA certificate that is not part of a chain from a leaf
> certificate to a trust anchor?  The chain is validated for a particular
> purpose, presumably "TLS client" (the error message in the subject line of
> this thread is about the processing of a client certificate).
>
>> We now have a very plain cacert.capf.pem. It only shows the following
>> attributes:
>> X509v3 Key Usage: critical
>>Certificate Sign, CRL Sign
>> and things work.
>
> Great!  This confirms that the issue was the restricted EKU of the
> intermediate CA certificate.
>
>> So to sum up: there is a mistake, that we know of, but really it is not in
>> our hands to change it. And we do not need to change it, because it is of no
>> concern to the problem at hand.
>
> The previous CA certificate was explicitly not suitable for verifying TLS
> clients, based on the de facto interpretation of EKU in CA certificates in
> OpenSSL and various other TLS libraries.  So the issue was very much a
> "concern to the problem at hand".
>
>> Secondly the presented cacert.capf.pem is (by itself) a valid certificate.
>
> It is a valid intermediate CA certificate, that is (de facto) constrained
> to be used only for verifying for TLS server certificates, and NOT TLS
> client certificates.
>
>> It does not present a mistake. We should also not need to change it - but we
>> do. Why?
>
> You had to change it because you want to use this CA to issue TLS client
> certificates, and so its EKU needs to either be absent or to explicitly
> permit TLS client authentication.
>
>
>> Having read all the discussion i do not know why.
>
> Mostly because despite my best attempts to explain the above, perhaps
> a language barrier, and/or my inability to explain the issue sufficiently
> clearly, is preventing the reasons from being communicated effectively.
>
>> It is a CA certificate and Cisco somehow restricts this CA certificate to
>> a certain chosen purpose.
>
> Perhaps you mean that default software settings create such a certificate.
> If so, please raise this as a bug with the software vendor.  As you've
> already seen deploying a CA without an EKU works, so the previous EKU is
> not in fact a requirement.
>
>> OpenSSL should not interfere at this point.
>
> OpenSSL implements a widely practiced de facto CA certificate "purpose"
> policy based on the optional EKU extension in the CA certificate.  If
> you don't to restrict the purposes for which a CA can issue EE certificates
> (directly or indirectly), then DO NOT include an EKU in the CA certificate.
> If you do want to limit the CA to issue only certificates for particular
> purposes, then include all (and only) those purposes in the EKU.
>
> Good luck.  And thanks for reporting this, this discussion should
> help other users to quickly resolve similar issues in the future.

Your arguments are fallacious. How the browsers do things does not
constitute the "de facto" standard. Your just begging the claim.

The docs have _not_ changed: https://www.openssl.org/docs/standards.html.

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

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

[Jeffrey Walton]

On Sun, Jan 21, 2018 at 6:38 PM, Salz, Rich via openssl-users
 wrote:
> ➢ The sensible thing at this point is to publish an update to RFC5280
> that accepts reality.
>
> Yes, and there’s an IETF place to do that if anyone is interested; see the 
> LAMPS working group.

Related, the subject came up recently on the PKIX mailing list: "Next
edition of X.509",
https://www.ietf.org/mail-archive/web/pkix/current/msg33478.html .

https://www.ietf.org/mail-archive/web/pkix/current/msg33489.html was a
proposal to modify the text. The modifications appear to propose KU
and EKU cast a wider net to accommodate IoT gadgets.

https://www.ietf.org/mail-archive/web/pkix/current/msg33490.html was a
comment to avoid the modification. The objection stated to an OID for
the new usages to accommodate the use cases.

Another thread of interest from SAAG is "Considerations about the need
to resume PKIX work",
https://mailarchive.ietf.org/arch/msg/saag/BJWLw-XZvq_fgCYDldCDLVamNbg

There does not seem to be a lot of interest in revising PKIX. I
persoanlly find it disappointing because it seems like it is the wild,
wild west to me.

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

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

[Jeffrey Walton]

On Mon, Jan 22, 2018 at 10:04 PM, Viktor Dukhovni
<openssl-us...@dukhovni.org> wrote:
>
>
>> On Jan 22, 2018, at 9:39 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
>>
>> If OpenSSL want to change the standard so that it aligns with the
>> project's implementation then the project should go to LAMP.
>> Otherwise, the project is acting without authority. OpenSSL cannot
>> arbitrarily decide to do something else on a suggestion or a whim.
>
> There is no "authority", nor is there an "Internet police".

"Authority" as in governance and policies and procedures.

>> You know, this issue could have been side stepped by providing both
>> behaviors, making one default, and allowing the user to make the
>> choice. Instead, the project wrapped its arms around the solution that
>> broke interop.
>
> Actually, IIRC Mozilla's NSS and Microsoft's CAPI do the same thing.
> So it is unclear where exactly we're breaking "interop".
>
>> I can't help but wonder, doesn't anyone think these decisions through?
>
> This was thought through and discussed.  I brought to the team's
> attention:
>
>
> http://www-archive.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html

Apples and oranges. Browsers use the CA/B baseline requirements.

What does it have to do the the IETF, the RFCs and PKIX?

> I am sorry to hear that you're saddened by my lack of fealty to
> RFC5280, but I find real-world considerations more compelling.
> The OP in this thread has perfectly reasonable work-arounds,
> the main obstacle seems to be a language barrier more than
> anything else.

Yeah, the real world decision just decision just derailed the use of
crypto, not improve upon it.

I've seen this so many times in the past. It is the result of allowing
engineers drive requirements.

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

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

[Jeffrey Walton]

On Mon, Jan 22, 2018 at 9:27 PM, Salz, Rich  wrote:
> ➢ I don't see CA/Browser Forums listed, but I do see RFC 3280 listed.
>
> The page also says it’s “casually maintained.”  Feel free to create a PR on 
> openssl/web repo. :)
>
> IETF RFC’s aren’t perfect; that’s why there are errata.  Dragging this all 
> the way to “we’re ignoring the words” is not nor accurate.  Someone who wants 
> to argue that OpenSSL is doing the wrong thing here, should go to the IETF 
> LAMPS WG and raise the issue.

If OpenSSL want to change the standard so that it aligns with the
project's implementation then the project should go to LAMP.
Otherwise, the project is acting without authority. OpenSSL cannot
arbitrarily decide to do something else on a suggestion or a whim.

You know, this issue could have been side stepped by providing both
behaviors, making one default, and allowing the user to make the
choice. Instead, the project wrapped its arms around the solution that
broke interop.

I can't help but wonder, doesn't anyone think these decisions through?

Thank god Andy has not broken AES interop by whitening AES keys
because some people think it is a good idea.

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

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

[Jeffrey Walton]

On Mon, Jan 22, 2018 at 9:01 PM, Salz, Rich via openssl-users
 wrote:
>
> > Here's the standards OpenSSL claims to implement:
>
> Read the whole text.  It doesn’t say anything like “claims to implement.”

My bad. Here's the corrected text:

This page is a partial list of the specifications that are
relevant to OpenSSL

I don't see CA/Browser Forums listed, but I do see RFC 3280 listed.

And there are no notes on issuing polices, which is the matter at
hand. No reasonable person would expect OpenSSL to cite 61 RFCs,
including the IETF's PKIX RFCs, and not use PKIX issuing policies.

I'm befuddled someone thought and others agreed it was OK to break a
worldwide standard. The purpose of the standard is to ensure
interoperability. The break is a throwback to the verify=false days
for folks who needs things to "just work".

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

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

[Jeffrey Walton]

On Mon, Jan 22, 2018 at 2:50 PM, Viktor Dukhovni
 wrote:
>
>
>> On Jan 22, 2018, at 12:07 PM, Gladewitz, Robert via openssl-users 
>>  wrote:
>>
>> the problem is, that i cant change the cisco implementation :-(.
>
> YOU DO NOT need to change the Cisco implementation.
>
>> Cisco tell me, the capf implemtation is following all rfc documents.
>
> Nothing Cisco is telling you requires your issuing CA to have an
> extended key usage listing just "TLS Web Server Authentication".
>
>> If you are right,
>> i cant use any freeradius implementation, because there are based on
>> openssl. There is no option in freeradius, to ignore some think like this.
>
> Your problem is a misconfigured CA certificate.  Make sure your *CA*
> certificate has no extended key usage specified, OR has *all* the key
> usages specified that are required by any leaf certificate it will issue.

This is wrong. The CA is not misconfigured.

>> For my understanding, CA certificate may have these exteded keys - it's just
>> something out of the ordinary.
>
> The extended key usages on the CA are interpreted to LIMIT the key usages
> of certificates it can issue.  You can certainly use this extension, but
> then expect the CA to be invalid for key usages you did not list.

This is wrong. The KU and EKU bits are not interpreted that way.

Here's the standards OpenSSL claims to implement:
https://www.openssl.org/docs/standards.html.

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

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

[Jeffrey Walton]

On Mon, Jan 22, 2018 at 1:44 AM, Gladewitz, Robert via openssl-users
 wrote:
>
> Thank you all for all the answers.
> The problem is that Cisco prescribes the attributes.
> ...
>
> Unfortunately, the Cisco CUCM telephone systems do not seem to accept 
> certificates without these attributes :-(.
>
> If I understand everything correctly, would the only (and unclean) workaround 
> be adding "TLS Web Client Authentication" to solve my problem?
>

I think you have a couple of choices.

First, you can downgrade to a version of OpenSSL that follows the RFC.
Second, you can patch OpenSSL to follow the RFC. Third, you can
implement the verify_callback and override the errant behavior.

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

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

[Jeffrey Walton]

On Sun, Jan 21, 2018 at 6:23 PM, Viktor Dukhovni
<openssl-us...@dukhovni.org> wrote:
>
>
>> On Jan 21, 2018, at 6:04 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
>>
>> Maybe OpenSSL should allow users to choose between IETF issuing
>> policies and CA/Browser BR issuing policies.
>
> The sensible thing at this point is to publish an update to RFC5280
> that accepts reality.

+1.

Add a Key-Interception usage while you're at it. Its a widespread practice too.

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

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

[Jeffrey Walton]

On Sun, Jan 21, 2018 at 5:59 PM, Viktor Dukhovni
<openssl-us...@dukhovni.org> wrote:
>
>
>> On Jan 21, 2018, at 2:40 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
>>
>>> OpenSSL interprets the "extendedKeyUsage" extension in CA certificates
>>> as a restriction on the allowed extended key usages of leaf certificates
>>> that can be issued by that CA.
>>>
>>> You should typically not specify extended key usage for CA certificates
>>> at all, unless you mean to restrict them to specific purposes.
>>
>> The behavior is inconsistent with RFC 5280:
>>
>> 4.2.1.12.  Extended Key Usage
>>
>>   This extension indicates one or more purposes for which the certified
>>   public key may be used, in addition to or in place of the basic
>>   purposes indicated in the key usage extension.  In general, this
>>   extension will appear only in end entity certificates.  This
>>   extension is defined as follows ...
>
> We're well aware of this, but this is the de-facto behaviour of
> multiple implementations.  This is an area in which RFC5280 fails
> to match the real world.

Apparently everyone did not get the memo :)

Maybe OpenSSL should allow users to choose between IETF issuing
policies and CA/Browser BR issuing policies.

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

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

[Jeffrey Walton]

On Sun, Jan 21, 2018 at 1:31 PM, Viktor Dukhovni
 wrote:
>
> ...
> OpenSSL interprets the "extendedKeyUsage" extension in CA certificates
> as a restriction on the allowed extended key usages of leaf certificates
> that can be issued by that CA.
>
> You should typically not specify extended key usage for CA certificates
> at all, unless you mean to restrict them to specific purposes.

The behavior is inconsistent with RFC 5280:

4.2.1.12.  Extended Key Usage

   This extension indicates one or more purposes for which the certified
   public key may be used, in addition to or in place of the basic
   purposes indicated in the key usage extension.  In general, this
   extension will appear only in end entity certificates.  This
   extension is defined as follows ...

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

Re: [openssl-users] CMAC Authentication

[Jeffrey Walton]

On Mon, Jan 15, 2018 at 8:22 AM, Rol Phil  wrote:
> Hello all,
>
> I have been using  to tag data with an example I had found.
> However when it comes to authenticate/decrypt a tag with given AES key I
> could not find examples.
>  using cmac.h or evp.h.
> Can anybody help me please?

CMAC is covered under EVP Signing and Verifying. See
https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying .

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

Re: [openssl-users] How to respond to TLS heartbeat in openssl

[Jeffrey Walton]

On Fri, Dec 22, 2017 at 1:32 AM, Keshava Krishna Bhat K
 wrote:
> Ok, I got to know that
>  openssl version -a gives out the flags used while building openssl.
> so the output of this was
>
> OpenSSL 1.0.2g  1 Mar 2016
> built on: reproducible build, date unspecified
> platform: debian-amd64
> options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
> compiler: cc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS
> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack
> -Wall -DMD32_REG_T=int -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/lib/ssl"
>
> Since the putput above does not have OPENSSL_NO_HEARTBEATS, I assume
> heartbeats are not disabled in the build.
> So I am back to square one :( -> how do I make the server respond to a TLS
> heartbeat request ? Do I have to read the packet and write it back ?

You should also check  for OPENSSL_NO_HEARTBEATS.

$ cd openssl
$ grep -B 1 -A 1 HEART include/openssl/opensslconf.h
#endif
#ifndef OPENSSL_NO_HEARTBEATS
# define OPENSSL_NO_HEARTBEATS
#endif

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

Re: [openssl-users] Lattice Ciphers

[Jeffrey Walton]

On Mon, Dec 18, 2017 at 1:38 AM, Colony.three via openssl-users
 wrote:
>
> G**gle's Eric Schmidt says, "If you have something that you don't want
> anyone to know, maybe you shouldn't be doing it in the first place.  This is
> a profoundly undemocratic attitude.  What would Thomas Paine, or Ben
> Franklin, or Patrick Henry say to this?

Off-topic, but... I was angry when I first read that, too.

Later I realized that was the best warning Google and Schmidt could
give. He basically told you government has infiltrated their systems,
and you should avoid their systems if security and privacy matters.

It is not just Google, but Google is the only one who has warned you.
Government has infiltrated other systems, including Apple, Amazon,
Microsoft, Saleforce, Rackspace and friends. You should be angry the
others have not warned you :)

Just avoid Google, Microsoft, Amazon and friends if your security and
privacy matters.

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

Re: [openssl-users] Generating CSR based on an x25519 public key

[Jeffrey Walton]

On Mon, Oct 23, 2017 at 6:47 PM, Kyle Hamilton  wrote:
> Out of curiosity, what are the algorithm identifiers for X25519 and Ed25519?
>

The ones I am aware of are available in
http://tools.ietf.org/html/draft-josefsson-pkix-newcurves.

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

Re: [openssl-users] Generating CSR based on an x25519 public key

[Jeffrey Walton]

On Sat, Oct 21, 2017 at 9:38 AM, Codarren Velvindron
 wrote:
> https://tls13.crypto.mozilla.org is using : The connection to this site is
> encrypted and authenticated using a strong protocol (TLS 1.3), a strong key
> exchange (X25519), and a strong cipher (AES_128_GCM).

That's what Rich said: "X25519 is a key-exchange-only algorithm". The
shared secret that drops out of the x25519 key exchange is used to key
AES128/GCM (some hand waiving).

> Using openssl standard tools is it possible to generate a CSR through
> Ed25519 ?

This is a different application. ed25519 is signing, not key exchange.

I'm not sure how to do it because I've never needed it. But keep in
mind Rich said: "OpenSSL doesn’t fully support Ed25519".

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

Re: [openssl-users] ca md too weak

[Jeffrey Walton]

On Fri, Oct 6, 2017 at 12:22 PM, Fabrice Delente  wrote:
> OK, I understand, thanks for your answer! I'll look into building
> openvpn 2.4.3 from source.

I believe you only have to set Fedora's security policy to allow MD5.
That is covered in the Fedora wiki page you were provided.

There's no need to download and build a new OpenSSL and OpenVPN.
However, if you to take that path, then see
https://stackoverflow.com/q/38985889/608639.

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

Re: [openssl-users] ca md too weak

[Jeffrey Walton]

> Until two days ago I used OpenVPN to connect to my workplace, on a
> non-security sensitive tunnel (just for convenience).
>
> However, OpenSSL updated on my machine (Fedora 26), and now the
> certificate is rejected:
>
> ...
> routines:SSL_CTX_use_certificate:ca md too weak
> Fri Oct  6 17:25:06 2017 Cannot load certificate file lcs/delentef.crt
> Fri Oct  6 17:25:06 2017 Exiting due to fatal error
>
> What solutions are there to this problem? Can I configure OpenSSL to
> accept this certificate after all?

https://fedoraproject.org/wiki/Changes/CryptoPolicy

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

Re: [openssl-users] DH_generate_key Hangs

[Jeffrey Walton]

>> You should avoid calls to RAND_poll altogether on Windows. Do so by
>> explicitly seeding the random number generator yourself.
>
> As a starting point, try something like this:
>
> -
> static ENGINE *rdrand;
>
> void init_prng(void) {
> /* Try to seed the PRNG with the Intel RDRAND on-chip PRNG */
> OPENSSL_cpuid_setup();
> ENGINE_load_rdrand();
> rdrand = ENGINE_by_id("rdrand");
> if (rdrand) {
> int success = 0;
> if (ENGINE_init(rdrand)) {
> success = ENGINE_set_default(rdrand, ENGINE_METHOD_RAND);
> }
>
> /***
> Per OpenSSL wiki, call ENGINE_free here regardless of whether we're
> successfully using rdrand. The "functional reference" to rdrand will
> be released when we call ENGINE_finish.
> ***/
> ENGINE_free(rdrand);
> if (! success) ENGINE_finish(rdrand), rdrand = NULL;
> }
>
> if (!rdrand && !RAND_status()){
>   RAND_screen();   /* this isn't really emough entropy, but it's a start 
> */
>   if (!RAND_status()) {
>  RAND_poll();  /* try to gather additional entropy */
>   }
>}
> }
>
> void terminate_engines(void) {
>if (rdrand) ENGINE_finish(rdrand), rdrand = NULL;
>/* similarly for any other engines you use */
>ENGINE_cleanup();
> }
> -
>
> Call init_prng after your OpenSSL initialization code (e.g. after calling 
> OpenSSL_add_all_algorithms), and terminate_engines when you're done using 
> OpenSSL (e.g. just before process exit).
>
> Note that this code uses RAND_screen if RDRAND isn't available. RAND_screen 
> is really not a very good idea; it may be OK on workstations, but rarely 
> provides much entropy on servers because they typically aren't doing much 
> screen output. And if you still need entropy after the RAND_screen call, 
> you'll end up in RAND_poll anyway. The alternative is to write your own code 
> that harvests entropy from some source (or sources).
>
> Other people may have better suggestions.

Headless servers without hw entropy sources are tough. In this case I
use hedging. I've got some patches somewhere for 1.0.1, but they won't
apply to 0.9.8.

Also see:

* When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities
and Hedging Deployed Cryptography,
http://pages.cs.wisc.edu/~rist/papers/sslhedge.pdf
* When Virtual is Harder than Real: Security Challenges in Virtual
Machine Based Computing Environments,
http://www.usenix.org/legacy/event/hotos05/final_papers/full_papers/garfinkel/garfinkel.pdf

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

Re: [openssl-users] DH_generate_key Hangs

[Jeffrey Walton]

On Thu, Oct 5, 2017 at 3:27 PM, Jason Qian via openssl-users
 wrote:
> Compared code of RAND_poll(void) between 1.0.1 and 1.0.2 and it seems no
> change

I believe it was fixed earlier than that. Also see
https://rt.openssl.org/Ticket/Display.html?id=2100=guest=guest

As Michael suggested, 0.9.8 is the biggest problem. You should
probably solve that problem first.

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

Re: [openssl-users] DH_generate_key Hangs

[Jeffrey Walton]

On Thu, Oct 5, 2017 at 2:55 PM, Jason Qian via openssl-users
 wrote:
> Thanks Michael,
>
>   I saw a lot of discussion for this issue on,
>
>https://mta.openssl.org/pipermail/openssl-dev/2015-July/002210.html
>
>   Not sure if openSSL has a workaround or a patch ?
>
>
> It hangs on :
>
> libeay32.dll!RAND_poll() Line 523
>
> if (heap_first(,
>   hlist.th32ProcessID,
>   hlist.th32HeapID))

You should avoid calls to RAND_poll altogether on Windows. Do so by
explicitly seeding the random number generator yourself.

Also see https://wiki.openssl.org/index.php/Random_Numbers#Windows_Issues
on the OpenSSL wiki.

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

Re: [openssl-users] Hardware client certificates moving to Centos 7

[Jeffrey Walton]

>> I don't know offhand which OpenSSL versions did away with MD5, but you
>> *can* install an 0.9.8e (+ RHEL/CentOS backported security patches)
>> straight off CentOS 7 repos:
>
> Ugh. No need for 0.9.8e (which is from, what, the early Industrial 
> Revolution?). MD5 is still available in OpenSSL 1.0.2, assuming it wasn't 
> disabled in the build configuration. I think Stuart is dealing with an 
> OpenSSL build that had MD5 disabled in the Configure step.
>
> Heck, MD4 and MDC2 are still available in 1.0.2 - even with the default 
> configuration, I believe. I'm looking at 1.0.2j here and it has GOST, MD4, 
> MD5, MDC2, RIPEMD-60, SHA, SHA1, SHA-2 (all standard lengths), and Whirlpool.

Some of those algorithms may still needed for some use cases. For
example, Apple still ships (or used to ship until recently) some
certificates that use MD2. They were present in iOS 7 and 8. Also see
http://seclists.org/fulldisclosure/2013/Sep/184.

I think the best OpenSSL can for now is allow those who don't need
antique algorithms to disable them at compile time. Otherwise, OpenSSL
is making policy decisions that may not work well for some folks.

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

Re: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods

[Jeffrey Walton]

On Wed, Sep 20, 2017 at 5:48 PM, Jordan Brown
 wrote:
> ...
> The above also works with "authorityCertSerialNumber", see
>
>https://tools.ietf.org/html/rfc5280#section-4.2.1.1
>
> If, however, the newer certificate has a different key, and the same
> subject DN, but does not place matching distinct subject key identifiers
> in the certificates it issues, then OpenSSL will not correctly handle
> multiple candidate issuers that differ in the public key, but provide
> no hints in the issued certificates which issuer to use.
>
> I'm not familiar with those extensions and will need to do more research.

I believe the controlling IETF document is "Internet X.509 Public Key
Infrastructure: Certification Path Building",
https://tools.ietf.org/html/rfc4158.

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

Re: [openssl-users] Problem with DER private key file into openssl ca

[Jeffrey Walton]

> openssl req -outform $format -config $cadir/openssl-root.cnf -set_serial
> 0x$(openssl rand -hex $sn)\
>   -inform $format -key private/ca.key.$format -subj "$DN"\
>   -new -x509 -days 7300 -sha256 -extensions v3_ca -out
> certs/ca.cert.$format
>
> unable to load Private Key
> 140492430772088:error:0906D06C:PEM routines:PEM_read_bio:no start
> line:pem_lib.c:707:Expecting: ANY PRIVATE KEY
>
> How do I tell it that the private key is DER?

-inform is used to specify the encoding. You can find the man pages at
https://www.openssl.org/docs/man1.0.2/apps/. You want the req.html.

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

Re: [openssl-users] Throwing in the towel on ENV for DN

[Jeffrey Walton]

> It is coming down that I would need a unique cnf for each cert type, rather
> than one per signing CA.  Things just don't work well without prompting or
> very consistent DN content.  So I am going to pull most of my. ENV.  I am
> leaving it in for dir and SAN.
>
> I feel it is a bug that if in 'prompt = no' or -batch, if a DN object is
> empty (size 0), it should just be dropped.  This is not an error condition.

If this is a private PKI, then you can do things like that.

But I believe you need a distinguished name if you are following the
RFCs. Maybe you can modify your script to stuff the principal name
from the SAN in the DN somewhere.

> Next steps:
>
> complete basic setup for ecdsa pki and 802.1AR leaf.  Publish on my website.
> Write up 'lessons learned' and post it here.

I think there's a separate RFC or draft for 802.1AR, but I have not read it.

Maybe part of the pain point is, OpenSSL is not aware of it. Its just
using RFC 5280 (and to some extent, 6125).

Maybe you should stop using the command line tools and code something
up in C. Once you hit your stride using the C APIs, its easy to crank
out certificates the way you want them.

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

Re: [openssl-users] Cant get the subjectALtName inot the root cert

[Jeffrey Walton]

On Thu, Aug 17, 2017 at 6:30 PM, Robert Moskowitz  wrote:
> I guess I am making progress.  I am not getting SAN into the root cert.  my
> cnf has in it:
>
> [ req ]
> # Options for the `req` tool (`man req`).
> default_bits= 2048
> prompt  = no
> distinguished_name  = req_distinguished_name
> string_mask = utf8only
> req_extensions  = req_ext
>
> [ req_ext ]
> #subjectAltName = email:$ENV::adminemail
> #subjectAltName = email:ad...@htt-consult.com
> subjectAltName = IP:192.168.24.1
>
> I tried all three above alternatives for SAN.  No SAN in the root cert
> created with:
>
> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>   -new -x509 -days 7300 -sha256 -extensions v3_ca -out certs/ca.cert.pem
>
> Thanks for any insight.
>
> This type of cnf worked for creating a CSR and with the copy option the SAN
> made it into the cert.

It looks a bit unusual for a Root CA.

As far as signing the CSR, you need

copy_extensions = copy

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

Re: [openssl-users] Implementing deprecation of commonname and emailaddress

[Jeffrey Walton]

On Thu, Aug 17, 2017 at 11:34 AM, Erwann Abalea
<erwann.aba...@docusign.com> wrote:
>
>> Le 17 août 2017 à 17:26, Jeffrey Walton <noloa...@gmail.com> a écrit :
>>
>>>> When you see a name like "example.com" in the CN, its usually a CA
>>>> including a domain name and not a hostname.
>>>
>>> That's nonsense.
>>
>> If a certificate is issued under CA/B policies, and CN=example.com but
>> it _lacks_ SAN=example.com, then its a not a hostname and it should
>> not be matched.
>
> Such a certificate would be mis-issued and be revoked immediately. CN MUST be 
> an FQDN (or a wild carded FQDN, or an IP address), and a copy of the value in 
> CN MUST be present in the SAN extension.

Oh, you would have some fun watching how various user agents handle
that scenario. For your first stop, check out how OpenSSL handles it.

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

Re: [openssl-users] Implementing deprecation of commonname and emailaddress

[Jeffrey Walton]

>> When you see a name like "example.com" in the CN, its usually a CA
>> including a domain name and not a hostname.
>
> That's nonsense.

If a certificate is issued under CA/B policies, and CN=example.com but
it _lacks_ SAN=example.com, then its a not a hostname and it should
not be matched.

I'm aware of OpenSSL's behavior in the matter. But OpenSSL does not
understand issuing policies so its easy to confuse.

Forgive me if OpenSSL is now imbued with knowledge of issuing policies
and how matching should occur outside of the RFCs.

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

Re: [openssl-users] Implementing deprecation of commonname and emailaddress

[Jeffrey Walton]

On Thu, Aug 17, 2017 at 12:28 AM, Robert Moskowitz  wrote:
> I have skimmed through a few RFCs following today's postings and a few web
> sites.  It would seem to me that I should:
>
> Remove commonName and emailAddress completely from the cnf file. They no
> longer belong in any cert, root or intermediate CA certs, server or user
> certs.

CommonName is supplied for viewing by tools like certificate viewers.
It should probably be a friendly name, like "Example Web Services".

Don't include hostnames in the CN. If you list it in the CN, then it
must be listed in the SAN, too. You must list it twice.

When you see a name like "example.com" in the CN, its usually a CA
including a domain name and not a hostname. It confusing for users and
user agents. I've seen user agents match a hostname based on the
domain name.

On the backend, there's usually a redirect for the domain example.com
to send user agents to a host like www.example.com. It happens up at
layer 7, not at layer 4.

> For servers include something like in the cnf file:
>
> subjectAltName = DNS:www.example.com, DNS:example.com, DNS=localhost,
> EMAIL:postmas...@example.com

Don't include an email address.

X.509 and PKIX certificates don't really have a proper field for email
addresses. That's why they get mashed into CommonName.

> (That is all suppose to be on a single line in case your mail viewer wraps
> it).
>
> Um, I can specify 'localhost' in this manner if I am on the server and
> connecting in the browser with https://localhost ??

Yes.

You can also put IP addresses there. The RFC's mostly allow it. The
CA/Browser Forum Baseline Requirements (CA/B BR) forbids it, but its
not clear (to me) what current browser behavior is.

For completeness, non-browser user agents, like wget and openssl,
follow the RFC standards and issuing policies. Browsers follow the
CA/B BR. That's why you often see browsers reject something accepted
by other user agents.

You might also be interested in
https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority/21340898#21340898
and 
https://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-certificate-with-openssl.
They questions and answers reference about 6 different standards.

> And for clients:
>
> subjectAltName = EMAIL:u...@example.com
>
> I am looking at how to build the above line using ENV variables. It is more
> a matter of how I do it than can I do it...

This is a whole 'nother can of worms. Also see
https://security.stackexchange.com/questions/62746/how-to-encode-a-username-in-pkix-certificate.

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

Re: [openssl-users] How to get a bye or word from BIGNUM in OpenSSL 1.1?

[Jeffrey Walton]

On Wed, Aug 2, 2017 at 12:38 AM, Jakob Bohm <jb-open...@wisemo.com> wrote:
> On 02/08/2017 04:21, Jeffrey Walton wrote:
>>
>> I'm trying to extract the low-order byte or word from a BIGNUM in
>> OpenSSL 1.1. We were told to use BN_bn2binpad, but its not clear to me
>> how to specify the location we want to extract.
>>
>> For example:
>>
>>  const char v[] = "ffeeddccbbaa99887766554433221100";
>>  BIGNUM n = BN_new();
>>
>>  if (BN_hex2bn(, v))
>>  {
>>  fprintf(stderr, "failed to parse BIGNUM\n");
>>  exit (1);
>>  }
>>
>> I don't see how to get the low-order word 33221100, or the second to
>> last byte 11.
>>
>> Here' the documentation but I don't see how to do it:
>> https://www.openssl.org/docs/man1.1.0/crypto/BN_bn2binpad.html. Other
>> libraries, like Java, Botan and Crypto++ allow us to specify a potion
>> to extract from in cases like these.
>>
>> How do we extract bytes or words from a BIGNUM?
>>
>> Thanks in advance.
>
> BN_bn2binpad (and it's friends) always give you *all* the bytes
> in the number in a buffer of you own.  You can then extract the
> bytes from there.
>
> If you care mostly about the least significant bytes, using
> BN_bn2lebinpad may be easier than BN_bn2binpad, as the least
> significant bytes will be first, not last, in the result.

Thanks.

It would be nice if the OpenSSL devs ate their own dogfood and
suffered that inefficient crap. I would wager that crap would change.

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

[openssl-users] How to get a bye or word from BIGNUM in OpenSSL 1.1?

[Jeffrey Walton]

I'm trying to extract the low-order byte or word from a BIGNUM in
OpenSSL 1.1. We were told to use BN_bn2binpad, but its not clear to me
how to specify the location we want to extract.

For example:

const char v[] = "ffeeddccbbaa99887766554433221100";
BIGNUM n = BN_new();

if (BN_hex2bn(, v))
{
fprintf(stderr, "failed to parse BIGNUM\n");
exit (1);
}

I don't see how to get the low-order word 33221100, or the second to
last byte 11.

Here' the documentation but I don't see how to do it:
https://www.openssl.org/docs/man1.1.0/crypto/BN_bn2binpad.html. Other
libraries, like Java, Botan and Crypto++ allow us to specify a potion
to extract from in cases like these.

How do we extract bytes or words from a BIGNUM?

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

Re: [openssl-users] Is RDRAND the default engine in OpenSSL 1.1.0?

[Jeffrey Walton]

On Fri, Jul 28, 2017 at 3:53 PM, Salz, Rich  wrote:
>> I thought RDRAND was disabled as the default random engine since
>> 1.0.1f. Has that changed in OpenSSL 1.1.0?
>
> No.  Do "git grep ENGINE_set_default_RAND"

Ack, thanks. I wonder where that's coming from for 1.1.0. Maybe
Dropbox is providing vendor patches.

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

[openssl-users] Is RDRAND the default engine in OpenSSL 1.1.0?

[Jeffrey Walton]

I thought RDRAND was disabled as the default random engine since
1.0.1f. Has that changed in OpenSSL 1.1.0?

Related, see:

* https://stackoverflow.com/q/45370852/608639
* http://seclists.org/fulldisclosure/2013/Dec/99
* 
https://software.intel.com/en-us/blogs/2014/10/03/changes-to-rdrand-integration-in-openssl
* https://trac.torproject.org/projects/tor/ticket/10402
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: CAVP fips_rsastest.c not producing the correct signature?

[Jeffrey Walton]

On Fri, Jul 28, 2017 at 12:15 AM, Swetha Hariharan
 wrote:
>
>
> I am trying test the rsa 186-2 openssl fips module 2.0.16 implementation
> using the NIST Testvectors. Using the  fips_rsastest.c file the
> FIPS_rsa_x931_generate_key_ex(rsa, keylen, bn_e, NULL) function called to
> generate the modulus n as the output and taking modulus size as the input
> i,e [mod=1024]. Then this modulus along with the appropriate hash function
> and message is passed to FIPS_rsa_sign(rsa, Msg, Msglen, dgst, pad_mode,
> Saltlen, NULL,sigbuf, (unsigned int *)) to obtain the signature as
> the output.
> But each time i execute the c code it generates different modulus n. Why is
> output changing after every execution. What am i doing wrong? I am facing
> the same problem with DSA parameter generation also. It will help me.

Key generation for RSA and DSA use pairwise consistency checks, not
known answer tests.

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

Re: [openssl-users] OpenSSL 1.1+: How to disable building of Manpages etc.?

[Jeffrey Walton]

On Sat, Jul 22, 2017 at 2:37 PM, Oliver Niebuhr
 wrote:
> Hi.
>
> I searched the Web and checked the Configure File. Am I blind or is
> there really no Parameter to disable the creation of the Documentation?
>
> As I also test the Qt Framework, I often recompile OpenSSL. You are
> right, building the Docs will only take 2 Minutes - but it sums up to
> countless hours for me.

Use 'make install_sw'. Maybe something like:

make distclean
./config enable-ec_nistp_64_gcc_128
make -j 9
make install_sw

enable-ec_nistp_64_gcc_128 is for x86_64. Also see
https://wiki.openssl.org/index.php/Compilation_and_Installation#Configure_Options.

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

[openssl-users] Configure 1.0.2 for Windows without readscreen()

[Jeffrey Walton]

Hi Everyone,

Windows 10 makes CreateCompatibleBitmap (and friends) available for
Desktop Apps only. For other builds, like phones and IoT gadgets, the
functions are not available.

My question is, is it possible to configure OpenSSL 1.0.2 to avoid the
missing Windows APIs, like readscreen()?

If not, is there a way to remove the Windows API specific stuff except
maybe CryptGenRandom?

Looking at 
https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/crypto/rand/rand_win.c,
I don't see an interesting guard. So I'm guessing the rand_win
generator may need to be removed.

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

Re: [openssl-users] Openssl 1.1.0f support for building Openssh7.2p2 and above

[Jeffrey Walton]

On Mon, Jul 10, 2017 at 2:01 AM, Sravani Maddukuri via openssl-users
 wrote:
>
> Is there any plans in the future to get the support of OpenSSL 1.1.0 for
> OpenSSH?

You should ask the OpenSSH folks.

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

Re: [openssl-users] Openssl 1.1.0f support for building Openssh7.2p2 and above

[Jeffrey Walton]

On Sun, Jul 9, 2017 at 11:31 PM, Sravani Maddukuri via openssl-users
 wrote:
> Dear Concern,
>
> Can you please update me on my below query?
>
> Does openssl 1.1.0f version support building Openssh7.2p2 and above
> versions?

As far as I know, OpenSSH does not support OpenSSL 1.1.0. Kurt Roeckx
provided the initial port and offered the patches to OpenSSH, but they
were never merged.

Also see http://github.com/openssh/openssh-portable/pull/48 and
https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes#OpenSSH.

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

Re: [openssl-users] OpenSSL and RPATH's (was: Cannot find SSL_CTX_get0_param in libssl library)

[Jeffrey Walton]

> RPATHs have advantages, but they have some major issues, too. For
> instance, if for whatever reason you need to move files around so that
> things are stored in a different location, suddenly you'll need to
> recompile everything -- because the RPATH is a hardcoded location of the
> library in use. This is very confusing, and not something that an
> average developer will expect.
>
> There is usually no need to hardcode the location of the library in use,
> provided the SONAME is configured correctly. Surprise surprise, OpenSSL
> actually does that right:
>
> wouter@gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
> |grep SONAME
>   SONAME   libssl.so.1.0.2
> wouter@gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.1
> |grep SONAME
>   SONAME   libssl.so.1.1
>
> There is no way that ld.so will load libssl1.1 for an application that
> is compiled against libssl.so with an SONAME of libssl.1.0.2 -- unless,
> of course, you do things like muck about with RPATH and point it to the
> wrong version of the library. In that case, you broke it, you get to
> keep both pieces.

The OpenSSL I build from sources is located in /usr/local. The gear
from /usr/local is first on-path.

This is what happens on Ubuntu 16.10:

$ /usr/bin/openssl errstr 0x3208408D
/usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: relocation error: /usr/bin/openssl: symbol
COMP_zlib_cleanup, version OPENSSL_1.0.0 not defined in file
libcrypto.so.1.0.0 with link time reference

This is what happens on Fedora release 25:

$ /usr/bin/openssl errstr 0x3208408D
error:3208408D:lib(50):func(132):reason(141)

It seems to me SONAME's just don't work as expected.

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

Re: [openssl-users] 1st time through, only -- "Can't open root/database.attr for reading, No such file or directory" ?

[Jeffrey Walton]

On Sun, Jun 4, 2017 at 8:57 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
> On Sun, Jun 4, 2017 at 7:56 PM, PGNet Dev <pgnet@gmail.com> wrote:
>> On 6/4/17 4:51 PM, Jeffrey Walton wrote:
>>>>
>>>> but the process STARTS with an apparently non-fatal error ...
>>>>
>>>>  Using configuration from /home/sec/newCA/openssl.cnf
>>>>  Can't open root/database.attr for reading, No such file or
>>>> directory
>>>>  140013244086016:error:02001002:system
>>>> library:fopen::crypto/bio/bss_file.c:74:fopen('root/database.attr','r')
>>>>  140013244086016:error:2006D080:BIO routines:BIO_new_file:no such
>>>> file:crypto/bio/bss_file.c:81:
>>>
>>>
>>> This usually indicates the OpenSSL conf file cannot be found. Its odd
>>> that "Using configuration from /home/sec/newCA/openssl.cnf" is
>>> reported.
>>>
>>> Maybe you can try `OPENSSL_CONF=/home/sec/newCA/openssl.cnf `
>>> to isolate the issue (or maybe rule out its not a conf file problem).
>>
>>
>> The message above doesn't indicate that openssl.cnf can't be found.  In fact
>> it explcitly states that it IS found and IS using it
>>
>>>>  Using configuration from /home/sec/newCA/openssl.cnf
>>
>> It's the same openssl.cnf used in all the PRIOR steps, with not problem
>> whatsoever.
>>
>> Rather it's
>>
>>>>  Can't open root/database.attr for reading, No such file or
>>>> directory
>>
>> that's not found.
>>
>> I've found that if I simply
>>
>> touch root/database.attr
>> touch intermediate/database.attr
>>
>> as already's been done with
>>
>> touch root/database
>> touch intermediate/database
>
> Oh, I was not aware you were skipping steps. I guess that explains the
> unusual results.

BTW, I believe you are also supposed to add an initial serial number.
Something like:

echo "0" > serialno.txt

Check your conf file for the filename.

(The information is somewhere in the docs. It may be in the
Certificates HOWTO or the CA HOWTO).

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

Re: [openssl-users] 1st time through, only -- "Can't open root/database.attr for reading, No such file or directory" ?

[Jeffrey Walton]

On Sun, Jun 4, 2017 at 7:56 PM, PGNet Dev <pgnet@gmail.com> wrote:
> On 6/4/17 4:51 PM, Jeffrey Walton wrote:
>>>
>>> but the process STARTS with an apparently non-fatal error ...
>>>
>>>  Using configuration from /home/sec/newCA/openssl.cnf
>>>  Can't open root/database.attr for reading, No such file or
>>> directory
>>>  140013244086016:error:02001002:system
>>> library:fopen::crypto/bio/bss_file.c:74:fopen('root/database.attr','r')
>>>  140013244086016:error:2006D080:BIO routines:BIO_new_file:no such
>>> file:crypto/bio/bss_file.c:81:
>>
>>
>> This usually indicates the OpenSSL conf file cannot be found. Its odd
>> that "Using configuration from /home/sec/newCA/openssl.cnf" is
>> reported.
>>
>> Maybe you can try `OPENSSL_CONF=/home/sec/newCA/openssl.cnf `
>> to isolate the issue (or maybe rule out its not a conf file problem).
>
>
> The message above doesn't indicate that openssl.cnf can't be found.  In fact
> it explcitly states that it IS found and IS using it
>
>>>  Using configuration from /home/sec/newCA/openssl.cnf
>
> It's the same openssl.cnf used in all the PRIOR steps, with not problem
> whatsoever.
>
> Rather it's
>
>>>  Can't open root/database.attr for reading, No such file or
>>> directory
>
> that's not found.
>
> I've found that if I simply
>
> touch root/database.attr
> touch intermediate/database.attr
>
> as already's been done with
>
> touch root/database
> touch intermediate/database

Oh, I was not aware you were skipping steps. I guess that explains the
unusual results.

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

Re: [openssl-users] 1st time through, only -- "Can't open root/database.attr for reading, No such file or directory" ?

[Jeffrey Walton]

> but the process STARTS with an apparently non-fatal error ...
>
> Using configuration from /home/sec/newCA/openssl.cnf
> Can't open root/database.attr for reading, No such file or directory
> 140013244086016:error:02001002:system 
> library:fopen::crypto/bio/bss_file.c:74:fopen('root/database.attr','r')
> 140013244086016:error:2006D080:BIO routines:BIO_new_file:no such 
> file:crypto/bio/bss_file.c:81:

This usually indicates the OpenSSL conf file cannot be found. Its odd
that "Using configuration from /home/sec/newCA/openssl.cnf" is
reported.

Maybe you can try `OPENSSL_CONF=/home/sec/newCA/openssl.cnf `
to isolate the issue (or maybe rule out its not a conf file problem).

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

Re: [openssl-users] Problem in connecting to Java (Tomcat) server with ECDHE ciphers

[Jeffrey Walton]

On Sun, Jun 4, 2017 at 1:01 AM, Pravesh Rai  wrote:
> Hi,
>
> Even though I've disabled SSLvX protocols on both - client (openssl-1.0.2k)
> & server (Java 1.8 with Tomcat), still getting following handshake error,
> while executing:
>
> "openssl s_client -connect a.b.c.d: -msg -debug -cipher
> ECDHE-ECDSA-AES256-GCM-SHA384"
>

GCM mode is a TLS 1.2 cipher. It looks like Java 8 enables it by
default; cf. 
https://blogs.oracle.com/java-platform-group/jdk-8-will-use-tls-12-as-default.

Maybe something like:

openssl s_client -connect www.example.com:443 -tls1_2 -servername
www.example.com

The command uses SNI and TLS 1.2, which is pretty much standard
practice nowadays.

If that does not do it, then maybe you can use SSLscan to identify the
protocols and cipher suites the server supports.
https://github.com/rbsec/sslscan

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

[openssl-users] OpenSSL and RPATH's (was: Cannot find SSL_CTX_get0_param in libssl library)

[Jeffrey Walton]

On Sun, May 28, 2017 at 5:31 PM, Salz, Rich  wrote:
>> The openssl program will use the wrong libssl.so and libcrypto.so.
>
> Yes, got it.
>
> But that's small potatoes compared to everyone else finding the wrong shared 
> library, and just saying "use rpath" doesn't help all those others.

OK, thanks.

So what are the problems here that need to be addressed? I think I
know some of them:

 1. Build OpenSSL with an RPATH if installed in non-system location
 2. Build user program with an RPATH if OpenSSL installed in non-system location
 3. Use another mechanism when Linux RATH not available (OS X, Solaris, friends)
 4. External build tools like Autotools and Cmake

Are there others?

OpenSSL build system should fix problem (1), like it does with BSDs.
The project should lead by example.

For (2) and (3), I think the best that can be done is (a) lead by
example as in (1); (b) ensure things like libcrypto.pc and libssl.pc
are up-to-date; and and (c) educate users. I realize the problems with
(c). If RTFM was going to work, then it would have happens in the last
50 years or so.

There's not much you can do with(4). They pick shitty flags, and they
are always going to be a problem. I advise *not* to build OpenSSL with
them, but Fan Boi's will still flock to them.

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

Re: [openssl-users] Cannot find SSL_CTX_get0_param in libssl library

[Jeffrey Walton]

On Sun, May 28, 2017 at 5:25 PM, Salz, Rich  wrote:
>> We still don't know what use case is being represented by omitting the
>> RPATH in the OpenSSL build.
>
> Because only one program, apps/openssl, presumably needs rpath.  But that 
> doesn't solve the problem for *external applications* that need to find 
> OpenSSL in a different place, does it?
>

Without RPATH's (or some other mechanism, like making openssl a script
that sets LD_LIBRARY_PATH), libssl.so will use the wrong libcrypto.so.
The openssl program will use the wrong libssl.so and libcrypto.so.

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

Re: [openssl-users] Build from source; library not found?

[Jeffrey Walton]

On Sun, May 28, 2017 at 5:16 PM, Hiran Chaudhuri
 wrote:
> It seems I misread the referenced documentation the first time.
>
> This stuff contains the answer, it just was not clear to me that also works
> on Linux.
> https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs.
>
> With that, the libraries have run paths that show the correct target
> directories. Thanks to all for the hint.

Arg... I consider confusing text a documentation bug.

Is this better:
https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs
?

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

Re: [openssl-users] Cannot find SSL_CTX_get0_param in libssl library

[Jeffrey Walton]

On Sun, May 28, 2017 at 2:59 AM, Mohit Batra  wrote:
> Hello All,
>
> I am trying to compile / install a utility from Source on CentOS that
> utilizes OpenSSL 1.1.0 (latest version) . However, I get the following
> error:
>
> configure: WARNING: Cannot find SSL_CTX_get0_param in libssl library. TLS
> hostname verification will not be available.
>
> Kindly help me out on this error.

When you build OpenSSL and your program, use an RPATH. Also see
https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs
.

We still don't know what use case is being represented by omitting the
RPATH in the OpenSSL build. Building OpenSSL with new library, but
runtime link to old library after installation makes no sense to most
users.

You can probably do it using LD_LIBRARY_PATH, but RPATHs are easier.

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

Re: [openssl-users] Build from source; library not found?

[Jeffrey Walton]

On Sat, May 20, 2017 at 7:10 AM, Hiran Chaudhuri
 wrote:
> Am 19-May-2017 00:36:18 +0200 schrieb openssl-us...@dukhovni.org:
>
>> hiran.chaudhuri> Now this is interesting. Yes, openssl can find both the
>> libraries
>> hiran.chaudhuri> libssl and libcrypto. Would that imply that rpath is only
>> a setting
>> hiran.chaudhuri> for application (executables) but not for shared
>> libraries?
>> hiran.chaudhuri> In that case the test I tried would be totally
>> meaningless.
>>
>> Yes, that's correct.
>
> NO, it is not correct, shared libraries also have rpaths for their
> own dependencies. And when building OpenSSL for installation in
> non-default locations (not /usr/lib and the like) the libraries
> should have an rpath.
>
> It would sound logical. But how could I then enforce the runpath to be set
> in the libraries?

https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs.

I've never understood the use case - build a new/updated openssl,
compile time link against the new one, and then runtime link against
the old one.

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

Re: [openssl-users] Dumb question about DES

[Jeffrey Walton]

On Thu, May 11, 2017 at 2:13 PM, Scott Neugroschl  wrote:
> OK.  Are the 3DES CBC ciphers still part of DEFAULT?

>From OpenSSL 1.0.1t:

$ openssl ciphers "DEFAULT"
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-
SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SH
A:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:DHE-D
SS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DS
S-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-S
HA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM
-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA
:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA2
56-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GC
M-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128
-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA
:SRP-AES-128-CBC-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DH
E-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128
-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAME
LLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RS
A-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES
128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:SEED-SHA:CAMELLIA128-SHA
:PSK-AES128-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:
ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE
-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-3
DES-EDE-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3
-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How many SAN entries...?

[Jeffrey Walton]

On Wed, Apr 26, 2017 at 1:03 PM, Blumenthal, Uri - 0553 - MITLL
 wrote:
> A naïve question. A certificate that contains SAN attribute(s) – is there a
> limit on how many, say, RFC822 SAN attributes can a valid certificate have?
>
>
>
> It’s been my understanding that a cert can contain as many SAN attributes as
> needed, but it appears that Apple believes it has to be only one (because
> certificates with more than one are not processed properly).

Lol... Apple is notorious for their defective and untested software.
I'm pretty sure they don't have a QA department. Also see
https://news.ycombinator.com/item?id=11034071.

Worse, when a bug is reported through their RADAR, it goes unfixed.
They force users into QA, and then don't fix the bugs that are
reported.

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

Re: [openssl-users] EVP_CIPHER_CTX array not compiling

[Jeffrey Walton]

On Sun, Apr 23, 2017 at 9:36 AM, Salz, Rich via openssl-users
 wrote:
>>#define OTEXT_AES_KEY_INIT(ctx, buf) { \
>>EVP_CIPHER_CTX_init(ctx); \
>>EVP_EncryptInit_ex(ctx, EVP_aes_128_ecb(), NULL, buf, ZERO_IV); \
>>}
>
> Most of the datatypes are now opaque.  This means you can't have an 
> EVP_CIPHER_CTX object, but instead a pointer to it.  Don't call the init 
> function, call the new function.  And then that has rippling changes in your 
> code.

Related, see https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes.
The page name is kind of boring, but it discusses how to convert from
1.0.2 to 1.1.0. In addition, it provides a small compatibility layer
so a lot of code "just works" for both 1.0.2 and 1.1.0.

We lifted it from Kurt's patch to OpenSSH. OpenSSH is stuck at 1.0.2,
and Kurt provided them with a migration path.

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

Re: [openssl-users] openssl-compat patch for OpenSSL 1.0.2 and below?

[Jeffrey Walton]

On Mon, Apr 3, 2017 at 5:49 PM, Benjamin Kaduk <bka...@akamai.com> wrote:
> On 04/02/2017 07:42 PM, Jeffrey Walton wrote:
>
> I was looking at Kurt Roeckx 's patches for OpenSSH at
> https://github.com/openssh/openssh-portable/pull/48/files. See
> libcrypto-compat.h and libcrypto-compat.c.
>
> Are the source files distributed by OpenSSL? If so, where is the download?
>
> If not, can the OpenSSL project consider adding them. They are very
> useful for managing projects that depend on older and newer OpenSSL
> libraries. OpenSSL taking on the responsibility would help ensure
> consistency and quality.
>
>
> The topic of backwards-compat headers has come up a few times previously on
> the list; with the resolution being a call for some external contributor to
> host and maintain them.
>
> So, no, OpenSSL does not distribute such things.

Thanks. The files are now hosted on OpenSSL's wiki at
https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes. We'll keep
an eye on them.

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

[openssl-users] openssl-compat patch for OpenSSL 1.0.2 and below?

[Jeffrey Walton]

I was looking at Kurt Roeckx 's patches for OpenSSH at
https://github.com/openssh/openssh-portable/pull/48/files. See
libcrypto-compat.h and libcrypto-compat.c.

Are the source files distributed by OpenSSL? If so, where is the download?

If not, can the OpenSSL project consider adding them. They are very
useful for managing projects that depend on older and newer OpenSSL
libraries. OpenSSL taking on the responsibility would help ensure
consistency and quality.

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

[openssl-users] install libcrypto.so.1.1 -> /usr/local//usr/local/lib64/libcrypto.so.1.1 ?

[Jeffrey Walton]

I'm working with OpenSSL 1.1.0. I'm trying to set prefix=/usr/local,
openssldir=/usr/local and libdir=/usr/local/lib64. The configure looks
like:

INSTALL_PREFIX=/usr/local
INSTALL_LIBDIR=$INSTALL_PREFIX/lib64
KERNEL_BITS=64 ./config no-ssl2 no-ssl3 no-comp shared \
enable-ec_nistp_64_gcc_128
-Wl,-rpath,$INSTALL_LIBDIR --prefix=$INSTALL_PREFIX \
--openssldir=$INSTALL_PREFIX --libdir=$INSTALL_LIBDIR

When I look at the tail of the compile and install I see:

...
install ./include/openssl/x509.h -> /usr/local/include/openssl/x509.h
install ./include/openssl/x509_vfy.h -> /usr/local/include/openssl/x509_vfy.h
install ./include/openssl/x509v3.h -> /usr/local/include/openssl/x509v3.h
install libcrypto.a -> /usr/local//usr/local/lib64/libcrypto.a
install libssl.a -> /usr/local//usr/local/lib64/libssl.a
install libcrypto.so.1.1 -> /usr/local//usr/local/lib64/libcrypto.so.1.1
link /usr/local//usr/local/lib64/libcrypto.so ->
/usr/local//usr/local/lib64/libcrypto.so.1.1
install libssl.so.1.1 -> /usr/local//usr/local/lib64/libssl.so.1.1
link /usr/local//usr/local/lib64/libssl.so ->
/usr/local//usr/local/lib64/libssl.so.1.1
install libcrypto.pc -> /usr/local//usr/local/lib64/pkgconfig/libcrypto.pc
install libssl.pc -> /usr/local//usr/local/lib64/pkgconfig/libssl.pc
install openssl.pc -> /usr/local//usr/local/lib64/pkgconfig/openssl.pc
*** Installing engines
install engines/capi.so -> /usr/local/usr/local/lib64/engines-1.1/capi.so
install engines/padlock.so -> /usr/local/usr/local/lib64/engines-1.1/padlock.so
*** Installing runtime files
install libcrypto.so.1.1 -> /usr/local//usr/local/lib64/libcrypto.so.1.1
install libssl.so.1.1 -> /usr/local//usr/local/lib64/libssl.so.1.1
install apps/openssl -> /usr/local/bin/openssl
install ./tools/c_rehash -> /usr/local/bin/c_rehash

I believe OpenSSL 1.0.2 is a little better behaved. I don't recall
seeing this when using it, but I might be wrong.

Any ideas how to get OpenSSL to use /usr/local as a prefix, but place
its libraries in /usr/local/lib64?

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

[openssl-users] speed test rdrand

[Jeffrey Walton]

Hi Everyone,

Is it possible to speed test RDRAND and RDSEED generators? If so, then
how do we do it?

$ openssl speed -engine rdrand
engine "rdrand" set.
Doing md4 for 3s on 16 size blocks: 8339773 md4's in 3.00s
Doing md4 for 3s on 64 size blocks: 6616610 md4's in 3.00s
Doing md4 for 3s on 256 size blocks: 4132167 md4's in 3.00s
...

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

Re: [openssl-users] Compiling OpenSSL 1.1.0e with AF_ALG engine

[Jeffrey Walton]

>> Sorry, never mind. After taking a closer look at the source code I saw
>> that there are further compile time and run-time kernel version
>> checks in e_afalg.c. I adjusted the version number and got that to
>> work now.
>
> Well, why does the afalg engine depend on Linux 4.1?
> AF_ALG is part of Linux since 2.6.38.
>
> Furthermore it is not clear to me why the Kernel version is being
> checked during the build.
> What if I build on an older kernel?
> Does your build system offer a config option for that?

Also see https://mta.openssl.org/pipermail/openssl-dev/2016-March/006171.html

Its been my experience that most AFALG issues are due to the kernel
and problems with its implementation, and not OpenSSL.

Kernel test vectors are virtually non-existent, so things randomly
move in and out of a state of "it works as expected" to other various
states. For example, here are the AFALG test vectors:
https://github.com/tstruk/afalg_async_test. They are not in the kernel
proper, they are incomplete, and its hits or miss whether they will
work as expected.

You can learn if an async driver is available with:

   cat /proc/crypto | egrep '^(name|driver|async|$)'

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

Re: [openssl-users] Issues while "configuring before compiling" OpenSSL on Raspberry-Pi

[Jeffrey Walton]

On Sun, Feb 12, 2017 at 8:13 AM, Ajay Garg  wrote:
> Any ideas please?
> Is compiling openssl even possible on Raspberry-Pi?
>

Try 'config' rather than 'Configure'. It looks like it does the job.
I'm not sure why the same triplet produces different results. Maybe
you need to perform a 'make dclean' to clean former artifacts?

$ git clone https://github.com/openssl/openssl
...
$ cd openssl
...

$ git checkout OpenSSL_1_0_2d
Checking out files: 100% (14097/14097), done.
Note: checking out 'OpenSSL_1_0_2d'.
...

$ ./config
Operating system: armv7l-whatever-linux2
Configuring for linux-armv4
Configuring for linux-armv4
no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
no-gmp  [default]  OPENSSL_NO_GMP (skip dir)
no-jpake[experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-libunbound   [experimental] OPENSSL_NO_LIBUNBOUND (skip dir)
no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
no-rfc3779  [default]  OPENSSL_NO_RFC3779 (skip dir)
no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
no-shared   [default]
no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE (skip dir)
no-store[experimental] OPENSSL_NO_STORE (skip dir)
no-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
no-zlib [default]
no-zlib-dynamic [default]
...

created directory `include/openssl'
e_os2.h => include/openssl/e_os2.h
making links in crypto...
make[1]: Entering directory '/home/jwalton/openssl/crypto'
crypto.h => ../include/openssl/crypto.h
opensslv.h => ../include/openssl/opensslv.h
opensslconf.h => ../include/openssl/opensslconf.h
ebcdic.h => ../include/openssl/ebcdic.h
symhacks.h => ../include/openssl/symhacks.h
ossl_typ.h => ../include/openssl/ossl_typ.h
constant_time_test.c => ../test/constant_time_test.c
...

generating dummy tests (if needed)...
make[1]: Entering directory '/home/jwalton/openssl/test'
md2test.c => dummytest.c
rc5test.c => dummytest.c
jpaketest.c => dummytest.c
make[1]: Leaving directory '/home/jwalton/openssl/test'

Configured for linux-armv4.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Decrypt old openssl files

[Jeffrey Walton]

>  I have two systems one with openssl 1.0.1e (debian wheezy) and the new one
> with openssl 1.1.0c (debian stretch)
>
>  The files encrypted with 1.0.1e are not decryptable via 1.1.0c
> These are the investigations I have done
>
> on my system with 1.0.1e openssl
> $ echo some text > file
> $ cat file  | openssl  aes-256-cbc  -pass pass:test  > file.enc
> $ md5sum file.enc
> 5482ea53a6677865d1e559ac3057738c  file.enc
>
> when I bring that file over to my system with 1.1.0c openssl
> $ md5sum file.enc
> 5482ea53a6677865d1e559ac3057738c  file.enc
> $ cat file.enc | openssl  aes-256-cbc  -d -pass pass:test
> bad decrypt
> 4146981184:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad
> decrypt:crypto/evp/evp_enc.c:529:
>
> Please can someone tell me what other options I Am supposed to pass to get
> decryption done successfully.

>From the OpenSSL 1.1.0c-3 update notes. I don't believe its in the
'openssl enc' man page yet
(https://www.openssl.org/docs/man1.0.1/apps/enc.html).

  The openssl enc command changed the default digest (used to create the key
  from passphrase) from MD5 to SHA256 since the version 1.1.0. The digest can
  be specified with the -md option.

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

Re: [openssl-users] Issue on Windows Server 2003 Resigning Expired CA certificate

[Jeffrey Walton]

On Fri, Feb 3, 2017 at 12:37 PM, Brandon Shiers
 wrote:
> I have a client that has a CA certificate that has expired.
>
> They are running Windows Server 2003 and OpenSSL 0.9.8d and FreeRadius for
> authentiaction.  Their certificate expired yesterday afternoon and I've been
> trying to get it resigned but I'm getting the following eerrors:
>
> E:\OpenSSL\bin\PEM\demoCA\private>e:\openssl\bin\openssl verify
> e:\openssl\bin\c
> acert.pem
> Error opening certificate file e:\openssl\bin\cacert.pem
> 3964:error:02001002:system library:fopen:No such file or
> directory:.\crypto\bio\
> bss_file.c:352:fopen('e:\openssl\bin\cacert.pem','rb')
> 3964:error:20074002:BIO routines:FILE_CTRL:system
> lib:.\crypto\bio\bss_file.c:35
> 4:
> unable to load certificate

Check the OpenSSL conf file first:
http://stackoverflow.com/q/16658038. You might find the the error is
due to the openssl.cfg file, and not the cacert.pem file.

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

Re: [openssl-users] How to detect AES-NI compatible CPU

[Jeffrey Walton]

On Fri, Feb 3, 2017 at 1:55 PM, Chris Clark  wrote:
> My application links to OpenSSL 1.1.0 dynamically, and I would like to
> be able to determine if the CPU supports the AES-NI instruction set.
> Is there an OpenSSL API that can do this?

Also note that even though the machine is capable of AES-NI, it does
not mean OpenSSL will use the hardware acceleration. If you call
AES_encrypt (and friends), then you get the "software-only"
implementation. If you disable the feature in the environment with
OPENSSL_ia32cap="~0x202", then you get the "software-only"
implementation

To use AES-NI, and other hardware accelerators like ARMv8's
instructions, you have to use the EVP interface.

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

Re: [openssl-users] FW: problem with missing STDINT.H file

[Jeffrey Walton]

> The attached text file is a snippet from attempting to install
> openssl-1.1.0c on a Solaris 8 machine. As can be seen, failed when
>  could not be found. There is no such file anywhere on this
> machine. As root, searched from the root directory for the file. Do have
>  in more than one location, /usr/include
> /opt/SUNWSpro/prod/include/CC/std   /opt/SUNWSpro/prod/include/CC/stlport4

CC is the Sun C++ compiler. C99 offered  and its available
for C programs.  provides uint32_t, uintptr_t and friends.
Many C++ compilers offer them, but the  types it was not
required for C++ until recently (C++11?).

Until this email, I thought Microsoft was the only implementation
which did not offer it in most of its compilers. Microsoft users must
include  instead (I think it changed in VS2013 with better
C++11 support).

I know  is available on later Solaris, but I don't know what
you need for early Solaris. Or maybe more correctly, its available in
later versions of Sun Studio/Oracle Studio/Developer Studio (like
versions 12).

The real question is for you, do you have the data types like
uint32_t, uintptr_t, and friends.

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

Re: [openssl-users] Leading Zeros in ASN1_INTEGER?

[Jeffrey Walton]

On Mon, Jan 30, 2017 at 5:03 AM, Matthias Ballreich
 wrote:
> thanks for explanation.
>
> But why did Windows Cert Manager and Firefox Cert Manager show 00BEED73EE as
> serial number instead of BEED73EE (which openssl shows)?

Its just a presentation detail. It appears Microsoft and Mozilla take
the content octets of the ASN.1 integer and they hex encoded it.
OpenSSL appears to convert the it into a binary number/big endian
array and hex encodes it before presenting it to you.

Another tool could have turned it into a binary number and Base64
encoded it before presenting it to you.

The important detail is the underlying data. You can use tools like
OpenSSL's asn1parse or Gutmann's dumpasn1 to see the raw data, if
needed.

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

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

[Jeffrey Walton]

> Could someone from the OpenSSL team please explain the rationale for this
> decision? What is the problem with using assignments with 0 or NULL to
> initialize pointers?

I'm not from the team, so take it for what its worth...

On some systems, NULL is _not_ 0. NULL can be anywhere in memory the
architecture wants it to be. It can be in a high page in memory, too.
One of my instructors in college was telling me about a system he
worked on where NULL was an address in the last page in memory, so it
took a value like `0x`.

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

Re: [openssl-users] Build problems on Windows

[Jeffrey Walton]

> IF EXIST libcrypto-1_1-x64.dll.manifest DEL /F /Q
> libcrypto-1_1-x64.dll.manifest
> link /nologo /debug /dll  /implib:libcrypto.lib
> /out:libcrypto-1_1-x64.dll /def:libcrypto-1_1-x64.def
> @C:\Users\jesaremi\AppData\Local\Temp\nm8557.tmp || (DEL /Q libcrypto.*
> libcrypto-1_1-x64.* && EXIT 1)
> crypto\aes\aes_cfb.obj : fatal error LNK1112: module machine type 'X86'
> conflicts with target machine type 'x64'
> NMAKE : fatal error U1077: 'link' : return code '0x1'
> Stop.
>

It sounds like the wrong Developer Tools Command Prompt was opened. You can
find them through Start -> Programs -> Visual Studio  -> Developer
Tools. Also see
https://msdn.microsoft.com/en-us/library/ms229859(v=vs.110).aspx .

If you plan on building for x86 and you configure for VC-WIN32, then be
sure you open the x86 command prompt, and not the x64 one.

If you want to build for x64, then be sure to configure with VC-WIN64A, and
be sure to open a x64 developer command prompt.

If you have the correct command prompt open, then perform a clean or
distclean. You may have old artifacts lying around.

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

Re: [openssl-users] stronger Kex

[Jeffrey Walton]

> I have two servers for testing purpose :
> - debian 6, apache 2.2,   openssl 1.0.1t  (mutu)
> - centos 7, apache 2.4.6, openssl 1.0.1e-fips (dedicated)
>
> Now, these 2 serveurs offers only those ciphers :
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
>
> I have two goals. First, I would like to use at least secp384r1
> and second (no problem), use an ECC certificate.
>
> Is it possible to do it with CHACHA20-POLY1305 ?
> Is it possible to use this cipher on those servers ?

You need OpenSSL 1.1.0 or above for ChaCha20/Poly1305:

$ openssl version
OpenSSL 1.1.0b  26 Sep 2016

$ openssl ciphers | tr ':' '\n' | grep -i chacha
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
DHE-RSA-CHACHA20-POLY1305
RSA-PSK-CHACHA20-POLY1305
DHE-PSK-CHACHA20-POLY1305
ECDHE-PSK-CHACHA20-POLY1305
PSK-CHACHA20-POLY1305

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

Re: [openssl-users] MinGW64 / MSYS2 and ./Configure : use of Windows style path causing failures to 'make'

[Jeffrey Walton]

On Tue, Dec 27, 2016 at 12:24 AM, Ron Gaw 
via openssl-users  wrote:
> I am using a MinGW64 / MSYS2 environment to compile OpenSSL1.1.0c, but
> failing consistently after multiple attempts with a few variations each
> attempt (including deleting entire source directory and
> re-untar/ungzipping).   I believe there's something wrong either with my
> environment settings or ./Configure options.  This is the output of
> ./Configure after setting only the CFLAGS env var:
>
> $ export "CFLAGS=-03"
> $ ./Configure mingw64 --prefix=/usr/local zlib shared
> Configuring OpenSSL version 1.1.0c (0x1010003fL)
> ...
> PERL  =C:\msys64\mingw64\bin\perl.exe
>
> SIXTY_FOUR_BIT mode
>
> Configured for mingw64.
>
> $ make
> C:\msys64\mingw64\bin\perl.exe "-I." -Mconfigdata "util\dofile.pl" \
> "-oMakefile" crypto\include\internal\bn_conf.h.in >
> crypto\include\internal\bn_conf.h
> /bin/sh: C:msys64mingw64binperl.exe: command not found
> make: *** [Makefile:701: crypto\include\internal\bn_conf.h] Error 127
>
>
> It seems the "\" is the culprit here, since the execution of the make
> command appears to strip those out and then (as expected) the /bin/sh cannot
> recognize that large hash of what should have been the path to Perl.  I did
> edit the first Makefile above to :
> Change the base PERL to "C:/msys64/mingw64/bin/perl.exe", *and*
> crypto/include/internal/bin_conf.h.in >
> crypto/include/internal/bin_conf.h
>
> The above worked, but *only* for that line of the make file (as I expected).
> It then fails at the very next line because I didn't edit every "\" to
> become "/" instead.  I'm not sure I'm willing to do that much editing...
> seems there's got to be a better way to make this work.
>
> I realize this has something to do with specifying ./Configure mingw64 
> and how it's populating the Makefiles using Windows-style paths, but I'm not
> sure it's safe / okay to fake having a Unix build target instead, since this
> will likely create new / other problems with libraries, etc.
>
> Am I missing a ./Configure option, an environment variable I should preset,
> or something else altogether?

http://stackoverflow.com/q/40948353/608639
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Compile OpenSSL for Android

[Jeffrey Walton]

On Wed, Dec 21, 2016 at 6:16 PM, Salz, Rich  wrote:
>> checking for library containing SSL_library_init... no
>> configure: error: libfko needs ssl
>
> The application is not prepared to build against 1.1.0  That function was 
> removed, and a #define for backward compatibility is used instead.
>

Also see 
https://wiki.openssl.org/index.php/Compilation_and_Installation#Autoconf
. Its another way to address the "SSL_library_init symbol or
OPENSSL_init_ssl symbol" issue.

The missing 1.1.0 code paths will need to be added. The compiler will
tell you where most of the problems are.

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

Re: [openssl-users] big endian vs little endian

[Jeffrey Walton]

On Sun, Dec 18, 2016 at 5:09 PM, Viktor Dukhovni
 wrote:
>
>> On Dec 18, 2016, at 2:55 PM, Walter H. via openssl-users 
>>  wrote:
>>
>> encrypt
>> openssl enc -e -in file -out encryptfile -aes-256-gcm
>
> GCM is not supported with "openssl enc(1)".  Use a CBC cipher
> instead.

+1. This was late to be documented, but its available at
(https://www.openssl.org/docs/man1.0.2/apps/enc.html):

"The enc program does not support authenticated
encryption modes like CCM and GCM. The utility
does not store or retrieve the authentication tag."

Maybe the encrypt program should throw an error rather than producing
incorrect results without a warning.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application

[Jeffrey Walton]

> So what is the correct way, 1 or 2?
>
> 1)
>
> RAND_poll()
> /* RAND_bytes is unnecessary */
> /* RAND_add is unnecessary */
>
> 2)
>
> RAND_poll()
> RAND_bytes(buf, 128);
> /* RAND_add is unnecessary */

On Windows, you call CryptGenRandom to obtain your seed for the
OpenSSL PRNG. On Linux, you use one of the random devices, like
/dev/srandom, /dev/random, or /dev/urandom.

Windows Phone and Windows Store apps add a twist, like requiring calls
to BCryptGenRandom. There's no way to wrote portable code when you
factor in Windows Phone and Windows Store. It will be a #define mess.

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

Re: [openssl-users] TLS Heartbeat

[Jeffrey Walton]

On Sat, Dec 10, 2016 at 9:25 PM, Rasool, Kaja Mohideen (Nokia - IN)
 wrote:
> Ok, maybe, TCP is doing it. Is there any other API using which I can specify
> the payload length & number of bytes for padding to send a TLS Heartbeat
> request? Then, I can use that API to send out a big enough heartbeat request
> so my server recognize & responds to it.

Maybe related, see
https://www.igvita.com/2013/12/16/optimizing-nginx-tls-time-to-first-byte/.
It shows how to measure and adjust for some throughput improvements.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Doubt about OpenSSL library initialization in an HTTP client application

[Jeffrey Walton]

> I'm trying to speed up the initialization of a legacy HTTP client
> application. Debugging that code, I found the following functions being
> called each application startup:
>
>   initialization
> SSL_library_init()
> SSL_load_error_strings()
> OpenSSL_add_all_algorithms()
> RAND_screen()
>
> however, the execution of RAND_screen()  spends about 3 seconds.

Also see https://wiki.openssl.org/index.php/Library_Initialization and
https://wiki.openssl.org/index.php/Random_Numbers#Windows_Issues.

The short of it is, you should stop relying on auto-initialization of
the RNG, and seed it yourself with a call to `RAND_add`.

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

[openssl-users] How to use Poly1305 with EVP interfaces?

[Jeffrey Walton]

I'm working from Master. I'm having trouble locating the message
digest for Poly1305, and how to use it with
https://wiki.openssl.org/index.php/EVP_Message_Digests.

At the moment I can only find EVP_chacha20_poly1305. It seems like if
Poly1305 is going to be paired with something, it would be AES, and
not TLS-ChaCha. I tried to use it with EVP_Message_Digests, but its
having a lot of trouble.

>From the type of EVP_chacha20_poly1305() and some of the error
messages, it looks like I may need to use the authenticated encryption
interfaces. I guess (maybe?) use AAD data only? If so, how do we
handle the per-message nonce?

How do I use the EVP interfaces to create a MAC with Poly1305?

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

[openssl-users] CONF-less OpenSSL configuration?

[Jeffrey Walton]

Is it possible to setup a CONF-less OpenSSL? If so, how?

The use case is mobile apps, like Android, iOS and Windows Phone.
There is no OPENSSLDIR per se; and the app's install directory will be
a moving target like a UUID.

I know hacks can be applied for iOS, like forgoing a macro and
returning NSHomeDirectory(). But I think I would rather avoid the hack
and go CONF-less.

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

[openssl-users] How to sort cipher list by ephemeral/non-ephemeral?

[Jeffrey Walton]

I prefer to use a cipher list like "HIGH:!aNULL:!RC4:!MD5". I prefer
it because its fairly easy to parse and understand. Its also easy to
teach to developers.

I want the resulting ciphers sorted with the ephemeral suites at the
head of the list.

How does one sort the list with ephemeral suites at the top of the list?

-

If 'openssl ciphers' is stable with respect to its output, then the
order is (is this @strength?):

# openssl ciphers -v 'HIGH:!aNULL:!MD5:!RC4:!PSK:!SRP:!KRB5' | cut -f 1 -d ' '
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA
DHE-DSS-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-DSS-AES256-SHA256
DHE-RSA-AES256-SHA
DHE-DSS-AES256-SHA
DHE-RSA-CAMELLIA256-SHA
DHE-DSS-CAMELLIA256-SHA
ECDH-RSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-GCM-SHA384
ECDH-RSA-AES256-SHA384
ECDH-ECDSA-AES256-SHA384
ECDH-RSA-AES256-SHA
ECDH-ECDSA-AES256-SHA
AES256-GCM-SHA384
AES256-SHA256
AES256-SHA
CAMELLIA256-SHA
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-ECDSA-AES128-SHA
DHE-DSS-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
DHE-DSS-AES128-SHA256
DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA
DHE-RSA-CAMELLIA128-SHA
DHE-DSS-CAMELLIA128-SHA
ECDH-RSA-AES128-GCM-SHA256
ECDH-ECDSA-AES128-GCM-SHA256
ECDH-RSA-AES128-SHA256
ECDH-ECDSA-AES128-SHA256
ECDH-RSA-AES128-SHA
ECDH-ECDSA-AES128-SHA
AES128-GCM-SHA256
AES128-SHA256
AES128-SHA
CAMELLIA128-SHA
ECDHE-RSA-DES-CBC3-SHA
ECDHE-ECDSA-DES-CBC3-SHA
EDH-RSA-DES-CBC3-SHA
EDH-DSS-DES-CBC3-SHA
ECDH-RSA-DES-CBC3-SHA
ECDH-ECDSA-DES-CBC3-SHA
DES-CBC3-SHA
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Alert number 43

[Jeffrey Walton]

> When I tested a remote server using s_client, it responded with:
>
> verify return:1
>
> 139790582232992:error:14094413:SSL routines:SSL3_READ_BYTES:sslv3
> alert unsupported certificate:s3_pkt.c:1259:SSL alert number 43
>
> 139790582232992:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl
> handshake failure:s3_pkt.c:598:
>
>
> I found the the following URL about this:
>
> http://stackoverflow.com/questions/14435839/ssl-alert-43-when-doing-client-authentication-in-ssl?answertab=oldest#tab-top
>
> My question: Does this indicate something wrong with server side
> certificate like the URL said?

Netscape Cert Type was recently removed, IIRC.

OpenSSL servers [used to?] have a bug where they can't use the EC key
pair they generated for use with an EC-based certificate. Also see
http://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography#Named_Curves.

Post the certificate. Use `openssl s_client -connect :
-tls1 -servername  | openssl x509 -text -noout`

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

Re: [openssl-users] Use of openssl

[Jeffrey Walton]

>  I've a free certificate from startssl for my email address. Now I would
> like to create a certificate for one of my internet domain. How can I do
> that? Can I use openssl? Is there a free service like cacert.org that allow
> to deploy free class IV certificates that are recognized?
> Sorry for my poor question. Thank you for your reply.

The three free services I am aware of are (1) CaCert, (2) StartCom,
and (3) Let's Encrypt.

CaCert is kind of dead because their roots are still using MD5. Nobody
trusts them, especially after Flame and Stuxnet.

StartCom has directions on their website. I don't recall what the
process is, but I've used it in the past. You might want to review the
instructions StartCom provides.

Let's Encrypt is new and has become very popular. I don't know the
process because I have never used them. They will likely suffer more
"unable to get local issuer certificate" problems than StartCom,
especially on older mobile devices.

You can ask users to install the Let's Encrypt Root CA to overcome the
"unable to get local issuer certificate" problem. Asking users to do
anything is usually a slippery slope, and it will probably create user
grief and generate support emails.

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

[openssl-users] What define(s) does enable-ec_nistp_64_gcc_128 translate to?

[Jeffrey Walton]

I'm working on OS X and I want to audit for configure-time use of
enable-ec_nistp_64_gcc_128.

Grepping the sources shows 1 relevant hit, but I don't see a define:

$ grep -IR 'enable-ec_nistp_64_gcc_128' *
CHANGES: Specify "enable-ec_nistp_64_gcc_128" on the Configure (or
config) command
INSTALL:  enable-ec_nistp_64_gcc_128
crypto/ec/asm/ecp_nistz256-x86_64.pl:#"enable-ec_nistp_64_gcc_128";

What define or defines does `enable-ec_nistp_64_gcc_128` translate
into? Is there anything set in ? Or how can I audit for
it?

*

openssl-1.1.0b$ KERNEL_BITS=64 ./config shared no-ssl2 no-comp
enable-ec_nistp_64_gcc_128 --prefix=/usr/local --openssldir=/usr/local
Operating system: x86_64-apple-darwinDarwin Kernel Version 12.6.0: Wed
Mar 18 16:23:48 PDT 2015; root:xnu-2050.48.19~1/RELEASE_X86_64
Configuring for darwin64-x86_64-cc
Configuring OpenSSL version 1.1.0b (0x0x1010002fL)
* Deprecated options: no-ssl2
no-asan [default]  OPENSSL_NO_ASAN
no-comp [option]   OPENSSL_NO_COMP (skip dir)
no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
no-egd  [default]  OPENSSL_NO_EGD
no-fuzz-afl [default]  OPENSSL_NO_FUZZ_AFL
no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
no-msan [default]  OPENSSL_NO_MSAN
no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
no-sctp [default]  OPENSSL_NO_SCTP
no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE
no-ssl3 [default]  OPENSSL_NO_SSL3
no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
no-ubsan[default]  OPENSSL_NO_UBSAN
no-unit-test[default]  OPENSSL_NO_UNIT_TEST
no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
no-zlib [default]
no-zlib-dynamic [default]
Configuring for darwin64-x86_64-cc
CC=cc
...
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] calloc vs kssl_calloc

[Jeffrey Walton]

On Sat, Oct 1, 2016 at 5:18 PM, Salz, Rich  wrote:
>
>> However there are very many OpenSSL users (myself included) who rely on
>> the legal status of OpenSSL/SSLeay as having no US origin parts.  If this has
>> changed, it needs a big red banner at the top of the www.openssl.org, every
>> affected source file with the original EAY copyright boilerplate or its 
>> OpenSSL
>> clone etc.
>
> We are NOT going to mark US/non-US contributions, sorry.

That's kind of a new twist on "Authentication is not X". For Java and
Web Apps, its "Authentication is not Authorizations" (Sandboxes and
Secure Contexts). For Git is "Authentication is not Code Integrity"
(Commit Signing).

In the new case, I thinks its "Authentication is not Lawfulness". Or
is it Lawlessness?

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

[openssl-users] OpenSSL and sourc'ing countries (was: calloc vs kssl_calloc)

[Jeffrey Walton]

>>> Is there something more I should do on this issue?  I recall the OpenSSL
>>> terms of use strongly discouraged people from the US from helping, due to US
>>> export restrictions.
>>
>> That's kinda outdated.
>
> However there are very many OpenSSL users (myself included)
> who rely on the legal status of OpenSSL/SSLeay as having no
> US origin parts.  If this has changed, it needs a big red
> banner at the top of the www.openssl.org, every affected
> source file with the original EAY copyright boilerplate or
> its OpenSSL clone etc.

That's kind of interesting. Are you saying there are countries where
you can source and import your crypto from some countries, but not
other countries?

As I understand the US procedures from working with DoC and BIS, you
don't need an import license (only an export license). But I'd be
interested in hearing how some countries are trying to control the
crypto from the import side of the equation.

More humorously, does import versus export even matter? The crypto
genie is out of the bottle. It can't be put back.

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

Re: [openssl-users] calloc vs kssl_calloc

[Jeffrey Walton]

On Sat, Oct 1, 2016 at 4:32 PM, Geoffrey Coram  wrote:
> I reported a bug, I'm not a developer
> / on the developer list; will someone else take this, or is there some
> bug database that I should enter an issue into?

If its an OpenSSL bug, then I believe you send an email to
r...@openssl.org along with the details. OpenSSL makes it easy on folks.

Also see Item 17 in the FAQ: "I think I've found a bug, what should I
do?", http://www.openssl.org/docs/faq.html#BUILD17.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Coverity Scan projects for OpenSSL?

[Jeffrey Walton]

> openssl/openssl is for current maser.
> OpenSSL_release is for 1.0.2
>
> Note1: we might review that now that 1.1.0 has been released.
>
> Note2: we recently changed our policy on Coverity access. Previously we
> did not typically allow access to the defect reports. Now we allow
> Defect viewer access to anyone that requests it.

These numbers are outstanding.

Defect Density - 0.02
Outstanding Defects - 4

Why aren't you announcing them?

You might also consider providing an announcement when new results are
available at a significant point in time for those interested in this
sort of thing. "Significant point in time" might be after a major
merge or passing through the release process security gate.

The announcement also raises awareness for the folks who are not
following the project on Coverity Scan. Ideally, your announcement
would be picked up by users of OpenSSL. They would register their
projects and start raising the bar in their software, too.

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

[openssl-users] OpenSSL 1.1.0 release (was: new FIPS module)

[Jeffrey Walton]

> Work on the new FIPS module has so far taken a backseat to higher
> priority topics like the 1.1 release ...

OpenSSL 1.1.0 was a very strong release. The team did an awesome job.
Hats off to them for a job that exceeded well done.

I did not observe problems at places where you can take the
temperature of developers, like Stack Overflow. The was an occasional
"project X fails to compile with OpenSSL 1.1.0" and "How do I do Y now
that Z is private" but that was expected. Other than that, you would
not even know 1.1.0 was released because things went so smoothly.

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

[openssl-users] Coverity Scan projects for OpenSSL?

[Jeffrey Walton]

Hi Everyone,

Coverity Scan has two projects for OpenSSL (https://scan.coverity.com/dashboard)

  * openssl/openssl
  * OpenSSL_release

Which should we request access to for the reports?

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

Re: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install'

[Jeffrey Walton]

On Wed, Sep 21, 2016 at 8:35 AM, Jing Liu  wrote:
> I’ve tried all my best to solve this problem but failed. Can you help me?
>
> - OS: Windows 10
>
> - Perl: ActivePerl 5.12.2 build 1202
>
> - Development environment: MS Visual Studio 2010 SP1
>
> - OpenSSL version: OpenSSL 1.1.0

Have you tried Strawberry Perl instead of Active Perl? I seem to
recall someone stated they were able to clear a similar issue using
Strawberry Perl.

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

Re: [openssl-users] OpenSSL Release Strategy and Blog

[Jeffrey Walton]

On Fri, Sep 9, 2016 at 8:26 AM, Pfluegl, Andreas  wrote:
> We started using OpenSSL in 2010 for Windows and Linux. We gladly followed
> the release strategy suggestion, as it allowed us to deliver patches without
> recompiling our code. So we still compile and link our code against 1.0.0
> while delivering the current 1.0.2x versions (which by the way works great).
>
> At Windows we started with VC10 and soon migrated to VC12, but currently we
> are struggling with porting to VC14. So we are considering to update the
> openSSL version we compile and link against to 1.0.2. I don't expect 1.0.2
> to be binary compatible to 1.0.1 or 1.0.3 as 1.0.0 is, but I expect it to be
> binary compatible with all 1.0.2x versions. Since I found no official
> statement which confirms this, I'd ask you to confirm this theory of mine.

https://www.openssl.org/docs/faq.html#MISC8 :

8. How does the versioning scheme work?

After the release of OpenSSL 1.0.0 the versioning scheme changed.
Letter releases (e.g. 1.0.1a) can only contain bug and security fixes
and no new features. Minor releases change the last number (e.g.
1.0.2) and can contain new features that retain binary compatibility.
Changes to the middle number are considered major releases and neither
source nor binary compatibility is guaranteed.

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

Re: [openssl-users] More secure use of DSA?

[Jeffrey Walton]

> Only if you think everything has to be equally protected.  That's the 
> assertion I am not thrilled with.  Sometimes knowing who sent it is more 
> important -- the metadata -- and sometimes the content -- say, the value of 
> the check -- is more important.

And its probably easier to go around the crypto rather than through
it. Why spend the compute cycles when a phishing email will usually do
nicely.

(I do a lot of work in US DoD and US Federal, so we have to honor
security levels).

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

Re: [openssl-users] More secure use of DSA?

[Jeffrey Walton]

On Fri, Sep 2, 2016 at 11:50 AM, Leam Hall  wrote:
> Thanks to Matt Caswell for helping me fix the DSA question. His solution,
> based of the information I provided, was:
>
> openssl genpkey -genparam -algorithm DSA -pkeyopt \
>   dsa_paramgen_bits:2048 -out dsa.params
>
> openssl genpkey -paramfile dsa.params -out dsa.key
>
> Which leads to my next question. For general application and ssh level
> defense, is 2048 the right bit amount? Is there a reason not to go to 4096
> absent very high request counts? Are there other security flags I should
> use?


Security levels are the way to compare different algorithms. With some
hand waiving, its a way to normalize the security provided by an
algorithm. As cryptanalysis progresses on an algorithm, the security
level usually drops. The naive attack is brute force, but sometimes
that's the best known attack.

2048-bit RSA and DSA provides about 112-bits of security. AES-128
provides about 126 bits of security; AES-256 provides about 256-bits
of security. SHA-1 provides about 80-bits of theoretical security due
to the birthday attack, but its closer to 64-bits in practice due to
Stevens attacks (Hash Clash, http://marc-stevens.nl/research/). MD5
provided about 64-bits of theoretical security, but its much less now
(http://www.win.tue.nl/hashclash/rogue-ca/). There are tables of
security levels from various standards groups. See, for example,
SP800-57, SP800-131, ECRYPT II Yearly Report on Algorithms and Key
Sizes, etc.

You often need to match security levels through out your system. For
example, if you are Key Agree'ing or Key Transporting to transport an
AES-128 key (128-bits of security), then you _don't_ want to use a RSA
1024-bit modulus (80-bits of security). Obviously, you don't attack
AES with 128-bits of security; rather, you attack the 80-bits of
security in 1024 RSA because its an easier problem.

Regarding SSH's position on DSA, I often wonder why they did not move
against ECDSA too since its the same algorithm over a different field.
DSA and ECDSA are both ElGamal-like signature schemes, both need a
subgroup order with a minimum size, both use a random k, etc.

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

Re: [openssl-users] (no subject)

[Jeffrey Walton]

On Fri, Aug 26, 2016 at 6:56 PM, Juliano Souza  wrote:
> I just found it.
>
> Hope to help someone with same requirement.
>
> http://www.cafesoft.com/products/cams/ps/docs32/admin/ConfiguringApache2ForSSLTLSMutualAuthentication.html
>

There's also Origin Bound Certificates (OCB),
http://www.czeskis.com/research/pubs/tls-obc.pdf. They are like
"tear-off" personal certificates. A user generates one on the fly for
an origin/site, and then uses it when needed. Its not signed by an
authority, so its like the user equivalent to a server's self signed
certificate.

The appealing thing with them is they effectively stop the MitM games
played by many user agents. Not surprisingly, the browser have mostly
rejected them because in their security model, interception is a valid
use case.

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

Re: [openssl-users] Migration from AES_ctr128_encrypt to EVP

[Jeffrey Walton]

> Could you please point me on some useful documentation, piece of code or any
> other source of information which would provide the guidelines for
> accomplishing my task? Or maybe somebody of you already have the experience
> in such migration which could be shared.

https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption
and 
https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption.

If you detail a specific problem, then better advice can probably be provided.

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

Re: [openssl-users] Load secrets to context.

[Jeffrey Walton]

>> Scenario 1 - Failing case
>>
>> SSL_CTX_use_certificate_file() : Loaded cert_file
>> SSL_CTX_use_certificate_chain_file() : Loaded chain_file
>
> Doing this makes no sense.  If you're loading the complete chain
> file, there's no reason to first load just the certificate.
>
> Just use SSL_CTX_use_certificate_chain_file(3), debugging incorrect
> usage is not a good use of time.

The best I can tell, its not an correct configuration. The NOTES
section says SSL_CTX_use_certificate_chain_file should be preferred,
but its not forbidden. Confer,
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_use_certificate.html
.

Perhaps its best to address the problem rather than attacking the
user. Its OK to disregard the feedback you are getting, but please
don't attack the users.

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

[openssl-users] OpenSSL and Microsoft fork on GitHub

[Jeffrey Walton]

Hi Everyone,

This just made my radar... Microsoft has a fork of OpenSSL at
http://github.com/Microsoft/openssl . It looks like it is actively
maintained.

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

Re: [openssl-users] Getting error 'SSLv2_client_method': identifier not found

[Jeffrey Walton]

On Mon, Jun 27, 2016 at 3:49 PM, Michael Wojcik
 wrote:
> SSLv2 is no longer supported, and neither are the SSLv2_*_method calls. (And
> yes, this causes build problems when updating to newer OpenSSL builds; and
> while that causes some pain, it was the Right Thing to do.)
>
> As Rich said, don't use SSLv2. Don't use SSLv3. If you can help it, don't
> use anything older than TLSv1.2.

The library should have unconditionally set OPENSSL_NO_SSL2 when it
yanked SSLv2 support. Iit was warned about use cases like this.

When SSLv2 was re-added to return NULL because, it still omitted
OPENSSL_NO_SSL2.

There was no need to break existing client code in this case.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q

[Jeffrey Walton]

On Sun, Jun 19, 2016 at 10:10 AM, Blumenthal, Uri - 0553 - MITLL
 wrote:
> I'm also speaking out of turn, but having both ends trying to be both server 
> and client *on the same connection* just does not make sense, TLS or DTLS.
>

Yeah, I was having trouble envisioning the use case. But I did not
want to dismiss it until I understood the requirements.

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

Re: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q

[Jeffrey Walton]

On Sun, Jun 19, 2016 at 9:47 AM, Test ssl  wrote:
> Hi Matt,
>
> This is a DTLSv1.0 connection, so the hosts on both sides will connect to
> each other acting as both TLS client and TLS server.
>
> We think the dtls failure is due to cipher suites. But we are not able to
> understand why it works for 1.0.1m with same certificate.
>
> Please help us.

I don't mean to speak out of turn, but you are not giving Matt too
much to work with.

Perhaps you could put together a minimum sample program which
demonstrates the problem? Or maybe give him s_server and s_client
commands to duplicate it?

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

Re: [openssl-users] Symbol(s) not found _TLSv1_2_method _BIO_test_flags

[Jeffrey Walton]

On Mon, Jun 13, 2016 at 6:32 PM, Dan S  wrote:
> So I had a suggestion to verify the correct linking by renaming the libssl
> and libcrypto built locally to something else, and linking to them- turns
> out that was the problem, apparently adding the search path in xcode does
> not take priority :( and it was still linking with the distributed old open
> ssl that came with 10.6 :(
>
> So I may just use the renamed files if I can't figure out how to tell the
> xcode to ignore the system libraries
>

Usually you do one of three things. First, you build your shared
object with a name. You will see something like this in the Makefile:

-install_name "$@" -current_version
"$(LIB_MAJOR).$(LIB_MINOR).$(LIB_PATCH)"...

Or, you use install_name_tool after you build the shared object to add
the name later. This is often used to reset the name after an install.

Second, you build as normal but you link against the static library
using the fully qualified pathname. You have to use the fully
qualified name because the IS X linker always uses the dynamic lib, if
available. it becomes an accute problem on iOS, where only the system
can supply dynlibs. You will see something like this when linking:

clang ... foo.o bar.o /usr/local/ssl/lib/libcrypto.a
/usr/local/ssl/lib/libssl.a -o foo.exe

This, you run your executable with DYLD_LIBRARY_PATH set
(http://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/dyld.1.html):

   DYLD_LIBRARY_PATH="/usr/local/ssl/lib:$DYLD_LIBRARY_PATH"; ./foo.exe

I personally use the second method. After years of fidlling with these
issues on multiple platforms, I try to avoid dynamic libraries as much
as possible. I want something that "just works" everywhere, and
linking against the static archive is the only thing I've found to
achieve it.

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

Re: [openssl-users] regarding ssl_server test

[Jeffrey Walton]

On Thu, May 26, 2016 at 5:51 PM, Jakob Bohm  wrote:
> On 26/05/2016 18:33, R-D intern wrote:
>>
>> Hello,
>>   I have implemented ssl for my internal server that listens over
>> a
>> private ip. Can anyone suggest how can I test my ssl_server? For eg.
>> Qualys
>> test shows the amount of ssl implementation of a server listening over
>> public ip  and even checks for vulnerabilities in ssl implementation. How
>> can such a thing be tested for a server listening over private ip?
>> Please help. Awaiting response.
>> Regards,
>> R-D Intern
>>
>
> Indeed, there are many servers that cannot be reached by the
> online configuration tests such as the one run by Qualsys.
>
> What would be really nice would be if one of the good test
> suites could be downloaded and run locally on internal servers,
> non-web servers, staging servers etc. to verify that
> configurations are correct, or at least as good as possible.

That's sslscan (http://sourceforge.net/projects/sslscan/). You need a
modern fork because the original version by Ventura-Whiting and Bowman
has been abandoned. The abandoned version lacks things like TLV 1.2
support and SNI support.

You can find lots of forks of the original sslscan on GitHub:
http://www.google.com/search?q=sslscan+site:github.com

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

Re: [openssl-users] good riddance to PayPal

[Jeffrey Walton]

On Thu, May 5, 2016 at 4:41 PM, Steve Marquess
 wrote:
> We've had a PayPal account for years, as the most convenient way for
> individuals to send small donations. However, as the person who has
> managed that account I can attest that PayPal has always been rather
> annoying to deal with, and I've finally hit my limit.

PayPal is renowned for poor customer service; confer,
http://www.google.com/search?q=paypal+sucks.

Get some bumper stickers and pins made up with the OpenSSL logo. Sell
them on Amazon and eBay for the value of a donation - $10, $25, etc.

Based on some estimates, Amazon and eBay will provide the Foundation's
presence at online retail stores that handle 75% of online spending
(c., 
http://www.marketwatch.com/story/amazon-will-account-for-more-than-half-of-2015-e-commerce-growth-says-macquarie-2015-12-22).

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