From matt at openssl.org Wed Jul 1 08:33:22 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 1 Jul 2020 09:33:22 +0100 Subject: manual edit: i2d_PKCS7_bio In-Reply-To: References: Message-ID: <7303f9e8-7412-1c4f-760f-e10c6b7b5f99@openssl.org> On 30/06/2020 20:25, Michael Mueller wrote: > https://www.openssl.org/docs/man1.1.1/man3/i2d_PKCS7_bio.html > > current:____ > > i2d_TYPE_fp() is similar to i2d_TYPE() except it writes the encoding of > the structure?a?to BIO?bp?and it returns 1 for success and 0 for failure. > > Suggested edit:__ > > i2d_TYPE_fp() is similar to i2d_TYPE() except it writes the encoding of > the structure?a?to?FILE pointer?fp?and it returns 1 for success and 0 > for failure.____ Raised as PR 12338: https://github.com/openssl/openssl/pull/12338 Matt From vincent.mc.li at gmail.com Wed Jul 1 17:44:03 2020 From: vincent.mc.li at gmail.com (Vincent Li) Date: Wed, 1 Jul 2020 10:44:03 -0700 (PDT) Subject: OpenSSL 1.1 result in error: variable has initializer but incomplete type static BIO_METHOD Message-ID: Hi, I am running apache bench (ab) and ported it with OpenSSL 1.0 support on top of mTCP support https://github.com/vincentmli/mtcp/commit/642835f786aa642ea0f20fe8db9b09054639453a#diff-02f7a72f514e6e0543e832d37450c251 but it breaks after I upgraded OpenSSL 1.0 to OpenSSL 1.1, I found there are quite a few projects having same problems including libevent, libevent has the fix in https://github.com/libevent/libevent/commit/3e9e0a0d46e4508e8782ec3787c6d86bab63046d so I borrowed the fix from libevent and applied the code fix below: ``` #include #include "openssl-compat.h" #define get_last_socket_error() errno #define clear_socket_error() errno=0 /* clone of openssl crypto/bio/bss_sock.c */ #ifdef HAVE_MTCP static int mtcp_sock_write(BIO *h, const char *buf, int num); static int mtcp_sock_read(BIO *h, char *buf, int size); static int mtcp_sock_puts(BIO *h, const char *str); static long mtcp_sock_ctrl(BIO *h, int cmd, long arg1, void *arg2); static int mtcp_sock_new(BIO *h); static int mtcp_sock_free(BIO *data); int BIO_mtcp_sock_should_retry(int s); /* static BIO_METHOD mtcp_methods_sockp = { BIO_TYPE_SOCKET, "socket", mtcp_sock_write, mtcp_sock_read, mtcp_sock_puts, NULL, mtcp_sock_ctrl, mtcp_sock_new, mtcp_sock_free, NULL, }; BIO_METHOD *BIO_mtcp_s_socket(void) { return (&mtcp_methods_sockp); } */ static BIO_METHOD *mtcp_methods_sockp; static BIO_METHOD * BIO_mtcp_s_socket(void) { if (mtcp_methods_sockp == NULL) { mtcp_methods_sockp = BIO_meth_new(BIO_TYPE_SOCKET, "socket"); if (mtcp_methods_sockp == NULL) return NULL; BIO_meth_set_write(mtcp_methods_sockp, mtcp_sock_write); BIO_meth_set_read(mtcp_methods_sockp, mtcp_sock_read); BIO_meth_set_puts(mtcp_methods_sockp, mtcp_sock_puts); BIO_meth_set_ctrl(mtcp_methods_sockp, mtcp_sock_ctrl); BIO_meth_set_create(mtcp_methods_sockp, mtcp_sock_new); BIO_meth_set_destroy(mtcp_methods_sockp, mtcp_sock_free); } return mtcp_methods_sockp; } /* BIO *BIO_mtcp_new_socket(mctx_t mctx, int fd, int close_flag) { BIO *ret; ret = BIO_new(BIO_mtcp_s_socket()); if (ret == NULL) return (NULL); BIO_set_fd(ret, fd, close_flag); ret->ptr = mctx; return (ret); } */ BIO *BIO_mtcp_new_socket(mctx_t mctx, int fd, int close_flag) { BIO *ret; if(!fd) return NULL; ret = BIO_new(BIO_mtcp_s_socket()); if (ret == NULL) return (NULL); BIO_set_init(ret, 1); BIO_set_fd(ret, fd, close_flag); BIO_set_data(ret, mctx); return (ret); } /* static int mtcp_sock_new(BIO *bi) { bi->init = 0; bi->num = 0; bi->ptr = NULL; bi->flags = 0; return (1); } */ static int mtcp_sock_new(BIO *bi) { BIO_set_init(bi, 0); BIO_set_num(bi, 0); BIO_set_data(bi, NULL); BIO_set_flags(bi, 0); return (1); } /* static int mtcp_sock_free(BIO *a) { if (a == NULL) return (0); mctx_t mctx = (mctx_t)a->ptr; mtcp_close(mctx, a->num); return (1); } */ static int mtcp_sock_free(BIO *a) { if (a == NULL) return (0); mctx_t mctx = (mctx_t)BIO_get_data(a); mtcp_close(mctx, BIO_get_num(a)); return (1); } /* static int mtcp_sock_read(BIO *b, char *out, int outl) { int ret = 0; mctx_t mctx = (mctx_t)b->ptr; if (out != NULL) { clear_socket_error(); //ret = readsocket(b->num, out, outl); ret = mtcp_read(mctx, b->num, out, outl); BIO_clear_retry_flags(b); if (ret <= 0) { if (BIO_mtcp_sock_should_retry(ret)) BIO_set_retry_read(b); } } return (ret); } */ static int mtcp_sock_read(BIO *b, char *out, int outl) { int ret = 0; mctx_t mctx = (mctx_t)BIO_get_data(b); if (out != NULL) { clear_socket_error(); //ret = readsocket(b->num, out, outl); ret = mtcp_read(mctx, BIO_get_num(b), out, outl); BIO_clear_retry_flags(b); if (ret <= 0) { if (BIO_mtcp_sock_should_retry(ret)) BIO_set_retry_read(b); } } return (ret); } /* static int mtcp_sock_write(BIO *b, const char *in, int inl) { int ret; mctx_t mctx = (mctx_t)b->ptr; clear_socket_error(); //ret = writesocket(b->num, in, inl); ret = mtcp_write(mctx, b->num, in, inl); BIO_clear_retry_flags(b); if (ret <= 0) { if (BIO_mtcp_sock_should_retry(ret)) BIO_set_retry_write(b); } return (ret); } */ static int mtcp_sock_write(BIO *b, const char *in, int inl) { int ret; mctx_t mctx = (mctx_t)BIO_get_data(b); clear_socket_error(); //ret = writesocket(b->num, in, inl); ret = mtcp_write(mctx, BIO_get_num(b), in, inl); BIO_clear_retry_flags(b); if (ret <= 0) { if (BIO_mtcp_sock_should_retry(ret)) BIO_set_retry_write(b); } return (ret); } /* static long mtcp_sock_ctrl(BIO *b, int cmd, long num, void *ptr) { long ret = 1; int *ip; switch (cmd) { case BIO_C_SET_FD: mtcp_sock_free(b); b->num = *((int *)ptr); b->shutdown = (int)num; b->init = 1; break; case BIO_C_GET_FD: if (b->init) { ip = (int *)ptr; if (ip != NULL) *ip = b->num; ret = b->num; } else ret = -1; break; case BIO_CTRL_GET_CLOSE: ret = b->shutdown; break; case BIO_CTRL_SET_CLOSE: b->shutdown = (int)num; break; case BIO_CTRL_DUP: case BIO_CTRL_FLUSH: ret = 1; break; default: ret = 0; break; } return (ret); } */ static long mtcp_sock_ctrl(BIO *b, int cmd, long num, void *ptr) { long ret = 1; int *ip; switch (cmd) { case BIO_C_SET_FD: mtcp_sock_free(b); BIO_set_num(b, *((int *)ptr)); BIO_set_shutdown(b, (int)num); BIO_set_init(b, 1); break; case BIO_C_GET_FD: if (BIO_get_init(b)) { ip = (int *)ptr; if (ip != NULL) *ip = BIO_get_num(b); ret = BIO_get_num(b); } else ret = -1; break; case BIO_CTRL_GET_CLOSE: ret = BIO_get_shutdown(b); break; case BIO_CTRL_SET_CLOSE: BIO_set_shutdown(b, (int)num); break; case BIO_CTRL_DUP: case BIO_CTRL_FLUSH: ret = 1; break; default: ret = 0; break; } return (ret); } ``` here is the openssl-compat.h ``` #ifndef OPENSSL_COMPAT_H #define OPENSSL_COMPAT_H #include #if (OPENSSL_VERSION_NUMBER < 0x10100000L) static inline BIO_METHOD *BIO_meth_new(int type, const char *name) { BIO_METHOD *biom = calloc(1, sizeof(BIO_METHOD)); if (biom != NULL) { biom->type = type; biom->name = name; } return biom; } #define BIO_meth_set_write(b, f) (b)->bwrite = (f) #define BIO_meth_set_read(b, f) (b)->bread = (f) #define BIO_meth_set_puts(b, f) (b)->bputs = (f) #define BIO_meth_set_ctrl(b, f) (b)->ctrl = (f) #define BIO_meth_set_create(b, f) (b)->create = (f) #define BIO_meth_set_destroy(b, f) (b)->destroy = (f) #define BIO_set_init(b, val) (b)->init = (val) #define BIO_set_data(b, val) (b)->ptr = (val) #define BIO_set_shutdown(b, val) (b)->shutdown = (val) #define BIO_set_num(b, val) (b)->num = (val) #define BIO_set_flags(b, val) (b)->flags = (val) #define BIO_get_init(b) (b)->init #define BIO_get_data(b) (b)->ptr #define BIO_get_shutdown(b) (b)->shutdown #define BIO_get_num(b) (b)->num #define BIO_get_flags(b) (b)->flags #define TLS_method SSLv23_method #endif /* (OPENSSL_VERSION_NUMBER < 0x10100000L) */ #endif /* OPENSSL_COMPAT_H */ ``` but I got compiling error ``` make[2]: Entering directory '/usr/src/mtcp/apps/apache_benchmark/support' /usr/src/mtcp/apps/apache_benchmark/srclib/apr/libtool --silent --mode=compile gcc -g -O2 -pthread -I/usr/src/mtcp/mtcp/lib/ -I/usr/src/mtcp/mtcp/src/include/ -DMULTI_THREADED -I/usr/src/mtcp/mtcp/lib/ -I/usr/src/mtcp/mtcp/src/include/ -DMULTI_THREADED -DLINUX -D_REENTRANT -D_GNU_SOURCE -I/usr/src/mtcp/apps/apache_benchmark/srclib/pcre -I. -I/usr/src/mtcp/apps/apache_benchmark/os/unix -I/usr/src/mtcp/apps/apache_benchmark/include -I/usr/src/mtcp/apps/apache_benchmark/srclib/apr/include -I/usr/src/mtcp/apps/apache_benchmark/srclib/apr-util/include -I/usr/src/mtcp/apps/apache_benchmark/srclib/apr-util/xml/expat/lib -I/usr/lib/include -I/usr/src/mtcp/apps/apache_benchmark/modules/ssl -prefer-non-pic -static -c ab.c && touch ab.lo ab.c: In function ?mtcp_sock_new?: ab.c:547:5: warning: implicit declaration of function ?BIO_set_num?; did you mean ?BIO_set_next?? [-Wimplicit-function-declaration] BIO_set_num(bi, 0); ^~~~~~~~~~~ BIO_set_next ab.c: In function ?mtcp_sock_free?: ab.c:570:22: warning: implicit declaration of function ?BIO_get_num?; did you mean ?BIO_get_init?? [-Wimplicit-function-declaration] mtcp_close(mctx, BIO_get_num(a)); ^~~~~~~~~~~ BIO_get_init ..........CUT...... /usr/src/mtcp/apps/apache_benchmark/support/ab.c:547: undefined reference to `BIO_set_num' .libs/ab.o: In function `mtcp_sock_free': /usr/src/mtcp/apps/apache_benchmark/support/ab.c:570: undefined reference to `BIO_get_num' .libs/ab.o: In function `mtcp_sock_ctrl': /usr/src/mtcp/apps/apache_benchmark/support/ab.c:703: undefined reference to `BIO_get_num' /usr/src/mtcp/apps/apache_benchmark/support/ab.c:704: undefined reference to `BIO_get_num' /usr/src/mtcp/apps/apache_benchmark/support/ab.c:695: undefined reference to `BIO_set_num' .libs/ab.o: In function `mtcp_sock_read': /usr/src/mtcp/apps/apache_benchmark/support/ab.c:603: undefined reference to `BIO_get_num' .libs/ab.o: In function `mtcp_sock_write': /usr/src/mtcp/apps/apache_benchmark/support/ab.c:638: undefined reference to `BIO_get_num' .libs/ab.o: In function `main': /usr/src/mtcp/apps/apache_benchmark/support/ab.c:2916: undefined reference to `SSLv3_client_method' /usr/src/mtcp/apps/apache_benchmark/support/ab.c:2913: undefined reference to `SSLv2_client_method' /usr/src/mtcp/apps/apache_benchmark/support/ab.c:2978: undefined reference to `CRYPTO_malloc_init' collect2: error: ld returned 1 exit status Makefile:38: recipe for target 'ab' failed make[2]: *** [ab] Error 1 ``` Since I defined BIO_set/get_init/data/shutdown/num in openssl-compat.h, why it only shows undefined reference to `BIO_set/set_num', not others? I am confused From vincent.mc.li at gmail.com Wed Jul 1 21:07:26 2020 From: vincent.mc.li at gmail.com (Vincent Li) Date: Wed, 1 Jul 2020 14:07:26 -0700 (PDT) Subject: OpenSSL 1.1 result in error: variable has initializer but incomplete type static BIO_METHOD In-Reply-To: References: Message-ID: On Wed, 1 Jul 2020, Vincent Li wrote: > > Hi, > > I am running apache bench (ab) and ported it with OpenSSL 1.0 support on top of mTCP support > > https://github.com/vincentmli/mtcp/commit/642835f786aa642ea0f20fe8db9b09054639453a#diff-02f7a72f514e6e0543e832d37450c251 > > but it breaks after I upgraded OpenSSL 1.0 to OpenSSL 1.1, I found there > are quite a few projects having same problems including libevent, libevent > has the fix in https://github.com/libevent/libevent/commit/3e9e0a0d46e4508e8782ec3787c6d86bab63046d > > so I borrowed the fix from libevent and applied the code fix below: > > ``` > #include > #include "openssl-compat.h" > #define get_last_socket_error() errno > #define clear_socket_error() errno=0 > /* clone of openssl crypto/bio/bss_sock.c */ > > #ifdef HAVE_MTCP > > static int mtcp_sock_write(BIO *h, const char *buf, int num); > static int mtcp_sock_read(BIO *h, char *buf, int size); > static int mtcp_sock_puts(BIO *h, const char *str); > static long mtcp_sock_ctrl(BIO *h, int cmd, long arg1, void *arg2); > static int mtcp_sock_new(BIO *h); > static int mtcp_sock_free(BIO *data); > int BIO_mtcp_sock_should_retry(int s); .........SNIP......... > > static long mtcp_sock_ctrl(BIO *b, int cmd, long num, void *ptr) > { > long ret = 1; > int *ip; > > switch (cmd) { > case BIO_C_SET_FD: > mtcp_sock_free(b); > BIO_set_num(b, *((int *)ptr)); > BIO_set_shutdown(b, (int)num); > BIO_set_init(b, 1); > break; > case BIO_C_GET_FD: > if (BIO_get_init(b)) { > ip = (int *)ptr; > if (ip != NULL) > *ip = BIO_get_num(b); > ret = BIO_get_num(b); > } else > ret = -1; > break; > case BIO_CTRL_GET_CLOSE: > ret = BIO_get_shutdown(b); > break; > case BIO_CTRL_SET_CLOSE: > BIO_set_shutdown(b, (int)num); > break; > case BIO_CTRL_DUP: > case BIO_CTRL_FLUSH: > ret = 1; > break; > default: > ret = 0; > break; > } > return (ret); > } I found http://vega.pgw.jp/~kabe/vsd/migrate2openssl-1.1.html which says: "bio->num (file descripter) could be set by BIO_set_fd(), but since this callbacks the routine set by BIO_meth_set_ctrl(biom, BioCtrl), beware of infinite loops. Recommend to not touch bio->num member and leave it alone." so I used BIO_set/get_fd() to work with the bio->num, it compiles ok with some warnings, but it appears I hit the infinite loops and core dump: root at vli-lab:/usr/src/mtcp/apps/apache_benchmark/support# cp .libs/ab . root at vli-lab:/usr/src/mtcp/apps/apache_benchmark/support# gdb --args ab -N 4 -c 4 -n 160 https://10.2.1.63/ GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git ...........SNIP............ Checking link status..done Port 0 Link Up - speed 10000 Mbps - full-duplex Benchmarking 10.2.1.63 (be patient) [New Thread 0x7fdff19fb700 (LWP 1510)] CPU0 connecting to port 443 [New Thread 0x7fdff11fa700 (LWP 1511)] [New Thread 0x7fdff09f9700 (LWP 1512)] CPU1 connecting to port 443 [New Thread 0x7fdfea6fe700 (LWP 1513)] CPU2 connecting to port 443 [New Thread 0x7fdfd7fff700 (LWP 1514)] CPU3 connecting to port 443 CPU 0: initialization finished. [mtcp_create_context:1359] CPU 0 is now the master thread. [CPU 0] dpdk0 flows: 0, RX: 0(pps) (err: 0), 0.00(Gbps), TX: 0(pps), 0.00(Gbps) [ ALL ] dpdk0 flows: 0, RX: 0(pps) (err: 0), 0.00(Gbps), TX: 0(pps), 0.00(Gbps) Thread 8 "ab" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fdff19fb700 (LWP 1510)] 0x00005555555dd3cd in mtcp_sock_ctrl (b=0x7fdfe4003dd0, cmd=105, num=0, ptr=0x560af680, close_flag=1443559040) at ab.c:692 692 switch (cmd) { (gdb) bt #0 0x00005555555dd3cd in mtcp_sock_ctrl (b=0x7fdfe4003dd0, cmd=105, num=0, ptr=0x560af680, close_flag=1443559040) at ab.c:692 #1 0x00007ffff6474949 in BIO_ctrl () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #2 0x00005555555dd3fb in mtcp_sock_ctrl (b=0x7fdfe4003dd0, cmd=, num=, ptr=0x560af680, close_flag=1443559040) at ab.c:703 #3 0x00007ffff6474949 in BIO_ctrl () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #4 0x00005555555dd3fb in mtcp_sock_ctrl (b=0x7fdfe4003dd0, cmd=, num=, ptr=0x560af680, close_flag=1443559040) at ab.c:703 #5 0x00007ffff6474949 in BIO_ctrl () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #6 0x00005555555dd3fb in mtcp_sock_ctrl (b=0x7fdfe4003dd0, cmd=, num=, ptr=0x560af680, close_flag=1443559040) at ab.c:703 ....loop continues.... How do I avoid the loops? here is the changed code: #ifdef USE_SSL #ifndef OPENSSL_NO_SOCK #include #include "openssl-compat.h" #define get_last_socket_error() errno #define clear_socket_error() errno=0 /* clone of openssl crypto/bio/bss_sock.c */ #ifdef HAVE_MTCP static int mtcp_sock_write(BIO *h, const char *buf, int num, int close_flag); static int mtcp_sock_read(BIO *h, char *buf, int size, int close_flag); static int mtcp_sock_puts(BIO *h, const char *str, int close_flag); static long mtcp_sock_ctrl(BIO *h, int cmd, long arg1, void *arg2, int close_flag); static int mtcp_sock_new(BIO *h); static int mtcp_sock_free(BIO *data, int close_flag); int BIO_mtcp_sock_should_retry(int s); static BIO_METHOD *mtcp_methods_sockp; static BIO_METHOD * BIO_mtcp_s_socket(void) { if (mtcp_methods_sockp == NULL) { mtcp_methods_sockp = BIO_meth_new(BIO_TYPE_SOCKET, "socket"); if (mtcp_methods_sockp == NULL) return NULL; BIO_meth_set_write(mtcp_methods_sockp, mtcp_sock_write); BIO_meth_set_read(mtcp_methods_sockp, mtcp_sock_read); BIO_meth_set_puts(mtcp_methods_sockp, mtcp_sock_puts); BIO_meth_set_ctrl(mtcp_methods_sockp, mtcp_sock_ctrl); BIO_meth_set_create(mtcp_methods_sockp, mtcp_sock_new); BIO_meth_set_destroy(mtcp_methods_sockp, mtcp_sock_free); } return mtcp_methods_sockp; } BIO *BIO_mtcp_new_socket(mctx_t mctx, int fd, int close_flag) { BIO *ret; if(!fd) return NULL; ret = BIO_new(BIO_mtcp_s_socket()); if (ret == NULL) return (NULL); BIO_set_init(ret, 1); BIO_set_fd(ret, fd, close_flag); BIO_set_data(ret, mctx); return (ret); } static int mtcp_sock_new(BIO *bi) { BIO_set_init(bi, 0); // BIO_set_fd(bi, fd, close_flag) BIO_set_data(bi, NULL); BIO_set_flags(bi, 0); return (1); } static int mtcp_sock_free(BIO *a, int close_flag) { if (a == NULL) return (0); mctx_t mctx = (mctx_t)BIO_get_data(a); mtcp_close(mctx, BIO_get_fd(a, close_flag)); return (1); } static int mtcp_sock_read(BIO *b, char *out, int outl, int close_flag) { int ret = 0; mctx_t mctx = (mctx_t)BIO_get_data(b); if (out != NULL) { clear_socket_error(); //ret = readsocket(b->num, out, outl); ret = mtcp_read(mctx, BIO_get_fd(b, close_flag), out, outl); BIO_clear_retry_flags(b); if (ret <= 0) { if (BIO_mtcp_sock_should_retry(ret)) BIO_set_retry_read(b); } } return (ret); } static int mtcp_sock_write(BIO *b, const char *in, int inl, int close_flag) { int ret; mctx_t mctx = (mctx_t)BIO_get_data(b); clear_socket_error(); //ret = writesocket(b->num, in, inl); ret = mtcp_write(mctx, BIO_get_fd(b, close_flag), in, inl); BIO_clear_retry_flags(b); if (ret <= 0) { if (BIO_mtcp_sock_should_retry(ret)) BIO_set_retry_write(b); } return (ret); } static long mtcp_sock_ctrl(BIO *b, int cmd, long num, void *ptr, int close_flag) { long ret = 1; int *ip; switch (cmd) { case BIO_C_SET_FD: mtcp_sock_free(b, close_flag); BIO_set_fd(b, *((int *)ptr), close_flag); BIO_set_shutdown(b, (int)num); BIO_set_init(b, 1); break; case BIO_C_GET_FD: if (BIO_get_init(b)) { ip = (int *)ptr; if (ip != NULL) *ip = BIO_get_fd(b, close_flag); ret = BIO_get_fd(b, close_flag); } else ret = -1; break; case BIO_CTRL_GET_CLOSE: ret = BIO_get_shutdown(b); break; case BIO_CTRL_SET_CLOSE: BIO_set_shutdown(b, (int)num); break; case BIO_CTRL_DUP: case BIO_CTRL_FLUSH: ret = 1; break; default: ret = 0; break; } return (ret); } static int mtcp_sock_puts(BIO *bp, const char *str, int close_flag) { int n, ret; n = strlen(str); ret = mtcp_sock_write(bp, str, n, close_flag); return (ret); } From rsalz at akamai.com Fri Jul 3 12:51:19 2020 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 3 Jul 2020 12:51:19 +0000 Subject: Goodbye Message-ID: <2BB42D63-C53F-4666-B228-5E17EA15C248@akamai.com> * topic: Change some words by accepting PR#12089 * * 4 against, 3 for, no absensions I am at a loss for words. I can?t contribute to a project that feels this way. The OMC (list at [1], a picture of some of them at [2] although it includes non-OMC members) is, in my view, on the wrong side of history. I hope that in time, the four men who voted against it will develop more ? what, empathy? ? and that sometime in the future this PR [3], or similar, will be merged. Until then, I will do what I have to in order to insure that Akamai?s needs for FIPS are met and once 3.0 is released, I will be fully applying my modest talents elsewhere. I have closed all non-FIPS PR?s, and as soon as I see this message in my inbox, I will unsubscribe from this list. I can be reached as rsalz at akamai.com. [1] https://www.openssl.org/community/omc.html [2] https://www.openssl.org/blog/blog/2019/05/23/f2f-committers-day/ [3] https://github.com/openssl/openssl/pull/12089 -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.Roos at f1-outsourcing.eu Fri Jul 3 13:03:07 2020 From: M.Roos at f1-outsourcing.eu (Marc Roos) Date: Fri, 3 Jul 2020 15:03:07 +0200 Subject: Goodbye In-Reply-To: <2BB42D63-C53F-4666-B228-5E17EA15C248@akamai.com> Message-ID: <"H00000710017387b.1593781387.sx.f1-outsourcing.eu*"@MHS> What a non-sense changing these words. Also hypocrite of Akamai, looking at the composition of the executive team. https://www.akamai.com/us/en/about/leadership/executive-team/ https://www.akamai.com/us/en/about/leadership/executive-team/operating-committee.jsp -----Original Message----- To: openssl-users Subject: Goodbye * topic: Change some words by accepting PR#12089 * * 4 against, 3 for, no absensions I am at a loss for words. I can?t contribute to a project that feels this way. The OMC (list at [1], a picture of some of them at [2] although it includes non-OMC members) is, in my view, on the wrong side of history. I hope that in time, the four men who voted against it will develop more ? what, empathy? ? and that sometime in the future this PR [3], or similar, will be merged. Until then, I will do what I have to in order to insure that Akamai?s needs for FIPS are met and once 3.0 is released, I will be fully applying my modest talents elsewhere. I have closed all non-FIPS PR?s, and as soon as I see this message in my inbox, I will unsubscribe from this list. I can be reached as rsalz at akamai.com. [1] https://www.openssl.org/community/omc.html [2] https://www.openssl.org/blog/blog/2019/05/23/f2f-committers-day/ [3] https://github.com/openssl/openssl/pull/12089 From raubvogel at gmail.com Fri Jul 3 13:34:29 2020 From: raubvogel at gmail.com (Mauricio Tavares) Date: Fri, 3 Jul 2020 09:34:29 -0400 Subject: Goodbye In-Reply-To: References: <2BB42D63-C53F-4666-B228-5E17EA15C248@akamai.com> Message-ID: On Fri, Jul 3, 2020 at 9:03 AM Marc Roos wrote: > > > What a non-sense changing these words. Also hypocrite of Akamai, looking > at the composition of the executive team. > > https://www.akamai.com/us/en/about/leadership/executive-team/ > > https://www.akamai.com/us/en/about/leadership/executive-team/operating-committee.jsp > To me it reminds me of the Minitrue RecDep. > > -----Original Message----- > To: openssl-users > Subject: Goodbye > > * topic: Change some words by accepting PR#12089 > > * > > * 4 against, 3 for, no absensions > > > > I am at a loss for words. > > > > I can?t contribute to a project that feels this way. The OMC (list at > [1], a picture of some of them at [2] although it includes non-OMC > members) is, in my view, on the wrong side of history. I hope that in > time, the four men who voted against it will develop more ? what, > empathy? ? and that sometime in the future this PR [3], or similar, > will be merged. Until then, I will do what I have to in order to insure > that Akamai?s needs for FIPS are met and once 3.0 is released, I will > be fully applying my modest talents elsewhere. > > > > I have closed all non-FIPS PR?s, and as soon as I see this message in > my inbox, I will unsubscribe from this list. I can be reached as rsalz > at akamai.com. > > > > [1] https://www.openssl.org/community/omc.html > > [2] https://www.openssl.org/blog/blog/2019/05/23/f2f-committers-day/ > > > [3] https://github.com/openssl/openssl/pull/12089 > > > > > From john.sha.jiang at gmail.com Fri Jul 3 16:18:32 2020 From: john.sha.jiang at gmail.com (John Jiang) Date: Sat, 4 Jul 2020 00:18:32 +0800 Subject: OCSP response signature algorithm Message-ID: Hi, I'm using OpenSSL 1.1.1. Can I configure the OCSP response signature algorithm? For a RSA issuer, it looks SHA256withRSA always be selected. PreferredSignatureAlgorithms extension in OCSP request may affect this algorithm in OpenSSL OCSP response. However, I prefer to use configuration. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at roubekas.org Fri Jul 3 16:58:26 2020 From: paul at roubekas.org (paul h. roubekas) Date: Fri, 3 Jul 2020 12:58:26 -0400 Subject: OCSP response signature algorithm In-Reply-To: References: Message-ID: <03b701d6515b$2bf83950$83e8abf0$@roubekas.org> unsubscribe openssl-users From: openssl-users On Behalf Of John Jiang Sent: Friday, July 3, 2020 12:19 PM To: openssl-users Subject: OCSP response signature algorithm Hi, I'm using OpenSSL 1.1.1. Can I configure the OCSP response signature algorithm? For a RSA issuer, it looks SHA256withRSA always be selected. PreferredSignatureAlgorithms extension in OCSP request may affect this algorithm in OpenSSL OCSP response. However, I prefer to use configuration. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at jordan.maileater.net Fri Jul 3 17:45:22 2020 From: openssl at jordan.maileater.net (Jordan Brown) Date: Fri, 3 Jul 2020 17:45:22 +0000 Subject: Goodbye In-Reply-To: <"H00000710017387b.1593781387.sx.f1-outsourcing.eu*"@MHS> References: <"H00000710017387b.1593781387.sx.f1-outsourcing.eu*"@MHS> Message-ID: <0101017315c86724-7e4a6f98-e65e-4091-b013-791eedc342c8-000000@us-west-2.amazonses.com> On 7/3/2020 6:03 AM, Marc Roos wrote: > Also hypocrite of Akamai, looking at the composition of the executive team. I think it's pretty clear that Rich was speaking as himself, not as a representative of Akamai. -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at denninger.net Fri Jul 3 17:46:59 2020 From: karl at denninger.net (Karl Denninger) Date: Fri, 3 Jul 2020 13:46:59 -0400 Subject: Goodbye In-Reply-To: <0101017315c86724-7e4a6f98-e65e-4091-b013-791eedc342c8-000000@us-west-2.amazonses.com> References: <"H00000710017387b.1593781387.sx.f1-outsourcing.eu*"@MHS> <0101017315c86724-7e4a6f98-e65e-4091-b013-791eedc342c8-000000@us-west-2.amazonses.com> Message-ID: <8c27d23e-0ed0-84b9-8c07-8c4f32c9fc3c@denninger.net> On 7/3/2020 13:45, Jordan Brown wrote: > On 7/3/2020 6:03 AM, Marc Roos wrote: >> Also hypocrite of Akamai, looking at the composition of the executive team. > > I think it's pretty clear that Rich was speaking as himself, not as a > representative of Akamai. > Sorry, that's not how it works. You post and reference a corporate email address, which he did, /you just took the action under the banner of the company./ Akamai is entirely _*and justifiably*_ exposed to being "canceled" on that basis. -- Karl Denninger karl at denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4897 bytes Desc: S/MIME Cryptographic Signature URL: From openssl at jordan.maileater.net Fri Jul 3 18:02:17 2020 From: openssl at jordan.maileater.net (Jordan Brown) Date: Fri, 3 Jul 2020 18:02:17 +0000 Subject: Goodbye In-Reply-To: <8c27d23e-0ed0-84b9-8c07-8c4f32c9fc3c@denninger.net> References: <"H00000710017387b.1593781387.sx.f1-outsourcing.eu*"@MHS> <0101017315c86724-7e4a6f98-e65e-4091-b013-791eedc342c8-000000@us-west-2.amazonses.com> <8c27d23e-0ed0-84b9-8c07-8c4f32c9fc3c@denninger.net> Message-ID: <0101017315d7e645-c6a69c8b-a45a-4cde-8901-176b3db6c16e-000000@us-west-2.amazonses.com> On 7/3/2020 10:46 AM, Karl Denninger wrote: > On 7/3/2020 13:45, Jordan Brown wrote: >> On 7/3/2020 6:03 AM, Marc Roos wrote: >>> Also hypocrite of Akamai, looking at the composition of the executive team. >> I think it's pretty clear that Rich was speaking as himself, not as a >> representative of Akamai. > > Sorry, that's not how it works. > > You post and reference a corporate email address, which he did, /you > just took the action under the banner of the company./ > > Akamai is entirely _*and justifiably*_ exposed to being "canceled" on > that basis. > I don't think that debating that question will be helpful, so I won't. Perhaps I should be absolutely clear:? When I say "I think ...", I am expressing my personal opinion and not the opinion of my employer, Oracle.? I disclose my employer in my signature so as to be totally transparent, not to serve as a spokesperson for the company. (And if anybody is curious, I use one of my personal throw-away addresses so that my work address doesn't get harvested for spam.? If for some reason you'd like verification of my employment, send me e-mail privately and I'll reply from the work address.) -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Jul 3 17:54:25 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 3 Jul 2020 13:54:25 -0400 Subject: Goodbye In-Reply-To: <8c27d23e-0ed0-84b9-8c07-8c4f32c9fc3c@denninger.net> References: <"H00000710017387b.1593781387.sx.f1-outsourcing.eu*"@MHS> <0101017315c86724-7e4a6f98-e65e-4091-b013-791eedc342c8-000000@us-west-2.amazonses.com> <8c27d23e-0ed0-84b9-8c07-8c4f32c9fc3c@denninger.net> Message-ID: <20200703175425.GG38125@straasha.imrryr.org> This is not the appropriate forum for dissecting the personal actions individual contributors. Let's return to OpenSSL- related topics. It would be best if there are no further posts in this thread. -- Viktor. From tincanteksup at gmail.com Sat Jul 4 04:35:30 2020 From: tincanteksup at gmail.com (tincanteksup) Date: Sat, 4 Jul 2020 05:35:30 +0100 Subject: Goodbye In-Reply-To: <2BB42D63-C53F-4666-B228-5E17EA15C248@akamai.com> References: <2BB42D63-C53F-4666-B228-5E17EA15C248@akamai.com> Message-ID: <24b4386a-ee63-1ce3-3a79-75e969e64109@gmail.com> On 03/07/2020 13:51, Salz, Rich via openssl-users wrote: > * topic: Change some words by accepting PR#12089 > > * > > * 4 against, 3 for, no absensions > > I am at a loss for words. > > I can?t contribute to a project that feels this way. The OMC (list at [1], a picture of some of them at [2] although it includes non-OMC members) is, in my view, on the wrong side of history. I hope that in time, the four men who voted against it will develop more ? what, empathy? ? and that sometime in the future this PR [3], or similar, will be merged. Until then, I will do what I have to in order to insure that Akamai?s needs for FIPS are met and once 3.0 is released, I will be fully applying my modest talents elsewhere. > > I have closed all non-FIPS PR?s, and as soon as I see this message in my inbox, I will unsubscribe from this list. I can be reached as rsalz at akamai.com. > > [1] https://www.openssl.org/community/omc.html > [2] https://www.openssl.org/blog/blog/2019/05/23/f2f-committers-day/ > [3] https://github.com/openssl/openssl/pull/12089 > Democracy .. it's not every-bodies cup of tea. Remember: Sticks and stones may break my bones but WORDS will never hurt me. From tincanteksup at gmail.com Sat Jul 4 05:14:10 2020 From: tincanteksup at gmail.com (tincanteksup) Date: Sat, 4 Jul 2020 06:14:10 +0100 Subject: Goodbye In-Reply-To: <24b4386a-ee63-1ce3-3a79-75e969e64109@gmail.com> References: <2BB42D63-C53F-4666-B228-5E17EA15C248@akamai.com> <24b4386a-ee63-1ce3-3a79-75e969e64109@gmail.com> Message-ID: <8d0a8a9f-66aa-34d6-b515-8412c594f5d5@gmail.com> If you are lucky .. enjoy your 4th Most of us are not so lucky .. From nico at cryptonector.com Sat Jul 4 05:41:24 2020 From: nico at cryptonector.com (Nico Williams) Date: Sat, 4 Jul 2020 00:41:24 -0500 Subject: Goodbye In-Reply-To: <0101017315c86724-7e4a6f98-e65e-4091-b013-791eedc342c8-000000@us-west-2.amazonses.com> References: <"H00000710017387b.1593781387.sx.f1-outsourcing.eu*"@MHS> <0101017315c86724-7e4a6f98-e65e-4091-b013-791eedc342c8-000000@us-west-2.amazonses.com> Message-ID: <20200704054121.GN3080@localhost> On Fri, Jul 03, 2020 at 05:45:22PM +0000, Jordan Brown wrote: > On 7/3/2020 6:03 AM, Marc Roos wrote: > > Also hypocrite of Akamai, looking at the composition of the executive team. > > I think it's pretty clear that Rich was speaking as himself, not as a > representative of Akamai. Hi Jordan, It's pretty clear that Rich was insinuating that the OMC are a bunch of racists, and that they should be canceled. He didn't _say_ it, but strongly implied it, or at least that was the message received by some. It's fair to suppose it was the intended message. And Rich specifically referred to his employer, not in his signature as you refer to yours, but in the text of his post. No, Rich did not say his words and actions represent Akamai, but still, he referred to Akamai specifically. More about this below. The OMC is staffed by real people, with real families, and the disagreement here did not rise to the point where one should dox the OMC members and imply that their employers should terminate their employment. They do not deserve what Rich implies. I know one of them well, one who voted against Rich's PR, and I assure you he's no racist. Rich didn't care to be polite. No! He meant to _provoke_, and not just replies like Marc's, but actual action against the OMC's members. I won't call out Akamai on account of Rich's behavior because I don't want to do what he did, but I don't blame anyone else for doing it -- Rich made it fair game by doing it first. But we must call out behavior like Rich's -- it's simply not acceptable. Nico -- From lear at ofcourseimright.com Sat Jul 4 06:08:53 2020 From: lear at ofcourseimright.com (Eliot Lear) Date: Sat, 4 Jul 2020 08:08:53 +0200 Subject: Goodbye In-Reply-To: <20200704054121.GN3080@localhost> References: <"H00000710017387b.1593781387.sx.f1-outsourcing.eu*"@MHS> <0101017315c86724-7e4a6f98-e65e-4091-b013-791eedc342c8-000000@us-west-2.amazonses.com> <20200704054121.GN3080@localhost> Message-ID: <67d185ea-351a-5dda-7e43-399a7e6e0b50@ofcourseimright.com> Can we please put the knives a way?? Rich has given a lot to this community.? As an openssl user, I'd rather the conversation moved along. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dank at kegel.com Sat Jul 4 15:35:33 2020 From: dank at kegel.com (Dan Kegel) Date: Sat, 4 Jul 2020 08:35:33 -0700 Subject: Goodbye In-Reply-To: <67d185ea-351a-5dda-7e43-399a7e6e0b50@ofcourseimright.com> References: <"H00000710017387b.1593781387.sx.f1-outsourcing.eu*"@MHS> <0101017315c86724-7e4a6f98-e65e-4091-b013-791eedc342c8-000000@us-west-2.amazonses.com> <20200704054121.GN3080@localhost> <67d185ea-351a-5dda-7e43-399a7e6e0b50@ofcourseimright.com> Message-ID: Likewise. Thank you, Rich! When this issue came up in Buildbot 5 years ago, there was a fair bit of... discussion, see http://trac.buildbot.net/ticket/2340 The resolution back then was to rename 'slave' to 'worker', which was a LOT of work, and seemed to satisfy everybody at the time. It came up again recently, see https://github.com/buildbot/buildbot/issues/5382 and they're now looking at whether and how to address the word 'master'. Not having noticed this discussion in openssl until today, here's my two cents as an openssl user: I think an incremental approach is fine, clean up the most offensive word or two first, and then see where things land. And if it can't start immediately, that's ok, it took buildbot a while to come up with the needed consensus and elbow grease. - Dan On Fri, Jul 3, 2020 at 11:10 PM Eliot Lear wrote: > Can we please put the knives a way? Rich has given a lot to this > community. As an openssl user, I'd rather the conversation moved along. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From don_sfw at dlaster.com Sat Jul 4 17:45:08 2020 From: don_sfw at dlaster.com (Donald R Laster Jr) Date: Sat, 4 Jul 2020 13:45:08 -0400 Subject: Goodbye In-Reply-To: References: <"H00000710017387b.1593781387.sx.f1-outsourcing.eu*"@MHS> <0101017315c86724-7e4a6f98-e65e-4091-b013-791eedc342c8-000000@us-west-2.amazonses.com> <20200704054121.GN3080@localhost> <67d185ea-351a-5dda-7e43-399a7e6e0b50@ofcourseimright.com> Message-ID: <82aacc20-968d-19ab-5b2b-ed9bedfc8cf7@dlaster.com> Having just noticed the last 4 or 5 emails related to this thread I have to say this is classic political correctness garbage. Don Dan Kegel wrote on 07/04/2020 11:35 AM: > Likewise.? Thank you, Rich! > > When this issue came up in Buildbot 5 years ago, there was a fair bit of... discussion, see > http://trac.buildbot.net/ticket/2340 > The resolution back then was to rename 'slave' to 'worker', which was a LOT of > work, and seemed to satisfy everybody at the time. > It came up again recently, see > https://github.com/buildbot/buildbot/issues/5382 > and they're now looking at whether and how to address the word 'master'. > > Not having noticed this discussion in openssl until today, here's my two cents as an openssl user: > I think an incremental approach is fine, clean up the most offensive word or two > first, and then see where things land.? And if it can't start immediately, that's > ok, it took buildbot a while to come up with the needed consensus and > elbow grease. > - Dan > > > > On Fri, Jul 3, 2020 at 11:10 PM Eliot Lear > wrote: > > Can we please put the knives a way?? Rich has given a lot to this > community.? As an openssl user, I'd rather the conversation moved along. > > > -- ============================================================== Donald R. Laster Jr. 25 Heidl Ave West Long Branch, NJ 07764 Email : laster at dlaster.com donaldrlasterjr at gmail.com (Cell) Phone : (732) 263-9235 (Home Evening) (732) 263-9236 (Home Office) (732) 539-5658 (Cell) (732) 263-9280 (Fax) -------------------------------------------------------------- Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln ============================================================== From dank at kegel.com Sat Jul 4 18:09:58 2020 From: dank at kegel.com (Dan Kegel) Date: Sat, 4 Jul 2020 11:09:58 -0700 Subject: Goodbye In-Reply-To: <82aacc20-968d-19ab-5b2b-ed9bedfc8cf7@dlaster.com> References: <"H00000710017387b.1593781387.sx.f1-outsourcing.eu*"@MHS> <0101017315c86724-7e4a6f98-e65e-4091-b013-791eedc342c8-000000@us-west-2.amazonses.com> <20200704054121.GN3080@localhost> <67d185ea-351a-5dda-7e43-399a7e6e0b50@ofcourseimright.com> <82aacc20-968d-19ab-5b2b-ed9bedfc8cf7@dlaster.com> Message-ID: It might be worth reminding folks of https://www.openssl.org/community/conduct.html which says "We strive to be an open and inclusive community where anyone can contribute." - Dan On Sat, Jul 4, 2020 at 11:02 AM Donald R Laster Jr wrote: > > Having just noticed the last 4 or 5 emails related to this thread I have > to say this is classic political correctness garbage. > Don > > Dan Kegel wrote on 07/04/2020 11:35 AM: > > Likewise. Thank you, Rich! > > > > When this issue came up in Buildbot 5 years ago, there was a fair bit > of... discussion, see > > http://trac.buildbot.net/ticket/2340 > > The resolution back then was to rename 'slave' to 'worker', which was a > LOT of > > work, and seemed to satisfy everybody at the time. > > It came up again recently, see > > https://github.com/buildbot/buildbot/issues/5382 > > and they're now looking at whether and how to address the word 'master'. > > > > Not having noticed this discussion in openssl until today, here's my two > cents as an openssl user: > > I think an incremental approach is fine, clean up the most offensive > word or two > > first, and then see where things land. And if it can't start > immediately, that's > > ok, it took buildbot a while to come up with the needed consensus and > > elbow grease. > > - Dan > > > > > > > > On Fri, Jul 3, 2020 at 11:10 PM Eliot Lear > wrote: > > > > Can we please put the knives a way? Rich has given a lot to this > > community. As an openssl user, I'd rather the conversation moved > along. > > > > > > > > -- > ============================================================== > > Donald R. Laster Jr. > 25 Heidl Ave > West Long Branch, NJ 07764 > > Email : laster at dlaster.com > donaldrlasterjr at gmail.com (Cell) > > Phone : (732) 263-9235 (Home Evening) > (732) 263-9236 (Home Office) > (732) 539-5658 (Cell) > (732) 263-9280 (Fax) > > -------------------------------------------------------------- > > Nearly all men can stand adversity, but if you want to test > a man's character, give him power. -- Abraham Lincoln > > ============================================================== > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shinelight at shininglightpro.com Sat Jul 4 18:10:33 2020 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Sat, 4 Jul 2020 11:10:33 -0700 Subject: Goodbye In-Reply-To: <2BB42D63-C53F-4666-B228-5E17EA15C248@akamai.com> References: <2BB42D63-C53F-4666-B228-5E17EA15C248@akamai.com> Message-ID: <3ca2f3e0-d3ab-73df-0922-b468c14b77fa@shininglightpro.com> Rich, I just want to wish you well on your future endeavors. You've got valuable skills as a software developer. Hopefully whatever negative experiences you've recently encountered won't dissuade you from contributing to open source projects in the future. There are, after all, an infinite number of exciting things to still be done in software. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From openssl-users at dukhovni.org Sat Jul 4 18:12:46 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 4 Jul 2020 14:12:46 -0400 Subject: Goodbye In-Reply-To: References: <"H00000710017387b.1593781387.sx.f1-outsourcing.eu*"@MHS> <0101017315c86724-7e4a6f98-e65e-4091-b013-791eedc342c8-000000@us-west-2.amazonses.com> <20200704054121.GN3080@localhost> <67d185ea-351a-5dda-7e43-399a7e6e0b50@ofcourseimright.com> <82aacc20-968d-19ab-5b2b-ed9bedfc8cf7@dlaster.com> Message-ID: <20200704181246.GI38125@straasha.imrryr.org> The issue is moot for now, let's move on. -- Viktor. From phill at hallambaker.com Sat Jul 4 19:12:15 2020 From: phill at hallambaker.com (Phillip Hallam-Baker) Date: Sat, 4 Jul 2020 15:12:15 -0400 Subject: Goodbye In-Reply-To: <82aacc20-968d-19ab-5b2b-ed9bedfc8cf7@dlaster.com> References: <"H00000710017387b.1593781387.sx.f1-outsourcing.eu*"@MHS> <0101017315c86724-7e4a6f98-e65e-4091-b013-791eedc342c8-000000@us-west-2.amazonses.com> <20200704054121.GN3080@localhost> <67d185ea-351a-5dda-7e43-399a7e6e0b50@ofcourseimright.com> <82aacc20-968d-19ab-5b2b-ed9bedfc8cf7@dlaster.com> Message-ID: For many people involved in developing cryptographic infrastructures, politics are a major concern. Getting the politics correct is important. The true power in this world lies in shaping what people believe. What my friend Joe Nye calls 'soft power'. To suggest that choice of language is irrelevant is ill-informed to sneer at it is plain stupid. On Sat, Jul 4, 2020 at 1:46 PM Donald R Laster Jr wrote: > > Having just noticed the last 4 or 5 emails related to this thread I have > to say this is classic political correctness garbage. > Don > > Dan Kegel wrote on 07/04/2020 11:35 AM: > > Likewise. Thank you, Rich! > > > > When this issue came up in Buildbot 5 years ago, there was a fair bit > of... discussion, see > > http://trac.buildbot.net/ticket/2340 > > The resolution back then was to rename 'slave' to 'worker', which was a > LOT of > > work, and seemed to satisfy everybody at the time. > > It came up again recently, see > > https://github.com/buildbot/buildbot/issues/5382 > > and they're now looking at whether and how to address the word 'master'. > > > > Not having noticed this discussion in openssl until today, here's my two > cents as an openssl user: > > I think an incremental approach is fine, clean up the most offensive > word or two > > first, and then see where things land. And if it can't start > immediately, that's > > ok, it took buildbot a while to come up with the needed consensus and > > elbow grease. > > - Dan > > > > > > > > On Fri, Jul 3, 2020 at 11:10 PM Eliot Lear > wrote: > > > > Can we please put the knives a way? Rich has given a lot to this > > community. As an openssl user, I'd rather the conversation moved > along. > > > > > > > > -- > ============================================================== > > Donald R. Laster Jr. > 25 Heidl Ave > West Long Branch, NJ 07764 > > Email : laster at dlaster.com > donaldrlasterjr at gmail.com (Cell) > > Phone : (732) 263-9235 (Home Evening) > (732) 263-9236 (Home Office) > (732) 539-5658 (Cell) > (732) 263-9280 (Fax) > > -------------------------------------------------------------- > > Nearly all men can stand adversity, but if you want to test > a man's character, give him power. -- Abraham Lincoln > > ============================================================== > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frans at fransdb.nl Sat Jul 4 19:13:31 2020 From: frans at fransdb.nl (Frans de Boer) Date: Sat, 4 Jul 2020 21:13:31 +0200 Subject: Goodbye In-Reply-To: <2BB42D63-C53F-4666-B228-5E17EA15C248@akamai.com> References: <2BB42D63-C53F-4666-B228-5E17EA15C248@akamai.com> Message-ID: <2d474510-09b2-d329-1161-b133434223e1@fransdb.nl> On 03-07-2020 14:51, Salz, Rich via openssl-users wrote: > > * topic:?Change some words by accepting PR#12089 > > * > > * 4 against, 3 for, no absensions > > I am at a loss for words. > > I can?t contribute to a project that feels this way.? The OMC (list at > [1], a picture of some of them at [2] although it includes non-OMC > members) is, in my view, on the wrong side of history. I hope that in > time, the four men who voted against it will develop more ? what, > empathy? ? and that sometime in the future this PR [3], or similar, > will be merged.? Until then, I will do what I have to in order to > insure that Akamai?s needs for FIPS are met and once 3.0 is released, > I will be fully applying my modest talents elsewhere. > > I have closed all non-FIPS PR?s, and as soon as I see this message in > my inbox, I will unsubscribe from this list. I can be reached as rsalz > at akamai.com. > > [1] https://www.openssl.org/community/omc.html > > [2] https://www.openssl.org/blog/blog/2019/05/23/f2f-committers-day/ > > [3] https://github.com/openssl/openssl/pull/12089 > > What is next, attack the jing/jang colors or renaming the night from black to colorless? I think this black/white or master/slave thing is blowing things out of proportion. Humans have all kind of colors, including colorless and white. And when I think of master/slave, it is just a principle - something is controlling something else. That there was a period where white people controlled the fate of "black" people is a colorless period in human history. Which should not be forgotten, but remembered as a period with lots of wrong doing to other human beings. I understand that white people should not talk about "negros" or the like, but colorless people think they can still us this awful word. Now, who is dictating who? Don't do/say things you would not have it from others to yourself. Black is not negative by definition, it is what your mind associate it with. --- Frans. -- A: Yes, just like that A: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.heimlich at gmail.com Sat Jul 4 19:23:37 2020 From: matt.heimlich at gmail.com (Matthew Heimlich) Date: Sat, 4 Jul 2020 15:23:37 -0400 Subject: Goodbye In-Reply-To: <2BB42D63-C53F-4666-B228-5E17EA15C248@akamai.com> References: <2BB42D63-C53F-4666-B228-5E17EA15C248@akamai.com> Message-ID: I see a lot of slippery slope fallacy in this thread. A small verbiage change that hurts almost no one but increases inclusivity in an open source project shouldn't be controversial to anyone but those who have an ax to grind. On Fri, Jul 3, 2020, 8:51 AM Salz, Rich via openssl-users < openssl-users at openssl.org> wrote: > > - topic: Change some words by accepting PR#12089 > > > - > > > - 4 against, 3 for, no absensions > > > > I am at a loss for words. > > > > I can?t contribute to a project that feels this way. The OMC (list at > [1], a picture of some of them at [2] although it includes non-OMC members) > is, in my view, on the wrong side of history. I hope that in time, the four > men who voted against it will develop more ? what, empathy? ? and that > sometime in the future this PR [3], or similar, will be merged. Until > then, I will do what I have to in order to insure that Akamai?s needs for > FIPS are met and once 3.0 is released, I will be fully applying my modest > talents elsewhere. > > > > I have closed all non-FIPS PR?s, and as soon as I see this message in my > inbox, I will unsubscribe from this list. I can be reached as rsalz at > akamai.com. > > > > [1] https://www.openssl.org/community/omc.html > > [2] https://www.openssl.org/blog/blog/2019/05/23/f2f-committers-day/ > > [3] https://github.com/openssl/openssl/pull/12089 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sat Jul 4 19:26:56 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 4 Jul 2020 15:26:56 -0400 Subject: Goodbye In-Reply-To: References: <"H00000710017387b.1593781387.sx.f1-outsourcing.eu*"@MHS> <0101017315c86724-7e4a6f98-e65e-4091-b013-791eedc342c8-000000@us-west-2.amazonses.com> <20200704054121.GN3080@localhost> <67d185ea-351a-5dda-7e43-399a7e6e0b50@ofcourseimright.com> <82aacc20-968d-19ab-5b2b-ed9bedfc8cf7@dlaster.com> Message-ID: <20200704192656.GK38125@straasha.imrryr.org> On Sat, Jul 04, 2020 at 03:12:15PM -0400, Phillip Hallam-Baker wrote: > To suggest that choice of language is irrelevant is ill-informed to > sneer at it is plain stupid. Let's avoid name calling (and while were' at it, actually close this unproductive thread). -- VIktor. From dank at kegel.com Sat Jul 4 19:38:55 2020 From: dank at kegel.com (Dan Kegel) Date: Sat, 4 Jul 2020 12:38:55 -0700 Subject: Goodbye In-Reply-To: <7e568beb-bd3a-b857-1b8b-34b05249eac7@dlaster.com> References: <"H00000710017387b.1593781387.sx.f1-outsourcing.eu*"@MHS> <0101017315c86724-7e4a6f98-e65e-4091-b013-791eedc342c8-000000@us-west-2.amazonses.com> <20200704054121.GN3080@localhost> <67d185ea-351a-5dda-7e43-399a7e6e0b50@ofcourseimright.com> <82aacc20-968d-19ab-5b2b-ed9bedfc8cf7@dlaster.com> <7e568beb-bd3a-b857-1b8b-34b05249eac7@dlaster.com> Message-ID: There's nothing wrong with being inclusive. Buildbot was not harmed by removing the word 'slave' from its codebase. - Dan On Sat, Jul 4, 2020 at 12:33 PM Donald R Laster Jr wrote: > Dan, > > The words "slave" and "master" have no negative or positive > connotations in relation to software or even hardware. They are simply > description of the purpose/function of the software or hardware. > > As I said this is nothing but classic political correctness. People > need to stop being offended at things which are not offensive. This is no > different than someone getting offended at the use of the words "servant" > and "master", or "boss" and "employee", or "parent" and "child". Changing > the software and documentation simply because someone does not like the use > of appropriate terms is a waste of time. And likely to create problems in > the future due to changes that serve no purpose. > > Don > > Dan Kegel wrote on 07/04/2020 02:09 PM: > > It might be worth reminding folks of > > https://www.openssl.org/community/conduct.html > > which says > > "We strive to be an open and inclusive community where anyone can > contribute." > > - Dan > > > > > > On Sat, Jul 4, 2020 at 11:02 AM Donald R Laster Jr > wrote: > > > > > > Having just noticed the last 4 or 5 emails related to this thread I > have to say this is classic political correctness garbage. > > Don > > > > Dan Kegel wrote on 07/04/2020 11:35 AM: > > > Likewise. Thank you, Rich! > > > > > > When this issue came up in Buildbot 5 years ago, there was a fair > bit of... discussion, see > > > http://trac.buildbot.net/ticket/2340 > > > The resolution back then was to rename 'slave' to 'worker', which > was a LOT of > > > work, and seemed to satisfy everybody at the time. > > > It came up again recently, see > > > https://github.com/buildbot/buildbot/issues/5382 > > > and they're now looking at whether and how to address the word > 'master'. > > > > > > Not having noticed this discussion in openssl until today, here's > my two cents as an openssl user: > > > I think an incremental approach is fine, clean up the most > offensive word or two > > > first, and then see where things land. And if it can't start > immediately, that's > > > ok, it took buildbot a while to come up with the needed consensus > and > > > elbow grease. > > > - Dan > > > > > > > > > > > > On Fri, Jul 3, 2020 at 11:10 PM Eliot Lear < > lear at ofcourseimright.com lear at ofcourseimright.com >> wrote: > > > > > > Can we please put the knives a way? Rich has given a lot to > this > > > community. As an openssl user, I'd rather the conversation > moved along. > > > > > > > > > > > > > -- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sat Jul 4 19:45:06 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 4 Jul 2020 15:45:06 -0400 Subject: [THREAD CLOSED] Re: Goodbye In-Reply-To: References: <"H00000710017387b.1593781387.sx.f1-outsourcing.eu*"@MHS> <0101017315c86724-7e4a6f98-e65e-4091-b013-791eedc342c8-000000@us-west-2.amazonses.com> <20200704054121.GN3080@localhost> <67d185ea-351a-5dda-7e43-399a7e6e0b50@ofcourseimright.com> <82aacc20-968d-19ab-5b2b-ed9bedfc8cf7@dlaster.com> <7e568beb-bd3a-b857-1b8b-34b05249eac7@dlaster.com> Message-ID: <20200704194506.GL38125@straasha.imrryr.org> On Sat, Jul 04, 2020 at 12:38:55PM -0700, Dan Kegel wrote: > There's nothing wrong with being inclusive. Buildbot > was not harmed by removing the word 'slave' from > its codebase. In case it is not yet abundantly clear, social justince discussions are off-topic for this list. Please stop. If this thread does not die down soon, we may have start unsubscribing offenders. -- Viktor. From doctor at doctor.nl2k.ab.ca Sat Jul 4 19:48:27 2020 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 4 Jul 2020 13:48:27 -0600 Subject: FTP server Message-ID: <20200704194827.GA33154@doctor.nl2k.ab.ca> Have there been stablility issues lately? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b The highest result of education is tolerance. -Helen Keller From kurt at roeckx.be Sat Jul 4 19:53:30 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 4 Jul 2020 21:53:30 +0200 Subject: Goodbye In-Reply-To: <2BB42D63-C53F-4666-B228-5E17EA15C248@akamai.com> References: <2BB42D63-C53F-4666-B228-5E17EA15C248@akamai.com> Message-ID: <20200704195330.GA289912@roeckx.be> On Fri, Jul 03, 2020 at 12:51:19PM +0000, Salz, Rich via openssl-users wrote: > * topic: Change some words by accepting PR#12089 > > * > > * 4 against, 3 for, no absensions > > I am at a loss for words. > > I can?t contribute to a project that feels this way. I would like to point out that the only thing that was voted on was to accept the pull request as a whole. A new pull request that removes the word slave has made and has been approved. Kurt From matt at openssl.org Sat Jul 4 21:06:54 2020 From: matt at openssl.org (Matt Caswell) Date: Sat, 4 Jul 2020 22:06:54 +0100 Subject: FTP server In-Reply-To: <20200704194827.GA33154@doctor.nl2k.ab.ca> References: <20200704194827.GA33154@doctor.nl2k.ab.ca> Message-ID: <7ef8a5a9-a7d5-4019-1ea3-044a0195509e@openssl.org> The infrastructure was upgraded on Thursday and so things were down for a while. Should all be back to normal now. If there are still problems then let us know. Matt On 04/07/2020 20:48, The Doctor wrote: > Have there been stablility issues lately? > From levitte at openssl.org Sat Jul 4 21:35:28 2020 From: levitte at openssl.org (Richard Levitte) Date: Sat, 04 Jul 2020 23:35:28 +0200 Subject: FTP server In-Reply-To: <7ef8a5a9-a7d5-4019-1ea3-044a0195509e@openssl.org> References: <20200704194827.GA33154@doctor.nl2k.ab.ca> <7ef8a5a9-a7d5-4019-1ea3-044a0195509e@openssl.org> Message-ID: <87blkvhskf.wl-levitte@openssl.org> Hmmm... I can see issues over IPv4 from my laptop, but it works flawlessly over iPv6, as well as from the VMS machines I've access to (over IPv4). Not sure what's going on there. The Doctor, would you mind telling us what's going on on your end? Cheers, Richard On Sat, 04 Jul 2020 23:06:54 +0200, Matt Caswell wrote: > > The infrastructure was upgraded on Thursday and so things were down for > a while. Should all be back to normal now. If there are still problems > then let us know. > > Matt > > On 04/07/2020 20:48, The Doctor wrote: > > Have there been stablility issues lately? > > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From doctor at doctor.nl2k.ab.ca Sat Jul 4 22:40:02 2020 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 4 Jul 2020 16:40:02 -0600 Subject: FTP server In-Reply-To: <87blkvhskf.wl-levitte@openssl.org> References: <20200704194827.GA33154@doctor.nl2k.ab.ca> <7ef8a5a9-a7d5-4019-1ea3-044a0195509e@openssl.org> <87blkvhskf.wl-levitte@openssl.org> Message-ID: <20200704224002.GA61122@doctor.nl2k.ab.ca> On Sat, Jul 04, 2020 at 11:35:28PM +0200, Richard Levitte wrote: > Hmmm... I can see issues over IPv4 from my laptop, but it works > flawlessly over iPv6, as well as from the VMS machines I've access to > (over IPv4). Not sure what's going on there. > > The Doctor, would you mind telling us what's going on on your end? > > Cheers, > Richard > > On Sat, 04 Jul 2020 23:06:54 +0200, > Matt Caswell wrote: > > > > The infrastructure was upgraded on Thursday and so things were down for > > a while. Should all be back to normal now. If there are still problems > > then let us know. > > > > Matt > > > > On 04/07/2020 20:48, The Doctor wrote: > > > Have there been stablility issues lately? > > > > > Iand here is a message 194.97.150.234:5908 It the IP and port it is tryingto connect to. Also, why are the http snapshots a day off? > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b The highest result of education is tolerance. -Helen Keller From levitte at openssl.org Sun Jul 5 12:04:15 2020 From: levitte at openssl.org (Richard Levitte) Date: Sun, 05 Jul 2020 14:04:15 +0200 Subject: FTP server In-Reply-To: <87blkvhskf.wl-levitte@openssl.org> References: <20200704194827.GA33154@doctor.nl2k.ab.ca> <7ef8a5a9-a7d5-4019-1ea3-044a0195509e@openssl.org> <87blkvhskf.wl-levitte@openssl.org> Message-ID: <87a70ei2ww.wl-levitte@openssl.org> Fixed! On Sat, 04 Jul 2020 23:35:28 +0200, Richard Levitte wrote: > > Hmmm... I can see issues over IPv4 from my laptop, but it works > flawlessly over iPv6, as well as from the VMS machines I've access to > (over IPv4). Not sure what's going on there. > > The Doctor, would you mind telling us what's going on on your end? > > Cheers, > Richard > > On Sat, 04 Jul 2020 23:06:54 +0200, > Matt Caswell wrote: > > > > The infrastructure was upgraded on Thursday and so things were down for > > a while. Should all be back to normal now. If there are still problems > > then let us know. > > > > Matt > > > > On 04/07/2020 20:48, The Doctor wrote: > > > Have there been stablility issues lately? > > > > > > -- > 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 doctor at doctor.nl2k.ab.ca Sun Jul 5 12:07:25 2020 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sun, 5 Jul 2020 06:07:25 -0600 Subject: FTP server In-Reply-To: <87a70ei2ww.wl-levitte@openssl.org> References: <20200704194827.GA33154@doctor.nl2k.ab.ca> <7ef8a5a9-a7d5-4019-1ea3-044a0195509e@openssl.org> <87blkvhskf.wl-levitte@openssl.org> <87a70ei2ww.wl-levitte@openssl.org> Message-ID: <20200705120725.GA57842@doctor.nl2k.ab.ca> On Sun, Jul 05, 2020 at 02:04:15PM +0200, Richard Levitte wrote: > Fixed! > > On Sat, 04 Jul 2020 23:35:28 +0200, > Richard Levitte wrote: > > > > Hmmm... I can see issues over IPv4 from my laptop, but it works > > flawlessly over iPv6, as well as from the VMS machines I've access to > > (over IPv4). Not sure what's going on there. > > > > The Doctor, would you mind telling us what's going on on your end? > > > > Cheers, > > Richard > > > > On Sat, 04 Jul 2020 23:06:54 +0200, > > Matt Caswell wrote: > > > > > > The infrastructure was upgraded on Thursday and so things were down for > > > a while. Should all be back to normal now. If there are still problems > > > then let us know. > > > > > > Matt > > > > > > On 04/07/2020 20:48, The Doctor wrote: > > > > Have there been stablility issues lately? > > > > > > > Oh! Still having issues. > > -- > > 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/ -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b The highest result of education is tolerance. -Helen Keller From john.sha.jiang at gmail.com Sun Jul 5 22:15:30 2020 From: john.sha.jiang at gmail.com (John Jiang) Date: Mon, 6 Jul 2020 06:15:30 +0800 Subject: OCSP response signature algorithm In-Reply-To: References: Message-ID: I just want to know how does OpenSSL implement RFC 6960 section 4.4.7.2 Responder Signature Algorithm Selection. Could I take a OpenSSL responder to use SHA1withRSA signature algorithm if the certificate is signed by this algorithm? [1] https://tools.ietf.org/html/rfc6960#section-4.4.7.2 On Sat, Jul 4, 2020 at 12:18 AM John Jiang wrote: > Hi, > I'm using OpenSSL 1.1.1. > > Can I configure the OCSP response signature algorithm? > For a RSA issuer, it looks SHA256withRSA always be selected. > > PreferredSignatureAlgorithms extension in OCSP request may affect this > algorithm in OpenSSL OCSP response. However, I prefer to use configuration. > > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbespalov at idirect.net Mon Jul 6 22:19:23 2020 From: kbespalov at idirect.net (Bespalov, Kyryl) Date: Mon, 6 Jul 2020 22:19:23 +0000 Subject: openSSL and mongoose logging Message-ID: Hey everyone, I need some help enabling traces in openSSL library. I also need to find out how to enable to the cry() method logging in ./Third_Part/mongoose mongoose.c file. Any help would be greatly appreciated. Thank you, Kyryl. This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shirisha.dasari at broadcom.com Tue Jul 7 05:36:17 2020 From: shirisha.dasari at broadcom.com (Shirisha Dasari) Date: Tue, 7 Jul 2020 11:06:17 +0530 Subject: OpenSSL shared library in FIPS mode Message-ID: Hi All, We have been trying to integrate FOM 2.0.13 with OpenSSL 1.0.2u for FIPS compliance. Post integration, we have been able to run in FIPS mode, with all self-tests passing as well. However, we seem to be encountering issues in creation and parsing of ECDSA keys. A little background on how we build the shared libcrypto library: TARGET: x86_64 BUILD HOST: x86_64 We do not use the OpenSSL Makefile to build the OpenSSL source. Our build infrastructure creates multiple static archives from the OpenSSL crypto source and finally creates a libcrypto.a from these archives as required by fipsld. The fipscanister.o and libcrypto.a are archived to create the final libcrypto.a and passed onto fipsld for creation of a dynamic library, libcrypto.so. fips_premain_dso gets built as a part of the build process too for generation of signature. These steps mimic the OpenSSL opensource Makefile. fipsld embeds the signature into the final libcrypto.so successfully and we are able to get into FIPS mode successfully at run time. Self-tests pass as well. Issue: While trying to use ECDSA host keys for OpenSSH, we noticed that parsing of ECDSA key fails. DSA and RSA key creation and parsing do not have this issue. Note that the ECDSA key was generated in FIPS mode and is being parsed in FIPS mode itself. root at localhost:/home/admin# openssl ec -in ssh_host_key_ecdsa -text -noout read EC key unable to load Key 140020611143360:error:10067066:elliptic curve routines:ec_GFp_simple_oct2point:invalid encoding:../../../../vendor/openssl-fips/crypto/ec/ecp_oct.c:370: 140020611143360:error:10092010:elliptic curve routines:d2i_ECPrivateKey:EC lib:../../../../vendor/openssl-fips/crypto/ec/ec_asn1.c:1172: 140020611143360:error:100D508E:elliptic curve routines:ECKEY_PRIV_DECODE:decode error:../../../../vendor/openssl-fips/crypto/ec/ec_ameth.c:256: 140020611143360:error:0606F091:digital envelope routines:EVP_PKCS82PKEY:private key decode error:../../../../vendor/openssl-fips/crypto/evp/evp_pkey.c:92: 140020611143360:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1 lib:../../../../vendor/openssl-fips/crypto/pem/pem_pkey.c:142: root at localhost:/home/admin# A portion of the sample ECDSA key generated with curve secp384r1 via ssh-keygen with "ssh-keygen -t ecdsa -b 384 -f ssh_host_key_ecdsa" is provided below: -----BEGIN PRIVATE KEY----- MIG2AgEAMBAGByqGSM49AgEGBSuBBAAiBIGeMIGbAgEBBDD ........ ........ -----END PRIVATE KEY----- A few questions related to this: 1) Is there a specific need to build the OpenSSL source only via the provided Makefile? 2) FIPS self test for ECDSA passes but the key creation/parsing fails. Could this indicate that the FIPS module APIs are not getting invoked in the case of ECDSA? -- Thanks & Regards, Shirisha. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Tue Jul 7 07:47:35 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Tue, 7 Jul 2020 17:47:35 +1000 Subject: OpenSSL shared library in FIPS mode In-Reply-To: References: Message-ID: <691867E4-B3E3-48EE-8330-68E9E0EF2789@oracle.com> OpenSSL 1.0.2 ceased being supported at the beginning of this year. If you are deviating in any way from the prescribed build instructions (you did read the security policy didn?t you?) you are not FIPS compliant. Not using the OpenSSL Makefile is such a deviation. My suspicion is that you are not and never have been FIPS compliant. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 7 Jul 2020, at 3:36 pm, Shirisha Dasari via openssl-users wrote: > > Hi All, > > We have been trying to integrate FOM 2.0.13 with OpenSSL 1.0.2u for FIPS compliance. Post integration, we have been able to run in FIPS mode, with all self-tests passing as well. However, we seem to be encountering issues in creation and parsing of ECDSA keys. > > A little background on how we build the shared libcrypto library: > > TARGET: x86_64 > BUILD HOST: x86_64 > > We do not use the OpenSSL Makefile to build the OpenSSL source. Our build infrastructure creates multiple static archives from the OpenSSL crypto source and finally creates a libcrypto.a from these archives as required by fipsld. The fipscanister.o and libcrypto.a are archived to create the final libcrypto.a and passed onto fipsld for creation of a dynamic library, libcrypto.so. fips_premain_dso gets built as a part of the build process too for generation of signature. These steps mimic the OpenSSL opensource Makefile. > > fipsld embeds the signature into the final libcrypto.so successfully and we are able to get into FIPS mode successfully at run time. Self-tests pass as well. > > Issue: > > While trying to use ECDSA host keys for OpenSSH, we noticed that parsing of ECDSA key fails. DSA and RSA key creation and parsing do not have this issue. Note that the ECDSA key was generated in FIPS mode and is being parsed in FIPS mode itself. > > root at localhost:/home/admin# openssl ec -in ssh_host_key_ecdsa -text -noout > read EC key > unable to load Key > 140020611143360:error:10067066:elliptic curve routines:ec_GFp_simple_oct2point:invalid encoding:../../../../vendor/openssl-fips/crypto/ec/ecp_oct.c:370: > 140020611143360:error:10092010:elliptic curve routines:d2i_ECPrivateKey:EC lib:../../../../vendor/openssl-fips/crypto/ec/ec_asn1.c:1172: > 140020611143360:error:100D508E:elliptic curve routines:ECKEY_PRIV_DECODE:decode error:../../../../vendor/openssl-fips/crypto/ec/ec_ameth.c:256: > 140020611143360:error:0606F091:digital envelope routines:EVP_PKCS82PKEY:private key decode error:../../../../vendor/openssl-fips/crypto/evp/evp_pkey.c:92: > 140020611143360:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1 lib:../../../../vendor/openssl-fips/crypto/pem/pem_pkey.c:142: > root at localhost:/home/admin# > > A portion of the sample ECDSA key generated with curve secp384r1 via ssh-keygen with "ssh-keygen -t ecdsa -b 384 -f ssh_host_key_ecdsa" is provided below: > > -----BEGIN PRIVATE KEY----- > MIG2AgEAMBAGByqGSM49AgEGBSuBBAAiBIGeMIGbAgEBBDD > ........ > ........ > -----END PRIVATE KEY----- > > A few questions related to this: > > 1) Is there a specific need to build the OpenSSL source only via the provided Makefile? > 2) FIPS self test for ECDSA passes but the key creation/parsing fails. Could this indicate that the FIPS module APIs are not getting invoked in the case of ECDSA? > > -- > Thanks & Regards, > Shirisha. -------------- next part -------------- An HTML attachment was scrubbed... URL: From murugesh.pitchaiah at gmail.com Tue Jul 7 15:09:34 2020 From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah) Date: Tue, 7 Jul 2020 20:39:34 +0530 Subject: OpenSSL shared library in FIPS mode In-Reply-To: References: Message-ID: Hi, Yes. You have to use openssl provided build files. Thanks, Murugesh P. On 7/7/20, Shirisha Dasari via openssl-users wrote: > Hi All, > > We have been trying to integrate FOM 2.0.13 with OpenSSL 1.0.2u for FIPS > compliance. Post integration, we have been able to run in FIPS mode, with > all self-tests passing as well. However, we seem to be encountering issues > in creation and parsing of ECDSA keys. > > A little background on how we build the shared libcrypto library: > > TARGET: x86_64 > BUILD HOST: x86_64 > > We do not use the OpenSSL Makefile to build the OpenSSL source. Our build > infrastructure creates multiple static archives from the OpenSSL crypto > source and finally creates a libcrypto.a from these archives as required by > fipsld. The fipscanister.o and libcrypto.a are archived to create the final > libcrypto.a and passed onto fipsld for creation of a dynamic library, > libcrypto.so. fips_premain_dso gets built as a part of the build process > too for generation of signature. These steps mimic the OpenSSL opensource > Makefile. > > fipsld embeds the signature into the final libcrypto.so successfully and we > are able to get into FIPS mode successfully at run time. Self-tests pass as > well. > > Issue: > > While trying to use ECDSA host keys for OpenSSH, we noticed that parsing of > ECDSA key fails. DSA and RSA key creation and parsing do not have this > issue. Note that the ECDSA key was generated in FIPS mode and is being > parsed in FIPS mode itself. > > root at localhost:/home/admin# openssl ec -in ssh_host_key_ecdsa -text -noout > read EC key > unable to load Key > 140020611143360:error:10067066:elliptic curve > routines:ec_GFp_simple_oct2point:invalid > encoding:../../../../vendor/openssl-fips/crypto/ec/ecp_oct.c:370: > 140020611143360:error:10092010:elliptic curve routines:d2i_ECPrivateKey:EC > lib:../../../../vendor/openssl-fips/crypto/ec/ec_asn1.c:1172: > 140020611143360:error:100D508E:elliptic curve > routines:ECKEY_PRIV_DECODE:decode > error:../../../../vendor/openssl-fips/crypto/ec/ec_ameth.c:256: > 140020611143360:error:0606F091:digital envelope > routines:EVP_PKCS82PKEY:private key decode > error:../../../../vendor/openssl-fips/crypto/evp/evp_pkey.c:92: > 140020611143360:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1 > lib:../../../../vendor/openssl-fips/crypto/pem/pem_pkey.c:142: > root at localhost:/home/admin# > > A portion of the sample ECDSA key generated with curve secp384r1 via > ssh-keygen with "ssh-keygen -t ecdsa -b 384 -f ssh_host_key_ecdsa" is > provided below: > > -----BEGIN PRIVATE KEY----- > MIG2AgEAMBAGByqGSM49AgEGBSuBBAAiBIGeMIGbAgEBBDD > ........ > ........ > -----END PRIVATE KEY----- > > A few questions related to this: > > 1) Is there a specific need to build the OpenSSL source only via the > provided Makefile? > 2) FIPS self test for ECDSA passes but the key creation/parsing fails. > Could this indicate that the FIPS module APIs are not getting invoked in > the case of ECDSA? > > -- > Thanks & Regards, > Shirisha. > From tomiii at tomiii.com Tue Jul 7 15:11:30 2020 From: tomiii at tomiii.com (Thomas Dwyer III) Date: Tue, 7 Jul 2020 08:11:30 -0700 Subject: OpenSSL shared library in FIPS mode In-Reply-To: <691867E4-B3E3-48EE-8330-68E9E0EF2789@oracle.com> References: <691867E4-B3E3-48EE-8330-68E9E0EF2789@oracle.com> Message-ID: On Tue, Jul 7, 2020 at 12:48 AM Dr Paul Dale wrote: > OpenSSL 1.0.2 ceased being supported at the beginning of this year. > > If you are deviating in any way from the prescribed build instructions > (you did read the security policy didn?t you?) you are not FIPS compliant. > Can you confirm whether that statement applies to the entirety of building libcrypto, or whether it's just the fipscanister.o component that requires strict adherence to the build instructions documented in the security policy? Thanks, Tom.III > Not using the OpenSSL Makefile is such a deviation. My suspicion is that > you are not and never have been FIPS compliant. > > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > > On 7 Jul 2020, at 3:36 pm, Shirisha Dasari via openssl-users < > openssl-users at openssl.org> wrote: > > Hi All, > > We have been trying to integrate FOM 2.0.13 with OpenSSL 1.0.2u for FIPS > compliance. Post integration, we have been able to run in FIPS mode, with > all self-tests passing as well. However, we seem to be encountering issues > in creation and parsing of ECDSA keys. > > A little background on how we build the shared libcrypto library: > > TARGET: x86_64 > BUILD HOST: x86_64 > > We do not use the OpenSSL Makefile to build the OpenSSL source. Our build > infrastructure creates multiple static archives from the OpenSSL crypto > source and finally creates a libcrypto.a from these archives as required by > fipsld. The fipscanister.o and libcrypto.a are archived to create the final > libcrypto.a and passed onto fipsld for creation of a dynamic library, > libcrypto.so. fips_premain_dso gets built as a part of the build process > too for generation of signature. These steps mimic the OpenSSL opensource > Makefile. > > fipsld embeds the signature into the final libcrypto.so successfully and > we are able to get into FIPS mode successfully at run time. Self-tests pass > as well. > > Issue: > > While trying to use ECDSA host keys for OpenSSH, we noticed that parsing > of ECDSA key fails. DSA and RSA key creation and parsing do not have this > issue. Note that the ECDSA key was generated in FIPS mode and is being > parsed in FIPS mode itself. > > root at localhost:/home/admin# openssl ec -in ssh_host_key_ecdsa -text > -noout > read EC key > unable to load Key > 140020611143360:error:10067066:elliptic curve > routines:ec_GFp_simple_oct2point:invalid > encoding:../../../../vendor/openssl-fips/crypto/ec/ecp_oct.c:370: > 140020611143360:error:10092010:elliptic curve routines:d2i_ECPrivateKey:EC > lib:../../../../vendor/openssl-fips/crypto/ec/ec_asn1.c:1172: > 140020611143360:error:100D508E:elliptic curve > routines:ECKEY_PRIV_DECODE:decode > error:../../../../vendor/openssl-fips/crypto/ec/ec_ameth.c:256: > 140020611143360:error:0606F091:digital envelope > routines:EVP_PKCS82PKEY:private key decode > error:../../../../vendor/openssl-fips/crypto/evp/evp_pkey.c:92: > 140020611143360:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1 > lib:../../../../vendor/openssl-fips/crypto/pem/pem_pkey.c:142: > root at localhost:/home/admin# > > A portion of the sample ECDSA key generated with curve secp384r1 via > ssh-keygen with "ssh-keygen -t ecdsa -b 384 -f ssh_host_key_ecdsa" is > provided below: > > -----BEGIN PRIVATE KEY----- > MIG2AgEAMBAGByqGSM49AgEGBSuBBAAiBIGeMIGbAgEBBDD > ........ > ........ > -----END PRIVATE KEY----- > > A few questions related to this: > > 1) Is there a specific need to build the OpenSSL source only via the > provided Makefile? > 2) FIPS self test for ECDSA passes but the key creation/parsing fails. > Could this indicate that the FIPS module APIs are not getting invoked in > the case of ECDSA? > > -- > Thanks & Regards, > Shirisha. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shirisha.dasari at broadcom.com Tue Jul 7 15:33:28 2020 From: shirisha.dasari at broadcom.com (Shirisha Dasari) Date: Tue, 7 Jul 2020 21:03:28 +0530 Subject: OpenSSL shared library in FIPS mode In-Reply-To: References: Message-ID: Thanks Murugesh. I just wanted to add that the FOM (OpenSSL FIPS object module) is built using the instructions provided by the User Guide: ./config make make install The built fipscanister.o is integrated into the OpenSSL distribution via our own build infrastructure by mimicking the OpenSSL makefiles (including invoking fipsld to embed the signature into the library). On Tue, Jul 7, 2020 at 8:39 PM murugesh pitchaiah < murugesh.pitchaiah at gmail.com> wrote: > Hi, > > Yes. You have to use openssl provided build files. > > Thanks, > Murugesh P. > > On 7/7/20, Shirisha Dasari via openssl-users > wrote: > > Hi All, > > > > We have been trying to integrate FOM 2.0.13 with OpenSSL 1.0.2u for FIPS > > compliance. Post integration, we have been able to run in FIPS mode, with > > all self-tests passing as well. However, we seem to be encountering > issues > > in creation and parsing of ECDSA keys. > > > > A little background on how we build the shared libcrypto library: > > > > TARGET: x86_64 > > BUILD HOST: x86_64 > > > > We do not use the OpenSSL Makefile to build the OpenSSL source. Our build > > infrastructure creates multiple static archives from the OpenSSL crypto > > source and finally creates a libcrypto.a from these archives as required > by > > fipsld. The fipscanister.o and libcrypto.a are archived to create the > final > > libcrypto.a and passed onto fipsld for creation of a dynamic library, > > libcrypto.so. fips_premain_dso gets built as a part of the build process > > too for generation of signature. These steps mimic the OpenSSL opensource > > Makefile. > > > > fipsld embeds the signature into the final libcrypto.so successfully and > we > > are able to get into FIPS mode successfully at run time. Self-tests pass > as > > well. > > > > Issue: > > > > While trying to use ECDSA host keys for OpenSSH, we noticed that parsing > of > > ECDSA key fails. DSA and RSA key creation and parsing do not have this > > issue. Note that the ECDSA key was generated in FIPS mode and is being > > parsed in FIPS mode itself. > > > > root at localhost:/home/admin# openssl ec -in ssh_host_key_ecdsa -text > -noout > > read EC key > > unable to load Key > > 140020611143360:error:10067066:elliptic curve > > routines:ec_GFp_simple_oct2point:invalid > > encoding:../../../../vendor/openssl-fips/crypto/ec/ecp_oct.c:370: > > 140020611143360:error:10092010:elliptic curve > routines:d2i_ECPrivateKey:EC > > lib:../../../../vendor/openssl-fips/crypto/ec/ec_asn1.c:1172: > > 140020611143360:error:100D508E:elliptic curve > > routines:ECKEY_PRIV_DECODE:decode > > error:../../../../vendor/openssl-fips/crypto/ec/ec_ameth.c:256: > > 140020611143360:error:0606F091:digital envelope > > routines:EVP_PKCS82PKEY:private key decode > > error:../../../../vendor/openssl-fips/crypto/evp/evp_pkey.c:92: > > 140020611143360:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1 > > lib:../../../../vendor/openssl-fips/crypto/pem/pem_pkey.c:142: > > root at localhost:/home/admin# > > > > A portion of the sample ECDSA key generated with curve secp384r1 via > > ssh-keygen with "ssh-keygen -t ecdsa -b 384 -f ssh_host_key_ecdsa" is > > provided below: > > > > -----BEGIN PRIVATE KEY----- > > MIG2AgEAMBAGByqGSM49AgEGBSuBBAAiBIGeMIGbAgEBBDD > > ........ > > ........ > > -----END PRIVATE KEY----- > > > > A few questions related to this: > > > > 1) Is there a specific need to build the OpenSSL source only via the > > provided Makefile? > > 2) FIPS self test for ECDSA passes but the key creation/parsing fails. > > Could this indicate that the FIPS module APIs are not getting invoked in > > the case of ECDSA? > > > > -- > > Thanks & Regards, > > Shirisha. > > > -- Thanks & Regards, Shirisha. -------------- next part -------------- An HTML attachment was scrubbed... URL: From klaus+ml.openssl-users at uxix.de Wed Jul 8 14:58:39 2020 From: klaus+ml.openssl-users at uxix.de (Klaus Umbach) Date: Wed, 8 Jul 2020 16:58:39 +0200 Subject: Order of protocols in MinProtocol Message-ID: <20200708145838.nzygt3hzkikzxizc@uxix.de> Hi, when I set "MinProtocol" to "TLSv1.2" in openssl.cnf, DTLSv1.2 doesn't work for the client (in my specific case openconnect). According to https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html, only one value is possible, so I can't set both. The usage of "Protocol", where I could use a list, is marked as deprecated. If I set it to "DTLSv1.2", openconnect works fine, but why is "TLSv1.2" higher than "DTLSv1.2" and what is the minimal version of TLS now? How could I set the a System default "MinProtocol" for DTLS and TLS to 1.2? - Klaus From openssl-users at dukhovni.org Wed Jul 8 15:28:06 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 8 Jul 2020 11:28:06 -0400 Subject: Order of protocols in MinProtocol In-Reply-To: <20200708145838.nzygt3hzkikzxizc@uxix.de> References: <20200708145838.nzygt3hzkikzxizc@uxix.de> Message-ID: <20200708152806.GC20025@straasha.imrryr.org> On Wed, Jul 08, 2020 at 04:58:39PM +0200, Klaus Umbach via openssl-users wrote: > when I set "MinProtocol" to "TLSv1.2" in openssl.cnf, DTLSv1.2 doesn't work for > the client (in my specific case openconnect). Unfortunately, I think that's expected. The actual bounds are numeric, and TLS protocols start at 0x0301 (TLS 1.0) and go up to 0x304 (TLS 1.3): # define TLS1_VERSION 0x0301 # define TLS1_1_VERSION 0x0302 # define TLS1_2_VERSION 0x0303 # define TLS1_3_VERSION 0x0304 # define TLS_MAX_VERSION TLS1_3_VERSION [ It is also possible to set the floor at SSL3_VERSION == 0x0300, if that's still enabled in your build. ] while DTLS protocols start at 0xFEFF (DTLS 1.0) and count down: # define DTLS1_VERSION 0xFEFF # define DTLS1_2_VERSION 0xFEFD # define DTLS_MIN_VERSION DTLS1_VERSION # define DTLS_MAX_VERSION DTLS1_2_VERSION So when on a particular SSL_CTX you set MinProtocol and/or MaxProtocol, that setting really only makes sense for TLS or for DTLS, but never both, and you need a separate SSL_CTX for DTLS if you intend to specify the protocol ranges. > How could I set the a System default "MinProtocol" for DTLS and TLS to 1.2? AFAIK, that's not presently possible. You can specify application profiles, for applications that specify an application name when initializing OpenSSL. Or use the OPENSSL_CONF environment variable to select an alternative configuration file for DTLS applications. -- Viktor. From matt at openssl.org Wed Jul 8 15:36:55 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 8 Jul 2020 16:36:55 +0100 Subject: Order of protocols in MinProtocol In-Reply-To: <20200708152806.GC20025@straasha.imrryr.org> References: <20200708145838.nzygt3hzkikzxizc@uxix.de> <20200708152806.GC20025@straasha.imrryr.org> Message-ID: <4208d555-74fa-343b-999f-b101fe4bf205@openssl.org> On 08/07/2020 16:28, Viktor Dukhovni wrote: >> How could I set the a System default "MinProtocol" for DTLS and TLS to 1.2? > > AFAIK, that's not presently possible. You can specify application > profiles, for applications that specify an application name when > initializing OpenSSL. Or use the OPENSSL_CONF environment variable to > select an alternative configuration file for DTLS applications. > Arguably, that is a bug. You *should* be able to do that - perhaps based on some sensible mapping between TLS protocol versions based on whether we have a DTLS or TLS based SSL_METHOD. Matt From openssl-users at dukhovni.org Wed Jul 8 16:21:52 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 8 Jul 2020 12:21:52 -0400 Subject: Order of protocols in MinProtocol In-Reply-To: <4208d555-74fa-343b-999f-b101fe4bf205@openssl.org> References: <20200708145838.nzygt3hzkikzxizc@uxix.de> <20200708152806.GC20025@straasha.imrryr.org> <4208d555-74fa-343b-999f-b101fe4bf205@openssl.org> Message-ID: <20200708162152.GE20025@straasha.imrryr.org> On Wed, Jul 08, 2020 at 04:36:55PM +0100, Matt Caswell wrote: > On 08/07/2020 16:28, Viktor Dukhovni wrote: > >> How could I set the a System default "MinProtocol" for DTLS and TLS to 1.2? > > > > AFAIK, that's not presently possible. You can specify application > > profiles, for applications that specify an application name when > > initializing OpenSSL. Or use the OPENSSL_CONF environment variable to > > select an alternative configuration file for DTLS applications. > > Arguably, that is a bug. You *should* be able to do that - perhaps based > on some sensible mapping between TLS protocol versions based on whether > we have a DTLS or TLS based SSL_METHOD. I agree that the situation with MinProtocol in openssl.cnf is unfortunate. But instead of mappings, I would propose a different solution: * Restrict MinProtocol/MaxProtocol to just TLS protocols, i.e. SSL_CTX objects with a TLS-based method. * Introduct new controls: DTLSMinProtocolDTLS, DTLSMaxProtocol, that are similarly restricted to SSL_CTX objects with a DTLS-based method. * Since SSL_CTX_new() takes a required method argument, we are in never in doubt as to which pair of controls to apply to a given context. Thoughts? -- Viktor. From matt at openssl.org Wed Jul 8 16:40:38 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 8 Jul 2020 17:40:38 +0100 Subject: Order of protocols in MinProtocol In-Reply-To: <20200708162152.GE20025@straasha.imrryr.org> References: <20200708145838.nzygt3hzkikzxizc@uxix.de> <20200708152806.GC20025@straasha.imrryr.org> <4208d555-74fa-343b-999f-b101fe4bf205@openssl.org> <20200708162152.GE20025@straasha.imrryr.org> Message-ID: On 08/07/2020 17:21, Viktor Dukhovni wrote: > On Wed, Jul 08, 2020 at 04:36:55PM +0100, Matt Caswell wrote: > >> On 08/07/2020 16:28, Viktor Dukhovni wrote: >>>> How could I set the a System default "MinProtocol" for DTLS and TLS to 1.2? >>> >>> AFAIK, that's not presently possible. You can specify application >>> profiles, for applications that specify an application name when >>> initializing OpenSSL. Or use the OPENSSL_CONF environment variable to >>> select an alternative configuration file for DTLS applications. >> >> Arguably, that is a bug. You *should* be able to do that - perhaps based >> on some sensible mapping between TLS protocol versions based on whether >> we have a DTLS or TLS based SSL_METHOD. > > I agree that the situation with MinProtocol in openssl.cnf is > unfortunate. But instead of mappings, I would propose a different > solution: > > * Restrict MinProtocol/MaxProtocol to just TLS protocols, > i.e. SSL_CTX objects with a TLS-based method. > > * Introduct new controls: DTLSMinProtocolDTLS, DTLSMaxProtocol, > that are similarly restricted to SSL_CTX objects with a DTLS-based > method. > > * Since SSL_CTX_new() takes a required method argument, we are in > never in doubt as to which pair of controls to apply to a given > context. > > Thoughts? Yes - that could work. Although it begs the question - would it change the way SSL_CTX_set_min_proto_version() works? (I assume that currently works just fine as is) Another question that throws up is how much of that solution would we backport to 1.1.1 since DTLS(Min|Max)Protocol would be a new feature. Should we backport it anyway with the justification that it is a "fix"? Or do we just backport the bit that means it doesn't get applied to DTLS? Matt From openssl-users at dukhovni.org Wed Jul 8 16:47:54 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 8 Jul 2020 12:47:54 -0400 Subject: Order of protocols in MinProtocol In-Reply-To: References: <20200708145838.nzygt3hzkikzxizc@uxix.de> <20200708152806.GC20025@straasha.imrryr.org> <4208d555-74fa-343b-999f-b101fe4bf205@openssl.org> <20200708162152.GE20025@straasha.imrryr.org> Message-ID: <20200708164754.GF20025@straasha.imrryr.org> On Wed, Jul 08, 2020 at 05:40:38PM +0100, Matt Caswell wrote: > > I agree that the situation with MinProtocol in openssl.cnf is > > unfortunate. But instead of mappings, I would propose a different > > solution: > > > > * Restrict MinProtocol/MaxProtocol to just TLS protocols, > > i.e. SSL_CTX objects with a TLS-based method. > > > > * Introduct new controls: DTLSMinProtocolDTLS, DTLSMaxProtocol, > > that are similarly restricted to SSL_CTX objects with a DTLS-based > > method. > > > > * Since SSL_CTX_new() takes a required method argument, we are in > > never in doubt as to which pair of controls to apply to a given > > context. > > > > Thoughts? > > Yes - that could work. Although it begs the question - would it change > the way SSL_CTX_set_min_proto_version() works? (I assume that currently > works just fine as is) No changes in SSL_CTX_set_(min|max)_proto_version() required. The API remains the same, and a user calling it on a context with a DTLS-based method, would (as before) pass the appropriate *DTLS* versions. The only change would be in the .cnf file, where "MinProtocol" and "MaxProtocol" would now apply only in TLS-based contexts, and new DTLSMinProtocol and DTLSMaxProtocol only in DTLS-based contexts. > Another question that throws up is how much of that solution would we > backport to 1.1.1 since DTLS(Min|Max)Protocol would be a new feature. I'd be inclined to backport. > Should we backport it anyway with the justification that it is a "fix"? > Or do we just backport the bit that means it doesn't get applied to DTLS? I see it as a bugfix. Yes, at least not misapply TLS limits to DTLS, but at that point not adding the corresponding DTLS controls feels too cautious to me. -- Viktor. From klaus+ml.openssl-users at uxix.de Wed Jul 8 16:48:24 2020 From: klaus+ml.openssl-users at uxix.de (Klaus Umbach) Date: Wed, 8 Jul 2020 18:48:24 +0200 Subject: Order of protocols in MinProtocol In-Reply-To: <20200708162152.GE20025@straasha.imrryr.org> References: <20200708145838.nzygt3hzkikzxizc@uxix.de> <20200708152806.GC20025@straasha.imrryr.org> <4208d555-74fa-343b-999f-b101fe4bf205@openssl.org> <20200708162152.GE20025@straasha.imrryr.org> Message-ID: <20200708164824.fnsm4shk2p26wl4v@uxix.de> On 08.07.20 12:21, Viktor Dukhovni wrote: > On Wed, Jul 08, 2020 at 04:36:55PM +0100, Matt Caswell wrote: > > > On 08/07/2020 16:28, Viktor Dukhovni wrote: > > >> How could I set the a System default "MinProtocol" for DTLS and TLS to 1.2? > > > > > > AFAIK, that's not presently possible. You can specify application > > > profiles, for applications that specify an application name when > > > initializing OpenSSL. Or use the OPENSSL_CONF environment variable to > > > select an alternative configuration file for DTLS applications. > > > > Arguably, that is a bug. You *should* be able to do that - perhaps based > > on some sensible mapping between TLS protocol versions based on whether > > we have a DTLS or TLS based SSL_METHOD. Should I open an issue at https://github.com/openssl/openssl/issues? > > I agree that the situation with MinProtocol in openssl.cnf is > unfortunate. But instead of mappings, I would propose a different > solution: > > * Restrict MinProtocol/MaxProtocol to just TLS protocols, > i.e. SSL_CTX objects with a TLS-based method. > > * Introduct new controls: DTLSMinProtocolDTLS, DTLSMaxProtocol, > that are similarly restricted to SSL_CTX objects with a DTLS-based > method. > > * Since SSL_CTX_new() takes a required method argument, we are in > never in doubt as to which pair of controls to apply to a given > context. > > Thoughts? To me this sounds sane. But for my personal problem right now (openconnect uses TLS and DTLS, so even if it would set an application name I couldn't set a "proper" setting), until this bug is fixed, I use this now: # MinProtocol = TLSv1.2 Protocol = -TLSv1, -TLSv1.1, TLSv1.2, TLSv1.3, DTLSv1.2 (with a big comment for future-me, why I did something, that i shouldn't) To my understanding, this will do exaclty what I want, up to that point in time, when there are newer versions of DTLS and/or TLS supported and I want to use them. (SSL3 is not supported in my build) Am I right? - Klaus From felipe at felipegasper.com Wed Jul 8 16:48:38 2020 From: felipe at felipegasper.com (Felipe Gasper) Date: Wed, 8 Jul 2020 12:48:38 -0400 Subject: RFC 7250 raw public keys? Message-ID: <0D1B2A50-C54C-47AE-A560-273E0BECB7A6@felipegasper.com> Hello, Does OpenSSL support authentication via raw public keys? (RFC 7250) I can?t find anything to this effect on openssl.org. Thank you! cheers, -Felipe Gasper From matt at openssl.org Wed Jul 8 16:57:48 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 8 Jul 2020 17:57:48 +0100 Subject: Order of protocols in MinProtocol In-Reply-To: <20200708164824.fnsm4shk2p26wl4v@uxix.de> References: <20200708145838.nzygt3hzkikzxizc@uxix.de> <20200708152806.GC20025@straasha.imrryr.org> <4208d555-74fa-343b-999f-b101fe4bf205@openssl.org> <20200708162152.GE20025@straasha.imrryr.org> <20200708164824.fnsm4shk2p26wl4v@uxix.de> Message-ID: On 08/07/2020 17:48, Klaus Umbach via openssl-users wrote: > On 08.07.20 12:21, Viktor Dukhovni wrote: >> On Wed, Jul 08, 2020 at 04:36:55PM +0100, Matt Caswell wrote: >> >>> On 08/07/2020 16:28, Viktor Dukhovni wrote: >>>>> How could I set the a System default "MinProtocol" for DTLS and TLS to 1.2? >>>> >>>> AFAIK, that's not presently possible. You can specify application >>>> profiles, for applications that specify an application name when >>>> initializing OpenSSL. Or use the OPENSSL_CONF environment variable to >>>> select an alternative configuration file for DTLS applications. >>> >>> Arguably, that is a bug. You *should* be able to do that - perhaps based >>> on some sensible mapping between TLS protocol versions based on whether >>> we have a DTLS or TLS based SSL_METHOD. > > Should I open an issue at https://github.com/openssl/openssl/issues? Yes please. > But for my personal problem right now (openconnect uses TLS and DTLS, so > even if it would set an application name I couldn't set a "proper" > setting), until this bug is fixed, I use this now: > > # MinProtocol = TLSv1.2 > Protocol = -TLSv1, -TLSv1.1, TLSv1.2, TLSv1.3, DTLSv1.2 Looks sane - although do you also mean to disable DTLSv1? Perhaps for safety you should also disable SSLv3 (although support for it is not built by default anyway). Matt From openssl-users at dukhovni.org Wed Jul 8 16:59:50 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 8 Jul 2020 12:59:50 -0400 Subject: RFC 7250 raw public keys? In-Reply-To: <0D1B2A50-C54C-47AE-A560-273E0BECB7A6@felipegasper.com> References: <0D1B2A50-C54C-47AE-A560-273E0BECB7A6@felipegasper.com> Message-ID: <20200708165950.GG20025@straasha.imrryr.org> On Wed, Jul 08, 2020 at 12:48:38PM -0400, Felipe Gasper wrote: > Does OpenSSL support authentication via raw public keys? (RFC 7250) I > can?t find anything to this effect on openssl.org. These are not presently supported. However, you can use DANE-EE(3) TLSA records to authenticate essentially empty leaf certificates: $ openssl req -new \ -newkey ed25519 -nodes -keyout key.pem \ -x509 -days 36500 -subj / -out cert.pem The resulting certificate contains pretty much only a public key: $ openssl x509 -text -in cert.pem Certificate: Data: Version: 3 (0x2) Serial Number: 03:ff:26:4b:48:53:95:3c:4e:db:5d:db:b8:e5:13:1c:a7:67:e0:49 Signature Algorithm: ED25519 Issuer: Validity Not Before: Jul 8 16:54:41 2020 GMT Not After : Jun 14 16:54:41 2120 GMT Subject: Subject Public Key Info: Public Key Algorithm: ED25519 ED25519 Public-Key: pub: ad:48:26:95:0f:70:c4:c6:8c:8b:da:9a:d1:3c:18: ef:ec:60:b1:d9:d6:40:7a:5c:4f:6e:8e:36:a2:9e: b0:c7 X509v3 extensions: X509v3 Subject Key Identifier: A1:47:10:54:37:97:45:C0:3D:5B:3A:F2:1A:3D:EE:9F:4A:46:7B:D2 X509v3 Authority Key Identifier: keyid:A1:47:10:54:37:97:45:C0:3D:5B:3A:F2:1A:3D:EE:9F:4A:46:7B:D2 X509v3 Basic Constraints: critical CA:TRUE Signature Algorithm: ED25519 48:e7:e2:1a:a0:3b:00:42:7c:66:46:67:26:08:ed:df:f8:64: 70:17:ff:72:8e:1d:42:8e:9b:99:e8:54:e5:e1:eb:97:fe:4e: dd:e6:89:b8:05:e5:b3:d8:da:a6:97:91:90:c5:54:56:0e:90: f5:b7:5a:54:c9:78:0b:b5:ed:03 -----BEGIN CERTIFICATE----- MIIBFjCByaADAgECAhQD/yZLSFOVPE7bXdu45RMcp2fgSTAFBgMrZXAwADAgFw0y MDA3MDgxNjU0NDFaGA8yMTIwMDYxNDE2NTQ0MVowADAqMAUGAytlcAMhAK1IJpUP cMTGjIvamtE8GO/sYLHZ1kB6XE9ujjainrDHo1MwUTAdBgNVHQ4EFgQUoUcQVDeX RcA9WzryGj3un0pGe9IwHwYDVR0jBBgwFoAUoUcQVDeXRcA9WzryGj3un0pGe9Iw DwYDVR0TAQH/BAUwAwEB/zAFBgMrZXADQQBI5+IaoDsAQnxmRmcmCO3f+GRwF/9y jh1CjpuZ6FTl4euX/k7d5om4BeWz2Nqml5GQxVRWDpD1t1pUyXgLte0D -----END CERTIFICATE----- And while it is larger than the bare key, the size penalty is not prohibitive. -- Viktor. From klaus+ml.openssl-users at uxix.de Wed Jul 8 17:27:18 2020 From: klaus+ml.openssl-users at uxix.de (Klaus Umbach) Date: Wed, 8 Jul 2020 19:27:18 +0200 Subject: Order of protocols in MinProtocol In-Reply-To: References: <20200708145838.nzygt3hzkikzxizc@uxix.de> <20200708152806.GC20025@straasha.imrryr.org> <4208d555-74fa-343b-999f-b101fe4bf205@openssl.org> <20200708162152.GE20025@straasha.imrryr.org> <20200708164824.fnsm4shk2p26wl4v@uxix.de> Message-ID: <20200708172718.ghttxtfa6vts3u47@uxix.de> On 08.07.20 17:57, Matt Caswell wrote: > > > On 08/07/2020 17:48, Klaus Umbach via openssl-users wrote: > > On 08.07.20 12:21, Viktor Dukhovni wrote: > >> On Wed, Jul 08, 2020 at 04:36:55PM +0100, Matt Caswell wrote: > >> > >>> On 08/07/2020 16:28, Viktor Dukhovni wrote: > >>>>> How could I set the a System default "MinProtocol" for DTLS and TLS to 1.2? > >>>> > >>>> AFAIK, that's not presently possible. You can specify application > >>>> profiles, for applications that specify an application name when > >>>> initializing OpenSSL. Or use the OPENSSL_CONF environment variable to > >>>> select an alternative configuration file for DTLS applications. > >>> > >>> Arguably, that is a bug. You *should* be able to do that - perhaps based > >>> on some sensible mapping between TLS protocol versions based on whether > >>> we have a DTLS or TLS based SSL_METHOD. > > > > Should I open an issue at https://github.com/openssl/openssl/issues? > > Yes please. Done: https://github.com/openssl/openssl/issues/12394 > > > > But for my personal problem right now (openconnect uses TLS and DTLS, so > > even if it would set an application name I couldn't set a "proper" > > setting), until this bug is fixed, I use this now: > > > > # MinProtocol = TLSv1.2 > > Protocol = -TLSv1, -TLSv1.1, TLSv1.2, TLSv1.3, DTLSv1.2 > > Looks sane - although do you also mean to disable DTLSv1? Perhaps for > safety you should also disable SSLv3 (although support for it is not > built by default anyway). Ah, thanks, I missed DTLSv1. (SSLv3 is not enabled in my build, but for safety-reasons, you are right) Thank you! - Klaus From felipe at felipegasper.com Wed Jul 8 17:31:04 2020 From: felipe at felipegasper.com (Felipe Gasper) Date: Wed, 8 Jul 2020 13:31:04 -0400 Subject: RFC 7250 raw public keys? In-Reply-To: <20200708165950.GG20025@straasha.imrryr.org> References: <0D1B2A50-C54C-47AE-A560-273E0BECB7A6@felipegasper.com> <20200708165950.GG20025@straasha.imrryr.org> Message-ID: > On Jul 8, 2020, at 12:59 PM, Viktor Dukhovni wrote: > > On Wed, Jul 08, 2020 at 12:48:38PM -0400, Felipe Gasper wrote: > >> Does OpenSSL support authentication via raw public keys? (RFC 7250) I >> can?t find anything to this effect on openssl.org. > > These are not presently supported. However, you can use DANE-EE(3) TLSA > records to authenticate essentially empty leaf certificates: That would also require changes to DNS, right? What I?m looking for is a way to authenticate a user over TLS in essentially the same manner that SSH?s handshake uses, where a signature of a shared secret validates the public key, which is on a preconfigured allowlist. I could do it post-handshake by using RFC 5705 key material exports as the shared secret--this usage seems to exemplify the intent of that extension--but TLS raw public keys seem a bit closer to ?prior art?. Anyhow, thank you! -FG From vkaliape at gmail.com Wed Jul 8 17:32:07 2020 From: vkaliape at gmail.com (Vijayakumar Kaliaperumal) Date: Wed, 8 Jul 2020 23:02:07 +0530 Subject: DTLS Heartbeat Removed in OpenSSL 1.1.1 In-Reply-To: References: Message-ID: Hi, I am just following up with my earlier mail as I did not get an answer. I now understand that the heartbeat mechanism is completely removed in OpenSSL 1.1.1, whereas it's still available in gnuTLS. So I do not understand why it was removed from OpenSSL Having your own keepalive mechanism(at application level) the only way forward ? I am still looking for some answers. Can someone throw some light on it ? Regards, Vijay On Tue, Jun 9, 2020 at 2:25 PM Vijayakumar Kaliaperumal wrote: > Hello, > > From the release notes of OpenSSL 1.1.1, I could see that DTLS heartbeat > has been removed > . > Heartbeat support has been removed; the ABI is changed for now. > > With RFC 6520 in standards track, any specific reason(Vulnerability/other > security issue reported) for the removal ?, How can we re-enable it ? > Recompile OpenSSL without OPENSSL_NO_HEARTBEATS macro ? Please advise. > > Regards, > Vijay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jul 8 17:51:50 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 8 Jul 2020 13:51:50 -0400 Subject: RFC 7250 raw public keys? In-Reply-To: References: <0D1B2A50-C54C-47AE-A560-273E0BECB7A6@felipegasper.com> <20200708165950.GG20025@straasha.imrryr.org> Message-ID: <20200708175150.GH20025@straasha.imrryr.org> On Wed, Jul 08, 2020 at 01:31:04PM -0400, Felipe Gasper wrote: > > On Jul 8, 2020, at 12:59 PM, Viktor Dukhovni wrote: > > > > On Wed, Jul 08, 2020 at 12:48:38PM -0400, Felipe Gasper wrote: > > > >> Does OpenSSL support authentication via raw public keys? (RFC 7250) I > >> can?t find anything to this effect on openssl.org. > > > > These are not presently supported. However, you can use DANE-EE(3) TLSA > > records to authenticate essentially empty leaf certificates: > > That would also require changes to DNS, right? Sure, but DANE-EE(3) is just one way to authenticate a stand-alone self-signed certificate. Indeed OpenSSL does not do the DNS lookups, you can store the matching digest anywhere and retrieve it in whatever way makes sense for your application. You can even compute it on the fly from a copy of the expected certificate. Postfix (in which I'm the maintainer of the TLS stack), creates synthetic DANE TLSA records as the way that it matches certificates by pre-configured "fingerprint" values. That said, you also don't need to use DANE authentication, you can implement your own certificate verification callbacks, ... My point was primarily that a bit of space overhead side, a minimal X.509 certificate is in most cases equivalent to a bare public key, but has broader API support. > What I?m looking for is a way to authenticate a user over TLS in > essentially the same manner that SSH?s handshake uses, where a > signature of a shared secret validates the public key, which is on a > preconfigured allowlist. I could do it post-handshake by using RFC > 5705 key material exports as the shared secret--this usage seems to > exemplify the intent of that extension--but TLS raw public keys seem a > bit closer to ?prior art?. Indeed DANE is only a good fit for authenticating servers, for authenticating clients, you just want to compute a public key fingerprint and do a database lookup. This is also supported in Postfix, just don't authenticate the client cert at all (no PKI), grab the key digest and use it directly for access control. -- Viktor. From Michael.Wojcik at microfocus.com Wed Jul 8 18:18:01 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 8 Jul 2020 18:18:01 +0000 Subject: DTLS Heartbeat Removed in OpenSSL 1.1.1 In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Vijayakumar Kaliaperumal > Sent: Wednesday, July 08, 2020 11:32 > I now understand that the heartbeat mechanism is completely removed in OpenSSL > 1.1.1, whereas it's still available in gnuTLS. gnuTLS would not be my personal choice of exemplar. "gnuTLS does it" often seems to be a better argument against something than for it. > So I do not understand why it was removed from OpenSSL Well, PR 1928 (https://github.com/openssl/openssl/pull/1928), which removed it, doesn't have a lot of discussion. Richard Levitte created the changes and the request, and Tim Hudson approved them; there's not much else, aside from some comments regarding deprecating the Configure option (which I believe was done). The PR does mention Issue 4856 (https://github.com/openssl/openssl/issues/4856), in which Hanno Boeck cites Heartbleed and claims "there don't seem to be any real world use cases". I'm not convinced that there aren't *any* real-world use cases. Your message suggests you have one, and Seggelmann et al. presumably had one when they wrote RFC 6520 and Seggelmann submitted the code change for OpenSSL. RFC 6520 notes that Heartbeat can be used for PMTU discovery for DTLS, besides its nominal "are you still there?" function. And keepalives are used in a number of protocols, both to keep a path active (though that was more relevant when virtual-circuit-switching and on-demand physical links were more common) and to periodically test a path to ensure the peer was still reachable and responding. However, Hanno Boeck knows as much about real-world TLS and DTLS usage as anyone I can think of, and Heartbeat is widely viewed as over-engineered and unnecessarily complex, which is why we had Heartbleed in the first place. None of the products I currently work on use DTLS, but if they did, I wouldn't be sorry to see Heartbeat go. > Having your own keepalive mechanism(at application level) the only way forward? If you're using OpenSSL, then I'd say it's either implement one in the application, or create an intermediate library that adds a keepalive mechanism on top of OpenSSL's DTLS support, or hack Heartbeat back into OpenSSL. I definitely would not recommend the third. The first lets you tailor the keepalive to the application's architecture and needs; the second lets you reuse the implementation. -- Michael Wojcik From felipe at felipegasper.com Wed Jul 8 18:24:47 2020 From: felipe at felipegasper.com (Felipe Gasper) Date: Wed, 8 Jul 2020 14:24:47 -0400 Subject: RFC 7250 raw public keys? In-Reply-To: <20200708175150.GH20025@straasha.imrryr.org> References: <0D1B2A50-C54C-47AE-A560-273E0BECB7A6@felipegasper.com> <20200708165950.GG20025@straasha.imrryr.org> <20200708175150.GH20025@straasha.imrryr.org> Message-ID: <12EDA97C-1CA5-4521-90E9-3A98618EB895@felipegasper.com> > On Jul 8, 2020, at 1:51 PM, Viktor Dukhovni wrote: > > On Wed, Jul 08, 2020 at 01:31:04PM -0400, Felipe Gasper wrote: > >> What I?m looking for is a way to authenticate a user over TLS in >> essentially the same manner that SSH?s handshake uses, where a >> signature of a shared secret validates the public key, which is on a >> preconfigured allowlist. I could do it post-handshake by using RFC >> 5705 key material exports as the shared secret--this usage seems to >> exemplify the intent of that extension--but TLS raw public keys seem a >> bit closer to ?prior art?. > > Indeed DANE is only a good fit for authenticating servers, for > authenticating clients, you just want to compute a public key > fingerprint and do a database lookup. > > This is also supported in Postfix, just don't authenticate > the client cert at all (no PKI), grab the key digest and > use it directly for access control. Wouldn?t there need to be a shared secret, though, or some other way for the server to have some influence on the randomness of what the client?s private key signs? (I don?t know TLS well enough to comment on whether that happens in an ordinary TLS handshake, but I assume it does?) -F From openssl-users at dukhovni.org Wed Jul 8 18:32:39 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 8 Jul 2020 14:32:39 -0400 Subject: RFC 7250 raw public keys? In-Reply-To: <12EDA97C-1CA5-4521-90E9-3A98618EB895@felipegasper.com> References: <0D1B2A50-C54C-47AE-A560-273E0BECB7A6@felipegasper.com> <20200708165950.GG20025@straasha.imrryr.org> <20200708175150.GH20025@straasha.imrryr.org> <12EDA97C-1CA5-4521-90E9-3A98618EB895@felipegasper.com> Message-ID: <20200708183239.GI20025@straasha.imrryr.org> On Wed, Jul 08, 2020 at 02:24:47PM -0400, Felipe Gasper wrote: > > This is also supported in Postfix, just don't authenticate > > the client cert at all (no PKI), grab the key digest and > > use it directly for access control. > > Wouldn?t there need to be a shared secret, though, or some other way > for the server to have some influence on the randomness of what the > client?s private key signs? (I don?t know TLS well enough to comment > on whether that happens in an ordinary TLS handshake, but I assume it > does?) TLS takes care of that: https://tools.ietf.org/html/rfc5246#section-7.4.8 https://tools.ietf.org/html/rfc8446#section-4.4.3 In particular, the client and server random values are included, as well as any ephemeral public values in DH or ECDH key exchange. -- Viktor. From tengicki at autopoll.de Thu Jul 9 09:09:40 2020 From: tengicki at autopoll.de (Andreas Tengicki) Date: Thu, 9 Jul 2020 11:09:40 +0200 Subject: creating certificate by code / problems to load via openssl x509 / pem format Message-ID: <6afcb37d-1381-a449-cf87-9e9b79f6343a@autopoll.de> Hello, your first help in this project, helps much, but now some weeks later, there is a new problem, and I cannot find any tipps via google. For all the coding a have looked into the openssl examples. I create a private key per code, the "openssl rsa -in test_privatekey.pem -check" is fine I create a certificate request per code, "openssl req -text -noout -verify -in test_request.pem" is fine I create a certifcate via this reqeust and store it with "PEM_write_bio_X509(out, crt);" like the others. (some more code below) Perhaps there is something wrong, but to detect this, I will use the validation, but it cannot load the certificate to validate it: >> openssl x509 -in test_certificate.pem -text unable to load certificate 140180222239872:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:../crypto/asn1/asn1_lib.c:91: 140180222239872:error:0D068066:asn1 encoding routines:asn1_check_tlen:bad object header:../crypto/asn1/tasn_dec.c:1118: 140180222239872:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:190:Type=ASN1_TIME 140180222239872:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:627:Field=notBefore, Type=X509_VAL 140180222239872:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:627:Field=validity, Type=X509_CINF 140180222239872:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:627:Field=cert_info, Type=X509 140180222239872:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:../crypto/pem/pem_oth.c:33: Thanks for any help. Best regards ? Andreas ---- ErrorHandling should be added in a second step, first debug outputs (I have deleted for here) says everything is created X509* certificate_create(const X509_REQ* req) { ? //openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt ? if ((crt = X509_new()) == NULL); ? //xca = load_cert(CAfile, CAformat, "CA Certificate"); ? BIO *bio = NULL; ? bio = BIO_new_file(CAfile, "r"); ? xca = PEM_read_bio_X509_AUX(bio, NULL, NULL, NULL); ? BIO_free(bio); ? upkey = X509_get0_pubkey(xca); ? char CAkeyile[] = "ca.key"; ? int CAkeyformat = 5; //FORMAT_PEM ? char passin[] = "xyz"; ? ENGINE *e = NULL; ? EVP_PKEY * CApkey = NULL; ? //CApkey = load_key(CAkeyfile, CAkeyformat, 0, passin, e, "CA Private Key"); ? bio = BIO_new_file(CAkeyile, "r"); ? CApkey = PEM_read_bio_PrivateKey(bio, NULL, NULL, passin); ? BIO_free(bio); ? EVP_PKEY_copy_parameters(upkey, CApkey); ? X509_STORE *ctx = NULL; ? ctx = X509_STORE_new(); ? X509_STORE_CTX *xsc = NULL; ? xsc = X509_STORE_CTX_new(); ? if (xsc == NULL || !X509_STORE_CTX_init(xsc, ctx, crt, NULL)); ? ASN1_INTEGER *serialno = NULL; ? serialno = ASN1_INTEGER_new(); ? BIGNUM *btmp = NULL; ? btmp = BN_new(); ? # define SERIAL_RAND_BITS??????? 159 ? if (!BN_rand(btmp, SERIAL_RAND_BITS, BN_RAND_TOP_ANY, BN_RAND_BOTTOM_ANY)); ? if (!BN_to_ASN1_INTEGER(btmp, serialno)); ? BN_free(btmp); ? X509_STORE_CTX_set_cert(xsc, crt); ? X509_STORE_CTX_set_flags(xsc, X509_V_FLAG_CHECK_SS_SIGNATURE); ? if (!X509_check_private_key(xca, CApkey)) ; ? if (!X509_set_issuer_name(crt, X509_get_subject_name(xca))); ? if (!X509_set_serialNumber(crt, serialno)); ? int days = 365; ? if (X509_time_adj_ex(X509_getm_notAfter(crt), days, 0, NULL) == NULL); ? const char digestname[] = "sha256"; ? const EVP_MD* md = EVP_get_digestbyname(digestname); ? EVP_MD_CTX *mctx = EVP_MD_CTX_new(); ? EVP_PKEY_CTX *pkctx = NULL; ? EVP_DigestSignInit(mctx, &pkctx, md, NULL, CApkey);? //ist CApkey hier der richtige private Key? sollte eigentlich ? int rv = (X509_sign_ctx(crt, mctx) > 0); ? EVP_MD_CTX_free(mctx); ? BIO *out = NULL; ? out = BIO_new_file("test_certificate.pem", "w"); ? PEM_write_bio_X509(out, crt); ? BIO_free_all(out); ? ...some more frees ... ? return crt; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Thu Jul 9 15:21:54 2020 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 9 Jul 2020 15:21:54 +0000 Subject: Master fails tests (mentioning # TODO Currently not supported) Message-ID: <8B1651A4-1108-4EE7-99B3-6663F7F8DB48@ll.mit.edu> MacOS 10.15.5, Xcode-11.5, current OpenSSL master (3.0 dev) Is this expected: genpkey: Error setting ec_param_enc:explicit parameter: C00D090F01000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -text => 1 not ok 1 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (text) # TODO Currently not supported # ------------------------------------------------------------------------------ # Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (text)' # at test/recipes/15-test_genec.t line 37. genpkey: Error setting ec_param_enc:explicit parameter: C0CDBE1601000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform PEM -out ecgen.Oakley-EC2N-3.explicit.pem => 1 not ok 2 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (PEM) # TODO Currently not supported # ------------------------------------------------------------------------------ # Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (PEM)' # at test/recipes/15-test_genec.t line 37. genpkey: Error setting ec_param_enc:explicit parameter: C01D251B01000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform DER -out ecgen.Oakley-EC2N-3.explicit.der => 1 not ok 3 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (DER) # TODO Currently not supported # ------------------------------------------------------------------------------ # Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (DER)' # at test/recipes/15-test_genec.t line 37. genpkey: Error setting ec_param_enc:explicit parameter: C07DD70A01000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -text => 1 not ok 4 - genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' (text) # TODO Currently not supported # ------------------------------------------------------------------------------ # Failed (TODO) test 'genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' (text)' # at test/recipes/15-test_genec.t line 37. genpkey: Error setting ec_param_enc:explicit parameter: C00D341201000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform PEM -out ecgen.Oakley-EC2N-3.explicit.pem => 1 not ok 5 - genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' (PEM) # TODO Currently not supported # ------------------------------------------------------------------------------ # Failed (TODO) test 'genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' (PEM)' # at test/recipes/15-test_genec.t line 37. genpkey: Error setting ec_param_enc:explicit parameter: C0FDFE1001000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform DER -out ecgen.Oakley-EC2N-3.explicit.der => 1 not ok 6 - genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' (DER) # TODO Currently not supported # ------------------------------------------------------------------------------ genpkey: Error setting ec_param_enc:explicit parameter: C09D391101000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-4' -pkeyopt 'ec_param_enc:explicit' -text => 1 not ok 13 - genpkey EC params Oakley-EC2N-4 with ec_param_enc:'explicit' (text) # TODO Currently not supported # ------------------------------------------------------------------------------ # Failed (TODO) test 'genpkey EC params Oakley-EC2N-4 with ec_param_enc:'explicit' (text)' # at test/recipes/15-test_genec.t line 37. genpkey: Error setting ec_param_enc:explicit parameter: C04DD91801000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-4' -pkeyopt 'ec_param_enc:explicit' -outform PEM -out ecgen.Oakley-EC2N-4.explicit.pem => 1 not ok 14 - genpkey EC params Oakley-EC2N-4 with ec_param_enc:'explicit' (PEM) # TODO Currently not supported # ------------------------------------------------------------------------------ # Failed (TODO) test 'genpkey EC params Oakley-EC2N-4 with ec_param_enc:'explicit' (PEM)' # at test/recipes/15-test_genec.t line 37. genpkey: Error setting ec_param_enc:explicit parameter: C0CD0E1101000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-4' -pkeyopt 'ec_param_enc:explicit' -outform DER -out ecgen.Oakley-EC2N-4.explicit.der => 1 not ok 15 - genpkey EC params Oakley-EC2N-4 with ec_param_enc:'explicit' (DER) # TODO Currently not supported # ------------------------------------------------------------------------------ # Failed (TODO) test 'genpkey EC params Oakley-EC2N-4 with ec_param_enc:'explicit' (DER)' # at test/recipes/15-test_genec.t line 37. genpkey: Error setting ec_param_enc:explicit parameter: C0BD080B01000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-4' -pkeyopt 'ec_param_enc:explicit' -text => 1 not ok 16 - genpkey EC key on Oakley-EC2N-4 with ec_param_enc:'explicit' (text) # TODO Currently not supported # ------------------------------------------------------------------------------ # Failed (TODO) test 'genpkey EC key on Oakley-EC2N-4 with ec_param_enc:'explicit' (text)' # at test/recipes/15-test_genec.t line 37. genpkey: Error setting ec_param_enc:explicit parameter: C08DB81401000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-4' -pkeyopt 'ec_param_enc:explicit' -outform PEM -out ecgen.Oakley-EC2N-4.explicit.pem => 1 not ok 17 - genpkey EC key on Oakley-EC2N-4 with ec_param_enc:'explicit' (PEM) # TODO Currently not supported # ------------------------------------------------------------------------------ # Failed (TODO) test 'genpkey EC key on Oakley-EC2N-4 with ec_param_enc:'explicit' (PEM)' # at test/recipes/15-test_genec.t line 37. genpkey: Error setting ec_param_enc:explicit parameter: C02D4F1401000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-4' -pkeyopt 'ec_param_enc:explicit' -outform DER -out ecgen.Oakley-EC2N-4.explicit.der => 1 not ok 18 - genpkey EC key on Oakley-EC2N-4 with ec_param_enc:'explicit' (DER) # TODO Currently not supported # ------------------------------------------------------------------------------15-test_genec.t .................... ok -- Regards, Uri -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From a.mueller at in-chemnitz.de Thu Jul 9 18:07:41 2020 From: a.mueller at in-chemnitz.de (Andreas =?utf-8?b?TcO8bGxlcg==?=) Date: Thu, 09 Jul 2020 18:07:41 +0000 Subject: Question about SSL_key_update Message-ID: <20200709180741.Horde.JhFlMpwq0trMBi4pz-Ta9Bz@mail.in-chemnitz.de> Hi, I "inherited" our project to support/use TLSv1.3 from a late colleague. We have a server written in C++ (Windows, Linux) and clients (Windows, Linux, also written in C++ and also a Java client). With Java, we use the native SSLSocket implementation, in Windows we use Schannel and in Linux we use OpenSSL 1.1.1g. It seems to work and even interoperability did not show issues on some initial testing. I was curious about SSL_key_update. I read that other implementations use it automatically, but with OpenSSL I have to do it manually. So I added a int rc = SSL_key_update(ssl, SSL_KEY_UPDATE_REQUESTED); after 1000 I/O operations and looked what happened. I started with the Java client and it gets wrong application data in such a situation. I tested with our Windows implementation (I know it may have interoperability issues) and here I can see the data I get from the server side and it is the same that I see on server side in the callback, but the Windows DecryptMessage function fails with SEC_E_INVALID_TOKEN. (I had expected something like SEC_I_RENEGOTIATE to get the information to put this record into InitializeSecurityContext.) The Linux client also aborts the connection, but here I have not yet more details, but either the decryption fails or the decrypted application data is wrong. Hopefully I can dig in there next week. Here is what happens on server side: 1. I call SSL_key_update (see above) 2. I call SSL_write with application data 3. The write callback is invoked with this data: DATA: 17 03 03 00 16 b6 02 b1 06 87 f2 30 0d 77 35 31 7a 5b 6d 3c c2 aa 11 2c 32 95 a9 4. The write callback is invoked again with application data provided to SSL_write: DATA: 17 03 03 00 45 12 24 e5 66 36 2f 28 ea 62 2e 17 4c 62 f0 38 07 7f 72 70 87 25 ba 45 ff cf f7 9f 0d 7d 48 ... I see these data arrive at the client side (Windows): DATA: 17 03 03 00 16 b6 02 b1 06 87 f2 30 0d 77 35 31 7a 5b 6d 3c c2 aa 11 2c 32 95 a9 but get the error described above. In Java I get wrong application data, so it seems to decrypt this as application data?! I saw an additional call to SSL_do_handshake in the apps/s_server.c and tried this, but it did not change anything. Is there anything else (except calling SSL_key_update) I have to take care of? Did anyone use this successfully with a Java SSLSocket? (We currently use Azul 8 which has a backport of TLSv1.3, and Azul 11). Has anyone experience with Windows Schannel against OpenSSL? I still believe that I do something wrong, because the Linux client also fails. Any hints are appreciated. Regards, Andreas From aerowolf at gmail.com Thu Jul 9 18:25:06 2020 From: aerowolf at gmail.com (Kyle Hamilton) Date: Thu, 9 Jul 2020 13:25:06 -0500 Subject: Master fails tests (mentioning # TODO Currently not supported) In-Reply-To: <8B1651A4-1108-4EE7-99B3-6663F7F8DB48@ll.mit.edu> References: <8B1651A4-1108-4EE7-99B3-6663F7F8DB48@ll.mit.edu> Message-ID: (I'm not an OpenSSL developer, but I know enough of development processes to explain what I see here. Actual OpenSSL developers should correct me if I'm wrong.) Most likely, yes this is currently expected. Since it's a dev branch, not a release branch, it's not expected to have everything internally consistent. Under test-driven development, one writes the tests for the behavior one expects to implement before one writes the code to implement that behavior. This is primarily to commit to the contract, and to ensure that the contract is fulfilled with the test data. A comment of "TODO Currently not supported" in the output of a failed test implies intent to support it in the next release, but the support hasn't yet been implemented. -Kyle H On Thu, Jul 9, 2020 at 10:22 AM Blumenthal, Uri - 0553 - MITLL wrote: > > MacOS 10.15.5, Xcode-11.5, current OpenSSL master (3.0 dev) > > Is this expected: > > > genpkey: Error setting ec_param_enc:explicit parameter: > C00D090F01000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -text => 1 > not ok 1 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (text) # TODO Currently not supported > # ------------------------------------------------------------------------------ > # Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (text)' > # at test/recipes/15-test_genec.t line 37. > genpkey: Error setting ec_param_enc:explicit parameter: > C0CDBE1601000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform PEM -out ecgen.Oakley-EC2N-3.explicit.pem => 1 > not ok 2 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (PEM) # TODO Currently not supported > # ------------------------------------------------------------------------------ > # Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (PEM)' > # at test/recipes/15-test_genec.t line 37. > genpkey: Error setting ec_param_enc:explicit parameter: > C01D251B01000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform DER -out ecgen.Oakley-EC2N-3.explicit.der => 1 > not ok 3 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (DER) # TODO Currently not supported > # ------------------------------------------------------------------------------ > # Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (DER)' > # at test/recipes/15-test_genec.t line 37. > genpkey: Error setting ec_param_enc:explicit parameter: > C07DD70A01000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -text => 1 > not ok 4 - genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' (text) # TODO Currently not supported > # ------------------------------------------------------------------------------ > # Failed (TODO) test 'genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' (text)' > # at test/recipes/15-test_genec.t line 37. > genpkey: Error setting ec_param_enc:explicit parameter: > C00D341201000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform PEM -out ecgen.Oakley-EC2N-3.explicit.pem => 1 > not ok 5 - genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' (PEM) # TODO Currently not supported > # ------------------------------------------------------------------------------ > # Failed (TODO) test 'genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' (PEM)' > # at test/recipes/15-test_genec.t line 37. > genpkey: Error setting ec_param_enc:explicit parameter: > C0FDFE1001000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform DER -out ecgen.Oakley-EC2N-3.explicit.der => 1 > not ok 6 - genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' (DER) # TODO Currently not supported > # ------------------------------------------------------------------------------ > genpkey: Error setting ec_param_enc:explicit parameter: > C09D391101000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-4' -pkeyopt 'ec_param_enc:explicit' -text => 1 > not ok 13 - genpkey EC params Oakley-EC2N-4 with ec_param_enc:'explicit' (text) # TODO Currently not supported > # ------------------------------------------------------------------------------ > # Failed (TODO) test 'genpkey EC params Oakley-EC2N-4 with ec_param_enc:'explicit' (text)' > # at test/recipes/15-test_genec.t line 37. > genpkey: Error setting ec_param_enc:explicit parameter: > C04DD91801000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-4' -pkeyopt 'ec_param_enc:explicit' -outform PEM -out ecgen.Oakley-EC2N-4.explicit.pem => 1 > not ok 14 - genpkey EC params Oakley-EC2N-4 with ec_param_enc:'explicit' (PEM) # TODO Currently not supported > # ------------------------------------------------------------------------------ > # Failed (TODO) test 'genpkey EC params Oakley-EC2N-4 with ec_param_enc:'explicit' (PEM)' > # at test/recipes/15-test_genec.t line 37. > genpkey: Error setting ec_param_enc:explicit parameter: > C0CD0E1101000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-4' -pkeyopt 'ec_param_enc:explicit' -outform DER -out ecgen.Oakley-EC2N-4.explicit.der => 1 > not ok 15 - genpkey EC params Oakley-EC2N-4 with ec_param_enc:'explicit' (DER) # TODO Currently not supported > # ------------------------------------------------------------------------------ > # Failed (TODO) test 'genpkey EC params Oakley-EC2N-4 with ec_param_enc:'explicit' (DER)' > # at test/recipes/15-test_genec.t line 37. > genpkey: Error setting ec_param_enc:explicit parameter: > C0BD080B01000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-4' -pkeyopt 'ec_param_enc:explicit' -text => 1 > not ok 16 - genpkey EC key on Oakley-EC2N-4 with ec_param_enc:'explicit' (text) # TODO Currently not supported > # ------------------------------------------------------------------------------ > # Failed (TODO) test 'genpkey EC key on Oakley-EC2N-4 with ec_param_enc:'explicit' (text)' > # at test/recipes/15-test_genec.t line 37. > genpkey: Error setting ec_param_enc:explicit parameter: > C08DB81401000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-4' -pkeyopt 'ec_param_enc:explicit' -outform PEM -out ecgen.Oakley-EC2N-4.explicit.pem => 1 > not ok 17 - genpkey EC key on Oakley-EC2N-4 with ec_param_enc:'explicit' (PEM) # TODO Currently not supported > # ------------------------------------------------------------------------------ > # Failed (TODO) test 'genpkey EC key on Oakley-EC2N-4 with ec_param_enc:'explicit' (PEM)' > # at test/recipes/15-test_genec.t line 37. > genpkey: Error setting ec_param_enc:explicit parameter: > C02D4F1401000000:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-4' -pkeyopt 'ec_param_enc:explicit' -outform DER -out ecgen.Oakley-EC2N-4.explicit.der => 1 > not ok 18 - genpkey EC key on Oakley-EC2N-4 with ec_param_enc:'explicit' (DER) # TODO Currently not supported > # ------------------------------------------------------------------------------15-test_genec.t .................... ok > > > -- > Regards, > Uri > From bkaduk at akamai.com Thu Jul 9 19:51:05 2020 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 9 Jul 2020 12:51:05 -0700 Subject: Question about SSL_key_update In-Reply-To: <20200709180741.Horde.JhFlMpwq0trMBi4pz-Ta9Bz@mail.in-chemnitz.de> References: <20200709180741.Horde.JhFlMpwq0trMBi4pz-Ta9Bz@mail.in-chemnitz.de> Message-ID: <20200709195104.GE20623@akamai.com> On Thu, Jul 09, 2020 at 06:07:41PM +0000, Andreas M?ller wrote: > Hi, > > I "inherited" our project to support/use TLSv1.3 from a late colleague. We > have a server written in C++ (Windows, Linux) > and clients (Windows, Linux, also written in C++ and also a Java client). > With Java, we use the native SSLSocket implementation, in Windows we use > Schannel and in Linux we use OpenSSL 1.1.1g. It seems to work and even > interoperability > did not show issues on some initial testing. > > I was curious about SSL_key_update. I read that other implementations use it > automatically, but with OpenSSL I have to > do it manually. So I added a > > int rc = SSL_key_update(ssl, SSL_KEY_UPDATE_REQUESTED); > > after 1000 I/O operations and looked what happened. > > I started with the Java client and it gets wrong application data in such a > situation. > > I tested with our Windows implementation (I know it may have > interoperability issues) and here I can see the > data I get from the server side and it is the same that I see on server side > in the callback, but the Windows > DecryptMessage function fails with SEC_E_INVALID_TOKEN. (I had expected > something like SEC_I_RENEGOTIATE to > get the information to put this record into InitializeSecurityContext.) > > The Linux client also aborts the connection, but here I have not yet more > details, but either the decryption fails > or the decrypted application data is wrong. Hopefully I can dig in there > next week. > > Here is what happens on server side: > > 1. I call SSL_key_update (see above) > 2. I call SSL_write with application data > 3. The write callback is invoked with this data: > DATA: 17 03 03 00 16 b6 02 b1 06 87 f2 30 0d 77 35 31 7a 5b 6d 3c c2 aa > 11 2c 32 95 a9 > 4. The write callback is invoked again with application data provided to > SSL_write: > DATA: 17 03 03 00 45 12 24 e5 66 36 2f 28 ea 62 2e 17 4c 62 f0 38 07 7f > 72 70 87 25 ba 45 ff cf f7 9f 0d 7d 48 ... > > I see these data arrive at the client side (Windows): > DATA: 17 03 03 00 16 b6 02 b1 06 87 f2 30 0d 77 35 31 7a 5b 6d 3c c2 aa > 11 2c 32 95 a9 > but get the error described above. In Java I get wrong application data, so > it seems to decrypt this as application > data?! > > I saw an additional call to SSL_do_handshake in the apps/s_server.c and > tried this, but it did not change anything. > > Is there anything else (except calling SSL_key_update) I have to take care of? Per the documentation (https://www.openssl.org/docs/man1.1.1/man3/SSL_key_update.html) it sounds like you're doing all you need to be. (In particular, you don't need to call SSL_do_handshake().) Probably the fastest way to track down what's happening is to get a full packet capture and keylog (e.g., with s_client -keylogfile path/to/log, then point wireshark at the trace+keys. -Ben From john.sha.jiang at gmail.com Thu Jul 9 22:07:51 2020 From: john.sha.jiang at gmail.com (John Jiang) Date: Fri, 10 Jul 2020 06:07:51 +0800 Subject: OCSP response signature algorithm In-Reply-To: References: Message-ID: I just got the OpenSSL ocsp tool option -rmd for specifying the digest algorithm in signature. This option is described at the below page, https://www.openssl.org/docs/manmaster/man1/openssl-ocsp.html Just out of curiosity, why isn't it at the following man page? https://www.openssl.org/docs/man1.1.1/man1/ocsp.html Though this option is supported by 1.1.1 series. On Mon, Jul 6, 2020 at 6:15 AM John Jiang wrote: > I just want to know how does OpenSSL implement RFC 6960 section 4.4.7.2 > Responder Signature Algorithm Selection. > > Could I take a OpenSSL responder to use SHA1withRSA signature algorithm > if the certificate is signed by this algorithm? > > [1] https://tools.ietf.org/html/rfc6960#section-4.4.7.2 > > On Sat, Jul 4, 2020 at 12:18 AM John Jiang > wrote: > >> Hi, >> I'm using OpenSSL 1.1.1. >> >> Can I configure the OCSP response signature algorithm? >> For a RSA issuer, it looks SHA256withRSA always be selected. >> >> PreferredSignatureAlgorithms extension in OCSP request may affect this >> algorithm in OpenSSL OCSP response. However, I prefer to use configuration. >> >> Thanks! >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajprudvi98 at gmail.com Fri Jul 10 11:55:03 2020 From: rajprudvi98 at gmail.com (prudvi raj) Date: Fri, 10 Jul 2020 17:25:03 +0530 Subject: get data from X509_EXTENSION in openSSL 1.1.1. In-Reply-To: References: Message-ID: Hi All, we are upgrading our codebase to 1.1.1 from 1.0.2k.Here's a code snippet causing error : ext = X509_get_ext(X509, n); data = ext->value->data; How do i get the data value from X509_EXTENSION object. since forward declarations are not allowed (compiler error) & i couldn't find a suitable 'getter' function. Can someone please help me out in resolving this issue.?? Thanks, Prudvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgoldman at us.ibm.com Fri Jul 10 12:09:22 2020 From: kgoldman at us.ibm.com (Kenneth Goldman) Date: Fri, 10 Jul 2020 08:09:22 -0400 Subject: get data from X509_EXTENSION in openSSL 1.1.1. In-Reply-To: References: Message-ID: > From: prudvi raj > To: openssl-users at openssl.org > Date: 07/10/2020 07:55 AM > Subject: [EXTERNAL] get data from X509_EXTENSION in openSSL 1.1.1. > Sent by: "openssl-users" > > Hi All, > > we are upgrading our codebase to 1.1.1 from 1.0.2k.Here's a code > snippet causing error : > > ?ext = X509_get_ext(X509, n); > ?data = ext->value->data; > > How do i get the?data value from X509_EXTENSION object. > since forward declarations are not allowed (compiler error) & i > couldn't find a suitable 'getter' function. > Can someone please help me out in resolving this issue.?? This may work: ASN1_BIT_STRING *keyUsage = X509_get_ext_d2i(X509Certificate, NID_key_usage, NULL, NULL); uint8_t bitmap = bitmap = keyUsage->data[0]; keyEncipherment = bitmap & (1<<5); /* bit 2 little endian */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From varunrapelly at gmail.com Fri Jul 10 12:16:44 2020 From: varunrapelly at gmail.com (Varun Rapelly) Date: Fri, 10 Jul 2020 17:46:44 +0530 Subject: Generating X509 Version 2 certificate Message-ID: Hi, I would like to create a self signed certificate with X509 version 2. I know that we need to configure "Issuer and subject unique identifiers" for X509 v2 format certificate, but not able to find the configuration required (in openssl.conf) to enable it. Please let me know how to enable the above mentioned extensions for creating X509v2 format certificate? Following below steps to create the certificate: mkdir newcerts touch index.txt echo '01' > serial cp ~/TLS_Cert/X509v2/ca.key . cp ~/TLS_Cert/X509v2/ca.crt . cp ~/TLS_Cert/X509v2/ca.cnf . read answer openssl ca -config ca.cnf -out example.org.crt -infiles request.csr cat example.org.crt Attached ca.cnf file. Thanks in advance. Varun Rapelly -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ca.cnf Type: application/octet-stream Size: 2676 bytes Desc: not available URL: From openssl-users at dukhovni.org Fri Jul 10 14:27:47 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 10 Jul 2020 10:27:47 -0400 Subject: get data from X509_EXTENSION in openSSL 1.1.1. In-Reply-To: References: Message-ID: <20200710142747.GR20025@straasha.imrryr.org> On Fri, Jul 10, 2020 at 05:25:03PM +0530, prudvi raj wrote: > we are upgrading our codebase to 1.1.1 from 1.0.2k.Here's a code snippet > causing error : > > ext = X509_get_ext(X509, n); > data = ext->value->data; Given: X509_EXTENSION *ext; you can obtain /* ext->object */ ASN1_OBJECT *oid = X509_EXTENSION_get_object(X509_EXTENSION *ext); /* ext->value, formally ASN1_OCTET_STRING, same as ASN1_STRING */ ASN1_OCTET_STRING *value = X509_EXTENSION_get_data(X509_EXTENSION *ext); from which you get: /* ASN1 type, e.g. V_ASN1_UTF8STRING */ int type = ASN1_STRING_type(value); /* Data length */ int length = ASN1_STRING_length(value); /* Data content, generally not a NUL-terminated C string */ const unsigned char *data = ASN1_STRING_get0_data(value); -- Viktor. From openssl-users at dukhovni.org Fri Jul 10 14:55:30 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 10 Jul 2020 10:55:30 -0400 Subject: Generating X509 Version 2 certificate In-Reply-To: References: Message-ID: <20200710145530.GS20025@straasha.imrryr.org> On Fri, Jul 10, 2020 at 05:46:44PM +0530, Varun Rapelly wrote: > I would like to create a self signed certificate with X509 version 2. Why exactly "version 2". Are you per chance confused by the wire encoding of X509 versions? X.509 version 1 <-> 0 in certificate version field /* original specification */ X.509 version 2 <-> 1 in certificate version field /* largely unused */ X.509 version 3 <-> 2 in certificate version field /* modern specification */ https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/keytoolDocs/x509certificates.html X.509 Version 2 introduced the concept of subject and issuer unique identifiers to handle the possibility of reuse of subject and/or issuer names over time. Most certificate profile documents strongly recommend that names not be reused, and that certificates should not make use of unique identifiers. Version 2 certificates are not widely used. > I know that we need to configure "Issuer and subject unique identifiers" > for X509 v2 format certificate, but not able to find the configuration > required (in openssl.conf) to enable it. These fields are *optional*. You do not need to set these. OpenSSL supports X.509v3, and has minimal support v2. You can inspect the optional unique ids via: void X509_get0_uids(const X509 *x, const ASN1_BIT_STRING **piuid, const ASN1_BIT_STRING **psuid) { if (piuid != NULL) *piuid = x->cert_info.issuerUID; if (psuid != NULL) *psuid = x->cert_info.subjectUID; } but there's no support for setting these, other than by parsing an ASN.1 X.509v2 encoded object that already has them. > Please let me know how to enable the above mentioned > extensions for creating X509v2 format certificate? > > Following below steps to create the certificate: > mkdir newcerts > touch index.txt > echo '01' > serial > cp ~/TLS_Cert/X509v2/ca.key . > cp ~/TLS_Cert/X509v2/ca.crt . > cp ~/TLS_Cert/X509v2/ca.cnf . > read answer > openssl ca -config ca.cnf -out example.org.crt -infiles request.csr > cat example.org.crt There is no support for encoding these deprecated fields. -- Viktor. From jenkinscolton7 at gmail.com Fri Jul 10 16:21:16 2020 From: jenkinscolton7 at gmail.com (Colton Jenkins) Date: Fri, 10 Jul 2020 12:21:16 -0400 Subject: EVP_PKEY_ASN1_METHOD(3) conflicts Message-ID: I'm currently working on implementing EVP_PKEY_cmp for ruby's openssl wrapper. Initially, I was going by the documentation provided for EVP_PKEY_cmp, but the maintainer discovered conflicting documentation. https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_ASN1_METHOD.html States the following: The param_cmp() method compares the parameters of keys *a* and *b*. It MUST return 1 when the keys are equal, 0 when not equal, or a negative number on error. It's called by EVP_PKEY_cmp_parameters(3) . However https://www.openssl.org/docs/man1.0.2/man3/EVP_PKEY_cmp.html States something slightly different: The function EVP_PKEY_cmp_parameters() and EVP_PKEY_cmp() return 1 if the keys match, 0 if they don't match, -1 if the key types are different and -2 if the operation is not supported. At this point I'm explicitly checking the type on each and not able to check -2 against a 'not supported' or in ruby 'not implemented' exception given EVP_PKEY_ASN1_METHOD(3) states ANY negative number can be an error. The current work in progress can be found here if interested. https://github.com/ruby/openssl/pull/383/files Thanks, Colton -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sun Jul 12 04:29:43 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 12 Jul 2020 00:29:43 -0400 Subject: Order of protocols in MinProtocol In-Reply-To: <20200708145838.nzygt3hzkikzxizc@uxix.de> <20200708172718.ghttxtfa6vts3u47@uxix.de> Message-ID: <20200712042943.GB20025@straasha.imrryr.org> On Wed, Jul 08, 2020 at 07:27:18PM +0200, Klaus Umbach via openssl-users wrote: > > > Should I open an issue at https://github.com/openssl/openssl/issues? > > > > Yes please. > > Done: https://github.com/openssl/openssl/issues/12394 Thanks again for opening the issue, but I have a follow up question for your original message, that is easiest to ask on the list. On Wed, Jul 08, 2020 at 04:58:39PM +0200, Klaus Umbach via openssl-users wrote: > when I set "MinProtocol" to "TLSv1.2" in openssl.cnf, DTLSv1.2 doesn't work for > the client (in my specific case openconnect). - Can you be a bit more specific about the failure mode of "openconnect"? - What are the error messages? - Can you get verbose error information? The reason I ask, is that much to my surprise, in trying to write a patch to resolve this issue, I discovered that I had already written essentially the requisite code back in 2015, but had long ago forgotten the details! Documentation improvements aside, the above 2015 code in OpenSSL already applies TLS version bounds only to TLS-based contexts, and DTLS bounds only to DTLS-based contexts. Thus you can already write: MinProtocol TLSv1.2 MinProtocol DTLSv1.2 repeating the option with appropriate settings for each of TLS and DTLS and pretty each applies to the appropriate type of SSL_CTX. The main outstanding issue for which I'm authoring a new PR, is that each of the above results in SSL_CONF_cmd() returning an error for contexts of the other type or for contexts that are for a specific fixed version of TLS or DTLS, and perhaps these errors are not ignored and cause issues with context initialisation? The update I'm writing will be more forgiving and silently report success when the setting is not applicable. That aside, clearly the documentation also needs an update. But I would like to confirm that I'm not missing some crucial detail, and therefore it would be very helpful to get a more detailed breakdown of the errors you observed, assuming that the application isn't so user-friendly as to hide all those geeky error details... :-( -- VIktor. From kurt at roeckx.be Sun Jul 12 07:35:04 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 12 Jul 2020 09:35:04 +0200 Subject: Order of protocols in MinProtocol In-Reply-To: <20200712042943.GB20025@straasha.imrryr.org> References: <20200708145838.nzygt3hzkikzxizc@uxix.de> <20200708172718.ghttxtfa6vts3u47@uxix.de> <20200712042943.GB20025@straasha.imrryr.org> Message-ID: <20200712073504.GA997029@roeckx.be> On Sun, Jul 12, 2020 at 12:29:43AM -0400, Viktor Dukhovni wrote: > > The main outstanding issue for which I'm authoring a new PR, is that > each of the above results in SSL_CONF_cmd() returning an error for > contexts of the other type or for contexts that are for a specific fixed > version of TLS or DTLS, and perhaps these errors are not ignored and > cause issues with context initialisation? The update I'm writing will > be more forgiving and silently report success when the setting is not > applicable. Looking at openconnect's code, it now supports 3 ways: - DTLSv1_client_method() with DTLS1_BAD_VER. - DTLS_client_method() with DTLS1_2_VERSION - A PSK The first 2 options will overwrite the protocol min and max version, so whatever is in the config file will not have any effect. Kurt From doctor at doctor.nl2k.ab.ca Mon Jul 13 12:06:16 2020 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 13 Jul 2020 06:06:16 -0600 Subject: openssl-1.1.1-stable-SNAP-20200713 bug Message-ID: <20200713120616.GA14266@doctor.nl2k.ab.ca> Script started on Mon Jul 13 06:01:58 2020 You have mail. root at doctor:/usr/source/openssl-1.1.1-stable-SNAP-20200713 # make make depend && make _all perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = "en_GB" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). rm -f test/ectest ${LDCMD:-/usr/local/bin/clang10} -pthread -Wa,--noexecstack -Qunused-arguments -Wall -O3 -L. -o test/ectest test/ectest.o test/libtestutil.a -lcrypto -pthread ld: error: undefined symbol: EC_GROUP_get_field_type >>> referenced by ectest.c >>> test/ectest.o:(custom_generator_test) ld: error: undefined symbol: EC_GROUP_get0_field >>> referenced by ectest.c >>> test/ectest.o:(custom_generator_test) clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[1]: stopped in /usr/source/openssl-1.1.1-stable-SNAP-20200713 *** Error code 1 Stop. make: stopped in /usr/source/openssl-1.1.1-stable-SNAP-20200713 root at doctor:/usr/source/openssl-1.1.1-stable-SNAP-20200713 # exit exit Script done on Mon Jul 13 06:02:20 2020 openssl-1.1.1-stable-SNAP-20200712 was all right. Please fix. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b We were not instructed to succumb to the world. -unknown From nic.tuv at gmail.com Mon Jul 13 17:02:06 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Mon, 13 Jul 2020 20:02:06 +0300 Subject: openssl-1.1.1-stable-SNAP-20200713 bug In-Reply-To: <20200713120616.GA14266@doctor.nl2k.ab.ca> References: <20200713120616.GA14266@doctor.nl2k.ab.ca> Message-ID: I independently reached the same failure and I opened a github issue that references this report: https://github.com/openssl/openssl/issues/12432 The fix should be coming in the form of https://github.com/openssl/openssl/pull/12433 Thanks for reporting this issue! Cheers, Nicola Tuveri -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Jul 13 18:25:52 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 13 Jul 2020 14:25:52 -0400 Subject: [openssl-users] d2i_TYPE() BCP question, distinguish malformed input from malloc error? Message-ID: <20200713182552.GF20025@straasha.imrryr.org> I am curious whether anyone has BCP recommentations for distinguishing between (presumably rare) out-of-memory or similar internal resource issues resulting in a NULL return value from d2i_TYPE() (e.g. d2i_X509()), vs. (presumably more common) issues with the input encoding? Does anyone have experiences (good or bad), and/or working code examples with trying to use the error stack to distinguish between these conditions? Would it be a good or bad idea to even try? Should OpenSSL have an alternative d2i interface: ssize_t d2i_ex_TYPE(TYPE **out, unsigned const char *buf, size_t len) where: * The out parameter is not "re-used", avoiding the d2i() pitfall. * The buffer pointer is not modified. * Success is a return value > 0. * Malformed input is a zero return value. * Internal errors (malloc, but also malformed ASN.1 type templates) yield a negative return value. This sort of thing could allow an application to distinguish permanent errors (malformed input) from transient errors (temporarily out of memory), and perhaps degrade in the appropriate way (possibly avoid resource exhaustion downgrade attacks). Of course a new API like that is a non-trivial project. I am not in a position to sign on that at present... So I'm left wondering whether anyone has worked around the issues in a reasonable way by inspecting the error stack in some reasonably reliable manner. -- Viktor. From doctor at doctor.nl2k.ab.ca Tue Jul 14 13:06:56 2020 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 14 Jul 2020 07:06:56 -0600 Subject: openssl-1.1.1-stable-SNAP-20200714 bug Re: openssl-1.1.1-stable-SNAP-20200713 bug In-Reply-To: References: <20200713120616.GA14266@doctor.nl2k.ab.ca> Message-ID: <20200714130656.GA66505@doctor.nl2k.ab.ca> On Mon, Jul 13, 2020 at 08:02:06PM +0300, Nicola Tuveri wrote: > I independently reached the same failure and I opened a github issue that > references this report: https://github.com/openssl/openssl/issues/12432 > > The fix should be coming in the form of > https://github.com/openssl/openssl/pull/12433 > > Thanks for reporting this issue! > > > Cheers, > > Nicola Tuveri And this morning we get Script started on Tue Jul 14 07:05:40 2020 root at doctor:/usr/source/openssl-1.1.1-stable-SNAP-20200714 # make make depend && make _all perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = "en_GB" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). rm -f test/ectest ${LDCMD:-/usr/local/bin/clang10} -pthread -Wa,--noexecstack -Qunused-arguments -Wall -O3 -L. -o test/ectest test/ectest.o test/libtestutil.a -lcrypto -pthread ld: error: undefined symbol: EC_GROUP_get_field_type >>> referenced by ectest.c >>> test/ectest.o:(custom_generator_test) ld: error: undefined symbol: EC_GROUP_get0_field >>> referenced by ectest.c >>> test/ectest.o:(custom_generator_test) clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[1]: stopped in /usr/source/openssl-1.1.1-stable-SNAP-20200714 *** Error code 1 Stop. make: stopped in /usr/source/openssl-1.1.1-stable-SNAP-20200714 root at doctor:/usr/source/openssl-1.1.1-stable-SNAP-20200714 # exit exit Script done on Tue Jul 14 07:05:54 2020 Error in lines 2126 and 2127 of test/ectest.c -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b We were not instructed to succumb to the world. -unknown From shivaramakrishna.ch at gmail.com Tue Jul 14 14:12:21 2020 From: shivaramakrishna.ch at gmail.com (shivaramakrishna chakravarthula) Date: Tue, 14 Jul 2020 16:12:21 +0200 Subject: Compiling OpenSSL shared libraries with custom name on Unix platforms Message-ID: Hello, Is it possible to compile OpenSSL shared libraries with custom names on Linux/ Unix platforms to avoid conflicts with installed OpenSSL libraries? I have tried to modify the SHLIB_EXT in Configure script but it is not working. I am sure it is a common problem and someone in this group can help. Thanks in advance. Thanks, Shiva -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgoldman at us.ibm.com Tue Jul 14 14:30:51 2020 From: kgoldman at us.ibm.com (Kenneth Goldman) Date: Tue, 14 Jul 2020 10:30:51 -0400 Subject: Compiling OpenSSL shared libraries with custom name on Unix platforms In-Reply-To: References: Message-ID: > From: shivaramakrishna chakravarthula > > Is it possible to compile OpenSSL shared libraries with custom > names?on Linux/ Unix platforms to avoid conflicts with installed > OpenSSL libraries? > I have tried to modify the SHLIB_EXT in Configure script but it is > not?working. I am sure it is a common problem and someone in this > group can help. If this is just for local testing, I typically build but don't install. By changing my paths, I can use the local copy. If you're sure you have ABI compatibility, could you manually copy and rename the .so files to /usr/include, /usr/local/include or equivalent? -------------- next part -------------- An HTML attachment was scrubbed... URL: From shivaramakrishna.ch at gmail.com Tue Jul 14 14:58:38 2020 From: shivaramakrishna.ch at gmail.com (shivaramakrishna chakravarthula) Date: Tue, 14 Jul 2020 16:58:38 +0200 Subject: Compiling OpenSSL shared libraries with custom name on Unix platforms In-Reply-To: References: Message-ID: Hi, I have compatibility issues for my application with new versions of OpenSSL and I want to use the older version of OpenSSL with my application. So, I want to link my application with an OpenSSL library built with the custom name so that it works fine on all systems and I can be assured of using the desired OpenSSL version. I am using RPATH to locate the libraries in runtime and I want to make sure my libraries don't conflict with existing libraries. Thanks, Shiva On Tue, 14 Jul 2020 at 16:31, Kenneth Goldman wrote: > > From: shivaramakrishna chakravarthula > > > > Is it possible to compile OpenSSL shared libraries with custom > > names on Linux/ Unix platforms to avoid conflicts with installed > > OpenSSL libraries? > > I have tried to modify the SHLIB_EXT in Configure script but it is > > not working. I am sure it is a common problem and someone in this > > group can help. > > If this is just for local testing, I typically build but don't > install. By changing my paths, I can use the local copy. > > If you're sure you have ABI compatibility, could you > manually copy and rename the .so files to /usr/include, > /usr/local/include or equivalent? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Tue Jul 14 15:56:20 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 14 Jul 2020 15:56:20 +0000 Subject: Compiling OpenSSL shared libraries with custom name on Unix platforms In-Reply-To: References: Message-ID: > From: openssl-users On Behalf Of shivaramakrishna chakravarthula > Sent: Tuesday, 14 July, 2020 08:59 > I have compatibility issues for my application with new versions of OpenSSL and > I want to use the older version of OpenSSL with my application. So, I want to > link my application with an OpenSSL library built with the custom name so that > it works fine on all systems and I can be assured of using the desired OpenSSL > version. The right way to fix this, of course, is to fix your application so it works with a current, supported OpenSSL version. Failing that, it would be best to link OpenSSL statically into your application. Then you don't have to worry about shared object location, and no one else will be using your outdated OpenSSL. -- Michael Wojcik From shivaramakrishna.ch at gmail.com Tue Jul 14 16:02:00 2020 From: shivaramakrishna.ch at gmail.com (shivaramakrishna chakravarthula) Date: Tue, 14 Jul 2020 18:02:00 +0200 Subject: Compiling OpenSSL shared libraries with custom name on Unix platforms In-Reply-To: References: Message-ID: That was something I have tried initially until I had problems with FIPS mode. I have compiled OpenSSL with FIPS support. But, I see FIPS self-tests failing when I link my application with OpenSSL static libraries. On Tue, 14 Jul 2020 at 17:57, Michael Wojcik wrote: > > From: openssl-users On Behalf Of > shivaramakrishna chakravarthula > > Sent: Tuesday, 14 July, 2020 08:59 > > > I have compatibility issues for my application with new versions of > OpenSSL and > > I want to use the older version of OpenSSL with my application. So, I > want to > > link my application with an OpenSSL library built with the custom name > so that > > it works fine on all systems and I can be assured of using the desired > OpenSSL > > version. > > The right way to fix this, of course, is to fix your application so it > works with a current, supported OpenSSL version. > > Failing that, it would be best to link OpenSSL statically into your > application. Then you don't have to worry about shared object location, and > no one else will be using your outdated OpenSSL. > > -- > Michael Wojcik > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Tue Jul 14 17:03:49 2020 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 14 Jul 2020 10:03:49 -0700 Subject: Compiling OpenSSL shared libraries with custom name on Unix platforms In-Reply-To: References: Message-ID: <20200714170348.GJ20623@akamai.com> On Tue, Jul 14, 2020 at 04:58:38PM +0200, shivaramakrishna chakravarthula wrote: > Hi, > > I have compatibility issues for my application with new versions of OpenSSL > and I want to use the older version of OpenSSL with my application. So, I > want to link my application with an OpenSSL library built with the custom > name so that it works fine on all systems and I can be assured of using the > desired OpenSSL version. I am using RPATH to locate the libraries in > runtime and I want to make sure my libraries don't conflict with existing > libraries. How old is this "older version"? The functionality you want sounds exactly like the "variant SONAMEs introduced in commit https://github.com/openssl/openssl/commit/822b5e2645a99bea15329bd66c9723c7e7119cdb but that's only in 1.1.0g and later. -Ben From shivaramakrishna.ch at gmail.com Tue Jul 14 19:08:10 2020 From: shivaramakrishna.ch at gmail.com (shivaramakrishna chakravarthula) Date: Tue, 14 Jul 2020 21:08:10 +0200 Subject: Compiling OpenSSL shared libraries with custom name on Unix platforms In-Reply-To: <20200714170348.GJ20623@akamai.com> References: <20200714170348.GJ20623@akamai.com> Message-ID: This is exactly similar to what I am looking for. I am using 1.0.2J version and there are some changes in the next version onwards that causes problems in SSL connections to older versions when DH key = 256 bytes are used. For backward compatibility reasons, I need to continue supporting 256 bytes DH keys for some more time and hence I want to stay on 1.0.2J version for now. Anyways, Thanks for sharing the details. Thanks, Shiva On Tue, 14 Jul 2020 at 19:03, Benjamin Kaduk wrote: > On Tue, Jul 14, 2020 at 04:58:38PM +0200, shivaramakrishna chakravarthula > wrote: > > Hi, > > > > I have compatibility issues for my application with new versions of > OpenSSL > > and I want to use the older version of OpenSSL with my application. So, I > > want to link my application with an OpenSSL library built with the custom > > name so that it works fine on all systems and I can be assured of using > the > > desired OpenSSL version. I am using RPATH to locate the libraries in > > runtime and I want to make sure my libraries don't conflict with existing > > libraries. > > How old is this "older version"? > > The functionality you want sounds exactly like the "variant SONAMEs > introduced > in commit > https://github.com/openssl/openssl/commit/822b5e2645a99bea15329bd66c9723c7e7119cdb > but that's only in 1.1.0g and later. > > -Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe at felipegasper.com Tue Jul 14 19:18:53 2020 From: felipe at felipegasper.com (Felipe Gasper) Date: Tue, 14 Jul 2020 15:18:53 -0400 Subject: minimum viable CSR? Message-ID: Hello, I have domains whose length exceeds the commonName maximum. To create a signing request for such a domain, then, I can?t put the domain in the CSR?s subject. Assuming that I?m interested in just a DV certificate--such that the CSR?s subject DN actually provides no useful information--what would the minimum-viable subject look like from the generation-via-OpenSSL side? Thank you! cheers, -Felipe Gasper From bkaduk at akamai.com Tue Jul 14 19:38:31 2020 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 14 Jul 2020 12:38:31 -0700 Subject: Compiling OpenSSL shared libraries with custom name on Unix platforms In-Reply-To: References: <20200714170348.GJ20623@akamai.com> Message-ID: <20200714193831.GK20623@akamai.com> On Tue, Jul 14, 2020 at 09:08:10PM +0200, shivaramakrishna chakravarthula wrote: > This is exactly similar to what I am looking for. I am using 1.0.2J version > and there are some changes in the next version onwards that causes problems > in SSL connections to older versions when DH key = 256 bytes are used. For > backward compatibility reasons, I need to continue supporting 256 bytes DH > keys for some more time and hence I want to stay on 1.0.2J version for now. > > Anyways, Thanks for sharing the details. Ah, thanks for the details. The change I linked to is not going to be of much use to you, since the build system got completely redone between those versions. I will note that, at least on some systems, you can use sed to change the SONAME of the compiled library before/during the installation process, which may be enough of a workaround for your purposes. -Ben From hkario at redhat.com Wed Jul 15 11:16:14 2020 From: hkario at redhat.com (Hubert Kario) Date: Wed, 15 Jul 2020 13:16:14 +0200 Subject: minimum viable =?iso-8859-1?Q?CSR=3F?= In-Reply-To: References: Message-ID: On Tuesday, 14 July 2020 21:18:53 CEST, Felipe Gasper wrote: > Hello, > > I have domains whose length exceeds the commonName maximum. To > create a signing request for such a domain, then, I can?t put > the domain in the CSR?s subject. > > Assuming that I?m interested in just a DV certificate--such > that the CSR?s subject DN actually provides no useful > information--what would the minimum-viable subject look like > from the generation-via-OpenSSL side? 1. Common Name is not used for host names for quite a few years now 2. most commercial CAs completely ignore any data in the CSR but the public key 3. Subject DN can be empty, if that will be accepted by CA is up to CAs policy -- 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 From felipe at felipegasper.com Wed Jul 15 11:19:31 2020 From: felipe at felipegasper.com (Felipe Gasper) Date: Wed, 15 Jul 2020 07:19:31 -0400 Subject: minimum viable CSR? In-Reply-To: References: Message-ID: <38B75B37-8A21-46DC-AF5D-1A2E9D211633@felipegasper.com> > On Jul 15, 2020, at 7:16 AM, Hubert Kario wrote: > > On Tuesday, 14 July 2020 21:18:53 CEST, Felipe Gasper wrote: >> Hello, >> >> I have domains whose length exceeds the commonName maximum. To create a signing request for such a domain, then, I can?t put the domain in the CSR?s subject. >> >> Assuming that I?m interested in just a DV certificate--such that the CSR?s subject DN actually provides no useful information--what would the minimum-viable subject look like from the generation-via-OpenSSL side? > > 1. Common Name is not used for host names for quite a few years now > 2. most commercial CAs completely ignore any data in the CSR but the public > key > 3. Subject DN can be empty, if that will be accepted by CA is up to CAs policy Making subject DN empty is what I was struggling with but eventually found a syntax that works. Thank you! -F From tomiii at tomiii.com Wed Jul 15 17:20:24 2020 From: tomiii at tomiii.com (Thomas Dwyer III) Date: Wed, 15 Jul 2020 10:20:24 -0700 Subject: OpenSSL 3.0 hangs at exit with FIPS provider Message-ID: Platform: Linux x86_64 I understand this is still alpha but how complete is the FIPS provider right now? I'm following the documentation at https://wiki.openssl.org/index.php/OpenSSL_3.0 but I'm having a problem where my application hangs during exit() when I use the "fips" provider. I reduced my code down to this minimal snippet that reproduces the problem: #include #include #include #include #include #include #include int main(int argc, char **argv) { OSSL_PROVIDER *pvdr = NULL; EVP_MD_CTX *ctx; const EVP_MD *md; char *alg = "sha1"; int rc = 0; pvdr = OSSL_PROVIDER_load(NULL, "fips"); if (pvdr == NULL) { fprintf(stderr, "Error loading FIPS provider\n"); exit(1); } md = EVP_get_digestbyname(alg); if (!digest) { fprintf(stderr, "unknown digest '%s'\n", alg); exit(1); } ctx = EVP_MD_CTX_create(); if (EVP_DigestInit_ex(ctx, md, NULL) != 1) { long err = ERR_get_error(); char *msg = ERR_error_string(err, NULL); fprintf(stderr, "EVP_DigestInit_ex() failed: %s\n", msg); exit(1); } EVP_MD_CTX_destroy(ctx); rc = OSSL_PROVIDER_unload(pvdr); if (rc != 1) { fprintf(stderr, "Error unloading FIPS provider\n"); exit(1); } printf("finished!\n"); exit(0); } When I run this it prints "finished!" and then hangs in some kind of spin loop consuming 100% CPU. Skipping the call to EVP_DigestInit_ex() allows it to exit successfully, as does inserting a call to OPENSSL_init_crypto() at the very top with the OPENSSL_INIT_NO_ATEXIT flag. Passing "default" instead of "fips" to OSSL_PROVIDER_load() also seems to work fine. What am I missing? Also, per section 7.8 of the wiki referenced above, I'm unable to confirm that the digest algorithm I want to use is being provided by the FIPS module. EVP_MD_provider(md) returns NULL even though the actual digest is computed correctly. Thanks, Tom.III -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Thu Jul 16 13:48:29 2020 From: openssl at openssl.org (OpenSSL) Date: Thu, 16 Jul 2020 13:48:29 +0000 Subject: OpenSSL version 3.0.0-alpha5 published Message-ID: <20200716134829.GA923@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 3.0 alpha 5 released ==================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 5 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha5.tar.gz Size: 13919931 SHA1 checksum: 0e2aded2b2bd2104bcee6bfcd10132a8aec87776 SHA256 checksum: 09ad89af04cbf36dbbce1fc7063e18fcc333fcaaf3eccecf22c4a99bac83e139 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha5.tar.gz openssl sha256 openssl-3.0.0-alpha5.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQJIBAEBCgAyFiEEeVOsH7w9yLOykjk+1enkP3357owFAl8QVLgUHGxldml0dGVA b3BlbnNzbC5vcmcACgkQ1enkP3357owlsxAAsESoir2B2o8zLiBgZpo24k+FGcsb zu6unJnYp0IZH+UkK+EXU4q440vpOcXaxC9zyXUKrdUp7e6iXzsVhqkTHFqkG+sE wiEjCO5VS/gPWo3Alrr1Lyzuc9EFLk5XzU0/p2MEVMwjxwHGuqshmJe5dgkv/NCa /SebPbzbKpCKnfnUhmEiiXzG8Sujit8zVl0bKSXsF0hgfm6bWzeuBUj2wqoUFmFe OlPuZ53cYYaF6Hw0XjSiW20RVJ9wD+jgJoQbos7l8QORzuOGsgxYExG0+M+0ketY W1TttXKZrPyO4qj/mdojrPOZWQQT3v5yInGI0wWLzPvXFBs4bKB088uKZQUyicd1 VJyvJBYR5K64podAoQSSjATo8zDZxts1A8JcfGKeLuIeXhhcOf+h75X0pk4+Sqaz +YQLj7lupg9Hksu8UGIcFZNc4zDvDdeFMxphAUkbnlBt7wB+sGSKMcxciYYGh7Vf 8PBTqFS3QcTe33m8KFJMNSwSNDyFILbqskltRQ4vxIquNQu3b1pgfNpKetGnQZJs hv1Ruc4o8rtkntMXx7xpY/uRnWDkdPtybZJNgUMc/iUe88p6YjXFq7q+PDtVAhYk 0EVNlU2lVjM0DZoi4aWKtqCWExJ/rFzuAeCNEXI8oFMSV3/wwE5WFv/uQC45vDuS yuGJQvyOaBjoJws= =uL/G -----END PGP SIGNATURE----- From bcloutier at integpg.com Thu Jul 16 14:03:37 2020 From: bcloutier at integpg.com (Bruce Cloutier) Date: Thu, 16 Jul 2020 10:03:37 -0400 Subject: OpenSSL version 3.0.0-alpha5 published In-Reply-To: <20200716134829.GA923@openssl.org> References: <20200716134829.GA923@openssl.org> Message-ID: <0287154b-dd35-2056-65ad-cffed2b97519@integpg.com> Where can I get the PGP key for the signature for this message? Seems not to have been uploaded to the key servers defined in my Enigmail. On 7/16/20 9:48 AM, OpenSSL wrote: > > ?? OpenSSL version 3.0 alpha 5 released > ?? ==================================== > > ?? OpenSSL - The Open Source toolkit for SSL/TLS > ?? https://www.openssl.org/ > > ?? OpenSSL 3.0 is currently in alpha. > > ?? OpenSSL 3.0 alpha 5 has now been made available. > > ?? Note: This OpenSSL pre-release has been provided for testing ONLY. > ?? It should NOT be used for security critical purposes. > > ?? Specific notes on upgrading to OpenSSL 3.0 from previous versions, > as well > ?? as known issues are available on the OpenSSL Wiki, here: > > ??????? https://wiki.openssl.org/index.php/OpenSSL_3.0 > > ?? The alpha release is available for download via HTTPS and FTP from the > ?? following master locations (you can find the various FTP mirrors under > ?? https://www.openssl.org/source/mirror.html): > > ???? * https://www.openssl.org/source/ > ???? * ftp://ftp.openssl.org/source/ > > ?? The distribution file name is: > > ??? o openssl-3.0.0-alpha5.tar.gz > ????? Size: 13919931 > ????? SHA1 checksum:? 0e2aded2b2bd2104bcee6bfcd10132a8aec87776 > ????? SHA256 checksum:? > 09ad89af04cbf36dbbce1fc7063e18fcc333fcaaf3eccecf22c4a99bac83e139 > > ?? The checksums were calculated using the following commands: > > ??? openssl sha1 openssl-3.0.0-alpha5.tar.gz > ??? openssl sha256 openssl-3.0.0-alpha5.tar.gz > > ?? Please download and check this alpha release as soon as possible. > ?? To report a bug, open an issue on GitHub: > > ??? https://github.com/openssl/openssl/issues > > ?? Please check the release notes and mailing lists to avoid duplicate > ?? reports of known issues. (Of course, the source is also available > ?? on GitHub.) > > ?? Yours, > > ?? The OpenSSL Project Team. > > > -- Sent using Thunderbird on Ubuntu 16.04LTS -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From levitte at openssl.org Thu Jul 16 14:38:53 2020 From: levitte at openssl.org (Richard Levitte) Date: Thu, 16 Jul 2020 16:38:53 +0200 Subject: OpenSSL version 3.0.0-alpha5 published In-Reply-To: <0287154b-dd35-2056-65ad-cffed2b97519@integpg.com> References: <20200716134829.GA923@openssl.org> <0287154b-dd35-2056-65ad-cffed2b97519@integpg.com> Message-ID: <87a6zzh6de.wl-levitte@openssl.org> I have it uploaded to pgp.mit.edu. It should replicate from there, I at least also found it on keys.gnupg.net. Cheers, Richard On Thu, 16 Jul 2020 16:03:37 +0200, Bruce Cloutier wrote: > > Where can I get the PGP key for the signature for this message? Seems > not to have been uploaded to the key servers defined in my Enigmail. > > > On 7/16/20 9:48 AM, OpenSSL wrote: > > > > ?? OpenSSL version 3.0 alpha 5 released > > ?? ==================================== > > > > ?? OpenSSL - The Open Source toolkit for SSL/TLS > > ?? https://www.openssl.org/ > > > > ?? OpenSSL 3.0 is currently in alpha. > > > > ?? OpenSSL 3.0 alpha 5 has now been made available. > > > > ?? Note: This OpenSSL pre-release has been provided for testing ONLY. > > ?? It should NOT be used for security critical purposes. > > > > ?? Specific notes on upgrading to OpenSSL 3.0 from previous versions, > > as well > > ?? as known issues are available on the OpenSSL Wiki, here: > > > > ??????? https://wiki.openssl.org/index.php/OpenSSL_3.0 > > > > ?? The alpha release is available for download via HTTPS and FTP from the > > ?? following master locations (you can find the various FTP mirrors under > > ?? https://www.openssl.org/source/mirror.html): > > > > ???? * https://www.openssl.org/source/ > > ???? * ftp://ftp.openssl.org/source/ > > > > ?? The distribution file name is: > > > > ??? o openssl-3.0.0-alpha5.tar.gz > > ????? Size: 13919931 > > ????? SHA1 checksum:? 0e2aded2b2bd2104bcee6bfcd10132a8aec87776 > > ????? SHA256 checksum:? > > 09ad89af04cbf36dbbce1fc7063e18fcc333fcaaf3eccecf22c4a99bac83e139 > > > > ?? The checksums were calculated using the following commands: > > > > ??? openssl sha1 openssl-3.0.0-alpha5.tar.gz > > ??? openssl sha256 openssl-3.0.0-alpha5.tar.gz > > > > ?? Please download and check this alpha release as soon as possible. > > ?? To report a bug, open an issue on GitHub: > > > > ??? https://github.com/openssl/openssl/issues > > > > ?? Please check the release notes and mailing lists to avoid duplicate > > ?? reports of known issues. (Of course, the source is also available > > ?? on GitHub.) > > > > ?? Yours, > > > > ?? The OpenSSL Project Team. > > > > > > > -- > Sent using Thunderbird on Ubuntu 16.04LTS > > > No public key for C5E3F0631FEDE337 created at 2020-07-16T16:03:37+0200 using (unknown algorithm 22) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From bcloutier at integpg.com Thu Jul 16 16:38:04 2020 From: bcloutier at integpg.com (Bruce Cloutier) Date: Thu, 16 Jul 2020 12:38:04 -0400 Subject: OpenSSL version 3.0.0-alpha5 published In-Reply-To: <87a6zzh6de.wl-levitte@openssl.org> References: <20200716134829.GA923@openssl.org> <0287154b-dd35-2056-65ad-cffed2b97519@integpg.com> <87a6zzh6de.wl-levitte@openssl.org> Message-ID: <85817a5d-640a-ecaa-06be-613bdd495936@integpg.com> Hmm.. hkps://pgp.mit.edu isn't responding for me at the moment and I was configured to use that by default. Found it on another. The dialog I got was that the key was not found but in reality the keyserver could not be reached. I'm good thanks. On 7/16/20 10:38 AM, Richard Levitte wrote: > I have it uploaded to pgp.mit.edu. It should replicate from there, I > at least also found it on keys.gnupg.net. > > Cheers, > Richard > > On Thu, 16 Jul 2020 16:03:37 +0200, > Bruce Cloutier wrote: >> Where can I get the PGP key for the signature for this message? Seems >> not to have been uploaded to the key servers defined in my Enigmail. >> >> >> On 7/16/20 9:48 AM, OpenSSL wrote: >>> ?? OpenSSL version 3.0 alpha 5 released >>> ?? ==================================== >>> >>> ?? OpenSSL - The Open Source toolkit for SSL/TLS >>> ?? https://www.openssl.org/ >>> >>> ?? OpenSSL 3.0 is currently in alpha. >>> >>> ?? OpenSSL 3.0 alpha 5 has now been made available. >>> >>> ?? Note: This OpenSSL pre-release has been provided for testing ONLY. >>> ?? It should NOT be used for security critical purposes. >>> >>> ?? Specific notes on upgrading to OpenSSL 3.0 from previous versions, >>> as well >>> ?? as known issues are available on the OpenSSL Wiki, here: >>> >>> ??????? https://wiki.openssl.org/index.php/OpenSSL_3.0 >>> >>> ?? The alpha release is available for download via HTTPS and FTP from the >>> ?? following master locations (you can find the various FTP mirrors under >>> ?? https://www.openssl.org/source/mirror.html): >>> >>> ???? * https://www.openssl.org/source/ >>> ???? * ftp://ftp.openssl.org/source/ >>> >>> ?? The distribution file name is: >>> >>> ??? o openssl-3.0.0-alpha5.tar.gz >>> ????? Size: 13919931 >>> ????? SHA1 checksum:? 0e2aded2b2bd2104bcee6bfcd10132a8aec87776 >>> ????? SHA256 checksum:? >>> 09ad89af04cbf36dbbce1fc7063e18fcc333fcaaf3eccecf22c4a99bac83e139 >>> >>> ?? The checksums were calculated using the following commands: >>> >>> ??? openssl sha1 openssl-3.0.0-alpha5.tar.gz >>> ??? openssl sha256 openssl-3.0.0-alpha5.tar.gz >>> >>> ?? Please download and check this alpha release as soon as possible. >>> ?? To report a bug, open an issue on GitHub: >>> >>> ??? https://github.com/openssl/openssl/issues >>> >>> ?? Please check the release notes and mailing lists to avoid duplicate >>> ?? reports of known issues. (Of course, the source is also available >>> ?? on GitHub.) >>> >>> ?? Yours, >>> >>> ?? The OpenSSL Project Team. >>> >>> >>> >> -- >> Sent using Thunderbird on Ubuntu 16.04LTS >> >> >> No public key for C5E3F0631FEDE337 created at 2020-07-16T16:03:37+0200 using (unknown algorithm 22) -- Sent using Thunderbird on Ubuntu 16.04LTS -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From rajprudvi98 at gmail.com Thu Jul 16 20:01:51 2020 From: rajprudvi98 at gmail.com (prudvi raj) Date: Fri, 17 Jul 2020 01:31:51 +0530 Subject: Generate opensslconf.h - openssl 1.0.2 vs openssl 1.1.1g Message-ID: Hello, How do i generate "opensslconf.h" in openssl 1.1.1g? >From docs, i assume it is created after we give "./Configure gcc". I observe that "opensslconf.h" is created only on giving "make" after ./Configure... But this additionally created .d & .o files in crypto folders. For openssl1.0.2 , the same opensslconf.h is created right after "./Configure" . (all .h files in include directory are created after ./Configure, whereas in 1.1.1 .h files appear in include directory - without any ./Configure) For context , we are upgrading our project to openssl 1.1.1g from 1.0.2k & i am concerned about this .d & .o files, in case i build the whole project - which is including openssl folder. Thanks, Prud. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonkbaby at gmail.com Fri Jul 17 00:59:35 2020 From: simonkbaby at gmail.com (SIMON BABY) Date: Thu, 16 Jul 2020 17:59:35 -0700 Subject: Query on openssl-1.1.0h build error Message-ID: Hello, I am working for a project which has dependency on openssl library. When I try to build the openssl package with below bit bake recipe (got from open embedded yocto ) it is failing with below errors.Could you please help to resolve my issue. http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/openssl/openssl_1.1.0h.bb?h=rocko sbaby at ubuntu:~/workspace$ bitbake openssl NOTE: Out of date cache found, rebuilding... *ERROR: Could not inherit file classes/multilib_header.bbclass * ERROR: Command execution failed: Exited with 1 When I commented the below two lines from the recepie, I got started build but it failed with below error marked in Red. inherit lib_package multilib_header ptest | make[1]: Entering directory `/home/sbaby/workspace/WQAR/tmp/work/mips-mv-linux/openssl-1.1.0h-r0/openssl-1.1.0h' | ( trap "rm -f crypto/aes/aes-mips.o.*" INT 0; \ | mips-montavista-linux-gnu-gcc -E -I. -Icrypto/include -Iinclude -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib32/ssl-1.1\"" -DENGINESDIR="\"/usr/lib32/engines-1.1\"" -Wall -O3 -pthread -mabi=64 -DBN_DIV3W -mips3 -fPIC -DOPENSSL_USE_NODELETE crypto/aes/aes-mips.S | \ | /usr/bin/perl -ne '/^#(line)?\s*[0-9]+/ or print' > crypto/aes/aes-mips.o.s && \ | mips-montavista-linux-gnu-gcc -march=octeon -msoft-float -mabi=n32 -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib32/ssl-1.1\"" -DENGINESDIR="\"/usr/lib32/engines-1.1\"" -Wall -O3 -pthread -mabi=64 -DBN_DIV3W -mips3 -fPIC -DOPENSSL_USE_NODELETE -c -o crypto/aes/aes-mips.o crypto/aes/aes-mips.o.s ) | Assembler messages: * | Error: -mips3 conflicts with the other architecture options, which imply -mips64r2* | make[1]: *** [crypto/aes/aes-mips.o] Error 1 | make[1]: Leaving directory `/home/sbaby/workspace/WQAR/tmp/work/mips-mv-linux/openssl-1.1.0h-r0/openssl-1.1.0h' | make: *** [all] Error 2 | + die 'oe_runmake failed' | + oefatal 'oe_runmake failed' Regards Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Fri Jul 17 09:02:25 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 17 Jul 2020 11:02:25 +0200 Subject: Generate opensslconf.h - openssl 1.0.2 vs openssl 1.1.1g In-Reply-To: References: Message-ID: <878sfih5um.wl-levitte@openssl.org> On Thu, 16 Jul 2020 22:01:51 +0200, prudvi raj wrote: > How do i? generate "opensslconf.h" in openssl 1.1.1g? > From docs, i assume it is created after we give? "./Configure gcc". > I observe that "opensslconf.h" is created only on giving "make" after ./Configure... But this > additionally created .d & .o files in crypto folders. Yes, generation of most such files have moved to the building phase rather than the configuration phase, so to say. The really quick way to get an individual file of this sort is to simply make it, i.e.: make include/openssl/opensslconf.h > For openssl1.0.2 , the same opensslconf.h is created right after "./Configure" . > (all .h files in include directory are created after ./Configure, whereas in 1.1.1 .h files appear > in include directory - without any ./Configure) Yeah, before 1.1.0, the public header files were spread around in diverse crypto/ subdirectories, and they got symlinked into include/openssl, or copied, on platforms that don't support symbolic links. We moved them permanently to include/openssl in 1.1.0, which means the symlinking is no longer needed. > For context , we are upgrading our project to openssl 1.1.1g from 1.0.2k & i am concerned about > this .d & .o files, in case i build the whole project - which is including openssl folder. I don't quite understand why .o files are a concern, they are the normal object files that are used to build up libraries and applications, and are produced in OpenSSL before 1.1.0 as well. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From tomiii at tomiii.com Fri Jul 17 16:57:11 2020 From: tomiii at tomiii.com (Thomas Dwyer III) Date: Fri, 17 Jul 2020 09:57:11 -0700 Subject: [SOLVED] Re: OpenSSL 3.0 hangs at exit with FIPS provider Message-ID: It turns out the problem was caused by a misinterpretation of the phrase "add the following lines near the beginning" in section 7.1 of the documentation at https://wiki.openssl.org/index.php/OpenSSL_3.0 for enabling FIPS support. I added these lines to the very top of the file: openssl_conf = openssl_init .include /usr/local/ssl/fipsmodule.cnf [openssl_init] providers = provider_sect [provider_sect] fips = fips_sect This caused the existing default section to now become part of the [provider_sect] section. Apparently any name=value line in that particular section where no [value] section exists causes OpenSSL to hang at exit when the FIPS provider is used. I consider this a bug, of course, but at least now I know what's causing it and how to work around it. Regarding how to confirm which provider is actually providing a given algorithm, I found that EVP_MD_provider() returns NULL for any EVP_MD obtained via EVP_get_digestbyname() (even after it's used successfully by EVP_DigestInit_ex()) but it returns a valid OSSL_PROVIDER for any EVP_MD obtained via EVP_MD_fetch(). Is this intentional? Tom.III On Wed, Jul 15, 2020 at 10:20 AM Thomas Dwyer III wrote: > Platform: Linux x86_64 > > I understand this is still alpha but how complete is the FIPS provider > right now? I'm following the documentation at > https://wiki.openssl.org/index.php/OpenSSL_3.0 but I'm having a problem > where my application hangs during exit() when I use the "fips" provider. I > reduced my code down to this minimal snippet that reproduces the problem: > > #include > #include > #include > #include > #include > #include > #include > > int > main(int argc, char **argv) > { > OSSL_PROVIDER *pvdr = NULL; > EVP_MD_CTX *ctx; > const EVP_MD *md; > char *alg = "sha1"; > int rc = 0; > > pvdr = OSSL_PROVIDER_load(NULL, "fips"); > if (pvdr == NULL) { > fprintf(stderr, "Error loading FIPS provider\n"); > exit(1); > } > > md = EVP_get_digestbyname(alg); > if (!md) { > fprintf(stderr, "unknown digest '%s'\n", alg); > exit(1); > } > > ctx = EVP_MD_CTX_create(); > > if (EVP_DigestInit_ex(ctx, md, NULL) != 1) { > long err = ERR_get_error(); > char *msg = ERR_error_string(err, NULL); > fprintf(stderr, "EVP_DigestInit_ex() failed: %s\n", msg); > exit(1); > } > > EVP_MD_CTX_destroy(ctx); > > rc = OSSL_PROVIDER_unload(pvdr); > if (rc != 1) { > fprintf(stderr, "Error unloading FIPS provider\n"); > exit(1); > } > > printf("finished!\n"); > exit(0); > } > > When I run this it prints "finished!" and then hangs in some kind of spin > loop consuming 100% CPU. Skipping the call to EVP_DigestInit_ex() allows it > to exit successfully, as does inserting a call to OPENSSL_init_crypto() at > the very top with the OPENSSL_INIT_NO_ATEXIT flag. Passing "default" > instead of "fips" to OSSL_PROVIDER_load() also seems to work fine. What am > I missing? > > Also, per section 7.8 of the wiki referenced above, I'm unable to confirm > that the digest algorithm I want to use is being provided by the FIPS > module. EVP_MD_provider(md) returns NULL even though the actual digest is > computed correctly. > > > Thanks, > Tom.III > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonkbaby at gmail.com Sat Jul 18 06:21:14 2020 From: simonkbaby at gmail.com (SIMON BABY) Date: Fri, 17 Jul 2020 23:21:14 -0700 Subject: build error Message-ID: Hi, I am getting the below build error with latest openssl 1.1.1g version. Can someone please help to resolve this issue? ERROR: Failure expanding variable None, expression was libcrypto libssl openssl-conf openssl-engines openssl-misc ${@bb.utils.contains('PTEST_ENABLED', '1', 'openssl-ptest', '', d)} openssl-dbg openssl openssl-doc openssl-dev openssl-static openssl-locale openssl-bin which triggered exception AttributeError: 'module' object has no attribute 'contains' ERROR: Command execution failed: Exited with 1 Regards Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Sat Jul 18 08:06:31 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 18 Jul 2020 08:06:31 +0000 Subject: [SOLVED] Re: OpenSSL 3.0 hangs at exit with FIPS provider In-Reply-To: References: Message-ID: Thomas, > I consider this a bug, of course, but at least now I know what's causing it and how to work around it. thanks for sharing your analysis. Would you mind creating a GitHub issue for the hang? https://github.com/openssl/openssl/issues Matthias From: openssl-users On Behalf Of Thomas Dwyer III Sent: Friday, July 17, 2020 6:57 PM To: openssl-users Subject: [SOLVED] Re: OpenSSL 3.0 hangs at exit with FIPS provider It turns out the problem was caused by a misinterpretation of the phrase "add the following lines near the beginning" in section 7.1 of the documentation at https://wiki.openssl.org/index.php/OpenSSL_3.0 for enabling FIPS support. I added these lines to the very top of the file: openssl_conf = openssl_init .include /usr/local/ssl/fipsmodule.cnf [openssl_init] providers = provider_sect [provider_sect] fips = fips_sect This caused the existing default section to now become part of the [provider_sect] section. Apparently any name=value line in that particular section where no [value] section exists causes OpenSSL to hang at exit when the FIPS provider is used. I consider this a bug, of course, but at least now I know what's causing it and how to work around it. Regarding how to confirm which provider is actually providing a given algorithm, I found that EVP_MD_provider() returns NULL for any EVP_MD obtained via EVP_get_digestbyname() (even after it's used successfully by EVP_DigestInit_ex()) but it returns a valid OSSL_PROVIDER for any EVP_MD obtained via EVP_MD_fetch(). Is this intentional? Tom.III -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Jul 20 11:45:02 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 20 Jul 2020 12:45:02 +0100 Subject: OpenSSL 3.0 hangs at exit with FIPS provider In-Reply-To: References: Message-ID: On 15/07/2020 18:20, Thomas Dwyer III wrote: > Platform: Linux x86_64 > > I understand this is still alpha but how complete is the FIPS provider > right now? Fairly complete. Please could you raise this as a github issue so that it can be properly investigated and tracked? > When I run this it prints "finished!" and then hangs in some kind of > spin loop consuming 100% CPU. Skipping the call to EVP_DigestInit_ex() > allows it to exit successfully, as does inserting a call to > OPENSSL_init_crypto() at the very top with the OPENSSL_INIT_NO_ATEXIT > flag. Passing "default" instead of "fips" to OSSL_PROVIDER_load() also > seems to work fine. What am I missing? > > Also, per section 7.8 of the wiki referenced above, I'm unable to > confirm that the digest algorithm I want to use is being provided by the > FIPS module. EVP_MD_provider(md) returns NULL even though the actual > digest is computed correctly. You need to explicitly fetch your md using EVP_MD_fetch(). The md you are using at the moment has no associated provider - one is implicitly fetched and used during the EVP_DigestInit_ex() call - but that doesn't affect the md object. By using "EVP_MD_fetch()" you can make the fetch explicit and EVP_MD_provider() should return the expected results. Matt > > > Thanks, > Tom.III > > From d.avion at slmail.me Mon Jul 20 16:23:41 2020 From: d.avion at slmail.me (d) Date: Mon, 20 Jul 2020 18:23:41 +0200 (CEST) Subject: Memory leak Message-ID: No memory leakage, if I comment out all SSL related constructs from my code. Thus, the SSL related code parts seem to be the cause of this leak. What is the issue here? Makefile: CC=clang CFLAGS=-g -Wextra -Wall -Werror -pedantic -std=c89 -lssl -fsanitize=address -fno-omit-frame-pointer .PHONY: clean test: main.c $(CC) $(CFLAGS) $^ -o $@ clean: rm -rf test Code: #define _DEFAULT_SOURCE #include #include #include #include #include #include #include #include #include #include #include int main(int argc, char **argv) { int sfd = 0; int ret = 0; struct addrinfo *result = NULL; struct addrinfo *rp = NULL; SSL_CTX *ssl_ctx = NULL; SSL *ssl = NULL; /* Socket initialization and connection */ sfd = socket(AF_INET, SOCK_STREAM, 0); assert(sfd != -1); { const unsigned int min_argc = 4; assert(argc == min_argc); } ret = getaddrinfo(argv[1], argv[2], NULL, &result); assert(ret != -1); for (rp = result; rp != NULL; rp = rp->ai_next) { if (connect(sfd, rp->ai_addr, rp->ai_addrlen) != -1) break; } /* SSL initialization */ SSL_load_error_strings(); SSL_library_init(); ssl_ctx = SSL_CTX_new(SSLv23_client_method()); ssl = SSL_new(ssl_ctx); SSL_set_fd(ssl, sfd); ret = SSL_connect(ssl); assert(ret != -1); /* HTTP requests */ { const size_t buf_sz = atoi(argv[3]); const unsigned int max = 30; char *buf = (char *)calloc(buf_sz + 1, sizeof(char)); strncat(buf, "GET / HTTP/1.1\r\nHost: ", max); strncat(buf, argv[1], max); strncat(buf, "\r\n\r\n", max); ret = SSL_write(ssl, buf, strlen(buf) + 1); assert(ret != -1); free(buf); } { const size_t buf_sz = atoi(argv[3]); char *buf = (char *)calloc(buf_sz + 1, sizeof(char)); assert(buf); ret = SSL_read(ssl, buf, buf_sz); assert(ret != -1); printf("%s\n", buf); free(buf); } /* Clean up */ SSL_free(ssl); close(sfd); return 0; } Program output: user at user-ubuntu:~/projects/https$ ./test finance.yahoo.com 443 1024 HTTP/1.1 200 OK Referrer-Policy: no-referrer-when-downgrade Strict-Transport-Security: max-age=15552000 X-Frame-Options: SAMEORIGIN Content-Security-Policy: sandbox allow-downloads allow-forms allow-modals allow-same-origin allow-scripts allow-popups allow-popups-to-escape-sandbox allow-top-navigation-by-user-activation allow-presentation; Content-Type: text/html; charset=utf-8 Set-Cookie: B=8mraj0lfhbaol&b=3&s=r7; expires=Mon, 20-Jul-2021 14:32:53 GMT; path=/; domain=.yahoo.com Date: Mon, 20 Jul 2020 14:32:53 GMT Server: ATS Cache-Control: max-age=0, private Expires: -1 Age: 0 Transfer-Encoding: chunked Connection: keep-alive Expect-CT: max-age=31536000, report-uri="http://csp.yahoo.com/beacon/csp?src=yahoocom-expect-ct-report-only" X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff ================================================================= ==28089==ERROR: LeakSanitizer: detected memory leaks Direct leak of 1024 byte(s) in 1 object(s) allocated from: ??? #0 0x493aed in malloc (/home/user/projects/https/test+0x493aed) ??? #1 0x7f59b7cf88cd in CRYPTO_zalloc (/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x17b8cd) ??? #2 0x7f59b7e7a0b2 in __libc_start_main /build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16 Direct leak of 64 byte(s) in 1 object(s) allocated from: ??? #0 0x493aed in malloc (/home/user/projects/https/test+0x493aed) ??? #1 0x7f59b7f59be9 in gaih_inet /build/glibc-YYA7BZ/glibc-2.31/posix/../sysdeps/posix/getaddrinfo.c:1058:18 ??? #2 0x7f59b7f5bf48 in getaddrinfo /build/glibc-YYA7BZ/glibc-2.31/posix/../sysdeps/posix/getaddrinfo.c:2256:12 ??? #3 0x442e3a in getaddrinfo (/home/user/projects/https/test+0x442e3a) ??? #4 0x4c349c in main /home/user/projects/https/main.c:30:11 ??? #5 0x7f59b7e7a0b2 in __libc_start_main /build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16 Indirect leak of 1712 byte(s) in 19 object(s) allocated from: ??? #0 0x493aed in malloc (/home/user/projects/https/test+0x493aed) ??? #1 0x7f59b7cf88cd in CRYPTO_zalloc (/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x17b8cd) Indirect leak of 504 byte(s) in 1 object(s) allocated from: ??? #0 0x493e09 in realloc (/home/user/projects/https/test+0x493e09) ??? #1 0x7f59b7d5b464? (/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x1de464) Indirect leak of 504 byte(s) in 1 object(s) allocated from: ??? #0 0x493aed in malloc (/home/user/projects/https/test+0x493aed) ??? #1 0x7f59b7d5ba48 in OPENSSL_sk_dup (/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x1dea48) Indirect leak of 456 byte(s) in 6 object(s) allocated from: ??? #0 0x493aed in malloc (/home/user/projects/https/test+0x493aed) ??? #1 0x7f59b7f59a59 in gaih_inet /build/glibc-YYA7BZ/glibc-2.31/posix/../sysdeps/posix/getaddrinfo.c:1058:18 ??? #2 0x7f59b7f5bf48 in getaddrinfo /build/glibc-YYA7BZ/glibc-2.31/posix/../sysdeps/posix/getaddrinfo.c:2256:12 ??? #3 0x442e3a in getaddrinfo (/home/user/projects/https/test+0x442e3a) ??? #4 0x4c349c in main /home/user/projects/https/main.c:30:11 ??? #5 0x7f59b7e7a0b2 in __libc_start_main /build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16 Indirect leak of 320 byte(s) in 5 object(s) allocated from: ??? #0 0x493aed in malloc (/home/user/projects/https/test+0x493aed) ??? #1 0x7f59b7f59be9 in gaih_inet /build/glibc-YYA7BZ/glibc-2.31/posix/../sysdeps/posix/getaddrinfo.c:1058:18 ??? #2 0x7f59b7f5bf48 in getaddrinfo /build/glibc-YYA7BZ/glibc-2.31/posix/../sysdeps/posix/getaddrinfo.c:2256:12 ??? #3 0x442e3a in getaddrinfo (/home/user/projects/https/test+0x442e3a) ??? #4 0x4c349c in main /home/user/projects/https/main.c:30:11 ??? #5 0x7f59b7e7a0b2 in __libc_start_main /build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16 Indirect leak of 32 byte(s) in 1 object(s) allocated from: ??? #0 0x493aed in malloc (/home/user/projects/https/test+0x493aed) ??? #1 0x7f59b7d5b9f3 in OPENSSL_sk_dup (/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x1de9f3) SUMMARY: AddressSanitizer: 4616 byte(s) leaked in 35 allocation(s). -------------- next part -------------- An HTML attachment was scrubbed... URL: From logout at free.fr Mon Jul 20 16:57:52 2020 From: logout at free.fr (Emmanuel Deloget) Date: Mon, 20 Jul 2020 18:57:52 +0200 Subject: Memory leak In-Reply-To: References: Message-ID: Hello "d", On Mon, Jul 20, 2020 at 6:23 PM d via openssl-users < openssl-users at openssl.org> wrote: > No memory leakage, if I comment out all SSL related constructs from my > code. > Thus, the SSL related code parts seem to be the cause of this leak. > What is the issue here? > Makefile: > SSL_CTX_new() shall be paired with SSL_CTX_free(). Best regards, -- Emmanuel Deloget -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomiii at tomiii.com Mon Jul 20 17:47:57 2020 From: tomiii at tomiii.com (Thomas Dwyer III) Date: Mon, 20 Jul 2020 10:47:57 -0700 Subject: [SOLVED] Re: OpenSSL 3.0 hangs at exit with FIPS provider In-Reply-To: References: Message-ID: I just created https://github.com/openssl/openssl/issues/12496 for this. Regards, Tom.III On Sat, Jul 18, 2020 at 1:06 AM Dr. Matthias St. Pierre < Matthias.St.Pierre at ncp-e.com> wrote: > Thomas, > > > > > I consider this a bug, of course, but at least now I know what's causing > it and how to work around it. > > > > thanks for sharing your analysis. Would you mind creating a GitHub issue > for the hang? > > > > https://github.com/openssl/openssl/issues > > > > Matthias > > > > > > > > *[image: NCP engingeering GmbH]* *Dr. Matthias St. Pierre* > > Senior Software Engineer > matthias.st.pierre at ncp-e.com > Phone: +49 911 9968-0 > www.ncp-e.com > > > * Follow us on:* Facebook | > Twitter | Xing > | YouTube > | LinkedIn > > > *Headquarters Germany: *NCP engineering GmbH ? Dombuehler Str. 2 ? 90449 > ? Nuremberg > *North American HQ:* NCP engineering Inc. ? 601 Cleveland Str., Suite > 501-25 ? Clearwater, FL 33755 > > Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate > Dietrich > Registry Court: Lower District Court of Nuremberg > Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE > 133557619 > > This e-mail message including any attachments is for the sole use of the > intended recipient(s) and may contain privileged or confidential > information. Any unauthorized review, use, disclosure or distribution is > prohibited. If you are not the intended recipient, please immediately > contact the sender by reply e-mail and delete the original message and > destroy all copies thereof. > > > > > *From:* openssl-users *On Behalf Of *Thomas > Dwyer III > *Sent:* Friday, July 17, 2020 6:57 PM > *To:* openssl-users > *Subject:* [SOLVED] Re: OpenSSL 3.0 hangs at exit with FIPS provider > > > > It turns out the problem was caused by a misinterpretation of the phrase > "add the following lines near the beginning" in section 7.1 of the > documentation at https://wiki.openssl.org/index.php/OpenSSL_3.0 for > enabling FIPS support. I added these lines to the very top of the file: > > > > openssl_conf = openssl_init > > > > .include /usr/local/ssl/fipsmodule.cnf > > > > [openssl_init] > > providers = provider_sect > > > > [provider_sect] > > fips = fips_sect > > > > This caused the existing default section to now become part of the > [provider_sect] section. Apparently any name=value line in that particular > section where no [value] section exists causes OpenSSL to hang at exit when > the FIPS provider is used. I consider this a bug, of course, but at least > now I know what's causing it and how to work around it. > > > > Regarding how to confirm which provider is actually providing a given > algorithm, I found that EVP_MD_provider() returns NULL for any EVP_MD > obtained via EVP_get_digestbyname() (even after it's used successfully by > EVP_DigestInit_ex()) but it returns a valid OSSL_PROVIDER for any EVP_MD > obtained via EVP_MD_fetch(). Is this intentional? > > > > > > Tom.III > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: NCP_logo_2f45208a-c14d-4000-bcd3-1ab400c0e48c.gif Type: image/gif Size: 2815 bytes Desc: not available URL: From cryptearth at cryptearth.de Tue Jul 21 02:20:27 2020 From: cryptearth at cryptearth.de (cryptearth) Date: Tue, 21 Jul 2020 04:20:27 +0200 Subject: TLSv1.3, AES and Apache2 on opensuse leap 15.2 Message-ID: <3d777797-eaec-9be0-26bd-589e4b08cc42@cryptearth.de> first of: as I'm not sure what's causing this issue I'll post this question on these locations: opensuse official forums https://forums.opensuse.org/showthread.php/541909-TLSv1-3-AES-and-Apache2 apache httpd mailing list openssl mailing list As OpenSuSE 15.2 recently released with openssl 1.1.1 in its repos it's now possible to use TLSv1.3 with Apache2 out of the box. As I use the TLS test on ssllabs.com as a reference I encountered some issues I'd like to ask for help to fix. First of, as most important, the used versions: apache2: 2.4.43-lp152.1.1 openssl: 1.1.1d-lp152.1.1 And here's the config (only used ssl-global.conf for this test): SSLProtocol -all +TLSv1.2 +TLSv1.3 SSLCipherSuite TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-RSA-CHACHA20-POLY1305HE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384HE-RSA-AES256-GCM-SHA384 SSLOpenSSLConfCmd Curves secp521r1:secp384r1 There were no other changes made to any other conf. As one can see I only enabled AES with 256 bit keylength and ordered chacha20 preferred over AES. But when testing with ssllabs.com server test it shows two issues I'm unable to solve myself: 1) although not enabled the server test also shows AES with only 128 bit keylength enabled and working - hence capping the score to only 90% for cipher strength (only ciphers with an equivalent of at least RSA 4096 give one full 100%) 2) the order doesn'T match the config - it shows AES256 as the most preferred one, then followed by the chacha20 and finally the AES128 As I don't know if this is an issue with apache, openssl or opensuse I posted it on all three to reach most group of people, so, if you're member of more than one of the mentioned I apologize if you get this topic multiple times. Thanks in advance to anyone, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.pluem at gmx.de Tue Jul 21 06:40:39 2020 From: r.pluem at gmx.de (=?UTF-8?B?UsO8ZGlnZXIgUGzDvG0=?=) Date: Tue, 21 Jul 2020 08:40:39 +0200 Subject: TLSv1.3, AES and Apache2 on opensuse leap 15.2 In-Reply-To: <3d777797-eaec-9be0-26bd-589e4b08cc42@cryptearth.de> References: <3d777797-eaec-9be0-26bd-589e4b08cc42@cryptearth.de> Message-ID: On 7/21/20 4:20 AM, cryptearth wrote: > first of: as I'm not sure what's causing this issue I'll post this question on these locations: > opensuse official forums https://forums.opensuse.org/showthread.php/541909-TLSv1-3-AES-and-Apache2 > apache httpd mailing list > openssl mailing list > > As OpenSuSE 15.2 recently released with openssl 1.1.1 in its repos it's now possible to use TLSv1.3 with Apache2 out of the box. > As I use the TLS test on ssllabs.com as a reference I encountered some issues I'd like to ask for help to fix. > First of, as most important, the used versions: > > apache2: 2.4.43-lp152.1.1 > openssl: 1.1.1d-lp152.1.1 > > And here's the config (only used ssl-global.conf for this test): > > SSLProtocol -all +TLSv1.2 +TLSv1.3 > SSLCipherSuite > TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-RSA-CHACHA20-POLY1305HE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384HE-RSA-AES256-GCM-SHA384 Try replacing the one SSLCiphersuite directive above with the below two ones: SSLCipherSuite ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384 SSLCipherSuite TLSv1.3 TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384 See http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslciphersuite Regards R?diger From cryptearth at cryptearth.de Tue Jul 21 08:42:41 2020 From: cryptearth at cryptearth.de (cryptearth) Date: Tue, 21 Jul 2020 10:42:41 +0200 Subject: TLSv1.3, AES and Apache2 on opensuse leap 15.2 In-Reply-To: References: <3d777797-eaec-9be0-26bd-589e4b08cc42@cryptearth.de> Message-ID: <9b6d19c1-0c56-ed50-f889-afb4d2d3e806@cryptearth.de> Hello R?diger, I got the same reply on the opensuse forums. Yes, it does "fix" my "issue", but as the reply on the forums noted: AES128 is mandatory for a 1.3 compliant implementation, as for why: I guess we all can come up with some three letter shorts without mentioning them by name. As for the ssllabs.com test: As I dug deeper in this "1.3 requires 128" I found an issue on github talking about it. At first there was a penalty in place for not supporting the mandatory AES128, but this ended up in no matter if AES128 was supported or not the test ended up with a penalty either way, one for supporting AES128 - the other for not following the RFC. The latter one was removed so although technical any server not supporting AES128 doesn't fully follow the standard the folks over at ssllabs.com seem to see the increased security is more important than to follow the [insert some north-american three letter short here] "recommandation". Anyway - as the test now shows the desired result I mark this topic as solved for now. Matt Am 21.07.2020 um 08:40 schrieb R?diger Pl?m: > > On 7/21/20 4:20 AM, cryptearth wrote: >> first of: as I'm not sure what's causing this issue I'll post this question on these locations: >> opensuse official forums https://forums.opensuse.org/showthread.php/541909-TLSv1-3-AES-and-Apache2 >> apache httpd mailing list >> openssl mailing list >> >> As OpenSuSE 15.2 recently released with openssl 1.1.1 in its repos it's now possible to use TLSv1.3 with Apache2 out of the box. >> As I use the TLS test on ssllabs.com as a reference I encountered some issues I'd like to ask for help to fix. >> First of, as most important, the used versions: >> >> apache2: 2.4.43-lp152.1.1 >> openssl: 1.1.1d-lp152.1.1 >> >> And here's the config (only used ssl-global.conf for this test): >> >> SSLProtocol -all +TLSv1.2 +TLSv1.3 >> SSLCipherSuite >> TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-RSA-CHACHA20-POLY1305HE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384HE-RSA-AES256-GCM-SHA384 > Try replacing the one SSLCiphersuite directive above with the below two ones: > > SSLCipherSuite ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384 > SSLCipherSuite TLSv1.3 TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384 > > See http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslciphersuite > > Regards > > R?diger > From matt at openssl.org Tue Jul 21 10:42:20 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Jul 2020 11:42:20 +0100 Subject: TLSv1.3, AES and Apache2 on opensuse leap 15.2 In-Reply-To: <9b6d19c1-0c56-ed50-f889-afb4d2d3e806@cryptearth.de> References: <3d777797-eaec-9be0-26bd-589e4b08cc42@cryptearth.de> <9b6d19c1-0c56-ed50-f889-afb4d2d3e806@cryptearth.de> Message-ID: <4cdb957d-3a2f-eded-9b5c-34f06b1b2379@openssl.org> On 21/07/2020 09:42, cryptearth wrote: > Hello R?diger, > > I got the same reply on the opensuse forums. > Yes, it does "fix" my "issue", but as the reply on the forums noted: > AES128 is mandatory for a 1.3 compliant implementation, AES128 is mandatory-to-implement for an RFC compliant implementation of TLSv1.3. AFAIK it is *not* mandatory for a client to offer it, nor is it mandatory for a server to accept it. Its just that the implementation has to be *able* to do it. There should be no problems with you configuring things to not offer or accept AES128. Matt > as for why: I > guess we all can come up with some three letter shorts without > mentioning them by name. > As for the ssllabs.com test: As I dug deeper in this "1.3 requires 128" > I found an issue on github talking about it. At first there was a > penalty in place for not supporting the mandatory AES128, but this ended > up in no matter if AES128 was supported or not the test ended up with a > penalty either way, one for supporting AES128 - the other for not > following the RFC. The latter one was removed so although technical any > server not supporting AES128 doesn't fully follow the standard the folks > over at ssllabs.com seem to see the increased security is more important > than to follow the [insert some north-american three letter short here] > "recommandation". > > Anyway - as the test now shows the desired result I mark this topic as > solved for now. > > Matt > > Am 21.07.2020 um 08:40 schrieb R?diger Pl?m: >> >> On 7/21/20 4:20 AM, cryptearth wrote: >>> first of: as I'm not sure what's causing this issue I'll post this >>> question on these locations: >>> opensuse official forums >>> https://forums.opensuse.org/showthread.php/541909-TLSv1-3-AES-and-Apache2 >>> >>> apache httpd mailing list >>> openssl mailing list >>> >>> As OpenSuSE 15.2 recently released with openssl 1.1.1 in its repos >>> it's now possible to use TLSv1.3 with Apache2 out of the box. >>> As I use the TLS test on ssllabs.com as a reference I encountered >>> some issues I'd like to ask for help to fix. >>> First of, as most important, the used versions: >>> >>> apache2: 2.4.43-lp152.1.1 >>> openssl: 1.1.1d-lp152.1.1 >>> >>> And here's the config (only used ssl-global.conf for this test): >>> >>> SSLProtocol -all +TLSv1.2 +TLSv1.3 >>> SSLCipherSuite >>> TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-RSA-CHACHA20-POLY1305HE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384HE-RSA-AES256-GCM-SHA384 >>> >> Try replacing the one SSLCiphersuite directive above with the below >> two ones: >> >> SSLCipherSuite >> ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384 >> >> SSLCipherSuite TLSv1.3 >> TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384 >> >> See http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslciphersuite >> >> Regards >> >> R?diger >> > From rajprudvi98 at gmail.com Tue Jul 21 19:19:05 2020 From: rajprudvi98 at gmail.com (prudvi raj) Date: Wed, 22 Jul 2020 00:49:05 +0530 Subject: "rsa->meth->rsa_sign" method in Openssl 1.1.1g Message-ID: While upgrading to openssl 1.1.1 from 1.0.2k . I came across this code snippet : if (rsa->flags & RSA_FLAG_SIGN_VER) return rsa->meth->rsa_sign (type, m, lLen, sigret, siglen, rsa); >From Docs : Enhance RSA_METHOD structure. Now there are two extra methods, rsa_sign and rsa_verify. When the RSA_FLAGS_SIGN_VER option is set these functions will be called when RSA_sign() and RSA_verify() are used. /* * New sign and verify functions: some libraries don't allow arbitrary * data to be signed/verified: this allows them to be used. Note: for * this to work the RSA_public_decrypt() and RSA_private_encrypt() should * *NOT* be used RSA_sign(), RSA_verify() should be used instead. */ In Latest Openssl 1.1.1 : -- RSA_FLAG_SIGN_VER is not required . To get flags : RSA_flags(rsa). -- "struct rsa_meth_st" has "rsa_sign" declared as a function pointer . I cannot find any actual function definition that the above "meth->rsa_sign " might point to , which can be called as this forward declaration is not allowed anymore . Maybe "RSA_sign()" ?? Moreover , "RSA_sign()" function has the same return code snippet above. . So, what is a suitable replacement for the above snippet in openssl 1.1.1g ?? Can Someone help me on this !!, TIA . Regards, Prud. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Jul 22 08:18:01 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 22 Jul 2020 09:18:01 +0100 Subject: "rsa->meth->rsa_sign" method in Openssl 1.1.1g In-Reply-To: References: Message-ID: <78936d3d-da93-64af-e1d7-5b0d158c6241@openssl.org> On 21/07/2020 20:19, prudvi raj wrote: > > While upgrading to openssl 1.1.1 from 1.0.2k . > I came across this code snippet : > ? ? if (rsa->flags & RSA_FLAG_SIGN_VER) > ? ? ? ? return rsa->meth->rsa_sign (type, m, lLen, sigret, siglen, rsa); > > From Docs : > Enhance RSA_METHOD structure. Now there are two extra methods, rsa_sign? > and rsa_verify. When the RSA_FLAGS_SIGN_VER option is set these > functions will be called when RSA_sign() and RSA_verify() are used. > ? ? /* ? > ? ? ?* New sign and verify functions: some libraries don't allow arbitrary > ? ? ?* data to be signed/verified: this allows them to be used. Note: for > ? ? ?* this to work the RSA_public_decrypt() and RSA_private_encrypt() > should * *NOT* be used RSA_sign(), RSA_verify() should be used instead. > ? ? ?*/ > > ?In Latest Openssl 1.1.1 :?? > -- RSA_FLAG_SIGN_VER is not required . To get flags :?RSA_flags(rsa).? > -- "struct rsa_meth_st" has? "rsa_sign" declared as a function pointer > .? I cannot find any actual function definition that the above > "meth->rsa_sign " might point to , which can be called as this forward > declaration is not allowed anymore . Maybe "RSA_sign()" ?? No need to check the flag. Just call RSA_sign(). Matt From luca.dimauro at cnit.it Wed Jul 22 09:11:53 2020 From: luca.dimauro at cnit.it (Luca Di Mauro) Date: Wed, 22 Jul 2020 11:11:53 +0200 Subject: Wrong HMAC in the implementation of ECIES IEEE1363a Message-ID: Hi guys, I have to implement the ECIES scheme as specified at https://wiki.plugtests.net/ITS-CMS6/images/4/4a/1609.2-consolidated-v4-d8-clean.pdf paragraph 5.3.5, with the KDF and encryption function specified here https://www.etsi.org/deliver/etsi_ts/102900_102999/102941/01.03.01_60/ts_102941v010301p.pdf at annex E. I wrote an implementation, but the HMAC seems to be wrong. Here I compute the shared secret and the HMAC value with: // Computing shared secret using ECSVDP-DHC EC_KEY_set_flags(osslEphKey, EC_FLAG_COFACTOR_ECDH); ECDH_compute_key(K, sizeof(K), osslEncPubKey, osslEphKey, &(this->etsiKdf)); free(osslEncPubKey); free(osslEphKey); // Setting Ke value (the left-most 16 byte of K) std::memcpy(Ke, K, Ke_KEY_LENGTH); // Setting Km value (the remaining 256 bits of K) memcpy(Km, K+Ke_KEY_LENGTH, Km_KEY_LENGTH); /* Encrypting "aesKey": C = aesKey XOR Ke */ for(inti=0; i 0) { // counter++ CB[0] = counter>> 24; CB[1] = (counter>> 16) & 0xff; CB[2] = (counter>> 8) & 0xff; CB[3] = counter& 0xff; EVP_DigestInit_ex(ctx, EVP_sha256(), NULL); EVP_DigestUpdate(ctx, in, inLength); EVP_DigestUpdate(ctx, CB, sizeof(CB)); EVP_DigestFinal_ex(ctx, HB, &HB_len); if(remains> HB_len) { memcpy((void*)out+outputedlen, HB, HB_len); outputedlen+= HB_len; remains-= HB_len; } else{ memcpy((void*)out+outputedlen, HB, remains); outputedlen+= remains; remains-= remains; } counter++; } ret= out; std::cout<<"\nKDF output length "<<*outLength< From rajprudvi98 at gmail.com Wed Jul 22 19:28:49 2020 From: rajprudvi98 at gmail.com (prudvi raj) Date: Thu, 23 Jul 2020 00:58:49 +0530 Subject: Generate opensslconf.h - openssl 1.0.2 vs openssl 1.1.1g In-Reply-To: <878sfih5um.wl-levitte@openssl.org> References: <878sfih5um.wl-levitte@openssl.org> Message-ID: Hello, --- Re : OPENSSLDIR in openssl 1.1.1--- I have successfully generated opensslconf.h , (used make , not make...opensslconf.h - had to generate other .h files as well). Upon comparing contents of opensslconf.h from 1.0.2 & 1.1.1 , i see that: "OPENSSLDIR" is #define 'ed in opensslconf.h in 1.0.2 & not in 1.1.1. Now, i got the error : /openssl/crypto/x509/x509_def.c: In function 'X509_get_default_private_dir': / openssl/crypto/x509/x509_def.c:17:12: error: 'OPENSSLDIR' undeclared (first use in this function) Although , the log of "make" showed OPENSSLDIR as "/usr/local/ssl" , which is default . I couldn't find where this is #define 'ed. May I know , where it's defined in openssl 1.1.1g or how this error can be resolved. ? Thanks, -Prud On Fri, Jul 17, 2020 at 2:32 PM Richard Levitte wrote: > On Thu, 16 Jul 2020 22:01:51 +0200, > prudvi raj wrote: > > How do i generate "opensslconf.h" in openssl 1.1.1g? > > From docs, i assume it is created after we give "./Configure > gcc". > > I observe that "opensslconf.h" is created only on giving "make" after > ./Configure... But this > > additionally created .d & .o files in crypto folders. > > Yes, generation of most such files have moved to the building phase > rather than the configuration phase, so to say. > > The really quick way to get an individual file of this sort is to > simply make it, i.e.: > > make include/openssl/opensslconf.h > > > For openssl1.0.2 , the same opensslconf.h is created right after > "./Configure" . > > (all .h files in include directory are created after ./Configure, > whereas in 1.1.1 .h files appear > > in include directory - without any ./Configure) > > Yeah, before 1.1.0, the public header files were spread around in > diverse crypto/ subdirectories, and they got symlinked into > include/openssl, or copied, on platforms that don't support symbolic > links. We moved them permanently to include/openssl in 1.1.0, which > means the symlinking is no longer needed. > > > For context , we are upgrading our project to openssl 1.1.1g from 1.0.2k > & i am concerned about > > this .d & .o files, in case i build the whole project - which is > including openssl folder. > > I don't quite understand why .o files are a concern, they are the > normal object files that are used to build up libraries and > applications, and are produced in OpenSSL before 1.1.0 as well. > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From claude-robitaille at hotmail.com Wed Jul 22 20:36:30 2020 From: claude-robitaille at hotmail.com (Claude Robitaille) Date: Wed, 22 Jul 2020 20:36:30 +0000 Subject: Using the library to encrypt a RSA private key compatible with Web Crypto API (PBKDF2) Message-ID: This is NOT about using the command line utility, it is about using the library in a program and exporting a private key, while encrypting it. But first; I successfully tested the resulting key using the command-line and parameters iter 64000, hmacWithSHA512 and aes256. So I know for sure (at least I think so) that openssl 1.1.1 (I am using 1.1.1d as the development library) generates something compatible with the Web Crypt API importKey function (the parameters are the same as default in openCrypto, which is a wrapper around Web Crypto API). Now, for my application. I am not sure how to do this. I normally use PEM_write_bio_PKCS8PrivateKey to generate a PEM string. That function do accept a passphrase and a cipher but it is not possible to set parameters. The default values, as I could gather by reading on the Internet are weak so I just do not want to lower the Web Crypto API end. How to proceed? Is there another function that can be used? How does the command line utility do? I looked at the EVP_KDF but soon realized it was not 1.1.1 but only in the new 3.0 beta stuff, which I prefer not to use now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jul 22 23:17:40 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 22 Jul 2020 19:17:40 -0400 Subject: Using the library to encrypt a RSA private key compatible with Web Crypto API (PBKDF2) In-Reply-To: References: Message-ID: <20200722231740.GE59671@straasha.imrryr.org> On Wed, Jul 22, 2020 at 08:36:30PM +0000, Claude Robitaille wrote: > This is NOT about using the command line utility, it is about using > the library in a program and exporting a private key, while encrypting > it. Encrypted public keys are created via the PKCS8 API. > Now, for my application. I am not sure how to do this. I normally use > PEM_write_bio_PKCS8PrivateKey to generate a PEM string. That function > do accept a passphrase and a cipher but it is not possible to set > parameters. The default values, as I could gather by reading on the > Internet are weak so I just do not want to lower the Web Crypto API > end. How to proceed? Is there another function that can be used? The function you're looking for is PEM_write_bio_PKCS8_PRIV_KEY_INFO(). With error checks elided, it boils down to: 1. const EVP_CIPHER *cipher = EVP_get_cipherbyname(SN_aes_256_cbc); 2. X509_ALGOR *pbe = PKCS5_pbe2_set_iv(cipher, iter, NULL, 0, NULL, NID_hmacWithSHA512); The function in question needs documentation, it would be fanstastic if someone stepped up to document it, or at least open an issue asking for same: X509_ALGOR *PKCS5_pbe2_set_iv(const EVP_CIPHER *cipher, int iter, unsigned char *salt, int saltlen, unsigned char *aiv, int prf_nid); When the IV is null a random IV is generated. When the salt is NULL and saltlen == 0 a random salt is used. /* When saltlen is 0 and salt is not NULL you may get a segfault! */ The return value is freed with: void X509_ALGOR_free(X509_ALGOR *); 3. PKCS8_PRIV_KEY_INFO *p8inf = EVP_PKEY2PKCS8(pkey); 4. X509_SIG *p8 = PKCS8_set0_pbe(pass, strlen(pass), p8inf, pbe); Here, you might want to pay attention to the character set in which the password is encoded, if it is not all ASCII, it should be UTF-8 (https://tools.ietf.org/html/rfc8018) 5. BIO *bio_out = ... 6. ret = PEM_write_bio_PKCS8(out_bio, p8); -- Viktor. From jb-openssl at wisemo.com Thu Jul 23 00:35:28 2020 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 23 Jul 2020 02:35:28 +0200 Subject: Lack of documentation for OPENSSL_ia32cap_P Message-ID: <311e4923-2cab-8ba9-0588-9cdc4ef90086@wisemo.com> The OPENSSL_ia32cap_P variable, its bitfields and the code that sets it (in assembler) seemto have no clear documentation. Looking at x86_64cpuid.pl, I see jumps to ".Lintel" etc. being conditional on stuff other than the CPU being an Intel CPU, while the code in there is generally unreadable due to the backwards SCO assembler format and the lack of clear comments about register usage such as "Here, EDX holds XXX and ESI holds YYYY" or eventhe code rationale "P50 microarchitecture stepping A incorrectly implements FDIV, so clear out private bit for using that in bignum implementations" As there is an external interface for changing the variable via an environment var, the lack of documentation makes that useless except for "cargo-cult" copying of values from old mailing list posts. 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 samath.lokuge at gmail.com Thu Jul 23 07:21:07 2020 From: samath.lokuge at gmail.com (Samath Lokuge) Date: Thu, 23 Jul 2020 10:21:07 +0300 Subject: Fwd: openssl support for PQUIC In-Reply-To: References: Message-ID: Hello, I am trying to install PQUIC set up for some testing. https://pquic.org/ it says I need "openssl-dev" but I could not find that package. So I installed "openssl-1.1.1g" instead but it does not work. I have 2 questions . 1 .Where I can find "openssl-dev" package for Ubuntu ? 2. Does "openssl-dev" or any other version has support for "QUIC" ? Thanks Samath -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jul 23 08:07:11 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 23 Jul 2020 09:07:11 +0100 Subject: Fwd: openssl support for PQUIC In-Reply-To: References: Message-ID: <3df4d705-b9ef-a565-8d02-24b22a160dd3@openssl.org> On 23/07/2020 08:21, Samath Lokuge wrote: > Hello, > I am trying to install PQUIC?set?up?for some testing. > https://pquic.org/? > > it says I need? "openssl-dev" but I could not find that package. > So I installed "openssl-1.1.1g" instead but it does not work. > I have 2 questions . > 1 .Where I can find? "openssl-dev" package for Ubuntu ? I think the "dev" package in Ubuntu is called "libssl-dev" > 2. Does? "openssl-dev" or any other version has support? for? "QUIC"? ? No version of OpenSSL supports QUIC although the Google boringssl fork has support for the Google QUIC stack. There is also an OpenSSL community patch that enables support for the Google QUIC stack on top of OpenSSL ()https://github.com/openssl/openssl/pull/8797). IIUC, PQUIC is actually based on picotls (a different TLS stack). I assume it just needs OpenSSL for the low level crypto. Matt From claude-robitaille at hotmail.com Thu Jul 23 15:04:30 2020 From: claude-robitaille at hotmail.com (Claude Robitaille) Date: Thu, 23 Jul 2020 15:04:30 +0000 Subject: Using the library to encrypt a RSA private key compatible with Web Crypto API (PBKDF2) In-Reply-To: <20200722231740.GE59671@straasha.imrryr.org> References: , <20200722231740.GE59671@straasha.imrryr.org> Message-ID: Super, that works beautifully. Thanks!! Now, for sake of completeness, if I wanted to do the opposite, i.e. decrypt a key, I guess the steps are the same, using PEM_read_bio_PKCS8 at the end. Except that the salt and IV must be extracted from the PEM string. What is the function to do that? ________________________________ From: openssl-users on behalf of Viktor Dukhovni Sent: July 22, 2020 7:17 PM To: openssl-users at openssl.org Subject: Re: Using the library to encrypt a RSA private key compatible with Web Crypto API (PBKDF2) On Wed, Jul 22, 2020 at 08:36:30PM +0000, Claude Robitaille wrote: > This is NOT about using the command line utility, it is about using > the library in a program and exporting a private key, while encrypting > it. Encrypted public keys are created via the PKCS8 API. > Now, for my application. I am not sure how to do this. I normally use > PEM_write_bio_PKCS8PrivateKey to generate a PEM string. That function > do accept a passphrase and a cipher but it is not possible to set > parameters. The default values, as I could gather by reading on the > Internet are weak so I just do not want to lower the Web Crypto API > end. How to proceed? Is there another function that can be used? The function you're looking for is PEM_write_bio_PKCS8_PRIV_KEY_INFO(). With error checks elided, it boils down to: 1. const EVP_CIPHER *cipher = EVP_get_cipherbyname(SN_aes_256_cbc); 2. X509_ALGOR *pbe = PKCS5_pbe2_set_iv(cipher, iter, NULL, 0, NULL, NID_hmacWithSHA512); The function in question needs documentation, it would be fanstastic if someone stepped up to document it, or at least open an issue asking for same: X509_ALGOR *PKCS5_pbe2_set_iv(const EVP_CIPHER *cipher, int iter, unsigned char *salt, int saltlen, unsigned char *aiv, int prf_nid); When the IV is null a random IV is generated. When the salt is NULL and saltlen == 0 a random salt is used. /* When saltlen is 0 and salt is not NULL you may get a segfault! */ The return value is freed with: void X509_ALGOR_free(X509_ALGOR *); 3. PKCS8_PRIV_KEY_INFO *p8inf = EVP_PKEY2PKCS8(pkey); 4. X509_SIG *p8 = PKCS8_set0_pbe(pass, strlen(pass), p8inf, pbe); Here, you might want to pay attention to the character set in which the password is encoded, if it is not all ASCII, it should be UTF-8 (https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8018&data=02%7C01%7C%7C6ecb294783f64bd662eb08d82e969dbe%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637310571707466330&sdata=QJ0dIUR%2FOsrgZn2SpnoRLHQRNZ1E7T4sB0O1CJyWIK8%3D&reserved=0) 5. BIO *bio_out = ... 6. ret = PEM_write_bio_PKCS8(out_bio, p8); -- Viktor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Jul 23 16:38:05 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 23 Jul 2020 12:38:05 -0400 Subject: Using the library to encrypt a RSA private key compatible with Web Crypto API (PBKDF2) In-Reply-To: References: <20200722231740.GE59671@straasha.imrryr.org> Message-ID: <20200723163805.GF59671@straasha.imrryr.org> On Thu, Jul 23, 2020 at 03:04:30PM +0000, Claude Robitaille wrote: > Now, for sake of completeness, if I wanted to do the opposite, i.e. > decrypt a key, I guess the steps are the same, using > PEM_read_bio_PKCS8 at the end. Except that the salt and IV must be > extracted from the PEM string. What is the function to do that? Reading is much simpler: EVP_PKEY *PEM_read_bio_PrivateKey(BIO *bp, EVP_PKEY **x, pem_password_cb *cb, void *u); Just set pass = "sesame" and call: EVP_PKEY *pkey = PEM_read_bio_PrivateKey(bio_in, NULL, NULL, pass); It is possible to use the PKCS8 routines explicitly with: PKCS8 *PEM_read_bio_PKCS8(BIO *bp, TYPE **a, pem_password_cb *cb, void *u); as follows: X509_SIG *p8 = PEM_read_bio_PKCS8(bio_in, NULL, NULL, NULL); PKCS8_PRIV_KEY_INFO *p8inf = PKCS8_decrypt(p8, pass, strlen(pass)); EVP_PKEY *pkey = EVP_PKCS82PKEY(p8inf); but there's little reason to do that. The PBE algorithm, salt and IV are handled internally. -- Viktor. From rajprudvi98 at gmail.com Thu Jul 23 19:39:45 2020 From: rajprudvi98 at gmail.com (prudvi raj) Date: Fri, 24 Jul 2020 01:09:45 +0530 Subject: error : unknown type name 'sa_family_t' in openssl 1.1.1g Message-ID: Hi, We are upgrading our code base to openssl 1.1.1g from 1.0.2k. During Compilation i am seeing this error : In file included from /openssl/include/internal/sockets.h:67:0, from /openssl/crypto/bio/bio_local.h:11, from /openssl/crypto/bio/bss_mem.c:12: /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:469:7: error: unknown type name 'sa_family_t' /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:497:8: error: unknown type name 'sa_family_t' /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:519:10: error: unknown type name 'sa_family_t' /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:543:4: error: unknown type name 'sa_family_t' /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:562:41: error: unknown type name 'sa_family_t' In bio_local.h , if we remove "#include" & replace it with "#include" , the error is gone !! . But I am not sure is this correct ?? Btw , even "internal/sockets.h " has " #include". How to resolve this , Might I have missed something during configure & compilation ?? fwiw: have given "./configure gcc" & same was given when we had upgraded to 1.0.2 from previous versions long ago. Thanks, Prud. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhb at FreeBSD.org Thu Jul 23 22:06:49 2020 From: jhb at FreeBSD.org (John Baldwin) Date: Thu, 23 Jul 2020 15:06:49 -0700 Subject: How to help with getting KTLS patches merged In-Reply-To: References: <20200608111233.GA716779@roeckx.be> Message-ID: <2adf6235-8cff-1c57-b93a-345dfacd55db@FreeBSD.org> On 6/10/20 3:48 PM, John Baldwin wrote: > On 6/8/20 4:12 AM, Kurt Roeckx wrote: >> On Thu, Jun 04, 2020 at 09:00:08AM -0700, John Baldwin wrote: >>> At the moment there are 3 open PRs related to Kernel TLS offload >>> support that I'm aware of: >>> >>> - 11589 adds TLS1.3 for Linux, has one approval from Matt Caswell >>> - 10626 adds TLS1.3 for FreeBSD, from which 11589 is derived, but will >>> need to be rebased on top of 11589 once it is merged >>> - 11679 adds TLS1.[012] RX offload for FreeBSD, but would conflict >>> a bit with 11589 >>> >>> Matt has already approved 11589, and I think 11589 looks ok from >>> my vantage point (I'm more familiar with the KTLS infrastructure >>> in FreeBSD rather than Linux). Given that 11589 has received the >>> most review, I think it is probably prudent for it to be merged >>> first at for me to then rebase the other two PRs on top of that >>> and resolve conflicts, etc. >> >> 11589 has now been merged. > > Thanks for all the folks who jumped in to review that! I have one more request related to KTLS patches. After 11589 was merged, I reworked the two FreeBSD changes and ended up merging them into a new PR that includes some refactoring inspired by 11589 and the original two patches (which are now much smaller). The new PR is 12111. One question I have is if a new PR is the right way to handle this, and if so should I close 10626 and 11679? I also have some open questions in 12111 about possibly reducing OS-specific #ifdef's outside of . Thanks for any feedback or comments. -- John Baldwin From levitte at openssl.org Fri Jul 24 05:30:02 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 24 Jul 2020 07:30:02 +0200 Subject: error : unknown type name 'sa_family_t' in openssl 1.1.1g In-Reply-To: References: Message-ID: <87y2n9fpk5.wl-levitte@openssl.org> It would be helpful if you showed us the Configure options, as they may very well have affected diverse macros. Cheers, Richard On Thu, 23 Jul 2020 21:39:45 +0200, prudvi raj wrote: > Hi, > > We are upgrading our code base to openssl 1.1.1g from 1.0.2k.? > During Compilation i am seeing this error : > In file included from /openssl/include/internal/sockets.h:67:0, > ?????????????????from /openssl/crypto/bio/bio_local.h:11, > ?????????????????from /openssl/crypto/bio/bss_mem.c:12: > /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:469:7: error: > unknown type name 'sa_family_t' > /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:497:8: error: > unknown type name 'sa_family_t' > /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:519:10: error: > unknown type name 'sa_family_t' > /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:543:4: error: > unknown type name 'sa_family_t' > /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:562:41: error: > unknown type name 'sa_family_t' > > In bio_local.h , if we remove "#include"? & replace it with? "#include socket.h>" , the error is gone !! .? But I am not sure is this correct ?? > Btw , even? "internal/sockets.h " has " #include". > > How to resolve this , Might I have missed something during configure & compilation? ??? > fwiw: have given "./configure gcc"? & same was given when we had upgraded to 1.0.2 from > previous versions long ago. > > Thanks, > Prud. > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rajprudvi98 at gmail.com Fri Jul 24 05:43:15 2020 From: rajprudvi98 at gmail.com (prudvi raj) Date: Fri, 24 Jul 2020 11:13:15 +0530 Subject: error : unknown type name 'sa_family_t' in openssl 1.1.1g In-Reply-To: <87y2n9fpk5.wl-levitte@openssl.org> References: <87y2n9fpk5.wl-levitte@openssl.org> Message-ID: ./Configure no-threads no-dso no-shared no-zlib no-asm no-engine no-bf no-camellia no-cast no-md2 no-md4 no-mdc2 no-ocsp no-rc2 no-rc5 no-hw no-idea no-srp gcc -prud On Fri, 24 Jul, 2020, 11:00 am Richard Levitte, wrote: > It would be helpful if you showed us the Configure options, as they > may very well have affected diverse macros. > > Cheers, > Richard > > On Thu, 23 Jul 2020 21:39:45 +0200, > prudvi raj wrote: > > Hi, > > > > We are upgrading our code base to openssl 1.1.1g from 1.0.2k. > > During Compilation i am seeing this error : > > In file included from > /openssl/include/internal/sockets.h:67:0, > > from /openssl/crypto/bio/bio_local.h:11, > > from /openssl/crypto/bio/bss_mem.c:12: > > > /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:469:7: > error: > > unknown type name 'sa_family_t' > > > /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:497:8: > error: > > unknown type name 'sa_family_t' > > > /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:519:10: > error: > > unknown type name 'sa_family_t' > > > /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:543:4: > error: > > unknown type name 'sa_family_t' > > > /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:562:41: > error: > > unknown type name 'sa_family_t' > > > > In bio_local.h , if we remove "#include" & replace > it with "#include > socket.h>" , the error is gone !! . But I am not sure is this correct ?? > > Btw , even "internal/sockets.h " has " #include". > > > > How to resolve this , Might I have missed something during configure & > compilation ?? > > fwiw: have given "./configure gcc" & same was given when we > had upgraded to 1.0.2 from > > previous versions long ago. > > > > Thanks, > > Prud. > > > > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfulger at gmx.com Fri Jul 24 07:30:52 2020 From: dfulger at gmx.com (Dan Fulger) Date: Fri, 24 Jul 2020 09:30:52 +0200 Subject: error : unknown type name 'sa_family_t' in openssl 1.1.1g Message-ID: > Btw , even "internal/sockets.h " has " #include". Yes, but after #include . OTOH, netdb.h should #include; can you send a download link for the cross compilation toolkit you are using? From matt at openssl.org Fri Jul 24 08:49:33 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 24 Jul 2020 09:49:33 +0100 Subject: How to help with getting KTLS patches merged In-Reply-To: <2adf6235-8cff-1c57-b93a-345dfacd55db@FreeBSD.org> References: <20200608111233.GA716779@roeckx.be> <2adf6235-8cff-1c57-b93a-345dfacd55db@FreeBSD.org> Message-ID: <56d95dbc-5c33-36e7-5ab2-eaa515d63989@openssl.org> On 23/07/2020 23:06, John Baldwin wrote: > On 6/10/20 3:48 PM, John Baldwin wrote: >> On 6/8/20 4:12 AM, Kurt Roeckx wrote: >>> On Thu, Jun 04, 2020 at 09:00:08AM -0700, John Baldwin wrote: >>>> At the moment there are 3 open PRs related to Kernel TLS offload >>>> support that I'm aware of: >>>> >>>> - 11589 adds TLS1.3 for Linux, has one approval from Matt Caswell >>>> - 10626 adds TLS1.3 for FreeBSD, from which 11589 is derived, but will >>>> need to be rebased on top of 11589 once it is merged >>>> - 11679 adds TLS1.[012] RX offload for FreeBSD, but would conflict >>>> a bit with 11589 >>>> >>>> Matt has already approved 11589, and I think 11589 looks ok from >>>> my vantage point (I'm more familiar with the KTLS infrastructure >>>> in FreeBSD rather than Linux). Given that 11589 has received the >>>> most review, I think it is probably prudent for it to be merged >>>> first at for me to then rebase the other two PRs on top of that >>>> and resolve conflicts, etc. >>> >>> 11589 has now been merged. >> >> Thanks for all the folks who jumped in to review that! > > I have one more request related to KTLS patches. > > After 11589 was merged, I reworked the two FreeBSD changes and ended > up merging them into a new PR that includes some refactoring inspired > by 11589 and the original two patches (which are now much smaller). > > The new PR is 12111. One question I have is if a new PR is the > right way to handle this, and if so should I close 10626 and 11679? > I also have some open questions in 12111 about possibly reducing > OS-specific #ifdef's outside of . If its a significant refactoring of earlier PRs then I think a new PR is appropriate - and in that case closing the earlier PRs is also fine. It would be helpful to refer to the new PR when closing the old PR (and vice versa) so that the history is not lost. Matt From FRabby at corsec.com Fri Jul 24 14:32:27 2020 From: FRabby at corsec.com (Faraj Rabby) Date: Fri, 24 Jul 2020 14:32:27 +0000 Subject: OpenSSL user guide for 1.1.1g Message-ID: Hi, I am looking for OpenSSL 1.1.1g related user guide or any documentation. I could not find it out. I am getting only the OpenSSL FOM versions. But I need OpenSSL FIPS run time module version 1.1.1g. If you have this please share with me. Thanks, Faraj [signature_2117521934] Assess | Enhance | Validate [signature_1983136996] [A close up of a logo Description automatically generated] [A drawing of a face Description automatically generated] [signature_2130214003] Faraj Rabby Certification Analyst O: 703.267.6050 x139 F: 703.267.6810 E: frabby at corsec.com www.corsec.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 6817 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1469 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 1421 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 1190 bytes Desc: image004.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 853 bytes Desc: image005.png URL: From paul.dale at oracle.com Sat Jul 25 01:42:18 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Sat, 25 Jul 2020 11:42:18 +1000 Subject: OpenSSL user guide for 1.1.1g In-Reply-To: References: Message-ID: <0FB87866-08EB-4C22-81BA-DA7EDF09E833@oracle.com> There is not and never will be FIPS support for OpenSSL 1.1.1. You?ll have to wait for the upcoming 3.0 release for FIPS support. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 25 Jul 2020, at 12:32 am, Faraj Rabby wrote: > > Hi, > I am looking for OpenSSL 1.1.1g related user guide or any documentation. I could not find it out. I am getting only the OpenSSL FOM versions. But I need OpenSSL FIPS run time module version 1.1.1g. If you have this please share with me. > Thanks, > Faraj > > > > > > Assess | Enhance | Validate > > > Faraj Rabby > Certification Analyst > O: 703.267.6050 x139 > F: 703.267.6810 > E: frabby at corsec.com > www.corsec.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From janjust at nikhef.nl Sat Jul 25 23:56:10 2020 From: janjust at nikhef.nl (Jan Just Keijser) Date: Sun, 26 Jul 2020 01:56:10 +0200 Subject: Lack of documentation for OPENSSL_ia32cap_P In-Reply-To: <311e4923-2cab-8ba9-0588-9cdc4ef90086@wisemo.com> References: <311e4923-2cab-8ba9-0588-9cdc4ef90086@wisemo.com> Message-ID: <19cd570a-e414-bd58-27cb-a111040b1384@nikhef.nl> On 23/07/20 02:35, Jakob Bohm via openssl-users wrote: > The OPENSSL_ia32cap_P variable, its bitfields and the code that sets > it (in assembler) seemto have no clear documentation. > > Looking at x86_64cpuid.pl, I see jumps to ".Lintel" etc. being > conditional > on stuff other than the CPU being an Intel CPU, while the code in > there is > generally unreadable due to the backwards SCO assembler format and the > lack > of clear comments about register usage such as "Here, EDX holds XXX > and ESI > holds YYYY" or eventhe code rationale "P50 microarchitecture stepping A > incorrectly implements FDIV, so clear out private bit for using that in > bignum implementations" > > As there is an external interface for changing the variable via an > environment > var, the lack of documentation makes that useless except for "cargo-cult" > copying of values from old mailing list posts. in the openssl 1.1.1g tree there's a file 'doc/man3/OPENSSL_ia32cap.pod' which documents it a little - not sure if that is still up-to-date though... HTH, JJK From gisle.vanem at gmail.com Mon Jul 27 12:00:14 2020 From: gisle.vanem at gmail.com (Gisle Vanem) Date: Mon, 27 Jul 2020 14:00:14 +0200 Subject: The need for 'gdi32.lib' Message-ID: <90fb70fd-226b-498f-7f0a-429ed9165c67@gmail.com> Hello lists. I've a question/doubt about this passage in NOTES-Windows.txt: Linking your application ======================== This section applies to all "native" builds. If you link with *static OpenSSL libraries* then you're expected to additionally link your application with WS2_32.LIB, *GDI32.LIB*, ADVAPI32.LIB, CRYPT32.LIB and USER32.LIB. ------ (* my emphasis) Using OpenSSL in an all-static link of Wget, I always note the line in 'wget.map': Unused libraries: f:\ProgramFiler-x86\WindowsKits\Lib\10.0.19041.0\um\x86\gdi32.lib Grepping through all of my OpenSSL sources, I see only the above mention and one in 'Configurations\10-main.conf'. So how/when is 'gdi32.dll' needed? Maybe it was true in the old-days? -- --gv From Matthias.St.Pierre at ncp-e.com Mon Jul 27 12:46:42 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 27 Jul 2020 12:46:42 +0000 Subject: The need for 'gdi32.lib' In-Reply-To: <90fb70fd-226b-498f-7f0a-429ed9165c67@gmail.com> References: <90fb70fd-226b-498f-7f0a-429ed9165c67@gmail.com> Message-ID: > Grepping through all of my OpenSSL sources, I see only the > above mention and one in 'Configurations\10-main.conf'. > > So how/when is 'gdi32.dll' needed? Maybe it was true in the old-days? My guess is that you are right and that it was needed only for the function readscreen(), used by RAND_screen() (see [1]). A quick search shows that this function was removed in pull request #1079 (merged as commit 888db7f224fe) before the release of 1.1.0, see [2]. Would you mind creating a pull request for changing the NOTES? Matthias [1] https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/crypto/rand/rand_win.c#L679-L745 [2] https://github.com/openssl/openssl/pull/1079 From tomiii at tomiii.com Mon Jul 27 20:19:08 2020 From: tomiii at tomiii.com (Thomas Dwyer III) Date: Mon, 27 Jul 2020 13:19:08 -0700 Subject: openssl fipsinstall Message-ID: Hi all, I'm replacing OpenSSL 1.0.2 with OpenSSL 3.0 in an embedded environment with very limited flash space. We need and use libcrypto and libssl but we have no need for the openssl binary. To date it was never necessary to ship this utility in our product. Now with OpenSSL 3.0 it appears the only way to get FIPS support is to run "openssl fipsinstall ..." to create a FIPS config file to be included by the main config file. However, at nearly 1MB in size this binary is prohibitively large. I am able to reproduce the output of "openssl fipsinstall ..." with a (considerably smaller) standalone tool that links with libcrypto and generates HMAC-SHA256 (using FIPS_KEY_STRING from fipskey.h) but I'm unclear on what the actual FIPS requirements are for this. Would I still be considered FIPS compliant if I use my own standalone tool instead of the openssl binary to generate the FIPS config? I presume I don't need to bother with the self-test callback and that it only matters whether or not OSSL_PROVIDER_load(NULL, "fips") succeeds? Thanks, Tom.III -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Mon Jul 27 22:38:58 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Tue, 28 Jul 2020 08:38:58 +1000 Subject: openssl fipsinstall In-Reply-To: References: Message-ID: <549F8A31-783A-42D6-92F2-0EF44E142161@oracle.com> These are questions better asked of a FIPS lab since they are the experts and we are not. I expect that your alternative installation process?s validity will depend on the security policy and what it says needs to be done. This hasn?t been written yet so there is no answer at this point. Skipping the self tests is definitely not permitted. The full suite of self tests *must* be run before the module can be used. You question prompts the possibility of making fipsinstall a standalone executable, this is something we could look into if we get time. I expect we?d look favourably on a pull request that allowed either or both options. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 28 Jul 2020, at 6:19 am, Thomas Dwyer III wrote: > > Hi all, > > I'm replacing OpenSSL 1.0.2 with OpenSSL 3.0 in an embedded environment with very limited flash space. We need and use libcrypto and libssl but we have no need for the openssl binary. To date it was never necessary to ship this utility in our product. Now with OpenSSL 3.0 it appears the only way to get FIPS support is to run "openssl fipsinstall ..." to create a FIPS config file to be included by the main config file. However, at nearly 1MB in size this binary is prohibitively large. > > I am able to reproduce the output of "openssl fipsinstall ..." with a (considerably smaller) standalone tool that links with libcrypto and generates HMAC-SHA256 (using FIPS_KEY_STRING from fipskey.h) but I'm unclear on what the actual FIPS requirements are for this. Would I still be considered FIPS compliant if I use my own standalone tool instead of the openssl binary to generate the FIPS config? I presume I don't need to bother with the self-test callback and that it only matters whether or not OSSL_PROVIDER_load(NULL, "fips") succeeds? > > > Thanks, > Tom.III > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomiii at tomiii.com Mon Jul 27 23:51:43 2020 From: tomiii at tomiii.com (Thomas Dwyer III) Date: Mon, 27 Jul 2020 16:51:43 -0700 Subject: openssl fipsinstall In-Reply-To: <549F8A31-783A-42D6-92F2-0EF44E142161@oracle.com> References: <549F8A31-783A-42D6-92F2-0EF44E142161@oracle.com> Message-ID: On Mon, Jul 27, 2020 at 3:39 PM Dr Paul Dale wrote: > These are questions better asked of a FIPS lab since they are the experts > and we are not. > > That is a fair response. I expect that your alternative installation process?s validity will depend > on the security policy and what it says needs to be done. This hasn?t been > written yet so there is no answer at this point. > > Skipping the self tests is definitely not permitted. The full suite of > self tests *must* be run before the module can be used. > > Oops, I didn't mean to suggest skipping the self-tests. I was talking about the callback that fipsinstall currently uses to display results and/or inject faults in the self-tests. I don't think I need that. As long as OSSL_PROVIDER_load() succeeds it seems safe (?) to assume that all the self-tests passed at some point. > You question prompts the possibility of making fipsinstall a standalone > executable, this is something we could look into if we get time. I expect > we?d look favourably on a pull request that allowed either or both options. > > This is encouraging. However, since there is no draft security policy written yet would this be premature? Or are you suggesting that the presence of a standalone tool might influence the contents of such a security policy? Thanks, Tom.III Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > > On 28 Jul 2020, at 6:19 am, Thomas Dwyer III wrote: > > Hi all, > > I'm replacing OpenSSL 1.0.2 with OpenSSL 3.0 in an embedded environment > with very limited flash space. We need and use libcrypto and libssl but we > have no need for the openssl binary. To date it was never necessary to ship > this utility in our product. Now with OpenSSL 3.0 it appears the only way > to get FIPS support is to run "openssl fipsinstall ..." to create a FIPS > config file to be included by the main config file. However, at nearly 1MB > in size this binary is prohibitively large. > > I am able to reproduce the output of "openssl fipsinstall ..." with a > (considerably smaller) standalone tool that links with libcrypto and > generates HMAC-SHA256 (using FIPS_KEY_STRING from fipskey.h) but I'm > unclear on what the actual FIPS requirements are for this. Would I still be > considered FIPS compliant if I use my own standalone tool instead of the > openssl binary to generate the FIPS config? I presume I don't need to > bother with the self-test callback and that it only matters whether or not > OSSL_PROVIDER_load(NULL, "fips") succeeds? > > > Thanks, > Tom.III > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Tue Jul 28 00:06:29 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Tue, 28 Jul 2020 10:06:29 +1000 Subject: openssl fipsinstall In-Reply-To: References: <549F8A31-783A-42D6-92F2-0EF44E142161@oracle.com> Message-ID: <94356847-49B6-48EF-8170-4657D6D37B2F@oracle.com> The fipsinstall program runs the platform tests. I.e. you need to run fipsinstall on the device at some point. > Or are you suggesting that the presence of a standalone tool might influence the contents of such a security policy? Yes. Well maybe. I?ll posit the possibility at the next planning meeting. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 28 Jul 2020, at 9:51 am, Thomas Dwyer III wrote: > > On Mon, Jul 27, 2020 at 3:39 PM Dr Paul Dale > wrote: > These are questions better asked of a FIPS lab since they are the experts and we are not. > > > > That is a fair response. > > > I expect that your alternative installation process?s validity will depend on the security policy and what it says needs to be done. This hasn?t been written yet so there is no answer at this point. > > Skipping the self tests is definitely not permitted. The full suite of self tests *must* be run before the module can be used. > > > > Oops, I didn't mean to suggest skipping the self-tests. I was talking about the callback that fipsinstall currently uses to display results and/or inject faults in the self-tests. I don't think I need that. As long as OSSL_PROVIDER_load() succeeds it seems safe (?) to assume that all the self-tests passed at some point. > > > > You question prompts the possibility of making fipsinstall a standalone executable, this is something we could look into if we get time. I expect we?d look favourably on a pull request that allowed either or both options. > > > > This is encouraging. However, since there is no draft security policy written yet would this be premature? Or are you suggesting that the presence of a standalone tool might influence the contents of such a security policy? > > > Thanks, > Tom.III > > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 28 Jul 2020, at 6:19 am, Thomas Dwyer III > wrote: >> >> Hi all, >> >> I'm replacing OpenSSL 1.0.2 with OpenSSL 3.0 in an embedded environment with very limited flash space. We need and use libcrypto and libssl but we have no need for the openssl binary. To date it was never necessary to ship this utility in our product. Now with OpenSSL 3.0 it appears the only way to get FIPS support is to run "openssl fipsinstall ..." to create a FIPS config file to be included by the main config file. However, at nearly 1MB in size this binary is prohibitively large. >> >> I am able to reproduce the output of "openssl fipsinstall ..." with a (considerably smaller) standalone tool that links with libcrypto and generates HMAC-SHA256 (using FIPS_KEY_STRING from fipskey.h) but I'm unclear on what the actual FIPS requirements are for this. Would I still be considered FIPS compliant if I use my own standalone tool instead of the openssl binary to generate the FIPS config? I presume I don't need to bother with the self-test callback and that it only matters whether or not OSSL_PROVIDER_load(NULL, "fips") succeeds? >> >> >> Thanks, >> Tom.III >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Jul 28 20:20:10 2020 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 28 Jul 2020 22:20:10 +0200 Subject: Lack of documentation for OPENSSL_ia32cap_P In-Reply-To: <19cd570a-e414-bd58-27cb-a111040b1384@nikhef.nl> References: <311e4923-2cab-8ba9-0588-9cdc4ef90086@wisemo.com> <19cd570a-e414-bd58-27cb-a111040b1384@nikhef.nl> Message-ID: <7983a5f1-34ac-eae4-5b55-52ba06e0caac@wisemo.com> On 2020-07-26 01:56, Jan Just Keijser wrote: > On 23/07/20 02:35, Jakob Bohm via openssl-users wrote: >> The OPENSSL_ia32cap_P variable, its bitfields and the code that sets >> it (in assembler) seemto have no clear documentation. >> Thanks, I somehow missed that document as I was grepping the code. >> Looking at x86_64cpuid.pl, I see jumps to ".Lintel" etc. being >> conditional >> on stuff other than the CPU being an Intel CPU, while the code in >> there is >> generally unreadable due to the backwards SCO assembler format and the >> lack >> of clear comments about register usage such as "Here, EDX holds XXX >> and ESI >> holds YYYY" or eventhe code rationale "P50 microarchitecture stepping A >> incorrectly implements FDIV, so clear out private bit for using that in >> bignum implementations" >> >> As there is an external interface for changing the variable via an >> environment >> var, the lack of documentation makes that useless except for "cargo-cult" >> copying of values from old mailing list posts. > in the openssl 1.1.1g tree there's a file 'doc/man3/OPENSSL_ia32cap.pod' > which documents it a little - not sure if that is still up-to-date > though... > > HTH, > > JJK 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 ebrun at haproxy.com Thu Jul 30 15:06:49 2020 From: ebrun at haproxy.com (Emeric Brun) Date: Thu, 30 Jul 2020 17:06:49 +0200 Subject: alternative to deprecated ENGINE_* API for external engines for openssl-3.0.0 Message-ID: <0025de94-aca4-4b80-897f-24780c4d19af@haproxy.com> Trying to compile my soft using openssl-3.0.0alpha5, I notice a lot of warnings about deprecated ENGINE_* functions (since commit 8dab4de53887639abc1152288fac76506beb87b3). Is-there any documentation on a new API/functions to handle external crypto engines? R, Emeric From dv at vollmann.ch Thu Jul 30 15:30:49 2020 From: dv at vollmann.ch (Detlef Vollmann) Date: Thu, 30 Jul 2020 17:30:49 +0200 Subject: DTLS reconnect Message-ID: <16268f2a-3283-b75b-2c6f-48aa3c13dd1f@vollmann.ch> Hello, section 4.2.8 "Establishing New Associations with Existing Parameters" of RFC 6347 () recommends ("SHOULD") that a new ClientHello from a client IP/port pair for which a session already exists initiates a new handshake. I tried to test such a scenario using s_server and s_client: As server: openssl s_server -accept 127.0.0.1:18001 -4 -cert demoCA/srv.crt -key demoCA/testdev.key -CAfile demoCA/testca.crt -dtls1_2 As client: openssl s_client -bind 127.0.0.1:19933 -connect 127.0.0.1:18001 -4 -noservername -cert demoCA/clnt.crt -key demoCA/testdev.key -CAfile demoCA/testca.crt -dtls1_2 Then stop the client using CTRL-C and start it again. tcpdump/wireshark shows the first (successful) handshake and then ClientHellos from the same IP/port pair which are never replied to. I tested the official Debian unstable package 1.1.1g-1 and today's master (a3f15e237c). So here are my questions: - Is this part of RFC 6347 implemented in OpenSSL? - If yes, how can it be used? Note: this is not the same as what the "-reconnect' option of s_client does. This reconnect sends a ClientHello with a previously established session ID for cached connections. Section 4.2.8 of DTLS 1.2 is about a client that has no existing session context but tries to connect from an IP address and UDP port it has used previously. This happens e.g. for many embedded devices after a reset. Thanks, Detlef From matt at openssl.org Thu Jul 30 15:39:04 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 30 Jul 2020 16:39:04 +0100 Subject: alternative to deprecated ENGINE_* API for external engines for openssl-3.0.0 In-Reply-To: <0025de94-aca4-4b80-897f-24780c4d19af@haproxy.com> References: <0025de94-aca4-4b80-897f-24780c4d19af@haproxy.com> Message-ID: On 30/07/2020 16:06, Emeric Brun wrote: > Trying to compile my soft using openssl-3.0.0alpha5, I notice a lot of warnings about deprecated ENGINE_* functions (since commit 8dab4de53887639abc1152288fac76506beb87b3). > > Is-there any documentation on a new API/functions to handle external crypto engines? As noted in the CHANGES file the preferred alternative is to use the new "provider" APIs. Providers are fundamental to OpenSSL 3.0. You can read about how they're used and configured in 3.0 on this wiki page: https://wiki.openssl.org/index.php/OpenSSL_3.0 There's some more detailed documentation about providers here: https://www.openssl.org/docs/manmaster/man7/provider.html If you're interested in writing providers then there's an example one on this man page: https://www.openssl.org/docs/manmaster/man7/provider-base.html OpenSSL 3.0 comes with a number of built-in or out-of-the-box providers which are documented here: https://www.openssl.org/docs/manmaster/man7/OSSL_PROVIDER-default.html https://www.openssl.org/docs/manmaster/man7/OSSL_PROVIDER-FIPS.html https://www.openssl.org/docs/manmaster/man7/OSSL_PROVIDER-legacy.html https://www.openssl.org/docs/manmaster/man7/OSSL_PROVIDER-null.html There's also a number of other pages for provider authors about the various hooks available for different types of algorithm, e.g. see: https://www.openssl.org/docs/manmaster/man7/provider-cipher.html This gives details about the hooks for symmetric ciphers. There are other similar pages for different algorithm types linked from here: https://www.openssl.org/docs/manmaster/man7/ Hope that helps, Matt From rajprudvi98 at gmail.com Thu Jul 30 20:06:39 2020 From: rajprudvi98 at gmail.com (prudvi raj) Date: Fri, 31 Jul 2020 01:36:39 +0530 Subject: =?UTF-8?B?ZXJyb3I6IGV4cGVjdGVkIOKAmD3igJksIOKAmCzigJksIOKAmDvigJksIOKAmGFzbeKAmQ==?= =?UTF-8?B?IG9yIOKAmF9fYXR0cmlidXRlX1/igJkgYmVmb3JlIC0gb3BlbnNzbCAxLjEuMSBjb21waWxhdGlvbg==?= Message-ID: Hi, During compilation of openssl 1.1.1g , i am seeing this error : openssl/crypto/ec/ecp_nistz256_table.c:31: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?ecp_nistz256_precomputed? options used : ./Configure no-threads no-dso no-shared no-zlib no-asm no-engine no-bf no-camellia no-cast no-md2 no-md4 no-mdc2 no-ocsp no-rc2 no-rc5 no-hw no-idea no-srp gcc Anyone has any idea why this error popped up & how to resolve these?. Thanks, Prudvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomiii at tomiii.com Thu Jul 30 23:12:37 2020 From: tomiii at tomiii.com (Thomas Dwyer III) Date: Thu, 30 Jul 2020 16:12:37 -0700 Subject: FIPS and default properties Message-ID: I'm struggling to understand how EVP_default_properties_is_fips_enabled() works. I cannot get this function to return nonzero unless I first call either EVP_default_properties_enable_fips() or EVP_set_default_properties(), even when the config file sets default_properties to enable fips. Also, the return value of this function doesn't seem to have any effect on which provider gets selected (which I think is what issue #11594 describes?). My config file has the following: *[openssl_init]providers = provider_sectalg_section = alg_sect* *[provider_sect]fips = fips_sectdefault = default_sect* *[default_sect]activate = 1* *[alg_sect]default_properties = fips=yes* *.include /path/to/fips.cnf* I understand this to mean both the default provider and the fips provider will be loaded into the default context, and both of these providers will be activated. I also see that: *EVP_MD_fetch(NULL, "sha256", NULL);* returns a pointer which EVP_MD_provider() confirms as being from the fips provider (as expected). Changing this to "fips=no" in the config file results in EVP_MD_fetch() returning EVP_MD from the default provider, again as expected. However, in both cases, EVP_default_properties_is_fips_enabled() always returns zero. I don't see anything in #11594 that would explain this. Calling EVP_default_properties_enable_fips(NULL, 1) results in EVP_default_properties_is_fips_enabled() returning 1, but this does not appear to override the fips=no from the config file during EVP_MD_fetch() (which is what I believe #11594 describes). Is the result of EVP_default_properties_is_fips_enabled() supposed to take into account the default properties specified in the config file? I don't see it doing that. Also, regarding #11594, if default properties are currently still broken, why do those in the config appear to work properly? And finally the burning question: Any ETA on a fix? :-) :-) :-) Thanks, Tom.III -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Jul 31 09:18:03 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 31 Jul 2020 10:18:03 +0100 Subject: FIPS and default properties In-Reply-To: References: Message-ID: <7745867b-d655-1a0d-99db-964f8433fcaa@openssl.org> On 31/07/2020 00:12, Thomas Dwyer III wrote: > Is the result of EVP_default_properties_is_fips_enabled() supposed to > take into account the default properties specified in the config file? I > don't see it doing that. Also, regarding #11594, if default properties > are currently still broken, why do those in the config appear to work > properly? EVP_default_is_fips_enabled() is supposed to take into account the default properties specified in the config file, so it sounds like you may have encountered a bug. I've raised this issue here: https://github.com/openssl/openssl/issues/12565 Matt > > And finally the burning question: Any ETA on a fix? :-) :-) :-) > > > Thanks, > Tom.III > From Tobias.Wolf at t-systems.com Fri Jul 31 12:31:18 2020 From: Tobias.Wolf at t-systems.com (Tobias.Wolf at t-systems.com) Date: Fri, 31 Jul 2020 12:31:18 +0000 Subject: win32 build and freeing pointers Message-ID: Hi guys, I've experienced the following strange behaviour. I have the same code and the same openssl build. With x64 everything I fine, but with x86 build not. With a 32bit environment I got the following access vialotion. I read that windows marks a freed pointer as "0XDDDDDDDD", but we are usally freeing and setting NULL value to a pointer, therefore a following NULL check later for a already freed pointer would NOT work, right? Has anybody an adivice for me? Regards Tobias [cid:image003.jpg at 01D66747.4082C820] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 69203 bytes Desc: image003.jpg URL: From dank at kegel.com Fri Jul 31 14:43:45 2020 From: dank at kegel.com (Dan Kegel) Date: Fri, 31 Jul 2020 07:43:45 -0700 Subject: win32 build and freeing pointers In-Reply-To: References: Message-ID: Sounds like the pointer is *pointing to* memory containing 0xdddddddd... i.e. this is a use-after-free error. You might consider building your app with Address Sanitizer enabled, that might find the problem earlier during execution. - Dan On Fri, Jul 31, 2020 at 5:32 AM wrote: > Hi guys, > > > > I?ve experienced the following strange behaviour. > > I have the same code and the same openssl build. > > With x64 everything I fine, but with x86 build not. > > With a 32bit environment I got the following access vialotion. > > I read that windows marks a freed pointer as ?0XDDDDDDDD?, but we are > usally freeing and setting NULL value to a pointer, therefore a following > NULL check later for a already freed pointer would NOT work, right? > > Has anybody an adivice for me? > > > > Regards > > Tobias > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 69203 bytes Desc: not available URL: From ebrun at haproxy.com Fri Jul 31 15:57:39 2020 From: ebrun at haproxy.com (Emeric Brun) Date: Fri, 31 Jul 2020 17:57:39 +0200 Subject: alternative to deprecated ENGINE_* API for external engines for openssl-3.0.0 In-Reply-To: References: <0025de94-aca4-4b80-897f-24780c4d19af@haproxy.com> Message-ID: <2176e519-a9d2-4607-ffe8-ad373b43f412@haproxy.com> Hi Matt, On 7/30/20 5:39 PM, Matt Caswell wrote: > > > On 30/07/2020 16:06, Emeric Brun wrote: >> Trying to compile my soft using openssl-3.0.0alpha5, I notice a lot of warnings about deprecated ENGINE_* functions (since commit 8dab4de53887639abc1152288fac76506beb87b3). >> >> Is-there any documentation on a new API/functions to handle external crypto engines? > > As noted in the CHANGES file the preferred alternative is to use the new > "provider" APIs. Providers are fundamental to OpenSSL 3.0. You can read > about how they're used and configured in 3.0 on this wiki page: > > https://wiki.openssl.org/index.php/OpenSSL_3.0 > > There's some more detailed documentation about providers here: > > https://www.openssl.org/docs/manmaster/man7/provider.html > > If you're interested in writing providers then there's an example one on > this man page: > > https://www.openssl.org/docs/manmaster/man7/provider-base.html > > > OpenSSL 3.0 comes with a number of built-in or out-of-the-box providers > which are documented here: > > https://www.openssl.org/docs/manmaster/man7/OSSL_PROVIDER-default.html > https://www.openssl.org/docs/manmaster/man7/OSSL_PROVIDER-FIPS.html > https://www.openssl.org/docs/manmaster/man7/OSSL_PROVIDER-legacy.html > https://www.openssl.org/docs/manmaster/man7/OSSL_PROVIDER-null.html > > There's also a number of other pages for provider authors about the > various hooks available for different types of algorithm, e.g. see: > > https://www.openssl.org/docs/manmaster/man7/provider-cipher.html > > This gives details about the hooks for symmetric ciphers. There are > other similar pages for different algorithm types linked from here: > > https://www.openssl.org/docs/manmaster/man7/ > > > Hope that helps, > > Matt > Thanks! A lot to read! I have few questions: Do those changes have an impact on the external engine side API, specially for Async engines? The most used engine with my application is the Intel Quick Assist, in async mode. Does intel have someting to do to be compliant with the new v3.0.0's "provider" model for the intel quick assist engine ? https://github.com/intel/QAT_Engine R, Emeric From matt at openssl.org Fri Jul 31 16:11:36 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 31 Jul 2020 17:11:36 +0100 Subject: alternative to deprecated ENGINE_* API for external engines for openssl-3.0.0 In-Reply-To: <2176e519-a9d2-4607-ffe8-ad373b43f412@haproxy.com> References: <0025de94-aca4-4b80-897f-24780c4d19af@haproxy.com> <2176e519-a9d2-4607-ffe8-ad373b43f412@haproxy.com> Message-ID: On 31/07/2020 16:57, Emeric Brun wrote: > > Thanks! A lot to read! > > I have few questions: > > Do those changes have an impact on the external engine side API, specially for Async engines? The most used engine with my application is the Intel Quick Assist, in async mode. > > Does intel have someting to do to be compliant with the new v3.0.0's "provider" model for the intel quick assist engine ? > > https://github.com/intel/QAT_Engine Yes and no! The entire ENGINE API is deprecated. Existing ENGINE authors should look to convert their engines to providers instead. However, although they are deprecated they do still *work*, i.e. the ENGINE support has not been removed (yet). So if you need to use an ENGINE in 3.0, then it should be fine - but until such time as the ENGINE authors update the ENGINE to be a provider you will have to live with the various deprecation warnings (or suppress them). Matt