From levitte at openssl.org  Fri Mar  1 08:45:05 2019
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 01 Mar 2019 09:45:05 +0100
Subject: Online docs have broken links
In-Reply-To: <cc2b9c2a0e36245104f8dc5e2e4c920a9a7d5803.camel@mad-scientist.net>
References: <cc2b9c2a0e36245104f8dc5e2e4c920a9a7d5803.camel@mad-scientist.net>
Message-ID: <87zhqfvv8u.wl-levitte@openssl.org>

Good catch!  That does answer a mystery with the current HTML
producing script...

Thanks.

Cheers,
Richard

On Thu, 28 Feb 2019 20:48:02 +0100,
Paul Smith wrote:
> 
> Not sure if anyone is aware or not, but many of the man pages on the
> openssl.org site contain broken links.  Basically anywhere a man page
> refers to a man page in a different section, the link is broken because
> it uses the same section.
> 
> So for example:
> 
>   https://www.openssl.org/docs/man1.1.1/man7/ssl.html
> 
> is in section 7, but it refers to functions in section 3... however all
> the links are broken because they still point to section 7.  See the
> link in the second paragraph of the description to SSL_CTX_NEW, which
> has this HTML linkage:
> 
>   <a href="/docs/man1.1.1/man7/SSL_CTX_new.html">SSL_CTX_new</a>
> 
> which does not exist; this should be .../man3/SSL_CTX_new.html instead.
> 
> I've found other links in the man3 section which want to refer to this
> "ssl" page, and look for it in section 3 instead of section 7, also
> broken.
> 
> Cheers!
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From sravani.maddukuri at broadcom.com  Fri Mar  1 11:34:19 2019
From: sravani.maddukuri at broadcom.com (Sravani Maddukuri)
Date: Fri, 1 Mar 2019 17:04:19 +0530
Subject: Compilation errors with 1.1.1b
Message-ID: <CADhPa=wv=3S5ZCNJkGtJ4B8Y1PKyECE=2sLZ93+tcMsTYvkd1Q@mail.gmail.com>

Hi,

Earlier our application used OpenSSL version 1.0.2n. Now we wanted to
upgrade to 1.1.1b.
After upgrade when i compile OpenSSL, i see the following errors:

Tried to generate the Makefile with both the ways mentioned below..

But getting compilation errors as attached mainly at places
where DEPRECATEDIN_1_1_0 and DEPRECATEDIN_0_9_8 are used.


./config >> ../build.log \

            no-idea no-md2 no-md4 no-mdc2 no-rc2 no-rc5 \

            -DOPENSSL_SYSNAME_LINUX -DOPENSSL_USE_IPV6
-DOPENSSL_IMPLEMENTS_strncasecmp \

    -DOPENSSL_API_COMPAT=0x1010102fL \

            -ffunction-sections -fdata-sections \

            no-hw shared no-asm


./config >> ../build.log \

            no-idea no-md2 no-md4 no-mdc2 no-rc2 no-rc5 \

            -DOPENSSL_SYSNAME_LINUX -DOPENSSL_USE_IPV6
-DOPENSSL_IMPLEMENTS_strncasecmp \

    disable-deprecated \

            -ffunction-sections -fdata-sections \

            no-hw shared no-asm

Can you please suggest the possible solution to fix the errors?

Regards,
Sravani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190301/722cd1b5/attachment-0001.html>
-------------- next part --------------
COMPILING....[openssl]   :  vendor/openssl/crypto/cpt_err.c
In file included from ../../../../vendor/openssl/include/openssl/err.h:21:0,
                 from ../../../../vendor/openssl/crypto/cpt_err.c:11:
../../../../vendor/openssl/include/openssl/bio.h:689:27: error: 'struct hostent' declared inside parameter list [-Werror]
 DEPRECATEDIN_1_1_0(struct hostent *BIO_gethostbyname(const char *name))
                           ^
../../../../vendor/openssl/include/openssl/bio.h:689:27: error: its scope is only this definition or declaration, which is probably not what you want [-Werror]
../../../../vendor/openssl/include/openssl/bio.h:689:1: error: return type defaults to 'int' [-Werror=implicit-int]
 DEPRECATEDIN_1_1_0(struct hostent *BIO_gethostbyname(const char *name))
 ^
../../../../vendor/openssl/include/openssl/bio.h: In function 'DEPRECATEDIN_1_1_0':
../../../../vendor/openssl/include/openssl/bio.h:690:1: error: expected declaration specifiers before 'DEPRECATEDIN_1_1_0'
 DEPRECATEDIN_1_1_0(int BIO_get_port(const char *str, unsigned short *port_ptr))
 ^
../../../../vendor/openssl/include/openssl/bio.h:697:2: error: expected declaration specifiers before ';' token
 };
  ^
../../../../vendor/openssl/include/openssl/bio.h:698:1: error: empty declaration [-Werror]
 enum BIO_sock_info_type {
 ^
../../../../vendor/openssl/include/openssl/bio.h:702:55: error: 'union BIO_sock_info_u' declared inside parameter list [-Werror]
                   enum BIO_sock_info_type type, union BIO_sock_info_u *info);
                                                       ^
In file included from ../../../../vendor/openssl/include/openssl/err.h:22:0,
                 from ../../../../vendor/openssl/crypto/cpt_err.c:11:
../../../../vendor/openssl/include/openssl/lhash.h:24:30: error: storage class specified for parameter 'OPENSSL_LH_NODE'
 typedef struct lhash_node_st OPENSSL_LH_NODE;
                              ^
../../../../vendor/openssl/include/openssl/lhash.h:25:15: error: storage class specified for parameter 'OPENSSL_LH_COMPFUNC'
 typedef int (*OPENSSL_LH_COMPFUNC) (const void *, const void *);
               ^
../../../../vendor/openssl/include/openssl/lhash.h:26:25: error: storage class specified for parameter 'OPENSSL_LH_HASHFUNC'
 typedef unsigned long (*OPENSSL_LH_HASHFUNC) (const void *);
                         ^
../../../../vendor/openssl/include/openssl/lhash.h:27:16: error: storage class specified for parameter 'OPENSSL_LH_DOALL_FUNC'
 typedef void (*OPENSSL_LH_DOALL_FUNC) (void *);
                ^
../../../../vendor/openssl/include/openssl/lhash.h:28:16: error: storage class specified for parameter 'OPENSSL_LH_DOALL_FUNCARG'
 typedef void (*OPENSSL_LH_DOALL_FUNCARG) (void *, void *);
                ^
../../../../vendor/openssl/include/openssl/lhash.h:29:25: error: storage class specified for parameter 'OPENSSL_LHASH'
 typedef struct lhash_st OPENSSL_LHASH;
                         ^
../../../../vendor/openssl/include/openssl/lhash.h:72:22: error: expected declaration specifiers or '...' before 'OPENSSL_LHASH'
 int OPENSSL_LH_error(OPENSSL_LHASH *lh);
                      ^
../../../../vendor/openssl/include/openssl/lhash.h:73:1: error: expected declaration specifiers before 'OPENSSL_LHASH'
 OPENSSL_LHASH *OPENSSL_LH_new(OPENSSL_LH_HASHFUNC h, OPENSSL_LH_COMPFUNC c);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:74:22: error: expected declaration specifiers or '...' before 'OPENSSL_LHASH'
 void OPENSSL_LH_free(OPENSSL_LHASH *lh);
                      ^
../../../../vendor/openssl/include/openssl/lhash.h:75:25: error: expected declaration specifiers or '...' before 'OPENSSL_LHASH'
 void *OPENSSL_LH_insert(OPENSSL_LHASH *lh, void *data);
                         ^
../../../../vendor/openssl/include/openssl/lhash.h:76:25: error: expected declaration specifiers or '...' before 'OPENSSL_LHASH'
 void *OPENSSL_LH_delete(OPENSSL_LHASH *lh, const void *data);
                         ^
../../../../vendor/openssl/include/openssl/lhash.h:77:27: error: expected declaration specifiers or '...' before 'OPENSSL_LHASH'
 void *OPENSSL_LH_retrieve(OPENSSL_LHASH *lh, const void *data);
                           ^
../../../../vendor/openssl/include/openssl/lhash.h:78:23: error: expected declaration specifiers or '...' before 'OPENSSL_LHASH'
 void OPENSSL_LH_doall(OPENSSL_LHASH *lh, OPENSSL_LH_DOALL_FUNC func);
                       ^
../../../../vendor/openssl/include/openssl/lhash.h:78:42: error: expected declaration specifiers or '...' before 'OPENSSL_LH_DOALL_FUNC'
 void OPENSSL_LH_doall(OPENSSL_LHASH *lh, OPENSSL_LH_DOALL_FUNC func);
                                          ^
../../../../vendor/openssl/include/openssl/lhash.h:79:27: error: expected declaration specifiers or '...' before 'OPENSSL_LHASH'
 void OPENSSL_LH_doall_arg(OPENSSL_LHASH *lh, OPENSSL_LH_DOALL_FUNCARG func, void *arg);
                           ^
../../../../vendor/openssl/include/openssl/lhash.h:79:46: error: expected declaration specifiers or '...' before 'OPENSSL_LH_DOALL_FUNCARG'
 void OPENSSL_LH_doall_arg(OPENSSL_LHASH *lh, OPENSSL_LH_DOALL_FUNCARG func, void *arg);
                                              ^
../../../../vendor/openssl/include/openssl/lhash.h:81:42: error: type defaults to 'int' in declaration of 'OPENSSL_LHASH' [-Werror=implicit-int]
 unsigned long OPENSSL_LH_num_items(const OPENSSL_LHASH *lh);
                                          ^
../../../../vendor/openssl/include/openssl/lhash.h:81:56: error: expected ';', ',' or ')' before '*' token
 unsigned long OPENSSL_LH_num_items(const OPENSSL_LHASH *lh);
                                                        ^
../../../../vendor/openssl/include/openssl/lhash.h:82:46: error: type defaults to 'int' in declaration of 'OPENSSL_LHASH' [-Werror=implicit-int]
 unsigned long OPENSSL_LH_get_down_load(const OPENSSL_LHASH *lh);
                                              ^
../../../../vendor/openssl/include/openssl/lhash.h:82:60: error: expected ';', ',' or ')' before '*' token
 unsigned long OPENSSL_LH_get_down_load(const OPENSSL_LHASH *lh);
                                                            ^
../../../../vendor/openssl/include/openssl/lhash.h:83:31: error: expected declaration specifiers or '...' before 'OPENSSL_LHASH'
 void OPENSSL_LH_set_down_load(OPENSSL_LHASH *lh, unsigned long down_load);
                               ^
../../../../vendor/openssl/include/openssl/lhash.h:86:29: error: type defaults to 'int' in declaration of 'OPENSSL_LHASH' [-Werror=implicit-int]
 void OPENSSL_LH_stats(const OPENSSL_LHASH *lh, FILE *fp);
                             ^
../../../../vendor/openssl/include/openssl/lhash.h:86:43: error: expected ';', ',' or ')' before '*' token
 void OPENSSL_LH_stats(const OPENSSL_LHASH *lh, FILE *fp);
                                           ^
../../../../vendor/openssl/include/openssl/lhash.h:87:34: error: type defaults to 'int' in declaration of 'OPENSSL_LHASH' [-Werror=implicit-int]
 void OPENSSL_LH_node_stats(const OPENSSL_LHASH *lh, FILE *fp);
                                  ^
../../../../vendor/openssl/include/openssl/lhash.h:87:48: error: expected ';', ',' or ')' before '*' token
 void OPENSSL_LH_node_stats(const OPENSSL_LHASH *lh, FILE *fp);
                                                ^
../../../../vendor/openssl/include/openssl/lhash.h:88:40: error: type defaults to 'int' in declaration of 'OPENSSL_LHASH' [-Werror=implicit-int]
 void OPENSSL_LH_node_usage_stats(const OPENSSL_LHASH *lh, FILE *fp);
                                        ^
../../../../vendor/openssl/include/openssl/lhash.h:88:54: error: expected ';', ',' or ')' before '*' token
 void OPENSSL_LH_node_usage_stats(const OPENSSL_LHASH *lh, FILE *fp);
                                                      ^
../../../../vendor/openssl/include/openssl/lhash.h:90:33: error: type defaults to 'int' in declaration of 'OPENSSL_LHASH' [-Werror=implicit-int]
 void OPENSSL_LH_stats_bio(const OPENSSL_LHASH *lh, BIO *out);
                                 ^
../../../../vendor/openssl/include/openssl/lhash.h:90:47: error: expected ';', ',' or ')' before '*' token
 void OPENSSL_LH_stats_bio(const OPENSSL_LHASH *lh, BIO *out);
                                               ^
../../../../vendor/openssl/include/openssl/lhash.h:91:38: error: type defaults to 'int' in declaration of 'OPENSSL_LHASH' [-Werror=implicit-int]
 void OPENSSL_LH_node_stats_bio(const OPENSSL_LHASH *lh, BIO *out);
                                      ^
../../../../vendor/openssl/include/openssl/lhash.h:91:52: error: expected ';', ',' or ')' before '*' token
 void OPENSSL_LH_node_stats_bio(const OPENSSL_LHASH *lh, BIO *out);
                                                    ^
../../../../vendor/openssl/include/openssl/lhash.h:92:44: error: type defaults to 'int' in declaration of 'OPENSSL_LHASH' [-Werror=implicit-int]
 void OPENSSL_LH_node_usage_stats_bio(const OPENSSL_LHASH *lh, BIO *out);
                                            ^
../../../../vendor/openssl/include/openssl/lhash.h:92:58: error: expected ';', ',' or ')' before '*' token
 void OPENSSL_LH_node_usage_stats_bio(const OPENSSL_LHASH *lh, BIO *out);
                                                          ^
../../../../vendor/openssl/include/openssl/lhash.h:119:25: error: empty declaration [-Werror]
 # define LHASH_OF(type) struct lhash_st_##type
                         ^
../../../../vendor/openssl/include/openssl/lhash.h:122:5: note: in expansion of macro 'LHASH_OF'
     LHASH_OF(type) { union lh_##type##_dummy { void* d1; unsigned long d2; int d3; } dummy; }; \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:197:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_STRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:126:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:197:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_STRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:131:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:197:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_STRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:135:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:197:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_STRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:139:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:197:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_STRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:143:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:197:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_STRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:147:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:197:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_STRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:151:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:197:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_STRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:155:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:197:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_STRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:159:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:197:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_STRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:163:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:197:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_STRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:167:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:197:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_STRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:171:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:197:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_STRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:176:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:197:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_STRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:119:25: error: empty declaration [-Werror]
 # define LHASH_OF(type) struct lhash_st_##type
                         ^
../../../../vendor/openssl/include/openssl/lhash.h:179:5: note: in expansion of macro 'LHASH_OF'
     LHASH_OF(type)
     ^
../../../../vendor/openssl/include/openssl/lhash.h:197:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_STRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:119:25: error: empty declaration [-Werror]
 # define LHASH_OF(type) struct lhash_st_##type
                         ^
../../../../vendor/openssl/include/openssl/lhash.h:122:5: note: in expansion of macro 'LHASH_OF'
     LHASH_OF(type) { union lh_##type##_dummy { void* d1; unsigned long d2; int d3; } dummy; }; \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:207:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_CSTRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:126:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:207:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_CSTRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:131:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:207:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_CSTRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:135:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:207:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_CSTRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:139:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:207:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_CSTRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:143:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:207:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_CSTRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:147:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:207:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_CSTRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:151:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:207:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_CSTRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:155:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:207:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_CSTRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:159:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:207:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_CSTRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:163:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:207:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_CSTRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:167:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:207:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_CSTRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:171:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:207:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_CSTRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:176:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/lhash.h:207:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_CSTRING);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:119:25: error: empty declaration [-Werror]
 # define LHASH_OF(type) struct lhash_st_##type
                         ^
../../../../vendor/openssl/include/openssl/lhash.h:179:5: note: in expansion of macro 'LHASH_OF'
     LHASH_OF(type)
     ^
../../../../vendor/openssl/include/openssl/lhash.h:207:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(OPENSSL_CSTRING);
 ^
In file included from ../../../../vendor/openssl/include/openssl/err.h:34:0,
                 from ../../../../vendor/openssl/crypto/cpt_err.c:11:
/projects/nwsoft-toolchains/xldk/iproc-a9-84783422/arm-buildroot-linux-gnueabi/sysroot/usr/include/errno.h:37:13: error: storage class specified for parameter '__errno_location'
 extern int *__errno_location (void) __THROW __attribute_const__;
             ^
/projects/nwsoft-toolchains/xldk/iproc-a9-84783422/arm-buildroot-linux-gnueabi/sysroot/usr/include/errno.h:45:14: error: storage class specified for parameter 'program_invocation_name'
 extern char *program_invocation_name;
              ^
/projects/nwsoft-toolchains/xldk/iproc-a9-84783422/arm-buildroot-linux-gnueabi/sysroot/usr/include/errno.h:46:14: error: storage class specified for parameter 'program_invocation_short_name'
 extern char *program_invocation_short_name;
              ^
/projects/nwsoft-toolchains/xldk/iproc-a9-84783422/arm-buildroot-linux-gnueabi/sysroot/usr/include/errno.h:52:13: error: storage class specified for parameter 'error_t'
 typedef int error_t;
             ^
In file included from ../../../../vendor/openssl/crypto/cpt_err.c:11:0:
../../../../vendor/openssl/include/openssl/err.h:50:3: error: storage class specified for parameter 'ERR_STATE'
 } ERR_STATE;
   ^
../../../../vendor/openssl/include/openssl/err.h:215:3: error: storage class specified for parameter 'ERR_STRING_DATA'
 } ERR_STRING_DATA;
   ^
In file included from ../../../../vendor/openssl/include/openssl/err.h:22:0,
                 from ../../../../vendor/openssl/crypto/cpt_err.c:11:
../../../../vendor/openssl/include/openssl/lhash.h:119:25: error: empty declaration [-Werror]
 # define LHASH_OF(type) struct lhash_st_##type
                         ^
../../../../vendor/openssl/include/openssl/lhash.h:122:5: note: in expansion of macro 'LHASH_OF'
     LHASH_OF(type) { union lh_##type##_dummy { void* d1; unsigned long d2; int d3; } dummy; }; \
     ^
../../../../vendor/openssl/include/openssl/err.h:217:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(ERR_STRING_DATA);
 ^
../../../../vendor/openssl/include/openssl/err.h:217:17: error: type defaults to 'int' in declaration of 'ERR_STRING_DATA' [-Werror=implicit-int]
 DEFINE_LHASH_OF(ERR_STRING_DATA);
                 ^
../../../../vendor/openssl/include/openssl/lhash.h:124:52: note: in definition of macro 'DEFINE_LHASH_OF'
         lh_##type##_new(unsigned long (*hfn)(const type *), \
                                                    ^
../../../../vendor/openssl/include/openssl/lhash.h:124:57: error: expected ';', ',' or ')' before '*' token
         lh_##type##_new(unsigned long (*hfn)(const type *), \
                                                         ^
../../../../vendor/openssl/include/openssl/err.h:217:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(ERR_STRING_DATA);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:125:25: error: expected ';', ',' or ')' before 'int'
                         int (*cfn)(const type *, const type *)) \
                         ^
../../../../vendor/openssl/include/openssl/err.h:217:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(ERR_STRING_DATA);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:131:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/err.h:217:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(ERR_STRING_DATA);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:134:41: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
     static ossl_unused ossl_inline type *lh_##type##_insert(LHASH_OF(type) *lh, type *d) \
                                         ^
../../../../vendor/openssl/include/openssl/err.h:217:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(ERR_STRING_DATA);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:138:41: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
     static ossl_unused ossl_inline type *lh_##type##_delete(LHASH_OF(type) *lh, const type *d) \
                                         ^
../../../../vendor/openssl/include/openssl/err.h:217:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(ERR_STRING_DATA);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:142:41: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
     static ossl_unused ossl_inline type *lh_##type##_retrieve(LHASH_OF(type) *lh, const type *d) \
                                         ^
../../../../vendor/openssl/include/openssl/err.h:217:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(ERR_STRING_DATA);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:147:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/err.h:217:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(ERR_STRING_DATA);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:151:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/err.h:217:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(ERR_STRING_DATA);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:155:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/err.h:217:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(ERR_STRING_DATA);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:159:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/err.h:217:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(ERR_STRING_DATA);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:163:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/err.h:217:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(ERR_STRING_DATA);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:167:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/err.h:217:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(ERR_STRING_DATA);
 ^
../../../../vendor/openssl/include/openssl/lhash.h:171:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     { \
     ^
../../../../vendor/openssl/include/openssl/err.h:217:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(ERR_STRING_DATA);
 ^
../../../../vendor/openssl/include/openssl/err.h:217:17: error: expected declaration specifiers or '...' before 'ERR_STRING_DATA'
 DEFINE_LHASH_OF(ERR_STRING_DATA);
                 ^
../../../../vendor/openssl/include/openssl/lhash.h:175:73: note: in definition of macro 'DEFINE_LHASH_OF'
                                                           void (*doall)(type *)) \
                                                                         ^
../../../../vendor/openssl/include/openssl/lhash.h:119:25: error: empty declaration [-Werror]
 # define LHASH_OF(type) struct lhash_st_##type
                         ^
../../../../vendor/openssl/include/openssl/lhash.h:179:5: note: in expansion of macro 'LHASH_OF'
     LHASH_OF(type)
     ^
../../../../vendor/openssl/include/openssl/err.h:217:1: note: in expansion of macro 'DEFINE_LHASH_OF'
 DEFINE_LHASH_OF(ERR_STRING_DATA);
 ^
In file included from ../../../../vendor/openssl/crypto/cpt_err.c:11:0:
../../../../vendor/openssl/include/openssl/err.h:248:31: error: expected declaration specifiers or '...' before 'ERR_STRING_DATA'
 int ERR_load_strings(int lib, ERR_STRING_DATA *str);
                               ^
../../../../vendor/openssl/include/openssl/err.h:249:34: error: type defaults to 'int' in declaration of 'ERR_STRING_DATA' [-Werror=implicit-int]
 int ERR_load_strings_const(const ERR_STRING_DATA *str);
                                  ^
../../../../vendor/openssl/include/openssl/err.h:249:50: error: expected ';', ',' or ')' before '*' token
 int ERR_load_strings_const(const ERR_STRING_DATA *str);
                                                  ^
../../../../vendor/openssl/include/openssl/err.h:250:33: error: expected declaration specifiers or '...' before 'ERR_STRING_DATA'
 int ERR_unload_strings(int lib, ERR_STRING_DATA *str);
                                 ^
../../../../vendor/openssl/include/openssl/err.h:259:1: error: expected declaration specifiers before 'DEPRECATEDIN_1_1_0'
 DEPRECATEDIN_1_1_0(void ERR_remove_thread_state(void *))
 ^
../../../../vendor/openssl/crypto/cpt_err.c:16:30: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'CRYPTO_str_functs'
 static const ERR_STRING_DATA CRYPTO_str_functs[] = {
                              ^
../../../../vendor/openssl/crypto/cpt_err.c:54:2: error: expected declaration specifiers before ';' token
 };
  ^
../../../../vendor/openssl/crypto/cpt_err.c:56:30: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'CRYPTO_str_reasons'
 static const ERR_STRING_DATA CRYPTO_str_reasons[] = {
                              ^
../../../../vendor/openssl/crypto/cpt_err.c:64:2: error: expected declaration specifiers before ';' token
 };
  ^
../../../../vendor/openssl/crypto/cpt_err.c:69:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 {
 ^
In file included from ../../../../vendor/openssl/include/openssl/err.h:21:0,
                 from ../../../../vendor/openssl/crypto/cpt_err.c:11:
../../../../vendor/openssl/include/openssl/bio.h:689:1: error: old-style parameter declarations in prototyped function definition
 DEPRECATEDIN_1_1_0(struct hostent *BIO_gethostbyname(const char *name))
 ^
../../../../vendor/openssl/crypto/cpt_err.c:77:1: error: expected '{' at end of input
 }
 ^
../../../../vendor/openssl/crypto/cpt_err.c:77:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors
make[2]: *** [vendor/_fp_vend_openssl_crypto/cpt_err.o] Error 1
make[1]: *** [openssl] Error 2
make: *** [openssl] Error 2


From christian at python.org  Fri Mar  1 11:41:40 2019
From: christian at python.org (Christian Heimes)
Date: Fri, 1 Mar 2019 12:41:40 +0100
Subject: Compilation errors with 1.1.1b
In-Reply-To: <CADhPa=wv=3S5ZCNJkGtJ4B8Y1PKyECE=2sLZ93+tcMsTYvkd1Q@mail.gmail.com>
References: <CADhPa=wv=3S5ZCNJkGtJ4B8Y1PKyECE=2sLZ93+tcMsTYvkd1Q@mail.gmail.com>
Message-ID: <e69fc24a-332a-4b23-f8b6-3cec3ec9ec50@python.org>

On 01/03/2019 12.34, Sravani Maddukuri via openssl-users wrote:
> Hi,
> 
> Earlier our application used OpenSSL version 1.0.2n. Now we wanted to
> upgrade to 1.1.1b.
> After upgrade when i compile OpenSSL, i see the following errors:
> 
> Tried to generate the Makefile with both the ways mentioned below..
> 
> But getting compilation errors as attached mainly at places
> where?DEPRECATEDIN_1_1_0 and?DEPRECATEDIN_0_9_8 are used.

Your system is missing 'struct hostent':

error: 'struct hostent' declared inside parameter list [-Werror]

The structure is provided by netdb.h. Does the error go away if you put
"#include <netdb.h>" before you include any OpenSSL headers?

Christian

From Chethan.Kumar at toshiba-tsip.com  Fri Mar  1 11:38:03 2019
From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar)
Date: Fri, 1 Mar 2019 11:38:03 +0000
Subject: openSSL 1.1.1b compatibility with GLIBC
Message-ID: <447C096A3E2889439233CDD6DAB29F959B08A54E@TOSBLRMBX03.TOSHIBA-TSIP.COM>

Dear all,

In need of some assistance. I compiled openssl1.1.1b on Debian and executed openssl commands on another Debian machine.
Its giving below error:
openssl: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /home/SYSROM_SRC/build/release/lib/libcrypto.so.1.1)

Even when I start HTTP services which uses openssl gives same error.
Starting webserverhttpd: Syntax error on line 208 of /config/httpd.conf: Cannot load lib/mod_ssl.so into server: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /usr/local/ebx/lib/libcrypto.so.1.1)

Environment used for the same is below:
Compilation Environment:
cat /proc/version
Linux version 3.16.0-6-amd64 (debian-kernel at lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) )

ldd --version
ldd (Debian GLIBC 2.19-18+deb8u10) 2.19

Executing Environment:
cat /proc/version
Linux version 4.4.130-cip23-eBN-kernel (jenkins at skelios-plt) (gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) )

ldd --version
ldd (GNU libc) 2.19

I need to know, how did the compilation was successful though GLIBC version was less and what should be done to make it work apart from updating GLIBC.

Thanking you,
Chethan Kumar

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190301/39c438fd/attachment.html>

From jb-openssl at wisemo.com  Fri Mar  1 13:24:08 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 1 Mar 2019 14:24:08 +0100
Subject: openSSL 1.1.1b compatibility with GLIBC
In-Reply-To: <447C096A3E2889439233CDD6DAB29F959B08A54E@TOSBLRMBX03.TOSHIBA-TSIP.COM>
References: <447C096A3E2889439233CDD6DAB29F959B08A54E@TOSBLRMBX03.TOSHIBA-TSIP.COM>
Message-ID: <b4ad89a8-dfdc-3bc9-1eae-d775c3cdb585@wisemo.com>

On 01/03/2019 12:38, Chethan Kumar wrote:
>
> Dear all,
>
> In need of some assistance. I compiled openssl1.1.1b on Debian and 
> executed openssl commands on another Debian machine.
>
> Its giving below error:
>
> openssl: */lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' not 
> found (required by /home/SYSROM_SRC/build/release/lib/libcrypto.so.1.1)*
>
Debian glibc versions with a given so-name (such as
libc.so.6) are backwards compatible, but not forward
compatible.

Thus compiling against glibc from an older version of Debian 8
(jessie) such as Debian glibc 2.19-18 should work with glibc
from a later version (such as "Debian GLIBC 2.19-18+deb8u10").
 ?But the other way around is not guaranteed to work, nor is
running with a non-Debian glibc when compiled against a Debian
glibc.

Your executing environment seems to contain a glibc which is
a plain version 2.19 with none of the Debian fixes added
between May 2014 and 16 Jun 2017 (see the file
/usr/share/doc/libc6/changelog.Debian.gz).

The package versions that need to match (or be in the correct
order) are package libc6-dev (when compiling) being same or
older than libc6 when running.

The command "dpkg --compare-versions" compares package
version numbers according to the correct rules.

When using the Debian packaging tools to package a compiled
file such as libcrypto.so.1.1, the resulting .deb file will
typically instruct the system to not install it unless a new
enough glibc is installed in the executing environment.

> Even when I start HTTP services which uses openssl gives same error.
>
> Starting webserverhttpd: Syntax error on line 208 of 
> /config/httpd.conf: Cannot load lib/mod_ssl.so into server: 
> */lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' not found 
> (required by /usr/local/ebx/lib/libcrypto.so.1.1)*
>
> Environment used for the same is below:
>
> *Compilation Environment:*
>
> cat /proc/version
>
> Linux version 3.16.0-6-amd64 (debian-kernel at lists.debian.org) (gcc 
> version 4.9.2 (Debian 4.9.2-10+deb8u1) )
>
> ldd --version
>
> ldd (Debian GLIBC 2.19-18+deb8u10) 2.19
>
> **
>
> *Executing Environment:*
>
> cat /proc/version
>
> Linux version 4.4.130-cip23-eBN-kernel (jenkins at skelios-plt) (gcc 
> version 4.9.2 (Debian 4.9.2-10+deb8u1) )
>
> ldd --version
>
> ldd (GNU libc) 2.19
>
> I need to know, how did the compilation was successful though GLIBC 
> version was less and what should be done to make it work apart from 
> updating GLIBC.
>
>

Enjoy

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


From norm.green at gemtalksystems.com  Fri Mar  1 19:16:52 2019
From: norm.green at gemtalksystems.com (Norm Green)
Date: Fri, 1 Mar 2019 11:16:52 -0800
Subject: 1.1.1b crash (RUN_ONCE problem?)
Message-ID: <e2114516-464d-6360-cc75-abf659b88700@gemtalksystems.com>

I'm debugging a failure in a debug build on Solaris SPARC in the below 
code in rand_lib.c.? On line 744, rand_meth_lock is NULL, which suggests 
the RUN_ONCE code is not working.? Wondering if anyone else has seen 
this problem?
We did not see this issue in 1.1.1a.? Perhaps changes in the RUN_ONCE 
code in this commit are responsible? 
https://github.com/openssl/openssl/commit/f725fe5b4b6504df08e30f5194d321c3025e2336



737 const RAND_METHOD *RAND_get_rand_method(void)
738 {
739???? const RAND_METHOD *tmp_meth = NULL;
740
741???? if (!RUN_ONCE(&rand_init, do_rand_init))
742???????? return NULL;
743
744???? CRYPTO_THREAD_write_lock(rand_meth_lock);
745???? if (default_RAND_meth == NULL) {
746 #ifndef OPENSSL_NO_ENGINE
747???????? ENGINE *e;
748
749???????? /* If we have an engine that can do RAND, use it. */
750???????? if ((e = ENGINE_get_default_RAND()) != NULL
751???????????????? && (tmp_meth = ENGINE_get_RAND(e)) != NULL) {
752???????????? funct_ref = e;
753???????????? default_RAND_meth = tmp_meth;
754???????? } else {
755???????????? ENGINE_finish(e);
756???????????? default_RAND_meth = &rand_meth;
757???????? }
758 #else
759???????? default_RAND_meth = &rand_meth;
760 #endif
761???? }
762???? tmp_meth = default_RAND_meth;
763???? CRYPTO_THREAD_unlock(rand_meth_lock);
764???? return tmp_meth;
765 }


From openssl-users at dukhovni.org  Fri Mar  1 19:54:29 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 1 Mar 2019 14:54:29 -0500
Subject: 1.1.1b crash (RUN_ONCE problem?)
In-Reply-To: <e2114516-464d-6360-cc75-abf659b88700@gemtalksystems.com>
References: <e2114516-464d-6360-cc75-abf659b88700@gemtalksystems.com>
Message-ID: <20190301195429.GI916@straasha.imrryr.org>

On Fri, Mar 01, 2019 at 11:16:52AM -0800, Norm Green wrote:

[ Please avoid non-breaking spaces in your posts. ]

> I'm debugging a failure in a debug build on Solaris SPARC in the below 
> code in rand_lib.c. On line 744, rand_meth_lock is NULL, which suggests 
> the RUN_ONCE code is not working.  Wondering if anyone else has seen 
> this problem?
> We did not see this issue in 1.1.1a.  Perhaps changes in the RUN_ONCE 
> code in this commit are responsible? 
> https://github.com/openssl/openssl/commit/f725fe5b4b6504df08e30f5194d321c3025e2336

That PR looks correct, and has no effect on the behaviour of RUN_ONCE
below.  It only introduces RUN_ONCE_ALT() and uses it in a few
special cases.

> 741     if (!RUN_ONCE(&rand_init, do_rand_init))
> 742         return NULL;
> 743
> 744     CRYPTO_THREAD_write_lock(rand_meth_lock);

Are you sure you're compiling linking and running with the desired
set of headers and libraries?

-- 
	Viktor.

From vieuxtech at gmail.com  Fri Mar  1 20:15:48 2019
From: vieuxtech at gmail.com (Sam Roberts)
Date: Fri, 1 Mar 2019 12:15:48 -0800
Subject: Online docs have broken links
In-Reply-To: <87zhqfvv8u.wl-levitte@openssl.org>
References: <cc2b9c2a0e36245104f8dc5e2e4c920a9a7d5803.camel@mad-scientist.net>
 <87zhqfvv8u.wl-levitte@openssl.org>
Message-ID: <CA+Sj9T=BvvRKfqtzdJem_H_prpqrAEwVSV3OpomKyDAEPMngDQ@mail.gmail.com>

I ran linklint on the output of `make install_html_docs`, and there
are a fair amount of refs to non-existent pages as well. Maybe its
worth adding a `test-docs` target?

Would PRs to fix the below be welcomed?

#------------------------------------------------------------
# ERROR  18 missing html files (cross referenced)
#------------------------------------------------------------
/../man1/version.html
    used in 1 file:
    /man3/CTLOG_STORE_new.html

/../man3/EVP_EncryptInit.html
    used in 1 file:
    /man3/EVP_CIPHER_meth_new.html

/../man3/OSSL_STORE_SEARCH.html
    used in 3 files:
    /man3/OSSL_STORE_expect.html
    /man3/OSSL_STORE_find.html
    /man3/OSSL_STORE_supports_search.html

/../man3/SSL_CTX_set_security_level.html
    used in 2 files:
    /man1/ciphers.html
    /man1/openssl-ciphers.html

/../man7/bio.html
    used in 4 files:
    /man3/BIO_pop.html
    /man3/BIO_push.html
    /man3/BIO_should_retry.html
    /man3/SCT_print.html

/man1/curl.html
    used in 2 files:
    /man1/openssl-tsget.html
    /man1/tsget.html

/man1/perl.html
    used in 2 files:
    /man1/openssl-ts.html
    /man1/ts.html

/man1/procmail.html
    used in 2 files:
    /man1/openssl-ts.html
    /man1/ts.html

/man3/EVP_MD_CTX_set_ctx.html
    used in 2 files:
    /man3/EVP_DigestSignInit.html
    /man3/EVP_DigestVerifyInit.html

/man3/EVP_bf.html
    used in 5 files:
    /man3/EVP_CIPHER_CTX_reset.html
    /man3/EVP_DecryptInit.html
    /man3/EVP_DecryptInit_ex.html
    /man3/EVP_EncryptInit.html
    /man3/EVP_EncryptInit_ex.html

/man3/EVP_cast5.html
    used in 5 files:
    /man3/EVP_CIPHER_CTX_reset.html
    /man3/EVP_DecryptInit.html
    /man3/EVP_DecryptInit_ex.html
    /man3/EVP_EncryptInit.html
    /man3/EVP_EncryptInit_ex.html

/man3/EVP_desx.html
    used in 5 files:
    /man3/EVP_CIPHER_CTX_reset.html
    /man3/EVP_DecryptInit.html
    /man3/EVP_DecryptInit_ex.html
    /man3/EVP_EncryptInit.html
    /man3/EVP_EncryptInit_ex.html

/man3/EVP_idea.html
    used in 5 files:
    /man3/EVP_CIPHER_CTX_reset.html
    /man3/EVP_DecryptInit.html
    /man3/EVP_DecryptInit_ex.html
    /man3/EVP_EncryptInit.html
    /man3/EVP_EncryptInit_ex.html

/man3/EVP_rc2.html
    used in 5 files:
    /man3/EVP_CIPHER_CTX_reset.html
    /man3/EVP_DecryptInit.html
    /man3/EVP_DecryptInit_ex.html
    /man3/EVP_EncryptInit.html
    /man3/EVP_EncryptInit_ex.html

/man3/EVP_rc5.html
    used in 5 files:
    /man3/EVP_CIPHER_CTX_reset.html
    /man3/EVP_DecryptInit.html
    /man3/EVP_DecryptInit_ex.html
    /man3/EVP_EncryptInit.html
    /man3/EVP_EncryptInit_ex.html

/man3/EVP_seed.html
    used in 5 files:
    /man3/EVP_CIPHER_CTX_reset.html
    /man3/EVP_DecryptInit.html
    /man3/EVP_DecryptInit_ex.html
    /man3/EVP_EncryptInit.html
    /man3/EVP_EncryptInit_ex.html

/man3/EVP_sm4.html
    used in 5 files:
    /man3/EVP_CIPHER_CTX_reset.html
    /man3/EVP_DecryptInit.html
    /man3/EVP_DecryptInit_ex.html
    /man3/EVP_EncryptInit.html
    /man3/EVP_EncryptInit_ex.html

/man3/X509_check_purpose.html
    used in 1 file:
    /man3/X509_get_extension_flags.html

From dkg at fifthhorseman.net  Fri Mar  1 20:47:05 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 01 Mar 2019 15:47:05 -0500
Subject: OpenSSL 3.0 vs. SSL 3.0
In-Reply-To: <cb2445e3-1609-70a3-ce47-5f815caab09c@python.org>
References: <cb2445e3-1609-70a3-ce47-5f815caab09c@python.org>
Message-ID: <87va12tj92.fsf@fifthhorseman.net>

On Wed 2019-02-27 16:02:32 +0100, Christian Heimes wrote:
> In my humble opinion, it's problematic and confusing to use "OpenSSL
> 3.0" for the next major version of OpenSSL and first release of
> OpenSSL with SSL 3.0 support.

Sigh.  You're right, but i wish you weren't. :)

Part of the problem of course is the "SSL" in "OpenSSL" itself, which
has held back the industry from adopting the more accurate "TLS" label.
But i understand the value of the brand, and why that won't be changed
either.

fwiw, i support the suggestion to skip 3.0, and call it OpenSSL 4.0
directly.  Reducing confusion matters.

           --dkg

From levitte at openssl.org  Fri Mar  1 22:58:39 2019
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 01 Mar 2019 23:58:39 +0100
Subject: Online docs have broken links
In-Reply-To: <CA+Sj9T=BvvRKfqtzdJem_H_prpqrAEwVSV3OpomKyDAEPMngDQ@mail.gmail.com>
References: <cc2b9c2a0e36245104f8dc5e2e4c920a9a7d5803.camel@mad-scientist.net>
 <87zhqfvv8u.wl-levitte@openssl.org>
 <CA+Sj9T=BvvRKfqtzdJem_H_prpqrAEwVSV3OpomKyDAEPMngDQ@mail.gmail.com>
Message-ID: <87tvgmw6ao.wl-levitte@openssl.org>

The problem isn't a lack of test_docs, the issue lies in how we
organised the manuals before (in an apps, a crypto and a ssl
directory), and the script that builds up these pages haven't been
updated to prefix properly per actual man section.

There's a PR that I think fixes the problem:
https://github.com/openssl/web/pull/124

Cheers,
Richard

On Fri, 01 Mar 2019 21:15:48 +0100,
Sam Roberts wrote:
> 
> I ran linklint on the output of `make install_html_docs`, and there
> are a fair amount of refs to non-existent pages as well. Maybe its
> worth adding a `test-docs` target?
> 
> Would PRs to fix the below be welcomed?
> 
> #------------------------------------------------------------
> # ERROR  18 missing html files (cross referenced)
> #------------------------------------------------------------
> /../man1/version.html
>     used in 1 file:
>     /man3/CTLOG_STORE_new.html
> 
> /../man3/EVP_EncryptInit.html
>     used in 1 file:
>     /man3/EVP_CIPHER_meth_new.html
> 
> /../man3/OSSL_STORE_SEARCH.html
>     used in 3 files:
>     /man3/OSSL_STORE_expect.html
>     /man3/OSSL_STORE_find.html
>     /man3/OSSL_STORE_supports_search.html
> 
> /../man3/SSL_CTX_set_security_level.html
>     used in 2 files:
>     /man1/ciphers.html
>     /man1/openssl-ciphers.html
> 
> /../man7/bio.html
>     used in 4 files:
>     /man3/BIO_pop.html
>     /man3/BIO_push.html
>     /man3/BIO_should_retry.html
>     /man3/SCT_print.html
> 
> /man1/curl.html
>     used in 2 files:
>     /man1/openssl-tsget.html
>     /man1/tsget.html
> 
> /man1/perl.html
>     used in 2 files:
>     /man1/openssl-ts.html
>     /man1/ts.html
> 
> /man1/procmail.html
>     used in 2 files:
>     /man1/openssl-ts.html
>     /man1/ts.html
> 
> /man3/EVP_MD_CTX_set_ctx.html
>     used in 2 files:
>     /man3/EVP_DigestSignInit.html
>     /man3/EVP_DigestVerifyInit.html
> 
> /man3/EVP_bf.html
>     used in 5 files:
>     /man3/EVP_CIPHER_CTX_reset.html
>     /man3/EVP_DecryptInit.html
>     /man3/EVP_DecryptInit_ex.html
>     /man3/EVP_EncryptInit.html
>     /man3/EVP_EncryptInit_ex.html
> 
> /man3/EVP_cast5.html
>     used in 5 files:
>     /man3/EVP_CIPHER_CTX_reset.html
>     /man3/EVP_DecryptInit.html
>     /man3/EVP_DecryptInit_ex.html
>     /man3/EVP_EncryptInit.html
>     /man3/EVP_EncryptInit_ex.html
> 
> /man3/EVP_desx.html
>     used in 5 files:
>     /man3/EVP_CIPHER_CTX_reset.html
>     /man3/EVP_DecryptInit.html
>     /man3/EVP_DecryptInit_ex.html
>     /man3/EVP_EncryptInit.html
>     /man3/EVP_EncryptInit_ex.html
> 
> /man3/EVP_idea.html
>     used in 5 files:
>     /man3/EVP_CIPHER_CTX_reset.html
>     /man3/EVP_DecryptInit.html
>     /man3/EVP_DecryptInit_ex.html
>     /man3/EVP_EncryptInit.html
>     /man3/EVP_EncryptInit_ex.html
> 
> /man3/EVP_rc2.html
>     used in 5 files:
>     /man3/EVP_CIPHER_CTX_reset.html
>     /man3/EVP_DecryptInit.html
>     /man3/EVP_DecryptInit_ex.html
>     /man3/EVP_EncryptInit.html
>     /man3/EVP_EncryptInit_ex.html
> 
> /man3/EVP_rc5.html
>     used in 5 files:
>     /man3/EVP_CIPHER_CTX_reset.html
>     /man3/EVP_DecryptInit.html
>     /man3/EVP_DecryptInit_ex.html
>     /man3/EVP_EncryptInit.html
>     /man3/EVP_EncryptInit_ex.html
> 
> /man3/EVP_seed.html
>     used in 5 files:
>     /man3/EVP_CIPHER_CTX_reset.html
>     /man3/EVP_DecryptInit.html
>     /man3/EVP_DecryptInit_ex.html
>     /man3/EVP_EncryptInit.html
>     /man3/EVP_EncryptInit_ex.html
> 
> /man3/EVP_sm4.html
>     used in 5 files:
>     /man3/EVP_CIPHER_CTX_reset.html
>     /man3/EVP_DecryptInit.html
>     /man3/EVP_DecryptInit_ex.html
>     /man3/EVP_EncryptInit.html
>     /man3/EVP_EncryptInit_ex.html
> 
> /man3/X509_check_purpose.html
>     used in 1 file:
>     /man3/X509_get_extension_flags.html
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From paul at mad-scientist.net  Fri Mar  1 22:26:01 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Fri, 01 Mar 2019 17:26:01 -0500
Subject: OpenSSL 3.0 (or 4.0) API goals
Message-ID: <94e128ac9bae93d6a1b2617e2cddebd2cd6dcf18.camel@mad-scientist.net>

Hi all.

I'm reading with interest the details coming out with respect to the
next release of OpenSSL.

I'm curious if there's any consideration being given to updating the
API for existing interfaces, and/or checking the APIs of any new
interfaces for issues that are seen in the current API.

I'm talking about things like:

 * Const-correctness for arguments
 * Signed vs. unsigned values for integer values
 * Avoiding non-portable types in the API (the most obvious example:
   using "int" as the type for socket descriptors, which is only
   portable to Windows due to an implementation detail).
 * Possibly using something like uint8_t* for pointers to buffers
   containing binary "stuff" (this could be more annoying than helpful,
   requiring a lot of casting, so I'm not sure about that).

Just wondering... seems like a good time to think about cleanups like
that, if feasible.


From angus at magsys.co.uk  Sat Mar  2 09:19:00 2019
From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd)
Date: Sat, 2 Mar 2019 09:19 +0000 (GMT Standard Time)
Subject: OpenSSL 3.0 (or 4.0) API goals
In-Reply-To: <94e128ac9bae93d6a1b2617e2cddebd2cd6dcf18.camel@mad-scientist.net>
Message-ID: <memo.20190302091910.11420C@magsys.adsl.magsys.co.uk>

> I'm curious if there's any consideration being given to updating 
> the API for existing interfaces, and/or checking the APIs of any new
> interfaces for issues that are seen in the current API.

Also replacing all C macros such as those for SSL_CTX_ctrl with proper
external functions.

This will ease use of OpenSSL with languages other than C, where we
currently have to code functions to replace the macros.  

Google did this when creating BoringSSL, there may be other similar
'improvements' that could help OpenSSL. 

Angus


From paul at mad-scientist.net  Sat Mar  2 19:23:55 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Sat, 02 Mar 2019 14:23:55 -0500
Subject: Online docs have broken links
In-Reply-To: <87tvgmw6ao.wl-levitte@openssl.org>
References: <cc2b9c2a0e36245104f8dc5e2e4c920a9a7d5803.camel@mad-scientist.net>
 <87zhqfvv8u.wl-levitte@openssl.org>
 <CA+Sj9T=BvvRKfqtzdJem_H_prpqrAEwVSV3OpomKyDAEPMngDQ@mail.gmail.com>
 <87tvgmw6ao.wl-levitte@openssl.org>
Message-ID: <9a769f2b2534a9896bb88d5826a4f52bae86e04c.camel@mad-scientist.net>

On Fri, 2019-03-01 at 23:58 +0100, Richard Levitte wrote:
> The problem isn't a lack of test_docs, the issue lies in how we
> organised the manuals before (in an apps, a crypto and a ssl
> directory), and the script that builds up these pages haven't been
> updated to prefix properly per actual man section.
> 
> There's a PR that I think fixes the problem:
> https://github.com/openssl/web/pull/124

Thanks for looking into this issue.

I had another request: can you adjust the title of the pages? 
Currently the titles look like this:

  <title>
  /docs/man1.1.1/man3/SSL_accept.html
  </title>

This can be frustrating when I have a bunch of SSL docs open in tabs in
my browser; the tab titles are all truncated to just "/docs/man..." or
whatever will fit.

I would prefer the title to be something like:

  <title>
  SSL_accept(3)
  </title>

If you would like to keep the version in the title maybe it could be
added after the name, something like:

  <title>
  SSL_accept(3) [1.1.1]
  </title>

or similar.

Cheers!


From ca+ssl-users at esmtp.org  Sun Mar  3 15:11:12 2019
From: ca+ssl-users at esmtp.org (Claus Assmann)
Date: Sun, 3 Mar 2019 07:11:12 -0800
Subject: 1.1.1: patches to compile on OpenBSD
Message-ID: <20190303151112.GA19153@x2.esmtp.org>

There are some patches for OpenSSL 1.1.1X in the OpenBSD ports tree.
Are there any plans to put (parts of) them into the next OpenSSL
version?

patch-Configurations_10-main_conf
patch-Configurations_shared-info_pl
patch-Configurations_unix-Makefile_tmpl

The changes in the last one which add an "e" to various names aren't
needed, but the rest is (AFAICT).
-------------- next part --------------
$OpenBSD: patch-Configurations_10-main_conf,v 1.1 2019/01/31 22:04:40 sthen Exp $

Index: Configurations/10-main.conf
--- Configurations/10-main.conf.orig
+++ Configurations/10-main.conf
@@ -953,6 +953,7 @@ my %targets = (
     },
     "BSD-x86-elf" => {
         inherit_from     => [ "BSD-x86" ],
+        shared_target    => "bsd-gcc-shared",
         perlasm_scheme   => "elf",
     },
 
-------------- next part --------------
$OpenBSD: patch-Configurations_shared-info_pl,v 1.1 2019/01/31 22:04:40 sthen Exp $

Also match lld's "compatible with GNU linkers".

Probably not really used at current (1.1.1a) as $config{CC} isn't even
set up when this is called...

Index: Configurations/shared-info.pl
--- Configurations/shared-info.pl.orig
+++ Configurations/shared-info.pl
@@ -12,9 +12,9 @@
 # environments on Windows.
 
 sub detect_gnu_ld {
     my @lines =
         `$config{CROSS_COMPILE}$config{CC} -Wl,-V /dev/null 2>&1`;
-    return grep /^GNU ld/, @lines;
+    return grep /^GNU ld|GNU linker/, @lines;
 }
 sub detect_gnu_cc {
     my @lines =
-------------- next part --------------
$OpenBSD: patch-Configurations_unix-Makefile_tmpl,v 1.3 2018/11/20 22:19:57 sthen Exp $

Index: Configurations/unix-Makefile.tmpl
--- Configurations/unix-Makefile.tmpl.orig
+++ Configurations/unix-Makefile.tmpl
@@ -885,7 +885,7 @@ libcrypto.pc:
 	    else \
 	        echo 'libdir=$(libdir)'; \
 	    fi; \
-	    echo 'includedir=$${prefix}/include'; \
+	    echo 'includedir=$${prefix}/include/eopenssl11'; \
 	    echo 'enginesdir=$${libdir}/engines-{- $sover_dirname -}'; \
 	    echo ''; \
 	    echo 'Name: OpenSSL-libcrypto'; \
@@ -903,12 +903,12 @@ libssl.pc:
 	    else \
 	        echo 'libdir=$(libdir)'; \
 	    fi; \
-	    echo 'includedir=$${prefix}/include'; \
+	    echo 'includedir=$${prefix}/include/eopenssl11'; \
 	    echo ''; \
 	    echo 'Name: OpenSSL-libssl'; \
 	    echo 'Description: Secure Sockets Layer and cryptography libraries'; \
 	    echo 'Version: '$(VERSION); \
-	    echo 'Requires.private: libcrypto'; \
+	    echo 'Requires.private: libecrypto'; \
 	    echo 'Libs: -L$${libdir} -lssl'; \
 	    echo 'Cflags: -I$${includedir}' ) > libssl.pc
 
@@ -920,12 +920,12 @@ openssl.pc:
 	    else \
 	        echo 'libdir=$(libdir)'; \
 	    fi; \
-	    echo 'includedir=$${prefix}/include'; \
+	    echo 'includedir=$${prefix}/include/eopenssl11'; \
 	    echo ''; \
 	    echo 'Name: OpenSSL'; \
 	    echo 'Description: Secure Sockets Layer and cryptography libraries and tools'; \
 	    echo 'Version: '$(VERSION); \
-	    echo 'Requires: libssl libcrypto' ) > openssl.pc
+	    echo 'Requires: libessl libecrypto' ) > openssl.pc
 
 configdata.pm: $(SRCDIR)/Configure $(SRCDIR)/config {- join(" ", @{$config{build_file_templates}}, @{$config{build_infos}}, @{$config{conf_files}}) -}
 	@echo "Detected changed: $?"
@@ -984,7 +984,7 @@ EOF
           if ($args{generator}->[0] =~ /\.pl$/) {
               $generator = 'CC="$(CC)" $(PERL)'.$generator_incs.' '.$generator;
           } elsif ($args{generator}->[0] =~ /\.m4$/) {
-              $generator = 'm4 -B 8192'.$generator_incs.' '.$generator.' >'
+              $generator = 'm4'.$generator_incs.' '.$generator.' >'
           } elsif ($args{generator}->[0] =~ /\.S$/) {
               $generator = undef;
           } else {

From levitte at openssl.org  Mon Mar  4 06:58:41 2019
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 04 Mar 2019 07:58:41 +0100
Subject: 1.1.1: patches to compile on OpenBSD
In-Reply-To: <20190303151112.GA19153@x2.esmtp.org>
References: <20190303151112.GA19153@x2.esmtp.org>
Message-ID: <87r2bnw2fy.wl-levitte@openssl.org>

So if I'm reading the patches correctly,
patch-Configurations_unix-Makefile_tmpl is all about that "e" stuff,
while the others are the more central things.

To my judgement, the "e" stuff is a vendor specific packaging problem,
i.e. not our table, while the other two are interesting.

Cheers,
Richard

On Sun, 03 Mar 2019 16:11:12 +0100,
Claus Assmann wrote:
> 
> There are some patches for OpenSSL 1.1.1X in the OpenBSD ports tree.
> Are there any plans to put (parts of) them into the next OpenSSL
> version?
> 
> patch-Configurations_10-main_conf
> patch-Configurations_shared-info_pl
> patch-Configurations_unix-Makefile_tmpl
> 
> The changes in the last one which add an "e" to various names aren't
> needed, but the rest is (AFAICT).
> $OpenBSD: patch-Configurations_10-main_conf,v 1.1 2019/01/31 22:04:40 sthen Exp $
> 
> Index: Configurations/10-main.conf
> --- Configurations/10-main.conf.orig
> +++ Configurations/10-main.conf
> @@ -953,6 +953,7 @@ my %targets = (
>      },
>      "BSD-x86-elf" => {
>          inherit_from     => [ "BSD-x86" ],
> +        shared_target    => "bsd-gcc-shared",
>          perlasm_scheme   => "elf",
>      },
>  
> $OpenBSD: patch-Configurations_shared-info_pl,v 1.1 2019/01/31 22:04:40 sthen Exp $
> 
> Also match lld's "compatible with GNU linkers".
> 
> Probably not really used at current (1.1.1a) as $config{CC} isn't even
> set up when this is called...
> 
> Index: Configurations/shared-info.pl
> --- Configurations/shared-info.pl.orig
> +++ Configurations/shared-info.pl
> @@ -12,9 +12,9 @@
>  # environments on Windows.
>  
>  sub detect_gnu_ld {
>      my @lines =
>          `$config{CROSS_COMPILE}$config{CC} -Wl,-V /dev/null 2>&1`;
> -    return grep /^GNU ld/, @lines;
> +    return grep /^GNU ld|GNU linker/, @lines;
>  }
>  sub detect_gnu_cc {
>      my @lines =
> $OpenBSD: patch-Configurations_unix-Makefile_tmpl,v 1.3 2018/11/20 22:19:57 sthen Exp $
> 
> Index: Configurations/unix-Makefile.tmpl
> --- Configurations/unix-Makefile.tmpl.orig
> +++ Configurations/unix-Makefile.tmpl
> @@ -885,7 +885,7 @@ libcrypto.pc:
>  	    else \
>  	        echo 'libdir=$(libdir)'; \
>  	    fi; \
> -	    echo 'includedir=$${prefix}/include'; \
> +	    echo 'includedir=$${prefix}/include/eopenssl11'; \
>  	    echo 'enginesdir=$${libdir}/engines-{- $sover_dirname -}'; \
>  	    echo ''; \
>  	    echo 'Name: OpenSSL-libcrypto'; \
> @@ -903,12 +903,12 @@ libssl.pc:
>  	    else \
>  	        echo 'libdir=$(libdir)'; \
>  	    fi; \
> -	    echo 'includedir=$${prefix}/include'; \
> +	    echo 'includedir=$${prefix}/include/eopenssl11'; \
>  	    echo ''; \
>  	    echo 'Name: OpenSSL-libssl'; \
>  	    echo 'Description: Secure Sockets Layer and cryptography libraries'; \
>  	    echo 'Version: '$(VERSION); \
> -	    echo 'Requires.private: libcrypto'; \
> +	    echo 'Requires.private: libecrypto'; \
>  	    echo 'Libs: -L$${libdir} -lssl'; \
>  	    echo 'Cflags: -I$${includedir}' ) > libssl.pc
>  
> @@ -920,12 +920,12 @@ openssl.pc:
>  	    else \
>  	        echo 'libdir=$(libdir)'; \
>  	    fi; \
> -	    echo 'includedir=$${prefix}/include'; \
> +	    echo 'includedir=$${prefix}/include/eopenssl11'; \
>  	    echo ''; \
>  	    echo 'Name: OpenSSL'; \
>  	    echo 'Description: Secure Sockets Layer and cryptography libraries and tools'; \
>  	    echo 'Version: '$(VERSION); \
> -	    echo 'Requires: libssl libcrypto' ) > openssl.pc
> +	    echo 'Requires: libessl libecrypto' ) > openssl.pc
>  
>  configdata.pm: $(SRCDIR)/Configure $(SRCDIR)/config {- join(" ", @{$config{build_file_templates}}, @{$config{build_infos}}, @{$config{conf_files}}) -}
>  	@echo "Detected changed: $?"
> @@ -984,7 +984,7 @@ EOF
>            if ($args{generator}->[0] =~ /\.pl$/) {
>                $generator = 'CC="$(CC)" $(PERL)'.$generator_incs.' '.$generator;
>            } elsif ($args{generator}->[0] =~ /\.m4$/) {
> -              $generator = 'm4 -B 8192'.$generator_incs.' '.$generator.' >'
> +              $generator = 'm4'.$generator_incs.' '.$generator.' >'
>            } elsif ($args{generator}->[0] =~ /\.S$/) {
>                $generator = undef;
>            } else {
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From WKnauf at hg-online.de  Mon Mar  4 08:08:30 2019
From: WKnauf at hg-online.de (Wolfgang Knauf)
Date: Mon, 4 Mar 2019 08:08:30 +0000
Subject: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field
Message-ID: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>

Hi,

I first asked this question in the OpenVPNGui forum, and they redirected me to here: OpenVPNGui 2.4.6 works with a customers server certificate, but it fails when using 2.4.7.

Here is the thread in the OpenVPNGui forum: https://forums.openvpn.net/viewtopic.php?f=24&t=27976

The error is:
Thu Feb 28 08:48:50 2019 VERIFY ERROR: depth=0, error=format error in certificate's notAfter field: C=de, L=Dortmund, O=Versatel, CN=ASG_1, emailAddress=...

The certificate has those fields:
        Validity
            Not Before: Oct 22 13:28:29 2009 GMT
            Not After : Mar  8 13:28:29 2037 GMT

The customer provided us with a ".....ca.crt" file, a "....user.crt" file and a "user.key" file. But I fear it is not smart to post those files in the internet ;-).

Best regards

Wolfgang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190304/20c2fee8/attachment.html>

From duythang.net at gmail.com  Mon Mar  4 08:14:52 2019
From: duythang.net at gmail.com (Thang Pham)
Date: Mon, 4 Mar 2019 15:14:52 +0700
Subject: bn_sqr8x_internal function consumes a lot of CPU time
Message-ID: <ea0ee0c4-e23c-1bcc-5339-468feb89414b@gmail.com>

Dear all,

I do not know if it is legitimate to ask this question here, but maybe 
you guys can help.

We have a service running behind nginx that using HTTPS. Recently the 
CPU utilization has raised to 100%, and using perf we see that nginx's 
using ~69% of CPU time. Inside nginx, bn_sqr8x_internal uses 32% of 
total CPU time (and mul4x_internal uses 11%).

All information I could find about bn_sqr8x_internal is that it belongs 
to bignum library in libcrypto(?). There is an idea here, that tells 
that they belong to handshake step, but it's BoringSSL, so I'm not sure 
if it's my case.

Could anyone please tell me what is nginx/libcrypto/libssl doing with 
this function, so I can find a clue to optimize the server?

Thank you very much,

-- 

Thang


From psteuer at mail.de  Mon Mar  4 08:45:34 2019
From: psteuer at mail.de (Patrick Steuer)
Date: Mon, 4 Mar 2019 09:45:34 +0100
Subject: bn_sqr8x_internal function consumes a lot of CPU time
In-Reply-To: <ea0ee0c4-e23c-1bcc-5339-468feb89414b@gmail.com>
References: <ea0ee0c4-e23c-1bcc-5339-468feb89414b@gmail.com>
Message-ID: <a4d1c0c8-b666-87df-62ed-d32cafe4e4a4@mail.de>

Its an x86_64 assembly subroutine of bn_mul_mont which implements 
montgomery modular multiplication. Its heavily used in rsa comutations.

Just set a breakpoint in the debugger and have a look at the callstack.



From levitte at openssl.org  Mon Mar  4 09:01:43 2019
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 04 Mar 2019 10:01:43 +0100
Subject: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter
 field
In-Reply-To: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
Message-ID: <87o96rvwqw.wl-levitte@openssl.org>

The format error refers to how the numbers are encoded in the
certificate.  The best way to see for ourselves is if you can run
'openssl asn1parse' on the certificate and show us the sequence that
contains the notBefore and notAfter time-stamps.  The are seen
together between the issuer name and the subject name.

As an example, here's the 'openssl asn1parse' output for
test/testx509.pem:

    : ; openssl asn1parse -i -in test/testx509.pem 
        0:d=0  hl=4 l= 347 cons: SEQUENCE          
        4:d=1  hl=4 l= 262 cons:  SEQUENCE          
        8:d=2  hl=2 l=   1 prim:   INTEGER           :18
       11:d=2  hl=2 l=  13 cons:   SEQUENCE          
       13:d=3  hl=2 l=   9 prim:    OBJECT            :md5WithRSAEncryption
       24:d=3  hl=2 l=   0 prim:    NULL              
       26:d=2  hl=2 l=  56 cons:   SEQUENCE          
       28:d=3  hl=2 l=  11 cons:    SET               
       30:d=4  hl=2 l=   9 cons:     SEQUENCE          
       32:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
       37:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :AU
       41:d=3  hl=2 l=  12 cons:    SET               
       43:d=4  hl=2 l=  10 cons:     SEQUENCE          
       45:d=5  hl=2 l=   3 prim:      OBJECT            :stateOrProvinceName
       50:d=5  hl=2 l=   3 prim:      PRINTABLESTRING   :QLD
       55:d=3  hl=2 l=  27 cons:    SET               
       57:d=4  hl=2 l=  25 cons:     SEQUENCE          
       59:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
       64:d=5  hl=2 l=  18 prim:      PRINTABLESTRING   :SSLeay/rsa test CA
       84:d=2  hl=2 l=  30 cons:   SEQUENCE          
       86:d=3  hl=2 l=  13 prim:    UTCTIME           :950619233312Z
      101:d=3  hl=2 l=  13 prim:    UTCTIME           :950717233312Z
      116:d=2  hl=2 l=  58 cons:   SEQUENCE          
      118:d=3  hl=2 l=  11 cons:    SET               
      120:d=4  hl=2 l=   9 cons:     SEQUENCE          
      122:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
      127:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :AU
      131:d=3  hl=2 l=  12 cons:    SET               
      133:d=4  hl=2 l=  10 cons:     SEQUENCE          
      135:d=5  hl=2 l=   3 prim:      OBJECT            :stateOrProvinceName
      140:d=5  hl=2 l=   3 prim:      PRINTABLESTRING   :QLD
      145:d=3  hl=2 l=  29 cons:    SET               
      147:d=4  hl=2 l=  27 cons:     SEQUENCE          
      149:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
      154:d=5  hl=2 l=  20 prim:      PRINTABLESTRING   :SSLeay/rsa test cert
      176:d=2  hl=2 l=  92 cons:   SEQUENCE          
      178:d=3  hl=2 l=  13 cons:    SEQUENCE          
      180:d=4  hl=2 l=   9 prim:     OBJECT            :rsaEncryption
      191:d=4  hl=2 l=   0 prim:     NULL              
      193:d=3  hl=2 l=  75 prim:    BIT STRING        
      270:d=1  hl=2 l=  12 cons:  SEQUENCE          
      272:d=2  hl=2 l=   8 prim:   OBJECT            :md5
      282:d=2  hl=2 l=   0 prim:   NULL              
      284:d=1  hl=2 l=  65 prim:  BIT STRING        

Here, the notBefore and notAfter are the following lines:

       84:d=2  hl=2 l=  30 cons:   SEQUENCE          
       86:d=3  hl=2 l=  13 prim:    UTCTIME           :950619233312Z
      101:d=3  hl=2 l=  13 prim:    UTCTIME           :950717233312Z

For visualization, this is the text form output of the same:

    : ; openssl x509 -in test/testx509.pem -dates -noout
    notBefore=Jun 19 23:33:12 1995 GMT
    notAfter=Jul 17 23:33:12 1995 GMT

So now, for the encoding, RFC5280 has a few things to say
(https://tools.ietf.org/html/rfc5280#section-4.1.2.5).  However, for
the dates you display, it should be easy, the should be the following:

    UTCTIME	:091022132829Z
    UTCTIME	:370308132829Z

If you see something violently different (such as GeneralizedTime
instead of UTCTIME), or the number of digits being wrong (12 for
UTCTIME, 14 for GeneralizedTime), or there being something other than
'Z' at the end, then you know why you get that error.

(I encoded those numbers manually, so I hope I got them right)

Cheers,
Richard

On Mon, 04 Mar 2019 09:08:30 +0100,
Wolfgang Knauf wrote:
> 
> 
> Hi,
> 
> I first asked this question in the OpenVPNGui forum, and they redirected me to here: OpenVPNGui
> 2.4.6 works with a customers server certificate, but it fails when using 2.4.7.
> 
> Here is the thread in the OpenVPNGui forum: https://forums.openvpn.net/viewtopic.php?f=24&t=27976
> 
> The error is:
> 
> Thu Feb 28 08:48:50 2019 VERIFY ERROR: depth=0, error=format error in certificate's notAfter field
> : C=de, L=Dortmund, O=Versatel, CN=ASG_1, emailAddress=...
> 
> The certificate has those fields:
> 
>         Validity
> 
>             Not Before: Oct 22 13:28:29 2009 GMT
> 
>             Not After : Mar  8 13:28:29 2037 GMT
> 
> The customer provided us with a ??..ca.crt? file, a ??.user.crt? file and a ?user.key? file. But I
> fear it is not smart to post those files in the internet ;-).
> 
> Best regards
> 
> Wolfgang
> 
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From janjust at nikhef.nl  Mon Mar  4 09:06:54 2019
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Mon, 4 Mar 2019 10:06:54 +0100
Subject: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter
 field
In-Reply-To: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
Message-ID: <af398ec1-5edf-d489-c820-571c998a9c17@nikhef.nl>

Hi,

On 04/03/19 09:08, Wolfgang Knauf wrote:
>
> Hi,
>
> I first asked this question in the OpenVPNGui forum, and they redirected me to here: OpenVPNGui 2.4.6 works with a customers 
> server certificate, but it fails when using 2.4.7.
>
> Here is the thread in the OpenVPNGui forum: https://forums.openvpn.net/viewtopic.php?f=24&t=27976 
> <https://forums.openvpn.net/viewtopic.php?f=24&t=27976>
>
> The error is:
>
> Thu Feb 28 08:48:50 2019 VERIFY ERROR: depth=0, error=*format error in certificate's notAfter field*: C=de, L=Dortmund, 
> O=Versatel, CN=ASG_1, emailAddress=...
>
> The certificate has those fields:
>
> ??????? Validity
>
> ??????????? Not Before: Oct 22 13:28:29 2009 GMT
>
> ??????????? Not After : Mar? 8 13:28:29 2037 GMT
>
> The customer provided us with a ??..ca.crt? file, a ??.user.crt? file and a ?user.key? file. But I fear it is not smart to 
> post those files in the internet ;-).
>
>
you can safely post the client.crt file - it is public info and useless without the key file.

Having said that, I just created a certificate set to expire on Mar 9 2037 and it passed the following command:
 ? c:\program files\openvpn\bin\openssl x509 -dates -subject -noout -in mycert.crt

can you run the same command on the failing certificate?

HTH,

JJK / Jan Just Keijser

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

From WKnauf at hg-online.de  Mon Mar  4 09:21:11 2019
From: WKnauf at hg-online.de (Wolfgang Knauf)
Date: Mon, 4 Mar 2019 09:21:11 +0000
Subject: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter
 field
In-Reply-To: <87o96rvwqw.wl-levitte@openssl.org>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <87o96rvwqw.wl-levitte@openssl.org>
Message-ID: <AM6PR08MB41817AE80946A28826CF4C8DF8710@AM6PR08MB4181.eurprd08.prod.outlook.com>

Hi,

the output is this:

C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in ..\config\SSL_HUG1 at l1139218.vt-security.de\l1139218.vt-security.de.user.crt
Error: offset too large

Would it be OK if I send the crt file to only your mail adress? I don't feel save by posting it to the mailing list ;-)?

I did not try to convert the date - still have the hope that it is an OpenSSL issue and can be fixed there ;-).

Best regards

Wolfgang

 
-----Urspr?ngliche Nachricht-----
Von: openssl-users <openssl-users-bounces at openssl.org> Im Auftrag von Richard Levitte
Gesendet: Montag, 4. M?rz 2019 10:02
An: openssl-users at openssl.org
Betreff: Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

The format error refers to how the numbers are encoded in the certificate.  The best way to see for ourselves is if you can run 'openssl asn1parse' on the certificate and show us the sequence that contains the notBefore and notAfter time-stamps.  The are seen together between the issuer name and the subject name.

As an example, here's the 'openssl asn1parse' output for
test/testx509.pem:

    : ; openssl asn1parse -i -in test/testx509.pem 
        0:d=0  hl=4 l= 347 cons: SEQUENCE          
        4:d=1  hl=4 l= 262 cons:  SEQUENCE          
        8:d=2  hl=2 l=   1 prim:   INTEGER           :18
       11:d=2  hl=2 l=  13 cons:   SEQUENCE          
       13:d=3  hl=2 l=   9 prim:    OBJECT            :md5WithRSAEncryption
       24:d=3  hl=2 l=   0 prim:    NULL              
       26:d=2  hl=2 l=  56 cons:   SEQUENCE          
       28:d=3  hl=2 l=  11 cons:    SET               
       30:d=4  hl=2 l=   9 cons:     SEQUENCE          
       32:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
       37:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :AU
       41:d=3  hl=2 l=  12 cons:    SET               
       43:d=4  hl=2 l=  10 cons:     SEQUENCE          
       45:d=5  hl=2 l=   3 prim:      OBJECT            :stateOrProvinceName
       50:d=5  hl=2 l=   3 prim:      PRINTABLESTRING   :QLD
       55:d=3  hl=2 l=  27 cons:    SET               
       57:d=4  hl=2 l=  25 cons:     SEQUENCE          
       59:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
       64:d=5  hl=2 l=  18 prim:      PRINTABLESTRING   :SSLeay/rsa test CA
       84:d=2  hl=2 l=  30 cons:   SEQUENCE          
       86:d=3  hl=2 l=  13 prim:    UTCTIME           :950619233312Z
      101:d=3  hl=2 l=  13 prim:    UTCTIME           :950717233312Z
      116:d=2  hl=2 l=  58 cons:   SEQUENCE          
      118:d=3  hl=2 l=  11 cons:    SET               
      120:d=4  hl=2 l=   9 cons:     SEQUENCE          
      122:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
      127:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :AU
      131:d=3  hl=2 l=  12 cons:    SET               
      133:d=4  hl=2 l=  10 cons:     SEQUENCE          
      135:d=5  hl=2 l=   3 prim:      OBJECT            :stateOrProvinceName
      140:d=5  hl=2 l=   3 prim:      PRINTABLESTRING   :QLD
      145:d=3  hl=2 l=  29 cons:    SET               
      147:d=4  hl=2 l=  27 cons:     SEQUENCE          
      149:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
      154:d=5  hl=2 l=  20 prim:      PRINTABLESTRING   :SSLeay/rsa test cert
      176:d=2  hl=2 l=  92 cons:   SEQUENCE          
      178:d=3  hl=2 l=  13 cons:    SEQUENCE          
      180:d=4  hl=2 l=   9 prim:     OBJECT            :rsaEncryption
      191:d=4  hl=2 l=   0 prim:     NULL              
      193:d=3  hl=2 l=  75 prim:    BIT STRING        
      270:d=1  hl=2 l=  12 cons:  SEQUENCE          
      272:d=2  hl=2 l=   8 prim:   OBJECT            :md5
      282:d=2  hl=2 l=   0 prim:   NULL              
      284:d=1  hl=2 l=  65 prim:  BIT STRING        

Here, the notBefore and notAfter are the following lines:

       84:d=2  hl=2 l=  30 cons:   SEQUENCE          
       86:d=3  hl=2 l=  13 prim:    UTCTIME           :950619233312Z
      101:d=3  hl=2 l=  13 prim:    UTCTIME           :950717233312Z

For visualization, this is the text form output of the same:

    : ; openssl x509 -in test/testx509.pem -dates -noout
    notBefore=Jun 19 23:33:12 1995 GMT
    notAfter=Jul 17 23:33:12 1995 GMT

So now, for the encoding, RFC5280 has a few things to say (https://tools.ietf.org/html/rfc5280#section-4.1.2.5).  However, for the dates you display, it should be easy, the should be the following:

    UTCTIME	:091022132829Z
    UTCTIME	:370308132829Z

If you see something violently different (such as GeneralizedTime instead of UTCTIME), or the number of digits being wrong (12 for UTCTIME, 14 for GeneralizedTime), or there being something other than 'Z' at the end, then you know why you get that error.

(I encoded those numbers manually, so I hope I got them right)

Cheers,
Richard

On Mon, 04 Mar 2019 09:08:30 +0100,
Wolfgang Knauf wrote:
> 
> 
> Hi,
> 
> I first asked this question in the OpenVPNGui forum, and they 
> redirected me to here: OpenVPNGui
> 2.4.6 works with a customers server certificate, but it fails when using 2.4.7.
> 
> Here is the thread in the OpenVPNGui forum: 
> https://forums.openvpn.net/viewtopic.php?f=24&t=27976
> 
> The error is:
> 
> Thu Feb 28 08:48:50 2019 VERIFY ERROR: depth=0, error=format error in 
> certificate's notAfter field
> : C=de, L=Dortmund, O=Versatel, CN=ASG_1, emailAddress=...
> 
> The certificate has those fields:
> 
>         Validity
> 
>             Not Before: Oct 22 13:28:29 2009 GMT
> 
>             Not After : Mar  8 13:28:29 2037 GMT
> 
> The customer provided us with a ??..ca.crt? file, a ??.user.crt? file 
> and a ?user.key? file. But I fear it is not smart to post those files in the internet ;-).
> 
> Best regards
> 
> Wolfgang
> 
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From WKnauf at hg-online.de  Mon Mar  4 09:22:41 2019
From: WKnauf at hg-online.de (Wolfgang Knauf)
Date: Mon, 4 Mar 2019 09:22:41 +0000
Subject: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter
 field
In-Reply-To: <af398ec1-5edf-d489-c820-571c998a9c17@nikhef.nl>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <af398ec1-5edf-d489-c820-571c998a9c17@nikhef.nl>
Message-ID: <AM6PR08MB41810B7109C8D39FF075C80EF8710@AM6PR08MB4181.eurprd08.prod.outlook.com>

Hi,

this is the output of "-dates":

C:\Program Files\OpenVPN\bin>openssl.exe x509 -dates -subject -noout -in ..\config\SSL_HUG1 at l1139218.vt-security.de\l1139218.vt-security.de.ca.crt
notBefore=Oct 22 13:28:29 2009 GMT
notAfter=Mar  8 13:28:29 2037 GMT
subject=C = de, L = Dortmund, O = Versatel, CN = Versatel VPN CA, emailAddress = admin at vt-security.de


Would it be OK if I send the crt file to only your mail adress? I don't feel save by posting it to the mailing list ;-)?

Best regards

Wolfgang

Von: Jan Just Keijser <janjust at nikhef.nl>
Gesendet: Montag, 4. M?rz 2019 10:07
An: Wolfgang Knauf <WKnauf at hg-online.de>; openssl-users at openssl.org
Betreff: Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Hi,

On 04/03/19 09:08, Wolfgang Knauf wrote:
Hi,

I first asked this question in the OpenVPNGui forum, and they redirected me to here: OpenVPNGui 2.4.6 works with a customers server certificate, but it fails when using 2.4.7.

Here is the thread in the OpenVPNGui forum: https://forums.openvpn.net/viewtopic.php?f=24&t=27976

The error is:
Thu Feb 28 08:48:50 2019 VERIFY ERROR: depth=0, error=format error in certificate's notAfter field: C=de, L=Dortmund, O=Versatel, CN=ASG_1, emailAddress=...

The certificate has those fields:
        Validity
            Not Before: Oct 22 13:28:29 2009 GMT
            Not After : Mar  8 13:28:29 2037 GMT

The customer provided us with a ".....ca.crt" file, a "....user.crt" file and a "user.key" file. But I fear it is not smart to post those files in the internet ;-).


you can safely post the client.crt file - it is public info and useless without the key file.

Having said that, I just created a certificate set to expire on Mar 9 2037 and it passed the following command:
  c:\program files\openvpn\bin\openssl x509 -dates -subject -noout -in mycert.crt

can you run the same command on the failing certificate?

HTH,

JJK / Jan Just Keijser
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190304/31bd4b42/attachment.html>

From levitte at openssl.org  Mon Mar  4 09:27:26 2019
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 04 Mar 2019 10:27:26 +0100
Subject: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter
 field
In-Reply-To: <af398ec1-5edf-d489-c820-571c998a9c17@nikhef.nl>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <af398ec1-5edf-d489-c820-571c998a9c17@nikhef.nl>
Message-ID: <87mumbvvk1.wl-levitte@openssl.org>

On Mon, 04 Mar 2019 10:06:54 +0100,
Jan Just Keijser wrote:
...
> Having said that, I just created a certificate set to expire on Mar 9 2037 and it passed the
> following command:
> ? c:\program files\openvpn\bin\openssl x509 -dates -subject -noout -in mycert.crt
> 
> can you run the same command on the failing certificate?

That's a poor test.  'openssl x509' doesn't verify the certificate,
and the error comes up during verification.  To verify, use 'openssl
verify'.  Here's an example with OpenSSL test files:

    openssl verify -trusted test/certs/root-cert.pem test/certs/ca-cert.pem 

So in Wolfgang's case, I suspect something like this would say more:

    openssl verify -trusted .....ca.crt .....user.crt

Cheers,
Richard

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

From janjust at nikhef.nl  Mon Mar  4 09:36:10 2019
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Mon, 4 Mar 2019 10:36:10 +0100
Subject: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter
 field
In-Reply-To: <87mumbvvk1.wl-levitte@openssl.org>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <af398ec1-5edf-d489-c820-571c998a9c17@nikhef.nl>
 <87mumbvvk1.wl-levitte@openssl.org>
Message-ID: <f38a8366-2fe0-9fcc-f90e-96320f421947@nikhef.nl>

Hi Richard,

On 04/03/19 10:27, Richard Levitte wrote:
> On Mon, 04 Mar 2019 10:06:54 +0100,
> Jan Just Keijser wrote:
> ...
>> Having said that, I just created a certificate set to expire on Mar 9 2037 and it passed the
>> following command:
>>  ? c:\program files\openvpn\bin\openssl x509 -dates -subject -noout -in mycert.crt
>>
>> can you run the same command on the failing certificate?
> That's a poor test.  'openssl x509' doesn't verify the certificate,
> and the error comes up during verification.  To verify, use 'openssl
> verify'.  Here's an example with OpenSSL test files:
>
>      openssl verify -trusted test/certs/root-cert.pem test/certs/ca-cert.pem
>
> So in Wolfgang's case, I suspect something like this would say more:
>
>      openssl verify -trusted .....ca.crt .....user.crt
>

you were one step ahead of me :)
I fully agree that it is a poor test, I was just wondering if there was 
an encoding error in the cert itself, esp as the EndDate approaches the 
32bit epoch...

Wolfgang, can you send me both the client cert and the CA cert that goes 
with it? both are public info.

cheers,

JJK / Jan Just Keijser


From WKnauf at hg-online.de  Mon Mar  4 09:37:54 2019
From: WKnauf at hg-online.de (Wolfgang Knauf)
Date: Mon, 4 Mar 2019 09:37:54 +0000
Subject: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter
 field
In-Reply-To: <f38a8366-2fe0-9fcc-f90e-96320f421947@nikhef.nl>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <af398ec1-5edf-d489-c820-571c998a9c17@nikhef.nl>
 <87mumbvvk1.wl-levitte@openssl.org>
 <f38a8366-2fe0-9fcc-f90e-96320f421947@nikhef.nl>
Message-ID: <AM6PR08MB41816AB9E3839B3B0F7E8BC9F8710@AM6PR08MB4181.eurprd08.prod.outlook.com>

Here is the output:

C:\Program Files\OpenVPN\bin>openssl.exe verify -trusted ..\config\SSL_HUG1 at l1139218.vt-security.de\l1139218.vt-security.de.ca.crt ..\config\SSL_HUG1 at l1139218.vt-security.de\l1139218.vt-security.de.user.crt
..\config\SSL_HUG1 at l1139218.vt-security.de\l1139218.vt-security.de.user.crt: OK

But it seems I don't have the root certificate, just the CA certificate?

I will send both certificate files in another mail.

Wolfgang

-----Urspr?ngliche Nachricht-----
Von: openssl-users <openssl-users-bounces at openssl.org> Im Auftrag von Jan Just Keijser
Gesendet: Montag, 4. M?rz 2019 10:36
An: Richard Levitte <levitte at openssl.org>; openssl-users at openssl.org
Betreff: Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Hi Richard,

On 04/03/19 10:27, Richard Levitte wrote:
> On Mon, 04 Mar 2019 10:06:54 +0100,
> Jan Just Keijser wrote:
> ...
>> Having said that, I just created a certificate set to expire on Mar 9 
>> 2037 and it passed the following command:
>>  ? c:\program files\openvpn\bin\openssl x509 -dates -subject -noout 
>> -in mycert.crt
>>
>> can you run the same command on the failing certificate?
> That's a poor test.  'openssl x509' doesn't verify the certificate, 
> and the error comes up during verification.  To verify, use 'openssl 
> verify'.  Here's an example with OpenSSL test files:
>
>      openssl verify -trusted test/certs/root-cert.pem 
> test/certs/ca-cert.pem
>
> So in Wolfgang's case, I suspect something like this would say more:
>
>      openssl verify -trusted .....ca.crt .....user.crt
>

you were one step ahead of me :)
I fully agree that it is a poor test, I was just wondering if there was an encoding error in the cert itself, esp as the EndDate approaches the 32bit epoch...

Wolfgang, can you send me both the client cert and the CA cert that goes with it? both are public info.

cheers,

JJK / Jan Just Keijser


From ca+ssl-users at esmtp.org  Mon Mar  4 10:29:26 2019
From: ca+ssl-users at esmtp.org (Claus Assmann)
Date: Mon, 4 Mar 2019 02:29:26 -0800
Subject: 1.1.1: patches to compile on OpenBSD
In-Reply-To: <87r2bnw2fy.wl-levitte@openssl.org>
References: <20190303151112.GA19153@x2.esmtp.org>
 <87r2bnw2fy.wl-levitte@openssl.org>
Message-ID: <20190304102926.GA11099@x2.esmtp.org>

On Mon, Mar 04, 2019, Richard Levitte wrote:
> So if I'm reading the patches correctly,
> patch-Configurations_unix-Makefile_tmpl is all about that "e" stuff,

Nope, seems you missed one change in all the text you quoted:

-              $generator = 'm4 -B 8192'.$generator_incs.' '.$generator.' >'
+              $generator = 'm4'.$generator_incs.' '.$generator.' >'

From matt at openssl.org  Mon Mar  4 11:59:26 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 4 Mar 2019 11:59:26 +0000
Subject: OpenSSL 3.0 (or 4.0) API goals
In-Reply-To: <94e128ac9bae93d6a1b2617e2cddebd2cd6dcf18.camel@mad-scientist.net>
References: <94e128ac9bae93d6a1b2617e2cddebd2cd6dcf18.camel@mad-scientist.net>
Message-ID: <aa0a1b44-7e5d-257b-97ea-6cb92a41d828@openssl.org>



On 01/03/2019 22:26, Paul Smith wrote:
> Hi all.
> 
> I'm reading with interest the details coming out with respect to the
> next release of OpenSSL.
> 
> I'm curious if there's any consideration being given to updating the
> API for existing interfaces, and/or checking the APIs of any new
> interfaces for issues that are seen in the current API.
> 
> I'm talking about things like:
> 
>  * Const-correctness for arguments

const correctness is an ongoing thing. I'd welcome PRs that address this.

>  * Signed vs. unsigned values for integer values

We did do quite a bit of work internally in libssl to implement more consistent
use of size_t where appropriate. We need to do something similar in libcrypto
although that's probably a much bigger job. Dealing with things internally is
much easier than changing the API - because that is obviously a breaking change
which we try to avoid where possible.

>  * Avoiding non-portable types in the API (the most obvious example:
>    using "int" as the type for socket descriptors, which is only
>    portable to Windows due to an implementation detail).

I would hope that we're not introducing any new instances of this. Any that we
have are likely to be historical. Removing such instances would be a matter of
deprecating the relevant APIs and making sure they have suitable portable
replacements in place.

>  * Possibly using something like uint8_t* for pointers to buffers
>    containing binary "stuff" (this could be more annoying than helpful,
>    requiring a lot of casting, so I'm not sure about that).
> 
> Just wondering... seems like a good time to think about cleanups like
> that, if feasible.
> 



On 02/03/2019 09:18, Angus Robertson - Magenta Systems Ltd wrote:
> Also replacing all C macros such as those for SSL_CTX_ctrl with proper
> external functions.
>
> This will ease use of OpenSSL with languages other than C, where we
> currently have to code functions to replace the macros.
>
> Google did this when creating BoringSSL, there may be other similar
> 'improvements' that could help OpenSSL.

I'd be in favour of that for SSL_ctrl/SSL_CTX_ctrl where I don't think the
"ctrl" pattern adds much value. All SSL_METHOD implementations share the same
ctrl implementation, with the exception of DTLS which adds a few extra ctrls.

For other areas that may not be the case. For example with BIO_ctrl all the
different BIO_METHODs all have quite separate ctrl implementations so there
seems a bigger benefit to this pattern there.


Matt


From levitte at openssl.org  Mon Mar  4 12:08:40 2019
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 04 Mar 2019 13:08:40 +0100
Subject: OpenSSL 3.0 (or 4.0) API goals
In-Reply-To: <aa0a1b44-7e5d-257b-97ea-6cb92a41d828@openssl.org>
References: <94e128ac9bae93d6a1b2617e2cddebd2cd6dcf18.camel@mad-scientist.net>
 <aa0a1b44-7e5d-257b-97ea-6cb92a41d828@openssl.org>
Message-ID: <94BF83B4-85B0-4A84-9E8D-B7B47A1673B1@openssl.org>



Matt Caswell <matt at openssl.org> skrev: (4 mars 2019 12:59:26 CET)
>
>
>On 01/03/2019 22:26, Paul Smith wrote:
>> Hi all.
>> 
>> I'm reading with interest the details coming out with respect to the
>> next release of OpenSSL.
>> 
>> I'm curious if there's any consideration being given to updating the
>> API for existing interfaces, and/or checking the APIs of any new
>> interfaces for issues that are seen in the current API.
>> 
>> I'm talking about things like:
>> 
>>  * Const-correctness for arguments
>
>const correctness is an ongoing thing. I'd welcome PRs that address
>this.

Incidentally, I looked at clang-tidy today. It seems to have some helpful options for this kind of work. 

>
>>  * Signed vs. unsigned values for integer values
>
>We did do quite a bit of work internally in libssl to implement more
>consistent
>use of size_t where appropriate. We need to do something similar in
>libcrypto
>although that's probably a much bigger job. Dealing with things
>internally is
>much easier than changing the API - because that is obviously a
>breaking change
>which we try to avoid where possible.
>
>>  * Avoiding non-portable types in the API (the most obvious example:
>>    using "int" as the type for socket descriptors, which is only
>>    portable to Windows due to an implementation detail).
>
>I would hope that we're not introducing any new instances of this. Any
>that we
>have are likely to be historical. Removing such instances would be a
>matter of
>deprecating the relevant APIs and making sure they have suitable
>portable
>replacements in place.
>
>>  * Possibly using something like uint8_t* for pointers to buffers
>>    containing binary "stuff" (this could be more annoying than
>helpful,
>>    requiring a lot of casting, so I'm not sure about that).
>> 
>> Just wondering... seems like a good time to think about cleanups like
>> that, if feasible.
>> 
>
>
>
>On 02/03/2019 09:18, Angus Robertson - Magenta Systems Ltd wrote:
>> Also replacing all C macros such as those for SSL_CTX_ctrl with
>proper
>> external functions.
>>
>> This will ease use of OpenSSL with languages other than C, where we
>> currently have to code functions to replace the macros.
>>
>> Google did this when creating BoringSSL, there may be other similar
>> 'improvements' that could help OpenSSL.
>
>I'd be in favour of that for SSL_ctrl/SSL_CTX_ctrl where I don't think
>the
>"ctrl" pattern adds much value. All SSL_METHOD implementations share
>the same
>ctrl implementation, with the exception of DTLS which adds a few extra
>ctrls.
>
>For other areas that may not be the case. For example with BIO_ctrl all
>the
>different BIO_METHODs all have quite separate ctrl implementations so
>there
>seems a bigger benefit to this pattern there.
>
>
>Matt

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From hkario at redhat.com  Mon Mar  4 12:57:56 2019
From: hkario at redhat.com (Hubert Kario)
Date: Mon, 04 Mar 2019 13:57:56 +0100
Subject: OpenSSL 3.0 (or 4.0) API goals
In-Reply-To: <aa0a1b44-7e5d-257b-97ea-6cb92a41d828@openssl.org>
References: <94e128ac9bae93d6a1b2617e2cddebd2cd6dcf18.camel@mad-scientist.net>
 <aa0a1b44-7e5d-257b-97ea-6cb92a41d828@openssl.org>
Message-ID: <3321663.AY8GOacBLF@pintsize.usersys.redhat.com>

On Monday, 4 March 2019 12:59:26 CET Matt Caswell wrote:
> On 01/03/2019 22:26, Paul Smith wrote:
> > Hi all.
> > 
> > I'm reading with interest the details coming out with respect to the
> > next release of OpenSSL.
> > 
> > I'm curious if there's any consideration being given to updating the
> > API for existing interfaces, and/or checking the APIs of any new
> > interfaces for issues that are seen in the current API.
> > 
> > I'm talking about things like:
> >  * Const-correctness for arguments
> 
> const correctness is an ongoing thing. I'd welcome PRs that address this.
> 
> >  * Signed vs. unsigned values for integer values
> 
> We did do quite a bit of work internally in libssl to implement more
> consistent use of size_t where appropriate. We need to do something similar
> in libcrypto although that's probably a much bigger job. Dealing with
> things internally is much easier than changing the API - because that is
> obviously a breaking change which we try to avoid where possible.

In the past 9 years OpenSSL broke ABI/API 2 times (0.9.x to 1.0.0 and 1.0.2 to 
1.1.0) and announced a third. I think it's far too often for such a critical 
and integral part of operating systems.

IMNSHO such API cleanup should be mandatory part of the OpenSSL 3.0 (4.0) 
deliverable.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190304/33af58cc/attachment.sig>

From janjust at nikhef.nl  Mon Mar  4 13:16:20 2019
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Mon, 4 Mar 2019 14:16:20 +0100
Subject: AW: OpenVPNGui 2.4.7 fails: format error in certificate's
 notAfter field
In-Reply-To: <AM6PR08MB41817AE80946A28826CF4C8DF8710@AM6PR08MB4181.eurprd08.prod.outlook.com>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <87o96rvwqw.wl-levitte@openssl.org>
 <AM6PR08MB41817AE80946A28826CF4C8DF8710@AM6PR08MB4181.eurprd08.prod.outlook.com>
Message-ID: <17f1ec0d-b1dd-4d66-3750-bc51f9cf82e5@nikhef.nl>

On 04/03/19 10:21, Wolfgang Knauf wrote:
> Hi,
>
> the output is this:
>
> C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in ..\config\SSL_HUG1 at l1139218.vt-security.de\l1139218.vt-security.de.user.crt
> Error: offset too large
>
> Would it be OK if I send the crt file to only your mail adress? I don't feel save by posting it to the mailing list ;-)?
>
>
I ran into the "offset too large" problem myself with my own certs as 
well. It turns out the 'asn1parse' util only likes PEM blobs, i.e. the 
parts starting with --BEGIN CERTIFICATE--

You can use
 ? openssl x509 -in l1139218.vt-security.de.user.crt -out | openssl 
ans1parse
to work around this.
For your certificates this results in

 ??? 0:d=0? hl=4 l= 942 cons: SEQUENCE
 ??? 4:d=1? hl=4 l= 791 cons: SEQUENCE
 ??? 8:d=2? hl=2 l=?? 3 cons: cont [ 0 ]
 ?? 10:d=3? hl=2 l=?? 1 prim: INTEGER?????????? :02
 ?? 13:d=2? hl=2 l=?? 9 prim: INTEGER?????????? :C604316CD0321FA1
 ?? 24:d=2? hl=2 l=? 13 cons: SEQUENCE
 ?? 26:d=3? hl=2 l=?? 9 prim: OBJECT :sha256WithRSAEncryption
 ?? 37:d=3? hl=2 l=?? 0 prim: NULL
[...]
 ? 155:d=2? hl=2 l=? 30 cons: SEQUENCE
 ? 157:d=3? hl=2 l=? 13 prim: UTCTIME?????????? :160418140054Z
 ? 172:d=3? hl=2 l=? 13 prim: UTCTIME?????????? :370308132808Z
 ? 187:d=2? hl=2 l=? 88 cons: SEQUENCE
 ? 189:d=3? hl=2 l=? 11 cons: SET
 ? 191:d=4? hl=2 l=?? 9 cons: SEQUENCE
 ? 193:d=5? hl=2 l=?? 3 prim: OBJECT??????????? :countryName
 ? 198:d=5? hl=2 l=?? 2 prim: PRINTABLESTRING?? :de

In other words, the dates look OK to me.
Also, I've thrown my own verification code against the certificate and 
everything checks out OK.
I'll see if I can reproduce the issue in my own OpenVPN setup.

HTH,

JJK / Jan Just Keijser


From matt at openssl.org  Mon Mar  4 13:22:40 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 4 Mar 2019 13:22:40 +0000
Subject: OpenSSL 3.0 (or 4.0) API goals
In-Reply-To: <3321663.AY8GOacBLF@pintsize.usersys.redhat.com>
References: <94e128ac9bae93d6a1b2617e2cddebd2cd6dcf18.camel@mad-scientist.net>
 <aa0a1b44-7e5d-257b-97ea-6cb92a41d828@openssl.org>
 <3321663.AY8GOacBLF@pintsize.usersys.redhat.com>
Message-ID: <cb3f6df8-3d18-3c98-74ea-01da42850a64@openssl.org>



On 04/03/2019 12:57, Hubert Kario wrote:
> On Monday, 4 March 2019 12:59:26 CET Matt Caswell wrote:
>> On 01/03/2019 22:26, Paul Smith wrote:
>>> Hi all.
>>>
>>> I'm reading with interest the details coming out with respect to the
>>> next release of OpenSSL.
>>>
>>> I'm curious if there's any consideration being given to updating the
>>> API for existing interfaces, and/or checking the APIs of any new
>>> interfaces for issues that are seen in the current API.
>>>
>>> I'm talking about things like:
>>>  * Const-correctness for arguments
>>
>> const correctness is an ongoing thing. I'd welcome PRs that address this.
>>
>>>  * Signed vs. unsigned values for integer values
>>
>> We did do quite a bit of work internally in libssl to implement more
>> consistent use of size_t where appropriate. We need to do something similar
>> in libcrypto although that's probably a much bigger job. Dealing with
>> things internally is much easier than changing the API - because that is
>> obviously a breaking change which we try to avoid where possible.
> 
> In the past 9 years OpenSSL broke ABI/API 2 times (0.9.x to 1.0.0 and 1.0.2 to 
> 1.1.0) and announced a third. I think it's far too often for such a critical 
> and integral part of operating systems.
> 
> IMNSHO such API cleanup should be mandatory part of the OpenSSL 3.0 (4.0) 
> deliverable.
> 

Well what we said about OpenSSL 3.0 is:

"OpenSSL 3.0 is a major release and will be a significant change to the internal
architecture of OpenSSL. We plan to keep impacts on existing end user
applications to an absolute minimum with the intention that the vast majority of
existing well-behaved applications will just need to be recompiled. No
deprecated APIs will be removed in this release."

(from my blog post).

And:

"The OpenSSL 3.0 release will have minimal impact to the vast majority
of existing applications; almost all well-behaved applications will
just need to be recompiled."


So ABI compatibility won't be maintained. But I expect API compatibility largely
will. I do not expect the 1.1.1 -> 3.0 move to be anything like the 1.0.2 ->
1.1.0 move. While a recompile will be necessary, the intention is that, in most
cases, that will be all.

Matt



From matt at openssl.org  Mon Mar  4 13:24:39 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 4 Mar 2019 13:24:39 +0000
Subject: AW: OpenVPNGui 2.4.7 fails: format error in certificate's
 notAfter field
In-Reply-To: <17f1ec0d-b1dd-4d66-3750-bc51f9cf82e5@nikhef.nl>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <87o96rvwqw.wl-levitte@openssl.org>
 <AM6PR08MB41817AE80946A28826CF4C8DF8710@AM6PR08MB4181.eurprd08.prod.outlook.com>
 <17f1ec0d-b1dd-4d66-3750-bc51f9cf82e5@nikhef.nl>
Message-ID: <4250580e-d7ce-734e-e5d3-4e2ee560974f@openssl.org>



On 04/03/2019 13:16, Jan Just Keijser wrote:
> On 04/03/19 10:21, Wolfgang Knauf wrote:
>> Hi,
>>
>> the output is this:
>>
>> C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in
>> ..\config\SSL_HUG1 at l1139218.vt-security.de\l1139218.vt-security.de.user.crt
>> Error: offset too large
>>
>> Would it be OK if I send the crt file to only your mail adress? I don't feel
>> save by posting it to the mailing list ;-)?
>>
>>
> I ran into the "offset too large" problem myself with my own certs as well. It
> turns out the 'asn1parse' util only likes PEM blobs, i.e. the parts starting
> with --BEGIN CERTIFICATE--

asn1parse will expect PEM by default but is perfectly capable of processing raw
DER too. Just use the "-inform DER" option.

Matt


From WKnauf at hg-online.de  Mon Mar  4 13:24:40 2019
From: WKnauf at hg-online.de (Wolfgang Knauf)
Date: Mon, 4 Mar 2019 13:24:40 +0000
Subject: AW: AW: OpenVPNGui 2.4.7 fails: format error in certificate's
 notAfter field
In-Reply-To: <17f1ec0d-b1dd-4d66-3750-bc51f9cf82e5@nikhef.nl>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <87o96rvwqw.wl-levitte@openssl.org>
 <AM6PR08MB41817AE80946A28826CF4C8DF8710@AM6PR08MB4181.eurprd08.prod.outlook.com>
 <17f1ec0d-b1dd-4d66-3750-bc51f9cf82e5@nikhef.nl>
Message-ID: <AM6PR08MB41819E29F0F85B7559595D54F8710@AM6PR08MB4181.eurprd08.prod.outlook.com>

Might the reason for this error be some server certificate that I don't have locally but that is downloaded/checked during the OpenVPNGui connection?

Sorry is this is a dumb questions, but I am just a user of OpenVPNGui and don't have knowledge about the internals...

Wolfgang

-----Urspr?ngliche Nachricht-----
Von: Jan Just Keijser <janjust at nikhef.nl> 
Gesendet: Montag, 4. M?rz 2019 14:16
An: Wolfgang Knauf <WKnauf at hg-online.de>; openssl-users at openssl.org
Betreff: Re: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

On 04/03/19 10:21, Wolfgang Knauf wrote:
> Hi,
>
> the output is this:
>
> C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in 
> ..\config\SSL_HUG1 at l1139218.vt-security.de\l1139218.vt-security.de.use
> r.crt
> Error: offset too large
>
> Would it be OK if I send the crt file to only your mail adress? I don't feel save by posting it to the mailing list ;-)?
>
>
I ran into the "offset too large" problem myself with my own certs as well. It turns out the 'asn1parse' util only likes PEM blobs, i.e. the parts starting with --BEGIN CERTIFICATE--

You can use
 ? openssl x509 -in l1139218.vt-security.de.user.crt -out | openssl ans1parse to work around this.
For your certificates this results in

 ??? 0:d=0? hl=4 l= 942 cons: SEQUENCE
 ??? 4:d=1? hl=4 l= 791 cons: SEQUENCE
 ??? 8:d=2? hl=2 l=?? 3 cons: cont [ 0 ]
 ?? 10:d=3? hl=2 l=?? 1 prim: INTEGER?????????? :02
 ?? 13:d=2? hl=2 l=?? 9 prim: INTEGER?????????? :C604316CD0321FA1
 ?? 24:d=2? hl=2 l=? 13 cons: SEQUENCE
 ?? 26:d=3? hl=2 l=?? 9 prim: OBJECT :sha256WithRSAEncryption
 ?? 37:d=3? hl=2 l=?? 0 prim: NULL
[...]
 ? 155:d=2? hl=2 l=? 30 cons: SEQUENCE
 ? 157:d=3? hl=2 l=? 13 prim: UTCTIME?????????? :160418140054Z
 ? 172:d=3? hl=2 l=? 13 prim: UTCTIME?????????? :370308132808Z
 ? 187:d=2? hl=2 l=? 88 cons: SEQUENCE
 ? 189:d=3? hl=2 l=? 11 cons: SET
 ? 191:d=4? hl=2 l=?? 9 cons: SEQUENCE
 ? 193:d=5? hl=2 l=?? 3 prim: OBJECT??????????? :countryName
 ? 198:d=5? hl=2 l=?? 2 prim: PRINTABLESTRING?? :de

In other words, the dates look OK to me.
Also, I've thrown my own verification code against the certificate and everything checks out OK.
I'll see if I can reproduce the issue in my own OpenVPN setup.

HTH,

JJK / Jan Just Keijser


From rsalz at akamai.com  Mon Mar  4 14:06:33 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 4 Mar 2019 14:06:33 +0000
Subject: 1.1.1: patches to compile on OpenBSD
In-Reply-To: <20190303151112.GA19153@x2.esmtp.org>
References: <20190303151112.GA19153@x2.esmtp.org>
Message-ID: <E4B5EA0D-AAC8-416C-9B08-619807FFA9BD@akamai.com>

Can we take OpenBSD code and put it under the Apache license?


From janjust at nikhef.nl  Mon Mar  4 14:20:36 2019
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Mon, 4 Mar 2019 15:20:36 +0100
Subject: AW: OpenVPNGui 2.4.7 fails: format error in certificate's
 notAfter field
In-Reply-To: <4250580e-d7ce-734e-e5d3-4e2ee560974f@openssl.org>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <87o96rvwqw.wl-levitte@openssl.org>
 <AM6PR08MB41817AE80946A28826CF4C8DF8710@AM6PR08MB4181.eurprd08.prod.outlook.com>
 <17f1ec0d-b1dd-4d66-3750-bc51f9cf82e5@nikhef.nl>
 <4250580e-d7ce-734e-e5d3-4e2ee560974f@openssl.org>
Message-ID: <cd050f20-31ae-fb5c-5874-4082d7393645@nikhef.nl>

Hi Matt,

On 04/03/19 14:24, Matt Caswell wrote:
>
> On 04/03/2019 13:16, Jan Just Keijser wrote:
>> On 04/03/19 10:21, Wolfgang Knauf wrote:
>>> Hi,
>>>
>>> the output is this:
>>>
>>> C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in
>>> ..\config\SSL_HUG1 at l1139218.vt-security.de\l1139218.vt-security.de.user.crt
>>> Error: offset too large
>>>
>>> Would it be OK if I send the crt file to only your mail adress? I don't feel
>>> save by posting it to the mailing list ;-)?
>>>
>>>
>> I ran into the "offset too large" problem myself with my own certs as well. It
>> turns out the 'asn1parse' util only likes PEM blobs, i.e. the parts starting
>> with --BEGIN CERTIFICATE--
> asn1parse will expect PEM by default but is perfectly capable of processing raw
> DER too. Just use the "-inform DER" option.
>
>
100% true but that is not what I was referring to; my certs usually look 
like this:

Certificate:
 ??? Data:
 ??????? Version: 3 (0x2)
 ??????? Serial Number: 5338 (0x14da)
 ??????? Signature Algorithm: sha256WithRSAEncryption
[...]
-----BEGIN CERTIFICATE-----
MIIEmjCCA4KgAwIBAgICFNowDQYJKoZIhvcNAQELBQAwUjELMAkGA1UEBhMCTkwx


it's that part *before* the --BEGIN CERTIFICATE--? on which the 
asn1parse command chokes. You can feed it either a DER file or a PEM 
blob - but not a certificate file with the certificate info listed in it.

JJK


From hkario at redhat.com  Mon Mar  4 15:22:32 2019
From: hkario at redhat.com (Hubert Kario)
Date: Mon, 04 Mar 2019 16:22:32 +0100
Subject: AW: OpenVPNGui 2.4.7 fails: format error in certificate's
 notAfter field
In-Reply-To: <cd050f20-31ae-fb5c-5874-4082d7393645@nikhef.nl>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <4250580e-d7ce-734e-e5d3-4e2ee560974f@openssl.org>
 <cd050f20-31ae-fb5c-5874-4082d7393645@nikhef.nl>
Message-ID: <1945697.9zkozX20WA@pintsize.usersys.redhat.com>

On Monday, 4 March 2019 15:20:36 CET Jan Just Keijser wrote:
> Hi Matt,
> 
> On 04/03/19 14:24, Matt Caswell wrote:
> > On 04/03/2019 13:16, Jan Just Keijser wrote:
> >> On 04/03/19 10:21, Wolfgang Knauf wrote:
> >>> Hi,
> >>> 
> >>> the output is this:
> >>> 
> >>> C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in
> >>> ..\config\SSL_HUG1 at l1139218.vt-security.de\l1139218.vt-security.de.user.
> >>> crt
> >>> Error: offset too large
> >>> 
> >>> Would it be OK if I send the crt file to only your mail adress? I don't
> >>> feel save by posting it to the mailing list ;-)?
> >> 
> >> I ran into the "offset too large" problem myself with my own certs as
> >> well. It turns out the 'asn1parse' util only likes PEM blobs, i.e. the
> >> parts starting with --BEGIN CERTIFICATE--
> > 
> > asn1parse will expect PEM by default but is perfectly capable of
> > processing raw DER too. Just use the "-inform DER" option.
> 
> 100% true but that is not what I was referring to; my certs usually look
> like this:
> 
> Certificate:
>      Data:
>          Version: 3 (0x2)
>          Serial Number: 5338 (0x14da)
>          Signature Algorithm: sha256WithRSAEncryption
> [...]
> -----BEGIN CERTIFICATE-----
> MIIEmjCCA4KgAwIBAgICFNowDQYJKoZIhvcNAQELBQAwUjELMAkGA1UEBhMCTkwx
> 
> 
> it's that part *before* the --BEGIN CERTIFICATE--  on which the
> asn1parse command chokes. You can feed it either a DER file or a PEM
> blob - but not a certificate file with the certificate info listed in it.

ah, yes, that's https://github.com/openssl/openssl/issues/7317

that should be possible to workaround with -strictpem option

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190304/8b1ee47b/attachment.sig>

From ylavic.dev at gmail.com  Mon Mar  4 23:37:53 2019
From: ylavic.dev at gmail.com (Yann Ylavic)
Date: Tue, 5 Mar 2019 00:37:53 +0100
Subject: Shouldn't no-pinshared be the default?
Message-ID: <CAKQ1sVP+nS3iAG9kv8oUg0DXwxy6L0==1=sEbpP=V_HAe3u4Ww@mail.gmail.com>

Hi,

after quite some time trying to convert Apache httpd (and libapr) to
new the OPENSSL_init/cleanup() 1.1 API, and wondering why openssl libs
would not unload with mod_ssl as before (1.0 and earlier), I found the
ELF NODELETE flag (gcc's -znodelete) and the new (no-)pinshared config
option (though available in 1.1.1 only, not in 1.1.0 AFAICT).

Unfortunately pinshared openssl can't work with the way httpd
dlopen/close()s mod_ssl, which itself initializes and cleans up
openssl, at each restart. Once openssl is cleaned up, it won't
re-initialize due to internal static variables (and it worked so far
in httpd because all the legacy cleanup methods currently used, like
OBJ/EVP/ENGINE_cleanup, are all no-ops now).

IIUC from some previous threads on this list, the new way to cleanup
openssl is to not cleanup (explicitely), which causes issues with some
usages obviously (and is possibly why build time no-pinshared and run
time OPENSSL_INIT_NO_ATEXIT appeared in 1.1.1).

So my question is, why isn't no-pinshared the default?
ISTM that pinshared is enabled on linux only, and linux has
__cxa_atexit semantics for atexit() already, so dlclose() should
already call OPENSSL_cleanup() when needed.
Thus with OPENSSL_INIT_NO_ATEXIT now available the user could choose
at runtime whether (s)he wants to call OPENSSL_cleanup() explicitely
or let openssl clean up by itself.

Of course one can build his/her own openssl with no-pinshared, but I
suppose distros don't, so all software that need to unload openssl
need to build their own one... Another concern is that none of
no-pinshared and OPENSSL_INIT_NO_ATEXIT is available in 1.1.0.

Am I missing something?

Regards,
Yann.

From mcr at sandelman.ca  Tue Mar  5 00:01:11 2019
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 04 Mar 2019 19:01:11 -0500
Subject: version mismatch macro help
Message-ID: <31043.1551744071@localhost>


Last year I tried to provide a macro that would do version checks.
(In fact, I got it wrong in a stupid way)

Today I installed a pre 1.1.1c build in a VM for testing purposes.
What does /usr/sbin/sshd says:

# /usr/sbin/sshd
OpenSSL version mismatch. Built against 1010101f, you have 10101030

Clearly 10101030 >= 1010101f, and the major.minor version match, so there
really shouldn't be an issue.  But openssh seems to have got it wrong, as far
as I can tell.  I will submit a bug report soon.

Can we include a useful macro/test for applications to deal with this
consistently?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190304/9a26256e/attachment.sig>

From norm.green at gemtalksystems.com  Tue Mar  5 04:29:28 2019
From: norm.green at gemtalksystems.com (Norm Green)
Date: Mon, 4 Mar 2019 20:29:28 -0800
Subject: 1.1.1b crash (RUN_ONCE problem?)
In-Reply-To: <20190301195429.GI916@straasha.imrryr.org>
References: <e2114516-464d-6360-cc75-abf659b88700@gemtalksystems.com>
 <20190301195429.GI916@straasha.imrryr.org>
Message-ID: <7037d9a7-2b72-3df5-e51d-50d240e67266@gemtalksystems.com>

Yes I'm sure the build process is correct.
Turns out this problem was cause by one thread calling exit() while 
another thread was doing SSL_write().? The SSL exit handler triggered by 
exit() was causing the lock in question to be freed AFAIKT.
So it would seem that threads either need to exit with pthread_exit() or 
return to a known state such that no SSL calls are in progress in any 
thread before the process can safely exit().


On 3/1/2019 11:54 AM, Viktor Dukhovni wrote:
> On Fri, Mar 01, 2019 at 11:16:52AM -0800, Norm Green wrote:
>
> [ Please avoid non-breaking spaces in your posts. ]
>
>> I'm debugging a failure in a debug build on Solaris SPARC in the below
>> code in rand_lib.c. On line 744, rand_meth_lock is NULL, which suggests
>> the RUN_ONCE code is not working.  Wondering if anyone else has seen
>> this problem?
>> We did not see this issue in 1.1.1a.  Perhaps changes in the RUN_ONCE
>> code in this commit are responsible?
>> https://github.com/openssl/openssl/commit/f725fe5b4b6504df08e30f5194d321c3025e2336
> That PR looks correct, and has no effect on the behaviour of RUN_ONCE
> below.  It only introduces RUN_ONCE_ALT() and uses it in a few
> special cases.
>
>> 741     if (!RUN_ONCE(&rand_init, do_rand_init))
>> 742         return NULL;
>> 743
>> 744     CRYPTO_THREAD_write_lock(rand_meth_lock);
> Are you sure you're compiling linking and running with the desired
> set of headers and libraries?
>


From openssl at foocrypt.net  Tue Mar  5 04:38:32 2019
From: openssl at foocrypt.net (openssl at foocrypt.net)
Date: Tue, 5 Mar 2019 15:38:32 +1100
Subject: Heads up, Inbuilt KORN Arithmetic & Test functions broken under
 Windows Subsystem for Linux
Message-ID: <487B51EA-0129-4CFD-BEC8-DD5203D7775D@foocrypt.net>

Hi

Not sure if any of the build / test  process of OpenSSL utilise inbuilt KORN Arithmetic & Test functions.

https://community.ubuntu.com/t/inbuilt-korn-arithmetic-test-functions-broken-under-windows-subsystem-for-linux/10089 <https://community.ubuntu.com/t/inbuilt-korn-arithmetic-test-functions-broken-under-windows-subsystem-for-linux/10089>




-- 

Regards,

Mark A. Lane   

Cryptopocalypse NOW 01 04 2016

Volumes 0.0 -> 10.0 Now available through iTunes - iBooks @ https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11
? Mark A. Lane 1980 - 2019, All Rights Reserved.
? FooCrypt 1980 - 2019, All Rights Reserved.
? FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2019, All Rights Reserved.
? Cryptopocalypse 1980 - 2019, All Rights Reserved.

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

From openssl-users at dukhovni.org  Tue Mar  5 04:41:36 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 4 Mar 2019 23:41:36 -0500
Subject: 1.1.1b crash (RUN_ONCE problem?)
In-Reply-To: <7037d9a7-2b72-3df5-e51d-50d240e67266@gemtalksystems.com>
References: <e2114516-464d-6360-cc75-abf659b88700@gemtalksystems.com>
 <20190301195429.GI916@straasha.imrryr.org>
 <7037d9a7-2b72-3df5-e51d-50d240e67266@gemtalksystems.com>
Message-ID: <40BB7E4A-A183-4759-BEEB-5510F6765948@dukhovni.org>

> On Mar 4, 2019, at 11:29 PM, Norm Green <norm.green at gemtalksystems.com> wrote:
> 
> Yes I'm sure the build process is correct.
> Turns out this problem was cause by one thread calling exit() while another thread was doing SSL_write().  The SSL exit handler triggered by exit() was causing the lock in question to be freed AFAIKT.
> So it would seem that threads either need to exit with pthread_exit() or return to a known state such that no SSL calls are in progress in any thread before the process can safely exit().

Yes, main() must not exit while threads are running code from
libraries with exit handlers.  This is issue is not unique to
OpenSSL.  I've observed the same problem with threading running
code in MIT's GSSAPI library.

Some users want libraries to be unloadable without memory leaks,
others want safe exit() while threads are running...  Serving
both is hard.

A multi-threaded program that wants to exit before all the
threads are done, should probably call _exit(), and skip
the exit handlers (when none of those are doing anything
critical, like flushing stdio buffers).

Alternatively arrange for a way to ask threads to terminate
promptly, and wait for them to do that.

-- 
-- 
	Viktor.


From matt at openssl.org  Tue Mar  5 11:51:34 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 5 Mar 2019 11:51:34 +0000
Subject: Shouldn't no-pinshared be the default?
In-Reply-To: <CAKQ1sVP+nS3iAG9kv8oUg0DXwxy6L0==1=sEbpP=V_HAe3u4Ww@mail.gmail.com>
References: <CAKQ1sVP+nS3iAG9kv8oUg0DXwxy6L0==1=sEbpP=V_HAe3u4Ww@mail.gmail.com>
Message-ID: <9d99432c-48d8-2db9-c8ce-8ee9a0331418@openssl.org>



On 04/03/2019 23:37, Yann Ylavic wrote:
> So my question is, why isn't no-pinshared the default?
> ISTM that pinshared is enabled on linux only,

That isn't correct. pinshared is the default everywhere. The way it is achieved
is different for different platforms (so on Linux we use -znodelete).

> and linux has
> __cxa_atexit semantics for atexit() already, so dlclose() should
> already call OPENSSL_cleanup() when needed.
> Thus with OPENSSL_INIT_NO_ATEXIT now available the user could choose
> at runtime whether (s)he wants to call OPENSSL_cleanup() explicitely
> or let openssl clean up by itself.

Actually if all platforms behaved like Linux then there would be no need for
pinshared at all. Unfortunately they don't and on some platforms atexit handlers
can get called even after they have been unloaded - which obviously leads to
crashes.

Feasibly we could make no-pinshared the default on platforms where it isn't
really needed (such as Linux). However:

1) This introduces a change of OpenSSL behaviour based on platform - which isn't
ideal for application developers targeting multiple platforms. Not sure how big
a deal this is.

2) The no-pinshared option does not appear in 1.1.1 or 1.1.1a. It first appears
in 1.1.1b. Backporting the option was considered ok. But changing the default
mid-series is probably not a good idea.

Changing the default could be considered for 3.0.

Matt

From ylavic.dev at gmail.com  Tue Mar  5 13:16:10 2019
From: ylavic.dev at gmail.com (Yann Ylavic)
Date: Tue, 5 Mar 2019 14:16:10 +0100
Subject: Shouldn't no-pinshared be the default?
In-Reply-To: <9d99432c-48d8-2db9-c8ce-8ee9a0331418@openssl.org>
References: <CAKQ1sVP+nS3iAG9kv8oUg0DXwxy6L0==1=sEbpP=V_HAe3u4Ww@mail.gmail.com>
 <9d99432c-48d8-2db9-c8ce-8ee9a0331418@openssl.org>
Message-ID: <CAKQ1sVOn28wxAnOBoBysKnU7Y9G5Z815B6X8SEY13se3HmrWDA@mail.gmail.com>

On Tue, Mar 5, 2019 at 12:51 PM Matt Caswell <matt at openssl.org> wrote:
>
> On 04/03/2019 23:37, Yann Ylavic wrote:
> > So my question is, why isn't no-pinshared the default?
> > ISTM that pinshared is enabled on linux only,
>
> That isn't correct. pinshared is the default everywhere. The way it is achieved
> is different for different platforms (so on Linux we use -znodelete).

Yes sorry, I meant -znodelete which, IMHO, is the worst option to keep
openssl loaded, at least double dlopen() can be worked around with
double dlclose(), while -znodelete is cast in stone at (distro-)build
time.
Also the double dlopen() could be opt-in/out at init time (some new
OPENSSL_INIT_[NO_]UNLOAD option), which looks far better for
usability, and with the right compatibility default could possibly
make it to 1.1 :p

>
> > and linux has
> > __cxa_atexit semantics for atexit() already, so dlclose() should
> > already call OPENSSL_cleanup() when needed.
> > Thus with OPENSSL_INIT_NO_ATEXIT now available the user could choose
> > at runtime whether (s)he wants to call OPENSSL_cleanup() explicitely
> > or let openssl clean up by itself.
>
> Actually if all platforms behaved like Linux then there would be no need for
> pinshared at all. Unfortunately they don't and on some platforms atexit handlers
> can get called even after they have been unloaded - which obviously leads to
> crashes.

Sure I understand that, but I think capable platforms shouldn't pay
the penalty, losing unload-ability looks like a serious 1.1 regression
to me.
This also begs the question of atexit() choice for cleanup, and why
there is a cleanup in the first place since it's called only when the
program exits (freeing memory is quite useless there, while
clean(s)ing it or the filesystem or whatever is definitely something
to be done on unload if that needs to happen).
Each system/compiler has probably its own way to run a callback on
dynamic unloading (__attribute__ destructor, #pragma fini, ...), so I
think it could/should be on a case by case basis. But since
OPENSSL_init_{crypto,ssl}/cleanup() is a nice step and now simple
solution for the user to control init/deinit, the poor man's choice of
"do it yourself" would still be better than "you can't do it", IMHO.

>
> Feasibly we could make no-pinshared the default on platforms where it isn't
> really needed (such as Linux). However:
>
> 1) This introduces a change of OpenSSL behaviour based on platform - which isn't
> ideal for application developers targeting multiple platforms. Not sure how big
> a deal this is.

Not sure either, though the current state is not ideal for developers
targeting other (not that insane) usages, which used to work
previously.
As an example, a server couldn't on restart, depending on its
configuration, switch to/from
INIT_{LOAD_CONFIG,ENGINE_*,ASYNC,ZLIB,...}.

>
> 2) The no-pinshared option does not appear in 1.1.1 or 1.1.1a. It first appears
> in 1.1.1b. Backporting the option was considered ok. But changing the default
> mid-series is probably not a good idea.
>
> Changing the default could be considered for 3.0.

Yes please, as it stands the 1.1 series is unloadable on the most used
openssl libraries, distros'. I find this a bit unfortunate, and more
#ifdef-ery to come (though I'd like the OPENSSL_INIT_[NO_]UNLOAD one
:) ).

Regards,
Yann.

From tmraz at redhat.com  Tue Mar  5 13:47:18 2019
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 05 Mar 2019 14:47:18 +0100
Subject: Shouldn't no-pinshared be the default?
In-Reply-To: <CAKQ1sVOn28wxAnOBoBysKnU7Y9G5Z815B6X8SEY13se3HmrWDA@mail.gmail.com>
References: <CAKQ1sVP+nS3iAG9kv8oUg0DXwxy6L0==1=sEbpP=V_HAe3u4Ww@mail.gmail.com>
 <9d99432c-48d8-2db9-c8ce-8ee9a0331418@openssl.org>
 <CAKQ1sVOn28wxAnOBoBysKnU7Y9G5Z815B6X8SEY13se3HmrWDA@mail.gmail.com>
Message-ID: <13647d7c2f67474ce1a7d97be492a2a5c44ce4a5.camel@redhat.com>

On Tue, 2019-03-05 at 14:16 +0100, Yann Ylavic wrote:
> On Tue, Mar 5, 2019 at 12:51 PM Matt Caswell <matt at openssl.org>
> wrote:
> > 
> > 2) The no-pinshared option does not appear in 1.1.1 or 1.1.1a. It
> > first appears
> > in 1.1.1b. Backporting the option was considered ok. But changing
> > the default
> > mid-series is probably not a good idea.
> > 
> > Changing the default could be considered for 3.0.
> 
> Yes please, as it stands the 1.1 series is unloadable on the most
> used
> openssl libraries, distros'. I find this a bit unfortunate, and more
> #ifdef-ery to come (though I'd like the OPENSSL_INIT_[NO_]UNLOAD one
> :) ).

But is it in reality at all possible to explicitly unload OpenSSL?
You're talking here about mod_ssl but what if the OpenSSL is loaded not
just by mod_ssl but by other shared library loaded into the httpd
process - for example libkrb5 or libldap. Then you can see what
disaster can happen if mod_ssl on unload explicitly calls
OpenSSL_cleanup().

The explicit cleanup is thus simply a no-go in distro-wide use of
OpenSSL.

-- 
Tom?? Mr?z
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]



From jb-openssl at wisemo.com  Tue Mar  5 14:59:30 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 5 Mar 2019 15:59:30 +0100
Subject: Shouldn't no-pinshared be the default?
In-Reply-To: <13647d7c2f67474ce1a7d97be492a2a5c44ce4a5.camel@redhat.com>
References: <CAKQ1sVP+nS3iAG9kv8oUg0DXwxy6L0==1=sEbpP=V_HAe3u4Ww@mail.gmail.com>
 <9d99432c-48d8-2db9-c8ce-8ee9a0331418@openssl.org>
 <CAKQ1sVOn28wxAnOBoBysKnU7Y9G5Z815B6X8SEY13se3HmrWDA@mail.gmail.com>
 <13647d7c2f67474ce1a7d97be492a2a5c44ce4a5.camel@redhat.com>
Message-ID: <def31c38-6093-f7de-04eb-5b74d448b3cc@wisemo.com>

On 05/03/2019 14:47, Tomas Mraz wrote:
> On Tue, 2019-03-05 at 14:16 +0100, Yann Ylavic wrote:
>> On Tue, Mar 5, 2019 at 12:51 PM Matt Caswell <matt at openssl.org>
>> wrote:
>>> 2) The no-pinshared option does not appear in 1.1.1 or 1.1.1a. It
>>> first appears
>>> in 1.1.1b. Backporting the option was considered ok. But changing
>>> the default
>>> mid-series is probably not a good idea.
>>>
>>> Changing the default could be considered for 3.0.
>> Yes please, as it stands the 1.1 series is unloadable on the most
>> used
>> openssl libraries, distros'. I find this a bit unfortunate, and more
>> #ifdef-ery to come (though I'd like the OPENSSL_INIT_[NO_]UNLOAD one
>> :) ).
> But is it in reality at all possible to explicitly unload OpenSSL?
> You're talking here about mod_ssl but what if the OpenSSL is loaded not
> just by mod_ssl but by other shared library loaded into the httpd
> process - for example libkrb5 or libldap. Then you can see what
> disaster can happen if mod_ssl on unload explicitly calls
> OpenSSL_cleanup().
>
> The explicit cleanup is thus simply a no-go in distro-wide use of
> OpenSSL.
>

On any system with a shared library concept (perhaps except some
historic abominations), shared library unload reference counting
is already handled by the OS/loader.? Thus any shared library that
cleans itself up when actually unloaded by the OS should just work.

Unfortunately OpenSSL 1.1.x chose to deliberately prevent itself
from being unloaded instead of making an internal abstraction for
the 3 unload scenarios common to all shared library systems:

A. Process is exiting, shared library is being unloaded along
 ? with the rest of the process.
 ? ?? A few resources (such as network sockets and C FILE* objects)
 ? should be graciously cleaned up, memory will be freed unless the
 ? OS is "no-MMU" style (Linux-noMMU, Win32s).? Any threads still
 ? accessing the library will exit very soon too.

B. Shared library is being unloaded before process exit was
 ? requested, all library resources must be cleaned up to avoid
 ? becoming memory leaks. No clients are trying to use the
 ? library, but any long-running library APIs might not have
 ? returned (due to application mistakes or lack of abort APIs).
Threads still accessing the library need to synchronize
 ? their orderly return to callers outside the shared library.
 ?? If OS serialization allows, the library needs to delay
 ? completion of the unload handler until the threads have
 ? left the library.

C. A client application requests cleanup manually.? Shared
 ? libraries accessed by multiple in-process "applications"
 ? (Your example above) will need to sometimes ignore such
 ? requests, static libraries can assume only one caller and
 ? should do the requested cleanup.

About 25 years ago I struggled with another library that did
the same kind of unload-blocking that OpenSSL 1.1.x does.? It
was sad to see a big project like OpenSSL repeat that mistake.

Enjoy

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


From ylavic.dev at gmail.com  Tue Mar  5 15:00:55 2019
From: ylavic.dev at gmail.com (Yann Ylavic)
Date: Tue, 5 Mar 2019 16:00:55 +0100
Subject: Shouldn't no-pinshared be the default?
In-Reply-To: <13647d7c2f67474ce1a7d97be492a2a5c44ce4a5.camel@redhat.com>
References: <CAKQ1sVP+nS3iAG9kv8oUg0DXwxy6L0==1=sEbpP=V_HAe3u4Ww@mail.gmail.com>
 <9d99432c-48d8-2db9-c8ce-8ee9a0331418@openssl.org>
 <CAKQ1sVOn28wxAnOBoBysKnU7Y9G5Z815B6X8SEY13se3HmrWDA@mail.gmail.com>
 <13647d7c2f67474ce1a7d97be492a2a5c44ce4a5.camel@redhat.com>
Message-ID: <CAKQ1sVNjGqT0oR9HbfPWUb2O5YXLz16kma2XqJQgn4M_cyg4Tg@mail.gmail.com>

On Tue, Mar 5, 2019 at 2:47 PM Tomas Mraz <tmraz at redhat.com> wrote:
>
> But is it in reality at all possible to explicitly unload OpenSSL?

Well, I don't want to forcibly unload openssl precisely, I want it to
unload when its refcount reaches zero.

> You're talking here about mod_ssl but what if the OpenSSL is loaded not
> just by mod_ssl but by other shared library loaded into the httpd
> process - for example libkrb5 or libldap. Then you can see what
> disaster can happen if mod_ssl on unload explicitly calls
> OpenSSL_cleanup().

Yes, I don't want to blindly cleanup openssl in mod_ssl either, I want
modules to cooperate on who initializes/cleans-up.
There is no such thing as httpd needing libkrb5 or libldap, modules
may, and the APR library (which httpd [h]e[a]vily relies on) may also
link to openssl and need its init/cleanup.
So my goal is to make the APR library able and responsible to
init/cleanup openssl for httpd and its modules (which is not an easy
thing to do properly from 0.9.8 to latest..., so a single place to do
it well makes sense), based on its lifetime handling mechanism, namely
APR pools.
If openssl is needed by (and for the whole lifetime of) httpd, bind it
to the process pool, if it's needed by module(s) bind it to the
configuration pool and init/cleanup will happen explictely once and
only once at the right time. Modules that cooperate with APR will use
its apr_crypto_lib helpers and trust init/cleanup to be done once and
only once. Modules that don't cooperate with APR (or using libs that
don't) will still OPENSSL_init_*() but it's not an issue (can be
called multiple times), same for OPENSSL_cleanup() although I doubt
one is doing this (besides mod_ssl, which precisely I want to fix).
Anyway modules are effectively unloaded on stop/restart in httpd, and
so are the libs they are linked with, and the next start does not
necessarily requires the same openssl intialization/configuration, but
it should not be an issue provided modules can cooperate. httpd is the
(final-)application which knows here, it's not a lib like openssl or
APR (both of which shouldn't impose their lifetime to their users). So
likewise APR will also have an option to not init/cleanup openssl at
all since it's possibly not the only consumer, but for those who wants
to cooperate fully through APR (like httpd), it's also possible.

>
> The explicit cleanup is thus simply a no-go in distro-wide use of
> OpenSSL.

Why? Distros know better than the applications they run?
Since we are here, why OPENSSL_cleanup() exists and is public in the
first place, and why no-pinshared or OPENSSL_INIT_NO_ATEXIT?


Regards,
Yann.

From levitte at openssl.org  Tue Mar  5 15:42:49 2019
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 05 Mar 2019 16:42:49 +0100
Subject: Shouldn't no-pinshared be the default?
In-Reply-To: <13647d7c2f67474ce1a7d97be492a2a5c44ce4a5.camel@redhat.com>
References: <CAKQ1sVP+nS3iAG9kv8oUg0DXwxy6L0==1=sEbpP=V_HAe3u4Ww@mail.gmail.com>
 <9d99432c-48d8-2db9-c8ce-8ee9a0331418@openssl.org>
 <CAKQ1sVOn28wxAnOBoBysKnU7Y9G5Z815B6X8SEY13se3HmrWDA@mail.gmail.com>
 <13647d7c2f67474ce1a7d97be492a2a5c44ce4a5.camel@redhat.com>
Message-ID: <D5C3742E-1302-4BA2-A765-52F3C967B6BD@openssl.org>



Tomas Mraz <tmraz at redhat.com> skrev: (5 mars 2019 14:47:18 CET)
>On Tue, 2019-03-05 at 14:16 +0100, Yann Ylavic wrote:
>> On Tue, Mar 5, 2019 at 12:51 PM Matt Caswell <matt at openssl.org>
>> wrote:
>> > 
>> > 2) The no-pinshared option does not appear in 1.1.1 or 1.1.1a. It
>> > first appears
>> > in 1.1.1b. Backporting the option was considered ok. But changing
>> > the default
>> > mid-series is probably not a good idea.
>> > 
>> > Changing the default could be considered for 3.0.
>> 
>> Yes please, as it stands the 1.1 series is unloadable on the most
>> used
>> openssl libraries, distros'. I find this a bit unfortunate, and more
>> #ifdef-ery to come (though I'd like the OPENSSL_INIT_[NO_]UNLOAD one
>> :) ).
>
>But is it in reality at all possible to explicitly unload OpenSSL?
>You're talking here about mod_ssl but what if the OpenSSL is loaded not
>just by mod_ssl but by other shared library loaded into the httpd
>process - for example libkrb5 or libldap. Then you can see what
>disaster can happen if mod_ssl on unload explicitly calls
>OpenSSL_cleanup().
>
>The explicit cleanup is thus simply a no-go in distro-wide use of
>OpenSSL.

It sounds like an allocatable library context that could be used to store all the "global" stuff would be a good thing. 
Incidently, we've introduced that concept for 3.0.0. Exactly what will end up in it is not decided, apart from the new provider related stuff. 

Cheers 
Richard 

-- 
Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet.

From zeyuany at gmail.com  Tue Mar  5 16:45:03 2019
From: zeyuany at gmail.com (Zeyuan Yu)
Date: Tue, 5 Mar 2019 10:45:03 -0600
Subject: Duplicate existing SSL_CTX
Message-ID: <CADArNs1prm6hmUbSGtqCC0pQ9v-4qVBzgyv5DpgM-VSci801Ew@mail.gmail.com>

Hi,

I'm working on a cert+key hot reload feature. Wonder if there is a way to
duplicate an existing SSL_CTX?

The idea would be duplicate the context, change the cert and key it is
using, and then swap the pointers to make it atomic.

Regards,
Zeyuan
-- 
[image: work-eat-sleep--400090.jpg]

*Zeyuan Yu*
Software Development Engineer, Verizon Media Group

m: 217.369.5086
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190305/859c3b95/attachment.html>

From tmraz at redhat.com  Tue Mar  5 17:05:32 2019
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 05 Mar 2019 18:05:32 +0100
Subject: Shouldn't no-pinshared be the default?
In-Reply-To: <CAKQ1sVNjGqT0oR9HbfPWUb2O5YXLz16kma2XqJQgn4M_cyg4Tg@mail.gmail.com>
References: <CAKQ1sVP+nS3iAG9kv8oUg0DXwxy6L0==1=sEbpP=V_HAe3u4Ww@mail.gmail.com>
 <9d99432c-48d8-2db9-c8ce-8ee9a0331418@openssl.org>
 <CAKQ1sVOn28wxAnOBoBysKnU7Y9G5Z815B6X8SEY13se3HmrWDA@mail.gmail.com>
 <13647d7c2f67474ce1a7d97be492a2a5c44ce4a5.camel@redhat.com>
 <CAKQ1sVNjGqT0oR9HbfPWUb2O5YXLz16kma2XqJQgn4M_cyg4Tg@mail.gmail.com>
Message-ID: <47eebb02df6999a35480f4be84521f5721b9f506.camel@redhat.com>

On Tue, 2019-03-05 at 16:00 +0100, Yann Ylavic wrote:
> On Tue, Mar 5, 2019 at 2:47 PM Tomas Mraz <tmraz at redhat.com> wrote:
> > 
> Why? Distros know better than the applications they run?

They actually do, because applications cannot really know whats deep in
the chain of loaded shared libraries - for example getpwnam() can load
libnss_ldap which can load libldap which can load libssl. And the
application has no idea about what is your nsswitch.conf config.

> Since we are here, why OPENSSL_cleanup() exists and is public in the
> first place, and why no-pinshared or OPENSSL_INIT_NO_ATEXIT?

Yes, having the public OPENSSL_cleanup() to be anything else than no-op 
is probably a mistake. 

-- 
Tom?? Mr?z
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]



From paul at mad-scientist.net  Tue Mar  5 18:14:29 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Tue, 05 Mar 2019 13:14:29 -0500
Subject: Is there a way to retrieve the certificate from SSL_CTX?
Message-ID: <652a41136e5972a6f8d702ad74103db960b9f192.camel@mad-scientist.net>

I'm trying to write a simple function to dump the expiration date of
the certificates in my SSL_CTX cert store.

I've managed to retrieve and show the CA certificates from the
certificate store, and the certificate chain, but I can't find a method
that retrieves the certificate itself from SSL_CTX.  Is this something
that is retrievable?

E.g., I'm adding my certificate with SSL_CTX_use_certificate(); is
there a way to get it back out?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190305/80ddec59/attachment-0001.html>

From wiml at omnigroup.com  Tue Mar  5 19:28:03 2019
From: wiml at omnigroup.com (Wim Lewis)
Date: Tue, 5 Mar 2019 11:28:03 -0800
Subject: Is there a way to retrieve the certificate from SSL_CTX?
In-Reply-To: <652a41136e5972a6f8d702ad74103db960b9f192.camel@mad-scientist.net>
References: <652a41136e5972a6f8d702ad74103db960b9f192.camel@mad-scientist.net>
Message-ID: <8B6D86A5-8122-4B7B-AC22-0BA49D0352C7@omnigroup.com>

On 5. mar. 2019, at 10:14 f.h., Paul Smith <paul at mad-scientist.net> wrote:
> E.g., I'm adding my certificate with SSL_CTX_use_certificate(); is there a way to get it back out?

Does SSL_CTX_get0_certificate() do what you need?

(The "get0" (vs "get") indicates its reference-counting semantics.)



From paul at mad-scientist.net  Tue Mar  5 20:46:50 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Tue, 05 Mar 2019 15:46:50 -0500
Subject: Is there a way to retrieve the certificate from SSL_CTX?
In-Reply-To: <8B6D86A5-8122-4B7B-AC22-0BA49D0352C7@omnigroup.com>
References: <652a41136e5972a6f8d702ad74103db960b9f192.camel@mad-scientist.net>
 <8B6D86A5-8122-4B7B-AC22-0BA49D0352C7@omnigroup.com>
Message-ID: <8b70b671915fb09be8206c7fff6b328e0d6da1b8.camel@mad-scientist.net>

On Tue, 2019-03-05 at 11:28 -0800, Wim Lewis wrote:
> On 5. mar. 2019, at 10:14 f.h., Paul Smith <paul at mad-scientist.net>
> wrote:
> > E.g., I'm adding my certificate with SSL_CTX_use_certificate(); is
> > there a way to get it back out?
> 
> Does SSL_CTX_get0_certificate() do what you need?

AHA!  That seems to do the trick.  If only it were discussed in a man
page [0], I might have found it... :)

Thanks Wim!


[0] After you pointed me to it I did find it listed in the ssl(7) man
    page, but no info on it.


From ylavic.dev at gmail.com  Tue Mar  5 21:16:49 2019
From: ylavic.dev at gmail.com (Yann Ylavic)
Date: Tue, 5 Mar 2019 22:16:49 +0100
Subject: Shouldn't no-pinshared be the default?
In-Reply-To: <47eebb02df6999a35480f4be84521f5721b9f506.camel@redhat.com>
References: <CAKQ1sVP+nS3iAG9kv8oUg0DXwxy6L0==1=sEbpP=V_HAe3u4Ww@mail.gmail.com>
 <9d99432c-48d8-2db9-c8ce-8ee9a0331418@openssl.org>
 <CAKQ1sVOn28wxAnOBoBysKnU7Y9G5Z815B6X8SEY13se3HmrWDA@mail.gmail.com>
 <13647d7c2f67474ce1a7d97be492a2a5c44ce4a5.camel@redhat.com>
 <CAKQ1sVNjGqT0oR9HbfPWUb2O5YXLz16kma2XqJQgn4M_cyg4Tg@mail.gmail.com>
 <47eebb02df6999a35480f4be84521f5721b9f506.camel@redhat.com>
Message-ID: <CAKQ1sVMtz8UHxET043+O0kKNPajHePBnfsOyDmxukOkFUjnTxA@mail.gmail.com>

On Tue, Mar 5, 2019 at 6:05 PM Tomas Mraz <tmraz at redhat.com> wrote:
>
> On Tue, 2019-03-05 at 16:00 +0100, Yann Ylavic wrote:
> > On Tue, Mar 5, 2019 at 2:47 PM Tomas Mraz <tmraz at redhat.com> wrote:
> > >
> > Why? Distros know better than the applications they run?
>
> They actually do, because applications cannot really know whats deep in
> the chain of loaded shared libraries - for example getpwnam() can load
> libnss_ldap which can load libldap which can load libssl. And the
> application has no idea about what is your nsswitch.conf config.

Who would do that seriously, configure a non-local User for httpd, and
read it (as root) preferably from a remote LDAP??
No, httpd shouldn't be run like this, and httpd developers know it
because they designed the root/main process with no other dependency
than the APR lib (both for portability and security reasons), and I'm
sure distros know it too.

Furthermore, if that scenario were a real use case, it'd mean that
libldap could initialize openssl with no regard to httpd needs,
possibly no-op'ing further OPENSSL_init_*() calls with its own
arbitrary init option (e.g. OPENSSL_INIT_[NO_]LOAD_CONFIG), while the
application really is httpd here (I'm sure openldap uses minimal init,
but since we are talking hypothetically..).

So really, please let standalone applications precisely alone and
choose what's best for them for their lifetime.

>
> > Since we are here, why OPENSSL_cleanup() exists and is public in the
> > first place, and why no-pinshared or OPENSSL_INIT_NO_ATEXIT?
>
> Yes, having the public OPENSSL_cleanup() to be anything else than no-op
> is probably a mistake.

We'll probably agree to disagree here..

Regards,
Yann.

From antiac at gmail.com  Wed Mar  6 08:47:01 2019
From: antiac at gmail.com (Antonio Iacono)
Date: Wed, 6 Mar 2019 09:47:01 +0100
Subject: Add pkcs11 command
Message-ID: <CAPN6PEQ6fzdR-6b-qvG4hZ2MX89mhBjm3UjKfgPZ7thUxxQpLA@mail.gmail.com>

There are some good tools for pkcs11, like pkcs11-tool of the OpenSC
project, but often only need the list of key ids to perform signature
operations with the engine.

I would propose a new pkcs11 command which, for now, only makes the
list of ids and labels of keys present in a token.

I have already prepared a draft in this branch
https://github.com/opensignature/openssl/tree/add-pkcs11-command/apps

Thanks,
Antonio

From levitte at openssl.org  Wed Mar  6 09:34:54 2019
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 06 Mar 2019 10:34:54 +0100
Subject: Add pkcs11 command
In-Reply-To: <CAPN6PEQ6fzdR-6b-qvG4hZ2MX89mhBjm3UjKfgPZ7thUxxQpLA@mail.gmail.com>
References: <CAPN6PEQ6fzdR-6b-qvG4hZ2MX89mhBjm3UjKfgPZ7thUxxQpLA@mail.gmail.com>
Message-ID: <87a7i84a81.wl-levitte@openssl.org>

There is a more generic command to do exactly this sort of thing,
'openssl storeutil', available since OpenSSL 1.1.1.

The pkcs11 backend / engine needs to implement the functionality
required to hook with the OSSL_STORE functionality for storeutil to be
useful.

Cheers,
Richard

On Wed, 06 Mar 2019 09:47:01 +0100,
Antonio Iacono wrote:
> 
> There are some good tools for pkcs11, like pkcs11-tool of the OpenSC
> project, but often only need the list of key ids to perform signature
> operations with the engine.
> 
> I would propose a new pkcs11 command which, for now, only makes the
> list of ids and labels of keys present in a token.
> 
> I have already prepared a draft in this branch
> https://github.com/opensignature/openssl/tree/add-pkcs11-command/apps
> 
> Thanks,
> Antonio
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From janjust at nikhef.nl  Wed Mar  6 09:52:44 2019
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Wed, 6 Mar 2019 10:52:44 +0100
Subject: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter
 field
In-Reply-To: <87o96rvwqw.wl-levitte@openssl.org>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <87o96rvwqw.wl-levitte@openssl.org>
Message-ID: <9233311c-3593-7f12-8d8b-bc216c191ab7@nikhef.nl>

Hi all,

On 04/03/19 10:01, Richard Levitte wrote:
> The format error refers to how the numbers are encoded in the
> certificate.  The best way to see for ourselves is if you can run
> 'openssl asn1parse' on the certificate and show us the sequence that
> contains the notBefore and notAfter time-stamps.  The are seen
> together between the issuer name and the subject name.
>
> As an example, here's the 'openssl asn1parse' output for
> test/testx509.pem:
>
>      : ; openssl asn1parse -i -in test/testx509.pem
>          0:d=0  hl=4 l= 347 cons: SEQUENCE
>          4:d=1  hl=4 l= 262 cons:  SEQUENCE
>          8:d=2  hl=2 l=   1 prim:   INTEGER           :18
>         11:d=2  hl=2 l=  13 cons:   SEQUENCE
>         13:d=3  hl=2 l=   9 prim:    OBJECT            :md5WithRSAEncryption
>         24:d=3  hl=2 l=   0 prim:    NULL
>         26:d=2  hl=2 l=  56 cons:   SEQUENCE
>         28:d=3  hl=2 l=  11 cons:    SET
>         30:d=4  hl=2 l=   9 cons:     SEQUENCE
>         32:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
>         37:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :AU
>         41:d=3  hl=2 l=  12 cons:    SET
>         43:d=4  hl=2 l=  10 cons:     SEQUENCE
>         45:d=5  hl=2 l=   3 prim:      OBJECT            :stateOrProvinceName
>         50:d=5  hl=2 l=   3 prim:      PRINTABLESTRING   :QLD
>         55:d=3  hl=2 l=  27 cons:    SET
>         57:d=4  hl=2 l=  25 cons:     SEQUENCE
>         59:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
>         64:d=5  hl=2 l=  18 prim:      PRINTABLESTRING   :SSLeay/rsa test CA
>         84:d=2  hl=2 l=  30 cons:   SEQUENCE
>         86:d=3  hl=2 l=  13 prim:    UTCTIME           :950619233312Z
>        101:d=3  hl=2 l=  13 prim:    UTCTIME           :950717233312Z
>        116:d=2  hl=2 l=  58 cons:   SEQUENCE
>        118:d=3  hl=2 l=  11 cons:    SET
>        120:d=4  hl=2 l=   9 cons:     SEQUENCE
>        122:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
>        127:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :AU
>        131:d=3  hl=2 l=  12 cons:    SET
>        133:d=4  hl=2 l=  10 cons:     SEQUENCE
>        135:d=5  hl=2 l=   3 prim:      OBJECT            :stateOrProvinceName
>        140:d=5  hl=2 l=   3 prim:      PRINTABLESTRING   :QLD
>        145:d=3  hl=2 l=  29 cons:    SET
>        147:d=4  hl=2 l=  27 cons:     SEQUENCE
>        149:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
>        154:d=5  hl=2 l=  20 prim:      PRINTABLESTRING   :SSLeay/rsa test cert
>        176:d=2  hl=2 l=  92 cons:   SEQUENCE
>        178:d=3  hl=2 l=  13 cons:    SEQUENCE
>        180:d=4  hl=2 l=   9 prim:     OBJECT            :rsaEncryption
>        191:d=4  hl=2 l=   0 prim:     NULL
>        193:d=3  hl=2 l=  75 prim:    BIT STRING
>        270:d=1  hl=2 l=  12 cons:  SEQUENCE
>        272:d=2  hl=2 l=   8 prim:   OBJECT            :md5
>        282:d=2  hl=2 l=   0 prim:   NULL
>        284:d=1  hl=2 l=  65 prim:  BIT STRING
>
> Here, the notBefore and notAfter are the following lines:
>
>         84:d=2  hl=2 l=  30 cons:   SEQUENCE
>         86:d=3  hl=2 l=  13 prim:    UTCTIME           :950619233312Z
>        101:d=3  hl=2 l=  13 prim:    UTCTIME           :950717233312Z
>
> For visualization, this is the text form output of the same:
>
>      : ; openssl x509 -in test/testx509.pem -dates -noout
>      notBefore=Jun 19 23:33:12 1995 GMT
>      notAfter=Jul 17 23:33:12 1995 GMT
>
> So now, for the encoding, RFC5280 has a few things to say
> (https://tools.ietf.org/html/rfc5280#section-4.1.2.5).  However, for
> the dates you display, it should be easy, the should be the following:
>
>      UTCTIME	:091022132829Z
>      UTCTIME	:370308132829Z
>
> If you see something violently different (such as GeneralizedTime
> instead of UTCTIME), or the number of digits being wrong (12 for
> UTCTIME, 14 for GeneralizedTime), or there being something other than
> 'Z' at the end, then you know why you get that error.
>
> (I encoded those numbers manually, so I hope I got them right)
>
> Cheers,
> Richard
>
> On Mon, 04 Mar 2019 09:08:30 +0100,
> Wolfgang Knauf wrote:
>>
>> Hi,
>>
>> I first asked this question in the OpenVPNGui forum, and they redirected me to here: OpenVPNGui
>> 2.4.6 works with a customers server certificate, but it fails when using 2.4.7.
>>
>> Here is the thread in the OpenVPNGui forum: https://forums.openvpn.net/viewtopic.php?f=24&t=27976
>>
>> The error is:
>>
>> Thu Feb 28 08:48:50 2019 VERIFY ERROR: depth=0, error=format error in certificate's notAfter field
>> : C=de, L=Dortmund, O=Versatel, CN=ASG_1, emailAddress=...
>>
>> The certificate has those fields:
>>
>>          Validity
>>
>>              Not Before: Oct 22 13:28:29 2009 GMT
>>
>>              Not After : Mar  8 13:28:29 2037 GMT
>>
>> The customer provided us with a ??..ca.crt? file, a ??.user.crt? file and a ?user.key? file. But I
>> fear it is not smart to post those files in the internet ;-).
>>
>>
as a follow-up:? Richard's analysis/suspicion was spot on.
However, it was the *server* side certificate that was causing the 
error, and the server certificate does indeed contain a poorly formatted 
date:

$ openssl asn1parse -in server.crt | grep UTC
 ? 157:d=3? hl=2 l=? 13 prim: UTCTIME?????????? :091022132829Z
 ? 172:d=3? hl=2 l=? 17 prim: UTCTIME?????????? :370308132808+0000

OpenSSL 1.0.x groks this, 1.1+ does not.

cheers,

JJK / Jan Just Keijser

From levitte at openssl.org  Wed Mar  6 10:06:30 2019
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 06 Mar 2019 11:06:30 +0100
Subject: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter
 field
In-Reply-To: <9233311c-3593-7f12-8d8b-bc216c191ab7@nikhef.nl>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <87o96rvwqw.wl-levitte@openssl.org>
 <9233311c-3593-7f12-8d8b-bc216c191ab7@nikhef.nl>
Message-ID: <878sxs48rd.wl-levitte@openssl.org>

On Wed, 06 Mar 2019 10:52:44 +0100,
Jan Just Keijser wrote:
> as a follow-up:? Richard's analysis/suspicion was spot on.
> However, it was the *server* side certificate that was causing the
> error, and the server certificate does indeed contain a poorly
> formatted date:
> 
> $ openssl asn1parse -in server.crt | grep UTC
> ? 157:d=3? hl=2 l=? 13 prim: UTCTIME?????????? :091022132829Z
> ? 172:d=3? hl=2 l=? 17 prim: UTCTIME?????????? :370308132808+0000

I'm glad I could help find the answer.

> OpenSSL 1.0.x groks this, 1.1+ does not.

Yup, 1.1+ is stricter regarding these things.

Cheers,
Richard

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

From rashok.svks at gmail.com  Wed Mar  6 10:51:14 2019
From: rashok.svks at gmail.com (Raja Ashok)
Date: Wed, 6 Mar 2019 16:21:14 +0530
Subject: DTLSv1_listen Nonblock IO failure not returning SSL_ERROR_WANT_READ
Message-ID: <CADSGPoEScHuCBev+O6QwmWwMS+GCBdWzEoj+RwTJ0bW-q80L4A@mail.gmail.com>

Hi,

When Nonblock IO failure happens on DTLSv1_listen() its returning 0. But
SSL_get_error() is not returning SSL_ERROR_WANT_READ. Instead it
returns SSL_ERROR_SYSCALL.

Can someone tell its intentionally kept this behaviour ?

Thanks & Regards,
Ashok,
Huawei Technologies, India
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190306/70ce25e8/attachment-0001.html>

From matt at openssl.org  Wed Mar  6 10:59:45 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 6 Mar 2019 10:59:45 +0000
Subject: DTLSv1_listen Nonblock IO failure not returning
 SSL_ERROR_WANT_READ
In-Reply-To: <CADSGPoEScHuCBev+O6QwmWwMS+GCBdWzEoj+RwTJ0bW-q80L4A@mail.gmail.com>
References: <CADSGPoEScHuCBev+O6QwmWwMS+GCBdWzEoj+RwTJ0bW-q80L4A@mail.gmail.com>
Message-ID: <832fc5fe-e19e-206f-1129-ec56cf6779c9@openssl.org>



On 06/03/2019 10:51, Raja Ashok wrote:
> Hi,
> 
> When Nonblock IO failure happens on DTLSv1_listen() its returning 0. But
> SSL_get_error() is not returning?SSL_ERROR_WANT_READ. Instead it
> returns?SSL_ERROR_SYSCALL.?
> 
> Can someone tell its intentionally kept this behaviour ?

You are not supposed to call SSL_get_error() after DTLSv1_listen().

See the DTLSv1_listen() documentation here:

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

Matt


From WKnauf at hg-online.de  Wed Mar  6 11:16:04 2019
From: WKnauf at hg-online.de (Wolfgang Knauf)
Date: Wed, 6 Mar 2019 11:16:04 +0000
Subject: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter
 field
In-Reply-To: <878sxs48rd.wl-levitte@openssl.org>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <87o96rvwqw.wl-levitte@openssl.org>
 <9233311c-3593-7f12-8d8b-bc216c191ab7@nikhef.nl>
 <878sxs48rd.wl-levitte@openssl.org>
Message-ID: <AM6PR08MB4181F3E7A30E70123653A0B2F8730@AM6PR08MB4181.eurprd08.prod.outlook.com>

Many thanks to all of you for your help! Sorry for posting those basic questions, but I was helpless - I am just a VPN client user, with not much knowledge of SSL :-(.

I forwarded the problem to our customer. Hopefully, they have more knowledge than me about certificates ;-).

Best regards

Wolfgang

-----Urspr?ngliche Nachricht-----
Von: openssl-users <openssl-users-bounces at openssl.org> Im Auftrag von Richard Levitte
Gesendet: Mittwoch, 6. M?rz 2019 11:07
An: openssl-users at openssl.org
Betreff: Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

On Wed, 06 Mar 2019 10:52:44 +0100,
Jan Just Keijser wrote:
> as a follow-up:? Richard's analysis/suspicion was spot on.
> However, it was the *server* side certificate that was causing the 
> error, and the server certificate does indeed contain a poorly 
> formatted date:
> 
> $ openssl asn1parse -in server.crt | grep UTC
> ? 157:d=3? hl=2 l=? 13 prim: UTCTIME?????????? :091022132829Z
> ? 172:d=3? hl=2 l=? 17 prim: UTCTIME?????????? :370308132808+0000

I'm glad I could help find the answer.

> OpenSSL 1.0.x groks this, 1.1+ does not.

Yup, 1.1+ is stricter regarding these things.

Cheers,
Richard

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

From ylavic.dev at gmail.com  Wed Mar  6 13:25:25 2019
From: ylavic.dev at gmail.com (Yann Ylavic)
Date: Wed, 6 Mar 2019 14:25:25 +0100
Subject: Shouldn't no-pinshared be the default?
In-Reply-To: <CAKQ1sVOn28wxAnOBoBysKnU7Y9G5Z815B6X8SEY13se3HmrWDA@mail.gmail.com>
References: <CAKQ1sVP+nS3iAG9kv8oUg0DXwxy6L0==1=sEbpP=V_HAe3u4Ww@mail.gmail.com>
 <9d99432c-48d8-2db9-c8ce-8ee9a0331418@openssl.org>
 <CAKQ1sVOn28wxAnOBoBysKnU7Y9G5Z815B6X8SEY13se3HmrWDA@mail.gmail.com>
Message-ID: <CAKQ1sVPyaBT1HhHT5GNOpAJKJP658nTbcEw=Grsmg8941Gj4+A@mail.gmail.com>

On Tue, Mar 5, 2019 at 2:16 PM Yann Ylavic <ylavic.dev at gmail.com> wrote:
>
> Also the double dlopen() could be opt-in/out at init time (some new
> OPENSSL_INIT_[NO_]UNLOAD option), which looks far better for
> usability, and with the right compatibility default could possibly
> make it to 1.1 :p

FWIW, I just opened PR #8420 for this..

Regards,
Yann.

From antiac at gmail.com  Wed Mar  6 13:34:32 2019
From: antiac at gmail.com (Antonio Iacono)
Date: Wed, 6 Mar 2019 14:34:32 +0100
Subject: Add pkcs11 command
In-Reply-To: <87a7i84a81.wl-levitte@openssl.org>
References: <CAPN6PEQ6fzdR-6b-qvG4hZ2MX89mhBjm3UjKfgPZ7thUxxQpLA@mail.gmail.com>
 <87a7i84a81.wl-levitte@openssl.org>
Message-ID: <CAPN6PET-ybLvw8ZBidTVzmdRQ35GuXXO3csam8q_tsRzz4QAeQ@mail.gmail.com>

I can write the function inside pkcs11 engine but then how do I "hook"
it to storeutl?

The first obstacle is here "No URI given, nothing to do" but with
pkcs11 I have no URI or File.

Thanks

On Wed, Mar 6, 2019 at 10:35 AM Richard Levitte <levitte at openssl.org> wrote:
>
> There is a more generic command to do exactly this sort of thing,
> 'openssl storeutil', available since OpenSSL 1.1.1.
>
> The pkcs11 backend / engine needs to implement the functionality
> required to hook with the OSSL_STORE functionality for storeutil to be
> useful.
>
> Cheers,
> Richard
>
> On Wed, 06 Mar 2019 09:47:01 +0100,
> Antonio Iacono wrote:
> >
> > There are some good tools for pkcs11, like pkcs11-tool of the OpenSC
> > project, but often only need the list of key ids to perform signature
> > operations with the engine.
> >
> > I would propose a new pkcs11 command which, for now, only makes the
> > list of ids and labels of keys present in a token.
> >
> > I have already prepared a draft in this branch
> > https://github.com/opensignature/openssl/tree/add-pkcs11-command/apps
> >
> > Thanks,
> > Antonio
> >
> --
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/

From antiac at gmail.com  Wed Mar  6 15:01:05 2019
From: antiac at gmail.com (Antonio Iacono)
Date: Wed, 6 Mar 2019 16:01:05 +0100
Subject: Add pkcs11 command
In-Reply-To: <87a7i84a81.wl-levitte@openssl.org>
References: <CAPN6PEQ6fzdR-6b-qvG4hZ2MX89mhBjm3UjKfgPZ7thUxxQpLA@mail.gmail.com>
 <87a7i84a81.wl-levitte@openssl.org>
Message-ID: <CAPN6PERMRP8JiHPiZOCFFnO-J=hBBhnTuH1mZd5j3f6os_NECg@mail.gmail.com>

OSSL_STORE_LOADER_set_open on bind ?

On Wed, Mar 6, 2019 at 10:35 AM Richard Levitte <levitte at openssl.org> wrote:
>
> There is a more generic command to do exactly this sort of thing,
> 'openssl storeutil', available since OpenSSL 1.1.1.
>
> The pkcs11 backend / engine needs to implement the functionality
> required to hook with the OSSL_STORE functionality for storeutil to be
> useful.
>
> Cheers,
> Richard
>
> On Wed, 06 Mar 2019 09:47:01 +0100,
> Antonio Iacono wrote:
> >
> > There are some good tools for pkcs11, like pkcs11-tool of the OpenSC
> > project, but often only need the list of key ids to perform signature
> > operations with the engine.
> >
> > I would propose a new pkcs11 command which, for now, only makes the
> > list of ids and labels of keys present in a token.
> >
> > I have already prepared a draft in this branch
> > https://github.com/opensignature/openssl/tree/add-pkcs11-command/apps
> >
> > Thanks,
> > Antonio
> >
> --
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/

From Michael.Wojcik at microfocus.com  Wed Mar  6 15:17:12 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 6 Mar 2019 15:17:12 +0000
Subject: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter
 field
In-Reply-To: <878sxs48rd.wl-levitte@openssl.org>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <87o96rvwqw.wl-levitte@openssl.org>
 <9233311c-3593-7f12-8d8b-bc216c191ab7@nikhef.nl>
 <878sxs48rd.wl-levitte@openssl.org>
Message-ID: <BN8PR18MB24679760C2C02FAF2468C4A3F9730@BN8PR18MB2467.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Richard Levitte
> Sent: Wednesday, March 06, 2019 03:07
> 
> On Wed, 06 Mar 2019 10:52:44 +0100,
> Jan Just Keijser wrote:
> > as a follow-up:? Richard's analysis/suspicion was spot on.
> > However, it was the *server* side certificate that was causing the
> > error, and the server certificate does indeed contain a poorly
> > formatted date:
> >
> > $ openssl asn1parse -in server.crt | grep UTC
> > ? 157:d=3? hl=2 l=? 13 prim: UTCTIME?????????? :091022132829Z
> > ? 172:d=3? hl=2 l=? 17 prim: UTCTIME?????????? :370308132808+0000
> 
> I'm glad I could help find the answer.
> 
> > OpenSSL 1.0.x groks this, 1.1+ does not.
> 
> Yup, 1.1+ is stricter regarding these things.

I would have expected 1.0.2p and later to have rejected this as well, since the RFC 5280 restrictions on validity date attributes were included in that release. There was some discussion about it on the OpenSSL lists, with some people suggesting that a change to insist on the letter of the standard which broke compatibility with certificates generated by some other implementations was not a great idea. (I am sympathetic to this argument myself, and feel there should at least be an option to relax these restrictions.)

See for example: https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html

It's interesting to note that back in 2009 when GeneralizedTime support for X.509 dates was added to OpenSSL, Erwann Abalea pointed out that RFC 5280 is only a profile of X.509, and X.509 itself allows timezone offsets and fracttional seconds, and so arguably OpenSSL ought to allow them too (presumably for use by non-TLS X.509 applications). (See e.g. http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.) Personally, I find that argument persuasive too, and think that it would be appropriate to have a mechanism to disable the 5280 checks.

Maybe I'll put together a PR, though I don't know if it has much chance of being accepted.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 




From openssl at openssl.org  Wed Mar  6 15:28:20 2019
From: openssl at openssl.org (OpenSSL)
Date: Wed, 6 Mar 2019 15:28:20 +0000
Subject: OpenSSL Security Advisory
Message-ID: <20190306152820.GA15119@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

OpenSSL Security Advisory [6 March 2019]
========================================

ChaCha20-Poly1305 with long nonces (CVE-2019-1543)
==================================================

Severity: Low

ChaCha20-Poly1305 is an AEAD cipher, and requires a unique nonce input for every
encryption operation. RFC 7539 specifies that the nonce value (IV) should be 96
bits (12 bytes). OpenSSL allows a variable nonce length and front pads the nonce
with 0 bytes if it is less than 12 bytes. However it also incorrectly allows a
nonce to be set of up to 16 bytes. In this case only the last 12 bytes are
significant and any additional leading bytes are ignored.

It is a requirement of using this cipher that nonce values are unique. Messages
encrypted using a reused nonce value are susceptible to serious confidentiality
and integrity attacks. If an application changes the default nonce length to be
longer than 12 bytes and then makes a change to the leading bytes of the nonce
expecting the new value to be a new unique nonce then such an application could
inadvertently encrypt messages with a reused nonce.

Additionally the ignored bytes in a long nonce are not covered by the integrity
guarantee of this cipher. Any application that relies on the integrity of these
ignored leading bytes of a long nonce may be further affected.

Any OpenSSL internal use of this cipher, including in SSL/TLS, is safe because
no such use sets such a long nonce value. However user applications that use
this cipher directly and set a non-default nonce length to be longer than 12
bytes may be vulnerable.

OpenSSL versions 1.1.1 and 1.1.0 are affected by this issue. Due to the limited
scope of affected deployments this has been assessed as low severity and
therefore we are not creating new releases at this time. The 1.1.1 mitigation
for this issue can be found in commit f426625b6a. The 1.1.0 mitigation for this
issue can be found in commit ee22257b14.

This issue does not impact OpenSSL 1.0.2.

This issue was discovered by Joran Dirk Greef of Ronomon. The fix was developed
by Matt Caswell from the OpenSSL development team. It was reported to OpenSSL on
26th February 2019.

Note
====

OpenSSL 1.0.2 and 1.1.0 are currently only receiving security updates. Support
for 1.0.2 will end on 31st December 2019. Support for 1.1.0 will end on 11th
September 2019. Users of these versions should upgrade to OpenSSL 1.1.1.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20190306.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlx/5b4ACgkQ2cTSbQ5g
RJEXSwgAgHQkb/CyWdubYozRAeUDBT9o6gt/kgsBwPYBxAV75lRo4qwBxzfkeQ6P
6EUFSzEPhabQOhpnTY4QaqphzG2FAl4BbtDalYN+zPOZxppmH7O8Kje+j+onInDI
O4jbjXLgAlgmf5jw5IyhfxQKcaFbdLtcFGzh1t4rMEhT+ehx8ePnGnklPTjfh4ea
bN+BlM1Fm6Au3i/IJB2I6e8ayxFnTx9mAegPvV/RRYma43Ee/Hpvb6eBaTfTZ9yp
lOp0jG4iViB4r3EP3H/l5oVC9fWCAI0Am+vcLq9PsWl632fc39hDREhPrRMfnOds
40ayI4NwoUu4Z89Qdae1iWEUkgjRgA==
=Aub4
-----END PGP SIGNATURE-----

From uri at ll.mit.edu  Wed Mar  6 15:33:31 2019
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Wed, 6 Mar 2019 15:33:31 +0000
Subject: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter
 field
In-Reply-To: <BN8PR18MB24679760C2C02FAF2468C4A3F9730@BN8PR18MB2467.namprd18.prod.outlook.com>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <87o96rvwqw.wl-levitte@openssl.org>
 <9233311c-3593-7f12-8d8b-bc216c191ab7@nikhef.nl>
 <878sxs48rd.wl-levitte@openssl.org>
 <BN8PR18MB24679760C2C02FAF2468C4A3F9730@BN8PR18MB2467.namprd18.prod.outlook.com>
Message-ID: <FC474B98-398D-41F8-BDDA-CAE0D597A852@ll.mit.edu>

Since OpenSSL is more than just a TLS implementation, I agree with Michael and support relaxing these checks when appropriate.

Regards,
Uri

Sent from my iPhone

On Mar 6, 2019, at 10:22, Michael Wojcik <Michael.Wojcik at microfocus.com> wrote:

>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
>> Richard Levitte
>> Sent: Wednesday, March 06, 2019 03:07
>> 
>> On Wed, 06 Mar 2019 10:52:44 +0100,
>> Jan Just Keijser wrote:
>>> as a follow-up:  Richard's analysis/suspicion was spot on.
>>> However, it was the *server* side certificate that was causing the
>>> error, and the server certificate does indeed contain a poorly
>>> formatted date:
>>> 
>>> $ openssl asn1parse -in server.crt | grep UTC
>>>   157:d=3  hl=2 l=  13 prim: UTCTIME           :091022132829Z
>>>   172:d=3  hl=2 l=  17 prim: UTCTIME           :370308132808+0000
>> 
>> I'm glad I could help find the answer.
>> 
>>> OpenSSL 1.0.x groks this, 1.1+ does not.
>> 
>> Yup, 1.1+ is stricter regarding these things.
> 
> I would have expected 1.0.2p and later to have rejected this as well, since the RFC 5280 restrictions on validity date attributes were included in that release. There was some discussion about it on the OpenSSL lists, with some people suggesting that a change to insist on the letter of the standard which broke compatibility with certificates generated by some other implementations was not a great idea. (I am sympathetic to this argument myself, and feel there should at least be an option to relax these restrictions.)
> 
> See for example: https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html
> 
> It's interesting to note that back in 2009 when GeneralizedTime support for X.509 dates was added to OpenSSL, Erwann Abalea pointed out that RFC 5280 is only a profile of X.509, and X.509 itself allows timezone offsets and fracttional seconds, and so arguably OpenSSL ought to allow them too (presumably for use by non-TLS X.509 applications). (See e.g. http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.) Personally, I find that argument persuasive too, and think that it would be appropriate to have a mechanism to disable the 5280 checks.
> 
> Maybe I'll put together a PR, though I don't know if it has much chance of being accepted.
> 
> -- 
> Michael Wojcik 
> Distinguished Engineer, Micro Focus 
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5801 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190306/5a335f42/attachment.bin>

From levitte at openssl.org  Wed Mar  6 15:35:18 2019
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 06 Mar 2019 16:35:18 +0100
Subject: Add pkcs11 command
In-Reply-To: <CAPN6PERMRP8JiHPiZOCFFnO-J=hBBhnTuH1mZd5j3f6os_NECg@mail.gmail.com>
References: <CAPN6PEQ6fzdR-6b-qvG4hZ2MX89mhBjm3UjKfgPZ7thUxxQpLA@mail.gmail.com>
 <87a7i84a81.wl-levitte@openssl.org>
 <CAPN6PERMRP8JiHPiZOCFFnO-J=hBBhnTuH1mZd5j3f6os_NECg@mail.gmail.com>
Message-ID: <871s3k3tjd.wl-levitte@openssl.org>

Not only.

What you need to do on bind is to create a whole OSSL_STORE_LOADER for
pkcs11.  OSSL_STORE_LOADER_set_open only sets the opening functions,
which is expected to take a URI and parse that into something
sensible, and return a context.  There are other functions to set as
well, such as the 'load', 'eof', 'error' and 'close' functions.

The OSSL_STORE_LOADER callback set is designed to work somewhat
vaguely like the stdio API, but instead of handling a set of bytes, it
handles a set of objects, which can be whatever the OSSL_STORE API
knows how to handle.

When you're done building the OSSL_STORE_LOADER (including a scheme
name, that's absolutely important), you hook it into libcrypto with
OSSL_STORE_register_loader(), an voil?, you should be able to do this:

    openssl storeutil -engine yourengine \
        'pkcs11:token=yourtoken;object=my-certificate;objecttype=cert;id=1234'

(I'm sorry, I don't know the URI scheme enough to say how to specify
that you want to get a list of all accessible certificates or other
objects)

There is the manual OSSL_STORE_LOADER(3) found in doc/man3/OSSL_STORE_LOADER.pod,
and the 'file:' scheme loader is in crypto/store/loader_file.c, but
fair warning, that one is a bit more complex than you would probably
expect from the average store loader.

Cheers,
Richard

On Wed, 06 Mar 2019 16:01:05 +0100,
Antonio Iacono wrote:
> 
> OSSL_STORE_LOADER_set_open on bind ?
> 
> On Wed, Mar 6, 2019 at 10:35 AM Richard Levitte <levitte at openssl.org> wrote:
> >
> > There is a more generic command to do exactly this sort of thing,
> > 'openssl storeutil', available since OpenSSL 1.1.1.
> >
> > The pkcs11 backend / engine needs to implement the functionality
> > required to hook with the OSSL_STORE functionality for storeutil to be
> > useful.
> >
> > Cheers,
> > Richard
> >
> > On Wed, 06 Mar 2019 09:47:01 +0100,
> > Antonio Iacono wrote:
> > >
> > > There are some good tools for pkcs11, like pkcs11-tool of the OpenSC
> > > project, but often only need the list of key ids to perform signature
> > > operations with the engine.
> > >
> > > I would propose a new pkcs11 command which, for now, only makes the
> > > list of ids and labels of keys present in a token.
> > >
> > > I have already prepared a draft in this branch
> > > https://github.com/opensignature/openssl/tree/add-pkcs11-command/apps
> > >
> > > Thanks,
> > > Antonio
> > >
> > --
> > Richard Levitte         levitte at openssl.org
> > OpenSSL Project         http://www.openssl.org/~levitte/
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From jb-openssl at wisemo.com  Wed Mar  6 15:36:42 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 6 Mar 2019 16:36:42 +0100
Subject: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter
 field
In-Reply-To: <BN8PR18MB24679760C2C02FAF2468C4A3F9730@BN8PR18MB2467.namprd18.prod.outlook.com>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <87o96rvwqw.wl-levitte@openssl.org>
 <9233311c-3593-7f12-8d8b-bc216c191ab7@nikhef.nl>
 <878sxs48rd.wl-levitte@openssl.org>
 <BN8PR18MB24679760C2C02FAF2468C4A3F9730@BN8PR18MB2467.namprd18.prod.outlook.com>
Message-ID: <76e471b9-ef62-427d-8bd2-3b574bd75ee0@wisemo.com>

On 06/03/2019 16:17, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
>> Richard Levitte
>> Sent: Wednesday, March 06, 2019 03:07
>>
>> On Wed, 06 Mar 2019 10:52:44 +0100,
>> Jan Just Keijser wrote:
>>> as a follow-up:? Richard's analysis/suspicion was spot on.
>>> However, it was the *server* side certificate that was causing the
>>> error, and the server certificate does indeed contain a poorly
>>> formatted date:
>>>
>>> $ openssl asn1parse -in server.crt | grep UTC
>>>  ? 157:d=3? hl=2 l=? 13 prim: UTCTIME?????????? :091022132829Z
>>>  ? 172:d=3? hl=2 l=? 17 prim: UTCTIME?????????? :370308132808+0000
>> I'm glad I could help find the answer.
>>
>>> OpenSSL 1.0.x groks this, 1.1+ does not.
>> Yup, 1.1+ is stricter regarding these things.
> I would have expected 1.0.2p and later to have rejected this as well, since the RFC 5280 restrictions on validity date attributes were included in that release. There was some discussion about it on the OpenSSL lists, with some people suggesting that a change to insist on the letter of the standard which broke compatibility with certificates generated by some other implementations was not a great idea. (I am sympathetic to this argument myself, and feel there should at least be an option to relax these restrictions.)
>
> See for example: https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html
>
> It's interesting to note that back in 2009 when GeneralizedTime support for X.509 dates was added to OpenSSL, Erwann Abalea pointed out that RFC 5280 is only a profile of X.509, and X.509 itself allows timezone offsets and fracttional seconds, and so arguably OpenSSL ought to allow them too (presumably for use by non-TLS X.509 applications). (See e.g. http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.) Personally, I find that argument persuasive too, and think that it would be appropriate to have a mechanism to disable the 5280 checks.
>
> Maybe I'll put together a PR, though I don't know if it has much chance of being accepted.
>

RFC5280 etc. is not even a requirement for SSL/TLS (it certainly
can't be for SSL versions before it), only for the publicly
trusted certificates used on the global Internet.? So arguably,
it should not apply to running TLS between closely related
parties (as is the traditional use case for something
like OpenVPN).

Running a private protocol over TLS between my server in one
building and my server in another building doesn't involve
the WebPKI.

It is of cause prudent for libraries to produce RFC5280
compliant certificates by default, and for test tools
(such as the "openssl x509" and "openssl validate"
commands) to warn when a certificate is outside the
standards for public certificates.

Enjoy

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


From openssl at jordan.maileater.net  Wed Mar  6 17:38:03 2019
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Wed, 6 Mar 2019 17:38:03 +0000
Subject: Shouldn't no-pinshared be the default?
In-Reply-To: <CAKQ1sVMtz8UHxET043+O0kKNPajHePBnfsOyDmxukOkFUjnTxA@mail.gmail.com>
References: <CAKQ1sVP+nS3iAG9kv8oUg0DXwxy6L0==1=sEbpP=V_HAe3u4Ww@mail.gmail.com>
 <9d99432c-48d8-2db9-c8ce-8ee9a0331418@openssl.org>
 <CAKQ1sVOn28wxAnOBoBysKnU7Y9G5Z815B6X8SEY13se3HmrWDA@mail.gmail.com>
 <13647d7c2f67474ce1a7d97be492a2a5c44ce4a5.camel@redhat.com>
 <CAKQ1sVNjGqT0oR9HbfPWUb2O5YXLz16kma2XqJQgn4M_cyg4Tg@mail.gmail.com>
 <47eebb02df6999a35480f4be84521f5721b9f506.camel@redhat.com>
 <CAKQ1sVMtz8UHxET043+O0kKNPajHePBnfsOyDmxukOkFUjnTxA@mail.gmail.com>
Message-ID: <01010169541568ea-aae4aad8-c71b-42a8-aab2-3853e91c1d98-000000@us-west-2.amazonses.com>

On 3/5/2019 1:16 PM, Yann Ylavic wrote:
> Furthermore, if that scenario were a real use case, it'd mean that
> libldap could initialize openssl with no regard to httpd needs,


Everybody has to play nice, but ... yes.? Random libraries might need
OpenSSL for their own reasons, and the application cannot predict which
libraries might need it or what those reasons might be.? OpenSSL must be
designed to be used by multiple non-coordinated components running in
the same process, including by dynamically loaded and unloaded shared
objects.

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

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

From jb-openssl at wisemo.com  Wed Mar  6 18:38:49 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 6 Mar 2019 19:38:49 +0100
Subject: Shouldn't no-pinshared be the default?
In-Reply-To: <01010169541568ea-aae4aad8-c71b-42a8-aab2-3853e91c1d98-000000@us-west-2.amazonses.com>
References: <CAKQ1sVP+nS3iAG9kv8oUg0DXwxy6L0==1=sEbpP=V_HAe3u4Ww@mail.gmail.com>
 <9d99432c-48d8-2db9-c8ce-8ee9a0331418@openssl.org>
 <CAKQ1sVOn28wxAnOBoBysKnU7Y9G5Z815B6X8SEY13se3HmrWDA@mail.gmail.com>
 <13647d7c2f67474ce1a7d97be492a2a5c44ce4a5.camel@redhat.com>
 <CAKQ1sVNjGqT0oR9HbfPWUb2O5YXLz16kma2XqJQgn4M_cyg4Tg@mail.gmail.com>
 <47eebb02df6999a35480f4be84521f5721b9f506.camel@redhat.com>
 <CAKQ1sVMtz8UHxET043+O0kKNPajHePBnfsOyDmxukOkFUjnTxA@mail.gmail.com>
 <01010169541568ea-aae4aad8-c71b-42a8-aab2-3853e91c1d98-000000@us-west-2.amazonses.com>
Message-ID: <2f0d77a8-10b6-4f1d-760c-1a4fc5512eb0@wisemo.com>

On 06/03/2019 18:38, Jordan Brown wrote:
> On 3/5/2019 1:16 PM, Yann Ylavic wrote:
>> Furthermore, if that scenario were a real use case, it'd mean that
>> libldap could initialize openssl with no regard to httpd needs,
>
>
> Everybody has to play nice, but ... yes.? Random libraries might need 
> OpenSSL for their own reasons, and the application cannot predict 
> which libraries might need it or what those reasons might be.? OpenSSL 
> must be designed to be used by multiple non-coordinated components 
> running in the same process, including by dynamically loaded and 
> unloaded shared objects.
>
Which is why using the reference count already kept by the OS
loader is such a nice solution.


Enjoy

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


From janjust at nikhef.nl  Thu Mar  7 07:29:59 2019
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Thu, 7 Mar 2019 08:29:59 +0100
Subject: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter
 field
In-Reply-To: <76e471b9-ef62-427d-8bd2-3b574bd75ee0@wisemo.com>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <87o96rvwqw.wl-levitte@openssl.org>
 <9233311c-3593-7f12-8d8b-bc216c191ab7@nikhef.nl>
 <878sxs48rd.wl-levitte@openssl.org>
 <BN8PR18MB24679760C2C02FAF2468C4A3F9730@BN8PR18MB2467.namprd18.prod.outlook.com>
 <76e471b9-ef62-427d-8bd2-3b574bd75ee0@wisemo.com>
Message-ID: <561f22a1-4d12-4b66-1605-c3d63ed1591d@nikhef.nl>

Hi all,

On 06/03/19 16:36, Jakob Bohm via openssl-users wrote:
> On 06/03/2019 16:17, Michael Wojcik wrote:
>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
>>> Behalf Of
>>> Richard Levitte
>>> Sent: Wednesday, March 06, 2019 03:07
>>>
>>> On Wed, 06 Mar 2019 10:52:44 +0100,
>>> Jan Just Keijser wrote:
>>>> as a follow-up:? Richard's analysis/suspicion was spot on.
>>>> However, it was the *server* side certificate that was causing the
>>>> error, and the server certificate does indeed contain a poorly
>>>> formatted date:
>>>>
>>>> $ openssl asn1parse -in server.crt | grep UTC
>>>> ?? 157:d=3? hl=2 l=? 13 prim: UTCTIME :091022132829Z
>>>> ?? 172:d=3? hl=2 l=? 17 prim: UTCTIME :370308132808+0000
>>> I'm glad I could help find the answer.
>>>
>>>> OpenSSL 1.0.x groks this, 1.1+ does not.
>>> Yup, 1.1+ is stricter regarding these things.
>> I would have expected 1.0.2p and later to have rejected this as well, 
>> since the RFC 5280 restrictions on validity date attributes were 
>> included in that release. There was some discussion about it on the 
>> OpenSSL lists, with some people suggesting that a change to insist on 
>> the letter of the standard which broke compatibility with 
>> certificates generated by some other implementations was not a great 
>> idea. (I am sympathetic to this argument myself, and feel there 
>> should at least be an option to relax these restrictions.)
>>
>> See for example: 
>> https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html
>>
>> It's interesting to note that back in 2009 when GeneralizedTime 
>> support for X.509 dates was added to OpenSSL, Erwann Abalea pointed 
>> out that RFC 5280 is only a profile of X.509, and X.509 itself allows 
>> timezone offsets and fracttional seconds, and so arguably OpenSSL 
>> ought to allow them too (presumably for use by non-TLS X.509 
>> applications). (See e.g. 
>> http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.) 
>> Personally, I find that argument persuasive too, and think that it 
>> would be appropriate to have a mechanism to disable the 5280 checks.
>>
>> Maybe I'll put together a PR, though I don't know if it has much 
>> chance of being accepted.
>>
>
> RFC5280 etc. is not even a requirement for SSL/TLS (it certainly
> can't be for SSL versions before it), only for the publicly
> trusted certificates used on the global Internet.? So arguably,
> it should not apply to running TLS between closely related
> parties (as is the traditional use case for something
> like OpenVPN).
>
> Running a private protocol over TLS between my server in one
> building and my server in another building doesn't involve
> the WebPKI.
>
> It is of cause prudent for libraries to produce RFC5280
> compliant certificates by default, and for test tools
> (such as the "openssl x509" and "openssl validate"
> commands) to warn when a certificate is outside the
> standards for public certificates.
>
so to recapitulate:
- OpenSSL 1.1+ (and possible 1.0.2<X>) introduced stricter RFC5280 
checks when doing certificate validation
- This causes certificates that contain fields that are not fully 
RFC5280 compliant to fail validation
- However, as Jakob states, there is no requirement in TLS for RFC5280 
compliance

Should this be considered a bug in OpenSSL then? If this is not 
considered a bug, shouldn't OpenSSL then state this as a requirement for 
certificate creaton?

Of course, the easy solution is to tell people to create and use RFC5280 
compliant certificates, but what if someone has a legitimate use case 
for not being able or wanting to do so?
Is there a way to loosen the verification checks (apart from writing a 
custom verify_callback) ?

thanks for any advice,

JJK / Jan Just Keijser

From Erwann.Abalea at docusign.com  Thu Mar  7 10:35:10 2019
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Thu, 7 Mar 2019 10:35:10 +0000
Subject: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter
 field
In-Reply-To: <76e471b9-ef62-427d-8bd2-3b574bd75ee0@wisemo.com>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <87o96rvwqw.wl-levitte@openssl.org>
 <9233311c-3593-7f12-8d8b-bc216c191ab7@nikhef.nl>
 <878sxs48rd.wl-levitte@openssl.org>
 <BN8PR18MB24679760C2C02FAF2468C4A3F9730@BN8PR18MB2467.namprd18.prod.outlook.com>
 <76e471b9-ef62-427d-8bd2-3b574bd75ee0@wisemo.com>
Message-ID: <6FBFEE27-1C5D-4134-A43B-1C226E0357C9@docusign.com>

Bonjour,

Here, reject the certificate is the correct behaviour, IMO.

UTCTime/GeneralizedTime are defined in X.680.

UTCTime:
 - can have no timezone information, or have Z, of have a timezone offset (with hours and minutes)
 - can be precise up to the second, or be precise up to the minute
 - cannot have fractional seconds or minutes
 - cannot have second 60 (think of leap seconds) 
 - is not subject to ISO8601 rules

GeneralizedTime:
 - can have no timezone information, or have Z, of have a timezone offset (either hours, or hours and minutes)
 - can be precise up to the second with optional fractional seconds, or be precise up to the minute and have fractional minutes, or be precise up to the hour and have fractional hours (any number of decimal places)
 - shall follow ISO8601 rules (including leap seconds)
 - cannot support the "midnight at end of day" (240000)


DER encoding (X.690) of these elements have of course stricter requirements:
 - the timezone shall be present and consist of Zulu time (Z), for UTC
 - the date/time shall be precise up to the second
 - if any fractional second is present, any trailing zero shall be omitted, and if there is no more decimal place, the trailing dot shall also be omitted

So in this case, the UTCTIME element containing "370308132808+0000" is not a valid DER encoding. That's not an RFC5280/X.509 difference.

There was a debate wether the tbsCertificate shall always be DER encoded or can be BER encoded and have the signature match the DER encoding, but it was closed from the ITU-T point of view in 1997 and first edition of X.509v3, by defining the SIGNED{} and SIGNATURE{} parameterized types and have additional text describing precisely the behaviour to adopt as a sender and receiver (first in clause 9, then moved to clause 6.1 in 2000, and clause 6.4 in 2012).
RFC5280 is far from being that clear.


OpenSSL added some checks on GeneralizedTime/UTCTime, by enforcing RFC5280 rules. I haven't followed the source code to see if these checks also apply to data types other than RFC5280 certificates (RFC5652 CMS signingTime attribute, RFC3161 timestamps, RFC6960 OCSP responses, ...). I remember having debated regarding the support of leap seconds on GitHub, and it seems that second 60 is not supported at all (even if for a certified/qualiied timestamping service, that second can exist and is supposed to be produced).


Cordialement,
Erwann Abalea

?Le 06/03/2019 16:38, ? openssl-users au nom de Jakob Bohm via openssl-users ? <openssl-users-bounces at openssl.org au nom de openssl-users at openssl.org> a ?crit :

    On 06/03/2019 16:17, Michael Wojcik wrote:
    >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
    >> Richard Levitte
    >> Sent: Wednesday, March 06, 2019 03:07
    >>
    >> On Wed, 06 Mar 2019 10:52:44 +0100,
    >> Jan Just Keijser wrote:
    >>> as a follow-up:  Richard's analysis/suspicion was spot on.
    >>> However, it was the *server* side certificate that was causing the
    >>> error, and the server certificate does indeed contain a poorly
    >>> formatted date:
    >>>
    >>> $ openssl asn1parse -in server.crt | grep UTC
    >>>    157:d=3  hl=2 l=  13 prim: UTCTIME           :091022132829Z
    >>>    172:d=3  hl=2 l=  17 prim: UTCTIME           :370308132808+0000
    >> I'm glad I could help find the answer.
    >>
    >>> OpenSSL 1.0.x groks this, 1.1+ does not.
    >> Yup, 1.1+ is stricter regarding these things.
    > I would have expected 1.0.2p and later to have rejected this as well, since the RFC 5280 restrictions on validity date attributes were included in that release. There was some discussion about it on the OpenSSL lists, with some people suggesting that a change to insist on the letter of the standard which broke compatibility with certificates generated by some other implementations was not a great idea. (I am sympathetic to this argument myself, and feel there should at least be an option to relax these restrictions.)
    >
    > See for example: https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html
    >
    > It's interesting to note that back in 2009 when GeneralizedTime support for X.509 dates was added to OpenSSL, Erwann Abalea pointed out that RFC 5280 is only a profile of X.509, and X.509 itself allows timezone offsets and fracttional seconds, and so arguably OpenSSL ought to allow them too (presumably for use by non-TLS X.509 applications). (See e.g. http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.) Personally, I find that argument persuasive too, and think that it would be appropriate to have a mechanism to disable the 5280 checks.
    >
    > Maybe I'll put together a PR, though I don't know if it has much chance of being accepted.
    >
    
    RFC5280 etc. is not even a requirement for SSL/TLS (it certainly
    can't be for SSL versions before it), only for the publicly
    trusted certificates used on the global Internet.  So arguably,
    it should not apply to running TLS between closely related
    parties (as is the traditional use case for something
    like OpenVPN).
    
    Running a private protocol over TLS between my server in one
    building and my server in another building doesn't involve
    the WebPKI.
    
    It is of cause prudent for libraries to produce RFC5280
    compliant certificates by default, and for test tools
    (such as the "openssl x509" and "openssl validate"
    commands) to warn when a certificate is outside the
    standards for public certificates.
    
    Enjoy
    
    Jakob
    -- 
    Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
    Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
    This public discussion message is non-binding and may contain errors.
    WiseMo - Remote Service Management for PCs, Phones and Embedded
    
    


From janjust at nikhef.nl  Fri Mar  8 13:30:40 2019
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Fri, 8 Mar 2019 14:30:40 +0100
Subject: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter
 field
In-Reply-To: <6FBFEE27-1C5D-4134-A43B-1C226E0357C9@docusign.com>
References: <AM0PR08MB4177E898356920A5619F91AAF8710@AM0PR08MB4177.eurprd08.prod.outlook.com>
 <87o96rvwqw.wl-levitte@openssl.org>
 <9233311c-3593-7f12-8d8b-bc216c191ab7@nikhef.nl>
 <878sxs48rd.wl-levitte@openssl.org>
 <BN8PR18MB24679760C2C02FAF2468C4A3F9730@BN8PR18MB2467.namprd18.prod.outlook.com>
 <76e471b9-ef62-427d-8bd2-3b574bd75ee0@wisemo.com>
 <6FBFEE27-1C5D-4134-A43B-1C226E0357C9@docusign.com>
Message-ID: <ad36c0b3-f0f7-99a4-e207-8d43c688d77c@nikhef.nl>

Hi Erwann,

On 07/03/19 11:35, Erwann Abalea via openssl-users wrote:
> Bonjour,
>
> Here, reject the certificate is the correct behaviour, IMO.
>
> UTCTime/GeneralizedTime are defined in X.680.
>
> UTCTime:
>   - can have no timezone information, or have Z, of have a timezone offset (with hours and minutes)
>   - can be precise up to the second, or be precise up to the minute
>   - cannot have fractional seconds or minutes
>   - cannot have second 60 (think of leap seconds)
>   - is not subject to ISO8601 rules
>
> GeneralizedTime:
>   - can have no timezone information, or have Z, of have a timezone offset (either hours, or hours and minutes)
>   - can be precise up to the second with optional fractional seconds, or be precise up to the minute and have fractional minutes, or be precise up to the hour and have fractional hours (any number of decimal places)
>   - shall follow ISO8601 rules (including leap seconds)
>   - cannot support the "midnight at end of day" (240000)
>

thanks for the clarification and note that either way it's fine with me 
- I just wanted to know what message to tell to OpenVPN users who run 
into this issue. The 'correct' answer seems to be:

"Your certificate is invalid and was always invalid, but up til now 
OpenSSL grokked it.? OpenSSL (and therefore OpenVPN) no longer likes 
your cert, so get a new one"

cheers,

JJK / Jan Just Keijser


From antiac at gmail.com  Fri Mar  8 23:35:31 2019
From: antiac at gmail.com (Antonio Iacono)
Date: Sat, 9 Mar 2019 00:35:31 +0100
Subject: Add pkcs11 command
In-Reply-To: <871s3k3tjd.wl-levitte@openssl.org>
References: <CAPN6PEQ6fzdR-6b-qvG4hZ2MX89mhBjm3UjKfgPZ7thUxxQpLA@mail.gmail.com>
 <87a7i84a81.wl-levitte@openssl.org>
 <CAPN6PERMRP8JiHPiZOCFFnO-J=hBBhnTuH1mZd5j3f6os_NECg@mail.gmail.com>
 <871s3k3tjd.wl-levitte@openssl.org>
Message-ID: <CAPN6PERMwCEUtWo4jq0cmE0jjBy=rjx2HS0n1QJTz_J_gz0_dw@mail.gmail.com>

OK thanks,

initial implementation of STORE into my pkcs11 engine (1) is ready.
I am able to do this openssl storeutl -engine pkcs11
'pkcs11:objecttype=cert;object=test'
and this is result:
engine "pkcs11" set.
0: Certificate
-----BEGIN CERTIFICATE-----
MIIC/DCCAeSgAwIBAgIUDrAyYf/dMsavGGEuYMLqJxFrHOUwDQYJKoZIhvcNAQEL
...

(1) https://github.com/openssl/openssl/pull/8200


On Wed, Mar 6, 2019 at 4:37 PM Richard Levitte <levitte at openssl.org> wrote:
> What you need to do on bind is to create a whole OSSL_STORE_LOADER for
> pkcs11.  OSSL_STORE_LOADER_set_open only sets the opening functions,
> which is expected to take a URI and parse that into something
> sensible, and return a context.  There are other functions to set as
> well, such as the 'load', 'eof', 'error' and 'close' functions.
>
> The OSSL_STORE_LOADER callback set is designed to work somewhat
> vaguely like the stdio API, but instead of handling a set of bytes, it
> handles a set of objects, which can be whatever the OSSL_STORE API
> knows how to handle.
>
> When you're done building the OSSL_STORE_LOADER (including a scheme
> name, that's absolutely important), you hook it into libcrypto with
> OSSL_STORE_register_loader(), an voil?, you should be able to do this:
>
>     openssl storeutil -engine yourengine \
>         'pkcs11:token=yourtoken;object=my-certificate;objecttype=cert;id=1234'
>
> (I'm sorry, I don't know the URI scheme enough to say how to specify
> that you want to get a list of all accessible certificates or other
> objects)
>
> There is the manual OSSL_STORE_LOADER(3) found in doc/man3/OSSL_STORE_LOADER.pod,
> and the 'file:' scheme loader is in crypto/store/loader_file.c, but
> fair warning, that one is a bit more complex than you would probably
> expect from the average store loader.
>
> Cheers,
> Richard
>

From win_i008 at yahoo.com  Mon Mar 11 03:48:16 2019
From: win_i008 at yahoo.com (Vinay Kumar)
Date: Mon, 11 Mar 2019 03:48:16 +0000 (UTC)
Subject: OpenSSL 1.1.1b version chooses wrong AS(assembler) on Windows
References: <250732409.3261423.1552276096416.ref@mail.yahoo.com>
Message-ID: <250732409.3261423.1552276096416@mail.yahoo.com>

Hi All,

The OpenSSL version 1.1.1b chooses wrong AS(assembler) on running through Cygwin in Windows. It chooses 'ml' instead of 'nasm'(but uses the syntax of nasm) which causes OpenSSL build failure on Windows. The same works fine with OpenSSL 1.1.0i version.
Looks like a bug with 1.1.1b version.
Setting 'AS=nasm' before running the configure script in the Cygwin shell resolves the problem.
Can someone please confirm if the above workaround is acceptable and can be logged as bug in OpenSSL 1.1.1b version?
Regards,Vinay

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

From levitte at openssl.org  Mon Mar 11 05:43:34 2019
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 11 Mar 2019 06:43:34 +0100
Subject: OpenSSL 1.1.1b version chooses wrong AS(assembler) on Windows
In-Reply-To: <250732409.3261423.1552276096416@mail.yahoo.com>
References: <250732409.3261423.1552276096416.ref@mail.yahoo.com>
 <250732409.3261423.1552276096416@mail.yahoo.com>
Message-ID: <87h8ca2cft.wl-levitte@openssl.org>

With the default configuration, I see it using the C compiler...  how
did you configure OpenSSL?

Cheers,
Richard

On Mon, 11 Mar 2019 04:48:16 +0100,
Vinay Kumar via openssl-users wrote:
> 
> 
> Hi All,
> 
> The OpenSSL version 1.1.1b chooses wrong AS(assembler) on running through Cygwin in Windows. It
> chooses 'ml' instead of 'nasm'(but uses the syntax of nasm) which causes OpenSSL build failure on
> Windows. The same works fine with OpenSSL 1.1.0i version.
> Looks like a bug with 1.1.1b version.
> Setting 'AS=nasm' before running the configure script in the Cygwin shell resolves the problem.
> Can someone please confirm if the above workaround is acceptable and can be logged as bug in
> OpenSSL 1.1.1b version?
> 
> Regards,
> Vinay
> 
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From beldmit at gmail.com  Mon Mar 11 13:37:27 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Mon, 11 Mar 2019 16:37:27 +0300
Subject: Migrating from 1.0.2 to 1.1.1
Message-ID: <CADqLbz+vxPFtBwJgmKBv8=2irkRDtzWYfxVTBd-Tmg9rn_K+=A@mail.gmail.com>

Hello,

I try to migrate the following code from 1.0.2 to 1.1.1:

=========
 ASN1_OBJECT *seed_id = OBJ_txt2obj(my_oid,1);
 int seed_pos = EVP_PKEY_get_attr_by_OBJ(pk, seed_id, -1);

  if (seed_pos >= 0)
  {
    X509_ATTRIBUTE *attr = EVP_PKEY_get_attr(pk, seed_pos);
    CE_CHECK(X509at_add1_attr(&(p8->attributes), attr) != NULL, 0,
CRYPTOCOM_R_NO_MEMORY);
  }
==========
The code is intended to add a custom attribute to PKCS8 attributes.
How do I do it in 1.1.1?

Thank you!

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190311/557bfa65/attachment.html>

From parthpatel041991 at gmail.com  Wed Mar 13 10:13:14 2019
From: parthpatel041991 at gmail.com (Parth Patel)
Date: Wed, 13 Mar 2019 15:43:14 +0530
Subject: build error with openssl-1.1.1b on solaris sparc 32 bit
 (solaris-sparcv9-gcc)
Message-ID: <CAONachcCk+VxZwpYpR=P7isjWD8L_udBUH9G3w2aUHAdEVNvsQ@mail.gmail.com>

Hi,

     Trying to build openssl-1.1.1b on solaris sparc 32 bit machine.
      Getting some error with respect to "file format not recognized"

 -lsocket -lnsl -ldl -pthread
/v/toolchain/SunOS-5.10-sparc/binutils-2.30/bin/gld:libcrypto.map: file
format not recognized; treating as linker script
/v/toolchain/SunOS-5.10-sparc/binutils-2.30/bin/gld:libcrypto.map:1: syntax
error
collect2: error: ld returned 1 exit status
make[1]: *** [libcrypto.so] Error 1
make[1]: Leaving directory
`/netapp-home/ppatel/lmadmin_parth/3rdparty/openssl/openssl-1.1.1b'

Can any one help me on this issue ?

Thanks,
Parth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190313/931a62ff/attachment.html>

From shiyao_liu at foxitsoftware.cn  Wed Mar 13 11:55:16 2019
From: shiyao_liu at foxitsoftware.cn (shiyao_liu at foxitsoftware.cn)
Date: Wed, 13 Mar 2019 19:55:16 +0800
Subject: How can I make openssl doesn't add a signed attribute "signingTime"
 when I sign a cms/cades singnature?
Message-ID: <2019031319551622789927@foxitsoftware.cn>+B511F795D4A5C48C

Hello everyone,

    I am working on a project about how to use openssl libs to implement a PAdES(whitch is based on CAdES) signature because I saw that the master branch of openssl has supported CAdES-BES signature. But now there is a problem I don't know how to solve it. So I am asking for some help.
    According to the PAdES reference, signing-time attribute in CMS signature shall not be present in a PAdES signature. In openssl libs, signing-time attribute is set in the function CMS_SignerInfo_sign. But I can't find a way to control it not to set  signing-time attribute. So I want to know if there is a way to not to set signing-time attribute or delete this attribute without changing the openssl source code.

Regards,
Shiyao Liu 



shiyao_liu at foxitsoftware.cn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190313/17b15b26/attachment-0001.html>

From levitte at openssl.org  Wed Mar 13 12:51:27 2019
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 13 Mar 2019 13:51:27 +0100
Subject: build error with openssl-1.1.1b on solaris sparc 32 bit
 (solaris-sparcv9-gcc)
In-Reply-To: <CAONachcCk+VxZwpYpR=P7isjWD8L_udBUH9G3w2aUHAdEVNvsQ@mail.gmail.com>
References: <CAONachcCk+VxZwpYpR=P7isjWD8L_udBUH9G3w2aUHAdEVNvsQ@mail.gmail.com>
Message-ID: <8736nr2b00.wl-levitte@openssl.org>

You might want to show the whole command line that caused this error,
and it would help if we could have a look at the libcrypto.map you
got.

To be more effective, it might be a good idea to create an issue for
this on github:  https://github.com/openssl/openssl/issues/new/choose

Cheers,
Richard

On Wed, 13 Mar 2019 11:13:14 +0100,
Parth Patel wrote:
> 
> 
> Hi,
> 
> ???? Trying to build openssl-1.1.1b on solaris sparc 32 bit machine.
> ????? Getting some error with respect to "file format not recognized"
> 
> ?-lsocket -lnsl -ldl -pthread
> /v/toolchain/SunOS-5.10-sparc/binutils-2.30/bin/gld:libcrypto.map: file format not recognized;
> treating as linker script
> /v/toolchain/SunOS-5.10-sparc/binutils-2.30/bin/gld:libcrypto.map:1: syntax error
> collect2: error: ld returned 1 exit status
> make[1]: *** [libcrypto.so] Error 1
> make[1]: Leaving directory `/netapp-home/ppatel/lmadmin_parth/3rdparty/openssl/openssl-1.1.1b'
> 
> Can any one help me on this issue ?
> 
> Thanks,
> Parth
> 
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Wed Mar 13 16:56:16 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 13 Mar 2019 16:56:16 +0000
Subject: Developers, a small request
Message-ID: <7B405EC7-BF89-413F-B866-8F19C9CF2502@akamai.com>

It would be really good if code being merged to master had --strict-warnings and the mdebug backtrace stuff turned on. In the past few days there have been a flurry of checkins that these flags would have caught.

Well, flurry is admittedly too strong. ?


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

From levitte at openssl.org  Wed Mar 13 20:09:29 2019
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 13 Mar 2019 21:09:29 +0100
Subject: Developers, a small request
In-Reply-To: <7B405EC7-BF89-413F-B866-8F19C9CF2502@akamai.com>
References: <7B405EC7-BF89-413F-B866-8F19C9CF2502@akamai.com>
Message-ID: <87zhpy1qpy.wl-levitte@openssl.org>

On Wed, 13 Mar 2019 17:56:16 +0100,
Salz, Rich via openssl-users wrote:
> It would be really good if code being merged to master had --strict-warnings and the mdebug
> backtrace stuff turned on. In the past few days there have been a flurry of checkins that these
> flags would have caught.

Well, we do have CIs to show us already in the PRs...  but sometimes,
we are a bit excited and forget to pause and give them a look before
merging.

That being said, if the corrections come soon after, I don't think
much harm is done.

We do have an internal checker that double checks if we've forgotten
to look after some configuration option, and the same CIs as mentioned
above continually fully rebuilding and testing (including extended
tests) all release branches as well as master.  We have shown many
times that we do react on those fairly quickly.

So yeah, we do need to remember that PRs go through the CIs before
merging.

Cheers,
Richard

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

From mahendra.sp at gmail.com  Thu Mar 14 06:51:28 2019
From: mahendra.sp at gmail.com (Mahendra SP)
Date: Thu, 14 Mar 2019 12:21:28 +0530
Subject: Issue in CRYPTO_cbc128_encrypt due to unaligned address
Message-ID: <CADDGra0n3q+f558b1=J=jLCTJF+khUc+iV925EgyKjTHE4LwNw@mail.gmail.com>

Hi All,

I am seeing an issue with the routine CRYPTO_cbc128_encrypt() in version
1.0.2h where,
, if I have not declared STRICT_ALIGNMENT, application crashes
intermittently.

There was a similar query here but for CRYPTO_ctr128_encrypt.
https://mta.openssl.org/pipermail/openssl-dev/2016-January/003966.html

I have dumped the addresses for both ivec and iv. Even though the addresses
are unaligned most of the times, crash is seen only occasioanally.

I don't want to declare STRICT_ALIGNMENT for performance reasons as I need
to have the size_t based operations. Is there a work around similar to one
proposed in the above thread or any other suggestions on how to handle this
?

Thanks
Mahendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190314/4d543eba/attachment.html>

From grace.priscilla at gmail.com  Thu Mar 14 08:11:28 2019
From: grace.priscilla at gmail.com (Grace Priscilla Jero)
Date: Thu, 14 Mar 2019 13:41:28 +0530
Subject: memory leak observed with openssl 1.0.2l version of openssl
Message-ID: <CAGfOHcWTFVEYNn=iXEe5B-fTgzpGH9TxkPAr8tFrtJca9KmARQ@mail.gmail.com>

Hi All,
We are using 1.0.2l version of system openssl that causes memory leak
during a state of congestion. Is this already a known issue?

The same was tested with 1.1.g version of openssl and there was'nt any
leaks. Do anyone know the changes or difference between these 2 versions.

Thanks,
Grace
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190314/0198f446/attachment.html>

From antiac at gmail.com  Thu Mar 14 08:41:07 2019
From: antiac at gmail.com (Antonio Iacono)
Date: Thu, 14 Mar 2019 09:41:07 +0100
Subject: How can I make openssl doesn't add a signed attribute
 "signingTime" when I sign a cms/cades singnature?
In-Reply-To: <5c88f03e.1c69fb81.6161e.151eSMTPIN_ADDED_BROKEN@mx.google.com>
References: <5c88f03e.1c69fb81.6161e.151eSMTPIN_ADDED_BROKEN@mx.google.com>
Message-ID: <CAPN6PER_=9GVqVrwOWH98uO1ounzUt6=judrZj0zwEyHa97HBg@mail.gmail.com>

Hello Shiyao,

the signing time attribute has always been considered mandatory or in
any case useful and only with CAdES optional and even with PAdES not
allowed.
A request similar to yours has already been received (see
https://mta.openssl.org/pipermail/openssl-users/2017-February/005240.html)
I also believe that CMS API flag would be useful that allows
suppression of the signing-time attribute.

Antonio

On Wed, Mar 13, 2019 at 12:57 PM shiyao_liu at foxitsoftware.cn
<shiyao_liu at foxitsoftware.cn> wrote:
>
> Hello everyone,
>
>     I am working on a project about how to use openssl libs to implement a PAdES(whitch is based on CAdES) signature because I saw that the master branch of openssl has supported CAdES-BES signature. But now there is a problem I don't know how to solve it. So I am asking for some help.
>     According to the PAdES reference, signing-time attribute in CMS signature shall not be present in a PAdES signature. In openssl libs, signing-time attribute is set in the function CMS_SignerInfo_sign. But I can't find a way to control it not to set  signing-time attribute. So I want to know if there is a way to not to set signing-time attribute or delete this attribute without changing the openssl source code.
>
> Regards,
> Shiyao Liu
>
> ________________________________
> shiyao_liu at foxitsoftware.cn

From Matthias.St.Pierre at ncp-e.com  Thu Mar 14 12:42:05 2019
From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre)
Date: Thu, 14 Mar 2019 13:42:05 +0100
Subject: Developers, a small request
In-Reply-To: <87zhpy1qpy.wl-levitte@openssl.org>
References: <7B405EC7-BF89-413F-B866-8F19C9CF2502@akamai.com>
 <87zhpy1qpy.wl-levitte@openssl.org>
Message-ID: <ad3a39d1-0ba3-2623-e9c5-833622071c30@ncp-e.com>


On 13.03.19 21:09, Richard Levitte wrote:
>
> So yeah, we do need to remember that PRs go through the CIs before
> merging.
>

Agreed, and thanks Rich for the polite reminder :-)

Matthias


From sachi059 at gmail.com  Thu Mar 14 14:09:27 2019
From: sachi059 at gmail.com (sachidananda sahu)
Date: Thu, 14 Mar 2019 19:39:27 +0530
Subject: Openssl cross compilation
Message-ID: <CAG2=8_rMgvgZeKCV=cgKxXA7JtUH1ZrNZTwx16xpPeADcbCyiQ@mail.gmail.com>

Hi Team,
I was trying to cross compile openssl for LDAP purpose but getting this
following error.

*checking for SPNEGO support in GSSAPI libraries... configure: error: in *
*configure: error: cannot run test program while cross compiling*
See `config.log' for more details

Openssl library version : cyrus-sasl-2.1.27
Command used : configure --host=x86_64-unknown-freebsd9
--cache=config.cache --disable-ntlm --disable-otp --disable-sample
--enable-gssapi --with-des=no --with-gss-impl=mit

The machine details
build system type... x86_64-unknown-linux-gnu
 host system type... x86_64-unknown-freebsd9
 target system type... x86_64-unknown-freebsd9

Can any one share the reason for this ?


-- 
Regards,
Sachidananda Sahu
+91-9035265767
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190314/80808c36/attachment.html>

From rsalz at akamai.com  Thu Mar 14 14:24:31 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 14 Mar 2019 14:24:31 +0000
Subject: Openssl cross compilation
In-Reply-To: <CAG2=8_rMgvgZeKCV=cgKxXA7JtUH1ZrNZTwx16xpPeADcbCyiQ@mail.gmail.com>
References: <CAG2=8_rMgvgZeKCV=cgKxXA7JtUH1ZrNZTwx16xpPeADcbCyiQ@mail.gmail.com>
Message-ID: <4C026CBB-C832-4CC8-A047-418A4AAE6733@akamai.com>

>: configure --host=x86_64-unknown-freebsd9 --cache=config.cache --disable-ntlm --disable-otp --disable-sample --enable-gssapi --with-des=no --with-gss-impl=mit

That?s not an OpenSSL configuration, and the error you got is not from OpenSSL.

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

From rsalz at akamai.com  Thu Mar 14 14:23:28 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 14 Mar 2019 14:23:28 +0000
Subject: Openssl cross compilation
In-Reply-To: <CAG2=8_rMgvgZeKCV=cgKxXA7JtUH1ZrNZTwx16xpPeADcbCyiQ@mail.gmail.com>
References: <CAG2=8_rMgvgZeKCV=cgKxXA7JtUH1ZrNZTwx16xpPeADcbCyiQ@mail.gmail.com>
Message-ID: <6E7FC5AA-5BDB-4292-8310-C6C7679F85A5@akamai.com>

  *   checking for SPNEGO support in GSSAPI libraries... configure: error: in
configure: error: cannot run test program while cross compiling
See `config.log' for more details

That?s ot
Openssl library version : cyrus-sasl-2.1.27
Command used : configure --host=x86_64-unknown-freebsd9 --cache=config.cache --disable-ntlm --disable-otp --disable-sample --enable-gssapi --with-des=no --with-gss-impl=mit

The machine details
build system type... x86_64-unknown-linux-gnu
 host system type... x86_64-unknown-freebsd9
 target system type... x86_64-unknown-freebsd9

Can any one share the reason for this ?


--
Regards,
Sachidananda Sahu
+91-9035265767
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190314/c779ec85/attachment.html>

From sachi059 at gmail.com  Thu Mar 14 14:32:11 2019
From: sachi059 at gmail.com (sachidananda sahu)
Date: Thu, 14 Mar 2019 20:02:11 +0530
Subject: Openssl cross compilation
In-Reply-To: <6E7FC5AA-5BDB-4292-8310-C6C7679F85A5@akamai.com>
References: <CAG2=8_rMgvgZeKCV=cgKxXA7JtUH1ZrNZTwx16xpPeADcbCyiQ@mail.gmail.com>
 <6E7FC5AA-5BDB-4292-8310-C6C7679F85A5@akamai.com>
Message-ID: <CAG2=8_raB7aPVKQZWM6vp-BNG2RZBCvTnFnk-DYYu72Z1vvo=Q@mail.gmail.com>

Hello Sorry,
Posted to wrong list, as I subscribed to both.

Thanks for pointing out.

On Thu, Mar 14, 2019, 7:57 PM Salz, Rich <rsalz at akamai.com> wrote:

>
>    - *checking for SPNEGO support in GSSAPI libraries... configure:
>    error: in *
>
> *configure: error: cannot run test program while cross compiling*
>
> See `config.log' for more details
>
>
>
> That?s ot
>
> Openssl library version : cyrus-sasl-2.1.27
>
> Command used : configure --host=x86_64-unknown-freebsd9
> --cache=config.cache --disable-ntlm --disable-otp --disable-sample
> --enable-gssapi --with-des=no --with-gss-impl=mit
>
>
>
> The machine details
>
> build system type... x86_64-unknown-linux-gnu
>
>  host system type... x86_64-unknown-freebsd9
>
>  target system type... x86_64-unknown-freebsd9
>
>
>
> Can any one share the reason for this ?
>
>
>
>
>
> --
>
> Regards,
> Sachidananda Sahu
> +91-9035265767
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190314/34283c06/attachment-0001.html>

From rama.krushna7 at gmail.com  Fri Mar 15 08:43:20 2019
From: rama.krushna7 at gmail.com (ramakrushna mishra)
Date: Fri, 15 Mar 2019 14:13:20 +0530
Subject: Reg solaris support for openssl 1.1.1b
In-Reply-To: <CAHgr=kJyCXVY9QssB2CO3hY=GsEwiEcvzwQ-Pyd3VKqSm51XLA@mail.gmail.com>
References: <CAHgr=kJyCXVY9QssB2CO3hY=GsEwiEcvzwQ-Pyd3VKqSm51XLA@mail.gmail.com>
Message-ID: <CAHgr=kJkwytkjD_pc0gmcZN1-AeA4aWdWv3jGjB3mKYTHAHAww@mail.gmail.com>

Hi,

I am trying to upgrade openssl on solaris machine from 1.1.0e to 1.1.1b.
The "uname -a " output from solaris is :

> SunOS  5.10 Generic_147147-26 sun4v sparc sun4v
>

The Configure and installation of openssl was successful.
But when i run "bin/openssl version" it fails with following error.

 "openssl version

ld.so.1: openssl: fatal: relocation error: file openssl: symbol
OPENSSL_sk_new_null: referenced symbol not found".


could you please anyone let me know what could be the problem ?


Thanks and regards,

Ram Krushna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190315/5a2a76ac/attachment.html>

From Matthias.St.Pierre at ncp-e.com  Fri Mar 15 09:38:38 2019
From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre)
Date: Fri, 15 Mar 2019 10:38:38 +0100
Subject: Reg solaris support for openssl 1.1.1b
In-Reply-To: <CAHgr=kJkwytkjD_pc0gmcZN1-AeA4aWdWv3jGjB3mKYTHAHAww@mail.gmail.com>
References: <CAHgr=kJyCXVY9QssB2CO3hY=GsEwiEcvzwQ-Pyd3VKqSm51XLA@mail.gmail.com>
 <CAHgr=kJkwytkjD_pc0gmcZN1-AeA4aWdWv3jGjB3mKYTHAHAww@mail.gmail.com>
Message-ID: <84fb71bd-8fe5-2e5d-5950-95ca8d58a494@ncp-e.com>

My guess is that your binary is loading the system's shared libraries.
To find out whether this is the case, try

 ??? ldd bin/openssl

If my assumption is correct, you might have to set the LD_LIBRARY_PATH explicitely.

HTH,
Matthias


On 15.03.19 09:43, ramakrushna mishra wrote:
> Hi,
>
> I am trying to upgrade openssl on solaris machine from?1.1.0e to 1.1.1b.
> The "uname -a " output from solaris is :
>
>     SunOS? 5.10 Generic_147147-26 sun4v sparc sun4v
>
>
> The Configure and installation of openssl was successful.
> But when i run "bin/openssl version" it fails with following error.
>
> ?"openssl version
>
> ld.so.1: openssl: fatal: relocation error: file openssl: symbol OPENSSL_sk_new_null: referenced symbol not found".
>
>
> could you please anyone let me know what could be the problem ?
>
>
> Thanks and?regards,
>
> Ram Krushna
>


From shiyao_liu at foxitsoftware.cn  Fri Mar 15 10:58:07 2019
From: shiyao_liu at foxitsoftware.cn (=?utf-8?B?c2hpeWFvX2xpdUBmb3hpdHNvZnR3YXJlLmNu?=)
Date: Fri, 15 Mar 2019 18:58:07 +0800
Subject: How can I make openssl doesn't add a signed attribute
 "signingTime" when I sign a cms/cades singnature?
In-Reply-To: <CAPN6PER_=9GVqVrwOWH98uO1ounzUt6=judrZj0zwEyHa97HBg@mail.gmail.com>
References: <5c88f03e.1c69fb81.6161e.151eSMTPIN_ADDED_BROKEN@mx.google.com>
 <CAPN6PER_=9GVqVrwOWH98uO1ounzUt6=judrZj0zwEyHa97HBg@mail.gmail.com>
Message-ID: <tencent_650ECC521F8AE94D45E4A552@qq.com>

Hello Antonio,


Thanks for your answer.So there is no way to not add the "signingTime" attribute? Is there a plan to make the attribute optional in the near future?


Regards.
Shiyao Liu
 
 
------------------ Original ------------------
From:  "Antonio Iacono"<antiac at gmail.com>;
Date:  Thu, Mar 14, 2019 04:41 PM
To:  "shiyao_liu at foxitsoftware.cn"<shiyao_liu at foxitsoftware.cn>; 
Cc:  "openssl-users"<openssl-users at openssl.org>; "gaochao_liu"<gaochao_liu at foxitsoftware.cn>; "junyi_liang"<junyi_liang at foxitsoftware.com>; "xiaochuan_liu"<xiaochuan_liu at foxitsoftware.cn>; 
Subject:  Re: How can I make openssl doesn't add a signed attribute "signingTime" when I sign a cms/cades singnature?

 
Hello Shiyao,

the signing time attribute has always been considered mandatory or in
any case useful and only with CAdES optional and even with PAdES not
allowed.
A request similar to yours has already been received (see
https://mta.openssl.org/pipermail/openssl-users/2017-February/005240.html)
I also believe that CMS API flag would be useful that allows
suppression of the signing-time attribute.

cc

On Wed, Mar 13, 2019 at 12:57 PM shiyao_liu at foxitsoftware.cn
<shiyao_liu at foxitsoftware.cn> wrote:
>
> Hello everyone,
>
>     I am working on a project about how to use openssl libs to implement a PAdES(whitch is based on CAdES) signature because I saw that the master branch of openssl has supported CAdES-BES signature. But now there is a problem I don't know how to solve it. So I am asking for some help.
>     According to the PAdES reference, signing-time attribute in CMS signature shall not be present in a PAdES signature. In openssl libs, signing-time attribute is set in the function CMS_SignerInfo_sign. But I can't find a way to control it not to set  signing-time attribute. So I want to know if there is a way to not to set signing-time attribute or delete this attribute without changing the openssl source code.
>
> Regards,
> Shiyao Liu
>
> ________________________________
> shiyao_liu at foxitsoftware.cn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190315/2035de36/attachment.html>

From dclarke at blastwave.org  Fri Mar 15 13:33:28 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Fri, 15 Mar 2019 09:33:28 -0400
Subject: Reg solaris support for openssl 1.1.1b
In-Reply-To: <84fb71bd-8fe5-2e5d-5950-95ca8d58a494@ncp-e.com>
References: <CAHgr=kJyCXVY9QssB2CO3hY=GsEwiEcvzwQ-Pyd3VKqSm51XLA@mail.gmail.com>
 <CAHgr=kJkwytkjD_pc0gmcZN1-AeA4aWdWv3jGjB3mKYTHAHAww@mail.gmail.com>
 <84fb71bd-8fe5-2e5d-5950-95ca8d58a494@ncp-e.com>
Message-ID: <5f34fc45-0d64-8be8-aedd-e96f93e050e1@blastwave.org>

On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
> My guess is that your binary is loading the system's shared libraries.
> To find out whether this is the case, try
> 
> ??? ldd bin/openssl
> 
> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
> explicitely.

Actually LD_LIBRARY_PATH is evil.

The correct way to do this is to compile with a RUNPATH set in the
output ELF files.

Building on Solaris is a real pain.

Dennis


From ludwig.mark at siemens.com  Fri Mar 15 15:56:38 2019
From: ludwig.mark at siemens.com (Ludwig, Mark)
Date: Fri, 15 Mar 2019 15:56:38 +0000
Subject: Reg solaris support for openssl 1.1.1b
In-Reply-To: <5f34fc45-0d64-8be8-aedd-e96f93e050e1@blastwave.org>
References: <CAHgr=kJyCXVY9QssB2CO3hY=GsEwiEcvzwQ-Pyd3VKqSm51XLA@mail.gmail.com>
 <CAHgr=kJkwytkjD_pc0gmcZN1-AeA4aWdWv3jGjB3mKYTHAHAww@mail.gmail.com>
 <84fb71bd-8fe5-2e5d-5950-95ca8d58a494@ncp-e.com>
 <5f34fc45-0d64-8be8-aedd-e96f93e050e1@blastwave.org>
Message-ID: <BC5672F8AD4C054BAF167C9801500D1A01786E75DC@USSLMMBX004.net.plm.eds.com>

> From: Dennis Clarke, Friday, March 15, 2019 8:33 AM
> 
> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
> > My guess is that your binary is loading the system's shared libraries.
> > To find out whether this is the case, try
> >
> > ??? ldd bin/openssl
> >
> > If my assumption is correct, you might have to set the LD_LIBRARY_PATH
> > explicitely.
> 
> Actually LD_LIBRARY_PATH is evil.
> 
> The correct way to do this is to compile with a RUNPATH set in the
> output ELF files.

Assuming you are in control of the destination systems' library locations, RUNPATH is desirable.

For an ISV, LD_LIBRARY_PATH is a necessary evil for application-delivered libraries.

> Building on Solaris is a real pain.

Compared with what?  This is how all Unices/*nix's work.

Best,
Mark Ludwig


From jb-openssl at wisemo.com  Fri Mar 15 17:19:53 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 15 Mar 2019 18:19:53 +0100
Subject: Reg solaris support for openssl 1.1.1b
In-Reply-To: <5f34fc45-0d64-8be8-aedd-e96f93e050e1@blastwave.org>
References: <CAHgr=kJyCXVY9QssB2CO3hY=GsEwiEcvzwQ-Pyd3VKqSm51XLA@mail.gmail.com>
 <CAHgr=kJkwytkjD_pc0gmcZN1-AeA4aWdWv3jGjB3mKYTHAHAww@mail.gmail.com>
 <84fb71bd-8fe5-2e5d-5950-95ca8d58a494@ncp-e.com>
 <5f34fc45-0d64-8be8-aedd-e96f93e050e1@blastwave.org>
Message-ID: <649ef06e-0f64-65bb-cb43-cfde681fd117@wisemo.com>

On 15/03/2019 14:33, Dennis Clarke wrote:
> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
>> My guess is that your binary is loading the system's shared libraries.
>> To find out whether this is the case, try
>>
>>  ??? ldd bin/openssl
>>
>> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
>> explicitely.
> Actually LD_LIBRARY_PATH is evil.
>
> The correct way to do this is to compile with a RUNPATH set in the
> output ELF files.
LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when 
testing
a newly compiled binary before installing the libraries to their final 
locations, perhaps
on the same, perhaps on another machine.

P.S.
I don't known if the Solaris loader lets LD_LIBRARY_PATH override 
RUNPATH as
presumed by the above answer.

Enjoy

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


From vieuxtech at gmail.com  Fri Mar 15 18:19:22 2019
From: vieuxtech at gmail.com (Sam Roberts)
Date: Fri, 15 Mar 2019 11:19:22 -0700
Subject: Why were edwards curves given distinct key types, aren't they EC keys?
Message-ID: <CA+Sj9TkpX+fR+o-5G3mLaW+ouHnVvxxee3fdNgbfpyAWeCBhSw@mail.gmail.com>

It seems like they are EC keys, with specific curve designs, and that
also have some algorithms designed specifically for them, like EdDSA
-- though it looks like that alg is being generalized to other curve
types (https://tools.ietf.org/html/rfc8032#ref-EDDSA2).

What about them makes it necessary to make them distinct, both from
each other, and EVP_PKEY_EC?

Thanks,
Sam

From Erwann.Abalea at docusign.com  Fri Mar 15 18:39:16 2019
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Fri, 15 Mar 2019 18:39:16 +0000
Subject: Why were edwards curves given distinct key types, aren't they EC
 keys?
In-Reply-To: <CA+Sj9TkpX+fR+o-5G3mLaW+ouHnVvxxee3fdNgbfpyAWeCBhSw@mail.gmail.com>
References: <CA+Sj9TkpX+fR+o-5G3mLaW+ouHnVvxxee3fdNgbfpyAWeCBhSw@mail.gmail.com>
Message-ID: <284C3B6C-48EB-4ADF-887D-5B01861EC30D@docusign.com>

Maybe because EVP_PKEY_EC designates an ECDSA key, that an EdDSA key is not generated the same way (particularly the public part), and that the encodings are different?

Cordialement,
Erwann Abalea

?Le 15/03/2019 19:20, ? openssl-users au nom de Sam Roberts ? <openssl-users-bounces at openssl.org au nom de vieuxtech at gmail.com> a ?crit :

    It seems like they are EC keys, with specific curve designs, and that
    also have some algorithms designed specifically for them, like EdDSA
    -- though it looks like that alg is being generalized to other curve
    types (https://tools.ietf.org/html/rfc8032#ref-EDDSA2).
    
    What about them makes it necessary to make them distinct, both from
    each other, and EVP_PKEY_EC?
    
    Thanks,
    Sam
    


From nic.tuv at gmail.com  Fri Mar 15 22:18:16 2019
From: nic.tuv at gmail.com (Nicola)
Date: Sat, 16 Mar 2019 00:18:16 +0200
Subject: Why were edwards curves given distinct key types,
 aren't they EC keys?
In-Reply-To: <CA+Sj9TkpX+fR+o-5G3mLaW+ouHnVvxxee3fdNgbfpyAWeCBhSw@mail.gmail.com>
References: <CA+Sj9TkpX+fR+o-5G3mLaW+ouHnVvxxee3fdNgbfpyAWeCBhSw@mail.gmail.com>
Message-ID: <CANm5x_PUVjw6w0acwJ7xUeqa3cH=VXhSFFqZWUfWM1-qdQNJ1g@mail.gmail.com>

It depends on the way they are defined: Ed25519 and Ed448 are
standardized as twisted edward curves, while traditional curves in the
EC module are defined in short weirstrass form.

The set of parameters describing the curves and their equation form
are different:
- for Edwards curves you have an expression of the form: `a x^2 + y^2
= 1 + d x^2 y^2`, and the parameters `a` and `d` have to satisfy
certain properties;
- for short Weierstrass curves the expression has the form: `y^3 = x^3
+ a x + b`, and the parameters `a` and `b` have to satisfy a different
set of properties.

While it would have been technically possible to (hackishly)
"overload" the existing EC module to support Ed curves, it wouldn't
make too much sense, as the standards use different encodings and
codepoints for describing keys and curve points (so one cannot reuse
the existing ASN1 methods associated with traditional EC objects).

In addition to that, EC objects are supposed to support a common set
of arithmetic primitives on top of which cryptosystems like ECDH,
cofactor-ECDH and ECDSA are defined, but again the standardized
Edwards curve are instead associated with a different digital
signature cryptosystem (EdDSA) and the `derive` (i.e. equivalent to
ECDH) operation is defined on different (although related) Montgomery
curves (i.e. X25519 for Ed25519 and X448 for Ed448).


Hope this answers your question,

Nicola

On Fri, Mar 15, 2019, 20:20 Sam Roberts <vieuxtech at gmail.com> wrote:

> It seems like they are EC keys, with specific curve designs, and that
> also have some algorithms designed specifically for them, like EdDSA
> -- though it looks like that alg is being generalized to other curve
> types (https://tools.ietf.org/html/rfc8032#ref-EDDSA2).
>
> What about them makes it necessary to make them distinct, both from
> each other, and EVP_PKEY_EC?
>
> Thanks,
> Sam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190316/04b5f5f1/attachment.html>

From dclarke at blastwave.org  Sat Mar 16 00:49:30 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Fri, 15 Mar 2019 20:49:30 -0400
Subject: Reg solaris support for openssl 1.1.1b
In-Reply-To: <649ef06e-0f64-65bb-cb43-cfde681fd117@wisemo.com>
References: <CAHgr=kJyCXVY9QssB2CO3hY=GsEwiEcvzwQ-Pyd3VKqSm51XLA@mail.gmail.com>
 <CAHgr=kJkwytkjD_pc0gmcZN1-AeA4aWdWv3jGjB3mKYTHAHAww@mail.gmail.com>
 <84fb71bd-8fe5-2e5d-5950-95ca8d58a494@ncp-e.com>
 <5f34fc45-0d64-8be8-aedd-e96f93e050e1@blastwave.org>
 <649ef06e-0f64-65bb-cb43-cfde681fd117@wisemo.com>
Message-ID: <4b08232c-f734-987c-814c-5acef59f42ab@blastwave.org>

On 3/15/19 1:19 PM, Jakob Bohm via openssl-users wrote:
> On 15/03/2019 14:33, Dennis Clarke wrote:
>> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
>>> My guess is that your binary is loading the system's shared libraries.
>>> To find out whether this is the case, try
>>>
>>> ???? ldd bin/openssl
>>>
>>> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
>>> explicitely.
>> Actually LD_LIBRARY_PATH is evil.
>>
>> The correct way to do this is to compile with a RUNPATH set in the
>> output ELF files.
> LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
> testing
> a newly compiled binary before installing the libraries to their final
> locations, perhaps
> on the same, perhaps on another machine.
> 
> P.S.
> I don't known if the Solaris loader lets LD_LIBRARY_PATH override
> RUNPATH as
> presumed by the above answer.

Yes it certainly does. Otherwise testing a new custom lib would be a
royal pain as opposed to just a pain.  Also most people still, after
twenty years, know what LD_LIBRARY_PATH env var is for and it is a waste
of breath trying to explain it after decades of watching folks skewer
themselves over and over and over ....

dc


From vieuxtech at gmail.com  Sat Mar 16 15:00:08 2019
From: vieuxtech at gmail.com (Sam Roberts)
Date: Sat, 16 Mar 2019 08:00:08 -0700
Subject: Why were edwards curves given distinct key types,
 aren't they EC keys?
In-Reply-To: <CANm5x_PUVjw6w0acwJ7xUeqa3cH=VXhSFFqZWUfWM1-qdQNJ1g@mail.gmail.com>
References: <CA+Sj9TkpX+fR+o-5G3mLaW+ouHnVvxxee3fdNgbfpyAWeCBhSw@mail.gmail.com>
 <CANm5x_PUVjw6w0acwJ7xUeqa3cH=VXhSFFqZWUfWM1-qdQNJ1g@mail.gmail.com>
Message-ID: <CA+Sj9TkXR41db5YzXO7v9Y7vAN16jLmk8WW+DhL0K0zqOJ0=Ng@mail.gmail.com>

That helps a lot, I can see why they are different enough from EC key
types to be distinct.

It still leaves me wondering whe two edwards curves have key types
distinct from each other? Why aren't they both EVP_PKEY_ED? (or
something of the like)

Cheers,
Sam

From nic.tuv at gmail.com  Sat Mar 16 15:05:05 2019
From: nic.tuv at gmail.com (Nicola)
Date: Sat, 16 Mar 2019 17:05:05 +0200
Subject: Why were edwards curves given distinct key types,
 aren't they EC keys?
In-Reply-To: <CA+Sj9TkXR41db5YzXO7v9Y7vAN16jLmk8WW+DhL0K0zqOJ0=Ng@mail.gmail.com>
References: <CA+Sj9TkpX+fR+o-5G3mLaW+ouHnVvxxee3fdNgbfpyAWeCBhSw@mail.gmail.com>
 <CANm5x_PUVjw6w0acwJ7xUeqa3cH=VXhSFFqZWUfWM1-qdQNJ1g@mail.gmail.com>
 <CA+Sj9TkXR41db5YzXO7v9Y7vAN16jLmk8WW+DhL0K0zqOJ0=Ng@mail.gmail.com>
Message-ID: <CANm5x_OvkVV12__FGYBodRf40ztq9abu2ky9X0tF1HH=4vXkJQ@mail.gmail.com>

Well, they just don't have their individual type either: they are just
`EVP_PKEY`s, with `EVP_PKEY` being the top level API in libcrypto for
public key cryptography.
The difference with `RSA_KEY`, `DSA_KEY`, `EC_KEY` (that can be
encapsulated in a generic `EVP_PKEY` object) is that Ed* keys don't
share a common module (apart from reusing common functions for parts
of the ASN1 encoding/decoding).
RSA, DSA and EC in libcrypto are submodules on their own, with a
dedicated `{RSA,DSA,EC}_*` API, in part for legacy reasons. By the
time X25519, Ed25519 and *448 were added, the new direction in the
project was to minimise the size of the public API and recommend the
use of the unified EVP API, so it did not make any sense to have a
separate submodule with its own data types and API.

This is of course to the best of my knowledge and mostly based on
guesses, as I was not actively contributing to the project while some
of these decisions were made, and I don't have the same insight on the
history of the design of the library as other project members.

BR,

Nicola

On Sat, Mar 16, 2019, 17:00 Sam Roberts <vieuxtech at gmail.com> wrote:

> That helps a lot, I can see why they are different enough from EC key
> types to be distinct.
>
> It still leaves me wondering whe two edwards curves have key types
> distinct from each other? Why aren't they both EVP_PKEY_ED? (or
> something of the like)
>
> Cheers,
> Sam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190316/a812bace/attachment.html>

From vieuxtech at gmail.com  Sat Mar 16 19:49:07 2019
From: vieuxtech at gmail.com (Sam Roberts)
Date: Sat, 16 Mar 2019 12:49:07 -0700
Subject: Why were edwards curves given distinct key types,
 aren't they EC keys?
In-Reply-To: <CANm5x_OvkVV12__FGYBodRf40ztq9abu2ky9X0tF1HH=4vXkJQ@mail.gmail.com>
References: <CA+Sj9TkpX+fR+o-5G3mLaW+ouHnVvxxee3fdNgbfpyAWeCBhSw@mail.gmail.com>
 <CANm5x_PUVjw6w0acwJ7xUeqa3cH=VXhSFFqZWUfWM1-qdQNJ1g@mail.gmail.com>
 <CA+Sj9TkXR41db5YzXO7v9Y7vAN16jLmk8WW+DhL0K0zqOJ0=Ng@mail.gmail.com>
 <CANm5x_OvkVV12__FGYBodRf40ztq9abu2ky9X0tF1HH=4vXkJQ@mail.gmail.com>
Message-ID: <CA+Sj9TmtXj6RDvk57fT04-_4OiCtx=n21vOfDFoFcZVaFyOnxQ@mail.gmail.com>

That helps a lot, thanks.

On Sat, Mar 16, 2019 at 8:05 AM Nicola <nic.tuv at gmail.com> wrote:
>
> Well, they just don't have their individual type either: they are just
> `EVP_PKEY`s, with `EVP_PKEY` being the top level API in libcrypto for
> public key cryptography.
> The difference with `RSA_KEY`, `DSA_KEY`, `EC_KEY` (that can be
> encapsulated in a generic `EVP_PKEY` object) is that Ed* keys don't
> share a common module (apart from reusing common functions for parts
> of the ASN1 encoding/decoding).
> RSA, DSA and EC in libcrypto are submodules on their own, with a
> dedicated `{RSA,DSA,EC}_*` API, in part for legacy reasons. By the
> time X25519, Ed25519 and *448 were added, the new direction in the
> project was to minimise the size of the public API and recommend the
> use of the unified EVP API, so it did not make any sense to have a
> separate submodule with its own data types and API.
>
> This is of course to the best of my knowledge and mostly based on
> guesses, as I was not actively contributing to the project while some
> of these decisions were made, and I don't have the same insight on the
> history of the design of the library as other project members.
>
> BR,
>
> Nicola
>
> On Sat, Mar 16, 2019, 17:00 Sam Roberts <vieuxtech at gmail.com> wrote:
>>
>> That helps a lot, I can see why they are different enough from EC key
>> types to be distinct.
>>
>> It still leaves me wondering whe two edwards curves have key types
>> distinct from each other? Why aren't they both EVP_PKEY_ED? (or
>> something of the like)
>>
>> Cheers,
>> Sam

From minfrin at sharp.fm  Sun Mar 17 23:06:19 2019
From: minfrin at sharp.fm (Graham Leggett)
Date: Mon, 18 Mar 2019 01:06:19 +0200
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
Message-ID: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>

Hi all,

While porting some code across from RHEL6 (openssl-1.0.1e-42) to RHEL7 (openssl-1.0.2k-16), I am getting the failure below where previously the code worked.

The code creates an X509_REQ, populates it, and then passes this to a module. Before passing it to the module, the structure is canonicalised by passing it through i2d_X509_REQ() and then d2i_X509_REQ() on the other side.

On RHEL7, d2i_X509_REQ fails as follows:

[root at localhost ~]# openssl req -in req.bin -inform der
unable to load X509 request
139903756527504:error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287:
139903756527504:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:720:Field=algorithm, Type=X509_ALGOR
139903756527504:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:720:Field=sig_alg, Type=X509_REQ

The failure occurs in the openssl code here:

424	        for (i = 0, tt = it->templates; i < it->tcount; i++, tt++) {
(gdb) 
427	            seqtt = asn1_do_adb(pval, tt, 1);
(gdb) 
428	            if (seqtt == NULL)
(gdb) 
427	            seqtt = asn1_do_adb(pval, tt, 1);
(gdb) 
428	            if (seqtt == NULL)
(gdb) 
430	            pseqval = asn1_get_field_ptr(pval, seqtt);
(gdb) 
432	            if (!len)
(gdb) 
430	            pseqval = asn1_get_field_ptr(pval, seqtt);
(gdb) 
432	            if (!len)
(gdb) 
435	            if (asn1_check_eoc(&p, len)) {
(gdb) 
434	            q = p;
(gdb) 
435	            if (asn1_check_eoc(&p, len)) {
(gdb) 
451	            if (i == (it->tcount - 1))
(gdb) 
459	            ret = asn1_template_ex_d2i(pseqval, &p, len, seqtt, isopt, ctx,
(gdb) 
461	            if (!ret) {
[????error here????]
(gdb) 
520	    if (combine == 0)
(gdb) 
521	        ASN1_item_ex_free(pval, it);
(gdb) 
522	    if (errtt)
(gdb) 
523	        ERR_add_error_data(4, "Field=", errtt->field_name,
(gdb) 
527	    return 0;
(gdb) 
528	}

The CSR can be found here: http://www.sharp.fm/req.bin

Would it be possible to confirm what is wrong with this request?

Regards,
Graham
?


From felipe at felipegasper.com  Sun Mar 17 23:21:19 2019
From: felipe at felipegasper.com (Felipe Gasper)
Date: Sun, 17 Mar 2019 19:21:19 -0400
Subject: In-memory SSL_CTX_use_certificate_chain_file?
Message-ID: <3C766350-824A-4C74-9909-D09E448A348E@felipegasper.com>

Hello,

Is there any equivalent to SSL_CTX_use_certificate_chain_file for a PEM buffet that?s already in memory?

Thank you!

-F

From felipe at felipegasper.com  Sun Mar 17 23:46:30 2019
From: felipe at felipegasper.com (Felipe Gasper)
Date: Sun, 17 Mar 2019 19:46:30 -0400
Subject: In-memory SSL_CTX_use_certificate_chain_file?
In-Reply-To: <3C766350-824A-4C74-9909-D09E448A348E@felipegasper.com>
References: <3C766350-824A-4C74-9909-D09E448A348E@felipegasper.com>
Message-ID: <96F3B6F4-DC58-48D0-BCB6-1A8210938155@felipegasper.com>

Buffer, not buffet. Silly autocorrect!

-F

> On Mar 17, 2019, at 7:21 PM, Felipe Gasper <felipe at felipegasper.com> wrote:
> 
> Hello,
> 
> Is there any equivalent to SSL_CTX_use_certificate_chain_file for a PEM buffet that?s already in memory?
> 
> Thank you!
> 
> -F


From d3ck0r at gmail.com  Sun Mar 17 23:55:11 2019
From: d3ck0r at gmail.com (J Decker)
Date: Sun, 17 Mar 2019 16:55:11 -0700
Subject: In-memory SSL_CTX_use_certificate_chain_file?
In-Reply-To: <96F3B6F4-DC58-48D0-BCB6-1A8210938155@felipegasper.com>
References: <3C766350-824A-4C74-9909-D09E448A348E@felipegasper.com>
 <96F3B6F4-DC58-48D0-BCB6-1A8210938155@felipegasper.com>
Message-ID: <CAA2GJqWwDrnLfX1uJqGPj_+WFPkigHd=P-+g+c+jp=m-jS+BEA@mail.gmail.com>

On Sun, Mar 17, 2019 at 4:46 PM Felipe Gasper <felipe at felipegasper.com>
wrote:

> Buffer, not buffet. Silly autocorrect!
>
> -F
>
> > On Mar 17, 2019, at 7:21 PM, Felipe Gasper <felipe at felipegasper.com>
> wrote:
> >
> > Hello,
> >
> > Is there any equivalent to SSL_CTX_use_certificate_chain_file for a PEM
> buffet that?s already in memory?
>
SSL_CTX_use_certificate( ses->ctx, sk_X509_value( ses->cert->chain, 0 ) );
?
SSL_CTX_add_extra_chain_cert( ses->ctx, sk_X509_value( ses->cert->chain, n
) );

and/or maybe

X509_STORE *store = SSL_CTX_get_cert_store( ses->ctx );
X509_STORE_add_cert( store, cert );

>
> > Thank you!
> >
> > -F
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190317/be2da0dc/attachment.html>

From felipe at felipegasper.com  Mon Mar 18 00:17:45 2019
From: felipe at felipegasper.com (Felipe Gasper)
Date: Sun, 17 Mar 2019 20:17:45 -0400
Subject: In-memory SSL_CTX_use_certificate_chain_file?
In-Reply-To: <CAA2GJqWwDrnLfX1uJqGPj_+WFPkigHd=P-+g+c+jp=m-jS+BEA@mail.gmail.com>
References: <3C766350-824A-4C74-9909-D09E448A348E@felipegasper.com>
 <96F3B6F4-DC58-48D0-BCB6-1A8210938155@felipegasper.com>
 <CAA2GJqWwDrnLfX1uJqGPj_+WFPkigHd=P-+g+c+jp=m-jS+BEA@mail.gmail.com>
Message-ID: <2E275AC8-D08B-4CEC-8136-3247AE7FDFAA@felipegasper.com>



> On Mar 17, 2019, at 7:55 PM, J Decker <d3ck0r at gmail.com> wrote:
> 
>> On Sun, Mar 17, 2019 at 4:46 PM Felipe Gasper <felipe at felipegasper.com> wrote:
>> Buffer, not buffet. Silly autocorrect!
>> 
>> -F
>> 
>> > On Mar 17, 2019, at 7:21 PM, Felipe Gasper <felipe at felipegasper.com> wrote:
>> > 
>> > Hello,
>> > 
>> > Is there any equivalent to SSL_CTX_use_certificate_chain_file for a PEM buffet that?s already in memory?
> SSL_CTX_use_certificate( ses->ctx, sk_X509_value( ses->cert->chain, 0 ) ); ? 
> SSL_CTX_add_extra_chain_cert( ses->ctx, sk_X509_value( ses->cert->chain, n ) );

Yeah, but then I have to determine how many certs are in the bundle, parse it, etc. I was hoping to get a function that does all of that in one fell swoop like the ..._file() function.

I mean, I guess I can copy/paste and tweak for now. Would a refactor in a PR be of interest?

-FG


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

From d3ck0r at gmail.com  Mon Mar 18 00:28:27 2019
From: d3ck0r at gmail.com (J Decker)
Date: Sun, 17 Mar 2019 17:28:27 -0700
Subject: In-memory SSL_CTX_use_certificate_chain_file?
In-Reply-To: <2E275AC8-D08B-4CEC-8136-3247AE7FDFAA@felipegasper.com>
References: <3C766350-824A-4C74-9909-D09E448A348E@felipegasper.com>
 <96F3B6F4-DC58-48D0-BCB6-1A8210938155@felipegasper.com>
 <CAA2GJqWwDrnLfX1uJqGPj_+WFPkigHd=P-+g+c+jp=m-jS+BEA@mail.gmail.com>
 <2E275AC8-D08B-4CEC-8136-3247AE7FDFAA@felipegasper.com>
Message-ID: <CAA2GJqWiyxVQiHw7N1nXeRSFVd318ENwCA_g2vFnp+18tYpJLA@mail.gmail.com>

On Sun, Mar 17, 2019 at 5:17 PM Felipe Gasper <felipe at felipegasper.com>
wrote:

>
>
> On Mar 17, 2019, at 7:55 PM, J Decker <d3ck0r at gmail.com> wrote:
>
>
> On Sun, Mar 17, 2019 at 4:46 PM Felipe Gasper <felipe at felipegasper.com>
> wrote:
>
>> Buffer, not buffet. Silly autocorrect!
>>
>> -F
>>
>> > On Mar 17, 2019, at 7:21 PM, Felipe Gasper <felipe at felipegasper.com>
>> wrote:
>> >
>> > Hello,
>> >
>> > Is there any equivalent to SSL_CTX_use_certificate_chain_file for a PEM
>> buffet that?s already in memory?
>>
> SSL_CTX_use_certificate( ses->ctx, sk_X509_value( ses->cert->chain, 0 ) );
> ?
> SSL_CTX_add_extra_chain_cert( ses->ctx, sk_X509_value( ses->cert->chain, n
> ) );
>
>
> Yeah, but then I have to determine how many certs are in the bundle, parse
> it, etc. I was hoping to get a function that does all of that in one fell
> swoop like the ..._file() function.
>
> I mean, I guess I can copy/paste and tweak for now. Would a refactor in a
> PR be of interest?
>
>
that top of this takes the input, uses bio to parse into x509 stack, and
then uses the stack setting up the ctx...

https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L665-L753


> -FG
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190317/198ec796/attachment.html>

From openssl-users at dukhovni.org  Mon Mar 18 02:55:41 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 17 Mar 2019 22:55:41 -0400
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
References: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
Message-ID: <20190318025541.GK3822@straasha.imrryr.org>

On Mon, Mar 18, 2019 at 01:06:19AM +0200, Graham Leggett wrote:

> [root at localhost ~]# openssl req -in req.bin -inform der
> unable to load X509 request
> 139903756527504:error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287:
> 139903756527504:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:720:Field=algorithm, Type=X509_ALGOR
> 139903756527504:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:720:Field=sig_alg, Type=X509_REQ

The CSR is malformed.

> The CSR can be found here: http://www.sharp.fm/req.bin
> 
> Would it be possible to confirm what is wrong with this request?

Running "openssl asn1parse -inform DER" we get:

	0:d=0  hl=4 l= 509 cons: SEQUENCE
	4:d=1  hl=4 l= 498 cons: SEQUENCE
	8:d=2  hl=2 l=   1 prim: INTEGER           :00
       11:d=2  hl=2 l=  67 cons: SEQUENCE
       13:d=3  hl=2 l=  14 cons: SET
       15:d=4  hl=2 l=  12 cons: SEQUENCE
       17:d=5  hl=2 l=   3 prim: OBJECT            :commonName
       22:d=5  hl=2 l=   5 prim: UTF8STRING        :Test1
       29:d=3  hl=2 l=  49 cons: SET
       31:d=4  hl=2 l=  47 cons: SEQUENCE
       33:d=5  hl=2 l=   3 prim: OBJECT            :serialNumber
       38:d=5  hl=2 l=  40 prim: PRINTABLESTRING   :354616bb0358f9474f1e84af5550567f8b6c4d5b
       80:d=2  hl=4 l= 290 cons: SEQUENCE
       84:d=3  hl=2 l=  13 cons: SEQUENCE
       86:d=4  hl=2 l=   9 prim: OBJECT            :rsaEncryption
       97:d=4  hl=2 l=   0 prim: NULL
       99:d=3  hl=4 l= 271 prim: BIT STRING
      374:d=2  hl=3 l= 129 cons: cont [ 0 ]
      377:d=3  hl=2 l=  42 cons: SEQUENCE
      379:d=4  hl=2 l=   9 prim: OBJECT            :challengePassword
      390:d=4  hl=2 l=  29 cons: SET
      392:d=5  hl=2 l=  27 prim: IA5STRING         :dfwrrdq4uhec96yj23io8soav0
      421:d=3  hl=2 l=  83 cons: SEQUENCE
      423:d=4  hl=2 l=   9 prim: OBJECT            :Extension Request
      434:d=4  hl=2 l=  70 cons: SET
      436:d=5  hl=2 l=  68 cons: SEQUENCE
      438:d=6  hl=2 l=  66 cons: SEQUENCE
      440:d=7  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Alternative Name
      445:d=7  hl=2 l=  59 prim: OCTET STRING      [HEX DUMP]:303981373335343631366262303335386639343734663165383461663535353035363766386236633464356240756B2E736173686B65792E6F7267
      506:d=1  hl=2 l=   2 cons: SEQUENCE
      508:d=2  hl=2 l=   0 prim: OBJECT            :BAD OBJECT:[]
      510:d=1  hl=2 l=   1 prim: BIT STRING

Whereas with:

    $ openssl req -config <(
	    printf "distinguished_name = dn\n[dn]\nprompt=yes\n[v3req]\n%s\n" \
                   "subjectAltName = DNS:example.com"
        ) -reqexts v3req -new -newkey rsa:1024 -keyout /dev/null \
          -nodes -subj / 2>/dev/null | openssl asn1parse

we get:

	0:d=0  hl=4 l= 360 cons: SEQUENCE
	4:d=1  hl=3 l= 210 cons: SEQUENCE
	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
      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

which has a non-zero length signature algorithm OID (l = 9).  Your
example has "l=0" where one would expect the signature OID after
the extensions.

-- 
	Viktor.

From minfrin at sharp.fm  Mon Mar 18 10:51:53 2019
From: minfrin at sharp.fm (Graham Leggett)
Date: Mon, 18 Mar 2019 12:51:53 +0200
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <20190318025541.GK3822@straasha.imrryr.org>
References: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
 <20190318025541.GK3822@straasha.imrryr.org>
Message-ID: <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>

On 18 Mar 2019, at 04:55, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:

> On Mon, Mar 18, 2019 at 01:06:19AM +0200, Graham Leggett wrote:
> 
>> [root at localhost ~]# openssl req -in req.bin -inform der
>> unable to load X509 request
>> 139903756527504:error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287:
>> 139903756527504:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:720:Field=algorithm, Type=X509_ALGOR
>> 139903756527504:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:720:Field=sig_alg, Type=X509_REQ
> 
> The CSR is malformed.

The CSR is incomplete, but isn?t malformed.

The CSR is the in the process of being built. Part of that process involves sending the partially complete CSR to another module, which then completes the CSR structure. This used to work, but has regressed when moving from rhel6 to rhel7.

> which has a non-zero length signature algorithm OID (l = 9).  Your
> example has "l=0" where one would expect the signature OID after
> the extensions.

How do I fix openssl to parse this as it did before?

Regards,
Graham
?


From minfrin at sharp.fm  Mon Mar 18 12:22:26 2019
From: minfrin at sharp.fm (Graham Leggett)
Date: Mon, 18 Mar 2019 14:22:26 +0200
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
References: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
 <20190318025541.GK3822@straasha.imrryr.org>
 <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
Message-ID: <0DABA868-D25C-4783-952C-C07DBE9E58ED@sharp.fm>

On 18 Mar 2019, at 12:51, Graham Leggett <minfrin at sharp.fm> wrote:

>> which has a non-zero length signature algorithm OID (l = 9).  Your
>> example has "l=0" where one would expect the signature OID after
>> the extensions.
> 
> How do I fix openssl to parse this as it did before?

I've raised this at https://github.com/openssl/openssl/issues/8514 to give more context.

Regards,
Graham
?


From openssl-users at dukhovni.org  Mon Mar 18 16:49:41 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 18 Mar 2019 12:49:41 -0400
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
References: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
 <20190318025541.GK3822@straasha.imrryr.org>
 <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
Message-ID: <A2E1FA0F-8BE7-4A3E-808D-A3D599C81AAC@dukhovni.org>



> On Mar 18, 2019, at 6:51 AM, Graham Leggett <minfrin at sharp.fm> wrote:
> 
> The CSR is incomplete, but isn?t malformed.

A mandatory part of the CSR is missing.  It is malformed.

> The CSR is the in the process of being built. Part of that process involves sending the partially complete CSR to another module, which then completes the CSR structure. This used to work, but has regressed when moving from rhel6 to rhel7.
> 
>> which has a non-zero length signature algorithm OID (l = 9).  Your
>> example has "l=0" where one would expect the signature OID after
>> the extensions.
> 
> How do I fix openssl to parse this as it did before?

Since you don't have a CSR, the fix is to not attempt to encode the data
as a CSR.  It sounds like what you have is a CRI (that is a
CertificationRequestInfo structure) so you'll need to encode that instead.

  https://tools.ietf.org/html/rfc2986#section-4

The relevant codec functions are:  i2d_X509_REQ_INFO and d2i_X509_REQ_INFO.

A CSR is:

   CertificationRequest ::= SEQUENCE {
        certificationRequestInfo CertificationRequestInfo,
        signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
        signature          BIT STRING
   }

which encapsulates the CRI a larger signed structure, adding precisely
the bits you're missing.

An alternative (if you must) is to create an actual CSR, with a dummy
signature OID, and signature and then ignore the signature on the other
side.

-- 
	Viktor.


From minfrin at sharp.fm  Mon Mar 18 19:51:02 2019
From: minfrin at sharp.fm (Graham Leggett)
Date: Mon, 18 Mar 2019 21:51:02 +0200
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <A2E1FA0F-8BE7-4A3E-808D-A3D599C81AAC@dukhovni.org>
References: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
 <20190318025541.GK3822@straasha.imrryr.org>
 <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
 <A2E1FA0F-8BE7-4A3E-808D-A3D599C81AAC@dukhovni.org>
Message-ID: <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>

On 18 Mar 2019, at 18:49, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:

> A mandatory part of the CSR is missing.  It is malformed.

Some further digging shows the CSR is indeed malformed - the old openssl code created a CSR like this:

  507:d=2  hl=2 l=   1 prim: OBJECT            :itu-t

while the new openssl code produces a CSR like this:

  508:d=2  hl=2 l=   0 prim: OBJECT            :BAD OBJECT

It looks like X509_REQ_new() in older versions of openssl created an object with an empty signature, while the new code produces a bad signature.

> Since you don't have a CSR, the fix is to not attempt to encode the data
> as a CSR.  It sounds like what you have is a CRI (that is a
> CertificationRequestInfo structure) so you'll need to encode that instead.
> 
>  https://tools.ietf.org/html/rfc2986#section-4
> 
> The relevant codec functions are:  i2d_X509_REQ_INFO and d2i_X509_REQ_INFO.
> 
> A CSR is:
> 
>   CertificationRequest ::= SEQUENCE {
>        certificationRequestInfo CertificationRequestInfo,
>        signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
>        signature          BIT STRING
>   }
> 
> which encapsulates the CRI a larger signed structure, adding precisely
> the bits you're missing.

This makes sense - however there don?t appear to be any APIs in openssl that allow you to manipulate a X509_REQ_INFO structure. I can create it, and encode/decode it, but there is no X509_REQ_INFO_get_subject_name() (or friends) to populate the structure. X509_REQ_INFO itself is opaque.

> An alternative (if you must) is to create an actual CSR, with a dummy
> signature OID, and signature and then ignore the signature on the other
> side.

This looks like a workaround for now, what API call would I use to do that?

The X509_REQ structure is opaque, so I can?t see what options I have for setting any OIDs.

Regards,
Graham
?


From dcoombs at carillon.ca  Mon Mar 18 20:02:02 2019
From: dcoombs at carillon.ca (Dave Coombs)
Date: Mon, 18 Mar 2019 16:02:02 -0400
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
References: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
 <20190318025541.GK3822@straasha.imrryr.org>
 <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
 <A2E1FA0F-8BE7-4A3E-808D-A3D599C81AAC@dukhovni.org>
 <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
Message-ID: <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>

> This makes sense - however there don?t appear to be any APIs in openssl that allow you to manipulate a X509_REQ_INFO structure. I can create it, and encode/decode it, but there is no X509_REQ_INFO_get_subject_name() (or friends) to populate the structure. X509_REQ_INFO itself is opaque.

I believe you said you're using 1.0.2, right?  The structures aren't opaque there.  You can make your X509_REQ and populate its name etc as you already are, and then i2d_X509_REQ_INFO its req_info member.

(Even in the 1.1 API, where they are opaque, i2d_re_X509_REQ_tbs will encode a given X509_REQ's X509_REQ_INFO for you.)

Good luck,
  -Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 9677 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190318/358478b0/attachment.bin>

From openssl-users at dukhovni.org  Mon Mar 18 20:27:19 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 18 Mar 2019 16:27:19 -0400
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
References: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
 <20190318025541.GK3822@straasha.imrryr.org>
 <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
 <A2E1FA0F-8BE7-4A3E-808D-A3D599C81AAC@dukhovni.org>
 <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
Message-ID: <7D9DBE8E-C71B-470D-B935-CC8B841EC52F@dukhovni.org>

> On Mar 18, 2019, at 4:02 PM, Dave Coombs <dcoombs at carillon.ca> wrote:
> 
> (Even in the 1.1 API, where they are opaque, i2d_re_X509_REQ_tbs will encode a given X509_REQ's X509_REQ_INFO for you.)

Yes, i2d_re_X509_REQ_tbs is the key function for constructing the
"to be signed" (tbs) request:

  int i2d_re_X509_REQ_tbs(X509_REQ *req, unsigned char **pp)
  {
      req->req_info.enc.modified = 1;
      return i2d_X509_REQ_INFO(&req->req_info, pp);
  }

By setting the "modified" bit, it ensures that the DER representation
will be re-generated with any changes made to the object.

So the OP can create the "partially filled in" X509_REQ and then call
i2d_re_X509_REQ_tbs() function to generate the DER CRI blob to sign. 
This removes any temptation to "cheat" by just casting the (X509_REQ *)
as an (X509_REQ_INFO *) and calling i2d_X509_REQ_INFO() on that (first
member of the X509_REQ structure).  The i2d_re_X509_REQ_tbs() function
achieves the same effect in a type safe supported manner.

-- 
	Viktor.


From zeev.tarantov at gmail.com  Mon Mar 18 23:05:14 2019
From: zeev.tarantov at gmail.com (Zeev Tarantov)
Date: Tue, 19 Mar 2019 01:05:14 +0200
Subject: Default DHE group
Message-ID: <CAMzrhQ_kkGC6rKKD25zWjO+-KY-t9J0of0uYenbzkrDOt_RTDA@mail.gmail.com>

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

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!

In case dh_auto was set, why doesn't openssl use the RFC 7919 groups also
with TLS versions below 1.3?
They are much more reputable than RFC 5114, which is what you get with an
RSA-2048 certificate, which is most common.

If this is fixed, maybe maybe TLS server software using openssl will be
able to switch to SSL_CTX_set_dh_auto, which will result in many more
server using secure key agreement. The alternative is that slowly people
will converge on the Google Chrome decision to disable DHE. Maybe it is
already too late, but perhaps with can still be done in openssl 1.1.1.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190319/01157250/attachment.html>

From minfrin at sharp.fm  Mon Mar 18 23:34:06 2019
From: minfrin at sharp.fm (Graham Leggett)
Date: Tue, 19 Mar 2019 01:34:06 +0200
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <7D9DBE8E-C71B-470D-B935-CC8B841EC52F@dukhovni.org>
References: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
 <20190318025541.GK3822@straasha.imrryr.org>
 <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
 <A2E1FA0F-8BE7-4A3E-808D-A3D599C81AAC@dukhovni.org>
 <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
 <7D9DBE8E-C71B-470D-B935-CC8B841EC52F@dukhovni.org>
Message-ID: <1F1D5938-6CB9-4F57-9959-DD12E02871F0@sharp.fm>

On 18 Mar 2019, at 22:27, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:

>> (Even in the 1.1 API, where they are opaque, i2d_re_X509_REQ_tbs will encode a given X509_REQ's X509_REQ_INFO for you.)
> 
> Yes, i2d_re_X509_REQ_tbs is the key function for constructing the
> "to be signed" (tbs) request:
> 
>  int i2d_re_X509_REQ_tbs(X509_REQ *req, unsigned char **pp)
>  {
>      req->req_info.enc.modified = 1;
>      return i2d_X509_REQ_INFO(&req->req_info, pp);
>  }
> 
> By setting the "modified" bit, it ensures that the DER representation
> will be re-generated with any changes made to the object.
> 
> So the OP can create the "partially filled in" X509_REQ and then call
> i2d_re_X509_REQ_tbs() function to generate the DER CRI blob to sign. 
> This removes any temptation to "cheat" by just casting the (X509_REQ *)
> as an (X509_REQ_INFO *) and calling i2d_X509_REQ_INFO() on that (first
> member of the X509_REQ structure).  The i2d_re_X509_REQ_tbs() function
> achieves the same effect in a type safe supported manner.

Can you confirm what structure is being encoded by i2d_re_X509_REQ_tbs, is this a X509_REQ_INFO?

The man page doesn?t explicitly specify the output formats of any of the related functions:

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

Looking at the source, we have X509_REQ_INFO being returned:

int i2d_re_X509_REQ_tbs(X509_REQ *req, unsigned char **pp)
{
    req->req_info.enc.modified = 1;
    return i2d_X509_REQ_INFO(&req->req_info, pp);
}

What would the corresponding functions need to be in the openssl v1.0.x world to achieve the same output as i2d_re_X509_REQ_tbs?

Would it just be to copy the above code in?

Regards,
Graham
?

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

From minfrin at sharp.fm  Tue Mar 19 00:22:00 2019
From: minfrin at sharp.fm (Graham Leggett)
Date: Tue, 19 Mar 2019 02:22:00 +0200
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
References: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
 <20190318025541.GK3822@straasha.imrryr.org>
 <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
 <A2E1FA0F-8BE7-4A3E-808D-A3D599C81AAC@dukhovni.org>
 <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
Message-ID: <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>

On 18 Mar 2019, at 22:02, Dave Coombs <dcoombs at carillon.ca> wrote:

>> This makes sense - however there don?t appear to be any APIs in openssl that allow you to manipulate a X509_REQ_INFO structure. I can create it, and encode/decode it, but there is no X509_REQ_INFO_get_subject_name() (or friends) to populate the structure. X509_REQ_INFO itself is opaque.
> 
> I believe you said you're using 1.0.2, right?  The structures aren't opaque there.  You can make your X509_REQ and populate its name etc as you already are, and then i2d_X509_REQ_INFO its req_info member.
> 
> (Even in the 1.1 API, where they are opaque, i2d_re_X509_REQ_tbs will encode a given X509_REQ's X509_REQ_INFO for you.)

How would I decode the X509_REQ_INFO structure on the other side, turning it back into X509_REQ?

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?

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:

https://source.redwax.eu/projects/RS/repos/mod_ca/browse/mod_ca_ldap.c#368

Regards,
Graham
?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3260 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190319/d62a00d7/attachment.bin>

From openssl-users at dukhovni.org  Tue Mar 19 01:22:52 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 18 Mar 2019 21:22:52 -0400
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>
References: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
 <20190318025541.GK3822@straasha.imrryr.org>
 <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
 <A2E1FA0F-8BE7-4A3E-808D-A3D599C81AAC@dukhovni.org>
 <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
 <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>
Message-ID: <199E4877-FE72-4A9A-97B6-B65CEF0B574C@dukhovni.org>

> On Mar 18, 2019, at 8:22 PM, Graham Leggett <minfrin at sharp.fm> 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?

> 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.

> 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"?

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.

-- 
	Viktor.


From rama.krushna7 at gmail.com  Tue Mar 19 04:38:58 2019
From: rama.krushna7 at gmail.com (ramakrushna mishra)
Date: Tue, 19 Mar 2019 10:08:58 +0530
Subject: Reg solaris support for openssl 1.1.1b
In-Reply-To: <mailman.13797.1552697382.21411.openssl-users@openssl.org>
References: <mailman.13797.1552697382.21411.openssl-users@openssl.org>
Message-ID: <CAHgr=kL=NS9=YeJ99DtxXgA=+BZbPauu-T1D_XYLddPJamssuQ@mail.gmail.com>

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.

There is another suggestion to "compile with a RUNPATH set in the
output ELF files.  " . Could anyone please provide more details about this
and how to do it ?

Thanks and Regards,
Ram Krushna
On Sat, Mar 16, 2019 at 6:20 AM <openssl-users-request at openssl.org> wrote:

> Send openssl-users mailing list submissions to
>         openssl-users at openssl.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
>         openssl-users-request at openssl.org
>
> You can reach the person managing the list at
>         openssl-users-owner at openssl.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
>
>
> Today's Topics:
>
>    1. Re: Reg solaris support for openssl 1.1.1b (Jakob Bohm)
>    5. Re: Reg solaris support for openssl 1.1.1b (Dennis Clarke)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 15 Mar 2019 18:19:53 +0100
> From: Jakob Bohm <jb-openssl at wisemo.com>
> To: openssl-users at openssl.org
> Subject: Re: Reg solaris support for openssl 1.1.1b
> Message-ID: <649ef06e-0f64-65bb-cb43-cfde681fd117 at wisemo.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 15/03/2019 14:33, Dennis Clarke wrote:
> > On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
> >> My guess is that your binary is loading the system's shared libraries.
> >> To find out whether this is the case, try
> >>
> >>  ??? ldd bin/openssl
> >>
> >> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
> >> explicitely.
> > Actually LD_LIBRARY_PATH is evil.
> >
> > The correct way to do this is to compile with a RUNPATH set in the
> > output ELF files.
> LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
> testing
> a newly compiled binary before installing the libraries to their final
> locations, perhaps
> on the same, perhaps on another machine.
>
> P.S.
> I don't known if the Solaris loader lets LD_LIBRARY_PATH override
> RUNPATH as
> presumed by the above answer.
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
>
> ------------------------------
> Message: 5
> Date: Fri, 15 Mar 2019 20:49:30 -0400
> From: Dennis Clarke <dclarke at blastwave.org>
> To: openssl-users at openssl.org
> Subject: Re: Reg solaris support for openssl 1.1.1b
> Message-ID: <4b08232c-f734-987c-814c-5acef59f42ab at blastwave.org>
> Content-Type: text/plain; charset=utf-8
>
> On 3/15/19 1:19 PM, Jakob Bohm via openssl-users wrote:
> > On 15/03/2019 14:33, Dennis Clarke wrote:
> >> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
> >>> My guess is that your binary is loading the system's shared libraries.
> >>> To find out whether this is the case, try
> >>>
> >>> ???? ldd bin/openssl
> >>>
> >>> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
> >>> explicitely.
> >> Actually LD_LIBRARY_PATH is evil.
> >>
> >> The correct way to do this is to compile with a RUNPATH set in the
> >> output ELF files.
> > LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
> > testing
> > a newly compiled binary before installing the libraries to their final
> > locations, perhaps
> > on the same, perhaps on another machine.
> >
> > P.S.
> > I don't known if the Solaris loader lets LD_LIBRARY_PATH override
> > RUNPATH as
> > presumed by the above answer.
>
> Yes it certainly does. Otherwise testing a new custom lib would be a
> royal pain as opposed to just a pain.  Also most people still, after
> twenty years, know what LD_LIBRARY_PATH env var is for and it is a waste
> of breath trying to explain it after decades of watching folks skewer
> themselves over and over and over ....
>
> dc
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> ------------------------------
>
> End of openssl-users Digest, Vol 52, Issue 19
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190319/826d3d95/attachment.html>

From sojulibra at gmail.com  Tue Mar 19 07:08:56 2019
From: sojulibra at gmail.com (=?UTF-8?B?55Sw5Lit5Ym15qi5?=)
Date: Tue, 19 Mar 2019 16:08:56 +0900
Subject: Building OpenSSL 1.1.1b for WinCE700
Message-ID: <CAPvkBARR=o2gm4ZztcN3oY6MY1tVgaXeVsQbikhgQQXDbAcyVQ@mail.gmail.com>

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 <winbase.h>" 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190319/693b80b4/attachment.html>

From thework.vlpl at gmail.com  Tue Mar 19 07:26:44 2019
From: thework.vlpl at gmail.com (work vlpl)
Date: Tue, 19 Mar 2019 13:26:44 +0600
Subject: How I can add extension with sequence value to CSR using openssl
 library?
Message-ID: <CAPt3fZgAMtraEqCYmhDeBnjQFg+SDUvkXe3Zk2Rd449vXdAGLA@mail.gmail.com>

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?

From dclarke at blastwave.org  Tue Mar 19 07:40:31 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Tue, 19 Mar 2019 07:40:31 +0000
Subject: Reg solaris support for openssl 1.1.1b
In-Reply-To: <CAHgr=kL=NS9=YeJ99DtxXgA=+BZbPauu-T1D_XYLddPJamssuQ@mail.gmail.com>
References: <mailman.13797.1552697382.21411.openssl-users@openssl.org>
 <CAHgr=kL=NS9=YeJ99DtxXgA=+BZbPauu-T1D_XYLddPJamssuQ@mail.gmail.com>
Message-ID: <50313fb7-c9f9-93fd-8a8a-b97efa261763@blastwave.org>

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

From swamy.j-s at in.abb.com  Tue Mar 19 07:55:53 2019
From: swamy.j-s at in.abb.com (Swamy J-S)
Date: Tue, 19 Mar 2019 07:55:53 +0000
Subject: cURL with openSSL 1.1.1 version
Message-ID: <HE1PR0602MB3643DF1FD528D8783EF804BF96400@HE1PR0602MB3643.eurprd06.prod.outlook.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190319/526252b5/attachment.html>

From Maxime.Torrelli at conduent.com  Tue Mar 19 08:25:17 2019
From: Maxime.Torrelli at conduent.com (Torrelli, Maxime)
Date: Tue, 19 Mar 2019 08:25:17 +0000
Subject: Building OpenSSL 1.1.1b for WinCE700
In-Reply-To: <CAPvkBARR=o2gm4ZztcN3oY6MY1tVgaXeVsQbikhgQQXDbAcyVQ@mail.gmail.com>
References: <CAPvkBARR=o2gm4ZztcN3oY6MY1tVgaXeVsQbikhgQQXDbAcyVQ@mail.gmail.com>
Message-ID: <BN6PR2001MB0963DB939A0AD55AE3FB983595400@BN6PR2001MB0963.namprd20.prod.outlook.com>

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 <openssl-users-bounces at openssl.org> De la part de ????
Envoy? : 19 March 2019 08:09
? : openssl-users at 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 <winbase.h>" 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190319/74db1286/attachment-0001.html>

From nic.tuv at gmail.com  Tue Mar 19 08:52:17 2019
From: nic.tuv at gmail.com (Nicola)
Date: Tue, 19 Mar 2019 10:52:17 +0200
Subject: cURL with openSSL 1.1.1 version
In-Reply-To: <HE1PR0602MB3643DF1FD528D8783EF804BF96400@HE1PR0602MB3643.eurprd06.prod.outlook.com>
References: <HE1PR0602MB3643DF1FD528D8783EF804BF96400@HE1PR0602MB3643.eurprd06.prod.outlook.com>
Message-ID: <CANm5x_P5mtdN0Pa5GrzsEus6OVrHNZ_sY4rRXTGvf2d3rBYLMA@mail.gmail.com>

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 <swamy.j-s at in.abb.com> 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*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190319/44e98ae2/attachment.html>

From matt at openssl.org  Tue Mar 19 09:38:58 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 19 Mar 2019 09:38:58 +0000
Subject: Building OpenSSL 1.1.1b for WinCE700
In-Reply-To: <CAPvkBARR=o2gm4ZztcN3oY6MY1tVgaXeVsQbikhgQQXDbAcyVQ@mail.gmail.com>
References: <CAPvkBARR=o2gm4ZztcN3oY6MY1tVgaXeVsQbikhgQQXDbAcyVQ@mail.gmail.com>
Message-ID: <b1073375-e52e-c9e6-2bc8-8b5bc4e05350@openssl.org>



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 <winbase.h>" 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
> 

From matt at openssl.org  Tue Mar 19 11:36:07 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 19 Mar 2019 11:36:07 +0000
Subject: Default DHE group
In-Reply-To: <CAMzrhQ_kkGC6rKKD25zWjO+-KY-t9J0of0uYenbzkrDOt_RTDA@mail.gmail.com>
References: <CAMzrhQ_kkGC6rKKD25zWjO+-KY-t9J0of0uYenbzkrDOt_RTDA@mail.gmail.com>
Message-ID: <369dccfc-a42a-87dc-48d1-0413bf4aeb5d@openssl.org>



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

From minfrin at sharp.fm  Tue Mar 19 12:04:14 2019
From: minfrin at sharp.fm (Graham Leggett)
Date: Tue, 19 Mar 2019 14:04:14 +0200
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <199E4877-FE72-4A9A-97B6-B65CEF0B574C@dukhovni.org>
References: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
 <20190318025541.GK3822@straasha.imrryr.org>
 <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
 <A2E1FA0F-8BE7-4A3E-808D-A3D599C81AAC@dukhovni.org>
 <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
 <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>
 <199E4877-FE72-4A9A-97B6-B65CEF0B574C@dukhovni.org>
Message-ID: <65906247-0744-40D8-8463-15EA01BC447E@sharp.fm>

On 19 Mar 2019, at 03:22, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:

>> On Mar 18, 2019, at 8:22 PM, Graham Leggett <minfrin at sharp.fm> 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
?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3260 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190319/faffcd06/attachment-0001.bin>

From graeme.perrow at sap.com  Tue Mar 19 13:40:19 2019
From: graeme.perrow at sap.com (Perrow, Graeme)
Date: Tue, 19 Mar 2019 13:40:19 +0000
Subject: Differences in defaults between 1.0.2 and 1.1.1
Message-ID: <VI1PR0201MB228605E22D6A22066B947507ED400@VI1PR0201MB2286.eurprd02.prod.outlook.com>

I have an LDAP server that accepts TLS connections, and I can make a connection to it using "openssl s_client -showcerts -host <host>:<port> -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(00000184)
write to 0x2917b30 [0x2928090] (326 bytes => 326 (0x146))
0000 - 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


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

From hkario at redhat.com  Tue Mar 19 14:21:50 2019
From: hkario at redhat.com (Hubert Kario)
Date: Tue, 19 Mar 2019 15:21:50 +0100
Subject: Differences in defaults between 1.0.2 and 1.1.1
In-Reply-To: <VI1PR0201MB228605E22D6A22066B947507ED400@VI1PR0201MB2286.eurprd02.prod.outlook.com>
References: <VI1PR0201MB228605E22D6A22066B947507ED400@VI1PR0201MB2286.eurprd02.prod.outlook.com>
Message-ID: <19914453.XeVdCo3Cv0@pintsize.usersys.redhat.com>

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 <host>:<port>
> -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(00000184)
> write to 0x2917b30 [0x2928090] (326 bytes => 326 (0x146))
> 0000 - 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190319/e2cbe076/attachment.sig>

From matt at openssl.org  Tue Mar 19 14:23:03 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 19 Mar 2019 14:23:03 +0000
Subject: Differences in defaults between 1.0.2 and 1.1.1
In-Reply-To: <VI1PR0201MB228605E22D6A22066B947507ED400@VI1PR0201MB2286.eurprd02.prod.outlook.com>
References: <VI1PR0201MB228605E22D6A22066B947507ED400@VI1PR0201MB2286.eurprd02.prod.outlook.com>
Message-ID: <8dbdc022-1af7-480a-9f89-dc98fab0e007@openssl.org>



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 <host>:<port> -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

From graeme.perrow at sap.com  Tue Mar 19 15:15:04 2019
From: graeme.perrow at sap.com (Perrow, Graeme)
Date: Tue, 19 Mar 2019 15:15:04 +0000
Subject: Differences in defaults between 1.0.2 and 1.1.1
In-Reply-To: <8dbdc022-1af7-480a-9f89-dc98fab0e007@openssl.org>
References: <VI1PR0201MB228605E22D6A22066B947507ED400@VI1PR0201MB2286.eurprd02.prod.outlook.com>
 <8dbdc022-1af7-480a-9f89-dc98fab0e007@openssl.org>
Message-ID: <VI1PR0201MB228693E9419155D6045797FEED400@VI1PR0201MB2286.eurprd02.prod.outlook.com>

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 <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
Sent: March 19, 2019 10:23 AM
To: openssl-users at 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 <host>:<port> -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

From matt at openssl.org  Tue Mar 19 15:38:14 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 19 Mar 2019 15:38:14 +0000
Subject: Differences in defaults between 1.0.2 and 1.1.1
In-Reply-To: <VI1PR0201MB228693E9419155D6045797FEED400@VI1PR0201MB2286.eurprd02.prod.outlook.com>
References: <VI1PR0201MB228605E22D6A22066B947507ED400@VI1PR0201MB2286.eurprd02.prod.outlook.com>
 <8dbdc022-1af7-480a-9f89-dc98fab0e007@openssl.org>
 <VI1PR0201MB228693E9419155D6045797FEED400@VI1PR0201MB2286.eurprd02.prod.outlook.com>
Message-ID: <94ee91d4-d54e-3346-dd47-2dbf2f72229d@openssl.org>



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
> <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell Sent: March 19,
> 2019 10:23 AM To: openssl-users at 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 <host>:<port> -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
> 

From openssl-users at dukhovni.org  Tue Mar 19 16:00:12 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 19 Mar 2019 12:00:12 -0400
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <65906247-0744-40D8-8463-15EA01BC447E@sharp.fm>
References: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
 <20190318025541.GK3822@straasha.imrryr.org>
 <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
 <A2E1FA0F-8BE7-4A3E-808D-A3D599C81AAC@dukhovni.org>
 <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
 <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>
 <199E4877-FE72-4A9A-97B6-B65CEF0B574C@dukhovni.org>
 <65906247-0744-40D8-8463-15EA01BC447E@sharp.fm>
Message-ID: <20190319160012.GN3822@straasha.imrryr.org>

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 -config <(
	printf "distinguished_name = dn\n[dn]\nprompt=yes\n[v3req]\n%s\n" \
		       "subjectAltName = DNS:example.com"
	    ) \
	-reqexts v3req -new -newkey rsa:1024 -keyout /dev/null \
        -nodes -subj / 2>/dev/null |
        openssl req -outform DER |
        hexdump -ve '16/1 " %02x" "\n"'
     30 82 01 68 30 81 d2 02 01 00 30 00 30 81 9f 30
#    wrapper -->|<-- CRI DER begins here
     0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 81
     8d 00 30 81 89 02 81 81 00 d0 61 3e 71 9c f6 a1
     d0 bd cf 7c f2 e6 be a2 5b 59 4a f5 8f 32 9d d6
     47 38 43 1a 57 51 18 bd e1 a2 1d 52 d0 8d c5 79
     07 c4 3c 78 19 5c ca c7 37 69 2a 22 70 05 e1 ab
     ec 35 b2 2b 1d 46 f7 8f b9 bd 30 27 08 81 1c ac
     81 a1 c3 ed 5b 9f 9e 46 22 d3 28 45 3c 85 36 30
     7e 11 46 ae 65 d0 8b 1d 19 28 3b 76 d6 f0 fd 59
     b3 62 5a e9 45 21 92 29 1d 0f af ad 87 c9 33 fc
     3d 87 5f 68 98 96 89 a6 b3 02 03 01 00 01 a0 29
     30 27 06 09 2a 86 48 86 f7 0d 01 09 0e 31 1a 30
     18 30 16 06 03 55 1d 11 04 0f 30 0d 82 0b 65 78
     61 6d 70 6c 65 2e 63 6f 6d 30 0d 06 09 2a 86 48
#    CRI DER ends here ------->|<--- begin sig OID
     86 f7 0d 01 01 0b 05 00 03 81 81 00 00 00 00 00
#    end sig OID ---->| null|<- 1024 zeroed sig bits
     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     00 00 00 00 00 00 00 00 00 00 00 00
#                                       |<-- end sig

Appending a fixed 147 byte suffix, and prepending an outer sequence
tag and length is not difficult.  But, since the signature is fake
anyway, it could be much shorter, for example truncating it to an
8-bit "0" signature (19 byte suffix with the OID and null parameters),
I get:

    $ perl -pe 's/\s//g; s/(..)/chr(hex($1))/eg;' <<-EOF | openssl req -inform DER -text
	 30 81 e8 30 81 d2 02 01 00 30 00 30 81 9f 30
	 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 81
	 8d 00 30 81 89 02 81 81 00 d0 61 3e 71 9c f6 a1
	 d0 bd cf 7c f2 e6 be a2 5b 59 4a f5 8f 32 9d d6
	 47 38 43 1a 57 51 18 bd e1 a2 1d 52 d0 8d c5 79
	 07 c4 3c 78 19 5c ca c7 37 69 2a 22 70 05 e1 ab
	 ec 35 b2 2b 1d 46 f7 8f b9 bd 30 27 08 81 1c ac
	 81 a1 c3 ed 5b 9f 9e 46 22 d3 28 45 3c 85 36 30
	 7e 11 46 ae 65 d0 8b 1d 19 28 3b 76 d6 f0 fd 59
	 b3 62 5a e9 45 21 92 29 1d 0f af ad 87 c9 33 fc
	 3d 87 5f 68 98 96 89 a6 b3 02 03 01 00 01 a0 29
	 30 27 06 09 2a 86 48 86 f7 0d 01 09 0e 31 1a 30
	 18 30 16 06 03 55 1d 11 04 0f 30 0d 82 0b 65 78
	 61 6d 70 6c 65 2e 63 6f 6d 30 0d 06 09 2a 86 48
	 86 f7 0d 01 01 0b 05 00 03 02 00 00
	EOF
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: 
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:d0:61:3e:71:9c:f6:a1:d0:bd:cf:7c:f2:e6:be:
                    a2:5b:59:4a:f5:8f:32:9d:d6:47:38:43:1a:57:51:
                    18:bd:e1:a2:1d:52:d0:8d:c5:79:07:c4:3c:78:19:
                    5c:ca:c7:37:69:2a:22:70:05:e1:ab:ec:35:b2:2b:
                    1d:46:f7:8f:b9:bd:30:27:08:81:1c:ac:81:a1:c3:
                    ed:5b:9f:9e:46:22:d3:28:45:3c:85:36:30:7e:11:
                    46:ae:65:d0:8b:1d:19:28:3b:76:d6:f0:fd:59:b3:
                    62:5a:e9:45:21:92:29:1d:0f:af:ad:87:c9:33:fc:
                    3d:87:5f:68:98:96:89:a6:b3
                Exponent: 65537 (0x10001)
        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name: 
                DNS:example.com
    Signature Algorithm: sha256WithRSAEncryption
         00
-----BEGIN CERTIFICATE REQUEST-----
MIHoMIHSAgEAMAAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANBhPnGc9qHQ
vc988ua+oltZSvWPMp3WRzhDGldRGL3hoh1S0I3FeQfEPHgZXMrHN2kqInAF4avs
NbIrHUb3j7m9MCcIgRysgaHD7VufnkYi0yhFPIU2MH4RRq5l0IsdGSg7dtbw/Vmz
YlrpRSGSKR0Pr62HyTP8PYdfaJiWiaazAgMBAAGgKTAnBgkqhkiG9w0BCQ4xGjAY
MBYGA1UdEQQPMA2CC2V4YW1wbGUuY29tMA0GCSqGSIb3DQEBCwUAAwIAAA==
-----END CERTIFICATE REQUEST-----

The prefix would often be 4 bytes (i.e. 16-bit rather than an 8-bit
length), rather than 3.  As, for example always with 2048-bit RSA
subject key.  [ The above CSR is atypically short. ]

-- 
	Viktor.

From andreas.fuchs at sit.fraunhofer.de  Tue Mar 19 16:41:24 2019
From: andreas.fuchs at sit.fraunhofer.de (Fuchs, Andreas)
Date: Tue, 19 Mar 2019 16:41:24 +0000
Subject: Howto prevent cycles in engine invocation ?
Message-ID: <9F48E1A823B03B4790B7E6E69430724D0162E79BF7@EXCH2010B.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

From beldmit at gmail.com  Tue Mar 19 20:09:59 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Tue, 19 Mar 2019 23:09:59 +0300
Subject: Howto prevent cycles in engine invocation ?
In-Reply-To: <9F48E1A823B03B4790B7E6E69430724D0162E79BF7@EXCH2010B.sit.fraunhofer.de>
References: <9F48E1A823B03B4790B7E6E69430724D0162E79BF7@EXCH2010B.sit.fraunhofer.de>
Message-ID: <CADqLbzLW3P2AsAdMGVh52Jh9_JS8jG3x36TZrRGM6=D8ZkJndQ@mail.gmail.com>

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 == &my_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 <andreas.fuchs at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190319/6ab49a3c/attachment-0001.html>

From andreas.fuchs at sit.fraunhofer.de  Tue Mar 19 22:31:21 2019
From: andreas.fuchs at sit.fraunhofer.de (Fuchs, Andreas)
Date: Tue, 19 Mar 2019 22:31:21 +0000
Subject: Howto prevent cycles in engine invocation ?
In-Reply-To: <CADqLbzLW3P2AsAdMGVh52Jh9_JS8jG3x36TZrRGM6=D8ZkJndQ@mail.gmail.com>
References: <9F48E1A823B03B4790B7E6E69430724D0162E79BF7@EXCH2010B.sit.fraunhofer.de>,
 <CADqLbzLW3P2AsAdMGVh52Jh9_JS8jG3x36TZrRGM6=D8ZkJndQ@mail.gmail.com>
Message-ID: <9F48E1A823B03B4790B7E6E69430724D0162E7ADAC@EXCH2010B.sit.fraunhofer.de>

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-bounces at openssl.org] on behalf of Dmitry Belyavsky [beldmit at gmail.com]
Sent: Tuesday, March 19, 2019 21:09
To: openssl-users at 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 == &my_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 <andreas.fuchs at sit.fraunhofer.de<mailto:andreas.fuchs at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190319/7ee9f565/attachment.html>

From swamy.j-s at in.abb.com  Wed Mar 20 11:40:10 2019
From: swamy.j-s at in.abb.com (Swamy J-S)
Date: Wed, 20 Mar 2019 11:40:10 +0000
Subject: cURL with openSSL 1.1.1 version
In-Reply-To: <CANm5x_P5mtdN0Pa5GrzsEus6OVrHNZ_sY4rRXTGvf2d3rBYLMA@mail.gmail.com>
References: <HE1PR0602MB3643DF1FD528D8783EF804BF96400@HE1PR0602MB3643.eurprd06.prod.outlook.com>
 <CANm5x_P5mtdN0Pa5GrzsEus6OVrHNZ_sY4rRXTGvf2d3rBYLMA@mail.gmail.com>
Message-ID: <HE1PR0602MB36437940A336388BF5AC3B4196410@HE1PR0602MB3643.eurprd06.prod.outlook.com>

Ubuntu released any libssl development package already for openssl 1.1.1? I want to download package internally, I don?t want to download openssl and build it externally.

Right now ?sudo apt install libssl-dev? installs openssl1.1.0g version, like this any command to install openssl 1.1.1??

Thanks and Regards,
SWAMY J S

From: Nicola <nic.tuv at gmail.com>
Sent: Tuesday, March 19, 2019 2:22 PM
To: Swamy J-S <swamy.j-s at in.abb.com>
Cc: openssl-users at openssl.org
Subject: Re: cURL with openSSL 1.1.1 version

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Currently Ubuntu 18.04 ships with OpenSSL 1.1.0 (https://packages.ubuntu.com/bionic/openssl<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpackages.ubuntu.com%2Fbionic%2Fopenssl&data=02%7C01%7Cswamy.j-s%40in.abb.com%7Ca64a60a8f0064a43ce5708d6ac48387f%7C372ee9e09ce04033a64ac07073a91ecd%7C0%7C0%7C636885823518561215&sdata=0nV1nWV7fC5GIwUDLLgidRS7u4LOSA%2Fiijni43%2F8beM%3D&reserved=0>) 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 <swamy.j-s at in.abb.com<mailto:swamy.j-s at in.abb.com>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190320/5525a8b3/attachment-0001.html>

From nic.tuv at gmail.com  Wed Mar 20 12:08:58 2019
From: nic.tuv at gmail.com (Nicola)
Date: Wed, 20 Mar 2019 14:08:58 +0200
Subject: cURL with openSSL 1.1.1 version
In-Reply-To: <HE1PR0602MB36437940A336388BF5AC3B4196410@HE1PR0602MB3643.eurprd06.prod.outlook.com>
References: <HE1PR0602MB3643DF1FD528D8783EF804BF96400@HE1PR0602MB3643.eurprd06.prod.outlook.com>
 <CANm5x_P5mtdN0Pa5GrzsEus6OVrHNZ_sY4rRXTGvf2d3rBYLMA@mail.gmail.com>
 <HE1PR0602MB36437940A336388BF5AC3B4196410@HE1PR0602MB3643.eurprd06.prod.outlook.com>
Message-ID: <CANm5x_NYE1edhziJ-Lj-uv=yCaWkNEo_CeQ2tYapAb3wGo3xwQ@mail.gmail.com>

Ubuntu Cosmic 18.10 ships openssl 1.1.1:
https://packages.ubuntu.com/cosmic/openssl

So one option could be to update to 18.10, which is not a LTS release though.

I strongly recommend against trying to manually grab indivudal
packages for 18.10 and force them in your 18.04 installation, you will
only cause problems with any other package that depends on openssl.

BR,

Nicola

On Wed, 20 Mar 2019 at 13:40, Swamy J-S <swamy.j-s at in.abb.com> wrote:
>
> Ubuntu released any libssl development package already for openssl 1.1.1? I want to download package internally, I don?t want to download openssl and build it externally.
>
>
>
> Right now ?sudo apt install libssl-dev? installs openssl1.1.0g version, like this any command to install openssl 1.1.1??
>
>
>
> Thanks and Regards,
>
> SWAMY J S
>
>
>
> From: Nicola <nic.tuv at gmail.com>
> Sent: Tuesday, March 19, 2019 2:22 PM
> To: Swamy J-S <swamy.j-s at in.abb.com>
> Cc: openssl-users at openssl.org
> Subject: Re: cURL with openSSL 1.1.1 version
>
>
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
>
> 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 <swamy.j-s at in.abb.com> 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

From RSteinhoff at gtreasury.com  Wed Mar 20 14:44:36 2019
From: RSteinhoff at gtreasury.com (Rudolph M. Steinhoff)
Date: Wed, 20 Mar 2019 14:44:36 +0000
Subject: Certificate Handshake
Message-ID: <SG2PR03MB31302BE50ECEAC1131FF2663CD410@SG2PR03MB3130.apcprd03.prod.outlook.com>

I need to implement a SOAP API that will utilize Two-Way Certificate Authentication and encryption/decryption.

I do not know what parts of the handshaking and processing of authentication and encryption/decryption is managed by the Windows Server Operating System (and/or IIS) Environment, or which parts are managed by my Self-Hosted Windows API SOAP Service?

My question is, given the below steps, which parts will the server manage and which parts will my C# .NET code manage.

My code is a Self-Hosted Windows Service using .NET and C#.

My questions are which parts of the process is managed by the Windows Server environment "for" the host/client application, and which parts are managed by the host/client application (C# .NET).

Ps... sorry if the image does not appear, the steps listed are from the image.

Here are the steps:


  1.  Client requests a secure connection to the host
  2.  Host (Windows? IIS? .NET Code?) provides public key and digital certificate to client
  3.  Client verifies certificate with the Certificate Authority (CA)
  4.  Client provides host with a public key
  5.  Host verifies client certificate with the Certificate Authority (CA)
  6.  Host sends client public key
  7.  Client encrypts message using host public key and sends message to host

Host decrypts client message using host's private key

  1.  Host encrypts message using clients public key. Sends message to client
Client decrypts host message using client private key

[enter image description here]

Rudy Steinhoff
Sr. Software Engineer

  Direct: (847-847-3763
  Main: (847) 847.3706
  2100 E. Lake Cook Road, Suite 1100
  Buffalo Grove, IL 60089
  www.GTreasury.com

[GTreasury Logo Signature]<http://www.gtreasury.com/>
This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed.  Any use, distribution, copying or disclosure by any other person is strictly prohibited.  If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy.
________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190320/65a428ae/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 38870 bytes
Desc: image001.jpg
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190320/65a428ae/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 8838 bytes
Desc: image002.png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190320/65a428ae/attachment-0001.png>

From kgoldman at us.ibm.com  Wed Mar 20 14:46:02 2019
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Wed, 20 Mar 2019 10:46:02 -0400
Subject: Using (not building) openssl with mingw on Windows 10
In-Reply-To: <09f436c6-a225-3d6a-540d-361026bc95b2@wisemo.com>
References: <pqvvjb$phc$1@blaine.gmane.org>
 <09f436c6-a225-3d6a-540d-361026bc95b2@wisemo.com>
Message-ID: <q6tjn9$3m80$1@blaine.gmane.org>

On 10/29/2018 7:18 AM, Jakob Bohm via openssl-users wrote:
> On 26/10/2018 23:08, Ken Goldman wrote:
>> I've been happily using the Shining Light 32-bit binaries with both 
>> openssl 1.0 and 1.1 and mingw.
>>
>> On a new machine, I tried the 64-bit binaries.? However, they're 
>> missing the openssl/lib/mingw directory where the .a files resided.
>>
>> It looks like the link procedure changed.? Any hints before I start 
>> experimenting?
>>
> Note that Win32 (Microsoft) .LIB files are actually standard unix-style
> .a files with the file names changed to match the the historic
> MS-DOS/Win16 practice (which had a different file format).
> 
> So it is highly likely the .LIB files can be used with mingw by just
> copying/symlinking them, or even just using a Mingw option to load
> .LIB files.
> 
> Beware however of the crazy GNU interpretation that listing a library
> file explicitly means include *all* the code from the library, not
> just the referenced object files.

Getting back to this:

I tried mingw linking against these

"c:/program files/openssl64/lib/libcrypto.lib"
"c:/program files/openssl64/lib/libssl.lib"

but the gcc linker failed to find the openssl functions.

Anyone have any ideas?

~~

I observe that the .a file is 3 mb while the .lib is 900k.

~~

The 32-bit build still has the mingw .a files, which I suppose
is a work around.



From Michael.Wojcik at microfocus.com  Wed Mar 20 16:41:41 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 20 Mar 2019 16:41:41 +0000
Subject: Using (not building) openssl with mingw on Windows 10
In-Reply-To: <q6tjn9$3m80$1@blaine.gmane.org>
References: <pqvvjb$phc$1@blaine.gmane.org>
 <09f436c6-a225-3d6a-540d-361026bc95b2@wisemo.com>
 <q6tjn9$3m80$1@blaine.gmane.org>
Message-ID: <BYAPR18MB29184811032E36BF024D6EFFF9410@BYAPR18MB2918.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Ken Goldman
> Sent: Wednesday, March 20, 2019 08:46
> To: openssl-users at openssl.org
> Subject: Re: Using (not building) openssl with mingw on Windows 10
>
> On 10/29/2018 7:18 AM, Jakob Bohm via openssl-users wrote:
> > Note that Win32 (Microsoft) .LIB files are actually standard unix-style
> > .a files with the file names changed to match the the historic
> > MS-DOS/Win16 practice (which had a different file format).
> >
> > So it is highly likely the .LIB files can be used with mingw by just
> > copying/symlinking them, or even just using a Mingw option to load
> > .LIB files.
> >
> > Beware however of the crazy GNU interpretation that listing a library
> > file explicitly means include *all* the code from the library, not
> > just the referenced object files.
>
> Getting back to this:
>
> I tried mingw linking against these
>
> "c:/program files/openssl64/lib/libcrypto.lib"
> "c:/program files/openssl64/lib/libssl.lib"
>
> but the gcc linker failed to find the openssl functions.
>
> Anyone have any ideas?
>
> ~~
>
> I observe that the .a file is 3 mb while the .lib is 900k.

Sounds like you might have import libraries there. Does "ar t libcrypto.lib" show a bunch of .obj members, or a bunch of .dll members? If it's the latter, then it's just an import library that tells the linker what DLL needs to be loaded at runtime.

We build static (non-import) OpenSSL libraries for Windows, but at least for 1.0.2 we had to tweak the configuration process. The stock Configure wanted to link OpenSSL with the static Microsoft C runtime if you were building static libraries, whereas we wanted static libraries linked with the dynamic runtime. (I don't remember offhand if we had to do the same for 1.1.1.)

--
Michael Wojcik
Distinguished Engineer, Micro Focus



From shivakumar2696 at gmail.com  Wed Mar 20 17:29:06 2019
From: shivakumar2696 at gmail.com (shiva kumar)
Date: Wed, 20 Mar 2019 22:59:06 +0530
Subject: ecparam error on openssl 102r
Message-ID: <CAN9sONeQmEimWhea_1ge3Z4vHNdRzYGj93=8PcDXRKDCCgAL2A@mail.gmail.com>

Hi,
When I run openssl ecparam on elliptic curve Oakley-EC2N-3,
Oakley-EC2N-4 on openssl 1.0.2r version,
I am getting the following error, can anyone please help me why i am
getting this error.

# openssl ecparam -out Oakley-EC2N-3_102r.pem -name Oakley-EC2N-3
unable to write elliptic curve parameters
2063867464:error:100BF079:elliptic curve routines:i2d_ECPKParameters:i2d
ecpkparameters failure:ec_asn1.c:1011:
2063867464:error:100BF079:elliptic curve routines:i2d_ECPKParameters:i2d
ecpkparameters failure:ec_asn1.c:1011:

unable to write elliptic curve parameters
2063867464:error:100BF079:elliptic curve routines:i2d_ECPKParameters:i2d
ecpkparameters failure:ec_asn1.c:1011:
2063867464:error:100BF079:elliptic curve routines:i2d_ECPKParameters:i2d
ecpkparameters failure:ec_asn1.c:1011:

Thanks and Regards
shivakumar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190320/630e9569/attachment.html>

From nic.tuv at gmail.com  Wed Mar 20 18:21:36 2019
From: nic.tuv at gmail.com (Nicola)
Date: Wed, 20 Mar 2019 20:21:36 +0200
Subject: ecparam error on openssl 102r
In-Reply-To: <CAN9sONeQmEimWhea_1ge3Z4vHNdRzYGj93=8PcDXRKDCCgAL2A@mail.gmail.com>
References: <CAN9sONeQmEimWhea_1ge3Z4vHNdRzYGj93=8PcDXRKDCCgAL2A@mail.gmail.com>
Message-ID: <CANm5x_PDOTcMmC2oEPae6cijiYSSjGdBoQCHDwVeFVkJNksP_w@mail.gmail.com>

TL;DR It's not a bug, it's a feature!

Hi,

you can generate explicit parameters for that curve by:

`openssl ecparam -name Oakley-EC2N-3 -param_enc explicit`

the command in your case was failing because by default it tries to
generate a named_curve ASN1 encoding, which fails because there is no
OID associated with Oakley-EC2N-3.

You can have a look at https://github.com/openssl/openssl/issues/5723
and https://github.com/openssl/openssl/pull/5725 that fixes it.

This change has been included in the 1.0.2 branch since 1.0.2p; in
1.0.2o your command will silently fail as the generated PEM file would
be invalid.


Best regards,

Nicola Tuveri

On Wed, 20 Mar 2019 at 19:29, shiva kumar <shivakumar2696 at gmail.com> wrote:
>
> Hi,
> When I run openssl ecparam on elliptic curve Oakley-EC2N-3,
> Oakley-EC2N-4 on openssl 1.0.2r version,
> I am getting the following error, can anyone please help me why i am getting this error.
>
> # openssl ecparam -out Oakley-EC2N-3_102r.pem -name Oakley-EC2N-3
> unable to write elliptic curve parameters
> 2063867464:error:100BF079:elliptic curve routines:i2d_ECPKParameters:i2d ecpkparameters failure:ec_asn1.c:1011:
> 2063867464:error:100BF079:elliptic curve routines:i2d_ECPKParameters:i2d ecpkparameters failure:ec_asn1.c:1011:
>
> unable to write elliptic curve parameters
> 2063867464:error:100BF079:elliptic curve routines:i2d_ECPKParameters:i2d ecpkparameters failure:ec_asn1.c:1011:
> 2063867464:error:100BF079:elliptic curve routines:i2d_ECPKParameters:i2d ecpkparameters failure:ec_asn1.c:1011:
>
> Thanks and Regards
> shivakumar

From sfhacker at hotmail.com  Wed Mar 20 22:44:31 2019
From: sfhacker at hotmail.com (Sergio NNX)
Date: Wed, 20 Mar 2019 22:44:31 +0000
Subject: Using (not building) openssl with mingw on Windows 10
In-Reply-To: <q6tjn9$3m80$1@blaine.gmane.org>
References: <pqvvjb$phc$1@blaine.gmane.org>
 <09f436c6-a225-3d6a-540d-361026bc95b2@wisemo.com>,
 <q6tjn9$3m80$1@blaine.gmane.org>
Message-ID: <DM6PR17MB221948E3094AF3B081C8E3BBCC410@DM6PR17MB2219.namprd17.prod.outlook.com>

>> I've been happily using the Shining Light 32-bit binaries with both
>> openssl 1.0 and 1.1 and mingw.

a) Where can we download OpenSSL binaries (x64) for Windows built with MinGW?
    [ https://slproweb.com/products/Win32OpenSSL.html ]

b) D:\Temp-Apps\OpenSSL-Win64\bin>openssl version -a

    OpenSSL 1.1.1b  26 Feb 2019
    built on: Wed Feb 27 02:30:51 2019 UTC
    platform: VC-WIN64A
    options:  bn(64,64) rc4(16x,int) des(long) idea(int) blowfish(ptr)
    compiler: cl /Z7 /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -D_USING_V110_SDK71_ -D_WINSOCK_DEPRECATED_NO_WARNINGS
    OPENSSLDIR: "C:\Program Files\Common Files\SSL"
    ENGINESDIR: "C:\Program Files\OpenSSL\lib\engines-1_1"
    Seeding source: os-specific

     + Paths seem to be hardcoded

c) D:\Temp-Apps\OpenSSL-Win64\bin>openssl engine capi -v -t -post list_containers
    6840:error:25078067:DSO support routines:win32_load:could not load the shared library:crypto\dso\dso_win32.c:107:filename(C:\Program Files\OpenSSL\lib\engines-1_1\capi.dll)
    6840:error:25070067:DSO support routines:DSO_load:could not load the shared library:crypto\dso\dso_lib.c:162:
    6840:error:260B6084:engine routines:dynamic_load:dso not found:crypto\engine\eng_dyn.c:414:
    6840:error:2606A074:engine routines:ENGINE_by_id:no such engine:crypto\engine\eng_list.c:334:id=capi

d) Unable to find any .a file within the installation folder (D:\Temp-Apps\OpenSSL-Win64)

>> On a new machine, I tried the 64-bit binaries.  However, they're
>> missing the openssl/lib/mingw directory where the .a files resided.

> Getting back to this:

> I tried mingw linking against these

> "c:/program files/openssl64/lib/libcrypto.lib"
> "c:/program files/openssl64/lib/libssl.lib"

> but the gcc linker failed to find the openssl functions.

> Anyone have any ideas?

We have been using OpenSSL for Windows (x64) built with MinGW for a long time.

> openssl.exe version -a

    OpenSSL 1.1.1a  20 Nov 2018
    built on: Sat Feb 23 14:32:38 2019 UTC
    platform: mingw64
    options:  bn(64,64) rc4(16x,int) des(long) idea(int) blowfish(ptr)
    compiler: gcc.exe -m64 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -D_WIN32_IE=0x0501 -DPTW32_STATIC_LIB -D__CLEANUP_C -m64 -O2 -pipe -mms-bitfields -fno-builtin -march=core2 -mtune=core2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -D_WIN32_IE=0x0501 -DPTW32_STATIC_LIB -D__CLEANUP_C -DUNICODE -D_UNICODE -DWIN32_LEAN_AND_MEAN -DOPENSSL_SSL_CLIENT_ENGINE_AUTO=capi -DOPENSSL_CAPIENG_DIALOG -m64 -pipe -mms-bitfields -fno-builtin -march=core2 -mtune=core2 -D_MT -DZLIB -DNDEBUG -I/mingw/include
    OPENSSLDIR: "\OpenSSL"
    ENGINESDIR: "\OpenSSL\lib\engines-1_1"
    Seeding source: os-specific

> openssl engine
    (rdrand) Intel RDRAND engine
    (dynamic) Dynamic engine loading support
    (padlock) VIA PadLock (no-RNG, no-ACE)
    (capi) CryptoAPI ENGINE

@Ken: this seems to be a quite old thread, but if you need either the include files or the .a files
      or both, we could email them to you.

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190320/2234f30c/attachment-0001.html>

From minfrin at sharp.fm  Thu Mar 21 00:36:12 2019
From: minfrin at sharp.fm (Graham Leggett)
Date: Thu, 21 Mar 2019 02:36:12 +0200
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <20190319160012.GN3822@straasha.imrryr.org>
References: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
 <20190318025541.GK3822@straasha.imrryr.org>
 <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
 <A2E1FA0F-8BE7-4A3E-808D-A3D599C81AAC@dukhovni.org>
 <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
 <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>
 <199E4877-FE72-4A9A-97B6-B65CEF0B574C@dukhovni.org>
 <65906247-0744-40D8-8463-15EA01BC447E@sharp.fm>
 <20190319160012.GN3822@straasha.imrryr.org>
Message-ID: <8AA96214-A78C-42AF-8380-95C08599FE3B@sharp.fm>

On 19 Mar 2019, at 18:00, Viktor Dukhovni <openssl-users at dukhovni.org> wrote
:
> 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).

I agree - it is the ideal structure to use, however translating this into real world implementation there aren?t any APIs in openssl that allow us to do this today, and it is very likely that the same limitation exists in other APIs we would like to support in future (NSS, native APIs, etc).

This software however is 7 years old, we?re not in a position to drop everything and rewrite it.

> 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.

In our world we?re translating from various protocols (scep, spkac, etc etc) where proof of possession isn?t a signed X509_REQ, but is rather a challenge passphrase, previous certificate, etc etc, to a standard object (CSR) that can then be signed by a range of modules (simple local signing, signing on a smartcard, etc etc).

As a result while in the ideal world we would be dealing with signed CSRs, in our world we have to support a CSR with proof of possession supplied alongside in a range of possible formats.

We might have to go with the sign-with-a-dummy-signature route, but this would be unfortunate.

>> 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).

We?re a modular CA, we don?t dictate to our modules what they can and can?t do, so to say ?that object?s sole purpose? is a contradiction.

It turns out that the module that checks the proof of possession against an LDAP server needs to pull out the subject of the CSR in order to make the LDAP query, which in turn means it needs to be able to read the contents of the X509_REQ (or X509_REQ_INFO).

X509_REQ_INFO prevents us from seeing the information, and so this won?t work for us.

>> 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?

Protocols like scep and spkac don?t supply a CSR, that?s not how they work.

>>> 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.

DER encoding is well standardised, and modularity is well understood. None of this is an odd choice in a modular CA.

>> 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.

And yet here we are.

The problem seems that at some point during the 1.0.2 releases, the X509_REQ was previously serialised with what looks like an empty X509_ALGOR structure:

 507:d=2  hl=2 l=   1 prim: OBJECT            :itu-t

and at some point openssl changed to serialise with a bad object instead:

 508:d=2  hl=2 l=   0 prim: OBJECT            :BAD OBJECT

A change from something from optional to mandatory should have happened in the 1.1.0 release, not within the 1.0.2 point releases.

Regards,
Graham
?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3260 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190321/c7a131c9/attachment.bin>

From openssl-users at dukhovni.org  Thu Mar 21 01:35:12 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 20 Mar 2019 21:35:12 -0400
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <8AA96214-A78C-42AF-8380-95C08599FE3B@sharp.fm>
References: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
 <20190318025541.GK3822@straasha.imrryr.org>
 <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
 <A2E1FA0F-8BE7-4A3E-808D-A3D599C81AAC@dukhovni.org>
 <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
 <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>
 <199E4877-FE72-4A9A-97B6-B65CEF0B574C@dukhovni.org>
 <65906247-0744-40D8-8463-15EA01BC447E@sharp.fm>
 <20190319160012.GN3822@straasha.imrryr.org>
 <8AA96214-A78C-42AF-8380-95C08599FE3B@sharp.fm>
Message-ID: <1265B2B9-EBF4-4159-9CDA-127BE8D6B243@dukhovni.org>

> On Mar 20, 2019, at 8:36 PM, Graham Leggett <minfrin at sharp.fm> wrote:
> 
> The problem seems that at some point during the 1.0.2 releases, the X509_REQ was previously serialised with what looks like an empty X509_ALGOR structure:
> 
> 507:d=2  hl=2 l=   1 prim: OBJECT            :itu-t
> 
> and at some point openssl changed to serialise with a bad object instead:
> 
> 508:d=2  hl=2 l=   0 prim: OBJECT            :BAD OBJECT
> 
> A change from something from optional to mandatory should have happened in the 1.1.0 release, not within the 1.0.2 point releases.

Sorry, are you saying that the serialized form changed in a 1.0.2
patch release?  I may have missed that detail.

Your github issue notes a change from 1.0.1 to 1.0.2, not a change
within the 1.0.2 patch release series...

Changes of behaviour between 1.0.1 and 1.0.2 were not off limits.

When testing a short program to reproduce the reported symptoms
I see the same output encoding (BAD OBJECT) with both 1.0.1 and
1.0.2.  For me, it is only 0.9.8 and 1.0.0 that generate the "0" OID.

    0:d=0  hl=3 l= 163 cons: SEQUENCE
    3:d=1  hl=3 l= 152 cons: SEQUENCE
    6:d=2  hl=2 l=   1 prim: INTEGER           :00
    9:d=2  hl=2 l=  51 cons: SEQUENCE
   11:d=3  hl=2 l=  11 cons: SET
   13:d=4  hl=2 l=   9 cons: SEQUENCE
   15:d=5  hl=2 l=   3 prim: OBJECT            :countryName
   20:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :US
   24:d=3  hl=2 l=  13 cons: SET
   26:d=4  hl=2 l=  11 cons: SEQUENCE
   28:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
   33:d=5  hl=2 l=   4 prim: UTF8STRING        :None
   39:d=3  hl=2 l=  21 cons: SET
   41:d=4  hl=2 l=  19 cons: SEQUENCE
   43:d=5  hl=2 l=   3 prim: OBJECT            :commonName
   48:d=5  hl=2 l=  12 prim: UTF8STRING        :test.example
   62:d=2  hl=2 l=  92 cons: SEQUENCE
   64:d=3  hl=2 l=  13 cons: SEQUENCE
   66:d=4  hl=2 l=   9 prim: OBJECT            :rsaEncryption
   77:d=4  hl=2 l=   0 prim: NULL
   79:d=3  hl=2 l=  75 prim: BIT STRING
  156:d=2  hl=2 l=   0 cons: cont [ 0 ]
  158:d=1  hl=2 l=   3 cons: SEQUENCE
  160:d=2  hl=2 l=   1 prim: OBJECT            :0.0
  163:d=1  hl=2 l=   1 prim: BIT STRING

With 1.0.1 I get:

    0:d=0  hl=3 l= 162 cons: SEQUENCE
    3:d=1  hl=3 l= 152 cons: SEQUENCE
    6:d=2  hl=2 l=   1 prim: INTEGER           :00
    9:d=2  hl=2 l=  51 cons: SEQUENCE
   11:d=3  hl=2 l=  11 cons: SET
   13:d=4  hl=2 l=   9 cons: SEQUENCE
   15:d=5  hl=2 l=   3 prim: OBJECT            :countryName
   20:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :US
   24:d=3  hl=2 l=  13 cons: SET
   26:d=4  hl=2 l=  11 cons: SEQUENCE
   28:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
   33:d=5  hl=2 l=   4 prim: UTF8STRING        :None
   39:d=3  hl=2 l=  21 cons: SET
   41:d=4  hl=2 l=  19 cons: SEQUENCE
   43:d=5  hl=2 l=   3 prim: OBJECT            :commonName
   48:d=5  hl=2 l=  12 prim: UTF8STRING        :test.example
   62:d=2  hl=2 l=  92 cons: SEQUENCE
   64:d=3  hl=2 l=  13 cons: SEQUENCE
   66:d=4  hl=2 l=   9 prim: OBJECT            :rsaEncryption
   77:d=4  hl=2 l=   0 prim: NULL
   79:d=3  hl=2 l=  75 prim: BIT STRING
  156:d=2  hl=2 l=   0 cons: cont [ 0 ]
  158:d=1  hl=2 l=   2 cons: SEQUENCE
  160:d=2  hl=2 l=   0 prim: OBJECT            :BAD OBJECT
  162:d=1  hl=2 l=   1 prim: BIT STRING

-- 
	Viktor.


From parthpatel041991 at gmail.com  Thu Mar 21 05:16:42 2019
From: parthpatel041991 at gmail.com (Parth Patel)
Date: Thu, 21 Mar 2019 10:46:42 +0530
Subject: Openssl Version 1.1.1b fails to compile on Solaris platform(Intel &
 Sparc)
Message-ID: <CAONacheFCxtRKQJjNOYzFcgWHVV8LcxduhXCVhw=Cww+LpLVTg@mail.gmail.com>

Hi All,

We are trying to build OpenSSL version 1.1.1b on Solaris, but it fails with
following error:

libcrypto.map: file format not recognized; treating as linker script
collect2: error: ld returned 1 exit status
gmake[2]: *** [libcrypto.so] Error 1
gmake[1]: *** [all] Error 2

$ uname -a
SunOS mh-vmss3fnpb32.enguk.acresso.com 5.10 Generic_147147-26 sun4v sparc
sun4v


This is happening because of the flags defined in
Configurations/10-main.conf:

#### Solaris configurations
    "solaris-common" => {
        inherit_from     => [ "BASE_unix" ],
        template         => 1,
        lib_cppflags     => "-DFILIO_H",
        ex_libs          => add("-lsocket -lnsl -ldl"),
        dso_scheme       => "dlfcn",
        thread_scheme    => "pthreads",
        shared_target    => "self",
        shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)",
        shared_ldflag    => "-Wl,-Bsymbolic",
        shared_defflag   => "-Wl,-M,",
        shared_sonameflag=> "-Wl,-h,",
    },

After changing the shared_defflag to "-Wl, -Map," it works fine. i.e "-Wl,
-M" is not recognized on Solaris, it needs to be "-Wl, -Map,".
Couple of queries here:
1. Is it not a bug on Solaris with OpenSSL 1.1.1b version?
2. Can we modify 'Configurations/10-main.conf' in our local copy of OpenSSL
which is used internally by our product?Will it cause any licensing
problem(OpenSSL license and GPL)?

Any help would be greatly appreciated.

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

From erik at efca.com  Thu Mar 21 05:22:35 2019
From: erik at efca.com (Erik Forsberg)
Date: Wed, 20 Mar 2019 22:22:35 -0700
Subject: Openssl Version 1.1.1b fails to compile on Solaris
 platform(Intel & Sparc)
In-Reply-To: <CAONacheFCxtRKQJjNOYzFcgWHVV8LcxduhXCVhw=Cww+LpLVTg@mail.gmail.com>
References: <CAONacheFCxtRKQJjNOYzFcgWHVV8LcxduhXCVhw=Cww+LpLVTg@mail.gmail.com>
Message-ID: <eR1zVlxzjZHaA6k@srv.efca.com>

I see this is Solaris 10, dont use that anywhere anymore.
But in Solaris 11, its fine. From ld(1)

??????-M mapfile

??????????Reads mapfile as a text file of directives to the link-editor. This
??????????option?can be specified multiple times. If mapfile is a directory,
??????????then all regular files, as defined by stat(2), within the directory
??????????are?processed. See Chapter 10, Mapfiles in the Link-Editor in Ora-
??????????cle Solaris 11.4 Linkers and Libraries Guide. Example mapfiles?are
??????????provided in /usr/lib/ld. See also FILES.


>-- Original Message --
>
>Hi All,
>
>We are trying to build OpenSSL version 1.1.1b on Solaris, but it fails with
>following error:
>
>libcrypto.map: file format not recognized; treating as linker script
>collect2: error: ld returned 1 exit status
>gmake[2]: *** [libcrypto.so] Error 1
>gmake[1]: *** [all] Error 2
>
>$ uname -a
>SunOS mh-vmss3fnpb32.enguk.acresso.com 5.10 Generic_147147-26 sun4v sparc
>sun4v
>
>
>This is happening because of the flags defined in
>Configurations/10-main.conf:
>
>#### Solaris configurations
>    "solaris-common" => {
>        inherit_from     => [ "BASE_unix" ],
>        template         => 1,
>        lib_cppflags     => "-DFILIO_H",
>        ex_libs          => add("-lsocket -lnsl -ldl"),
>        dso_scheme       => "dlfcn",
>        thread_scheme    => "pthreads",
>        shared_target    => "self",
>        shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)",
>        shared_ldflag    => "-Wl,-Bsymbolic",
>        shared_defflag   => "-Wl,-M,",
>        shared_sonameflag=> "-Wl,-h,",
>    },
>
>After changing the shared_defflag to "-Wl, -Map," it works fine. i.e "-Wl,
>-M" is not recognized on Solaris, it needs to be "-Wl, -Map,".
>Couple of queries here:
>1. Is it not a bug on Solaris with OpenSSL 1.1.1b version?
>2. Can we modify 'Configurations/10-main.conf' in our local copy of OpenSSL
>which is used internally by our product?Will it cause any licensing
>problem(OpenSSL license and GPL)?
>
>Any help would be greatly appreciated.
>
>Regards,
>Parth



From openssl-users at dukhovni.org  Thu Mar 21 05:49:15 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 21 Mar 2019 01:49:15 -0400
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <1265B2B9-EBF4-4159-9CDA-127BE8D6B243@dukhovni.org>
References: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
 <20190318025541.GK3822@straasha.imrryr.org>
 <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
 <A2E1FA0F-8BE7-4A3E-808D-A3D599C81AAC@dukhovni.org>
 <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
 <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>
 <199E4877-FE72-4A9A-97B6-B65CEF0B574C@dukhovni.org>
 <65906247-0744-40D8-8463-15EA01BC447E@sharp.fm>
 <20190319160012.GN3822@straasha.imrryr.org>
 <8AA96214-A78C-42AF-8380-95C08599FE3B@sharp.fm>
 <1265B2B9-EBF4-4159-9CDA-127BE8D6B243@dukhovni.org>
Message-ID: <50335680-2D2B-4CD4-9524-3A5AB2A8538B@dukhovni.org>

> On Mar 20, 2019, at 9:35 PM, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
> Your github issue notes a change from 1.0.1 to 1.0.2, not a change
> within the 1.0.2 patch release series...
> 
> Changes of behaviour between 1.0.1 and 1.0.2 were not off limits.
> 
> When testing a short program to reproduce the reported symptoms
> I see the same output encoding (BAD OBJECT) with both 1.0.1 and
> 1.0.2.  For me, it is only 0.9.8 and 1.0.0 that generate the "0" OID.

The change dates back to:

  https://github.com/openssl/openssl/commit/38a503fb8adaad331b8a67aaa9eb2fa915113ed0

which first appeared in OpenSSL 1.0.1i.  It was cherry-picked onto the
1.0.2 branch:

   https://github.com/openssl/openssl/commit/ff4cfc4c588c41d5e8d2d530231bc36cbc525add

The effect of this is that "NID_undef" generates an empty ASN.1 value, rather
than an OID of "0.0".  Single component OIDs are not representable in ASN.1
BER/DER since the OID encoding combines the first elements as a single value.

Encoding "NID_undef" (uninitialized OID) as 0.0 isn't right, because there is no
OID, and we're pretending to have an OID of 0.0.  Of course not encoding anything
isn't great either, we're then skipping an element of the enclosing structure and
generating incorrect ASN.1 for the containing structure.

Really what could/should probably happen here, is that i2d should fail, because
the structure specifies an object that has no ASN.1 encoding.

-- 
	Viktor.


From swamy.j-s at in.abb.com  Thu Mar 21 05:59:41 2019
From: swamy.j-s at in.abb.com (Swamy J-S)
Date: Thu, 21 Mar 2019 05:59:41 +0000
Subject: How to disable TLS 1.3 in OpenSSL 1.1.1
Message-ID: <HE1PR0602MB36435DA7873536BD0243881996420@HE1PR0602MB3643.eurprd06.prod.outlook.com>

I have updated my openssl from 1.1.0 to 1.1.1 recently. Openssl 1.1.1 version supports TLS1.3 feature.

But I want to use TLS 1.2 only for my application with curl 7.58 in Ubuntu 18.04. So while using openssl 1.1.1 how to disable default TLS 1.3 and how to enable TLS 1.2?



Can I set any flags while building openssl 1.1.1 to disable TLS 1.3 or can i get any package from ubuntu to disable TLS 1.3 ?


Thanks and Regards,
SWAMY J S

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

From levitte at openssl.org  Thu Mar 21 06:09:37 2019
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 21 Mar 2019 07:09:37 +0100
Subject: Openssl Version 1.1.1b fails to compile on Solaris platform(Intel
 & Sparc)
In-Reply-To: <eR1zVlxzjZHaA6k@srv.efca.com>
References: <CAONacheFCxtRKQJjNOYzFcgWHVV8LcxduhXCVhw=Cww+LpLVTg@mail.gmail.com>
 <eR1zVlxzjZHaA6k@srv.efca.com>
Message-ID: <8736ng4v32.wl-levitte@openssl.org>

"collect2" indicates that this isn't Solaris ld, but GNU ld in
action.  With GNU ld, -Map doesn't do what you think it does
(from https://sourceware.org/binutils/docs/ld/Options.html#Options):

    -Map=mapfile

        Print a link map to the file mapfile. See the description of
        the -M option, above.

Also, with GNU ld, -M has a different meaning than for Solaris:

    -M
    --print-map
    
        Print a link map to the standard output. A link map provides
        information about the link, including the following:
    ...

What you actually want is -Wl,--version-script=

However, it seems like our solaris configs need more than just a small
tweak.  The way they're currently written, they assume that the linker
is Solaris ld at all times...  I'm told, though, that this is a
correct assumption with the default gcc on Solaris, but that doesn't
mean a non-default gcc that uses GNU ld instead of Solaris ld is
impossible.

I'll raise an issue on this.

Cheers,
Richard

On Thu, 21 Mar 2019 06:22:35 +0100,
Erik Forsberg wrote:
> 
> I see this is Solaris 10, dont use that anywhere anymore.
> But in Solaris 11, its fine. From ld(1)
> 
> ??????-M mapfile
> 
> ??????????Reads mapfile as a text file of directives to the link-editor. This
> ??????????option?can be specified multiple times. If mapfile is a directory,
> ??????????then all regular files, as defined by stat(2), within the directory
> ??????????are?processed. See Chapter 10, Mapfiles in the Link-Editor in Ora-
> ??????????cle Solaris 11.4 Linkers and Libraries Guide. Example mapfiles?are
> ??????????provided in /usr/lib/ld. See also FILES.
> 
> 
> >-- Original Message --
> >
> >Hi All,
> >
> >We are trying to build OpenSSL version 1.1.1b on Solaris, but it fails with
> >following error:
> >
> >libcrypto.map: file format not recognized; treating as linker script
> >collect2: error: ld returned 1 exit status
> >gmake[2]: *** [libcrypto.so] Error 1
> >gmake[1]: *** [all] Error 2
> >
> >$ uname -a
> >SunOS mh-vmss3fnpb32.enguk.acresso.com 5.10 Generic_147147-26 sun4v sparc
> >sun4v
> >
> >
> >This is happening because of the flags defined in
> >Configurations/10-main.conf:
> >
> >#### Solaris configurations
> >    "solaris-common" => {
> >        inherit_from     => [ "BASE_unix" ],
> >        template         => 1,
> >        lib_cppflags     => "-DFILIO_H",
> >        ex_libs          => add("-lsocket -lnsl -ldl"),
> >        dso_scheme       => "dlfcn",
> >        thread_scheme    => "pthreads",
> >        shared_target    => "self",
> >        shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)",
> >        shared_ldflag    => "-Wl,-Bsymbolic",
> >        shared_defflag   => "-Wl,-M,",
> >        shared_sonameflag=> "-Wl,-h,",
> >    },
> >
> >After changing the shared_defflag to "-Wl, -Map," it works fine. i.e "-Wl,
> >-M" is not recognized on Solaris, it needs to be "-Wl, -Map,".
> >Couple of queries here:
> >1. Is it not a bug on Solaris with OpenSSL 1.1.1b version?
> >2. Can we modify 'Configurations/10-main.conf' in our local copy of OpenSSL
> >which is used internally by our product?Will it cause any licensing
> >problem(OpenSSL license and GPL)?
> >
> >Any help would be greatly appreciated.
> >
> >Regards,
> >Parth
> 
> 
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From hmurray at megapathdsl.net  Thu Mar 21 06:14:32 2019
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 20 Mar 2019 23:14:32 -0700
Subject: How to disable TLS 1.3 in OpenSSL 1.1.1
In-Reply-To: Message from Swamy J-S <swamy.j-s@in.abb.com> of "Thu,
 21 Mar 2019 05:59:41 -0000."
 <HE1PR0602MB36435DA7873536BD0243881996420@HE1PR0602MB3643.eurprd06.prod.outlook.com>
Message-ID: <20190321061432.1B6E140605C@ip-64-139-1-69.sjc.megapath.net>


> But I want to use TLS 1.2 only for my application with curl 7.58 in Ubuntu
> 18.04. So while using openssl 1.1.1 how to disable default TLS 1.3 and how
> to enable TLS 1.2? 

Just curious.  Why do you want to disable TLS 1.3?  It will automagically use 
1.2 if that's all the other end supports.  Why not use 1.3 if both ends 
support it?


> Can I set any flags while building openssl 1.1.1 to disable TLS 1.3 or can
> i get any package from ubuntu to disable TLS 1.3 ? 

You can do it at run time using SSL_set_max_proto_version


-- 
These are my opinions.  I hate spam.




From levitte at openssl.org  Thu Mar 21 06:22:39 2019
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 21 Mar 2019 07:22:39 +0100
Subject: Openssl Version 1.1.1b fails to compile on Solaris platform(Intel
 & Sparc)
In-Reply-To: <8736ng4v32.wl-levitte@openssl.org>
References: <CAONacheFCxtRKQJjNOYzFcgWHVV8LcxduhXCVhw=Cww+LpLVTg@mail.gmail.com>
 <eR1zVlxzjZHaA6k@srv.efca.com> <8736ng4v32.wl-levitte@openssl.org>
Message-ID: <871s304uhc.wl-levitte@openssl.org>

Said and done: https://github.com/openssl/openssl/issues/8547

I would appreciate it if you followed what's happening there and
helped out getting it right...

Cheers,
Richard

On Thu, 21 Mar 2019 07:09:37 +0100,
Richard Levitte wrote:
> 
> "collect2" indicates that this isn't Solaris ld, but GNU ld in
> action.  With GNU ld, -Map doesn't do what you think it does
> (from https://sourceware.org/binutils/docs/ld/Options.html#Options):
> 
>     -Map=mapfile
> 
>         Print a link map to the file mapfile. See the description of
>         the -M option, above.
> 
> Also, with GNU ld, -M has a different meaning than for Solaris:
> 
>     -M
>     --print-map
>     
>         Print a link map to the standard output. A link map provides
>         information about the link, including the following:
>     ...
> 
> What you actually want is -Wl,--version-script=
> 
> However, it seems like our solaris configs need more than just a small
> tweak.  The way they're currently written, they assume that the linker
> is Solaris ld at all times...  I'm told, though, that this is a
> correct assumption with the default gcc on Solaris, but that doesn't
> mean a non-default gcc that uses GNU ld instead of Solaris ld is
> impossible.
> 
> I'll raise an issue on this.
> 
> Cheers,
> Richard
> 
> On Thu, 21 Mar 2019 06:22:35 +0100,
> Erik Forsberg wrote:
> > 
> > I see this is Solaris 10, dont use that anywhere anymore.
> > But in Solaris 11, its fine. From ld(1)
> > 
> > ??????-M mapfile
> > 
> > ??????????Reads mapfile as a text file of directives to the link-editor. This
> > ??????????option?can be specified multiple times. If mapfile is a directory,
> > ??????????then all regular files, as defined by stat(2), within the directory
> > ??????????are?processed. See Chapter 10, Mapfiles in the Link-Editor in Ora-
> > ??????????cle Solaris 11.4 Linkers and Libraries Guide. Example mapfiles?are
> > ??????????provided in /usr/lib/ld. See also FILES.
> > 
> > 
> > >-- Original Message --
> > >
> > >Hi All,
> > >
> > >We are trying to build OpenSSL version 1.1.1b on Solaris, but it fails with
> > >following error:
> > >
> > >libcrypto.map: file format not recognized; treating as linker script
> > >collect2: error: ld returned 1 exit status
> > >gmake[2]: *** [libcrypto.so] Error 1
> > >gmake[1]: *** [all] Error 2
> > >
> > >$ uname -a
> > >SunOS mh-vmss3fnpb32.enguk.acresso.com 5.10 Generic_147147-26 sun4v sparc
> > >sun4v
> > >
> > >
> > >This is happening because of the flags defined in
> > >Configurations/10-main.conf:
> > >
> > >#### Solaris configurations
> > >    "solaris-common" => {
> > >        inherit_from     => [ "BASE_unix" ],
> > >        template         => 1,
> > >        lib_cppflags     => "-DFILIO_H",
> > >        ex_libs          => add("-lsocket -lnsl -ldl"),
> > >        dso_scheme       => "dlfcn",
> > >        thread_scheme    => "pthreads",
> > >        shared_target    => "self",
> > >        shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)",
> > >        shared_ldflag    => "-Wl,-Bsymbolic",
> > >        shared_defflag   => "-Wl,-M,",
> > >        shared_sonameflag=> "-Wl,-h,",
> > >    },
> > >
> > >After changing the shared_defflag to "-Wl, -Map," it works fine. i.e "-Wl,
> > >-M" is not recognized on Solaris, it needs to be "-Wl, -Map,".
> > >Couple of queries here:
> > >1. Is it not a bug on Solaris with OpenSSL 1.1.1b version?
> > >2. Can we modify 'Configurations/10-main.conf' in our local copy of OpenSSL
> > >which is used internally by our product?Will it cause any licensing
> > >problem(OpenSSL license and GPL)?
> > >
> > >Any help would be greatly appreciated.
> > >
> > >Regards,
> > >Parth
> > 
> > 
> > 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From openssl-users at dukhovni.org  Thu Mar 21 06:26:28 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 21 Mar 2019 02:26:28 -0400
Subject: How to disable TLS 1.3 in OpenSSL 1.1.1
In-Reply-To: <20190321061432.1B6E140605C@ip-64-139-1-69.sjc.megapath.net>
References: <20190321061432.1B6E140605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <BE344FC0-4154-43D5-BA08-0DA7D564BA5E@dukhovni.org>



> On Mar 21, 2019, at 2:14 AM, Hal Murray <hmurray at megapathdsl.net> wrote:
> 
>> Can I set any flags while building openssl 1.1.1 to disable TLS 1.3 or can
>> i get any package from ubuntu to disable TLS 1.3 ? 
> 
> You can do it at run time using SSL_set_max_proto_version

It can also be set in the system-wide default openssl.cnf file.

-- 
	Viktor.


From levitte at openssl.org  Thu Mar 21 07:04:19 2019
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 21 Mar 2019 08:04:19 +0100
Subject: Openssl Version 1.1.1b fails to compile on Solaris platform(Intel
 & Sparc)
In-Reply-To: <871s304uhc.wl-levitte@openssl.org>
References: <CAONacheFCxtRKQJjNOYzFcgWHVV8LcxduhXCVhw=Cww+LpLVTg@mail.gmail.com>
 <eR1zVlxzjZHaA6k@srv.efca.com> <8736ng4v32.wl-levitte@openssl.org>
 <871s304uhc.wl-levitte@openssl.org>
Message-ID: <87zhpo3dzg.wl-levitte@openssl.org>

Tentative fix: https://github.com/openssl/openssl/pull/8548

On Thu, 21 Mar 2019 07:22:39 +0100,
Richard Levitte wrote:
> 
> Said and done: https://github.com/openssl/openssl/issues/8547
> 
> I would appreciate it if you followed what's happening there and
> helped out getting it right...
> 
> Cheers,
> Richard
> 
> On Thu, 21 Mar 2019 07:09:37 +0100,
> Richard Levitte wrote:
> > 
> > "collect2" indicates that this isn't Solaris ld, but GNU ld in
> > action.  With GNU ld, -Map doesn't do what you think it does
> > (from https://sourceware.org/binutils/docs/ld/Options.html#Options):
> > 
> >     -Map=mapfile
> > 
> >         Print a link map to the file mapfile. See the description of
> >         the -M option, above.
> > 
> > Also, with GNU ld, -M has a different meaning than for Solaris:
> > 
> >     -M
> >     --print-map
> >     
> >         Print a link map to the standard output. A link map provides
> >         information about the link, including the following:
> >     ...
> > 
> > What you actually want is -Wl,--version-script=
> > 
> > However, it seems like our solaris configs need more than just a small
> > tweak.  The way they're currently written, they assume that the linker
> > is Solaris ld at all times...  I'm told, though, that this is a
> > correct assumption with the default gcc on Solaris, but that doesn't
> > mean a non-default gcc that uses GNU ld instead of Solaris ld is
> > impossible.
> > 
> > I'll raise an issue on this.
> > 
> > Cheers,
> > Richard
> > 
> > On Thu, 21 Mar 2019 06:22:35 +0100,
> > Erik Forsberg wrote:
> > > 
> > > I see this is Solaris 10, dont use that anywhere anymore.
> > > But in Solaris 11, its fine. From ld(1)
> > > 
> > > ??????-M mapfile
> > > 
> > > ??????????Reads mapfile as a text file of directives to the link-editor. This
> > > ??????????option?can be specified multiple times. If mapfile is a directory,
> > > ??????????then all regular files, as defined by stat(2), within the directory
> > > ??????????are?processed. See Chapter 10, Mapfiles in the Link-Editor in Ora-
> > > ??????????cle Solaris 11.4 Linkers and Libraries Guide. Example mapfiles?are
> > > ??????????provided in /usr/lib/ld. See also FILES.
> > > 
> > > 
> > > >-- Original Message --
> > > >
> > > >Hi All,
> > > >
> > > >We are trying to build OpenSSL version 1.1.1b on Solaris, but it fails with
> > > >following error:
> > > >
> > > >libcrypto.map: file format not recognized; treating as linker script
> > > >collect2: error: ld returned 1 exit status
> > > >gmake[2]: *** [libcrypto.so] Error 1
> > > >gmake[1]: *** [all] Error 2
> > > >
> > > >$ uname -a
> > > >SunOS mh-vmss3fnpb32.enguk.acresso.com 5.10 Generic_147147-26 sun4v sparc
> > > >sun4v
> > > >
> > > >
> > > >This is happening because of the flags defined in
> > > >Configurations/10-main.conf:
> > > >
> > > >#### Solaris configurations
> > > >    "solaris-common" => {
> > > >        inherit_from     => [ "BASE_unix" ],
> > > >        template         => 1,
> > > >        lib_cppflags     => "-DFILIO_H",
> > > >        ex_libs          => add("-lsocket -lnsl -ldl"),
> > > >        dso_scheme       => "dlfcn",
> > > >        thread_scheme    => "pthreads",
> > > >        shared_target    => "self",
> > > >        shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)",
> > > >        shared_ldflag    => "-Wl,-Bsymbolic",
> > > >        shared_defflag   => "-Wl,-M,",
> > > >        shared_sonameflag=> "-Wl,-h,",
> > > >    },
> > > >
> > > >After changing the shared_defflag to "-Wl, -Map," it works fine. i.e "-Wl,
> > > >-M" is not recognized on Solaris, it needs to be "-Wl, -Map,".
> > > >Couple of queries here:
> > > >1. Is it not a bug on Solaris with OpenSSL 1.1.1b version?
> > > >2. Can we modify 'Configurations/10-main.conf' in our local copy of OpenSSL
> > > >which is used internally by our product?Will it cause any licensing
> > > >problem(OpenSSL license and GPL)?
> > > >
> > > >Any help would be greatly appreciated.
> > > >
> > > >Regards,
> > > >Parth
> > > 
> > > 
> > > 
> > -- 
> > Richard Levitte         levitte at openssl.org
> > OpenSSL Project         http://www.openssl.org/~levitte/
> > 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Thu Mar 21 13:00:14 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 21 Mar 2019 13:00:14 +0000
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <8AA96214-A78C-42AF-8380-95C08599FE3B@sharp.fm>
References: <6144BC2D-B069-4175-BF3B-74AB5284E98A@sharp.fm>
 <20190318025541.GK3822@straasha.imrryr.org>
 <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
 <A2E1FA0F-8BE7-4A3E-808D-A3D599C81AAC@dukhovni.org>
 <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
 <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>
 <199E4877-FE72-4A9A-97B6-B65CEF0B574C@dukhovni.org>
 <65906247-0744-40D8-8463-15EA01BC447E@sharp.fm>
 <20190319160012.GN3822@straasha.imrryr.org>
 <8AA96214-A78C-42AF-8380-95C08599FE3B@sharp.fm>
Message-ID: <CA1815E4-1EB5-4EC7-BA68-D1AAB058867B@akamai.com>

>    This software however is 7 years old, we?re not in a position to drop everything and rewrite it.
  

Then don't upgrade?  If it's for a CA you don't need TLS 1.3 for example.

Or take the existing OpenSSL code that works and jam it into the current release.


From dclarke at blastwave.org  Thu Mar 21 14:49:22 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Thu, 21 Mar 2019 14:49:22 +0000
Subject: Openssl Version 1.1.1b fails to compile on Solaris platform(Intel
 & Sparc)
In-Reply-To: <87zhpo3dzg.wl-levitte@openssl.org>
References: <CAONacheFCxtRKQJjNOYzFcgWHVV8LcxduhXCVhw=Cww+LpLVTg@mail.gmail.com>
 <eR1zVlxzjZHaA6k@srv.efca.com> <8736ng4v32.wl-levitte@openssl.org>
 <871s304uhc.wl-levitte@openssl.org> <87zhpo3dzg.wl-levitte@openssl.org>
Message-ID: <3667c0e1-d966-d369-9381-ec3291a06639@blastwave.org>

On 3/21/19 7:04 AM, Richard Levitte wrote:
> Tentative fix: https://github.com/openssl/openssl/pull/8548
> 

I think this was all covered in detail during the beta test releases
and I am certain that last year I was quite vocal that the config files
are wrong for Solaris. The solution is that the user *must* modify the
config files and really there is no other way. The compiler that I
tested with was Oracle Studio 12.6 on a solaris 10 sparc server with
full contract support and thus the libm files were changed.  That was
all covered last year and I think Rainer Orth has been detailed and also
vocal about the libm disaster.

also see :

    Obsolete Solaris 10 support
    https://gcc.gnu.org/ml/gcc/2018-10/msg00139.html

So don't expect much in the future from gcc for Solaris 10.

Also see extensive discussions in the OpenSSL archives around the
 Solaris issues :

https://mta.openssl.org/pipermail/openssl-users/2018-February/thread.html



-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

From openssl-users at dukhovni.org  Thu Mar 21 16:51:17 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 21 Mar 2019 12:51:17 -0400
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <CA1815E4-1EB5-4EC7-BA68-D1AAB058867B@akamai.com>
References: <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
 <A2E1FA0F-8BE7-4A3E-808D-A3D599C81AAC@dukhovni.org>
 <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
 <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>
 <199E4877-FE72-4A9A-97B6-B65CEF0B574C@dukhovni.org>
 <65906247-0744-40D8-8463-15EA01BC447E@sharp.fm>
 <20190319160012.GN3822@straasha.imrryr.org>
 <8AA96214-A78C-42AF-8380-95C08599FE3B@sharp.fm>
 <CA1815E4-1EB5-4EC7-BA68-D1AAB058867B@akamai.com>
Message-ID: <20190321165117.GX3822@straasha.imrryr.org>

On Thu, Mar 21, 2019 at 01:00:14PM +0000, Salz, Rich via openssl-users wrote:

> >    This software however is 7 years old, we?re not in a position to drop everything and rewrite it.
> 
> Then don't upgrade?  If it's for a CA you don't need TLS 1.3 for example.
> 
> Or take the existing OpenSSL code that works and jam it into the current release.

Perhaps the OP is not an end-user, but rather maintains these modules
for a user community, in which case "don't upgrade" is not generally
an option.  In any case, it seems a bit premature to close the
conversation.

While the original decision to use incomplete (and thus invalid)
CSRs, is unfortunate, and not OpenSSL's fault, we can still continue
to discuss meaningful options.  On the DER padding front, the minimal
working suffix is 7 bytes:

	30 03    -- Length 3 sequence
	06 01 00 -- OBJECT ID: 0.0
	03 01 00 -- empty BIT STRING

One then also prepends a prefix (typically 4 bytes):

	30 82 xx xx -- a sequence of 256 to 65535 bytes
	30 81 xx    -- a sequence of 128 to 255 bytes
	30 xx       -- a sequence of up to 127 bytes

The "xx" length is the DER length of the CRI + 7 bytes for the
suffix.

On the OpenSSL side, having found that we emit dubious encodings
of structures with an (unspecified) null OID element, I am considering
whether it would make sense to encode them as a zero-length (invalid,
but faithful) ASN.1 OBJECT:

    06 00

*and* decode these back to a zero length NID_undef object.  While
these are likely to not interoperate with many other ASN.1 decoder
implementations, just interoperating with the same version of OpenSSL
would make it possible to encode/decode partially initialized
structures in which some "objects" are as yet unspecified.

The reason I'm considering changes is that it now appears that the
original commmit that stopped encoding single element OIDs, is not
fully baked.  Just skipping required components of structures is
not a good outcome.

-- 
	Viktor.

From uri at ll.mit.edu  Thu Mar 21 17:22:24 2019
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 21 Mar 2019 17:22:24 +0000
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <20190321165117.GX3822@straasha.imrryr.org>
References: <81CFA08D-27FE-4E32-8051-73BFB9BB9041@sharp.fm>
 <A2E1FA0F-8BE7-4A3E-808D-A3D599C81AAC@dukhovni.org>
 <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
 <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>
 <199E4877-FE72-4A9A-97B6-B65CEF0B574C@dukhovni.org>
 <65906247-0744-40D8-8463-15EA01BC447E@sharp.fm>
 <20190319160012.GN3822@straasha.imrryr.org>
 <8AA96214-A78C-42AF-8380-95C08599FE3B@sharp.fm>
 <CA1815E4-1EB5-4EC7-BA68-D1AAB058867B@akamai.com>
 <20190321165117.GX3822@straasha.imrryr.org>
Message-ID: <90FB014A-5BB1-4B48-BF03-FC5B932A04F8@ll.mit.edu>

+1 to Viktor's points.

Regards,
Uri

Sent from my iPhone

> On Mar 21, 2019, at 12:52, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
> On Thu, Mar 21, 2019 at 01:00:14PM +0000, Salz, Rich via openssl-users wrote:
> 
>>>   This software however is 7 years old, we?re not in a position to drop everything and rewrite it.
>> 
>> Then don't upgrade?  If it's for a CA you don't need TLS 1.3 for example.
>> 
>> Or take the existing OpenSSL code that works and jam it into the current release.
> 
> Perhaps the OP is not an end-user, but rather maintains these modules
> for a user community, in which case "don't upgrade" is not generally
> an option.  In any case, it seems a bit premature to close the
> conversation.
> 
> While the original decision to use incomplete (and thus invalid)
> CSRs, is unfortunate, and not OpenSSL's fault, we can still continue
> to discuss meaningful options.  On the DER padding front, the minimal
> working suffix is 7 bytes:
> 
>    30 03    -- Length 3 sequence
>    06 01 00 -- OBJECT ID: 0.0
>    03 01 00 -- empty BIT STRING
> 
> One then also prepends a prefix (typically 4 bytes):
> 
>    30 82 xx xx -- a sequence of 256 to 65535 bytes
>    30 81 xx    -- a sequence of 128 to 255 bytes
>    30 xx       -- a sequence of up to 127 bytes
> 
> The "xx" length is the DER length of the CRI + 7 bytes for the
> suffix.
> 
> On the OpenSSL side, having found that we emit dubious encodings
> of structures with an (unspecified) null OID element, I am considering
> whether it would make sense to encode them as a zero-length (invalid,
> but faithful) ASN.1 OBJECT:
> 
>    06 00
> 
> *and* decode these back to a zero length NID_undef object.  While
> these are likely to not interoperate with many other ASN.1 decoder
> implementations, just interoperating with the same version of OpenSSL
> would make it possible to encode/decode partially initialized
> structures in which some "objects" are as yet unspecified.
> 
> The reason I'm considering changes is that it now appears that the
> original commmit that stopped encoding single element OIDs, is not
> fully baked.  Just skipping required components of structures is
> not a good outcome.
> 
> -- 
>    Viktor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5821 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190321/b0906537/attachment-0001.bin>

From openssl-users at dukhovni.org  Thu Mar 21 17:57:43 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 21 Mar 2019 13:57:43 -0400
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <90FB014A-5BB1-4B48-BF03-FC5B932A04F8@ll.mit.edu>
References: <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
 <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>
 <199E4877-FE72-4A9A-97B6-B65CEF0B574C@dukhovni.org>
 <65906247-0744-40D8-8463-15EA01BC447E@sharp.fm>
 <20190319160012.GN3822@straasha.imrryr.org>
 <8AA96214-A78C-42AF-8380-95C08599FE3B@sharp.fm>
 <CA1815E4-1EB5-4EC7-BA68-D1AAB058867B@akamai.com>
 <20190321165117.GX3822@straasha.imrryr.org>
 <90FB014A-5BB1-4B48-BF03-FC5B932A04F8@ll.mit.edu>
Message-ID: <20190321175743.GZ3822@straasha.imrryr.org>

On Thu, Mar 21, 2019 at 05:22:24PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:

> > On the DER padding front, the minimal
> > working suffix is 7 bytes:

Apparently I can't count today, clearly the suffix is 8 bytes.

> > 
> >    30 03    -- Length 3 sequence
> >    06 01 00 -- OBJECT ID: 0.0
> >    03 01 00 -- empty BIT STRING
> > 
> > On the OpenSSL side, having found that we emit dubious encodings
> > of structures with an (unspecified) null OID element, I am considering
> > whether it would make sense to encode them as a zero-length (invalid,
> > but faithful) ASN.1 OBJECT:
> > 
> >    06 00
> > 
> > *and* decode these back to a zero length NID_undef object.

After discussing this idea with a friend, I am less enthusiastic
about this option.  His point is that if OpenSSL starts emitting
invalid empty OIDs as a way to support encoding incompletely
initialized structures, this could contaminate the ecosystem with
subsequent new downstream work-arounds in other implementations.

His order of "preference" is:

    1.  Return failure from i2d_ASN_OBJECT(), which then percolates
	up to failure to encode the containing structure.

    2.  Emit a "harmless" default OID (such as 0.0), returning to
	the behaviour prior to 1.0.1i

    3.  Emit the invalid empty OID (06 00) in the expectation that
	this would not be something that other decoders would have
	to support.  That is, it would only be used, as in this case,
	to serialize and deserialize objects *within* an application,
	and there would be no pressure on other implementations to
	follow suit.

I am curious what other OpenSSL developers and users would like to
see happen.  Any of the above?  Or something else?  The present
behaviour seems wrong to me, because we're silently generating
invalid structures with missing required fields (when encoding
incompletely initialized structures).

Failing in i2d_ASN1_OBJECT() is unlikely to do harm, because the
current invalid output is not better, and we've not seen any
complaints until now in ~5 years of OpenSSL 1.0.2 deployment.
So use of i2d on partially created objects looks rather rare,
and perhaps explicit failure is better than any ad-hoc output?

-- 
	Viktor.

From kgoldman at us.ibm.com  Thu Mar 21 19:43:55 2019
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Thu, 21 Mar 2019 15:43:55 -0400
Subject: Using (not building) openssl with mingw on Windows 10
In-Reply-To: <BYAPR18MB29184811032E36BF024D6EFFF9410@BYAPR18MB2918.namprd18.prod.outlook.com>
References: <pqvvjb$phc$1@blaine.gmane.org>
 <09f436c6-a225-3d6a-540d-361026bc95b2@wisemo.com>
 <q6tjn9$3m80$1@blaine.gmane.org>
 <BYAPR18MB29184811032E36BF024D6EFFF9410@BYAPR18MB2918.namprd18.prod.outlook.com>
Message-ID: <c606e9da-6b5c-63df-e4cb-7cc0ae73ef68@us.ibm.com>

On 3/20/2019 12:41 PM, Michael Wojcik wrote:

> 
> Sounds like you might have import libraries there. Does "ar t 
> libcrypto.lib" show a bunch of .obj members, or a bunch of .dll 
> members? If it's the latter, then it's just an import library that 
> tells the linker what DLL needs to be loaded at runtime.

ar t libcrypto.lib returns about 4100 lines of:

libcrypto-1_1-x64.dll
libcrypto-1_1-x64.dll
...

So it's an 'import library'.  But I get link errors, with each openssl 
function missing.

Any clues?

> We build static (non-import) OpenSSL libraries for Windows, but at 
> least for 1.0.2 we had to tweak the configuration process. The stock 
> Configure wanted to link OpenSSL with the static Microsoft C runtime 
> if you were building static libraries, whereas we wanted static 
> libraries linked with the dynamic runtime. (I don't remember offhand 
> if we had to do the same for 1.1.1.)

I'm not building OpenSSL.  I use Shining Light, because I don't want to
ship OpenSSL with my code and I certainly don't want to require
my users to build it.


From kgoldman at us.ibm.com  Thu Mar 21 19:52:20 2019
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Thu, 21 Mar 2019 15:52:20 -0400
Subject: Using (not building) openssl with mingw on Windows 10
In-Reply-To: <DM6PR17MB221948E3094AF3B081C8E3BBCC410@DM6PR17MB2219.namprd17.prod.outlook.com>
References: <pqvvjb$phc$1@blaine.gmane.org>
 <09f436c6-a225-3d6a-540d-361026bc95b2@wisemo.com>
 <q6tjn9$3m80$1@blaine.gmane.org>
 <DM6PR17MB221948E3094AF3B081C8E3BBCC410@DM6PR17MB2219.namprd17.prod.outlook.com>
Message-ID: <48e5e03a-bb5d-1701-341f-7676056e9518@us.ibm.com>

On 3/20/2019 6:44 PM, Sergio NNX wrote:
>>> I've been happily using the Shining Light 32-bit binaries with both
>>> openssl 1.0 and 1.1 and mingw.
> 
>> Getting back to this:
> 
>> I tried mingw linking against these
> 
>> "c:/program files/openssl64/lib/libcrypto.lib"
>> "c:/program files/openssl64/lib/libssl.lib"
> 
>> but the gcc linker failed to find the openssl functions.
> 
>> Anyone have any ideas?
> 
> We have been using OpenSSL for Windows (x64) built with MinGW for a long 
> time.

Can you send your linker command.  What from the OpenSSL64/lib
directory do you link to?

Below is your compiler command, but it's my linker that's failing.

>  ? ? compiler: gcc.exe -m64 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 
> -D_WIN32_IE=0x0501 -DPTW32_STATIC_LIB -D__CLEANUP_C -m64 -O2 -pipe 
> -mms-bitfields -fno-builtin -march=core2 -mtune=core2 -DL_ENDIAN 
> -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM 
> -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM 
> -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM 
> -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -D_WIN32_IE=0x0501 
> -DPTW32_STATIC_LIB -D__CLEANUP_C -DUNICODE -D_UNICODE 
> -DWIN32_LEAN_AND_MEAN -DOPENSSL_SSL_CLIENT_ENGINE_AUTO=capi 
> -DOPENSSL_CAPIENG_DIALOG -m64 -pipe -mms-bitfields -fno-builtin 
> -march=core2 -mtune=core2 -D_MT -DZLIB -DNDEBUG -I/mingw/include
> 
> @Ken: this seems to be a quite old thread, but if you need either the 
> include files or the .a files
>  ? ? ? or both, we could email them to you.

I have the include files.

I think I need the .a files or equivalent, but I prefer to use the 
Shining Light install.  If I get a private copy from you, I have to
distribute it.

Besides the process and legal issues, it doesn't feel right to
distribute security code that I got via email from an unknown
person with the email name 'sfhacker'.  :-)



From uri at ll.mit.edu  Thu Mar 21 19:59:40 2019
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 21 Mar 2019 19:59:40 +0000
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <20190321175743.GZ3822@straasha.imrryr.org>
References: <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
 <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>
 <199E4877-FE72-4A9A-97B6-B65CEF0B574C@dukhovni.org>
 <65906247-0744-40D8-8463-15EA01BC447E@sharp.fm>
 <20190319160012.GN3822@straasha.imrryr.org>
 <8AA96214-A78C-42AF-8380-95C08599FE3B@sharp.fm>
 <CA1815E4-1EB5-4EC7-BA68-D1AAB058867B@akamai.com>
 <20190321165117.GX3822@straasha.imrryr.org>
 <90FB014A-5BB1-4B48-BF03-FC5B932A04F8@ll.mit.edu>
 <20190321175743.GZ3822@straasha.imrryr.org>
Message-ID: <5A2B34A1-B128-47E1-8332-C348993C6792@ll.mit.edu>

First, let me prefix that while I don't want to badmouth anybody, even incompetence cannot excuse deliberately generating bad/unparsable encoding. That's one of the cases when the cure is clearly worse than the disease.

On 3/21/19, 13:58, "openssl-users on behalf of Viktor Dukhovni" <openssl-users-bounces at openssl.org on behalf of openssl-users at dukhovni.org> wrote:
    > > On the OpenSSL side, having found that we emit dubious encodings
    > > of structures with an (unspecified) null OID element, I am considering
    > > whether it would make sense to encode them as a zero-length (invalid,
    > > but faithful) ASN.1 OBJECT:
    > > 
    > >    06 00
    > > 
    > > *and* decode these back to a zero length NID_undef object.
    
    After discussing this idea with a friend, I am less enthusiastic
    about this option.  His point is that if OpenSSL starts emitting
    invalid empty OIDs as a way to support encoding incompletely
    initialized structures, this could contaminate the ecosystem with
    subsequent new downstream work-arounds in other implementations.

I don't see how it is worse than what's there now.
    
    His order of "preference" is:
    
        1.  Return failure from i2d_ASN_OBJECT(), which then percolates
    	up to failure to encode the containing structure.

That would be the correct but strict behavior: OID is required, therefore no OID -> no encoding. Just fail (hopefully with an explanatory error code, and documented!)

            2.  Emit a "harmless" default OID (such as 0.0), returning to
    	the behaviour prior to 1.0.1i

I'm OK with that, and it's probably more acceptable than (1), though OID "0.0" is not the same as "no-OID". I wonder if there's ever a case when OID "0.0" can appear in this construct? If so, then (2) is unacceptable, otherwise I don't know.

But the original "fix" (can't call it that but in quotes and with big tongue-in-cheek) was there for a reason, however misguided the actual change turned out to be. What was the reason for changing this (original) behavior? Just desire for "purity" (....), or something more tangible/reasonable?
    
        3.  Emit the invalid empty OID (06 00) in the expectation that
    	this would not be something that other decoders would have
    	to support.  That is, it would only be used, as in this case,
    	to serialize and deserialize objects *within* an application,
    	and there would be no pressure on other implementations to
    	follow suit.

I'm OK with (3) too. In fact, this would probably be my first preference - and yes, implementations that care to support use cases with no-OID would have to support this. But at least they won't have a broken parser on their hands.
    
    Failing in i2d_ASN1_OBJECT() is unlikely to do harm, because the
    current invalid output is not better, and we've not seen any
    complaints until now in ~5 years of OpenSSL 1.0.2 deployment.
    So use of i2d on partially created objects looks rather rare,
    and perhaps explicit failure is better than any ad-hoc output?

Failing in i2d_ASN1_OBJECT() would be my second preference. My first preference would be your (3). I can live with (2), but I don't like it much because substituting a valid OID for a no-OID is "slippery".
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190321/919bab69/attachment.bin>

From openssl-users at dukhovni.org  Thu Mar 21 20:06:31 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 21 Mar 2019 16:06:31 -0400
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <20190321175743.GZ3822@straasha.imrryr.org>
References: <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
 <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>
 <199E4877-FE72-4A9A-97B6-B65CEF0B574C@dukhovni.org>
 <65906247-0744-40D8-8463-15EA01BC447E@sharp.fm>
 <20190319160012.GN3822@straasha.imrryr.org>
 <8AA96214-A78C-42AF-8380-95C08599FE3B@sharp.fm>
 <CA1815E4-1EB5-4EC7-BA68-D1AAB058867B@akamai.com>
 <20190321165117.GX3822@straasha.imrryr.org>
 <90FB014A-5BB1-4B48-BF03-FC5B932A04F8@ll.mit.edu>
 <20190321175743.GZ3822@straasha.imrryr.org>
Message-ID: <F3250BC0-19EA-4B7C-9EC1-54E63F93C0EC@dukhovni.org>

> On Mar 21, 2019, at 1:57 PM, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
>    1.  Return failure from i2d_ASN_OBJECT(), which then percolates
> 	up to failure to encode the containing structure.
> 
>    2.  Emit a "harmless" default OID (such as 0.0), returning to
> 	the behaviour prior to 1.0.1i
> 
>    3.  Emit the invalid empty OID (06 00) in the expectation that
> 	this would not be something that other decoders would have
> 	to support.  That is, it would only be used, as in this case,
> 	to serialize and deserialize objects *within* an application,
> 	and there would be no pressure on other implementations to
> 	follow suit.
> 
> I am curious what other OpenSSL developers and users would like to
> see happen.  Any of the above?  Or something else?  The present
> behaviour seems wrong to me, because we're silently generating
> invalid structures with missing required fields (when encoding
> incompletely initialized structures).

I've opened https://github.com/openssl/openssl/issues/8553 to track
this issue.

-- 
	Viktor.


From richmoore44 at gmail.com  Thu Mar 21 23:26:15 2019
From: richmoore44 at gmail.com (Richard Moore)
Date: Thu, 21 Mar 2019 23:26:15 +0000
Subject: cURL with openSSL 1.1.1 version
In-Reply-To: <HE1PR0602MB3643DF1FD528D8783EF804BF96400@HE1PR0602MB3643.eurprd06.prod.outlook.com>
References: <HE1PR0602MB3643DF1FD528D8783EF804BF96400@HE1PR0602MB3643.eurprd06.prod.outlook.com>
Message-ID: <CAMp7mVt2YMocYsZoESdTjkD_zJ9UEp42O-4wYatsvRXCJ8ZNwQ@mail.gmail.com>

On Tue, 19 Mar 2019 at 07:56, Swamy J-S <swamy.j-s at in.abb.com> wrote:

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

If you use gnuTLS as your SSL backend then this is nothing to do with
openssl at all.

Kind Regards

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

From Michael.Wojcik at microfocus.com  Fri Mar 22 16:18:19 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 22 Mar 2019 16:18:19 +0000
Subject: Using (not building) openssl with mingw on Windows 10
In-Reply-To: <c606e9da-6b5c-63df-e4cb-7cc0ae73ef68@us.ibm.com>
References: <pqvvjb$phc$1@blaine.gmane.org>
 <09f436c6-a225-3d6a-540d-361026bc95b2@wisemo.com>
 <q6tjn9$3m80$1@blaine.gmane.org>
 <BYAPR18MB29184811032E36BF024D6EFFF9410@BYAPR18MB2918.namprd18.prod.outlook.com>
 <c606e9da-6b5c-63df-e4cb-7cc0ae73ef68@us.ibm.com>
Message-ID: <BYAPR18MB2918BA236A221FB804502FF5F9430@BYAPR18MB2918.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Ken Goldman
> Sent: Thursday, March 21, 2019 13:44
> To: openssl-users at openssl.org
>
> On 3/20/2019 12:41 PM, Michael Wojcik wrote:
>
> >
> > Sounds like you might have import libraries there. Does "ar t
> > libcrypto.lib" show a bunch of .obj members, or a bunch of .dll
> > members? If it's the latter, then it's just an import library that
> > tells the linker what DLL needs to be loaded at runtime.
>
> ar t libcrypto.lib returns about 4100 lines of:
>
> libcrypto-1_1-x64.dll
> libcrypto-1_1-x64.dll
> ...
>
> So it's an 'import library'.  But I get link errors, with each openssl
> function missing.
>
> Any clues?

Without picking at the problem files myself, not really. It's probably something that will be fairly obvious in retrospect but I'm not seeing it from here.

The import libraries (I'm assuming libssl.lib is one as well, on your system) basically tell the linker "for this symbol, insert a runtime load reference to this DLL". The Cygwin nm can display the symbols in an import library; I don't remember if MingW includes nm, or know if it understands import libraries.

So well-formed import versions of libcrypto.lib and libssl.lib should name all the public OpenSSL symbols, and you shouldn't get resolution errors when linking against them. You might well get resolution errors at runtime, if the corresponding DLLs can't be found; but not a link time.

I seem to have discarded some of your older messages. Did you ever send us the actual link command that's being used? Maybe that will throw some light on the problem.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From Michael.Wojcik at microfocus.com  Fri Mar 22 16:18:20 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 22 Mar 2019 16:18:20 +0000
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <F3250BC0-19EA-4B7C-9EC1-54E63F93C0EC@dukhovni.org>
References: <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
 <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>
 <199E4877-FE72-4A9A-97B6-B65CEF0B574C@dukhovni.org>
 <65906247-0744-40D8-8463-15EA01BC447E@sharp.fm>
 <20190319160012.GN3822@straasha.imrryr.org>
 <8AA96214-A78C-42AF-8380-95C08599FE3B@sharp.fm>
 <CA1815E4-1EB5-4EC7-BA68-D1AAB058867B@akamai.com>
 <20190321165117.GX3822@straasha.imrryr.org>
 <90FB014A-5BB1-4B48-BF03-FC5B932A04F8@ll.mit.edu>
 <20190321175743.GZ3822@straasha.imrryr.org>
 <F3250BC0-19EA-4B7C-9EC1-54E63F93C0EC@dukhovni.org>
Message-ID: <BYAPR18MB2918ED53F0B1493F0405F458F9430@BYAPR18MB2918.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Viktor Dukhovni
> Sent: Thursday, March 21, 2019 14:07
> To: openssl-users at openssl.org
>
> > On Mar 21, 2019, at 1:57 PM, Viktor Dukhovni <openssl-users at dukhovni.org>
> wrote:
> >
> >    2.  Emit a "harmless" default OID (such as 0.0), returning to
> >     the behaviour prior to 1.0.1i

What about registering a new OID for "missing required object"? Then at least there'd be a standard way to represent this case, and other parsers could decide to accommodate it however they prefer.

I'm by no means an ASN.1 expert, so this may be a dumb idea.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From uri at ll.mit.edu  Fri Mar 22 18:12:44 2019
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Fri, 22 Mar 2019 18:12:44 +0000
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <BYAPR18MB2918ED53F0B1493F0405F458F9430@BYAPR18MB2918.namprd18.prod.outlook.com>
References: <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
 <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>
 <199E4877-FE72-4A9A-97B6-B65CEF0B574C@dukhovni.org>
 <65906247-0744-40D8-8463-15EA01BC447E@sharp.fm>
 <20190319160012.GN3822@straasha.imrryr.org>
 <8AA96214-A78C-42AF-8380-95C08599FE3B@sharp.fm>
 <CA1815E4-1EB5-4EC7-BA68-D1AAB058867B@akamai.com>
 <20190321165117.GX3822@straasha.imrryr.org>
 <90FB014A-5BB1-4B48-BF03-FC5B932A04F8@ll.mit.edu>
 <20190321175743.GZ3822@straasha.imrryr.org>
 <F3250BC0-19EA-4B7C-9EC1-54E63F93C0EC@dukhovni.org>
 <BYAPR18MB2918ED53F0B1493F0405F458F9430@BYAPR18MB2918.namprd18.prod.outlook.com>
Message-ID: <CA35C05C-EF2D-401A-BE43-4FBE37B51438@ll.mit.edu>

Hmm... Registering an OID dedicated to express this case should be feasible, and perfectly within the ASN.1 rules. One question - where in the OID tree would it live, as offhand I don't have any idea. It can't be too deep down, and also, it better be fairly short.  

>From the ASN.1 point of view - there's nothing dumb in this idea. There's plenty of MIB objects expressing/representing all kinds of things - might as well add this.



?On 3/22/19, 12:34, "openssl-users on behalf of Michael Wojcik" <openssl-users-bounces at openssl.org on behalf of Michael.Wojcik at microfocus.com> wrote:

    > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
    > Viktor Dukhovni
    > Sent: Thursday, March 21, 2019 14:07
    > To: openssl-users at openssl.org
    >
    > > On Mar 21, 2019, at 1:57 PM, Viktor Dukhovni <openssl-users at dukhovni.org>
    > wrote:
    > >
    > >    2.  Emit a "harmless" default OID (such as 0.0), returning to
    > >     the behaviour prior to 1.0.1i
    
    What about registering a new OID for "missing required object"? Then at least there'd be a standard way to represent this case, and other parsers could decide to accommodate it however they prefer.
    
    I'm by no means an ASN.1 expert, so this may be a dumb idea.
    
    --
    Michael Wojcik
    Distinguished Engineer, Micro Focus
    
    
    
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190322/6a6cdd2a/attachment.bin>

From kgoldman at us.ibm.com  Fri Mar 22 20:34:42 2019
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Fri, 22 Mar 2019 16:34:42 -0400
Subject: Using (not building) openssl with mingw on Windows 10
In-Reply-To: <BYAPR18MB2918BA236A221FB804502FF5F9430@BYAPR18MB2918.namprd18.prod.outlook.com>
References: <pqvvjb$phc$1@blaine.gmane.org>
 <09f436c6-a225-3d6a-540d-361026bc95b2@wisemo.com>
 <q6tjn9$3m80$1@blaine.gmane.org>
 <BYAPR18MB29184811032E36BF024D6EFFF9410@BYAPR18MB2918.namprd18.prod.outlook.com>
 <c606e9da-6b5c-63df-e4cb-7cc0ae73ef68@us.ibm.com>
 <BYAPR18MB2918BA236A221FB804502FF5F9430@BYAPR18MB2918.namprd18.prod.outlook.com>
Message-ID: <q73gt2$g09$1@blaine.gmane.org>

On 3/22/2019 12:18 PM, Michael Wojcik wrote:
> 
> I seem to have discarded some of your older messages. Did you ever
> send us the actual link command that's being used? Maybe that will
> throw some light on the problem.

"c:/program files/mingw/bin/gcc.exe" -D_MT -DTPM_WINDOWS -I.  -shared -o 
libibmtss.dll tssfile.o tsscryptoh.o tsscrypto.o tssprintcmd.o tss.o 
tssproperties.o tssmarshal.o tssauth.o tssutils.o tsssocket.o tssdev.o 
tsstransmit.o tssresponsecode.o tssccattributes.o tssprint.o Unmarshal.o 
CommandAttributeData.o tss20.o tssauth20.o Commands.o ntc2lib.o tssntc.o
-Wl,--out-implib,libibmtss.a "c:/program 
files/openssl64/lib/libcrypto.lib" "c:/program files/MinGW/lib/libws2_32.a"

tsscrypto.o: In function `TSS_Crypto_Init':
c:\Users\KennethGoldman\tpm2\utils/tsscrypto.c:109: undefined reference 
to `OPENSSL_init_crypto'
tsscrypto.o: In function `TSS_Hash_GetMd':
c:\Users\KennethGoldman\tpm2\utils/tsscrypto.c:133: undefined reference 
to `EVP_get_digestbyname'
...
continues for all OpenSSL function names

~~

My guess is that this link snippet is wrong, but I don't know what it 
should be.

"c:/program files/openssl64/lib/libcrypto.lib"

~~

For Openssl 32-bit, this worked, but the .a is not in the 64-bit Shining 
Light build.

"c:/program files/openssl/lib/mingw/libcrypto-1_1.a"



From sfhacker at hotmail.com  Sat Mar 23 12:01:24 2019
From: sfhacker at hotmail.com (Sergio NNX)
Date: Sat, 23 Mar 2019 12:01:24 +0000
Subject: Using (not building) openssl with mingw on Windows 10
In-Reply-To: <q73gt2$g09$1@blaine.gmane.org>
References: <pqvvjb$phc$1@blaine.gmane.org>
 <09f436c6-a225-3d6a-540d-361026bc95b2@wisemo.com>
 <q6tjn9$3m80$1@blaine.gmane.org>
 <BYAPR18MB29184811032E36BF024D6EFFF9410@BYAPR18MB2918.namprd18.prod.outlook.com>
 <c606e9da-6b5c-63df-e4cb-7cc0ae73ef68@us.ibm.com>
 <BYAPR18MB2918BA236A221FB804502FF5F9430@BYAPR18MB2918.namprd18.prod.outlook.com>,
 <q73gt2$g09$1@blaine.gmane.org>
Message-ID: <DM6PR17MB2219D655A58B100C241E2B5BCC5C0@DM6PR17MB2219.namprd17.prod.outlook.com>

> "c:/program files/mingw/bin/gcc.exe" -D_MT -DTPM_WINDOWS -I.  -shared -o
> libibmtss.dll tssfile.o tsscryptoh.o tsscrypto.o tssprintcmd.o tss.o
> tssproperties.o tssmarshal.o tssauth.o tssutils.o tsssocket.o tssdev.o
> tsstransmit.o tssresponsecode.o tssccattributes.o tssprint.o Unmarshal.o
> CommandAttributeData.o tss20.o tssauth20.o Commands.o ntc2lib.o tssntc.o
> -Wl,--out-implib,libibmtss.a "c:/program
> files/openssl64/lib/libcrypto.lib" "c:/program files/MinGW/lib/libws2_32.a"

> tsscrypto.o: In function `TSS_Crypto_Init':
> c:\Users\KennethGoldman\tpm2\utils/tsscrypto.c:109: undefined reference
> to `OPENSSL_init_crypto'
> tsscrypto.o: In function `TSS_Hash_GetMd':
> c:\Users\KennethGoldman\tpm2\utils/tsscrypto.c:133: undefined reference
> to `EVP_get_digestbyname'
> ...
> continues for all OpenSSL function names


It seems to work fine here:

/mingw/bin/gcc.exe -DTPM_WINDOWS -D_MT -L. -shared -Wl,--no-undefined -Wl,--out-implib,libibmtss.dll.a -o libibmtss-1.1.dll \
                        tssfile.o tsscryptoh.o tsscrypto.o tssprintcmd.o tss.o tssproperties.o tssmarshal.o tssauth.o tssutils.o tsssocket.o tssdev.o tsstransmit.o tssresponsecode.o tssccattributes.o tssprint.o Unmarshal.o CommandAttributeData.o tss12.o tssauth12.o tssmarshal12.o Unmarshal12.o Commands12.o tssccattributes12.o CommandAttributeData12.o tss20.o tssauth20.o Commands.o ntc2lib.o tssntc.o -lcrypto -lz -lcrypt32 -lws2_32


Sorry to pollute this list! You will soon find out why!

Out of curiosity, we downloaded ibmtss1331.tar.gz and tried to build it from source (first time ever).

We have been using MSYS/MinGW for quite some time and we build (from source) and deploy large projects (with many dependencies) on a regular basis.
We tried to do the same with this project (ibmtss).
Then, on a MSYS console window we typed: make -f makefile.mak under 'ibmtss1331\utils' folder.

Find some snippets of 'makefile.mak' file:

    * CC = "c:/program files/mingw/bin/gcc.exe"

   * -I"c:/program files/MinGW/include" \
   * -I"c:/program files/openssl/include" \

    * LNLIBS =  "c:/program files/openssl/lib/mingw/libeay32.a" \
         "c:/program files/openssl/lib/mingw/ssleay32.a" \
         "c:/program files/MinGW/lib/libws2_32.a"

  * imaextend.exe: imaextend.o imalib.o $(LIBTSS)
     $(CC) $(LNFLAGS) -L. -libmtss $< -o $@ applink.o imalib.o $(LNLIBS) $(LIBTSS)


As you can imagine, there are dozens of compilation errors, such as:

    $ make -f makefile.mak all
    "c:/program files/mingw/bin/gcc.exe" -DTPM_WINDOWS -I. -I"c:/program files/MinGW/include" -I"c:/program files/openssl/include"  -Wall -W -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wformat=2 -Wold-style-definition -ggdb -O0 -c -DTPM_TPM20 tssfile.c
    /bin/sh: c:/program files/mingw/bin/gcc.exe: No such file or directory
    make: *** [tssfile.o] Error 127

    cc1.exe: warning: unrecognized command line option '-Wno-self-assign'

Some runtime errors or 'mistakes', such as:

    $ powerup.exe -v
    TSS_Socket_Open: Opening localhost:2322-mssim
    TSS_Socket_Open: Error on connect to localhost:2322
    TSS_Socket_Open: client connect: error 0 No error
    powerup: failed, rc 000b0008
    TSS_RC_NO_CONNECTION - Failure connecting to lower layer

None of the executables provide some sort of version info and/or dependencies info (e.g. OpenSSL version)

It is impossible to figure out how tests can be run! We tried: make -f makefile.mak check and make -f makefile.mak test and we got:

    make: *** No rule to make target `check'.  Stop.

    make: *** No rule to make target `test'.  Stop.

Trying to build from source a 'cousin' project (ibmtpm1332), taken from the same repository,  we came across things like this (we use MinGW x64):

    #elif TPM_POSIX && !defined _LP64
    #define  RADIX_BITS                     32

    #elif TPM_POSIX &&  defined _LP64
    #define  RADIX_BITS                    64

    #elif TPM_WINDOWS
    #define  RADIX_BITS                     32

    #else
    #error "RADIX_BITS is not set"

    #endif

But then you get:

    In file included from BnValues.h:271:0,
                 from Global.h:83,
                 from Tpm.h:71,
                 from AlgorithmCap.c:67:
    TpmToOsslMath.h:83:4: error: #error "Ossl library is using different radix"
    #  error "Ossl library is using different radix"
       ^~~~~
    make: *** [AlgorithmCap.o] Error 1

On the one hand, we are preparing a comprehensive patch as a contribution to the ibmtss/tpm project(s).
On the other hand, we refuse to believe that IBM is 'fostering' these practices and quality in 2019! We have decided to contact IBM to report and discuss this matter.

To my mind, we can conclude that OpenSSL project has nothing to do with the issue reported here. Sorry again!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190323/2c64f7e6/attachment.html>

From mcr at sandelman.ca  Sat Mar 23 16:33:46 2019
From: mcr at sandelman.ca (Michael Richardson)
Date: Sat, 23 Mar 2019 17:33:46 +0100
Subject: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding
 routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
In-Reply-To: <CA35C05C-EF2D-401A-BE43-4FBE37B51438@ll.mit.edu>
References: <DA098F66-D43D-4A61-A518-E18AB8095EDA@sharp.fm>
 <5A643760-A47C-4A30-86AC-77ADF93E680D@carillon.ca>
 <D9ADBB52-F266-4585-B31B-3A0E456E37D7@sharp.fm>
 <199E4877-FE72-4A9A-97B6-B65CEF0B574C@dukhovni.org>
 <65906247-0744-40D8-8463-15EA01BC447E@sharp.fm>
 <20190319160012.GN3822@straasha.imrryr.org>
 <8AA96214-A78C-42AF-8380-95C08599FE3B@sharp.fm>
 <CA1815E4-1EB5-4EC7-BA68-D1AAB058867B@akamai.com>
 <20190321165117.GX3822@straasha.imrryr.org>
 <90FB014A-5BB1-4B48-BF03-FC5B932A04F8@ll.mit.edu>
 <20190321175743.GZ3822@straasha.imrryr.org>
 <F3250BC0-19EA-4B7C-9EC1-54E63F93C0EC@dukhovni.org>
 <BYAPR18MB2918ED53F0B1493F0405F458F9430@BYAPR18MB2918.namprd18.prod.outlook.com>
 <CA35C05C-EF2D-401A-BE43-4FBE37B51438@ll.mit.edu>
Message-ID: <13940.1553358826@dooku.sandelman.ca>


Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu> wrote:
    > Hmm... Registering an OID dedicated to express this case should be
    > feasible, and perfectly within the ASN.1 rules. One question - where in
    > the OID tree would it live, as offhand I don't have any idea. It can't
    > be too deep down, and also, it better be fairly short.

In some vendor PEN space if 0.0 is a bad idea.
I'm sure that someone has one, or I can volunteer a number from mine.
I don't see why it has to be short if it never leaves in a legitimate CSR.

    > From the ASN.1 point of view - there's nothing dumb in this
    > idea. There's plenty of MIB objects expressing/representing all kinds
    > of things - might as well add this.

+1.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190323/7aa4afb9/attachment.sig>

From 72911e at gmail.com  Mon Mar 25 00:20:43 2019
From: 72911e at gmail.com (Tim Webber)
Date: Sun, 24 Mar 2019 20:20:43 -0400
Subject: aes-cbc-256 mode descryption without an IV
Message-ID: <CAOrpx1TyqWBZErj=6L3cSQ_CMfJoiHrk2byALHi2FF8WaoPuCQ@mail.gmail.com>

I just posted a message which i have copied below to a python forum.  It
might be better asked here.  The coles notes version of my question is this:

I have received an encrypted data file (mydata.encrypted) and a key (plain
text for now) and the following command to decrypt it:

openssl enc -d -aes-256-cbc -a -in mydata.encrypted -out mydata.decrypted
-kfile my_symmetric_key

Question is this.  How is the initialization vector calculated?  This
command works fine.  My issues is that i dont know how the initialization
vetor is calculated.  I suspect if its left out there is some default way
of doing it.  Can you tell me how its done? Thanks!

************************* ORIGINAL QUESTION to python community
******************

I have received an encrypted data file (mydata.encrypted) and a key (plain
text for now) and the following command to decrypt it:

openssl enc -d -aes-256-cbc -a -in mydata.encrypted -out mydata.decrypted
-kfile my_symmetric_key

The people who encrypted these data did so with openssl but I dont know
what the encrypt command looks like. I do know that the above command does
decrypt the data successfully though.

I want to use Python to decrypt this file. I am thinking of using
cryptodome but am open to suggestions. Here's what i know from the above
openssl decrypt command.

- its uses AES cbc 256 mode for the decryption ( -d )
- it uses base64 to encode the data "AFTER" (-a) the cryptographic operation
- it does not specify the initialization vector (IV).

I am struggling with how to code for this using python. What I suspect is
my problem is that i dont know how to properly calculate the IV. Looking at
the openssl documentation they say to see "key derivation" to find out how
they handle IV when its not specified. I cant track down this key
derivation information. Any help will be appreciated!
*******************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190324/111c0c8b/attachment-0001.html>

From aqoyyuum at cardaccess.com.au  Mon Mar 25 00:33:55 2019
From: aqoyyuum at cardaccess.com.au (Abdul Qoyyuum)
Date: Mon, 25 Mar 2019 11:33:55 +1100
Subject: Internal IP Exposed
Message-ID: <CAA3DN=X-cNFT0LXN+djWzoLaHThQJBybGFqsdvOKNoAFrqfxew@mail.gmail.com>

Hi all,

New to the mailing list and a complete newbie to openssl and the likes.
There's a ticket by a client that I'm new at and he claims that there's a
security problem with the openssl command to his servers.

Internal IP exposed after running a openssl (version 1.1.0j) connect
command:

openssl s_client -connect 103.XX.XXX.XX:10443 -quiet

Where 103.XX.XXX.XX is a Public IP. And after it shows the certificates,
typed the following:

GET /images HTTP/1.0

And hit enter twice, the following gets displayed:

HTTP/1.0 301 Moved Permanently
Date: Mon, 25 Mar 2019 00:10:13 GMT
Server: xxxxxxxx-xxxxx
Location: https://10.240.123.1:10443/images/
Connection: close
Content-Type: text/html; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=28800

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>301 Moved Permanently</TITLE>
</HEAD><BODY>
<H1>Moved Permanently</H1>
The document has moved <A HREF="https://10.240.123.1:10443/images/">here</A>.<P>
</BODY></HTML>
read:errno=0

The 10.240.123.1 is an internal IP and it is exposed by this little method.
Although not shown when using curl -kv -O command.

Is there a way to cover up the "Location" or at least the internal IP from
being exposed? Thanks.
Sorry if this isn't clear or if this is the wrong place to ask this.

-- 
Abdul Qoyyuum Bin Haji Abdul Kadir
HP No: +673 720 8043
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190325/d18021eb/attachment.html>

From karl at denninger.net  Mon Mar 25 00:46:56 2019
From: karl at denninger.net (Karl Denninger)
Date: Sun, 24 Mar 2019 19:46:56 -0500
Subject: Internal IP Exposed
In-Reply-To: <CAA3DN=X-cNFT0LXN+djWzoLaHThQJBybGFqsdvOKNoAFrqfxew@mail.gmail.com>
References: <CAA3DN=X-cNFT0LXN+djWzoLaHThQJBybGFqsdvOKNoAFrqfxew@mail.gmail.com>
Message-ID: <4ffa0856-d5a9-2825-6dd9-5262f287dc2f@denninger.net>


On 3/24/2019 19:33, Abdul Qoyyuum wrote:
> Hi all,
>
> New to the mailing list and a complete newbie to openssl and the
> likes. There's a ticket by a client that I'm new at and he claims that
> there's a security problem with the openssl command to his servers.
>
> Internal IP exposed after running a openssl (version 1.1.0j) connect
> command:
>
> |openssl s_client -connect 103.XX.XXX.XX:10443 -quiet |
>
> Where 103.XX.XXX.XX is a Public IP. And after it shows the
> certificates, typed the following:
>
> |GET /images HTTP/1.0 |
>
> And hit enter twice, the following gets displayed:
>
> |HTTP/1.0 301 Moved Permanently Date: Mon, 25 Mar 2019 00:10:13 GMT
> Server: xxxxxxxx-xxxxx Location: https://10.240.123.1:10443/images/
> Connection: close Content-Type: text/html; charset=utf-8
> X-Frame-Options: SAMEORIGIN Content-Security-Policy: frame-ancestors
> 'self' X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff
> Strict-Transport-Security: max-age=28800 <!DOCTYPE HTML PUBLIC
> "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD> <TITLE>301 Moved
> Permanently</TITLE> </HEAD><BODY> <H1>Moved Permanently</H1> The
> document has moved <A
> HREF="https://10.240.123.1:10443/images/">here</A>.<P> </BODY></HTML>
> read:errno=0 |
>
> The 10.240.123.1 is an internal IP and it is exposed by this little
> method. Although not shown when using |curl -kv -O| command.
>
> Is there a way to cover up the "Location" or at least the internal IP
> from being exposed? Thanks.
>
> Sorry if this isn't clear or if this is the wrong place to ask this.
>
OpenSSL is not involved in that in any way so the fix and issue is not
there.

I am assuming that the original connection is to a "tunnel" on the
internal/external gateway.? That is, connect to <a.b.c.d:10443> and the
gateway "twists" that to the internal address on port 443, which is the
usual HTTPS port (this assumption is due to that looking like an HTTPS
server from what it returns.)? This is a very common firewall/gateway
function.

The issue is that OpenSSL just created and maintained the SSL connection
and data transport.? The offending information isn't emitted by OpenSSL;
it's emitted by the remote server code itself and OpenSSL simply
transports it from one end to the other, encrypted.? It thus must (and
does) transport exactly, byte-by-byte, whatever it gets (in both
directions.)

The server code on the remote end could be programmed to not issue the
header and body text, but if it generates a 301 the HTML header
"Location:" MUST be returned with the new location by the HTML
specifications so the application that connected (typically a browser)
can issue a new request to the correct, redirected place.? However it
doesn't have to return an IP number and most servers do not because
there frequently is more than one host and/or domain on a given IP
number -- it could and should instead return a domain name (e.g.
"https://www.example.com/images") -- but that header has to be there.?
The body text actually does not; it can be void and it's ok (that's not
used by browsers, but is useful for humans if/when troubleshooting.)

The issue is LIKELY that the host in question doesn't have a reverse IP
mapped for itself but that's web server and OS dependent.? It may also
be that the hostname is not defined in the server's configuration file.?
Without knowing what the web server in question is all I can do there is
guess as to exactly what is missing, but in any event the issue is in
the web server application configuration and not OpenSSL.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190324/9f05e314/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190324/9f05e314/attachment.bin>

From public at enkore.de  Mon Mar 25 12:08:02 2019
From: public at enkore.de (Marian Beermann)
Date: Mon, 25 Mar 2019 13:08:02 +0100
Subject: aes-cbc-256 mode descryption without an IV
In-Reply-To: <CAOrpx1TyqWBZErj=6L3cSQ_CMfJoiHrk2byALHi2FF8WaoPuCQ@mail.gmail.com>
References: <CAOrpx1TyqWBZErj=6L3cSQ_CMfJoiHrk2byALHi2FF8WaoPuCQ@mail.gmail.com>
Message-ID: <fa422cab-60a4-3b24-f0f4-0074680b80cb@enkore.de>

Well let's just read the man pages, shall we?

>        -kfile filename
> Read the password to derive the key from the first line of filename.

Then

>        -md digest
> Use the specified digest to create the key from the passphrase.
> The default algorithm is sha-256.

And

>       -iv IV
> ...
> When a password is being specified using one of the other options, the
IV is generated from this password.

The man page doesn't specify the key derivation algorithm, but a quick
glance at apps/enc.c shows that it uses EVP_BytesToKey, which is
documented here:
https://www.openssl.org/docs/man1.1.0/man3/EVP_BytesToKey.html

-Marian

Am 25.03.19 um 01:20 schrieb Tim Webber:
> I just posted a message which i have copied below to a python forum.? It
> might be better asked here.? The coles notes version of my question is this:
> 
> I have received an encrypted data file (mydata.encrypted) and a key
> (plain text for now) and the following command to decrypt it:
> 
> openssl enc -d -aes-256-cbc -a -in mydata.encrypted -out
> mydata.decrypted -kfile my_symmetric_key
> 
> Question is this.? How is the initialization vector calculated?? This
> command works fine.? My issues is that i dont know how the
> initialization vetor is calculated.? I suspect if its left out there is
> some default way of doing it.? Can you tell me how its done? Thanks!
> 
> ************************* ORIGINAL QUESTION to python community
> ******************
> 
> I have received an encrypted data file (mydata.encrypted) and a key
> (plain text for now) and the following command to decrypt it:
> 
> openssl enc -d -aes-256-cbc -a -in mydata.encrypted -out
> mydata.decrypted -kfile my_symmetric_key
> 
> The people who encrypted these data did so with openssl but I dont know
> what the encrypt command looks like. I do know that the above command
> does decrypt the data successfully though.
> 
> I want to use Python to decrypt this file. I am thinking of using
> cryptodome but am open to suggestions. Here's what i know from the above
> openssl decrypt command.
> 
> - its uses AES cbc 256 mode for the decryption ( -d )
> - it uses base64 to encode the data "AFTER" (-a) the cryptographic operation
> - it does not specify the initialization vector (IV).?
> 
> I am struggling with how to code for this using python. What I suspect
> is my problem is that i dont know how to properly calculate the IV.
> Looking at the openssl documentation they say to see "key derivation" to
> find out how they handle IV when its not specified. I cant track down
> this key derivation information. Any help will be appreciated!?
> *******************************?


From Jochen.Bern at binect.de  Mon Mar 25 12:25:21 2019
From: Jochen.Bern at binect.de (Jochen Bern)
Date: Mon, 25 Mar 2019 12:25:21 +0000
Subject: Internal IP Exposed
In-Reply-To: <mailman.14250.1553515692.21411.openssl-users@openssl.org>
References: <mailman.14250.1553515692.21411.openssl-users@openssl.org>
Message-ID: <723c1fa0-b45b-04b4-db81-65ae814ed62e@binect.de>

On 03/25/2019 01:08 PM, openssl-users-request at openssl.org digested:
> Date: Mon, 25 Mar 2019 11:33:55 +1100
> From: Abdul Qoyyuum <aqoyyuum at cardaccess.com.au>
> 
> GET /images HTTP/1.0

Note that this is a HTTP 1.*0* request that doesn't require the client
to send a Host: header stating what *his* idea of "which server am I
trying to talk to?" is.

> HTTP/1.0 301 Moved Permanently
> Location: https://10.240.123.1:10443/images/

/images is a directory, which means that the client is supposed to ask
for "/images/" (with a trailing slash) to request a directory listing.

The server is helpfully sending back a HTTP Redirect to tell the client
what he *should* request instead, in the form of a complete URL, which
necessitates a host and port part. Having no idea who and what the
*client* expects to talk to, the server fills in what *it* knows - its
local (internal) IP and port. This "attack" already worked that way
almost 20 years ago, when I demonstrated it to some (horrified) bank IT
people on their Netscape-based online banking solution middleware ...

OpenSSL is not involved here, and whether (and what) you can do to close
the gap depends on what HTTP server (and, if present, reverse proxy
solution) you're using.

Regards,
-- 
Jochen Bern
Systemingenieur

www.binect.de
www.facebook.de/binect

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

From public at enkore.de  Mon Mar 25 16:24:43 2019
From: public at enkore.de (Marian Beermann)
Date: Mon, 25 Mar 2019 17:24:43 +0100
Subject: aes-cbc-256 mode descryption without an IV
In-Reply-To: <CAOrpx1QSgP+7FHssMN_m0chP-6Ynz0U3MP+QV_t86r=Pw0ghxw@mail.gmail.com>
References: <CAOrpx1TyqWBZErj=6L3cSQ_CMfJoiHrk2byALHi2FF8WaoPuCQ@mail.gmail.com>
 <fa422cab-60a4-3b24-f0f4-0074680b80cb@enkore.de>
 <CAOrpx1QSgP+7FHssMN_m0chP-6Ynz0U3MP+QV_t86r=Pw0ghxw@mail.gmail.com>
Message-ID: <f4ea0107-2290-d8f9-d040-fc8425a619e8@enkore.de>

As it just so happens here is a gist implementing EVP_BytesToKey in Python:
https://gist.github.com/tly1980/b6c2cc10bb35cb4446fb6ccf5ee5efbc

-Marian

Am 25.03.19 um 17:14 schrieb Tim Webber:
> Thanks Marian.? i did read the man pages for enc .? not sure how that
> gets you to the? EVP_BytesToKey algorithm but thank you for providing
> that page.? i suspect it might be easier to have the folks encrypting
> the data specifiy an IV rather than trying to figure out how to
> implement? EVP_BytesToKey in python.? its not inconsequential.
> 
> On Mon, Mar 25, 2019 at 5:08 AM Marian Beermann <public at enkore.de
> <mailto:public at enkore.de>> wrote:
> 
>     Well let's just read the man pages, shall we?
> 
>     >? ? ? ? -kfile filename
>     > Read the password to derive the key from the first line of filename.
> 
>     Then
> 
>     >? ? ? ? -md digest
>     > Use the specified digest to create the key from the passphrase.
>     > The default algorithm is sha-256.
> 
>     And
> 
>     >? ? ? ?-iv IV
>     > ...
>     > When a password is being specified using one of the other options, the
>     IV is generated from this password.
> 
>     The man page doesn't specify the key derivation algorithm, but a quick
>     glance at apps/enc.c shows that it uses EVP_BytesToKey, which is
>     documented here:
>     https://www.openssl.org/docs/man1.1.0/man3/EVP_BytesToKey.html
> 
>     -Marian
> 
>     Am 25.03.19 um 01:20 schrieb Tim Webber:
>     > I just posted a message which i have copied below to a python
>     forum.? It
>     > might be better asked here.? The coles notes version of my
>     question is this:
>     >
>     > I have received an encrypted data file (mydata.encrypted) and a key
>     > (plain text for now) and the following command to decrypt it:
>     >
>     > openssl enc -d -aes-256-cbc -a -in mydata.encrypted -out
>     > mydata.decrypted -kfile my_symmetric_key
>     >
>     > Question is this.? How is the initialization vector calculated?? This
>     > command works fine.? My issues is that i dont know how the
>     > initialization vetor is calculated.? I suspect if its left out
>     there is
>     > some default way of doing it.? Can you tell me how its done? Thanks!
>     >
>     > ************************* ORIGINAL QUESTION to python community
>     > ******************
>     >
>     > I have received an encrypted data file (mydata.encrypted) and a key
>     > (plain text for now) and the following command to decrypt it:
>     >
>     > openssl enc -d -aes-256-cbc -a -in mydata.encrypted -out
>     > mydata.decrypted -kfile my_symmetric_key
>     >
>     > The people who encrypted these data did so with openssl but I dont
>     know
>     > what the encrypt command looks like. I do know that the above command
>     > does decrypt the data successfully though.
>     >
>     > I want to use Python to decrypt this file. I am thinking of using
>     > cryptodome but am open to suggestions. Here's what i know from the
>     above
>     > openssl decrypt command.
>     >
>     > - its uses AES cbc 256 mode for the decryption ( -d )
>     > - it uses base64 to encode the data "AFTER" (-a) the cryptographic
>     operation
>     > - it does not specify the initialization vector (IV).?
>     >
>     > I am struggling with how to code for this using python. What I suspect
>     > is my problem is that i dont know how to properly calculate the IV.
>     > Looking at the openssl documentation they say to see "key
>     derivation" to
>     > find out how they handle IV when its not specified. I cant track down
>     > this key derivation information. Any help will be appreciated!?
>     > *******************************?
> 


From openssl-users at dukhovni.org  Mon Mar 25 18:37:55 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 25 Mar 2019 14:37:55 -0400
Subject: ECC keypair generation with password
In-Reply-To: <OF3CED9B88.98FBB195-ON002583C8.00622654-852583C8.006252CE@notes.na.collabserv.com>
References: <q59eu8$m5i$1@blaine.gmane.org>
 <20190228203625.GD916@straasha.imrryr.org>
 <OF3CED9B88.98FBB195-ON002583C8.00622654-852583C8.006252CE@notes.na.collabserv.com>
Message-ID: <9B875512-884E-4DD6-9B4A-B0E62A3ED10F@dukhovni.org>

> On Mar 25, 2019, at 1:53 PM, Kenneth Goldman <kgoldman at us.ibm.com> wrote:
> 
> 
>     $ openssl ec -aes128 <<EOF
> 
> This was the piece I was missing.  Thanks.
> 
> In the script, I used this:
> 
>     openssl ec -aes128 -passout pass:rrrr -in tmpecprivkeydec.pem -out tmpecprivkey.pem

I try to avoid putting sensitive information in command-line arguments.

If you're using "bash" (which has "printf" as a built-in) you could use:

	-passout file:<(printf "rrrr\n")

which does not create any processes with the password in the argument vector.
Example:

$ openssl enc -aes128 -pass file:<(printf "rrrr\n") <<EOF | openssl enc -d -aes128 -pass file:<(printf "rrrr\n")
> foobar
> EOF
foobar

-- 
	Viktor.


From kgoldman at us.ibm.com  Mon Mar 25 18:58:40 2019
From: kgoldman at us.ibm.com (Kenneth Goldman)
Date: Mon, 25 Mar 2019 13:58:40 -0500
Subject: ECC keypair generation with password
In-Reply-To: <9B875512-884E-4DD6-9B4A-B0E62A3ED10F@dukhovni.org>
References: <q59eu8$m5i$1@blaine.gmane.org>
 <20190228203625.GD916@straasha.imrryr.org>
 <OF3CED9B88.98FBB195-ON002583C8.00622654-852583C8.006252CE@notes.na.collabserv.com>
 <9B875512-884E-4DD6-9B4A-B0E62A3ED10F@dukhovni.org>
Message-ID: <OF597E86FE.84FCCE29-ON002583C8.00681748-852583C8.00683F9F@notes.na.collabserv.com>

> From: Viktor Dukhovni <openssl-users at dukhovni.org>
> >
> > In the script, I used this:
> >
> >     openssl ec -aes128 -passout pass:rrrr -in tmpecprivkeydec.pem
> -out tmpecprivkey.pem
>
> I try to avoid putting sensitive information in command-line arguments.
>
> If you're using "bash" (which has "printf" as a built-in) you could use:
>
>    -passout file:<(printf "rrrr\n")
>
> which does not create any processes with the password in the argument
vector.
> Example:
>
> $ openssl enc -aes128 -pass file:<(printf "rrrr\n") <<EOF | openssl
> enc -d -aes128 -pass file:<(printf "rrrr\n")
> > foobar
> > EOF
> foobar

Understood, but this is just for a regression test script.

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

From kgoldman at us.ibm.com  Mon Mar 25 21:22:48 2019
From: kgoldman at us.ibm.com (Kenneth Goldman)
Date: Mon, 25 Mar 2019 16:22:48 -0500
Subject: Using (not building) openssl with mingw on Windows 10
In-Reply-To: <BYAPR18MB2918BA236A221FB804502FF5F9430@BYAPR18MB2918.namprd18.prod.outlook.com>
References: <pqvvjb$phc$1@blaine.gmane.org>
 <09f436c6-a225-3d6a-540d-361026bc95b2@wisemo.com>
 <q6tjn9$3m80$1@blaine.gmane.org>
 <BYAPR18MB29184811032E36BF024D6EFFF9410@BYAPR18MB2918.namprd18.prod.outlook.com>
 <c606e9da-6b5c-63df-e4cb-7cc0ae73ef68@us.ibm.com>
 <BYAPR18MB2918BA236A221FB804502FF5F9430@BYAPR18MB2918.namprd18.prod.outlook.com>
Message-ID: <OF972F9330.25772EAA-ON002583C8.0073E64A-852583C8.007571A6@notes.na.collabserv.com>


> From: Michael Wojcik <Michael.Wojcik at microfocus.com>

> Without picking at the problem files myself, not really. It's
> probably something that will be fairly obvious in retrospect but I'm
> not seeing it from here.
>
> The import libraries (I'm assuming libssl.lib is one as well, on
> your system) basically tell the linker "for this symbol, insert a
> runtime load reference to this DLL". The Cygwin nm can display the
> symbols in an import library; I don't remember if MingW includes nm,
> or know if it understands import libraries.
>
> So well-formed import versions of libcrypto.lib and libssl.lib
> should name all the public OpenSSL symbols, and you shouldn't get
> resolution errors when linking against them. You might well get
> resolution errors at runtime, if the corresponding DLLs can't be
> found; but not a link time.

Here's a new attempt.  I added -lcrypto.  I also added -L and the path to
libcrypto.lib.

The error makes sense because -lcrypto should search for libcrypto.a, and
there is none in the Shining Light build.

I also tried pointing directly to "c:/program
files/openssl64/lib/libcrypto.lib", but the link failed.

~~

"c:/program files/mingw/bin/gcc.exe" -D_MT -DTPM_WINDOWS -I.  -shared -o
libibmtss.dll tssfile.o tsscryptoh.o tsscrypto.o tssprintcmd.o tss.o
tssproperties.o tssmarshal.o tssauth.o tssutils.o tsssocket.o tssdev.o
tsstransmit.o tssresponsecode.o tssccattributes.o tssprint.o Unmarshal.o
CommandAttributeData.o tss20.o tssauth20.o Commands.o ntc2lib.o tssntc.o \
		-Wl,--out-implib,libibmtss.a -L"c:/program files/openssl64/lib"
-lcrypto "c:/program files/MinGW/lib/libws2_32.a"

c:/program
files/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe:
cannot find -lcrypto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190325/b6a1337e/attachment.html>

From bastien.bonnot at gmail.com  Mon Mar 25 21:53:56 2019
From: bastien.bonnot at gmail.com (sebastien)
Date: Mon, 25 Mar 2019 22:53:56 +0100
Subject: install error with linux mint 19.1
Message-ID: <8ff38ade-2b50-e8e5-6683-881ead48e7af@gmail.com>

hi

in a terminal I've got this error with

|openssl version openssl: /usr/lib/x86_64-linux-gnu/libssl.so.1.1: 
version `OPENSSL_1_1_1' not found (required by openssl) openssl: 
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1: version `OPENSSL_1_1_1' not 
found (required by openssl) can you please help me ? |

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

From jb-openssl at wisemo.com  Mon Mar 25 22:11:38 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 25 Mar 2019 23:11:38 +0100
Subject: install error with linux mint 19.1
In-Reply-To: <8ff38ade-2b50-e8e5-6683-881ead48e7af@gmail.com>
References: <8ff38ade-2b50-e8e5-6683-881ead48e7af@gmail.com>
Message-ID: <0e7aa536-a031-7df6-cdb2-cd1ce8316054@wisemo.com>

On 25/03/2019 22:53, sebastien wrote:
>
> hi
>
> in a terminal I've got this error with
>
> |openssl version openssl: /usr/lib/x86_64-linux-gnu/libssl.so.1.1: 
> version `OPENSSL_1_1_1' not found (required by openssl) openssl: 
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1: version `OPENSSL_1_1_1' 
> not found (required by openssl) can you please help me ? |
I guess the files |/usr/lib/x86_64-linux-gnu/libssl.so.1.1 and
||/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1|||are the system installed
OpenSSL 1.1.0 libraries and your freshly compiled openssl 1.1.1
program is is trying to load them instead of it's own version 1.1.1
libraries.

If so, try testing withthe command

LD_LIBRARY_PATH=/home/your/openssl-1.1.1-build-dir/somewhere openssl version

to force use of your not-yet-installed OpenSSL 1.1.1 libraries.

Enjoy

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


From tniessen at tnie.de  Mon Mar 25 23:25:21 2019
From: tniessen at tnie.de (=?UTF-8?Q?Tobias_Nie=c3=9fen?=)
Date: Tue, 26 Mar 2019 00:25:21 +0100
Subject: Using RSA-PSS in OpenSSL 1.1.1b
Message-ID: <f953a226-9e24-cb19-ea5a-40bd6b96b043@tnie.de>

Hello,

I am using OpenSSL 1.1.1b and I have two questions regarding RSA-PSS. I 
am using the following command to generate the private key:

 ??? openssl genpkey -algorithm RSA-PSS -pkeyopt rsa_keygen_bits:2048 
-pkeyopt rsa_keygen_pubexp:65537 -pkeyopt rsa_pss_keygen_md:sha256 
-pkeyopt rsa_pss_keygen_mgf1_md:sha256 -pkeyopt 
rsa_pss_keygen_saltlen:16 -out rsa_pss_private_2048_restricted.pem

This works, but I am unsure how to produce the corresponding public key 
using the openssl CLI, it would be great if someone could give me some 
pointers.

I also need to access the key restrictions (MD / MGF1 MD / salt length) 
given only a pointer to the EVP_PKEY structure. I understand that the 
information is stored in the RSA_PSS_PARAMS structure. How do I access 
the restrictions using the public API?

Thanks in advance!
Tobias


From openssl-users at dukhovni.org  Tue Mar 26 00:29:10 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 25 Mar 2019 20:29:10 -0400
Subject: Using RSA-PSS in OpenSSL 1.1.1b
In-Reply-To: <f953a226-9e24-cb19-ea5a-40bd6b96b043@tnie.de>
References: <f953a226-9e24-cb19-ea5a-40bd6b96b043@tnie.de>
Message-ID: <20190326002909.GO3822@straasha.imrryr.org>

On Tue, Mar 26, 2019 at 12:25:21AM +0100, Tobias Nie?en wrote:

> I am using OpenSSL 1.1.1b and I have two questions regarding RSA-PSS. I 
> am using the following command to generate the private key:
> 
>  $ openssl genpkey -algorithm RSA-PSS -pkeyopt rsa_keygen_bits:2048 \
>    -pkeyopt rsa_keygen_pubexp:65537 -pkeyopt rsa_pss_keygen_md:sha256 \
>    -pkeyopt rsa_pss_keygen_mgf1_md:sha256 -pkeyopt \
>    rsa_pss_keygen_saltlen:16 -out rsa_pss_private_2048_restricted.pem
> 
> This works, but I am unsure how to produce the corresponding public key 
> using the openssl CLI, it would be great if someone could give me some 
> pointers.

    $ openssl genpkey -algorithm RSA-PSS -pkeyopt rsa_keygen_bits:2048 \
        -pkeyopt rsa_keygen_pubexp:65537 -pkeyopt rsa_pss_keygen_md:sha256 \
        -pkeyopt rsa_pss_keygen_mgf1_md:sha256 -pkeyopt rsa_pss_keygen_saltlen:16 \
        -out rsa_pss_private_2048_restricted.pem
    ....................................................................+++++
    ...........................+++++
    $ openssl pkey -in rsa_pss_private_2048_restricted.pem -pubout |
      openssl pkey -pubin -text
    -----BEGIN PUBLIC KEY-----
    MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAaEaMBgGCSqGSIb3DQEB
    CDALBglghkgBZQMEAgGiAwIBEAOCAQ8AMIIBCgKCAQEAtfBYSSrOvPmuwVzRJeOP
    h5o9iZEM2L9CTY3mJRW5cJOdoOwjEp6ITge3QxPbgoFlKwg88U1ejIj7/uNwZKIV
    yO5WRYRBFxS+rdBv6gQNyBn6z4LcxQ1chE6PgpmO0ZsDj56aRumf7mmg5ewFHOAG
    txeSRyT4NO6XMFb57OGGqGwhYm/nUrbrtmErCc8Y/HKP0TVHCnrvoGf2hgAkmvYG
    FxqbXs12nQrgcecPZVtszcdD/RelTaE62TnNrsHOCEdqLoOXTJ/64LQXKFrbAd7H
    YiBKXYA+PkJf5a053LJ9gIJlkYKpCbXqkI9cLRS/uX5WDg5/rJilR8Ng77tQSJvq
    LwIDAQAB
    -----END PUBLIC KEY-----
    RSA-PSS Public-Key: (2048 bit)
    Modulus:
	00:b5:f0:58:49:2a:ce:bc:f9:ae:c1:5c:d1:25:e3:
	8f:87:9a:3d:89:91:0c:d8:bf:42:4d:8d:e6:25:15:
	b9:70:93:9d:a0:ec:23:12:9e:88:4e:07:b7:43:13:
	db:82:81:65:2b:08:3c:f1:4d:5e:8c:88:fb:fe:e3:
	70:64:a2:15:c8:ee:56:45:84:41:17:14:be:ad:d0:
	6f:ea:04:0d:c8:19:fa:cf:82:dc:c5:0d:5c:84:4e:
	8f:82:99:8e:d1:9b:03:8f:9e:9a:46:e9:9f:ee:69:
	a0:e5:ec:05:1c:e0:06:b7:17:92:47:24:f8:34:ee:
	97:30:56:f9:ec:e1:86:a8:6c:21:62:6f:e7:52:b6:
	eb:b6:61:2b:09:cf:18:fc:72:8f:d1:35:47:0a:7a:
	ef:a0:67:f6:86:00:24:9a:f6:06:17:1a:9b:5e:cd:
	76:9d:0a:e0:71:e7:0f:65:5b:6c:cd:c7:43:fd:17:
	a5:4d:a1:3a:d9:39:cd:ae:c1:ce:08:47:6a:2e:83:
	97:4c:9f:fa:e0:b4:17:28:5a:db:01:de:c7:62:20:
	4a:5d:80:3e:3e:42:5f:e5:ad:39:dc:b2:7d:80:82:
	65:91:82:a9:09:b5:ea:90:8f:5c:2d:14:bf:b9:7e:
	56:0e:0e:7f:ac:98:a5:47:c3:60:ef:bb:50:48:9b:
	ea:2f
    Exponent: 65537 (0x10001)
    PSS parameter restrictions:
      Hash Algorithm: sha256
      Mask Algorithm: mgf1 with sha256
      Minimum Salt Length: 0x10
      Trailer Field: 0xBC (default)

> I also need to access the key restrictions (MD / MGF1 MD / salt length) 
> given only a pointer to the EVP_PKEY structure. I understand that the 
> information is stored in the RSA_PSS_PARAMS structure. How do I access 
> the restrictions using the public API?

EVP_PKEY_get0_RSA() gets you the underlying algorithm-specific RSA
key.  But there don't appear to be any accessors that use the
internal rsa_pss_get_param() function to return these parameters
(I could not find any).  Perhaps open an issue on github, or if
you are up for it, a pull request (with documentationa and code).

-- 
	Viktor.

From 72911e at gmail.com  Tue Mar 26 01:58:11 2019
From: 72911e at gmail.com (Tim Webber)
Date: Mon, 25 Mar 2019 18:58:11 -0700
Subject: aes-cbc-256 mode descryption without an IV
In-Reply-To: <f4ea0107-2290-d8f9-d040-fc8425a619e8@enkore.de>
References: <CAOrpx1TyqWBZErj=6L3cSQ_CMfJoiHrk2byALHi2FF8WaoPuCQ@mail.gmail.com>
 <fa422cab-60a4-3b24-f0f4-0074680b80cb@enkore.de>
 <CAOrpx1QSgP+7FHssMN_m0chP-6Ynz0U3MP+QV_t86r=Pw0ghxw@mail.gmail.com>
 <f4ea0107-2290-d8f9-d040-fc8425a619e8@enkore.de>
Message-ID: <CAOrpx1TTkGnifOt=N5daCTs+aLbT2m9wMQLvkkTP=jaGzg1cQw@mail.gmail.com>

Good fine Marian.  Thx for all your help.

On Mon, Mar 25, 2019 at 9:24 AM Marian Beermann <public at enkore.de> wrote:

> As it just so happens here is a gist implementing EVP_BytesToKey in Python:
> https://gist.github.com/tly1980/b6c2cc10bb35cb4446fb6ccf5ee5efbc
>
> -Marian
>
> Am 25.03.19 um 17:14 schrieb Tim Webber:
> > Thanks Marian.  i did read the man pages for enc .  not sure how that
> > gets you to the  EVP_BytesToKey algorithm but thank you for providing
> > that page.  i suspect it might be easier to have the folks encrypting
> > the data specifiy an IV rather than trying to figure out how to
> > implement  EVP_BytesToKey in python.  its not inconsequential.
> >
> > On Mon, Mar 25, 2019 at 5:08 AM Marian Beermann <public at enkore.de
> > <mailto:public at enkore.de>> wrote:
> >
> >     Well let's just read the man pages, shall we?
> >
> >     >        -kfile filename
> >     > Read the password to derive the key from the first line of
> filename.
> >
> >     Then
> >
> >     >        -md digest
> >     > Use the specified digest to create the key from the passphrase.
> >     > The default algorithm is sha-256.
> >
> >     And
> >
> >     >       -iv IV
> >     > ...
> >     > When a password is being specified using one of the other options,
> the
> >     IV is generated from this password.
> >
> >     The man page doesn't specify the key derivation algorithm, but a
> quick
> >     glance at apps/enc.c shows that it uses EVP_BytesToKey, which is
> >     documented here:
> >     https://www.openssl.org/docs/man1.1.0/man3/EVP_BytesToKey.html
> >
> >     -Marian
> >
> >     Am 25.03.19 um 01:20 schrieb Tim Webber:
> >     > I just posted a message which i have copied below to a python
> >     forum.  It
> >     > might be better asked here.  The coles notes version of my
> >     question is this:
> >     >
> >     > I have received an encrypted data file (mydata.encrypted) and a key
> >     > (plain text for now) and the following command to decrypt it:
> >     >
> >     > openssl enc -d -aes-256-cbc -a -in mydata.encrypted -out
> >     > mydata.decrypted -kfile my_symmetric_key
> >     >
> >     > Question is this.  How is the initialization vector calculated?
> This
> >     > command works fine.  My issues is that i dont know how the
> >     > initialization vetor is calculated.  I suspect if its left out
> >     there is
> >     > some default way of doing it.  Can you tell me how its done?
> Thanks!
> >     >
> >     > ************************* ORIGINAL QUESTION to python community
> >     > ******************
> >     >
> >     > I have received an encrypted data file (mydata.encrypted) and a key
> >     > (plain text for now) and the following command to decrypt it:
> >     >
> >     > openssl enc -d -aes-256-cbc -a -in mydata.encrypted -out
> >     > mydata.decrypted -kfile my_symmetric_key
> >     >
> >     > The people who encrypted these data did so with openssl but I dont
> >     know
> >     > what the encrypt command looks like. I do know that the above
> command
> >     > does decrypt the data successfully though.
> >     >
> >     > I want to use Python to decrypt this file. I am thinking of using
> >     > cryptodome but am open to suggestions. Here's what i know from the
> >     above
> >     > openssl decrypt command.
> >     >
> >     > - its uses AES cbc 256 mode for the decryption ( -d )
> >     > - it uses base64 to encode the data "AFTER" (-a) the cryptographic
> >     operation
> >     > - it does not specify the initialization vector (IV).
> >     >
> >     > I am struggling with how to code for this using python. What I
> suspect
> >     > is my problem is that i dont know how to properly calculate the IV.
> >     > Looking at the openssl documentation they say to see "key
> >     derivation" to
> >     > find out how they handle IV when its not specified. I cant track
> down
> >     > this key derivation information. Any help will be appreciated!
> >     > *******************************
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190325/864bdbff/attachment-0001.html>

From aerowolf at gmail.com  Tue Mar 26 03:09:31 2019
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Mon, 25 Mar 2019 22:09:31 -0500
Subject: Internal IP Exposed
In-Reply-To: <CAA3DN=X-cNFT0LXN+djWzoLaHThQJBybGFqsdvOKNoAFrqfxew@mail.gmail.com>
References: <CAA3DN=X-cNFT0LXN+djWzoLaHThQJBybGFqsdvOKNoAFrqfxew@mail.gmail.com>
Message-ID: <CAPMEXDY1UVrXFrfFJbFq=34Rhm-wdVz2YOnR2Ds+3L9Uzz9prw@mail.gmail.com>

That's a configuration issue with the servers, not an issue with the
openssl command itself.

There's no information on what the back-end HTTP server software is
being used.  If it were Apache, there would be a ServerName directive
that could change the server's idea of what name it should refer to
itself as.  I don't have information on other server software
configuration.

-Kyle H

On Sun, Mar 24, 2019 at 7:34 PM Abdul Qoyyuum
<aqoyyuum at cardaccess.com.au> wrote:
>
> Hi all,
>
> New to the mailing list and a complete newbie to openssl and the likes. There's a ticket by a client that I'm new at and he claims that there's a security problem with the openssl command to his servers.
>
> Internal IP exposed after running a openssl (version 1.1.0j) connect command:
>
> openssl s_client -connect 103.XX.XXX.XX:10443 -quiet
>
> Where 103.XX.XXX.XX is a Public IP. And after it shows the certificates, typed the following:
>
> GET /images HTTP/1.0
>
> And hit enter twice, the following gets displayed:
>
> HTTP/1.0 301 Moved Permanently
> Date: Mon, 25 Mar 2019 00:10:13 GMT
> Server: xxxxxxxx-xxxxx
> Location: https://10.240.123.1:10443/images/
> Connection: close
> Content-Type: text/html; charset=utf-8
> X-Frame-Options: SAMEORIGIN
> Content-Security-Policy: frame-ancestors 'self'
> X-XSS-Protection: 1; mode=block
> X-Content-Type-Options: nosniff
> Strict-Transport-Security: max-age=28800
>
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <HTML><HEAD>
> <TITLE>301 Moved Permanently</TITLE>
> </HEAD><BODY>
> <H1>Moved Permanently</H1>
> The document has moved <A HREF="https://10.240.123.1:10443/images/">here</A>.<P>
> </BODY></HTML>
> read:errno=0
>
> The 10.240.123.1 is an internal IP and it is exposed by this little method. Although not shown when using curl -kv -O command.
>
> Is there a way to cover up the "Location" or at least the internal IP from being exposed? Thanks.
>
> Sorry if this isn't clear or if this is the wrong place to ask this.
>
> --
> Abdul Qoyyuum Bin Haji Abdul Kadir
> HP No: +673 720 8043

From rama.krushna7 at gmail.com  Tue Mar 26 04:38:12 2019
From: rama.krushna7 at gmail.com (ramakrushna mishra)
Date: Tue, 26 Mar 2019 10:08:12 +0530
Subject: Reg solaris support for openssl 1.1.1b
In-Reply-To: <CAHgr=kL=NS9=YeJ99DtxXgA=+BZbPauu-T1D_XYLddPJamssuQ@mail.gmail.com>
References: <mailman.13797.1552697382.21411.openssl-users@openssl.org>
 <CAHgr=kL=NS9=YeJ99DtxXgA=+BZbPauu-T1D_XYLddPJamssuQ@mail.gmail.com>
Message-ID: <CAHgr=k+NbGaW735roC+aQBFW4B7VxCYi7o6VsqDqn6_7Xy4yRQ@mail.gmail.com>

>
> Hi All,
>

Thanks for your responses.
I am able to build openssl 1.1.1 on my solaris and able to run "openssl
version".
I followed the same procedure for openssl 1.1.1b and when I run "openssl
version"  seeing the mentioned error. i.e
"ld.so.1: openssl: fatal: relocation error: file openssl: symbol
OPENSSL_sk_new_null: referenced symbol not found
Killed
".

So, How come it works with openssl 1.1.1 and not with 1.1.1b.
I am using the same machine and same procedure to configure and install it.
So, Is there anything different that need to be done for 1.1.1b version ?

Thanks and Regards,
Ram Krushna


>
> On Sat, Mar 16, 2019 at 6:20 AM <openssl-users-request at openssl.org> wrote:
>
>> Send openssl-users mailing list submissions to
>>         openssl-users at openssl.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://mta.openssl.org/mailman/listinfo/openssl-users
>> or, via email, send a message with subject or body 'help' to
>>         openssl-users-request at openssl.org
>>
>> You can reach the person managing the list at
>>         openssl-users-owner at openssl.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of openssl-users digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: Reg solaris support for openssl 1.1.1b (Jakob Bohm)
>>    5. Re: Reg solaris support for openssl 1.1.1b (Dennis Clarke)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 15 Mar 2019 18:19:53 +0100
>> From: Jakob Bohm <jb-openssl at wisemo.com>
>> To: openssl-users at openssl.org
>> Subject: Re: Reg solaris support for openssl 1.1.1b
>> Message-ID: <649ef06e-0f64-65bb-cb43-cfde681fd117 at wisemo.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> On 15/03/2019 14:33, Dennis Clarke wrote:
>> > On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
>> >> My guess is that your binary is loading the system's shared libraries.
>> >> To find out whether this is the case, try
>> >>
>> >>  ??? ldd bin/openssl
>> >>
>> >> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
>> >> explicitely.
>> > Actually LD_LIBRARY_PATH is evil.
>> >
>> > The correct way to do this is to compile with a RUNPATH set in the
>> > output ELF files.
>> LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
>> testing
>> a newly compiled binary before installing the libraries to their final
>> locations, perhaps
>> on the same, perhaps on another machine.
>>
>> P.S.
>> I don't known if the Solaris loader lets LD_LIBRARY_PATH override
>> RUNPATH as
>> presumed by the above answer.
>>
>> Enjoy
>>
>> Jakob
>> --
>> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
>> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
>> This public discussion message is non-binding and may contain errors.
>> WiseMo - Remote Service Management for PCs, Phones and Embedded
>>
>>
>>
>> ------------------------------
>> Message: 5
>> Date: Fri, 15 Mar 2019 20:49:30 -0400
>> From: Dennis Clarke <dclarke at blastwave.org>
>> To: openssl-users at openssl.org
>> Subject: Re: Reg solaris support for openssl 1.1.1b
>> Message-ID: <4b08232c-f734-987c-814c-5acef59f42ab at blastwave.org>
>> Content-Type: text/plain; charset=utf-8
>>
>> On 3/15/19 1:19 PM, Jakob Bohm via openssl-users wrote:
>> > On 15/03/2019 14:33, Dennis Clarke wrote:
>> >> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
>> >>> My guess is that your binary is loading the system's shared libraries.
>> >>> To find out whether this is the case, try
>> >>>
>> >>> ???? ldd bin/openssl
>> >>>
>> >>> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
>> >>> explicitely.
>> >> Actually LD_LIBRARY_PATH is evil.
>> >>
>> >> The correct way to do this is to compile with a RUNPATH set in the
>> >> output ELF files.
>> > LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
>> > testing
>> > a newly compiled binary before installing the libraries to their final
>> > locations, perhaps
>> > on the same, perhaps on another machine.
>> >
>> > P.S.
>> > I don't known if the Solaris loader lets LD_LIBRARY_PATH override
>> > RUNPATH as
>> > presumed by the above answer.
>>
>> Yes it certainly does. Otherwise testing a new custom lib would be a
>> royal pain as opposed to just a pain.  Also most people still, after
>> twenty years, know what LD_LIBRARY_PATH env var is for and it is a waste
>> of breath trying to explain it after decades of watching folks skewer
>> themselves over and over and over ....
>>
>> dc
>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> openssl-users mailing list
>> openssl-users at openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>> ------------------------------
>>
>> End of openssl-users Digest, Vol 52, Issue 19
>> *********************************************
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190326/09253e6e/attachment.html>

From dclarke at blastwave.org  Tue Mar 26 06:55:38 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Tue, 26 Mar 2019 02:55:38 -0400
Subject: Reg solaris support for openssl 1.1.1b
In-Reply-To: <CAHgr=k+NbGaW735roC+aQBFW4B7VxCYi7o6VsqDqn6_7Xy4yRQ@mail.gmail.com>
References: <mailman.13797.1552697382.21411.openssl-users@openssl.org>
 <CAHgr=kL=NS9=YeJ99DtxXgA=+BZbPauu-T1D_XYLddPJamssuQ@mail.gmail.com>
 <CAHgr=k+NbGaW735roC+aQBFW4B7VxCYi7o6VsqDqn6_7Xy4yRQ@mail.gmail.com>
Message-ID: <4c02f69c-512b-d5c8-67a2-eebe6e3f3197@blastwave.org>

On 3/26/19 12:38 AM, ramakrushna mishra wrote:
>     Hi All,
> 
> 
> Thanks for your responses.?
> I am able to build openssl 1.1.1 on my solaris and able to run "openssl
> version".
> I followed the same procedure for openssl 1.1.1b and when I run "openssl
> version"? seeing the mentioned error. i.e?
> "ld.so.1: openssl: fatal: relocation error: file openssl: symbol
> OPENSSL_sk_new_null: referenced symbol not found

Did you modify Configurations/10-main.conf ?



-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

From sojulibra at gmail.com  Wed Mar 27 10:33:44 2019
From: sojulibra at gmail.com (=?UTF-8?B?55Sw5Lit5Ym15qi5IChTb3VqdSBUQU5BS0Ep?=)
Date: Wed, 27 Mar 2019 19:33:44 +0900
Subject: Building OpenSSL 1.1.1b for WinCE700
In-Reply-To: <b1073375-e52e-c9e6-2bc8-8b5bc4e05350@openssl.org>
References: <CAPvkBARR=o2gm4ZztcN3oY6MY1tVgaXeVsQbikhgQQXDbAcyVQ@mail.gmail.com>
 <b1073375-e52e-c9e6-2bc8-8b5bc4e05350@openssl.org>
Message-ID: <CAPvkBATRzBmqYAmHfiJs9wbgCt_s7zk_jViTU1sia35-pfL4aQ@mail.gmail.com>

Hello,

It works with our custommized cURL code.
I wrote a detailed build instruction for CE.
  https://qiita.com/souju/items/94117c024862f57459c3

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

Thank you. I post the PR.
  https://github.com/openssl/openssl/pull/8596

Regards,
Souju TANAKA


2019?3?19?(?) 18:39 Matt Caswell <matt at openssl.org>:

>
>
> 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 <winbase.h>" 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190327/9585737c/attachment-0001.html>

From hvn at open.com.au  Wed Mar 27 15:06:40 2019
From: hvn at open.com.au (Heikki Vatiainen)
Date: Wed, 27 Mar 2019 17:06:40 +0200
Subject: Delta CRL and verify app -extended_crl flag
Message-ID: <cc8680ff-fbf9-5832-e1c7-0a7e289b9ac8@open.com.au>

I started experimenting with delta CRLs and noticed that 'openssl 
verify' in OpenSSL distribution test suite uses -extended_crl flag with 
-use_deltas. The documentation is not clear if 'extended CRL features' 
also covers delta CRLs and if it is required for deltas to work.

The corresponding verify flags are also mentioned on  the 
X509_VERIFY_PARAM_set_flags manual page, with some caveats regarding 
delta CRLs, but otherwise there seem to be few examples in the net about 
what options to use.

Can anyone confirm if -extended_crl is required for delta CRLs? If it 
is, I can submit a documentation update to make clarify this.

Here are the docs I've used:

https://www.openssl.org/docs/manmaster/man1/verify.html

https://www.openssl.org/docs/manmaster/man3/X509_VERIFY_PARAM_set_flags.html

Thanks,
Heikki

-- 
Heikki Vatiainen

From rama.krushna7 at gmail.com  Thu Mar 28 05:01:10 2019
From: rama.krushna7 at gmail.com (ramakrushna mishra)
Date: Thu, 28 Mar 2019 10:31:10 +0530
Subject: Reg solaris support for openssl 1.1.1b
In-Reply-To: <mailman.14348.1553682979.21411.openssl-users@openssl.org>
References: <mailman.14348.1553682979.21411.openssl-users@openssl.org>
Message-ID: <CAHgr=k+3hropSNOdgmwH-9o60hShEAMTiB9-g-k1UWBg8PiAOQ@mail.gmail.com>

Hi Dennis

Yes, 10-main.conf is modified for both the versions.
Following are changes.

<<< file 1:
/view/rdl117_linuxx86_64/vobs_tools/src/openssl-1.1.1b/Configurations/10-main.conf@
@/main/1
>>> file 2: 10-main.conf
********************************
-----[16 changed to 16]-----
<                                 ASFLAGS   => "/nologo /Zi",
---
>                                 ASFLAGS   => "/nologo",
-----[44 changed to 44]-----
<                                ASFLAGS   => "/nologo /Zi",
---
>                                ASFLAGS   => "/nologo",
-----[211 changed to 211]-----
<         ex_libs          => add("-lsocket -lnsl -ldl"),
---
>         ex_libs          => add("-lsocket -lnsl -ldl -lm -lrt"),
-----[1226 changed to 1226]-----
<         lib_cflags       => add("/Zi /Fdossl_static.pdb"),
---
>         lib_cflags       => add("/Fdossl_static.pdb"),
-----[1228-1229 changed to 1228-1229]-----
<         dso_cflags       => "/Zi /Fddso.pdb",
<         bin_cflags       => "/Zi /Fdapp.pdb",
---
>         dso_cflags       => "/Fddso.pdb",
>         bin_cflags       => "/Fdapp.pdb",

The error is coming for OPENSSL_sk_new_null which is changed in 1.1.1b
compared to 1.1.1 with https://github.com/openssl/openssl/pull/7721.
Can this be related ?

Thanks and Regards,
Ram Krushna


On Wed, Mar 27, 2019 at 4:07 PM <openssl-users-request at openssl.org> wrote:

> Send openssl-users mailing list submissions to
>         openssl-users at openssl.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
>         openssl-users-request at openssl.org
>
> You can reach the person managing the list at
>         openssl-users-owner at openssl.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
>
>
> Today's Topics:
>
>    1. Re: Internal IP Exposed (Kyle Hamilton)
>    2. Re: Reg solaris support for openssl 1.1.1b (ramakrushna mishra)
>    3. Re: Reg solaris support for openssl 1.1.1b (Dennis Clarke)
>    4. Re: Building OpenSSL 1.1.1b for WinCE700 (???? (Souju TANAKA))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 25 Mar 2019 22:09:31 -0500
> From: Kyle Hamilton <aerowolf at gmail.com>
> To: Abdul Qoyyuum <aqoyyuum at cardaccess.com.au>
> Cc: openssl-users <openssl-users at openssl.org>
> Subject: Re: Internal IP Exposed
> Message-ID:
>         <CAPMEXDY1UVrXFrfFJbFq=
> 34Rhm-wdVz2YOnR2Ds+3L9Uzz9prw at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> That's a configuration issue with the servers, not an issue with the
> openssl command itself.
>
> There's no information on what the back-end HTTP server software is
> being used.  If it were Apache, there would be a ServerName directive
> that could change the server's idea of what name it should refer to
> itself as.  I don't have information on other server software
> configuration.
>
> -Kyle H
>
> On Sun, Mar 24, 2019 at 7:34 PM Abdul Qoyyuum
> <aqoyyuum at cardaccess.com.au> wrote:
> >
> > Hi all,
> >
> > New to the mailing list and a complete newbie to openssl and the likes.
> There's a ticket by a client that I'm new at and he claims that there's a
> security problem with the openssl command to his servers.
> >
> > Internal IP exposed after running a openssl (version 1.1.0j) connect
> command:
> >
> > openssl s_client -connect 103.XX.XXX.XX:10443 -quiet
> >
> > Where 103.XX.XXX.XX is a Public IP. And after it shows the certificates,
> typed the following:
> >
> > GET /images HTTP/1.0
> >
> > And hit enter twice, the following gets displayed:
> >
> > HTTP/1.0 301 Moved Permanently
> > Date: Mon, 25 Mar 2019 00:10:13 GMT
> > Server: xxxxxxxx-xxxxx
> > Location: https://10.240.123.1:10443/images/
> > Connection: close
> > Content-Type: text/html; charset=utf-8
> > X-Frame-Options: SAMEORIGIN
> > Content-Security-Policy: frame-ancestors 'self'
> > X-XSS-Protection: 1; mode=block
> > X-Content-Type-Options: nosniff
> > Strict-Transport-Security: max-age=28800
> >
> > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> > <HTML><HEAD>
> > <TITLE>301 Moved Permanently</TITLE>
> > </HEAD><BODY>
> > <H1>Moved Permanently</H1>
> > The document has moved <A HREF="https://10.240.123.1:10443/images/
> ">here</A>.<P>
> > </BODY></HTML>
> > read:errno=0
> >
> > The 10.240.123.1 is an internal IP and it is exposed by this little
> method. Although not shown when using curl -kv -O command.
> >
> > Is there a way to cover up the "Location" or at least the internal IP
> from being exposed? Thanks.
> >
> > Sorry if this isn't clear or if this is the wrong place to ask this.
> >
> > --
> > Abdul Qoyyuum Bin Haji Abdul Kadir
> > HP No: +673 720 8043
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 26 Mar 2019 10:08:12 +0530
> From: ramakrushna mishra <rama.krushna7 at gmail.com>
> To: openssl-users at openssl.org
> Subject: Re: Reg solaris support for openssl 1.1.1b
> Message-ID:
>         <CAHgr=
> k+NbGaW735roC+aQBFW4B7VxCYi7o6VsqDqn6_7Xy4yRQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> >
> > Hi All,
> >
>
> Thanks for your responses.
> I am able to build openssl 1.1.1 on my solaris and able to run "openssl
> version".
> I followed the same procedure for openssl 1.1.1b and when I run "openssl
> version"  seeing the mentioned error. i.e
> "ld.so.1: openssl: fatal: relocation error: file openssl: symbol
> OPENSSL_sk_new_null: referenced symbol not found
> Killed
> ".
>
> So, How come it works with openssl 1.1.1 and not with 1.1.1b.
> I am using the same machine and same procedure to configure and install it.
> So, Is there anything different that need to be done for 1.1.1b version ?
>
> Thanks and Regards,
> Ram Krushna
>
>
> >
> > On Sat, Mar 16, 2019 at 6:20 AM <openssl-users-request at openssl.org>
> wrote:
> >
> >> Send openssl-users mailing list submissions to
> >>         openssl-users at openssl.org
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >>         https://mta.openssl.org/mailman/listinfo/openssl-users
> >> or, via email, send a message with subject or body 'help' to
> >>         openssl-users-request at openssl.org
> >>
> >> You can reach the person managing the list at
> >>         openssl-users-owner at openssl.org
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of openssl-users digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >>    1. Re: Reg solaris support for openssl 1.1.1b (Jakob Bohm)
> >>    5. Re: Reg solaris support for openssl 1.1.1b (Dennis Clarke)
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: Fri, 15 Mar 2019 18:19:53 +0100
> >> From: Jakob Bohm <jb-openssl at wisemo.com>
> >> To: openssl-users at openssl.org
> >> Subject: Re: Reg solaris support for openssl 1.1.1b
> >> Message-ID: <649ef06e-0f64-65bb-cb43-cfde681fd117 at wisemo.com>
> >> Content-Type: text/plain; charset=utf-8; format=flowed
> >>
> >> On 15/03/2019 14:33, Dennis Clarke wrote:
> >> > On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
> >> >> My guess is that your binary is loading the system's shared
> libraries.
> >> >> To find out whether this is the case, try
> >> >>
> >> >>  ??? ldd bin/openssl
> >> >>
> >> >> If my assumption is correct, you might have to set the
> LD_LIBRARY_PATH
> >> >> explicitely.
> >> > Actually LD_LIBRARY_PATH is evil.
> >> >
> >> > The correct way to do this is to compile with a RUNPATH set in the
> >> > output ELF files.
> >> LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
> >> testing
> >> a newly compiled binary before installing the libraries to their final
> >> locations, perhaps
> >> on the same, perhaps on another machine.
> >>
> >> P.S.
> >> I don't known if the Solaris loader lets LD_LIBRARY_PATH override
> >> RUNPATH as
> >> presumed by the above answer.
> >>
> >> Enjoy
> >>
> >> Jakob
> >> --
> >> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> >> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
> >> This public discussion message is non-binding and may contain errors.
> >> WiseMo - Remote Service Management for PCs, Phones and Embedded
> >>
> >>
> >>
> >> ------------------------------
> >> Message: 5
> >> Date: Fri, 15 Mar 2019 20:49:30 -0400
> >> From: Dennis Clarke <dclarke at blastwave.org>
> >> To: openssl-users at openssl.org
> >> Subject: Re: Reg solaris support for openssl 1.1.1b
> >> Message-ID: <4b08232c-f734-987c-814c-5acef59f42ab at blastwave.org>
> >> Content-Type: text/plain; charset=utf-8
> >>
> >> On 3/15/19 1:19 PM, Jakob Bohm via openssl-users wrote:
> >> > On 15/03/2019 14:33, Dennis Clarke wrote:
> >> >> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
> >> >>> My guess is that your binary is loading the system's shared
> libraries.
> >> >>> To find out whether this is the case, try
> >> >>>
> >> >>> ???? ldd bin/openssl
> >> >>>
> >> >>> If my assumption is correct, you might have to set the
> LD_LIBRARY_PATH
> >> >>> explicitely.
> >> >> Actually LD_LIBRARY_PATH is evil.
> >> >>
> >> >> The correct way to do this is to compile with a RUNPATH set in the
> >> >> output ELF files.
> >> > LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
> >> > testing
> >> > a newly compiled binary before installing the libraries to their final
> >> > locations, perhaps
> >> > on the same, perhaps on another machine.
> >> >
> >> > P.S.
> >> > I don't known if the Solaris loader lets LD_LIBRARY_PATH override
> >> > RUNPATH as
> >> > presumed by the above answer.
> >>
> >> Yes it certainly does. Otherwise testing a new custom lib would be a
> >> royal pain as opposed to just a pain.  Also most people still, after
> >> twenty years, know what LD_LIBRARY_PATH env var is for and it is a waste
> >> of breath trying to explain it after decades of watching folks skewer
> >> themselves over and over and over ....
> >>
> >> dc
> >>
> >>
> >>
> >> ------------------------------
> >>
> >> Subject: Digest Footer
> >>
> >> _______________________________________________
> >> openssl-users mailing list
> >> openssl-users at openssl.org
> >> https://mta.openssl.org/mailman/listinfo/openssl-users
> >>
> >>
> >> ------------------------------
> >>
> >> End of openssl-users Digest, Vol 52, Issue 19
> >> *********************************************
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mta.openssl.org/pipermail/openssl-users/attachments/20190326/09253e6e/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Tue, 26 Mar 2019 02:55:38 -0400
> From: Dennis Clarke <dclarke at blastwave.org>
> To: openssl-users at openssl.org
> Subject: Re: Reg solaris support for openssl 1.1.1b
> Message-ID: <4c02f69c-512b-d5c8-67a2-eebe6e3f3197 at blastwave.org>
> Content-Type: text/plain; charset=utf-8
>
> On 3/26/19 12:38 AM, ramakrushna mishra wrote:
> >     Hi All,
> >
> >
> > Thanks for your responses.?
> > I am able to build openssl 1.1.1 on my solaris and able to run "openssl
> > version".
> > I followed the same procedure for openssl 1.1.1b and when I run "openssl
> > version"? seeing the mentioned error. i.e?
> > "ld.so.1: openssl: fatal: relocation error: file openssl: symbol
> > OPENSSL_sk_new_null: referenced symbol not found
>
> Did you modify Configurations/10-main.conf ?
>
>
>
> --
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
> GreyBeard and suspenders optional
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 27 Mar 2019 19:33:44 +0900
> From: ???? (Souju TANAKA) <sojulibra at gmail.com>
> To: openssl-users at openssl.org
> Subject: Re: Building OpenSSL 1.1.1b for WinCE700
> Message-ID:
>         <
> CAPvkBATRzBmqYAmHfiJs9wbgCt_s7zk_jViTU1sia35-pfL4aQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> It works with our custommized cURL code.
> I wrote a detailed build instruction for CE.
>   https://qiita.com/souju/items/94117c024862f57459c3
>
> > It would be good if you created a github PR for this so the changes can
> be
> > considered for inclusion.
>
> Thank you. I post the PR.
>   https://github.com/openssl/openssl/pull/8596
>
> Regards,
> Souju TANAKA
>
>
> 2019?3?19?(?) 18:39 Matt Caswell <matt at openssl.org>:
>
> >
> >
> > 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 <winbase.h>" 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
> > >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mta.openssl.org/pipermail/openssl-users/attachments/20190327/9585737c/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> ------------------------------
>
> End of openssl-users Digest, Vol 52, Issue 41
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190328/a01b0b2d/attachment-0001.html>

From jerrylui803 at gmail.com  Thu Mar 28 18:31:08 2019
From: jerrylui803 at gmail.com (Jerry Lui)
Date: Thu, 28 Mar 2019 14:31:08 -0400
Subject: Question about RSA CRT private key operation
Message-ID: <CAGvkZ-vt+GUFUcZ+twEJEGruFb9xaejcXcOz-mseex_Yriwe6w@mail.gmail.com>

Hi,

While implementing my application with RSA, I came across this paper:
https://people.redhat.com/~fweimer/rsa-crt-leaks.pdf

When I implement RSA private key operation with CRT, should I do an extra
verify operation suggested in the paper (section 1.3)? or is this handled
by OpenSSL already? (More specifically in versions 1.0.2, 1.1.0, and 1.1.1)

i.e. When I'm doing RSA CRT private key operation:
- Is calling RSA_private_encrypt() sufficient?
OR
- Should I call RSA_private_encrypt() to get the cipher text, and pass the
cipher text to RSA_public_decrypt() (without using CRT). And return the
cipher text only if decrypt(encrypt(original_text)) matches the original
text?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190328/5a95f941/attachment.html>

From aram.akhavan at asu.edu  Fri Mar 29 20:23:31 2019
From: aram.akhavan at asu.edu (Aram Akhavan)
Date: Fri, 29 Mar 2019 13:23:31 -0700
Subject: CRL issuer does not match CA subject
Message-ID: <4fca7660-ca5a-ae8b-50ee-7af0b980ea3d@asu.edu>

Hello!

I'm creating a small PKI following the guide here: 
https://jamielinux.com/docs/openssl-certificate-authority

The intermediate CA cert is created with:
/openssl ca -config $ROOT_CONF -extensions v3_intermediate_ca //-days 
3650 -notext -md sha256/

If I then dump the cert, I see that subject line is
/Subject: C = us, ST = ca, O = test, CN = intermediate CA/

I then create the CRL using:
/openssl ca -config $INTRMDT_CONF //-gencrl -out $INTRMDT_CRL/

When I dump the CRL, though, the issuer is
/Issuer: /C=us/ST=ca/O=test/CN=intermediate ca/

When I put my certificate through 
https://certificate.revocationcheck.com/, it complains that the CRL 
issuer and intermediate CA subject don't match byte for byte.

Is there a way to have both generated with the same formatting? I looked 
through my configuration files and couldn't find anything that would 
explain the difference. I think it works anyways, but it would be nice 
to have them match...

Best regards,

Aram

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

From ivan.medoedov at gmail.com  Sat Mar 30 15:02:55 2019
From: ivan.medoedov at gmail.com (Ivan Medoedov)
Date: Sat, 30 Mar 2019 16:02:55 +0100
Subject: The smallest minimal example of an HTTPS GET request with openssl
Message-ID: <CAKioB7-m41BHz5qoa7_SpVo=q7Y46p-L_-PdtfDJh4ObU9vsDw@mail.gmail.com>

Hello,

I've only managed to find this, but it seems to do too much for what I need:

https://wiki.openssl.org/index.php/SSL/TLS_Client

Basically I need something like Go's http.Get("https://mysite.com/version")
to just get a one line of text from the server.

I can't use libcurl, I have to use pure openssl.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190330/508e65a1/attachment.html>

From openssl-users at dukhovni.org  Sat Mar 30 18:53:11 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 30 Mar 2019 14:53:11 -0400
Subject: The smallest minimal example of an HTTPS GET request with openssl
In-Reply-To: <CAKioB7-m41BHz5qoa7_SpVo=q7Y46p-L_-PdtfDJh4ObU9vsDw@mail.gmail.com>
References: <CAKioB7-m41BHz5qoa7_SpVo=q7Y46p-L_-PdtfDJh4ObU9vsDw@mail.gmail.com>
Message-ID: <20190330185311.GE1347@straasha.imrryr.org>

On Sat, Mar 30, 2019 at 04:02:55PM +0100, Ivan Medoedov wrote:

> I've only managed to find this, but it seems to do too much for what I need:
> 
> https://wiki.openssl.org/index.php/SSL/TLS_Client
> 
> Basically I need something like Go's http.Get("https://mysite.com/version")
> to just get a one line of text from the server.
> 
> I can't use libcurl, I have to use pure openssl.

OpenSSL is NOT an HTTPS (client or server) library.  OpenSSL can
establish a TLS connection, but does not implement anything like
"http.Get".  That's what libcurl and the like are for.

If you're willing to roll your own HTTP client code, then you
can use OpenSSL for the TLS part of the HTTPS transaction.

HTTP clients handle all sorts of complications over and above TLS:

    * Proxies
    * Redirects
    * Client requests with bodies
    * Authentication
    * Chunked transfer encoding
    * Content encoding (e.g. gzip)
    * Cookies
    ...

None of these are in scope for OpenSSL.

-- 
	Viktor.

From prajwal.pachi at gmail.com  Sat Mar 30 18:55:23 2019
From: prajwal.pachi at gmail.com (Prajwal Pachi)
Date: Sun, 31 Mar 2019 00:25:23 +0530
Subject: Error in OpenSSL1.1.1b during including in Project
Message-ID: <CAGNGh2qcGNOvp8F2UJw5YKSYhx+ptzxsPGxF0yauUb+i9oZTwg@mail.gmail.com>

Hi All,

I am trying to build openssl for Android Environment.
Openssl version: 1.1.1b
Android NDK: android-ndk-r15c
Android SDK: Android-26

I am able to create libssl.a and libcrypto.a. The generated Lib and Include
file, I am adding it to our project and trying to build.
I am getting error:* Severity Code Description Project File Line
Suppression State Error no member named 'ENGINE_cleanup' in the global
namespace; did you mean 'EVP_PBE_cleanup'?*

Kindly help me out, how to resolve this issue.


-- 
- Prajwal S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190331/a00920d9/attachment.html>

From ivan.medoedov at gmail.com  Sat Mar 30 19:09:01 2019
From: ivan.medoedov at gmail.com (Ivan Medoedov)
Date: Sat, 30 Mar 2019 20:09:01 +0100
Subject: The smallest minimal example of an HTTPS GET request with openssl
In-Reply-To: <20190330185311.GE1347@straasha.imrryr.org>
References: <CAKioB7-m41BHz5qoa7_SpVo=q7Y46p-L_-PdtfDJh4ObU9vsDw@mail.gmail.com>
 <20190330185311.GE1347@straasha.imrryr.org>
Message-ID: <CAKioB7-eZW-Gcpi4o2QBwwic87ErktzV1mQmm+JWFLMwmk9jHg@mail.gmail.com>

You are right of course. I handle HTTP myself. A TLS connection example
will suffice.

On Sat, Mar 30, 2019 at 7:53 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Sat, Mar 30, 2019 at 04:02:55PM +0100, Ivan Medoedov wrote:
>
> > I've only managed to find this, but it seems to do too much for what I
> need:
> >
> > https://wiki.openssl.org/index.php/SSL/TLS_Client
> >
> > Basically I need something like Go's http.Get("
> https://mysite.com/version")
> > to just get a one line of text from the server.
> >
> > I can't use libcurl, I have to use pure openssl.
>
> OpenSSL is NOT an HTTPS (client or server) library.  OpenSSL can
> establish a TLS connection, but does not implement anything like
> "http.Get".  That's what libcurl and the like are for.
>
> If you're willing to roll your own HTTP client code, then you
> can use OpenSSL for the TLS part of the HTTPS transaction.
>
> HTTP clients handle all sorts of complications over and above TLS:
>
>     * Proxies
>     * Redirects
>     * Client requests with bodies
>     * Authentication
>     * Chunked transfer encoding
>     * Content encoding (e.g. gzip)
>     * Cookies
>     ...
>
> None of these are in scope for OpenSSL.
>
> --
>         Viktor.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190330/3dd1a7fd/attachment-0001.html>

From openssl-users at dukhovni.org  Sat Mar 30 19:59:21 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 30 Mar 2019 15:59:21 -0400
Subject: The smallest minimal example of an HTTPS GET request with openssl
In-Reply-To: <CAKioB7-eZW-Gcpi4o2QBwwic87ErktzV1mQmm+JWFLMwmk9jHg@mail.gmail.com>
References: <CAKioB7-m41BHz5qoa7_SpVo=q7Y46p-L_-PdtfDJh4ObU9vsDw@mail.gmail.com>
 <20190330185311.GE1347@straasha.imrryr.org>
 <CAKioB7-eZW-Gcpi4o2QBwwic87ErktzV1mQmm+JWFLMwmk9jHg@mail.gmail.com>
Message-ID: <20190330195921.GF1347@straasha.imrryr.org>

On Sat, Mar 30, 2019 at 08:09:01PM +0100, Ivan Medoedov wrote:

> You are right of course. I handle HTTP myself. A TLS connection example
> will suffice.
> 
> > > https://wiki.openssl.org/index.php/SSL/TLS_Client

That example can be simplified, but OpenSSL does not presently
provide a built-in high-level function to make a verified connection
to a given host:port.

With library initialization now implicit in 1.1.0 and later, and
thread-safety no longer requiring application callbacks, this would
now be easier to provide, but:

    * SSL_CTX creation is moderately expensive, and one should
      generally create and use the same SSL_CTX for multiple SSL
      connecitons in any applications that uses more than one SSL
      connection.  So typically, there would still be a one-time
      initialization step to create the SSL_CTX (application context).

    * Some applications will want to do post-handshake I/O via the
      socket API, and prefer to hand OpenSSL an already connected
      socket on which to perform the TLS handshake.  Others may
      want OpenSSL to establish the connection and may prefer to
      use BIO interface to interact with the peer.

    * While many systems have a usable default "trust store",
      some do not, or the default "trust store" is overly inclusive.
      Applications should generally allow the user to specify the
      set of trusted CAs.

    ...

Through in enough similar qualifiers, and you end up with the rather
complex example.  It could perhaps be refactored as (hypothetical
interface):

	/*
	 * Context with default trust store, protocols, ciphers, ...
	 * and peer verification enabled.
	 */
	SSL_CTX *app_ctx = SSL_default_ssl_ctx(TLS_method());

	/*
	 * Prepare verified (with name checks) SSL handle for the
	 * requested host:port (with SNI).
	 */
	SSL *con = SSL_default_ssl(app_ctx, host, port);

Then depending on whether you want to give OpenSSL an already
connected socket, or have OpenSSL make the connection for you:

	int err = SSL_connect_socket(con, fd);

or (something along the lines of):

	BIO *bp = SSL_connect_hostport(con, host, port, &err);

At this point a stock error handler may be required, but if all
went well, you now need an I/O loop.  And so would need to either
use the connected file descriptor with your own buffering, ...
or use OpenSSL BIOs, or some other buffering I/O layer that
supports custom read/write wrappers.

On FreeBSD/NetBSD it might be nice to have stock "fittings" to
wrap stdio around OpenSSL connections via:

     #include <stdio.h>

     FILE *
     funopen(const void *cookie,
             int	(*readfn)  (void *, char *, int),
             int	(*writefn) (void *, const char *, int),
             fpos_t	(*seekfn)  (void *, fpos_t, int),
             int	(*closefn) (void *));

Providing higher level interfaces to the core TLS library would
make a good project for someone good at API design, who is familiar
with OpenSSL, but more interested in the API than the internals.

-- 
	Viktor.

From ivan.medoedov at gmail.com  Sat Mar 30 20:28:05 2019
From: ivan.medoedov at gmail.com (Ivan Medoedov)
Date: Sat, 30 Mar 2019 21:28:05 +0100
Subject: The smallest minimal example of an HTTPS GET request with openssl
In-Reply-To: <20190330195921.GF1347@straasha.imrryr.org>
References: <CAKioB7-m41BHz5qoa7_SpVo=q7Y46p-L_-PdtfDJh4ObU9vsDw@mail.gmail.com>
 <20190330185311.GE1347@straasha.imrryr.org>
 <CAKioB7-eZW-Gcpi4o2QBwwic87ErktzV1mQmm+JWFLMwmk9jHg@mail.gmail.com>
 <20190330195921.GF1347@straasha.imrryr.org>
Message-ID: <CAKioB78Xu2FCkoJ74tZ-AHwf74KTmWULDBDp1ErZEdHW0f0c0A@mail.gmail.com>

Thanks, Viktor.

On Sat, Mar 30, 2019 at 8:59 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Sat, Mar 30, 2019 at 08:09:01PM +0100, Ivan Medoedov wrote:
>
> > You are right of course. I handle HTTP myself. A TLS connection example
> > will suffice.
> >
> > > > https://wiki.openssl.org/index.php/SSL/TLS_Client
>
> That example can be simplified, but OpenSSL does not presently
> provide a built-in high-level function to make a verified connection
> to a given host:port.
>
> With library initialization now implicit in 1.1.0 and later, and
> thread-safety no longer requiring application callbacks, this would
> now be easier to provide, but:
>
>     * SSL_CTX creation is moderately expensive, and one should
>       generally create and use the same SSL_CTX for multiple SSL
>       connecitons in any applications that uses more than one SSL
>       connection.  So typically, there would still be a one-time
>       initialization step to create the SSL_CTX (application context).
>
>     * Some applications will want to do post-handshake I/O via the
>       socket API, and prefer to hand OpenSSL an already connected
>       socket on which to perform the TLS handshake.  Others may
>       want OpenSSL to establish the connection and may prefer to
>       use BIO interface to interact with the peer.
>
>     * While many systems have a usable default "trust store",
>       some do not, or the default "trust store" is overly inclusive.
>       Applications should generally allow the user to specify the
>       set of trusted CAs.
>
>     ...
>
> Through in enough similar qualifiers, and you end up with the rather
> complex example.  It could perhaps be refactored as (hypothetical
> interface):
>
>         /*
>          * Context with default trust store, protocols, ciphers, ...
>          * and peer verification enabled.
>          */
>         SSL_CTX *app_ctx = SSL_default_ssl_ctx(TLS_method());
>
>         /*
>          * Prepare verified (with name checks) SSL handle for the
>          * requested host:port (with SNI).
>          */
>         SSL *con = SSL_default_ssl(app_ctx, host, port);
>
> Then depending on whether you want to give OpenSSL an already
> connected socket, or have OpenSSL make the connection for you:
>
>         int err = SSL_connect_socket(con, fd);
>
> or (something along the lines of):
>
>         BIO *bp = SSL_connect_hostport(con, host, port, &err);
>
> At this point a stock error handler may be required, but if all
> went well, you now need an I/O loop.  And so would need to either
> use the connected file descriptor with your own buffering, ...
> or use OpenSSL BIOs, or some other buffering I/O layer that
> supports custom read/write wrappers.
>
> On FreeBSD/NetBSD it might be nice to have stock "fittings" to
> wrap stdio around OpenSSL connections via:
>
>      #include <stdio.h>
>
>      FILE *
>      funopen(const void *cookie,
>              int        (*readfn)  (void *, char *, int),
>              int        (*writefn) (void *, const char *, int),
>              fpos_t     (*seekfn)  (void *, fpos_t, int),
>              int        (*closefn) (void *));
>
> Providing higher level interfaces to the core TLS library would
> make a good project for someone good at API design, who is familiar
> with OpenSSL, but more interested in the API than the internals.
>
> --
>         Viktor.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190330/4de6da12/attachment.html>

From openssl-users at dukhovni.org  Sat Mar 30 20:50:17 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 30 Mar 2019 16:50:17 -0400
Subject: The smallest minimal example of an HTTPS GET request with openssl
In-Reply-To: <CAKioB78Xu2FCkoJ74tZ-AHwf74KTmWULDBDp1ErZEdHW0f0c0A@mail.gmail.com>
References: <CAKioB7-m41BHz5qoa7_SpVo=q7Y46p-L_-PdtfDJh4ObU9vsDw@mail.gmail.com>
 <20190330185311.GE1347@straasha.imrryr.org>
 <CAKioB7-eZW-Gcpi4o2QBwwic87ErktzV1mQmm+JWFLMwmk9jHg@mail.gmail.com>
 <20190330195921.GF1347@straasha.imrryr.org>
 <CAKioB78Xu2FCkoJ74tZ-AHwf74KTmWULDBDp1ErZEdHW0f0c0A@mail.gmail.com>
Message-ID: <D1FDD9E7-23FC-4948-8976-D6C34B6F2161@dukhovni.org>



> On Mar 30, 2019, at 4:28 PM, Ivan Medoedov <ivan.medoedov at gmail.com> wrote:
> 
> Thanks, Viktor.

You're welcome.  One important note about the example on the Wiki.
Since OpenSSL 1.0.2, there is internal support for certificate
name checks.  You should not roll your own.

The SSL_set1_host(3) interface is present since OpenSSL 1.1.0.
In OpenSSL 1.0.2 you can use SSL_CTX_get0_param(3) and
X509_VERIFY_PARAM_set1_host(3):

        X509_VERIFY_PARAM *vpm = SSL_get0_param(ssl);
        X509_VERIFY_PARAM_set1_host(vpm, "www.foo.com", 0);

Either of the above needs to happen before the handshake starts and
then the checks are made automatically as part of the handshake,
resulting in a certificate verification failure if the name checks
fail.

Alternatively, you can call  X509_check_host(3) after the handshake
completes.  This might also then need to happen after session resumption,
because the cached certificate validity would only cover the trust path,
and not the name checks.  But if you never resume sessions that failed
name checks previously, and never re-use sessions across different
host names (for the same IP e.g.) then you might be safe without, some
care is recommended.

-- 
	Viktor.


From prajwal.pachi at gmail.com  Sun Mar 31 06:57:00 2019
From: prajwal.pachi at gmail.com (Prajwal Pachi)
Date: Sun, 31 Mar 2019 12:27:00 +0530
Subject: Error in OpenSSL1.1.1b during including in Project
In-Reply-To: <CAGNGh2qcGNOvp8F2UJw5YKSYhx+ptzxsPGxF0yauUb+i9oZTwg@mail.gmail.com>
References: <CAGNGh2qcGNOvp8F2UJw5YKSYhx+ptzxsPGxF0yauUb+i9oZTwg@mail.gmail.com>
Message-ID: <CAGNGh2oTfoE7bYwQ1HZq3pZy6DZn3oA9UngRO2Qvz+JHStghAg@mail.gmail.com>

Hi All,

I am trying to build a cross platform library with help of Openssll
LibCrypto and libSSL library. When i generate the lib and include the files
and lib in cross platform library project I am getting below error.
error : member access into incomplete type 'ssl_ctx_st'
1>                 *   X509Ptr cert = {
::PEM_read_bio_X509_AUX(bio_cert.get(), 0, m_ctx->default_passwd_callback,
m_ctx->default_passwd_callback_userdata), ::X509_free };*

*Kindly if anybody know the how to resolve this error, Please let me know.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190331/a614ca79/attachment.html>

From Andrew_Porter at bmc.com  Sun Mar 31 15:43:03 2019
From: Andrew_Porter at bmc.com (Porter, Andrew)
Date: Sun, 31 Mar 2019 15:43:03 +0000
Subject: The smallest minimal example of an HTTPS GET request with openssl
In-Reply-To: <CAKioB7-m41BHz5qoa7_SpVo=q7Y46p-L_-PdtfDJh4ObU9vsDw@mail.gmail.com>
References: <CAKioB7-m41BHz5qoa7_SpVo=q7Y46p-L_-PdtfDJh4ObU9vsDw@mail.gmail.com>
Message-ID: <e4d4a4faa763422ba85e3c6e82206fc1@phx-exmbprd-02.adprod.bmc.com>

You would have to ignore some initial certificate info output but some variation on

echo "GET /version" | openssl s_client -connect test.example.com -crlf -ign_eof -quiet

would be as pure OpenSSL as you can get?

Andrew

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Ivan Medoedov
Sent: Saturday, March 30, 2019 08:03
To: openssl-users at openssl.org
Subject: [EXTERNAL] The smallest minimal example of an HTTPS GET request with openssl

Hello,

I've only managed to find this, but it seems to do too much for what I need:

https://wiki.openssl.org/index.php/SSL/TLS_Client<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openssl.org_index.php_SSL_TLS-5FClient&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=rM-xapYCunnmjke6suxLaVU8krc3wfCZvRQxfT87RRc&m=n8RqUrz6Ov5TrW2POn-Srsvd_sQFaz4rbCfMwfYOShM&s=dV4FDjsLprTO1x56rJ6EycpvjEe2Q6WiTDsX35rNkjk&e=>

Basically I need something like Go's http.Get("https://mysite.com/version<https://urldefense.proofpoint.com/v2/url?u=https-3A__mysite.com_version&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=rM-xapYCunnmjke6suxLaVU8krc3wfCZvRQxfT87RRc&m=n8RqUrz6Ov5TrW2POn-Srsvd_sQFaz4rbCfMwfYOShM&s=C23QKTnwylYwT5PT_ziC5NcbdioKu1wSXQWiE0B-nHE&e=>") to just get a one line of text from the server.

I can't use libcurl, I have to use pure openssl.

Thanks


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

From jgh at wizmail.org  Sun Mar 31 19:56:39 2019
From: jgh at wizmail.org (Jeremy Harris)
Date: Sun, 31 Mar 2019 20:56:39 +0100
Subject: SSL_SESSION_set1_ticket ?
Message-ID: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>

Why is there not an SSL_SESSION_set1_ticket() ?

Having to store an entire ASN.1-coded session in a DB, at
some 1250 byte versus 160 for the ticket is suboptimal.


This is for client-side TLS1.2 resumption, when the clients
are separate processes and time-separated.

You can get ticket blobs via
SSL_SESSION_get0_ticket(SSL_get_session(ssl)).

You can get/set the entire session via i2d_SSL_SESSION(sess, ),
d2i_SSL_session(&sess, string, ), SSL_set_session(ssl, sess).

If it were possible to use an SSL_SESSION_set1_ticket,
what else would need to be set in the session?
-- 
Thanks,
  Jeremy

From dfulger at gmx.com  Wed Mar 27 15:02:37 2019
From: dfulger at gmx.com (Dan Fulger)
Date: Wed, 27 Mar 2019 15:02:37 -0000
Subject: An idiosyncratic port of OpenSSL 1.1.1b to OS/400 ILE
Message-ID: <trinity-8c1d50c4-b00b-4ba2-8a2e-c4f0e508f352-1553698639847@3c-app-mailcom-bs01>

An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20190327/bddf3ba0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AS400_GNU.tar.gz
Type: application/octet-stream
Size: 503420 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20190327/bddf3ba0/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AS400patch.tar.gz
Type: application/octet-stream
Size: 58434 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20190327/bddf3ba0/attachment-0003.obj>