Re: [openssl-users] Version negotiation failure failure?
Ah, yes. Well that's why FIPS for OpenSSL is the main focus of the next release, and presumably why Oracle is one of the sponsors... :-) In the mean-time, yeah, you may have to support 1.0.2 for ~1 more year. > On Sep 12, 2018, at 1:18 AM, Jordan Brown > wrote: > > My understanding is that lack of FIPS-140 certification is a problem for us. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Version negotiation failure failure?
> On Sep 11, 2018, at 9:57 PM, Jakob Bohm wrote: > > Clarification question, as I cannot match what you wrote above with > the changelog (NEWS) in the OpenSSL 1.1.1 tarball: > > - Does OpenSSL 1.1.1 include SSL3.0 support or not? The code is there, but it is disabled in default builds. You need to run: ./Configure enable-ssl3 ... to get SSL 3.0 support. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
On Tue, Sep 11, 2018, 13:10 Kurt Roeckx wrote: > On Tue, Sep 11, 2018 at 04:59:45PM +0200, Juan Isoza wrote: > > Hello, > > > > What is the better way, for anyone running, by example, Apache or nginx > on > > a popular Linux districution (Ubuntu, Debian, Suse) and want support TLS > > 1.3 ? > > > > Waiting package update to have openssl 1.1.1 ? probably a lot of time > > > > Recompile openssl dynamic library and replace system library ? We must be > > sure we don't broke the system > > > > Recompile Apache or NGinx with openssl statically linked ? probably > complex > > Note that you most likely need an update of both nginx/apache and > openssl. > Note that httpd 2.4 released does not yet support TLS 1.3, although it compiles against the new OpenSSL, YMMV. Within the next two httpd releases, we would expect OpenSSL 1.1.1 TLS 1.3 support to be GA. In the interim there is a working branch for 1.1.1 compatibility merges, and svn trunk already supports it, if you want to live on the bleeding edge. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Version negotiation failure failure?
On 11/09/2018 19:34, Viktor Dukhovni wrote: On Sep 11, 2018, at 1:17 PM, Jordan Brown wrote: The key piece that I was missing - I hadn't looked at and thought about the protocol enough - was that there's no version-independent way for the server to fail. If the server supports only versions larger than the client supports, it has no way to say "no". If the positions are reversed, the server counter-offers a version that the client then rejects as too old. In OpenSSL 1.1.x, though the server might not support continuing with the client's maximum version, it is willing to do so just long enough to send a fatal protocol version mismatch alert. It helps that SSL2/SSL3 are not supported, and TLS 1.0 and up support the alert. Time to move to OpenSSL 1.1.x, it has many improvements, ... Clarification question, as I cannot match what you wrote above with the changelog (NEWS) in the OpenSSL 1.1.1 tarball: - Does OpenSSL 1.1.1 include SSL3.0 support or not? Note that some real world clients are permanently stuck at SSL 3.0 due to the vendor refusing to release updates. 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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Curves and ECDHParameters
> On Sep 11, 2018, at 6:20 PM, Viktor Dukhovni > wrote: > > > The 1.0.2 documentation for "ECDHParameters" explains that this is > server-side setting to select a particular *fixed* ECDHE curve. > This is a legacy feature that predates negotiation of the curve > used based on the client's extension. That said, in 1.0.2, it may be necessary to set "ECDHParameters" to "Automatic" in order to enable ECDHE with Curve negotiation based on the (separately specified) Curves. I am not sure whether automatic ECDHE is on by default in 1.0.2, IIRC it may not be. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Curves and ECDHParameters
> On Sep 11, 2018, at 4:55 PM, Joseph Christopher Sible > wrote: > > What exactly are each of "Curves" and "ECDHParameters" used for, as > documented by https://www.openssl.org/docs/man1.0.2/ssl/SSL_CONF_cmd.html? The documentation of OpenSSL 1.1.x does not mention "ECDHParameters", only "Curves" is documented as a synonym of "Groups". The 1.0.2 documentation for "ECDHParameters" explains that this is server-side setting to select a particular *fixed* ECDHE curve. This is a legacy feature that predates negotiation of the curve used based on the client's extension. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2
On Tue, Sep 11, 2018 at 04:09:48PM -0500, Benjamin Kaduk wrote: > On Tue, Sep 11, 2018 at 03:04:06PM -0600, The Doctor wrote: > > On Tue, Sep 11, 2018 at 02:57:09PM -0500, Benjamin Kaduk via openssl-users > > wrote: > > > On Tue, Sep 11, 2018 at 10:48:40AM -0600, The Doctor wrote: > > > > On Tue, Sep 11, 2018 at 09:33:36AM -0600, The Doctor wrote: > > > > > Looks likes I found a first bug > > > > > > > > > > ../test/recipes/70-test_comp.t . > > > > > Proxy started on port [::1]:10789 > > > > > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server > > > > > -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache > > > > > -accept [::1]:0 -cert ../../apps/server.pem -cert2 > > > > > ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites > > > > > TLS_AES_128_GCM_SHA256 > > > > > engine "ossltest" set. > > > > > Using default temp DH parameters > > > > > ACCEPT [::1]:39577 > > > > > Server responds on [::1]:39577 > > > > > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg > > > > > stack: base=805d16098, sp=805d160e8, hwm=805d160d0 > > > > > > > > > > > > > Using perl 5.28.1 > > > > > > The test suite needs some modules not included in the core perl > > > port/package. > > > You should probably list out what p5-* you have installed. > > > > > > p5-Archive-Zip-1.63Create, manipulate, read, and write Zip > > archive files > > p5-Authen-NTLM-1.09_1 Perl5 NTLM authentication module > > p5-Authen-PAM-0.16_2 Perl interface to the PAM library > > p5-Authen-SASL-2.16_1 Perl5 module for SASL authentication > > p5-Business-ISBN-3.004 Work with International Standard Book Numbers > > p5-Business-ISBN-Data-20140910.003 Data pack for Business::ISBN > > p5-CGI-4.40Handle Common Gateway Interface requests and > > responses > > p5-Class-Inspector-1.32Provides information about classes > > p5-Convert-ASN1-0.27_2 Perl5 module to encode and decode ASN.1 data > > structures > > p5-Convert-BinHex-1.125Perl module to extract data from Macintosh > > BinHex files > > p5-Convert-TNEF-0.18_1 Perl module to read TNEF files > > p5-Crypt-OpenSSL-Bignum-0.09 OpenSSL's multiprecision integer arithmetic > > p5-Crypt-OpenSSL-Guess-0.11Guess OpenSSL include path > > p5-Crypt-OpenSSL-RSA-0.30_1Perl5 module to RSA encode and decode > > strings using OpenSSL > > p5-Crypt-OpenSSL-Random-0.15 Perl5 interface to the OpenSSL pseudo-random > > number generator > > p5-Crypt-SSLeay-0.72_3 Perl5 interface to allow p5-libwww LWP to > > make https connections > > p5-DBD-SQLite-1.58 Provides access to SQLite3 databases through > > the DBI > > p5-DBD-mysql-4.046 MySQL driver for the Perl5 Database > > Interface (DBI) > > p5-DBI-1.641 Perl5 Database Interface, required for > > DBD::* modules > > p5-Data-Dump-1.23_1Pretty printing of data structures > > p5-Date-EzDate-1.16Date and time manipulation made easy > > p5-Devel-CheckLib-1.13 Check that a library is available > > p5-Digest-BubbleBabble-0.02_1 Perl5 interface to a fingerprint in "bubble > > babble" format > > p5-Digest-HMAC-1.03_1 Perl5 interface to HMAC Message-Digest > > Algorithms > > p5-Digest-SHA1-2.13_1 Perl interface to the SHA-1 Algorithm > > p5-Encode-Detect-1.01_1Encode::Encoding subclass that detects the > > encoding of data > > p5-Encode-Locale-1.05 Determine the locale encoding > > p5-Error-0.17026 Error/exception handling in object-oriented > > programming style > > p5-ExtUtils-Depends-0.405 Easily build XS extensions that depend on XS > > extensions > > p5-ExtUtils-PkgConfig-1.16 Simplistic interface to pkg-config > > p5-File-Listing-6.04_1 Parse directory listings > > p5-File-ShareDir-1.116 Locate per-dist and per-module shared files > > p5-File-ShareDir-Install-0.13 Install read-only data files from a > > distribution > > p5-Filesys-Df-0.92_1 Perl extension for filesystem space > > p5-Filter-1.59 Number of source filters for perl5 programs > > p5-GD-2.68 Perl5 interface to Gd Graphics Library > > version2 > > p5-GD-Barcode-1.15_6 GD::Barcode - Create barcode image with GD > > p5-GSSAPI-0.28_1 Perl extension providing access to the > > GSSAPIv2 library > > p5-Geo-IP-1.51 Gets country name by IP or hostname > > p5-Geography-Countries-2009041301_1 Handle ISO-3166 country codes > > p5-Glib2-1.327 This module provides access to Glib and > > GObject libraries > > p5-HTML-Parser-3.72Perl5 module for parsing HTML documents > > p5-HTML-Tagset-3.20_1 Some useful data table in parsing HTML > > p5-HTTP-Cookies-6.04 HTTP Cookie jars > > p5-HTTP-Daemon-6.01_1 Simple HTTP server class > >
[openssl-users] Curves and ECDHParameters
What exactly are each of "Curves" and "ECDHParameters" used for, as documented by https://www.openssl.org/docs/man1.0.2/ssl/SSL_CONF_cmd.html? My understanding of elliptic curves in TLS is that they're used in two places: as ECDSA key pairs used in certificates, and in ECDHE for key exchange. (Are there more uses I'm not aware of?) I know the curve used for ECDSA is a property of the key pair associated with the certificate, so it doesn't make sense to be a setting controlled at runtime. My best guess is that the curve for ECDHE is controlled by ECDHParameters. Given all of this, I can't figure out what's left for the "Curves" parameter to control. Are my above assumptions right? If so, what does "Curves" control? Joseph C. Sible -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2
On Tue, Sep 11, 2018 at 03:04:06PM -0600, The Doctor wrote: > On Tue, Sep 11, 2018 at 02:57:09PM -0500, Benjamin Kaduk via openssl-users > wrote: > > On Tue, Sep 11, 2018 at 10:48:40AM -0600, The Doctor wrote: > > > On Tue, Sep 11, 2018 at 09:33:36AM -0600, The Doctor wrote: > > > > Looks likes I found a first bug > > > > > > > > ../test/recipes/70-test_comp.t . > > > > Proxy started on port [::1]:10789 > > > > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server > > > > -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept > > > > [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem > > > > -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256 > > > > engine "ossltest" set. > > > > Using default temp DH parameters > > > > ACCEPT [::1]:39577 > > > > Server responds on [::1]:39577 > > > > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg > > > > stack: base=805d16098, sp=805d160e8, hwm=805d160d0 > > > > > > > > > > Using perl 5.28.1 > > > > The test suite needs some modules not included in the core perl > > port/package. > > You should probably list out what p5-* you have installed. > > > p5-Archive-Zip-1.63Create, manipulate, read, and write Zip > archive files > p5-Authen-NTLM-1.09_1 Perl5 NTLM authentication module > p5-Authen-PAM-0.16_2 Perl interface to the PAM library > p5-Authen-SASL-2.16_1 Perl5 module for SASL authentication > p5-Business-ISBN-3.004 Work with International Standard Book Numbers > p5-Business-ISBN-Data-20140910.003 Data pack for Business::ISBN > p5-CGI-4.40Handle Common Gateway Interface requests and > responses > p5-Class-Inspector-1.32Provides information about classes > p5-Convert-ASN1-0.27_2 Perl5 module to encode and decode ASN.1 data > structures > p5-Convert-BinHex-1.125Perl module to extract data from Macintosh > BinHex files > p5-Convert-TNEF-0.18_1 Perl module to read TNEF files > p5-Crypt-OpenSSL-Bignum-0.09 OpenSSL's multiprecision integer arithmetic > p5-Crypt-OpenSSL-Guess-0.11Guess OpenSSL include path > p5-Crypt-OpenSSL-RSA-0.30_1Perl5 module to RSA encode and decode strings > using OpenSSL > p5-Crypt-OpenSSL-Random-0.15 Perl5 interface to the OpenSSL pseudo-random > number generator > p5-Crypt-SSLeay-0.72_3 Perl5 interface to allow p5-libwww LWP to make > https connections > p5-DBD-SQLite-1.58 Provides access to SQLite3 databases through > the DBI > p5-DBD-mysql-4.046 MySQL driver for the Perl5 Database Interface > (DBI) > p5-DBI-1.641 Perl5 Database Interface, required for DBD::* > modules > p5-Data-Dump-1.23_1Pretty printing of data structures > p5-Date-EzDate-1.16Date and time manipulation made easy > p5-Devel-CheckLib-1.13 Check that a library is available > p5-Digest-BubbleBabble-0.02_1 Perl5 interface to a fingerprint in "bubble > babble" format > p5-Digest-HMAC-1.03_1 Perl5 interface to HMAC Message-Digest > Algorithms > p5-Digest-SHA1-2.13_1 Perl interface to the SHA-1 Algorithm > p5-Encode-Detect-1.01_1Encode::Encoding subclass that detects the > encoding of data > p5-Encode-Locale-1.05 Determine the locale encoding > p5-Error-0.17026 Error/exception handling in object-oriented > programming style > p5-ExtUtils-Depends-0.405 Easily build XS extensions that depend on XS > extensions > p5-ExtUtils-PkgConfig-1.16 Simplistic interface to pkg-config > p5-File-Listing-6.04_1 Parse directory listings > p5-File-ShareDir-1.116 Locate per-dist and per-module shared files > p5-File-ShareDir-Install-0.13 Install read-only data files from a > distribution > p5-Filesys-Df-0.92_1 Perl extension for filesystem space > p5-Filter-1.59 Number of source filters for perl5 programs > p5-GD-2.68 Perl5 interface to Gd Graphics Library version2 > p5-GD-Barcode-1.15_6 GD::Barcode - Create barcode image with GD > p5-GSSAPI-0.28_1 Perl extension providing access to the > GSSAPIv2 library > p5-Geo-IP-1.51 Gets country name by IP or hostname > p5-Geography-Countries-2009041301_1 Handle ISO-3166 country codes > p5-Glib2-1.327 This module provides access to Glib and > GObject libraries > p5-HTML-Parser-3.72Perl5 module for parsing HTML documents > p5-HTML-Tagset-3.20_1 Some useful data table in parsing HTML > p5-HTTP-Cookies-6.04 HTTP Cookie jars > p5-HTTP-Daemon-6.01_1 Simple HTTP server class > p5-HTTP-Date-6.02_1Conversion routines for the HTTP protocol date > formats > p5-HTTP-Message-6.18 Representation of HTTP style messages > p5-HTTP-Negotiate-6.01_1 Implementation of the HTTP content negotiation > algorithm >
Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2
On Tue, Sep 11, 2018 at 02:57:09PM -0500, Benjamin Kaduk via openssl-users wrote: > On Tue, Sep 11, 2018 at 10:48:40AM -0600, The Doctor wrote: > > On Tue, Sep 11, 2018 at 09:33:36AM -0600, The Doctor wrote: > > > Looks likes I found a first bug > > > > > > ../test/recipes/70-test_comp.t . > > > Proxy started on port [::1]:10789 > > > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server > > > -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept > > > [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept > > > 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256 > > > engine "ossltest" set. > > > Using default temp DH parameters > > > ACCEPT [::1]:39577 > > > Server responds on [::1]:39577 > > > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack: > > > base=805d16098, sp=805d160e8, hwm=805d160d0 > > > > > > > Using perl 5.28.1 > > The test suite needs some modules not included in the core perl port/package. > You should probably list out what p5-* you have installed. p5-Archive-Zip-1.63Create, manipulate, read, and write Zip archive files p5-Authen-NTLM-1.09_1 Perl5 NTLM authentication module p5-Authen-PAM-0.16_2 Perl interface to the PAM library p5-Authen-SASL-2.16_1 Perl5 module for SASL authentication p5-Business-ISBN-3.004 Work with International Standard Book Numbers p5-Business-ISBN-Data-20140910.003 Data pack for Business::ISBN p5-CGI-4.40Handle Common Gateway Interface requests and responses p5-Class-Inspector-1.32Provides information about classes p5-Convert-ASN1-0.27_2 Perl5 module to encode and decode ASN.1 data structures p5-Convert-BinHex-1.125Perl module to extract data from Macintosh BinHex files p5-Convert-TNEF-0.18_1 Perl module to read TNEF files p5-Crypt-OpenSSL-Bignum-0.09 OpenSSL's multiprecision integer arithmetic p5-Crypt-OpenSSL-Guess-0.11Guess OpenSSL include path p5-Crypt-OpenSSL-RSA-0.30_1Perl5 module to RSA encode and decode strings using OpenSSL p5-Crypt-OpenSSL-Random-0.15 Perl5 interface to the OpenSSL pseudo-random number generator p5-Crypt-SSLeay-0.72_3 Perl5 interface to allow p5-libwww LWP to make https connections p5-DBD-SQLite-1.58 Provides access to SQLite3 databases through the DBI p5-DBD-mysql-4.046 MySQL driver for the Perl5 Database Interface (DBI) p5-DBI-1.641 Perl5 Database Interface, required for DBD::* modules p5-Data-Dump-1.23_1Pretty printing of data structures p5-Date-EzDate-1.16Date and time manipulation made easy p5-Devel-CheckLib-1.13 Check that a library is available p5-Digest-BubbleBabble-0.02_1 Perl5 interface to a fingerprint in "bubble babble" format p5-Digest-HMAC-1.03_1 Perl5 interface to HMAC Message-Digest Algorithms p5-Digest-SHA1-2.13_1 Perl interface to the SHA-1 Algorithm p5-Encode-Detect-1.01_1Encode::Encoding subclass that detects the encoding of data p5-Encode-Locale-1.05 Determine the locale encoding p5-Error-0.17026 Error/exception handling in object-oriented programming style p5-ExtUtils-Depends-0.405 Easily build XS extensions that depend on XS extensions p5-ExtUtils-PkgConfig-1.16 Simplistic interface to pkg-config p5-File-Listing-6.04_1 Parse directory listings p5-File-ShareDir-1.116 Locate per-dist and per-module shared files p5-File-ShareDir-Install-0.13 Install read-only data files from a distribution p5-Filesys-Df-0.92_1 Perl extension for filesystem space p5-Filter-1.59 Number of source filters for perl5 programs p5-GD-2.68 Perl5 interface to Gd Graphics Library version2 p5-GD-Barcode-1.15_6 GD::Barcode - Create barcode image with GD p5-GSSAPI-0.28_1 Perl extension providing access to the GSSAPIv2 library p5-Geo-IP-1.51 Gets country name by IP or hostname p5-Geography-Countries-2009041301_1 Handle ISO-3166 country codes p5-Glib2-1.327 This module provides access to Glib and GObject libraries p5-HTML-Parser-3.72Perl5 module for parsing HTML documents p5-HTML-Tagset-3.20_1 Some useful data table in parsing HTML p5-HTTP-Cookies-6.04 HTTP Cookie jars p5-HTTP-Daemon-6.01_1 Simple HTTP server class p5-HTTP-Date-6.02_1Conversion routines for the HTTP protocol date formats p5-HTTP-Message-6.18 Representation of HTTP style messages p5-HTTP-Negotiate-6.01_1 Implementation of the HTTP content negotiation algorithm p5-IO-HTML-1.001_1 Open an HTML file with automatic charset detection p5-IO-Socket-INET6-2.72_1 Perl module with object interface to AF_INET6 domain sockets p5-IO-Socket-SSL-2.059 Perl5 interface to SSL sockets p5-IO-String-1.08_1
Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2
> On Sep 11, 2018, at 3:57 PM, Benjamin Kaduk via openssl-users > wrote: > >>> panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack: >>> base=805d16098, sp=805d160e8, hwm=805d160d0 >>> >> >> Using perl 5.28.1 Thanks for the hint, I was looking too close at the panic... This is a Perl issue, with an XSUB routine pushing more arguments onto the stack than the stack can hold. Sure does not look like an OpenSSL issue... Perhaps similar to: http://code.activestate.com/lists/perl5-porters/240289/ https://rt.perl.org/Public/Bug/Display.html?id=133327 I have Perl 5.26 and all is well... -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2
On Tue, Sep 11, 2018 at 10:48:40AM -0600, The Doctor wrote: > On Tue, Sep 11, 2018 at 09:33:36AM -0600, The Doctor wrote: > > Looks likes I found a first bug > > > > ../test/recipes/70-test_comp.t . > > Proxy started on port [::1]:10789 > > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server > > -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept > > [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 > > -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256 > > engine "ossltest" set. > > Using default temp DH parameters > > ACCEPT [::1]:39577 > > Server responds on [::1]:39577 > > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack: > > base=805d16098, sp=805d160e8, hwm=805d160d0 > > > > Using perl 5.28.1 The test suite needs some modules not included in the core perl port/package. You should probably list out what p5-* you have installed. Also, do you have any IPv6 addresses configured? -Ben -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL 1.0.2p w/ FIPS 2.0.16 - Apache 2.4.29
Noticing that my earlier attempts to compile Apache were not FIPS compliant, I set off to correct my error. I found the wiki, that provides the steps for building Apache with FIPS. Every time that it attempts to compile the SSL module, it dies. "mod_ssl.c", line 41: warning: syntax error: empty declaration "mod_ssl.c", line 398: warning: implicit function declaration: OPENSSL_malloc_init cc: acomp failed for mod_ssl.c *** Error code 1 make: Fatal error: Command failed for target `mod_ssl.lo' Current working directory /export/home/kellyi/Apache-2.4-Test/httpd-2.4.29/modules/ssl *** Error code 1 The following command caused the error: otarget=`echo all-recursive|sed s/-recursive//`; \ list=' '; \ for i in $list; do \ if test -d "$i"; then \ target="$otarget"; \ echo "Making $target in $i"; \ if test "$i" = "."; then \ made_local=yes; \ target="local-$target"; \ fi; \ (cd $i && make $target) || exit 1; \ fi; \ done; \ if test "$otarget" = "all" && test -z 'libmod_ssl.la'; then \ made_local=yes; \ fi; \ if test "$made_local" != "yes"; then \ make "local-$otarget" || exit 1; \ fi make: Fatal error: Command failed for target `all-recursive' Current working directory /export/home/kellyi/Apache-2.4-Test/httpd-2.4.29/modules/ssl *** Error code 1 The following command caused the error: otarget=`echo all-recursive|sed s/-recursive//`; \ list=' aaa cache core database debugging filters http loggers metadata session slotmem ssl arch/unix dav/main generators dav/fs mappers'; \ for i in $list; do \ if test -d "$i"; then \ target="$otarget"; \ echo "Making $target in $i"; \ if test "$i" = "."; then \ made_local=yes; \ target="local-$target"; \ fi; \ (cd $i && make $target) || exit 1; \ fi; \ done; \ if test "$otarget" = "all" && test -z ''; then \ made_local=yes; \ fi; \ if test "$made_local" != "yes"; then \ make "local-$otarget" || exit 1; \ fi make: Fatal error: Command failed for target `all-recursive' Current working directory /export/home/kellyi/Apache-2.4-Test/httpd-2.4.29/modules *** Error code 1 The following command caused the error: otarget=`echo all-recursive|sed s/-recursive//`; \ list=' srclib os server modules support'; \ for i in $list; do \ if test -d "$i"; then \ target="$otarget"; \ echo "Making $target in $i"; \ if test "$i" = "."; then \ made_local=yes; \ target="local-$target"; \ fi; \ (cd $i && make $target) || exit 1; \ fi; \ done; \ if test "$otarget" = "all" && test -z 'httpd shared-build '; then \ made_local=yes; \ fi; \ if test "$made_local" != "yes"; then \ make "local-$otarget" || exit 1; \ fi make: Fatal error: Command failed for target `all-recursive' However, now that I go back and look at openssl again, I see that there issues with it, as well. Here is the result from attempting to rebuild openssl. making all in crypto... /usr/bin/perl ../util/mkbuildinf.pl "/opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM" "solaris-sparcv9-cc" >buildinf.h /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c cryptlib.c /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c mem.c /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c mem_dbg.c /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c cversion.c /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
On 09/11/2018 02:35 PM, Viktor Dukhovni wrote:
On Tue, Sep 11, 2018 at 02:28:12PM -0400, Dennis Clarke wrote:
It sounds like a downstream ELF header nightmare.
Actually, it works just fine. You link with the variant library,
and it happily coexists with any dependencies you may have that in
turn depend on the system TLS library. The variant SONAME and
symbol versions provide all the requisite isolation. You only
pay the cost of customization for the handful of packages you
want to have running against the non-default libraries.
Mildly interesting in giving it a try. However I have 1.1.1 running and
tested fine on Solaris 10 sparc without any interferance from the system
provided ( ORacle? ) ssl bits. However I do have RUNPATH and RPATH set
to /usr/local/lib for everything I have built.
One thing I've not tested, is isolation from system SSL libraries
that don't employ symbol versions. Debian has been doing symbol
versions for a long time, so I never needed to worry about that.
And OpenSSL 1.1.0 has symbol versions on most platforms.
I would assume that Solaris also has symbol versions for OpenSSL
1.0.x, but if it does not and that's the system's SSL library, then
the variant build might not happily coexist with indirect dependencies
in other shared libraries, haven't tried that. Regardless, you're
no worse off than with the default SONAME and symbol versions.
The GNU ld manual makes direct reference to ye old Solaris 2.5 as a sort
of template for the format used.
https://sourceware.org/binutils/docs/ld/VERSION.html
but you won't find the section headers ( SHT_GNU_versym, SHT_GNU_verdef,
and SHT_GNU_verneed ) in an ELF file on Solaris but SUNW_version has
been around forever ( I think I saw it in 1994 ? ) :
# elfdump -devl /usr/local/bin/openssl
ELF Header
ei_magic: { 0x7f, E, L, F }
ei_class: ELFCLASS64 ei_data: ELFDATA2MSB
ei_osabi: ELFOSABI_SOLARISei_abiversion: EAV_SUNW_CURRENT
e_machine: EM_SPARCV9 e_version: EV_CURRENT
e_type: ET_EXEC
e_flags:[ EF_SPARCV9_TSO ]
e_entry: 0x100020200 e_ehsize: 64 e_shstrndx: 29
e_shoff: 0x194bd78 e_shentsize: 64 e_shnum: 31
e_phoff: 0x40 e_phentsize: 56 e_phnum: 5
Version Needed Section: .SUNW_version
index fileversion
[2] libssl.so.1.1 OPENSSL_1_1_0[ INFO ]
[3] OPENSSL_1_1_1
[4] libcrypto.so.1.1OPENSSL_1_1_0[ INFO ]
[5] OPENSSL_1_1_1
[6] libsocket.so.1 SUNW_0.7
[7] librt.so.1 SUNW_1.2
[8] SUNW_1.1 [ INFO ]
[9] libpthread.so.1 SUNW_1.2
[10] SUNW_0.9 [ INFO ]
[11] libc.so.1 SUNW_1.21.2
[12] SUNW_1.1 [ INFO ]
[13] SUNW_0.7 [ INFO ]
Dynamic Section: .dynamic
index tagvalue
[0] NEEDED0x86d5 libssl.so.1.1
[1] NEEDED0x86ff libcrypto.so.1.1
[2] NEEDED0x8710 libsocket.so.1
[3] NEEDED0x8774 libnsl.so.1
[4] NEEDED0x8780 libdl.so.1
[5] NEEDED0x8728 librt.so.1
[6] NEEDED0x8745 libpthread.so.1
[7] NEEDED0x875e libc.so.1
[8] INIT 0x100904ff8
[9] FINI 0x100905008
[10] RUNPATH 0x878b /usr/local/lib
[11] RPATH 0x878b /usr/local/lib
[12] HASH 0x10178
[13] STRTAB0x1e710
[14] STRSZ 0x899a
[15] SYMTAB0x13b08
[16] SYMENT0x18
[17] CHECKSUM 0x9857
[18] VERNEED 0x1000170b0
[19] VERNEEDNUM0x6
[20] PLTRELSZ 0x7e48
[21] PLTREL0x7
[22] JMPREL0x1000183b8
[23] RELA 0x100018028
[24] RELASZ0x81d8
[25] RELAENT 0x18
[26] DEBUG 0
[27] FLAGS 0 0
[28] FLAGS_1 0 0
[29] SUNW_STRPAD 0x200
[30] SUNW_LDMACH 0x2bEM_SPARCV9
[31] PLTGOT0x100a26700
[32-42] NULL 0
jupiter #
Anyways .. the whole mess started with Sun's versioning concepts and it
was Ulrich Drepper that did the first implementation in glibc 2.1 with
Eric Youngdale who also bolted in "symbol-level versioning with multiple
definitions of a symbol." :
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
On Tue, Sep 11, 2018 at 02:28:12PM -0400, Dennis Clarke wrote: > >> It sounds like a downstream ELF header nightmare. > > > > Actually, it works just fine. You link with the variant library, > > and it happily coexists with any dependencies you may have that in > > turn depend on the system TLS library. The variant SONAME and > > symbol versions provide all the requisite isolation. You only > > pay the cost of customization for the handful of packages you > > want to have running against the non-default libraries. > > Mildly interesting in giving it a try. However I have 1.1.1 running and > tested fine on Solaris 10 sparc without any interferance from the system > provided ( ORacle? ) ssl bits. However I do have RUNPATH and RPATH set > to /usr/local/lib for everything I have built. One thing I've not tested, is isolation from system SSL libraries that don't employ symbol versions. Debian has been doing symbol versions for a long time, so I never needed to worry about that. And OpenSSL 1.1.0 has symbol versions on most platforms. I would assume that Solaris also has symbol versions for OpenSSL 1.0.x, but if it does not and that's the system's SSL library, then the variant build might not happily coexist with indirect dependencies in other shared libraries, haven't tried that. Regardless, you're no worse off than with the default SONAME and symbol versions. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
It sounds like a downstream ELF header nightmare. Actually, it works just fine. You link with the variant library, and it happily coexists with any dependencies you may have that in turn depend on the system TLS library. The variant SONAME and symbol versions provide all the requisite isolation. You only pay the cost of customization for the handful of packages you want to have running against the non-default libraries. Mildly interesting in giving it a try. However I have 1.1.1 running and tested fine on Solaris 10 sparc without any interferance from the system provided ( ORacle? ) ssl bits. However I do have RUNPATH and RPATH set to /usr/local/lib for everything I have built. Otherwise, you have to be sure to recompile the world ... Right. Recompile the "world" isn't what it once was and a decently fast system gets that done overnight. In any case https://www.tls13.net/ is running just fine and a whole slew of browsers ( and curl ) have hit it. Nothing from the Opera folks however. Makes me wonder about lynx/links text browsers too. Dennis -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
On Tue, Sep 11, 2018 at 08:10:01PM +0200, Kurt Roeckx wrote: > On Tue, Sep 11, 2018 at 04:59:45PM +0200, Juan Isoza wrote: > > Hello, > > > > What is the better way, for anyone running, by example, Apache or nginx on > > a popular Linux districution (Ubuntu, Debian, Suse) and want support TLS > > 1.3 ? > > > > Waiting package update to have openssl 1.1.1 ? probably a lot of time > > > > Recompile openssl dynamic library and replace system library ? We must be > > sure we don't broke the system > > > > Recompile Apache or NGinx with openssl statically linked ? probably complex > > Note that you most likely need an update of both nginx/apache and > openssl. > > I will very likely make 1.1.1 available in Debian backports. I hope that > the nginx maintainer will also make a version that works with 1.1.1. Looking at stretch-backports, it already has an nginx version that is recent enough, so you would just need a new openssl. I can only do an openssl upload to backports after it has reached testing. Kurt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
On Tue, Sep 11, 2018 at 04:59:45PM +0200, Juan Isoza wrote: > Hello, > > What is the better way, for anyone running, by example, Apache or nginx on > a popular Linux districution (Ubuntu, Debian, Suse) and want support TLS > 1.3 ? > > Waiting package update to have openssl 1.1.1 ? probably a lot of time > > Recompile openssl dynamic library and replace system library ? We must be > sure we don't broke the system > > Recompile Apache or NGinx with openssl statically linked ? probably complex Note that you most likely need an update of both nginx/apache and openssl. I will very likely make 1.1.1 available in Debian backports. I hope that the nginx maintainer will also make a version that works with 1.1.1. But this is most likely going to take a while. We first want to make things work properly in testing. In the mean time buillding things yourself seems like the easiest solution. If using Debian you can just take the versions of the packages currently in unstable and build them on stable. Kurt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
On Tue, Sep 11, 2018 at 01:47:18PM -0400, Dennis Clarke wrote:
> >--- Configurations/10-main.conf
> >+++ Configurations/10-main.conf
> >
> >+"BSD-x86_64-opt" => {
> >+inherit_from => [ "BSD-x86_64" ],
> >+shlib_variant => "-opt",
> >+},
> >+
I guess this is a thread about Linux, and I gave a BSD example, but
there are no substative differences.
> It sounds like a downstream ELF header nightmare.
Actually, it works just fine. You link with the variant library,
and it happily coexists with any dependencies you may have that in
turn depend on the system TLS library. The variant SONAME and
symbol versions provide all the requisite isolation. You only
pay the cost of customization for the handful of packages you
want to have running against the non-default libraries.
This has been running in production on thousands of servers for
multiple years on Ubuntu (karmic, since retired), Debian wheezy,
jessie and stretch.
Otherwise, you have to be sure to recompile the world, to avoid
dependency conflicts where some system library use TLS, say for
LDAP lookups via an nsswitch module, and crashes because it wants
a differen OpenSSL version.
--
Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
On 09/11/2018 01:09 PM, Viktor Dukhovni wrote:
On Sep 11, 2018, at 10:59 AM, Juan Isoza wrote:
What is the better way, for anyone running, by example, Apache or nginx on a
popular Linux districution (Ubuntu, Debian, Suse) and want support TLS 1.3 ?
Waiting package update to have openssl 1.1.1 ? probably a lot of time
Roll you own. It works. Really really well in fact.
Recompile openssl dynamic library and replace system library ? We must be sure
we don't broke the system
Don't do that. That path leads to madness.
Recompile Apache or NGinx with openssl statically linked ? probably complex
You can install OpenSSL 1.1.1 in a non-default location, say:
./Configure --prefix=/usr/local/opt/openssl/1.1.1 BSD-x86_64-opt shared
with the "BSD-x86_64-opt" target inheriting from "BSD-x86_64":
--- Configurations/10-main.conf
+++ Configurations/10-main.conf
+"BSD-x86_64-opt" => {
+inherit_from => [ "BSD-x86_64" ],
+shlib_variant => "-opt",
+},
+
Integrating this into "ports" is an exercise for the reader...
It sounds like a downstream ELF header nightmare. Most likely better to
just isolate systems entirely and build the software stack dependencies
using standard locations and standard SONAME/RPATH/RUNPATH data. However
if someone wants to spin in tight circles battling lib resolution, well
gee, sounds like endless fun. Not for me .. thanks.
Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2
On 09/11/2018 01:30 PM, The Doctor wrote: On Tue, Sep 11, 2018 at 12:48:53PM -0400, Dennis Clarke wrote: On 09/11/2018 12:23 PM, Viktor Dukhovni wrote: On Sep 11, 2018, at 11:33 AM, The Doctor wrote: Looks likes I found a first bug Let's just slow down here a sec. LEt's get this tweaked accordingly for current BSD standards. Well I have been building and testing all the beta releases on a mixture of platforms for a while. All year? A while now and have not seen any show stoppers anywhere other than a bit of config tweaks and Makefile edits. I have been running a TLS v1.3 website for months and it never skips a beat. So this is most likely just a FreeBSD "feature" and a non-issue. The maintainer(s) in the FreeBSD project are the folks to speak with here and not the OpenSSL folks. Regardless I will give the release a whirl on OpenBSD 11.2 and 12.0 and possibly on PPC64 also. If there is anything to report you will see it in the FreeBSD bugzilla. Dennis Clarke ye ol greybeard UNIX silverback -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Version negotiation failure failure?
> On Sep 11, 2018, at 1:17 PM, Jordan Brown > wrote: > > The key piece that I was missing - I hadn't looked at and thought about the > protocol enough - was that there's no version-independent way for the server > to fail. If the server supports only versions larger than the client > supports, it has no way to say "no". If the positions are reversed, the > server counter-offers a version that the client then rejects as too old. In OpenSSL 1.1.x, though the server might not support continuing with the client's maximum version, it is willing to do so just long enough to send a fatal protocol version mismatch alert. It helps that SSL2/SSL3 are not supported, and TLS 1.0 and up support the alert. Time to move to OpenSSL 1.1.x, it has many improvements, ... -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2
On Tue, Sep 11, 2018 at 12:48:53PM -0400, Dennis Clarke wrote: > On 09/11/2018 12:23 PM, Viktor Dukhovni wrote: > > > > > >> On Sep 11, 2018, at 11:33 AM, The Doctor wrote: > >> > >> Looks likes I found a first bug > >> > > > > This did not happen on my machine, the build succeeded, and all tests > > passed: > > > > $ uname -srp > > FreeBSD 11.1-RELEASE-p10 amd64 > > > > You have 11.1 there whereas the initial report is in regards to 11.2. > I think 12.0 is right around the corner. I'll have a look at both. > > >> My configuration is > >> > >> #!/usr/local/bin/bash > >> CC=/usr/local/bin/clang60 ./Configure --prefix=/usr/local BSD-x86_64 > >> enable-crypto-mdebug enable-crypto-mdebug-backtrace enable-rfc3779 > >> enable-shared zlib-dynamic enable-sctp enable-rc4 > >> disable-weak-ssl-ciphers no-idea enable-ssl-trace enable-unit-test; make > >> depend > > > > You don't need to, and should not run "make depend" for OpenSSL 1.1.x. > > I'd recommend building an empty sub-directory or "out of tree": > > > > mkdir build; cd build; $path_to_source/Configure ...; make; make test > > > > Why are you building with "enable-crypto-mdebug" and > > "enable-crypto-mdebug-backtrace"? > > These are developer-team options, not expected to used by others, or > > necessarily work > > reliably on all systems... They also incur a substantial performance > > penalty. > > > > Hrmmm ... I'll give it a whirl out of the box but generally I find that > the Configurations/10-main.conf needs to be edited as well as the > resultant Makefile but after that everything goes smoothly. > > Dennis > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users LEt's get this tweaked accordingly for current BSD standards. -- 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 Look at Psalms 14 and 53 on Atheism NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Version negotiation failure failure?
On 9/11/2018 9:46 AM, Viktor Dukhovni wrote: > Part of the confusion is also using a version inflexible method on the > client, that's rarely done. My test engineers like trying all the variations, including the ones nobody will ever use :-) > Instead of "s_client -tls1" it is wiser to test with "s_client > -no_ssl2 -no_ssl3 -no_tls1_1 -no_tls1_2". That is subtract the > versions you don't want. IIRC that still leaves you "version flexible" > even if only with a single version. In the application that's causing me trouble now, we start with SSLv23_method and then add SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, and in this particular test case SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2. But how we construct the client configuration won't matter. The client says "the highest I support is 1.0" and the server says (to itself) "the lowest I support is 1.1; I don't even know how to say 'no' so I'm just giving up". The key piece that I was missing - I hadn't looked at and thought about the protocol enough - was that there's no version-independent way for the server to fail. If the server supports only versions larger than the client supports, it has no way to say "no". If the positions are reversed, the server counter-offers a version that the client then rejects as too old. Thanks again. -- Jordan Brown, Oracle Solaris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
> On Sep 11, 2018, at 10:59 AM, Juan Isoza wrote:
>
> What is the better way, for anyone running, by example, Apache or nginx on a
> popular Linux districution (Ubuntu, Debian, Suse) and want support TLS 1.3 ?
>
> Waiting package update to have openssl 1.1.1 ? probably a lot of time
>
> Recompile openssl dynamic library and replace system library ? We must be
> sure we don't broke the system
>
> Recompile Apache or NGinx with openssl statically linked ? probably complex
You can install OpenSSL 1.1.1 in a non-default location, say:
./Configure --prefix=/usr/local/opt/openssl/1.1.1 BSD-x86_64-opt shared
with the "BSD-x86_64-opt" target inheriting from "BSD-x86_64":
--- Configurations/10-main.conf
+++ Configurations/10-main.conf
+"BSD-x86_64-opt" => {
+inherit_from => [ "BSD-x86_64" ],
+shlib_variant => "-opt",
+},
+
but also specifying 'shlib_variant => "-opt"', see Configurations/README:
shlib_variant => A "variant" identifier inserted between the base
shared library name and the extension. On "unixy"
platforms (BSD, Linux, Solaris, MacOS/X, ...) this
supports installation of custom OpenSSL libraries
that don't conflict with other builds of OpenSSL
installed on the system. The variant identifier
becomes part of the SONAME of the library and also
any symbol versions (symbol versions are not used or
needed with MacOS/X). For example, on a system
where a default build would normally create the SSL
shared library as 'libssl.so -> libssl.so.1.1' with
the value of the symlink as the SONAME, a target
definition that sets 'shlib_variant => "-abc"' will
create 'libssl.so -> libssl-abc.so.1.1', again with
an SONAME equal to the value of the symlink. The
symbol versions associated with the variant library
would then be 'OPENSSL_ABC_' rather than
the default 'OPENSSL_'. The string inserted
into symbol versions is obtained by mapping all
letters in the "variant" identifier to upper case
and all non-alphanumeric characters to '_'.
The resulting libraries have a non-default SONAME:
$ readelf -d *.so | grep SONAME
0x000e SONAME Library soname:
[libcrypto-opt.so.1.1]
0x000e SONAME Library soname: [libssl-opt.so.1.1]
And non-default symbol versions:
$ objdump -T libssl.so | grep SSL_CTX_new
000338c0 gDF .text 03b3 OPENSSL_OPT_1_1_0
SSL_CTX_new
$ objdump -T libcrypto.so | grep X509_new
001d7be0 gDF .text 0011 OPENSSL_OPT_1_1_0 X509_new
All that remains is to link Apache, Nginx, ... with these libraries instead:
CFLAGS+="-I/usr/local/opt/openssl/1.1.1/include"
LDFLAGS+="-L/usr/local/opt/openssl/1.1.1/lib
-Wl,-rpath,/usr/local/opt/openssl/1.1.1/lib"
Integrating this into "ports" is an exercise for the reader...
--
--
Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2
On Tue, Sep 11, 2018 at 12:23:08PM -0400, Viktor Dukhovni wrote:
>
>
> > On Sep 11, 2018, at 11:33 AM, The Doctor wrote:
> >
> > Looks likes I found a first bug
> >
> > ../test/recipes/70-test_comp.t .
> > Proxy started on port [::1]:10789
> > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server
> > -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept
> > [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1
> > -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256
> > engine "ossltest" set.
> > Using default temp DH parameters
> > ACCEPT [::1]:39577
> > Server responds on [::1]:39577
> > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack:
> > base=805d16098, sp=805d160e8, hwm=805d160d0
>
> This did not happen on my machine, the build succeeded, and all tests
> passed:
>
>$ uname -srp
>FreeBSD 11.1-RELEASE-p10 amd64
>
Using 11.2 myself. 11.1 is now unsupported.
> ##
> ## Makefile for OpenSSL
> ##
> ## WARNING: do not edit!
> ## Generated by Configure from ../Configurations/unix-Makefile.tmpl,
> ../Configurations/common.tmpl
>
> PLATFORM=BSD-x86_64
> OPTIONS=enable-shared no-asan no-crypto-mdebug no-crypto-mdebug-backtrace
> no-ec_nistp_64_gcc_128 no-egd no-fuzz-afl no-fuzz-libfuzzer no-heartbeats
> no-md2 no-msan no-rc5 no-sctp no-ssl-trace no-ssl3 no-ssl3-method no-ubsan
> no-unit-test no-weak-ssl-ciphers no-zlib no-zlib-dynamic
> CONFIGURE_ARGS=("BSD-x86_64", "shared")
>
> Ditto with a configuration similar to yours, but built with "CC=clang50":
>
> ##
> ## Makefile for OpenSSL
> ##
> ## WARNING: do not edit!
> ## Generated by Configure from ../Configurations/unix-Makefile.tmpl,
> ../Configurations/common.tmpl
>
> PLATFORM=BSD-x86_64
> OPTIONS=--prefix=/usr/local enable-crypto-mdebug
> enable-crypto-mdebug-backtrace enable-rfc3779 enable-shared
> enable-zlib-dynamic enable-sctp enable-rc4 enable-ssl-trace enable-unit-test
> no-asan no-ec_nistp_64_gcc_128 no-egd no-fuzz-afl no-fuzz-libfuzzer
> no-heartbeats no-idea no-md2 no-msan no-rc5 no-ssl3 no-ssl3-method no-ubsan
> no-weak-ssl-ciphers
> CONFIGURE_ARGS=("--prefix=/usr/local", "BSD-x86_64", "enable-crypto-mdebug",
> "enable-crypto-mdebug-backtrace", "enable-rfc3779", "enable-shared",
> "zlib-dynamic", "enable-sctp", "enable-rc4", "disable-weak-ssl-ciphers",
> "no-idea", "enable-ssl-trace", "enable-unit-test")
>
> > My configuration is
> >
> > #!/usr/local/bin/bash
> > CC=/usr/local/bin/clang60 ./Configure --prefix=/usr/local BSD-x86_64
> > enable-crypto-mdebug enable-crypto-mdebug-backtrace enable-rfc3779
> > enable-shared zlib-dynamic enable-sctp enable-rc4
> > disable-weak-ssl-ciphers no-idea enable-ssl-trace enable-unit-test; make
> > depend
>
> You don't need to, and should not run "make depend" for OpenSSL 1.1.x.
> I'd recommend building an empty sub-directory or "out of tree":
>
> mkdir build; cd build; $path_to_source/Configure ...; make; make test
>
> Why are you building with "enable-crypto-mdebug" and
> "enable-crypto-mdebug-backtrace"?
> These are developer-team options, not expected to used by others, or
> necessarily work
> reliably on all systems... They also incur a substantial performance penalty.
>
clang 6.0 is the default and there is clang 6.0.1 and clang 7.0 FYI
Let me try without mdebug
> --
> Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism
NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018!
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2
On 09/11/2018 12:23 PM, Viktor Dukhovni wrote: On Sep 11, 2018, at 11:33 AM, The Doctor wrote: Looks likes I found a first bug This did not happen on my machine, the build succeeded, and all tests passed: $ uname -srp FreeBSD 11.1-RELEASE-p10 amd64 You have 11.1 there whereas the initial report is in regards to 11.2. I think 12.0 is right around the corner. I'll have a look at both. My configuration is #!/usr/local/bin/bash CC=/usr/local/bin/clang60 ./Configure --prefix=/usr/local BSD-x86_64 enable-crypto-mdebug enable-crypto-mdebug-backtrace enable-rfc3779 enable-shared zlib-dynamic enable-sctp enable-rc4 disable-weak-ssl-ciphers no-idea enable-ssl-trace enable-unit-test; make depend You don't need to, and should not run "make depend" for OpenSSL 1.1.x. I'd recommend building an empty sub-directory or "out of tree": mkdir build; cd build; $path_to_source/Configure ...; make; make test Why are you building with "enable-crypto-mdebug" and "enable-crypto-mdebug-backtrace"? These are developer-team options, not expected to used by others, or necessarily work reliably on all systems... They also incur a substantial performance penalty. Hrmmm ... I'll give it a whirl out of the box but generally I find that the Configurations/10-main.conf needs to be edited as well as the resultant Makefile but after that everything goes smoothly. Dennis -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2
On Tue, Sep 11, 2018 at 09:33:36AM -0600, The Doctor wrote: > Looks likes I found a first bug > > ../test/recipes/70-test_comp.t . > Proxy started on port [::1]:10789 > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server > -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept > [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 > -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256 > engine "ossltest" set. > Using default temp DH parameters > ACCEPT [::1]:39577 > Server responds on [::1]:39577 > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack: > base=805d16098, sp=805d160e8, hwm=805d160d0 > > > My configuration is > > #!/usr/local/bin/bash > CC=/usr/local/bin/clang60 ./Configure --prefix=/usr/local BSD-x86_64 > enable-crypto-mdebug enable-crypto-mdebug-backtrace enable-rfc3779 > enable-shared zlib-dynamic enable-sctp enable-rc4 disable-weak-ssl-ciphers > no-idea enable-ssl-trace enable-unit-test; make depend > -- > 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 Look at Psalms 14 and 53 on Atheism > NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October > 2018! > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users Using perl 5.28.1 -- 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 Look at Psalms 14 and 53 on Atheism NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Version negotiation failure failure?
> On Sep 11, 2018, at 12:33 PM, Jordan Brown > wrote: > > Thanks! > > Now I need to wrap my head around what that all means. > > It sounds like the protocol doesn't really have a version-independent way for > the version negotiation to cleanly fail. That's unfortunate. Well, once SSL3 is out of the picture (as in OpenSSL 1.1.x), TLS 1.0 and up do all support the requisite alert, and the 1.1.x state machine seems to handle this more along the lines that you expect. The issue is that 1.0.2 is older and tries to stick to SSL 3.0 capabilities when talking to SSL 3.0 clients, ... so things get a bit messier. Part of the confusion is also using a version inflexible method on the client, that's rarely done. Instead of "s_client -tls1" it is wiser to test with "s_client -no_ssl2 -no_ssl3 -no_tls1_1 -no_tls1_2". That is subtract the versions you don't want. IIRC that still leaves you "version flexible" even if only with a single version. In OpenSSL 1.1.x all the "-no_some_version" options are superseded by the min/max version options, which should be used instead. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Version negotiation failure failure?
Thanks! Now I need to wrap my head around what that all means. It sounds like the protocol doesn't really have a version-independent way for the version negotiation to cleanly fail. That's unfortunate. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2
> On Sep 11, 2018, at 11:33 AM, The Doctor wrote:
>
> Looks likes I found a first bug
>
> ../test/recipes/70-test_comp.t .
> Proxy started on port [::1]:10789
> Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server
> -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept
> [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1
> -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256
> engine "ossltest" set.
> Using default temp DH parameters
> ACCEPT [::1]:39577
> Server responds on [::1]:39577
> panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack:
> base=805d16098, sp=805d160e8, hwm=805d160d0
This did not happen on my machine, the build succeeded, and all tests
passed:
$ uname -srp
FreeBSD 11.1-RELEASE-p10 amd64
##
## Makefile for OpenSSL
##
## WARNING: do not edit!
## Generated by Configure from ../Configurations/unix-Makefile.tmpl,
../Configurations/common.tmpl
PLATFORM=BSD-x86_64
OPTIONS=enable-shared no-asan no-crypto-mdebug no-crypto-mdebug-backtrace
no-ec_nistp_64_gcc_128 no-egd no-fuzz-afl no-fuzz-libfuzzer no-heartbeats
no-md2 no-msan no-rc5 no-sctp no-ssl-trace no-ssl3 no-ssl3-method no-ubsan
no-unit-test no-weak-ssl-ciphers no-zlib no-zlib-dynamic
CONFIGURE_ARGS=("BSD-x86_64", "shared")
Ditto with a configuration similar to yours, but built with "CC=clang50":
##
## Makefile for OpenSSL
##
## WARNING: do not edit!
## Generated by Configure from ../Configurations/unix-Makefile.tmpl,
../Configurations/common.tmpl
PLATFORM=BSD-x86_64
OPTIONS=--prefix=/usr/local enable-crypto-mdebug enable-crypto-mdebug-backtrace
enable-rfc3779 enable-shared enable-zlib-dynamic enable-sctp enable-rc4
enable-ssl-trace enable-unit-test no-asan no-ec_nistp_64_gcc_128 no-egd
no-fuzz-afl no-fuzz-libfuzzer no-heartbeats no-idea no-md2 no-msan no-rc5
no-ssl3 no-ssl3-method no-ubsan no-weak-ssl-ciphers
CONFIGURE_ARGS=("--prefix=/usr/local", "BSD-x86_64", "enable-crypto-mdebug",
"enable-crypto-mdebug-backtrace", "enable-rfc3779", "enable-shared",
"zlib-dynamic", "enable-sctp", "enable-rc4", "disable-weak-ssl-ciphers",
"no-idea", "enable-ssl-trace", "enable-unit-test")
> My configuration is
>
> #!/usr/local/bin/bash
> CC=/usr/local/bin/clang60 ./Configure --prefix=/usr/local BSD-x86_64
> enable-crypto-mdebug enable-crypto-mdebug-backtrace enable-rfc3779
> enable-shared zlib-dynamic enable-sctp enable-rc4 disable-weak-ssl-ciphers
> no-idea enable-ssl-trace enable-unit-test; make depend
You don't need to, and should not run "make depend" for OpenSSL 1.1.x.
I'd recommend building an empty sub-directory or "out of tree":
mkdir build; cd build; $path_to_source/Configure ...; make; make test
Why are you building with "enable-crypto-mdebug" and
"enable-crypto-mdebug-backtrace"?
These are developer-team options, not expected to used by others, or
necessarily work
reliably on all systems... They also incur a substantial performance penalty.
--
Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl 1.1.1 and FreeBSD 11.2
Looks likes I found a first bug ../test/recipes/70-test_comp.t . Proxy started on port [::1]:10789 Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256 engine "ossltest" set. Using default temp DH parameters ACCEPT [::1]:39577 Server responds on [::1]:39577 panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack: base=805d16098, sp=805d160e8, hwm=805d160d0 My configuration is #!/usr/local/bin/bash CC=/usr/local/bin/clang60 ./Configure --prefix=/usr/local BSD-x86_64 enable-crypto-mdebug enable-crypto-mdebug-backtrace enable-rfc3779 enable-shared zlib-dynamic enable-sctp enable-rc4 disable-weak-ssl-ciphers no-idea enable-ssl-trace enable-unit-test; make depend -- 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 Look at Psalms 14 and 53 on Atheism NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.0.2 and TLS 1.3
> On Sep 11, 2018, at 9:58 AM, The Doctor wrote: > > So Openssh, NTPd, MOd_pagespeed have to adopt OPEnssl 1.1X API > in order to use TLS 1.3 . OpenSSH does not use TLS or libssl, so does not need that OpenSSL 1.1.x feature. It could still benefit from libcrypto algorithm improvements that result in more constant behaviour and/or other improvements. While OpenBSD may be slow to port to OpenSSL 1.1.x, porting OpenSSH to 1.1.x is not difficult. Christos Zoulas has done that for NetBSD, the latest HPN patches port OpenSSH to OpenSSL 1.1.0 [ I used the HPN patches for OpenSSH 7.7p1 as a starting point, and have a clean build of OpenSSH 7.8p1 with OpenSSL 1.1.x after some minor improvements. ] -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Migrating to openssl 1.1.1 in real life linux server
Hello, What is the better way, for anyone running, by example, Apache or nginx on a popular Linux districution (Ubuntu, Debian, Suse) and want support TLS 1.3 ? Waiting package update to have openssl 1.1.1 ? probably a lot of time Recompile openssl dynamic library and replace system library ? We must be sure we don't broke the system Recompile Apache or NGinx with openssl statically linked ? probably complex -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.0.2 and TLS 1.3
On 11/09/18 15:12, Perrow, Graeme wrote: > AFAIK 1.1.1 does not support the FIPS module, which means that those of us > who require FIPS must stay on 1.0.2. Any ETA on when FIPS support might be > added? TBD. Likely to be next year (before the EOL of 1.0.2) IMO. Our development focus is now shifting from implementing TLSv1.3 to implementing the new FIPS module. Matt > > Graeme > > -Original Message- > From: openssl-users On Behalf Of Matt > Caswell > Sent: September 11, 2018 4:31 AM > To: openssl-users@openssl.org > Subject: Re: [openssl-users] openssl 1.0.2 and TLS 1.3 > > > > On 11/09/18 09:05, Dr. Matthias St. Pierre wrote: >>> Von: openssl-users Im Auftrag von The >>> Doctor >>> Gesendet: Dienstag, 11. September 2018 08:49 >>> An: openssl-users@openssl.org; openssl-...@openssl.org >>> Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3 >>> >>> Will that combination occur? >> >> Support for TLS 1.3 is a new feature in OpenSSL 1.1.1 which will be released >> today. >> OpenSSL 1.0.2 is an LTS release which will only receive security updates and >> no new >> features. > > Strictly speaking 1.0.2 will receive bug fixes and security fixes until > the end of this year. From the end of this year until the end of 2019 it > will receive security fixes only. In any case it will receive no new > features (including TLSv1.3). > > From the release of 1.1.1 (today), 1.1.0 will receive security fixes > only for one year. > > Matt > > > >> >> HTH, >> Matthias >> >> See also >> https://wiki.openssl.org/index.php/TLS1.3 >> https://www.openssl.org/policies/releasestrat.html >> >> >> -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.0.2 and TLS 1.3
AFAIK 1.1.1 does not support the FIPS module, which means that those of us who require FIPS must stay on 1.0.2. Any ETA on when FIPS support might be added? Graeme -Original Message- From: openssl-users On Behalf Of Matt Caswell Sent: September 11, 2018 4:31 AM To: openssl-users@openssl.org Subject: Re: [openssl-users] openssl 1.0.2 and TLS 1.3 On 11/09/18 09:05, Dr. Matthias St. Pierre wrote: >> Von: openssl-users Im Auftrag von The >> Doctor >> Gesendet: Dienstag, 11. September 2018 08:49 >> An: openssl-users@openssl.org; openssl-...@openssl.org >> Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3 >> >> Will that combination occur? > > Support for TLS 1.3 is a new feature in OpenSSL 1.1.1 which will be released > today. > OpenSSL 1.0.2 is an LTS release which will only receive security updates and > no new > features. Strictly speaking 1.0.2 will receive bug fixes and security fixes until the end of this year. From the end of this year until the end of 2019 it will receive security fixes only. In any case it will receive no new features (including TLSv1.3). >From the release of 1.1.1 (today), 1.1.0 will receive security fixes only for one year. Matt > > HTH, > Matthias > > See also > https://wiki.openssl.org/index.php/TLS1.3 > https://www.openssl.org/policies/releasestrat.html > > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.0.2 and TLS 1.3
On Tue, Sep 11, 2018 at 03:01:38PM +0100, Matt Caswell wrote: > > > On 11/09/18 14:58, The Doctor wrote: > > On Tue, Sep 11, 2018 at 09:31:23AM +0100, Matt Caswell wrote: > >> > >> > >> On 11/09/18 09:05, Dr. Matthias St. Pierre wrote: > Von: openssl-users Im Auftrag von > The Doctor > Gesendet: Dienstag, 11. September 2018 08:49 > An: openssl-users@openssl.org; openssl-...@openssl.org > Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3 > > Will that combination occur? > >>> > >>> Support for TLS 1.3 is a new feature in OpenSSL 1.1.1 which will be > >>> released today. > >>> OpenSSL 1.0.2 is an LTS release which will only receive security updates > >>> and no new > >>> features. > >> > >> Strictly speaking 1.0.2 will receive bug fixes and security fixes until > >> the end of this year. From the end of this year until the end of 2019 it > >> will receive security fixes only. In any case it will receive no new > >> features (including TLSv1.3). > >> > >> >From the release of 1.1.1 (today), 1.1.0 will receive security fixes > >> only for one year. > >> > >> Matt > >> > >> > > > > Got you. > > > > So Openssh, NTPd, MOd_pagespeed have to adopt OPEnssl 1.1X API > > in order to use TLS 1.3 . > > Yes. I would encourage *all* applications still on the 1.0.x API to move > to 1.1.1 asap. By the end of next year there will be no supported > OpenSSL version that has the old API. > > > Matt > > I will forward this to the many mailing lists I belong to. > > >> > >>> > >>> HTH, > >>> Matthias > >>> > >>> See also > >>> https://wiki.openssl.org/index.php/TLS1.3 > >>> https://www.openssl.org/policies/releasestrat.html > >>> > >>> > >>> > >> -- > >> openssl-users mailing list > >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- 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 Look at Psalms 14 and 53 on Atheism NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.0.2 and TLS 1.3
>So Openssh, NTPd, MOd_pagespeed have to adopt OPEnssl 1.1X API in order to use TLS 1.3 . Yes. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.0.2 and TLS 1.3
On 11/09/18 14:58, The Doctor wrote: > On Tue, Sep 11, 2018 at 09:31:23AM +0100, Matt Caswell wrote: >> >> >> On 11/09/18 09:05, Dr. Matthias St. Pierre wrote: Von: openssl-users Im Auftrag von The Doctor Gesendet: Dienstag, 11. September 2018 08:49 An: openssl-users@openssl.org; openssl-...@openssl.org Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3 Will that combination occur? >>> >>> Support for TLS 1.3 is a new feature in OpenSSL 1.1.1 which will be >>> released today. >>> OpenSSL 1.0.2 is an LTS release which will only receive security updates >>> and no new >>> features. >> >> Strictly speaking 1.0.2 will receive bug fixes and security fixes until >> the end of this year. From the end of this year until the end of 2019 it >> will receive security fixes only. In any case it will receive no new >> features (including TLSv1.3). >> >> >From the release of 1.1.1 (today), 1.1.0 will receive security fixes >> only for one year. >> >> Matt >> >> > > Got you. > > So Openssh, NTPd, MOd_pagespeed have to adopt OPEnssl 1.1X API > in order to use TLS 1.3 . Yes. I would encourage *all* applications still on the 1.0.x API to move to 1.1.1 asap. By the end of next year there will be no supported OpenSSL version that has the old API. Matt > >> >>> >>> HTH, >>> Matthias >>> >>> See also >>> https://wiki.openssl.org/index.php/TLS1.3 >>> https://www.openssl.org/policies/releasestrat.html >>> >>> >>> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.0.2 and TLS 1.3
On Tue, Sep 11, 2018 at 09:31:23AM +0100, Matt Caswell wrote: > > > On 11/09/18 09:05, Dr. Matthias St. Pierre wrote: > >> Von: openssl-users Im Auftrag von The > >> Doctor > >> Gesendet: Dienstag, 11. September 2018 08:49 > >> An: openssl-users@openssl.org; openssl-...@openssl.org > >> Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3 > >> > >> Will that combination occur? > > > > Support for TLS 1.3 is a new feature in OpenSSL 1.1.1 which will be > > released today. > > OpenSSL 1.0.2 is an LTS release which will only receive security updates > > and no new > > features. > > Strictly speaking 1.0.2 will receive bug fixes and security fixes until > the end of this year. From the end of this year until the end of 2019 it > will receive security fixes only. In any case it will receive no new > features (including TLSv1.3). > > >From the release of 1.1.1 (today), 1.1.0 will receive security fixes > only for one year. > > Matt > > Got you. So Openssh, NTPd, MOd_pagespeed have to adopt OPEnssl 1.1X API in order to use TLS 1.3 . > > > > > HTH, > > Matthias > > > > See also > > https://wiki.openssl.org/index.php/TLS1.3 > > https://www.openssl.org/policies/releasestrat.html > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL 1.1.1 Blog
Our new Long Term Support release, OpenSSL 1.1.1, including TLSv1.3, has been released today. Please download and upgrade! There is a blog post about the new release and the status of the older releases here: https://www.openssl.org/blog/blog/2018/09/11/release111/ Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL version 1.1.1 published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL version 1.1.1 released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1 of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1 is available for download via HTTP 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-1.1.1.tar.gz Size: 8337920 SHA1 checksum: e4559f31dca37ce815e0c7135488b747745a056d SHA256 checksum: 2836875a0f89c03d0fdf483941512613a50cfb421d6fd94b9f41d7279d586a3d The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1.tar.gz openssl sha256 openssl-1.1.1.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAluXuZ8ACgkQ2cTSbQ5g RJFPFQf9G1LopuN1P3tIUTgps9Z1SS+TuC7OeRPu9TCEqOR0yO8WGyTCfLZnoXZ7 0BqFASYW4VbPCy8LH3glHLBe64NApdoA1HoMmHCvd+TxPQHEvhc0OejSaOGZKY/r 2LGUvEguiyYpjQS4bQmsl8wNl3CrYRGSMqBcbFj+qF/Rrlpa1hpKGnH4ooMxe7Nx /Ro4AjMe46vQL/RU980yFl+JTkhAvSOxw0cltbILPO2MP6Fo4QZqMO8mYRjEnqUZ E/Ixl/dIkSWjPC8pkkRS9FmMQHHYe66S20OK7V2Zl3Zd88FrNI+qeKgEF3ABGknR 6vR0kPkddRl43JktQ4B1QKS+GcwzHw== =fvfm -END PGP SIGNATURE- -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.0.2 and TLS 1.3
On 11/09/18 09:05, Dr. Matthias St. Pierre wrote: >> Von: openssl-users Im Auftrag von The >> Doctor >> Gesendet: Dienstag, 11. September 2018 08:49 >> An: openssl-users@openssl.org; openssl-...@openssl.org >> Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3 >> >> Will that combination occur? > > Support for TLS 1.3 is a new feature in OpenSSL 1.1.1 which will be released > today. > OpenSSL 1.0.2 is an LTS release which will only receive security updates and > no new > features. Strictly speaking 1.0.2 will receive bug fixes and security fixes until the end of this year. From the end of this year until the end of 2019 it will receive security fixes only. In any case it will receive no new features (including TLSv1.3). >From the release of 1.1.1 (today), 1.1.0 will receive security fixes only for one year. Matt > > HTH, > Matthias > > See also > https://wiki.openssl.org/index.php/TLS1.3 > https://www.openssl.org/policies/releasestrat.html > > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.0.2 and TLS 1.3
> Von: openssl-users Im Auftrag von The > Doctor > Gesendet: Dienstag, 11. September 2018 08:49 > An: openssl-users@openssl.org; openssl-...@openssl.org > Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3 > > Will that combination occur? Support for TLS 1.3 is a new feature in OpenSSL 1.1.1 which will be released today. OpenSSL 1.0.2 is an LTS release which will only receive security updates and no new features. HTH, Matthias See also https://wiki.openssl.org/index.php/TLS1.3 https://www.openssl.org/policies/releasestrat.html -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Preventing Handshake Termination Because of Unverifiable Client Certificates
> On Sep 11, 2018, at 2:25 AM, Armen Babikyan wrote: > > I realized that something like this could be an option a few minutes after I > hit "send". Thanks for the confirmation - I'll give this a shot! You should also consider what if anything you want to pass to SSL_CTX_set_client_CA_list(3) See the docs. Some clients (IIRC Java's TLS stack) don't send any client certificates unless the server solicits a certificate from a matching CA, and leaving the list empty may not work for such clients. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl 1.0.2 and TLS 1.3
Will that combination occur? -- 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 Look at Psalms 14 and 53 on Atheism NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Preventing Handshake Termination Because of Unverifiable Client Certificates
Hi Viktor, I realized that something like this could be an option a few minutes after I hit "send". Thanks for the confirmation - I'll give this a shot! Many thanks! Armen On Mon, Sep 10, 2018 at 11:19 PM, Viktor Dukhovni < openssl-us...@dukhovni.org> wrote: > > > > On Sep 11, 2018, at 2:09 AM, Armen Babikyan > wrote: > > > > I have a question regarding openssl and verification of client > certificates. Is there a way to have an openssl-enabled server ask for a > client certificate, and when it receives one it can't verify, rather than > immediately terminating the handshake, it would allow the connection, but > pass some context about the failed verification to the calling application? > > Yes. > > > It appears that what I want is not possible from the SSL_VERIFY_* > options presented here: > > Actually, SSL_VERIFY_PEER is the right choice, but you also need a > non-null verification callback that continues (by returning 1) > despite failures to verify the client certificate. > > You can check the verification status at the completion of the > handshake via SSL_get_verify_result(3). > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Preventing Handshake Termination Because of Unverifiable Client Certificates
> On Sep 11, 2018, at 2:09 AM, Armen Babikyan wrote: > > I have a question regarding openssl and verification of client certificates. > Is there a way to have an openssl-enabled server ask for a client > certificate, and when it receives one it can't verify, rather than > immediately terminating the handshake, it would allow the connection, but > pass some context about the failed verification to the calling application? Yes. > It appears that what I want is not possible from the SSL_VERIFY_* options > presented here: Actually, SSL_VERIFY_PEER is the right choice, but you also need a non-null verification callback that continues (by returning 1) despite failures to verify the client certificate. You can check the verification status at the completion of the handshake via SSL_get_verify_result(3). -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Preventing Handshake Termination Because of Unverifiable Client Certificates
Hello, I have a question regarding openssl and verification of client certificates. Is there a way to have an openssl-enabled server ask for a client certificate, and when it receives one it can't verify, rather than immediately terminating the handshake, it would allow the connection, but pass some context about the failed verification to the calling application? It appears that what I want is not possible from the SSL_VERIFY_* options presented here: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_ verify_depth.html#NOTES My use case is to opportunistically allow connections from VoIP devices, whether or not the clients have certificates I can verify. Suppose I use the term "blue check" as an internal measure of client trustworthiness/provenance. 1) If the client presents a certificate that I can verify, I want to build some context that gives this client a "blue check". 2) If the client presents a certificate that I can't verify, I want to still allow it to connect, but not have a "blue check" associated with that client. 3) If the client doesn't present a certificate, I want to still allow it to connect, but, as in (2), not have a "blue check" It seems that the openssl library and documented behavior is artificially limiting me to only allow (1) and (3). I would like to support scenario (2) as well. Is the existing behavior intentional, or am I out in left-field with this request? If the latter, would you consider a patch to implement the behavior in (2), perhaps as an additional param, e.g. SSL_VERIFY_DONTFAIL? Additionally, it would be great if I could still get some information about the cert presented by the unverifiable client from within my application as well. Thanks! Armen -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
