RE: Howto prevent cycles in engine invocation ?

[Fuchs, Andreas]

Hi Dimitry,

thanks, yes, that's why I'm doing inside the engine as well.

The question was regarding the library that my engine links against that in 
turn uses libcrypto again.

That linked library uses the EVP methods with the "default"-engine, which is 
however set from the surrounding application.

I guess it's a similar question to when an application links against liba.so 
and libb.so and both use openssl internally but set different default engines. 
How can you prevent them from interfering with each other ?

Thanks,
Andreas


From: openssl-users [openssl-users-boun...@openssl.org] on behalf of Dmitry 
Belyavsky [beld...@gmail.com]
Sent: Tuesday, March 19, 2019 21:09
To: openssl-users@openssl.org
Subject: Re: Howto prevent cycles in engine invocation ?

Hello Andreas,

I used smth like
===
RSA_METHOD my_rsa_method = {
"My RSA method",
0,  /* pub_enc */
0,  /* pub_dec */
0,  /* priv_enc */
my_priv_dec,  /* priv_dec */
0,  /* rsa_mod_exp */
0,  /* bn_mod_exp */
0,  /* init */
0,  /* finish */
RSA_METHOD_FLAG_NO_CHECK|RSA_FLAG_SIGN_VER,  /* flags */
NULL,   /* app_data */
my_rsa_sign,  /* rsa_sign */
0   /* rsa_verify */
};

static int my_priv_dec (int flen, const unsigned char *from,
unsigned char *to, RSA *rsa, int padding)
{
  const RSA_METHOD *def_meth = RSA_PKCS1_SSLeay();
  if ((rsa->meth == _rsa_method) && RSA_get_ex_data(rsa, my_key_pos))
  {
return my_op_rsa_decrypt(flen, from, to, rsa, padding);
  }

  return def_meth->rsa_priv_dec(flen, from, to, rsa, padding);
}
==
But this code worked for 1.0.* branch

вт, 19 марта 2019 г., 19:52 Fuchs, Andreas 
mailto:andreas.fu...@sit.fraunhofer.de>>:
Following scenario:

I have an engine that implements e.g. RSA decryption.
That engine links against a library that links against libcrypto to perform RSA 
decryption.

Now if I have an application that sets the default library to be my engine, 
won't I end up in an infinite loop ?

Or the other way around:
- Is there a way to change the default engine from within my engine before 
calling out to the library ?
- Can the library itself select "software-only" as an engine ?

I guess I don't have a concrete problem in my specific case, since I have 
app_data attached to any key and
if my engine receives a key without app_data, it will just call SSLeay() 
functions.

But what if that was not the case ?

Thanks a lot for any help,
Andreas

Re: Howto prevent cycles in engine invocation ?

[Dmitry Belyavsky]

Hello Andreas,

I used smth like
===
RSA_METHOD my_rsa_method = {
"My RSA method",
0,  /* pub_enc */
0,  /* pub_dec */
0,  /* priv_enc */
my_priv_dec,  /* priv_dec */
0,  /* rsa_mod_exp */
0,  /* bn_mod_exp */
0,  /* init */
0,  /* finish */
RSA_METHOD_FLAG_NO_CHECK|RSA_FLAG_SIGN_VER,  /* flags */
NULL,   /* app_data */
my_rsa_sign,  /* rsa_sign */
0   /* rsa_verify */
};

static int my_priv_dec (int flen, const unsigned char *from,
unsigned char *to, RSA *rsa, int padding)
{
  const RSA_METHOD *def_meth = RSA_PKCS1_SSLeay();
  if ((rsa->meth == _rsa_method) && RSA_get_ex_data(rsa, my_key_pos))
  {
return my_op_rsa_decrypt(flen, from, to, rsa, padding);
  }

  return def_meth->rsa_priv_dec(flen, from, to, rsa, padding);
}
==
But this code worked for 1.0.* branch

вт, 19 марта 2019 г., 19:52 Fuchs, Andreas :

> Following scenario:
>
> I have an engine that implements e.g. RSA decryption.
> That engine links against a library that links against libcrypto to
> perform RSA decryption.
>
> Now if I have an application that sets the default library to be my
> engine, won't I end up in an infinite loop ?
>
> Or the other way around:
> - Is there a way to change the default engine from within my engine before
> calling out to the library ?
> - Can the library itself select "software-only" as an engine ?
>
> I guess I don't have a concrete problem in my specific case, since I have
> app_data attached to any key and
> if my engine receives a key without app_data, it will just call SSLeay()
> functions.
>
> But what if that was not the case ?
>
> Thanks a lot for any help,
> Andreas

Re: cURL with openSSL 1.1.1 version

[Nicola]

Currently Ubuntu 18.04 ships with OpenSSL 1.1.0 (
https://packages.ubuntu.com/bionic/openssl) and official Ubuntu packages
depending on OpenSSL link against this version.

1.1.0 will be EOL in September, and after that the decision on which level
of support to provide depends on the Ubuntu project and their development
strategies.

1.1.1 was designed to minimize breaking changes coming from 1.1.0, so
existing applications shouldn't require major changes for the existing
functionality, but ultimately it will be Ubuntu decision if they are going
to maintain their fork of 1.1.0 after upstream EOL or to upgrade to 1.1.1

If you are compiling your own application disregarding the distribution
maintainers decisions, you are free to compile and link against your own
version of openssl and to the best of my knowledge recent versions of curl
will not create any issue when compiling against 1.1.1

If you have your own code using the OpenSSL API directly and have not
updated since 1.0.2, some changes will most likely be required as since
1.1.0 most structs are opaque and you need to use accessors to get and set
their members.

Best regards,

Nicola Tuveri

On Tue, Mar 19, 2019, 09:56 Swamy J-S  wrote:

> Hi,
>
>
>
> Currently am working with curl 7.58 and openssl 1.0.2 in ubuntu 18.04.
>
>
>
> As openssl 1.0.2 support will end this year, I want to upgrade my openssl
> to 1.1.1 branch.
>
>
>
> Right now my code uses curl library with libcurl4 and gnuTLS as SSL
> backend. Am using many curl options such as CURLOPT_SSL_VERIFYPEER ,
> CURLOPT_SSL_VERIFYHOST, CURLOPT_SSL_CTX_FUNCTION, CURLOPT_SSL_CTX_DATA etc.
>
>
>
>
> If I upgrade openssl to 1.1.1 then all these curl options will be working
> fine? Or should I upgrade curl and other things also?? If you have any
> document or release notes regarding this the please let me know.
>
>
>
> Regards,
>
> *SWAMY J S*
>

Re: Reg solaris support for openssl 1.1.1b

[Dennis Clarke]

On 3/19/19 4:38 AM, ramakrushna mishra wrote:
> Hi All,
> 
> Thanks for all your response.
> I have tried to set LD_LIBRARY_PATH to the lib path of newly installed
> openssl and still "./openssl version" fails with the same reason.
> 

right out of the ld man page we see the option -R passed to the linker :

 -R path
 -rpath path

 A colon-separated list of directories  used  to  specify
 library  search  directories  to  the runtime linker. If
 present and not NULL, the path is recorded in the output
 object  file  and passed to the runtime linker. Multiple
 instances of this option are concatenated together  with
 each path separated by a colon. See Directories Searched
 by the Runtime Linker in Linker and Libraries Guide.

 The use of a runpath  within  an  associated  object  is
 preferable  to  setting  global  search  paths  such  as
 through the LD_LIBRARY_PATH environment  variable.  Only
 the  runpaths  that  are  necessary  to find the objects
 dependencies should be recorded. ldd(1) can also be used
 to  discover  unused  runpaths  in dynamic objects, when
 used with the -U option.

 Various tokens can also be supplied with a runpath  that
 provide a flexible means of identifying system capabili-
 ties or an objects location. See Chapter 6, Establishing
 Dependencies  with  Dynamic String Tokens, in Linker and
 Libraries Guide. The $ORIGIN token is especially  useful
 in allowing dynamic objects to be relocated to different
 locations in the file system.


So that works. Alos there is a note about the dreaded :


 LD_LIBRARY_PATH

 A list  of  directories  in  which  to  search  for  the
 libraries specified using the -l option. Multiple direc-
 tories are separated by a colon.  In  the  most  general
 case,  this  environment variable contains two directory
 lists separated by a semicolon.

   dirlist1;dirlist2


 If ld is called with any number of occurrences of -L, as
 in:

   ld ... -Lpath1 ... -Lpathn ...


 then the search path ordering is:

   dirlist1 path1 ... pathn dirlist2 LIBPATH


 When the list of directories does not  contain  a  semi-
 colon, the list is interpreted as dirlist2.

 The LD_LIBRARY_PATH environment  variable  also  affects
 the runtime linkers search for dynamic dependencies.

 This environment variable can be specified with a _32 or
 _64   suffix.   This   makes  the  environment  variable
 specific, respectively, to 32-bit  or  64-bit  processes
 and  overrides  any non-suffixed version of the environ-
 ment variable that is in effect.


OKay good to know .. but ignore that for now.



 LD_OPTIONS

 A default set of options to  ld.  LD_OPTIONS  is  inter-
 preted by ld just as though its value had been placed on
 the command line, immediately following the name used to
 invoke ld, as in:

   ld $LD_OPTIONS ... other-arguments ...


OKay you need that.


 LD_RUN_PATH

 An alternative mechanism for specifying a runpath to the
 link-editor.  See the -R option. If both LD_RUN_PATH and
 the -R option are specified, -R supersedes.



Nice to know also.


So go back and recompile and set LD_RUN_PATH=/some/path/to/lib as well
as set LD_OPTIONS='-R/some/path/to/lib -L/some/path/to/lib ' and when
the link stage hits your output ELF files will have both a RUNPATH and
a RPATH set.  If you're using gcc you may also specify the option
-Wl,-rpath=/some/path/to/lib and you will get that passed to the linker.


dc

Building OpenSSL 1.1.1b for WinCE700

[田中創樹]

Hello,

I have successfully build OpenSSL 1.1.1b (only libraries, no app) for
WINCE700-ARMV4I, though I don't do any tests. Here is what I did. I hope
original sources will be changed so as there is no need to change.

1. Modify wcecompat.

Add an alias, "_access" for access() in wcecompat io.h as below.
--
#define access _wceaccess
#define _access _wceaccess
--

2. Set Environmental variables

set OSVERSION=WCE700
set PLATFORM=VC-CE
set TARGETCPU=ARMV4I
set WCECOMPAT=C:\Users\dev\tanaka\wcecompat
set LIB=C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Windows CE
Tools\SDKs\YOUR_SDK_NAME\Lib\ARMV4I;C:\Program Files\Microsoft
SDKs\Windows\v6.0A\Lib;C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\ce\lib\ARMV4I;C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\lib
set INCLUDE=C:\Program Files (x86)\Windows CE
Tools\SDKs\YOUR_SDK_NAME\Include\ARMV4I;C:\Program Files (x86)\Microsoft
Visual Studio 9.0\VC\atlmfc\include;C:\Program Files (x86)\Microsoft Visual
Studio 9.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v6.0A\include;
set Path=C:\WINCE700\sdk\bin\i386\arm;C:\Program Files (x86)\Microsoft
Visual Studio 9.0\Common7\Tools;C:\Program Files (x86)\Microsoft Visual
Studio 9.0\VC\VCPackages;C:\Program Files\Microsoft
SDKs\Windows\v6.0A\bin;C:\cygwin64\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE;C:\Program Files
(x86)\Microsoft Visual Studio 9.0\VC\BIN;%Path%
set LIBPATH=C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\ATLMFC\LIB;"C:\Program Files (x86)\Windows CE
Tools\SDKs\YOUR_SDK_NAME\Lib\ARMV4I";C:\Program Files (x86)\Microsoft
Visual Studio 9.0\VC\lib;C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\ce\lib\ARMV4I;

3. Configure

(for ARM)(Configurations/windows-makefile.tmpl) Delete a line of
"setargv.obj". setargv.obj in C:\Program Files (x86)\Microsoft Visual
Studio 9.0\VC\lib is for x86 and cannot be linked with ARM objs.

C:\Strawberry\perl\bin\perl Configure no-idea no-mdc2 no-rc5 no-asm no-ssl3
no-stdio no-async no-engine VC-CE

Using full path to specify Strawberry perl. I recommend Strawberry perl
here to avoid error messages, I used 5.24.4.1-32bit.

I added 3 options of "no-stdio" and "no-engine", "no-async". Because..
  * no-stdio: GetStdHandle() and STD_INPUT_HANDLE cannot be used in WinCE.
(used in apps\apps.c)
  * no-engine: Lack of CreatePipe() in WinCE (used in engines\e_dasync.c)
  * no-async: Lack of ConvertFiberToThread() in WinCE (used in
crypto\async\arch\async_win.c)
By "no-stdio" option, we build only libraries. No command line application
are generated.

4. Modify "makefile"

  * Add -D_MSC_VER=1300 in "CFLAGS="
  * In "CNF_CPPFLAGS=", change -I"\$(WCECOMPAT)/include" to
-I$(WCECOMPAT)/include
  * Change CNF_EX_LIBS=3 to CNF_EX_LIBS=ws2.lib crypt32.lib kernel32.lib
$(WCECOMPAT)\lib\wcecompat.lib $(WCECOMPAT)\lib\wcecompatex.lib
corelibc.lib coredll.lib

5. Modify C Source

Comment out a line of "#  define stat_stat" in
  crypto\conf\conf_def.c
  crypto\rand\randfile.c
  crypto\store\loader_file.c
Comment out a line of "#  define fstat   _fstat" in crypto\rand\randfile.c.

(crypt/init.c 167l and 777l) For lack of GetModuleHandleEx() in CE, Change
"# ifdef DSO_WIN32" to "# if defined(DSO_WIN32) && !defined(_WIN32_WCE)"
-
# ifdef DSO_WIN32
{
HMODULE handle = NULL;
BOOL ret;

/* We don't use the DSO route for WIN32 because there is a better
way */
ret = GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS
-

(crypto\rand\randfile.c 257l) For lack of GetEnvironmentVariableW() in CE,
Change "#if defined(_WIN32) && defined(CP_UTF8)" to "#if defined(_WIN32) &&
defined(CP_UTF8) && !defined(_WIN32_WCE)"

(for ARM)(include\internal\refcount.h)
  * Add "#include " for InterlockedExchangeAdd().
  * (106l) In function CRYPTO_UP_REF() and CRYPTO_DOWN_REF(), change 2
"_InterlockedExchangeAdd()" to be "InterlockedExchangeAdd()". There is no
_InterlockedExchangeAdd() for non x86 in C:\Program Files (x86)\Windows CE
Tools\SDKs\YOUR_SDK_NAME\Include\Armv4i\winbase.h.

(crypt/threads_win.c 27l) For lack of
InitializeCriticalSectionAndSpinCount() in CE, change
--
/* 0x400 is the spin count value suggested in the documentation */
if (!InitializeCriticalSectionAndSpinCount(lock, 0x400)) {
OPENSSL_free(lock);
return NULL;
}
--
to
--
#ifndef _WIN32_WCE
/* 0x400 is the spin count value suggested in the documentation */
if (!InitializeCriticalSectionAndSpinCount(lock, 0x400)) {
OPENSSL_free(lock);
return NULL;
}
#else
InitializeCriticalSection(lock);
#endif
--

6. Build

nmake

Then we will get the following artifacts.
  libcrypto.lib
  libcrypto-1_1.dll
  libcrypto-1_1.pdb
  libssl.lib
  libssl-1_1.dll
  libssl-1_1.pdb

Regards,
Soju TANAKA

cURL with openSSL 1.1.1 version

[Swamy J-S]

Hi,

Currently am working with curl 7.58 and openssl 1.0.2 in ubuntu 18.04.

As openssl 1.0.2 support will end this year, I want to upgrade my openssl to 
1.1.1 branch.

Right now my code uses curl library with libcurl4 and gnuTLS as SSL backend. Am 
using many curl options such as CURLOPT_SSL_VERIFYPEER , 
CURLOPT_SSL_VERIFYHOST, CURLOPT_SSL_CTX_FUNCTION, CURLOPT_SSL_CTX_DATA etc.

If I upgrade openssl to 1.1.1 then all these curl options will be working fine? 
Or should I upgrade curl and other things also?? If you have any document or 
release notes regarding this the please let me know.

Regards,
SWAMY J S

How I can add extension with sequence value to CSR using openssl library?

[work vlpl]

I know how to add simple extension (oid + str), for example

```
nid = OBJ_create("1.2.3.4", "shortname", "long name");
ASN1_OCTET_STRING_set(os, "ext value", 9);
ex = X509_EXTENSION_create_by_NID( NULL, nid, 0, os );
sk_X509_EXTENSION_push(exts, ex);
```

I want to learn how I can add extension with the next specification

The specific identity objects shall be contained in the attribute's
SET. Any identity object included in the resulting CSR shall be added
as a PKCS#9 Extension Request

- macAddress (OID 1.3.6.1.1.1.1.22), encoded as an IA5STRING type
- imei (OID 1.3.6.1.4.1.40808.1.1.3), encoded as an IA5STRING type
- meid (OID 1.3.6.1.4.1.40808.1.1.4), encoded as a BITSTRING type
- DevId (OID 1.3.6.1.4.1.40808.1.1.5), encoded as a PRINTABLESTRING type


I assume Extension Request extension has oid = 1.2.840.113549.1.9.14

And this is probably openssl config for extension

```
asn1 = SEQUENCE:attrs

[attrs]
attr1 = SEQUENCE:extreq

[extreq]
oid = OID:extensionRequest
vals = SET:extreqvals

[extreqvals]

oid1 = OID:macAddress
oid2 = OID:imei
oid3 = OID:meid
oid4 = OID:DevId
```

How I can do it in C?

RE: Building OpenSSL 1.1.1b for WinCE700

[Torrelli, Maxime]

Hello !

Thanks a lot for sharing this! I will try to compile it with our SDK and let 
you know if I get any testing results.


Greetings,

Maxime TORRELLI
Embedded Software Engineer

Conduent
Conduent Business Solutions (France)
1 rue Claude Chappe – BP 345
07503 Guilherand Granges Cedex

De : openssl-users  De la part de 
Envoyé : 19 March 2019 08:09
À : openssl-users@openssl.org
Objet : Building OpenSSL 1.1.1b for WinCE700

Hello,

I have successfully build OpenSSL 1.1.1b (only libraries, no app) for 
WINCE700-ARMV4I, though I don't do any tests. Here is what I did. I hope 
original sources will be changed so as there is no need to change.

1. Modify wcecompat.

Add an alias, "_access" for access() in wcecompat io.h as below.
--
#define access _wceaccess
#define _access _wceaccess
--

2. Set Environmental variables

set OSVERSION=WCE700
set PLATFORM=VC-CE
set TARGETCPU=ARMV4I
set WCECOMPAT=C:\Users\dev\tanaka\wcecompat
set LIB=C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Windows CE 
Tools\SDKs\YOUR_SDK_NAME\Lib\ARMV4I;C:\Program Files\Microsoft 
SDKs\Windows\v6.0A\Lib;C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\ce\lib\ARMV4I;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib
set INCLUDE=C:\Program Files (x86)\Windows CE 
Tools\SDKs\YOUR_SDK_NAME\Include\ARMV4I;C:\Program Files (x86)\Microsoft Visual 
Studio 9.0\VC\atlmfc\include;C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v6.0A\include;
set Path=C:\WINCE700\sdk\bin\i386\arm;C:\Program Files (x86)\Microsoft Visual 
Studio 9.0\Common7\Tools;C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\VCPackages;C:\Program Files\Microsoft 
SDKs\Windows\v6.0A\bin;C:\cygwin64\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
 Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE;C:\Program Files 
(x86)\Microsoft Visual Studio 9.0\VC\BIN;%Path%
set LIBPATH=C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\ATLMFC\LIB;"C:\Program Files (x86)\Windows CE 
Tools\SDKs\YOUR_SDK_NAME\Lib\ARMV4I";C:\Program Files (x86)\Microsoft Visual 
Studio 9.0\VC\lib;C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\ce\lib\ARMV4I;

3. Configure

(for ARM)(Configurations/windows-makefile.tmpl) Delete a line of "setargv.obj". 
setargv.obj in C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib is for 
x86 and cannot be linked with ARM objs.

C:\Strawberry\perl\bin\perl Configure no-idea no-mdc2 no-rc5 no-asm no-ssl3 
no-stdio no-async no-engine VC-CE

Using full path to specify Strawberry perl. I recommend Strawberry perl here to 
avoid error messages, I used 5.24.4.1-32bit.

I added 3 options of "no-stdio" and "no-engine", "no-async". Because..
  * no-stdio: GetStdHandle() and STD_INPUT_HANDLE cannot be used in WinCE. 
(used in apps\apps.c)
  * no-engine: Lack of CreatePipe() in WinCE (used in engines\e_dasync.c)
  * no-async: Lack of ConvertFiberToThread() in WinCE (used in 
crypto\async\arch\async_win.c)
By "no-stdio" option, we build only libraries. No command line application are 
generated.

4. Modify "makefile"

  * Add -D_MSC_VER=1300 in "CFLAGS="
  * In "CNF_CPPFLAGS=", change -I"\$(WCECOMPAT)/include" to 
-I$(WCECOMPAT)/include
  * Change CNF_EX_LIBS=3 to CNF_EX_LIBS=ws2.lib crypt32.lib kernel32.lib 
$(WCECOMPAT)\lib\wcecompat.lib $(WCECOMPAT)\lib\wcecompatex.lib corelibc.lib 
coredll.lib

5. Modify C Source

Comment out a line of "#  define stat_stat" in
  crypto\conf\conf_def.c
  crypto\rand\randfile.c
  crypto\store\loader_file.c
Comment out a line of "#  define fstat   _fstat" in crypto\rand\randfile.c.

(crypt/init.c 167l and 777l) For lack of GetModuleHandleEx() in CE, Change "# 
ifdef DSO_WIN32" to "# if defined(DSO_WIN32) && !defined(_WIN32_WCE)"
-
# ifdef DSO_WIN32
{
HMODULE handle = NULL;
BOOL ret;

/* We don't use the DSO route for WIN32 because there is a better way */
ret = GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS
-

(crypto\rand\randfile.c 257l) For lack of GetEnvironmentVariableW() in CE, 
Change "#if defined(_WIN32) && defined(CP_UTF8)" to "#if defined(_WIN32) && 
defined(CP_UTF8) && !defined(_WIN32_WCE)"

(for ARM)(include\internal\refcount.h)
  * Add "#include " for InterlockedExchangeAdd().
  * (106l) In function CRYPTO_UP_REF() and CRYPTO_DOWN_REF(), change 2 
"_InterlockedExchangeAdd()" to be "InterlockedExchangeAdd()". There is no 
_InterlockedExchangeAdd() for non x86 in C:\Program Files (x86)\Windows CE 
Tools\SDKs\YOUR_SDK_NAME\Include\Armv4i\winbase.h.

(crypt/threads_win.c 27l) For lack of InitializeCriticalSectionAndSpinCount() 
in CE, change
--
/* 0x400 is the spin count value suggested in the documentation */
if (!InitializeCriticalSectionAndSpinCount(lock, 0x400)) {
OPENSSL_free(lock);
return NULL;
}
--
to
--
#ifndef _WIN32_WCE
   

Re: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287

[Graham Leggett]

On 19 Mar 2019, at 03:22, Viktor Dukhovni  wrote:

>> On Mar 18, 2019, at 8:22 PM, Graham Leggett  wrote:
>> 
>> How would I decode the X509_REQ_INFO structure on the other side, turning it 
>> back into X509_REQ?
> 
> The function returns the DER form of the CRI, which can then be signed.
> You can use d2i_X509_REQ_INFO() to get an X509_REQ_INFO, but indeed there's
> not much you can do with that, other than DER-encode it again and sign.
> 
> Why do you need to do the encode and decode?  What's wrong with the original
> request object?

The code is a modular ca, and different modules communicate with each other 
generically using the standard DER encoded structures. Openssl isn’t visible 
through the API, it is an implementation detail.

>> While I can see a d2i_X509_REQ_INFO() function, I can’t find a corresponding 
>> function in openssl 1.1.0+ that assigns this to a X509_REQ, unless I am 
>> missing it?
> 
> It should not be needed.

I don’t follow - in order to get access to the data inside the X509_REQ_INFO 
structure, I need to first wrap it in a X509_REQ, otherwise I have no API calls 
to get access to the data inside it.

>> By way of concrete example, having crossed the module boundary we need to 
>> pull out details from the X509_REQ_INFO, which can only be done if this 
>> structure has been assigned to a X509_REQ first:
> 
> Can you be more specific about these "module boundaries”?

The modules are Apache httpd modules, and the boundaries between the modules 
are hooks that pass DER encoded structures between each module.

> In any case, given the DER form of the CRI, it is easy to construct
> the DER form of an enclosing CSR with a dummy signature:
> 
>   0:d=0  hl=4 l= 360 cons: SEQUENCE   -- Outer sequence and length:  
> 30 82 01 68
> 
>   4:d=1  hl=3 l= 210 cons: SEQUENCE   -- DER encoding of CRI
>   7:d=2  hl=2 l=   1 prim: INTEGER   :00
>   10:d=2  hl=2 l=   0 cons: SEQUENCE
>   12:d=2  hl=3 l= 159 cons: SEQUENCE
>   15:d=3  hl=2 l=  13 cons: SEQUENCE
>   17:d=4  hl=2 l=   9 prim: OBJECT:rsaEncryption
>   28:d=4  hl=2 l=   0 prim: NULL
>   30:d=3  hl=3 l= 141 prim: BIT STRING
>  174:d=2  hl=2 l=  41 cons: cont [ 0 ]
>  176:d=3  hl=2 l=  39 cons: SEQUENCE
>  178:d=4  hl=2 l=   9 prim: OBJECT:Extension Request
>  189:d=4  hl=2 l=  26 cons: SET
>  191:d=5  hl=2 l=  24 cons: SEQUENCE
>  193:d=6  hl=2 l=  22 cons: SEQUENCE
>  195:d=7  hl=2 l=   3 prim: OBJECT:X509v3 Subject Alternative 
> Name
>  200:d=7  hl=2 l=  15 prim: OCTET STRING  [HEX 
> DUMP]:300D820B6578616D706C652E636F6D
> 
>  217:d=1  hl=2 l=  13 cons: SEQUENCE  -- Signature algorithm OID 
> and parameters
>  219:d=2  hl=2 l=   9 prim: OBJECT:sha256WithRSAEncryption
>  230:d=2  hl=2 l=   0 prim: NULL
>  232:d=1  hl=3 l= 129 prim: BIT STRING-- Signature data
> 
> In the above we see that the CRI, needs (typically) an ~4-byte prefix
> of (0x30 + DER encoded length) and a suffix of the form:
> 
>   30 0d -- 13 byte sequence
>06 09 2a 86 48 86 f7 0d 01 01 0b  -- 9 byte OID 
> (sha256WithRSAEncryption)
>05 00 -- NULL parameters
>03 81 81 00   -- 128 byte bit string with 0 unused 
> bits
>xx xx xx xx ... xx-- 128 bytes of random data.
> 
> your random data could be all zeros.  The trailer length is then a
> fixed 147 bytes.  Add that to the length of CRI and prepend the
> outer sequence (0x30 + DER encoded (length CRI + 147)), then the
> CRI and then the trailer, and presto-magic you have a CSR with
> a bogus signature, but one that will encode and decode, just not
> pass "req -verify".
> 
> This isn't pretty, and perhaps we need some new functions to explicitly
> embed a CRI in a CSR, but it is certainly something you can do in the
> short term.

Can we not rather fix the initialisation of the X509_REQ in X509_REQ_new() so 
that it works like it used to? It seems like a massive headache to do something 
that used to be trivial.

I see there have been changes to openssl code relating to how structures are 
initialised, I suspect an error has crept in where an ASN.1 object is missing 
instead of empty, thus the malformed CSR.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Default DHE group

[Matt Caswell]

On 18/03/2019 23:05, Zeev Tarantov wrote:
> Since openssl verion 1.1.0, code for TLS server can use
> `SSL_CTX_set_dh_auto(ctx, 1);` to let openssl handle choice of DH group which
> will be used to generate ephemeral keys if a DHE cipher suite is negotiated.
> 
> TLS 1.3 limits DHE parameters to use groups from RFC 7919, from ffdhe2048 to
> ffdhe8192.
> Reference: https://tools.ietf.org/html/rfc8446#section-4.2.8.1
> 
> I'm looking at the function ssl_get_auto_dh in github master and you get one 
> of:
> RFC 5114 DH_get_1024_160
> RFC 5114 DH_get_2048_224
> RFC 3526 BN_get_rfc3526_prime_3072
> RFC 3526 BN_get_rfc3526_prime_8192
> 
> Because SSL_CTX_set_dh_auto does not use the values from RFC 7919, application
> developers choose to not use SSL_CTX_set_dh_auto.
> See for example this commit to nginx web server:
> https://hg.nginx.org/nginx/rev/1aa9650a8154

Well I don't think that commit is an example of developers choosing not to use
SSL_CTX_set_dh_auto because it doesn't use the values from RFC7919. The commit
doesn't mention RFC7919 at all and actually predates the publication of that RFC
in any case. Rather it seems to be a policy decision to not use fixed DH
parameters due to precomputation attacks. That concern would apply equally well
to RFC7919 - although I'm not aware of any practical precomputation attacks for
non-export grade DH params.

I'm also not aware of any concerns raised about the RFC3526/RFC5114 params
(other than the 1024 one is quite small - but looking at the logic of
SSL_CTX_set_dh_auto it selects a size based on the strength of the other
elements in the ciphersuite - so it will use larger DH params where 
appropriate).

> I also cannot really recommend postfix switch to SSL_CTX_set_dh_auto from the
> hardcoded default generated by the postfix developers
> (https://github.com/vdukhovni/postfix/blob/postfix-3.4/postfix/src/tls/tls_dh.c).
> 
> Patching software using openssl to use RFC 7919 groups "manually" does not 
> scale
> well. Expecting server admins to configure this at install time is laughable.
> 
> The situation is so dire, Google Chrome famously decided there are so many
> RSA-2048/DHE-1024 web servers deployed, that disabling DHE is the right thing 
> to do!

Again, this seems to be mixing up different things. I'm not sure how that is
relevant to the RFC7919 vs RFC5114/RFC3526 discussion.

> 
> In case dh_auto was set, why doesn't openssl use the RFC 7919 groups also with
> TLS versions below 1.3?

In fact OpenSSL does not support DHE in TLSv1.3 at all so it is not a case of
using RFC7919 for one protocol version and not for others. There is a PR for
adding TLSv1.3 support for this:

https://github.com/openssl/openssl/pull/8178

The reason that they aren't supported by SSL_CTX_set_dh_auto() at the moment is
that that function was introduced before RFC7919 was published (and in fact
1.1.0 was released in the same month as the publication of that RFC). I notice
that the underlying RFC7919 params have been integrated into the latest versions
of OpenSSL but only in libcrypto - not in libssl. I'd certainly have no
objection to updating SSL_CTX_set_dh_auto() to use more modern parameters in
OpenSSL 3.0 (PRs welcome) - although I don't think we could justify backporting
such a change to a stable branch (1.1.1).

Matt

Re: Building OpenSSL 1.1.1b for WinCE700

[Matt Caswell]

On 19/03/2019 07:08, 田中創樹 wrote:
> Hello,
> 
> I have successfully build OpenSSL 1.1.1b (only libraries, no app) for
> WINCE700-ARMV4I, though I don't do any tests. Here is what I did. I hope
> original sources will be changed so as there is no need to change.

It would be good if you created a github PR for this so the changes can be
considered for inclusion.

Matt


> 
> 1. Modify wcecompat.
> 
> Add an alias, "_access" for access() in wcecompat io.h as below.
> --
> #define access _wceaccess
> #define _access _wceaccess
> --
> 
> 2. Set Environmental variables
> 
> set OSVERSION=WCE700
> set PLATFORM=VC-CE
> set TARGETCPU=ARMV4I
> set WCECOMPAT=C:\Users\dev\tanaka\wcecompat
> set LIB=C:\Program Files (x86)\Microsoft Visual Studio
> 9.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Windows CE
> Tools\SDKs\YOUR_SDK_NAME\Lib\ARMV4I;C:\Program Files\Microsoft
> SDKs\Windows\v6.0A\Lib;C:\Program Files (x86)\Microsoft Visual Studio
> 9.0\VC\ce\lib\ARMV4I;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib
> set INCLUDE=C:\Program Files (x86)\Windows CE
> Tools\SDKs\YOUR_SDK_NAME\Include\ARMV4I;C:\Program Files (x86)\Microsoft 
> Visual
> Studio 9.0\VC\atlmfc\include;C:\Program Files (x86)\Microsoft Visual Studio
> 9.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v6.0A\include;
> set Path=C:\WINCE700\sdk\bin\i386\arm;C:\Program Files (x86)\Microsoft Visual
> Studio 9.0\Common7\Tools;C:\Program Files (x86)\Microsoft Visual Studio
> 9.0\VC\VCPackages;C:\Program Files\Microsoft
> SDKs\Windows\v6.0A\bin;C:\cygwin64\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
> Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE;C:\Program Files
> (x86)\Microsoft Visual Studio 9.0\VC\BIN;%Path%
> set LIBPATH=C:\Program Files (x86)\Microsoft Visual Studio
> 9.0\VC\ATLMFC\LIB;"C:\Program Files (x86)\Windows CE
> Tools\SDKs\YOUR_SDK_NAME\Lib\ARMV4I";C:\Program Files (x86)\Microsoft Visual
> Studio 9.0\VC\lib;C:\Program Files (x86)\Microsoft Visual Studio
> 9.0\VC\ce\lib\ARMV4I;
> 
> 3. Configure
> 
> (for ARM)(Configurations/windows-makefile.tmpl) Delete a line of 
> "setargv.obj".
> setargv.obj in C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib is 
> for
> x86 and cannot be linked with ARM objs.
> 
> C:\Strawberry\perl\bin\perl Configure no-idea no-mdc2 no-rc5 no-asm no-ssl3
> no-stdio no-async no-engine VC-CE
> 
> Using full path to specify Strawberry perl. I recommend Strawberry perl here 
> to
> avoid error messages, I used 5.24.4.1-32bit.
> 
> I added 3 options of "no-stdio" and "no-engine", "no-async". Because..
>   * no-stdio: GetStdHandle() and STD_INPUT_HANDLE cannot be used in WinCE. 
> (used
> in apps\apps.c)
>   * no-engine: Lack of CreatePipe() in WinCE (used in engines\e_dasync.c)
>   * no-async: Lack of ConvertFiberToThread() in WinCE (used in
> crypto\async\arch\async_win.c)
> By "no-stdio" option, we build only libraries. No command line application are
> generated.
> 
> 4. Modify "makefile"
> 
>   * Add -D_MSC_VER=1300 in "CFLAGS="
>   * In "CNF_CPPFLAGS=", change -I"\$(WCECOMPAT)/include" to 
> -I$(WCECOMPAT)/include
>   * Change CNF_EX_LIBS=3 to CNF_EX_LIBS=ws2.lib crypt32.lib kernel32.lib
> $(WCECOMPAT)\lib\wcecompat.lib $(WCECOMPAT)\lib\wcecompatex.lib corelibc.lib
> coredll.lib
> 
> 5. Modify C Source
> 
> Comment out a line of "#  define stat    _stat" in
>   crypto\conf\conf_def.c
>   crypto\rand\randfile.c
>   crypto\store\loader_file.c
> Comment out a line of "#  define fstat   _fstat" in crypto\rand\randfile.c.
> 
> (crypt/init.c 167l and 777l) For lack of GetModuleHandleEx() in CE, Change "#
> ifdef DSO_WIN32" to "# if defined(DSO_WIN32) && !defined(_WIN32_WCE)"
> -
> # ifdef DSO_WIN32
>     {
>     HMODULE handle = NULL;
>     BOOL ret;
> 
>     /* We don't use the DSO route for WIN32 because there is a better way 
> */
>     ret = GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS
> -
> 
> (crypto\rand\randfile.c 257l) For lack of GetEnvironmentVariableW() in CE,
> Change "#if defined(_WIN32) && defined(CP_UTF8)" to "#if defined(_WIN32) &&
> defined(CP_UTF8) && !defined(_WIN32_WCE)"
> 
> (for ARM)(include\internal\refcount.h)
>   * Add "#include " for InterlockedExchangeAdd().
>   * (106l) In function CRYPTO_UP_REF() and CRYPTO_DOWN_REF(), change 2
> "_InterlockedExchangeAdd()" to be "InterlockedExchangeAdd()". There is no
> _InterlockedExchangeAdd() for non x86 in C:\Program Files (x86)\Windows CE
> Tools\SDKs\YOUR_SDK_NAME\Include\Armv4i\winbase.h.
> 
> (crypt/threads_win.c 27l) For lack of InitializeCriticalSectionAndSpinCount() 
> in
> CE, change
> --
>     /* 0x400 is the spin count value suggested in the documentation */
>     if (!InitializeCriticalSectionAndSpinCount(lock, 0x400)) {
>     OPENSSL_free(lock);
>     return NULL;
>     }
> --
> to
> --
> #ifndef _WIN32_WCE
>     /* 0x400 is the spin count value suggested in the documentation */
>   

RE: Differences in defaults between 1.0.2 and 1.1.1

[Perrow, Graeme]

Thanks Matt, the command you listed did succeed. I was hoping to be able to 
change our code so that we could connect to any server we were able to connect 
to before, but if this is truly a server-side bug, there's only so much we can 
do on the client side.

If our customers see this change in behaviour after we upgrade OpenSSL, my 
understanding is that they will simply have to fix their server.

Graeme

-Original Message-
From: openssl-users  On Behalf Of Matt 
Caswell
Sent: March 19, 2019 10:23 AM
To: openssl-users@openssl.org
Subject: Re: Differences in defaults between 1.0.2 and 1.1.1



On 19/03/2019 13:40, Perrow, Graeme wrote:
> TLS: error: accept - force handshake failure: errno 11 - moznss error -12162
> 
> TLS: can't accept: TLS error -12162:Unsupported hash algorithm used by TLS 
> peer..


Just to confirm - you've not configured client authentication?

Assuming not, the above error message from the server suggests that it doesn't
like one of the signature algorithms sent through from the client in the
ClientHello. At least I'm assuming that's the point at which it fails. You
omitted most of the -debug output so its a little unclear exactly how far
through the handshake it got before the failure occurred. If my assumption is
right then it looks like the server may be behaving incorrectly. It isn't
supposed to fail if it encounters a parameter it doesn't recognise - its just
supposed to ignore it.

To test the theory I suggest sending through the same list of signature
algorithms in the same order that 1.0.2 sends them. You can do that using the
"-sigalgs" parameter to s_client:

openssl s_client -showcerts -host : -debug -sigalgs
"RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1"

Matt

Re: Differences in defaults between 1.0.2 and 1.1.1

[Matt Caswell]

On 19/03/2019 15:15, Perrow, Graeme wrote:
> Thanks Matt, the command you listed did succeed. I was hoping to be able to
> change our code so that we could connect to any server we were able to
> connect to before, but if this is truly a server-side bug, there's only so
> much we can do on the client side.
> 
> If our customers see this change in behaviour after we upgrade OpenSSL, my
> understanding is that they will simply have to fix their server.

Fixing the server really is the right solution here. It is broken and clients
shouldn't be forced to work around such broken set ups.

If you absolutely *had* to do it, you can do the same workaround in C code that
s_client does with that "-sigalgs" parameter using the function
SSL_CTX_set1_sigalgs (or SSL_set1_sigalgs):

https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set1_sigalgs.html

But I'd strongly advise against it since using such a sigalgs list will impact
your ability to interoperate with TLSv1.3 servers.

Matt


> 
> Graeme
> 
> -Original Message- From: openssl-users
>  On Behalf Of Matt Caswell Sent: March 19,
> 2019 10:23 AM To: openssl-users@openssl.org Subject: Re: Differences in
> defaults between 1.0.2 and 1.1.1
> 
> 
> 
> On 19/03/2019 13:40, Perrow, Graeme wrote:
>> TLS: error: accept - force handshake failure: errno 11 - moznss error
>> -12162
>> 
>> TLS: can't accept: TLS error -12162:Unsupported hash algorithm used by TLS
>> peer..
> 
> 
> Just to confirm - you've not configured client authentication?
> 
> Assuming not, the above error message from the server suggests that it
> doesn't like one of the signature algorithms sent through from the client in
> the ClientHello. At least I'm assuming that's the point at which it fails.
> You omitted most of the -debug output so its a little unclear exactly how
> far through the handshake it got before the failure occurred. If my
> assumption is right then it looks like the server may be behaving
> incorrectly. It isn't supposed to fail if it encounters a parameter it
> doesn't recognise - its just supposed to ignore it.
> 
> To test the theory I suggest sending through the same list of signature 
> algorithms in the same order that 1.0.2 sends them. You can do that using
> the "-sigalgs" parameter to s_client:
> 
> openssl s_client -showcerts -host : -debug -sigalgs 
> "RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1"
>
>  Matt
> 

Re: Differences in defaults between 1.0.2 and 1.1.1

[Hubert Kario]

On Tuesday, 19 March 2019 14:40:19 CET Perrow, Graeme wrote:
> I have an LDAP server that accepts TLS connections, and I can make a
> connection to it using "openssl s_client -showcerts -host :
> -debug". The output shows this is a TLSv1.2 connection using
> ECDHE-RSA-AES128-SHA. This is using OpenSSL version 1.0.2j.
> 
> If I run exactly the same command using the openssl executable built with
> 1.1.1, I get errors:
> 
> CONNECTED(0184)
> write to 0x2917b30 [0x2928090] (326 bytes => 326 (0x146))
>  - 16 03 01 01 41 01 00 01-3d 03 03 5a e6 ad 03 79   A...=..Z...y
> ...
> 0140 - cb bb 7f 9c 78 24 x$
> read from 0x2917b30 [0x291edf3] (5 bytes => 0 (0x0))
> write:errno=0
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 326 bytes
> Verification: OK
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> Early data was not sent
> Verify return code: 0 (ok)
> ---
> read from 0x2917b30 [0x290e960] (8192 bytes => 0 (0x0))
> 
> The connection is closed by the server, which is reporting an error:
> 
> TLS: error: accept - force handshake failure: errno 11 - moznss error -12162
> TLS: can't accept: TLS error -12162:Unsupported hash algorithm used by TLS
> peer..
> 
> If I add the -no_tls1_2 switch, the openssl 1.1.1 command succeeds. Since
> the server didn't change and the client command line didn't change, it
> would seem that some default behaviour has changed within OpenSSL for
> 1.1.1. I know that some ciphersuites were removed or disabled but the one
> used by OpenSSL 1.0.2j (ECDHE-RSA-AES128-SHA) does not seem to be one of
> them (it's listed in "openssl ciphers"). Does anyone know what might be
> happening here? Thanks

the error would indicate that the server is using Mozilla NSS library for the 
TLS implementation.

I recall that some very old NSS versions were intolerant to undefined 
signature algorithms[1,2]. Which NSS version is the server using?

And OpenSSL needs to add rsa_pss_* signature algorithms to the ClientHello - 
those are the only ones allowed for RSA keys in TLS 1.3 - the bug is in the 
server.

 1 - https://bugzilla.mozilla.org/show_bug.cgi?id=1119983
 2 - https://bugzilla.mozilla.org/show_bug.cgi?id=1317857
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.

Differences in defaults between 1.0.2 and 1.1.1

[Perrow, Graeme]

I have an LDAP server that accepts TLS connections, and I can make a connection 
to it using "openssl s_client -showcerts -host : -debug". The 
output shows this is a TLSv1.2 connection using ECDHE-RSA-AES128-SHA. This is 
using OpenSSL version 1.0.2j.

If I run exactly the same command using the openssl executable built with 
1.1.1, I get errors:

CONNECTED(0184)
write to 0x2917b30 [0x2928090] (326 bytes => 326 (0x146))
 - 16 03 01 01 41 01 00 01-3d 03 03 5a e6 ad 03 79   A...=..Z...y
...
0140 - cb bb 7f 9c 78 24 x$
read from 0x2917b30 [0x291edf3] (5 bytes => 0 (0x0))
write:errno=0
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 326 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
read from 0x2917b30 [0x290e960] (8192 bytes => 0 (0x0))

The connection is closed by the server, which is reporting an error:

TLS: error: accept - force handshake failure: errno 11 - moznss error -12162
TLS: can't accept: TLS error -12162:Unsupported hash algorithm used by TLS 
peer..

If I add the -no_tls1_2 switch, the openssl 1.1.1 command succeeds. Since the 
server didn't change and the client command line didn't change, it would seem 
that some default behaviour has changed within OpenSSL for 1.1.1. I know that 
some ciphersuites were removed or disabled but the one used by OpenSSL 1.0.2j 
(ECDHE-RSA-AES128-SHA) does not seem to be one of them (it's listed in "openssl 
ciphers"). Does anyone know what might be happening here?
Thanks
Graeme Perrow

Re: Differences in defaults between 1.0.2 and 1.1.1

[Matt Caswell]

On 19/03/2019 13:40, Perrow, Graeme wrote:
> TLS: error: accept - force handshake failure: errno 11 - moznss error -12162
> 
> TLS: can't accept: TLS error -12162:Unsupported hash algorithm used by TLS 
> peer..


Just to confirm - you've not configured client authentication?

Assuming not, the above error message from the server suggests that it doesn't
like one of the signature algorithms sent through from the client in the
ClientHello. At least I'm assuming that's the point at which it fails. You
omitted most of the -debug output so its a little unclear exactly how far
through the handshake it got before the failure occurred. If my assumption is
right then it looks like the server may be behaving incorrectly. It isn't
supposed to fail if it encounters a parameter it doesn't recognise - its just
supposed to ignore it.

To test the theory I suggest sending through the same list of signature
algorithms in the same order that 1.0.2 sends them. You can do that using the
"-sigalgs" parameter to s_client:

openssl s_client -showcerts -host : -debug -sigalgs
"RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1"

Matt

Re: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287

[Viktor Dukhovni]

On Tue, Mar 19, 2019 at 02:04:14PM +0200, Graham Leggett wrote:

> > Why do you need to do the encode and decode?  What's wrong with the original
> > request object?
> 
> The code is a modular ca, and different modules communicate with each other
> generically using the standard DER encoded structures.

Well, the *standard* structure for passing around just the unsigned
data underlying a CSR (X509_REQ), is a CertificationRequestInfo
(X509_REQ_INFO).  So if the modules are to use *standard* structures
to communicate.  The object being passed needs to be either a CSR
(signed) or the enclosed CRI (unsigned).

You could, for example, sign the request with some suitable key
(ideally the private key corresponding to the public key in the
CSR, if available) before handing it off.  If the signing key is
not the enclosed public key, it would not pass "req -verify" (it
never did before either, for lack of a signature), but the called
module would be able to decode a CSR, and work as before.

> > > While I can see a d2i_X509_REQ_INFO() function, I can’t find a
> > > corresponding function in openssl 1.1.0+ that assigns this to a
> > > X509_REQ, unless I am missing it?
> > 
> > It should not be needed.
> 
> I don’t follow - in order to get access to the data inside the X509_REQ_INFO
> structure, I need to first wrap it in a X509_REQ, otherwise I have no API
> calls to get access to the data inside it.

No need to get access to the data inside an X509_REQ_INFO is expected.
That object's sole purpose is to be serializable for signing.

You have rather an edge-case, where for some reason you're delegating
signing to a CA module by passing it a non-standard structure that
*resembles* a CSR, which is however for some reason not signed with
the subject key (not signed at all), and you expect the CA to apply
policy, by decoding the CRI inside  this non-CSR.

OpenSSL 1.1.x does not have structure member accessors for a CRI,
but they would be easy to add, that's essentially what the X509_REQ
accessors do:

long X509_REQ_get_version(const X509_REQ *req)
{
return ASN1_INTEGER_get(req->req_info.version);
}

X509_NAME *X509_REQ_get_subject_name(const X509_REQ *req)
{
return req->req_info.subject;
}

int X509_REQ_get_attr_count(const X509_REQ *req)
{
return X509at_get_attr_count(req->req_info.attributes);
}

int X509_REQ_get_attr_by_NID(const X509_REQ *req, int nid, int lastpos)
{
return X509at_get_attr_by_NID(req->req_info.attributes, nid, lastpos);
}

int X509_REQ_get_attr_by_OBJ(const X509_REQ *req, const ASN1_OBJECT *obj,
 int lastpos)
{
return X509at_get_attr_by_OBJ(req->req_info.attributes, obj, lastpos);
}

X509_ATTRIBUTE *X509_REQ_get_attr(const X509_REQ *req, int loc)
{
return X509at_get_attr(req->req_info.attributes, loc);
}

X509_ATTRIBUTE *X509_REQ_delete_attr(X509_REQ *req, int loc)
{
return X509at_delete_attr(req->req_info.attributes, loc);
}

If one were to "void the warranty", one could cast the (X509_REQ_INFO
*) as an (X509_REQ *), and the accessors would just work, but you
must not do that, the internal details might change some day, as
they did between 1.1.x and 1.0.2 (where the X509_REQ_INFO is a
separately allocated structure pointed to by the X509_REQ).

> > Can you be more specific about these "module boundaries”?
> 
> The modules are Apache httpd modules, and the boundaries between the modules
> are hooks that pass DER encoded structures between each module.

Well, so the key question is, why not pass an actual CSR.  What's
preventing the CSR from being signed?

> > This isn't pretty, and perhaps we need some new functions to explicitly
> > embed a CRI in a CSR, but it is certainly something you can do in the
> > short term.
> 
> Can we not rather fix the initialisation of the X509_REQ in X509_REQ_new()
> so that it works like it used to? It seems like a massive headache to do
> something that used to be trivial.

No, because it is not broken.  The "massive headache" is peculiar to
the rather odd choice of "RPC" between these Apache modules, where
a non-CSR is masquerading as a CSR.

> I see there have been changes to openssl code relating to how structures
> are initialised, I suspect an error has crept in where an ASN.1 object is
> missing instead of empty, thus the malformed CSR.

There is no error.  The X509_REQ_INFO and X509_ALGOR (signature
algorithm) are now embedded in the CSR, and are no longer optional.

Your immediate choices are to sign a CSR, or to embed your CRI in
an outer DER wrapper that simulates a CSR.  Signing with some
key (ideally the subject key) seems simplest.

Even if we provide the "missing" CRI accessors in OpenSSL 1.1.1c,
I don't think that would practically solve your problem, because
some users would have 1.1.0, 1.1.1, 1.1.1a or 1.1.1b.

The DER wrapper is also simple (commented hex):

$ openssl req 

Howto prevent cycles in engine invocation ?

[Fuchs, Andreas]

Following scenario:

I have an engine that implements e.g. RSA decryption.
That engine links against a library that links against libcrypto to perform RSA 
decryption.

Now if I have an application that sets the default library to be my engine, 
won't I end up in an infinite loop ?

Or the other way around:
- Is there a way to change the default engine from within my engine before 
calling out to the library ?
- Can the library itself select "software-only" as an engine ?

I guess I don't have a concrete problem in my specific case, since I have 
app_data attached to any key and
if my engine receives a key without app_data, it will just call SSLeay() 
functions.

But what if that was not the case ?

Thanks a lot for any help,
Andreas