Re: TLSv1.3 supprt for 2.4.x?
Sorry for the multiple messages. I was trying to edit my original reply and didn't realize every attempt would result in a new message.The purpose of this mail is to include the 'make' errors that I received and that may not be visible in other list archives as HTML tags (and apparently anything enclosed with them) are stripped. My apologies for stomping all over mail list etiquette. The initial 'make' error if libiconv is installed is: /usr/local/apache2/tlsv1.3-for-2.4.x/srclib/apr/libtool --silent --mode=link cc -g -O2 -L/usr/local/lib -o htpasswd htpasswd.lo passwd_common.lo /usr/local/apache2/tlsv1.3-for-2.4.x/srclib/apr/libapr-2.la -lcrypt -lcrypt -lpthread -lexpat -lcrypt /usr/local/apache2/tlsv1.3-for-2.4.x/srclib/apr/.libs/libapr-2.so: undefined reference to `libiconv' /usr/local/apache2/tlsv1.3-for-2.4.x/srclib/apr/.libs/libapr-2.so: undefined reference to `libiconv_close' /usr/local/apache2/tlsv1.3-for-2.4.x/srclib/apr/.libs/libapr-2.so: undefined reference to `libiconv_open' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[2]: stopped in /usr/local/apache2/tlsv1.3-for-2.4.x/support *** Error code 1 Temporarily uninstalling libiconv allows 'make' to finish. However libiconv must be reinstalled prior to 'make install' to avoid another error: Installing HTML documents mkdir /usr/local/apache2/htdocs Shared object "libiconv.so.2" not found, required by "rsync" *** Error code 1 (ignored) ... mkdir /usr/local/apache2/manual Shared object "libiconv.so.2" not found, required by "rsync" *** Error code 1 Stop. make[1]: stopped in /usr/local/apache2/tlsv1.3-for-2.4.x *** Error code 1 Regards, Dennis -- Sent from: http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html
Re: TLSv1.3 supprt for 2.4.x?
With the recent release of openssl 1.1.1 back on Sept 11 that supports TLS 1.3 final RFC 8446, I believe demand for this backport will steadily increase. Thank you Stephan for proposing this backport branch. FreeBSD 11.2-RELEASE-p3 Apache/2.4.35-dev (Unix) OpenSSL/1.1.1 I've compiled and am running this branch and hosting a web site successfully providing TLSv1.3 (rfc8446) I can negotiate a TLS 1.3 connection from another openssl 1.1.1 client. I am also successful connecting with Firefox Nightly 64.0a1. Support for RFC 8446 was added in version 63 which is expected to ship October 2018. There is one error that I receive during initial 'make' if the package converters/libiconv is installed on the system: Temporarily uninstalling libiconv allows 'make' to finish. However libiconv must be reinstalled prior to 'make install' to avoid another error: rsync is the only pkg that depends on libiconv so i'm not sure why it would interfere in the make process. After successfully compiling and installing this branch, httpd appears to have the backported features working. Thank you everyone for all your efforts in bringing this backport proposal forward. Cheers, Dennis -- Sent from: http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html
Re: TLSv1.3 supprt for 2.4.x?
With the recent release of openssl 1.1.1 back on Sept 11 that supports TLS 1.3 final RFC 8446, I believe demand for this backport will steadily increase. Thank you Stephan for proposing this backport branch.FreeBSD 11.2-RELEASE-p3Apache/2.4.35-dev (Unix)OpenSSL/1.1.1I've compiled and am running this branch and hosting a web site successfully providing TLSv1.3 (rfc8446)I can negotiate a TLS 1.3 connection from another openssl 1.1.1 client. I am also successful connecting with Firefox Nightly 64.0a1. Support for RFC 8446 was added in version 63 which is expected to ship October 2018.There is one error that I receive during initial 'make' if the package converters/libiconv is installed on the system:Temporarily uninstalling libiconv allows 'make' to finish.However libiconv must be reinstalled prior to 'make install' to avoid another error:rsync is the only pkg that depends on libiconv so i'm not sure why it would interfere in the make process.After successfully compiling and installing this branch, httpd appears to have the backported features working.Thank you everyone for all your efforts in bringing this backport proposal forward.Cheers,Dennis -- Sent from: http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html
Re: TLSv1.3 supprt for 2.4.x?
With the recent release of openssl 1.1.1 back on Sept 11 that supports TLS 1.3 final RFC 8446, I believe demand for this backport will steadily increase. Thank you Stephan for proposing this backport branch. FreeBSD 11.2-RELEASE-p3 Apache/2.4.35-dev (Unix) OpenSSL/1.1.1 I've compiled and am running this branch and hosting a web site successfully providing TLSv1.3 (rfc8446) I can negotiate a TLS 1.3 connection from another openssl 1.1.1 client. I am also successful connecting with Firefox Nightly 64.0a1. Support for RFC 8446 was added in version 63 which is expected to ship October 2018. There is one error that I receive during initial 'make' if the package converters/libiconv is installed on the system: Temporarily uninstalling libiconv allows 'make' to finish. However libiconv must be reinstalled prior to 'make install' to avoid another error: rsync is the only pkg that depends on libiconv so i'm not sure why it would interfere in the make process. After successfully compiling and installing this branch, httpd appears to have the backported features working. Thank you everyone for all your efforts in bringing this backport proposal forward. Cheers, Dennis -- Sent from: http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html
Re: TLSv1.3 supprt for 2.4.x?
> Am 18.09.2018 um 17:03 schrieb Joe Orton : > >> On Tue, Sep 18, 2018 at 04:54:58PM +0200, Yann Ylavic wrote: >>> On Tue, Sep 18, 2018 at 4:08 PM Joe Orton wrote: >>> >>> As of r1841219 I think the tlsv1.3-for-2.4.x is ready for merging... >> >> Thanks Joe for the hard work! > > Thanks to Stefan for getting us most of the way! > I did the easy parts. You pulled this through. Thanks! >> Does it work for mod_proxy auth with a httpd backend, both in TLS 1.3? >> I wonder because PHA isn't enabled on mod_proxy either, IIUC. >> Will test but possibly you did it already. > > I thinkso but I will double-check it is being tested under TLSv1.3, I > added this for that case specifically, IIRC because I was seeing test > failures without it: > > http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?view=markup=1840710#l1561 > > Regards, Joe
Re: TLSv1.3 supprt for 2.4.x?
On Tue, Sep 18, 2018 at 04:54:58PM +0200, Yann Ylavic wrote: > On Tue, Sep 18, 2018 at 4:08 PM Joe Orton wrote: > > > > As of r1841219 I think the tlsv1.3-for-2.4.x is ready for merging... > > Thanks Joe for the hard work! Thanks to Stefan for getting us most of the way! > Does it work for mod_proxy auth with a httpd backend, both in TLS 1.3? > I wonder because PHA isn't enabled on mod_proxy either, IIUC. > Will test but possibly you did it already. I think so but I will double-check it is being tested under TLSv1.3, I added this for that case specifically, IIRC because I was seeing test failures without it: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?view=markup=1840710#l1561 Regards, Joe
Re: TLSv1.3 supprt for 2.4.x?
On Tue, Sep 18, 2018 at 4:08 PM Joe Orton wrote: > > As of r1841219 I think the tlsv1.3-for-2.4.x is ready for merging... Thanks Joe for the hard work! > > A BIG caveat remains around Post-Handshake Auth. With the current Perl > stack (including whatever adjustments for OpenSSL 1.1.1 already > required) the failures I get with the test suite and that branch are > significant, because PHA is NOT enabled by default client-side and a > bunch of the tests rely on that. Does it work for mod_proxy auth with a httpd backend, both in TLS 1.3? I wonder because PHA isn't enabled on mod_proxy either, IIUC. Will test but possibly you did it already. > > I don't understand the logic behind disabling PHA by default, and I > think it's a serious error, but I am not optimistic that the decision > will be reversed. It's completely incomprehensible I guess... Regards, Yann.
Re: TLSv1.3 supprt for 2.4.x?
As of r1841219 I think the tlsv1.3-for-2.4.x is ready for merging... A BIG caveat remains around Post-Handshake Auth. With the current Perl stack (including whatever adjustments for OpenSSL 1.1.1 already required) the failures I get with the test suite and that branch are significant, because PHA is NOT enabled by default client-side and a bunch of the tests rely on that. I don't understand the logic behind disabling PHA by default, and I think it's a serious error, but I am not optimistic that the decision will be reversed. So with PHA disabled client side I get: t/security/CVE-2009-3555.t(Wstat: 0 Tests: 4 Failed: 2) Failed tests: 3-4 t/ssl/basicauth.t (Wstat: 0 Tests: 4 Failed: 2) Failed tests: 2-3 t/ssl/env.t (Wstat: 0 Tests: 30 Failed: 15) Failed tests: 16-30 t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4) Failed tests: 1-4 t/ssl/fakeauth.t (Wstat: 0 Tests: 3 Failed: 2) Failed tests: 2-3 t/ssl/ocsp.t (Wstat: 0 Tests: 3 Failed: 1) Failed test: 3 t/ssl/require.t (Wstat: 0 Tests: 10 Failed: 3) Failed tests: 2, 5, 9 t/ssl/varlookup.t (Wstat: 0 Tests: 83 Failed: 83) Failed tests: 1-83 t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1) Failed test: 2 Hacking the Perl stack to enable PHA by default, PoC patches here - http://people.apache.org/~jorton/tlsv13-pha-snafu/ - I get: t/security/CVE-2009-3555.t(Wstat: 0 Tests: 4 Failed: 2) Failed tests: 3-4 t/ssl/ocsp.t (Wstat: 0 Tests: 3 Failed: 1) Failed test: 3 which I believe are both false +ves. I'll continue working these remaining failures. Regards, Joe
Re: TLSv1.3 supprt for 2.4.x?
On Wed, Sep 12, 2018 at 3:17 PM Joe Orton wrote:
>
> On Tue, Sep 11, 2018 at 03:39:42PM +0200, Yann Ylavic wrote:
> > On Tue, Sep 11, 2018 at 12:13 PM Joe Orton wrote:
> > >
> > > Does anybody have successful test results with post-handshake auth? I'm
> > > testing against Fedora's OpenSSL 1.1.1pre9 which has merged the changes
> > > for https://github.com/openssl/openssl/issues/6933
> >
> > Just tried trunk+openssl-1.1.1pre9 (SSLProtocol TLSv1.3 and
> > SSLVerifyClient require), with both firefox and s_client (w/ and w/o
> > -enable_pha) and can't reproduce the hang.
> >
> > What's your client tooling?
>
> Have you tried the test suite with trunk+pre9? I haven't had time to
> test this directly, but with Fedora 29's pre9 + tls1.3-2.4.x branch I am
> down to:
>
> $ ./t/TEST t/ssl/
> ...
> Failed 5/14 test programs. 12/331 subtests failed.
With patch [1] (SSL_CTX_clear_mode for AUTO_RETRY) and your latest
framework changes, the only errors remaining are:
t/modules/http2.t ... Failed 28/52 subtests
("Parse errors: Bad plan. You planned 52 tests but ran 24", tests
skipped because of TLS-1.3??).
t/ssl/proxy.t .. 3/? # Failed test 3 in t/ssl/proxy.t at line 63
# Failed test 5 in t/ssl/proxy.t at line 75
# Failed test 6 in t/ssl/proxy.t at line 89
# Failed test 7 in t/ssl/proxy.t at line 95
t/ssl/proxy.t .. 113/? # Failed test 116 in t/ssl/proxy.t at line 63 fail #2
# Failed test 118 in t/ssl/proxy.t at line 75 fail #2
# Failed test 119 in t/ssl/proxy.t at line 89 fail #2
# Failed test 120 in t/ssl/proxy.t at line 95 fail #2
t/ssl/proxy.t .. Failed 8/172 subtests
(didn't look at the details)
For the ssl/proxy ones, I tried with patch [2]
(SSL_CTX_set_post_handshake_auth):
t/ssl/proxy.t .. 1/? # Failed test 4 in t/ssl/proxy.t at line 69
t/ssl/proxy.t .. 108/? # Failed test 117 in t/ssl/proxy.t at line 69 fail #2
t/ssl/proxy.t .. Failed 2/172 subtests
(better but not really that yet. Anyway I don't really understand why
we'd do that, and how it helps Perl, given that it's supposed to be
opt-in for compatibility, and AFAICT ssl/proxy tests don't use
TLS-1.3...)
>
> 1. disable AUTO_RETRY to fix PHA
> https://github.com/openssl/openssl/issues/7178#issuecomment-420300988
>
> 2. too much code has been moved out of ssl_hook_Access(), the
> FakeBasicAuth code & requires checking needs to come back
>
> 3. perl client side updates needed in IO::Socket:SSL and Net::SSLeay to
> re-enable PHA because of https://github.com/openssl/openssl/issues/6933
>
> I will commit (1) and (2) today/tomorrow. I think (3) is, um, bizarre,
> but I'm not sure whether it is simpler to fight OpenSSL API design
> decisions or change every SSL client in the world to cope with them,
> probably the latter.
I can't grok that change needed on the client-side either :/
Regards,
Yann.
[1]:
Index: modules/ssl/ssl_engine_init.c
===
--- modules/ssl/ssl_engine_init.c(revision 1840709)
+++ modules/ssl/ssl_engine_init.c(working copy)
@@ -786,6 +786,10 @@ static apr_status_t ssl_init_ctx_protocol(server_r
SSL_CTX_set_mode(ctx, SSL_MODE_RELEASE_BUFFERS);
#endif
+#ifdef SSL_MODE_AUTO_RETRY
+SSL_CTX_clear_mode(ctx, SSL_MODE_AUTO_RETRY);
+#endif
+
return APR_SUCCESS;
}
--
[2]:
Index: modules/ssl/ssl_engine_init.c
===
--- modules/ssl/ssl_engine_init.c(revision 1840709)
+++ modules/ssl/ssl_engine_init.c(working copy)
@@ -1553,6 +1557,11 @@ static apr_status_t ssl_init_proxy_certs(server_re
SSL_CTX_set_client_cert_cb(mctx->ssl_ctx,
ssl_callback_proxy_cert);
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+if (/*mctx->enable_pha*/1) {
+SSL_CTX_set_post_handshake_auth(mctx->ssl_ctx, 1);
+}
+#endif
if (!(pkp->cert_file || pkp->cert_path)) {
return APR_SUCCESS;
--
Re: TLSv1.3 supprt for 2.4.x?
On Tue, Sep 11, 2018 at 03:39:42PM +0200, Yann Ylavic wrote: > On Tue, Sep 11, 2018 at 12:13 PM Joe Orton wrote: > > > > Does anybody have successful test results with post-handshake auth? I'm > > testing against Fedora's OpenSSL 1.1.1pre9 which has merged the changes > > for https://github.com/openssl/openssl/issues/6933 > > Just tried trunk+openssl-1.1.1pre9 (SSLProtocol TLSv1.3 and > SSLVerifyClient require), with both firefox and s_client (w/ and w/o > -enable_pha) and can't reproduce the hang. > > What's your client tooling? Have you tried the test suite with trunk+pre9? I haven't had time to test this directly, but with Fedora 29's pre9 + tls1.3-2.4.x branch I am down to: $ ./t/TEST t/ssl/ ... Failed 5/14 test programs. 12/331 subtests failed. needed to get this far: 1. disable AUTO_RETRY to fix PHA https://github.com/openssl/openssl/issues/7178#issuecomment-420300988 2. too much code has been moved out of ssl_hook_Access(), the FakeBasicAuth code & requires checking needs to come back 3. perl client side updates needed in IO::Socket:SSL and Net::SSLeay to re-enable PHA because of https://github.com/openssl/openssl/issues/6933 I will commit (1) and (2) today/tomorrow. I think (3) is, um, bizarre, but I'm not sure whether it is simpler to fight OpenSSL API design decisions or change every SSL client in the world to cope with them, probably the latter.
Re: TLSv1.3 supprt for 2.4.x?
On Tue, Sep 11, 2018 at 03:39:42PM +0200, Yann Ylavic wrote: > On Tue, Sep 11, 2018 at 12:13 PM Joe Orton wrote: > > > > Does anybody have successful test results with post-handshake auth? I'm > > testing against Fedora's OpenSSL 1.1.1pre9 which has merged the changes > > for https://github.com/openssl/openssl/issues/6933 > > Just tried trunk+openssl-1.1.1pre9 (SSLProtocol TLSv1.3 and > SSLVerifyClient require), with both firefox and s_client (w/ and w/o > -enable_pha) and can't reproduce the hang. Interesting. I will test with trunk next then. > What's your client tooling? Perl/OpenSSL stack, e.g. running t/ssl/basicauth.t from the test suite is sufficient to trigger this for me.
Re: TLSv1.3 supprt for 2.4.x?
On Tue, Sep 11, 2018 at 12:13 PM Joe Orton wrote: > > Does anybody have successful test results with post-handshake auth? I'm > testing against Fedora's OpenSSL 1.1.1pre9 which has merged the changes > for https://github.com/openssl/openssl/issues/6933 Just tried trunk+openssl-1.1.1pre9 (SSLProtocol TLSv1.3 and SSLVerifyClient require), with both firefox and s_client (w/ and w/o -enable_pha) and can't reproduce the hang. What's your client tooling? Regards, Yann.
Re: TLSv1.3 supprt for 2.4.x?
On Tue, Sep 11, 2018 at 10:42:02AM +0200, Stefan Eissing wrote: > > Am 10.09.2018 um 10:59 schrieb Joe Orton : > > http://svn.apache.org/viewvc?view=revision=1828220 > > - I think this is merged in the branch slightly differently? > > I think this overlaps with a subsequent change of SSL_HAVE_PROTOCOL_TLSV1_3 > vs. SSL_OP_NO_TLSv1_3? Feel free to fix this as you think it's best. Probably just need to mark it merged, ignore this for now. > > http://svn.apache.org/viewvc?view=revision=1828790 > > http://svn.apache.org/viewvc?view=revision=1828791 > > http://svn.apache.org/viewvc?view=revision=1828792 > > - I think these should be merged too? > > Just done. Thanks! Thanks a lot. Does anybody have successful test results with post-handshake auth? I'm testing against Fedora's OpenSSL 1.1.1pre9 which has merged the changes for https://github.com/openssl/openssl/issues/6933 I'm not able to get a successful PHA exchange, even with a client which explicitly enables PHA. It seems like the test suite will be broken until the Perl stack is patched to enable PHA somehow, which is a massive headache AFAICT. Without the SSL_peek(ssl, peekbuf, 0) after SSL_do_handshake(), OpenSSL is sending the CertificateRequest to the client but doesn't wait to read the response. With the SSL_peek() call I think it successfully completes the "handshake" (and gets the cert) but then hangs waiting for app_data which is never coming, and eventually times out. Anybody got better results? Regards, Joe
Re: TLSv1.3 supprt for 2.4.x?
> Am 10.09.2018 um 10:59 schrieb Joe Orton : > > On Wed, Sep 05, 2018 at 01:36:06PM +0200, Stefan Eissing wrote: >> A member of the OpenSSL project gave me a "go ahead" and we now have branch: >> >> https://svn.apache.org/repos/asf/httpd/httpd/branches/tlsv1.3-for-2.4.x >> >> as a copy of 2.4.x with >> 1827912,1827924,1827992,1828222,1828720,1828723,1833588,1833589,1839920,1839946 >> merged in. If was not a clean merge as some feature from trunk are not >> present in 2.4.x, so peer review/test is definitely desired. > > Awesome, thank you Stefan! > > Comparing to what I produced for Fedora, I had a few extra revisions > backported (and also missed some of the later ones you caught): > > http://svn.apache.org/viewvc?view=revision=1828220 > - I think this is merged in the branch slightly differently? I think this overlaps with a subsequent change of SSL_HAVE_PROTOCOL_TLSV1_3 vs. SSL_OP_NO_TLSv1_3? Feel free to fix this as you think it's best. > http://svn.apache.org/viewvc?view=revision=1828790 > http://svn.apache.org/viewvc?view=revision=1828791 > http://svn.apache.org/viewvc?view=revision=1828792 > - I think these should be merged too? Just done. Thanks! > > I will do some testing now. > > Regards, Joe
Re: TLSv1.3 supprt for 2.4.x?
On Wed, Sep 05, 2018 at 01:36:06PM +0200, Stefan Eissing wrote: > A member of the OpenSSL project gave me a "go ahead" and we now have branch: > > https://svn.apache.org/repos/asf/httpd/httpd/branches/tlsv1.3-for-2.4.x > > as a copy of 2.4.x with > 1827912,1827924,1827992,1828222,1828720,1828723,1833588,1833589,1839920,1839946 > merged in. If was not a clean merge as some feature from trunk are not > present in 2.4.x, so peer review/test is definitely desired. Awesome, thank you Stefan! Comparing to what I produced for Fedora, I had a few extra revisions backported (and also missed some of the later ones you caught): http://svn.apache.org/viewvc?view=revision=1828220 - I think this is merged in the branch slightly differently? http://svn.apache.org/viewvc?view=revision=1828790 http://svn.apache.org/viewvc?view=revision=1828791 http://svn.apache.org/viewvc?view=revision=1828792 - I think these should be merged too? I will do some testing now. Regards, Joe
Re: TLSv1.3 supprt for 2.4.x?
On Thu, Sep 6, 2018 at 3:13 AM Stefan Eissing wrote: > > > I can't imagine the project releasing this changeset without first > releasing > > a stable 2.4.35, followed shortly thereafter with a less stable TLS 1.3 > > release. It appears to introduce a set of required(?) config changes, > > something we've never purposefully done in a major.minor update. > > I think we will find common ground in that we do not want to interrupt > existing > httpd deployments with such a feature. On the other hand, we have a > responsibility > also as one of the leading HTTP servers on this planet, to enable our > users to > protect themselves by applying the latest tech in security. > > This, we have to balance. > > Precisely for this feature, we need to evaluate: > - do we introduce config breaking changes? > I added the optional parameter to SSLCipherSuite in a way that does not > (or should not) affect existing configurations. If I erred, it would be > good to find out. > +1 - no breaking changes. Adding the parameter optional (default TLS 1.2 and earlier) should accomplish this. Trusting OpenSSL initially to provide only more-secure TLS 1.3 ciphers suggests that folks won't need to drop ciphers from that list for some time, yet. > - does this change affect servers linked with OpenSSL 1.0.x or older? > The intention of the change is to not do that. The guarding of changes > by #ifdef make it work with OpenSSL 1.0.2 for me. I invited Bernard > explicitly to test his libressl setups to get broader coverage. Maybe > Rainer and Rüdiger will find the time to tests their various setups. > +1 - If we still compile successfully against 0.9.8/1.0.0/1.0.1 it would be a kindness to our users on older OS distributions, granted only 1.0.2 and onwards are still "supported" by OpenSSL, but OS vendors may be maintaining their forks longer. > - servers linking with a latest *SSL library (or distros shipping it that > way) will see TLSv1.3 enabled, unless the configurations remove it > explicitly. I think, based on feedback from others, this is what we want to > happen. > +1 - Given the (presumably) sane set of defaults. > All this can and should be discussed by bringing forth technical arguments > or counter examples, IMO. For the release, there will be voting, just as > with other backport proposals, will it not? > Agreed, as to review for release. To the subject top-thread, feedback to the merge branch would be early, easy, appreciated, and save iterations, so is not a waste of effort for those willing to review the design decisions. For who are uncomfortable running ./buildconf against a checkout, they do not lose the opportunity to review.
Re: TLSv1.3 supprt for 2.4.x?
> Am 05.09.2018 um 18:52 schrieb William A Rowe Jr : > > On Wed, Sep 5, 2018 at 10:52 AM, Dennis Clarke wrote: > On 09/05/2018 07:36 AM, Stefan Eissing wrote: > A member of the OpenSSL project gave me a "go ahead" and we now have branch: > > https://svn.apache.org/repos/asf/httpd/httpd/branches/tlsv1.3-for-2.4.x > > as a copy of 2.4.x with > 1827912,1827924,1827992,1828222,1828720,1828723,1833588,1833589,1839920,1839946 > merged in. If was not a clean merge as some feature from trunk are not > present in 2.4.x, so peer review/test is definitely desired. > > I put a backport proposal into 2.4.x/STATUS > > Cheers, Stefan > > > Awesome but there are plenty of folks that will want a simple tarball > with the usual autoconf/configure magic done for them. Could be a waste > of effort given that OpenSSL 1.1.1 release is 6 days away. > > Not a waste of effort. > > The project can't realistically deliver such a large changeset without wider > testing, the number of issues raised on multiple forums demonstrate that. > (Thankfully > 50% are users who were unaware of draft vs. final TLS > handshake signatures, and such inattentive users aren't productively > contributing to interoperability review.) Users who are prepared to > *constructively* engage on any proposed changeset should have few > problems with a couple extra steps. If there are interop problems at the TLS layer itself, these are not directly a concert to httpd, but a matter of IETF draft versions and implementations to sort out. At this point, we will not help resolving interop issues by holding back a release that can use TLSv1.3. > I can't imagine the project releasing this changeset without first releasing > a stable 2.4.35, followed shortly thereafter with a less stable TLS 1.3 > release. It appears to introduce a set of required(?) config changes, > something we've never purposefully done in a major.minor update. I think we will find common ground in that we do not want to interrupt existing httpd deployments with such a feature. On the other hand, we have a responsibility also as one of the leading HTTP servers on this planet, to enable our users to protect themselves by applying the latest tech in security. This, we have to balance. Precisely for this feature, we need to evaluate: - do we introduce config breaking changes? I added the optional parameter to SSLCipherSuite in a way that does not (or should not) affect existing configurations. If I erred, it would be good to find out. - does this change affect servers linked with OpenSSL 1.0.x or older? The intention of the change is to not do that. The guarding of changes by #ifdef make it work with OpenSSL 1.0.2 for me. I invited Bernard explicitly to test his libressl setups to get broader coverage. Maybe Rainer and Rüdiger will find the time to tests their various setups. - servers linking with a latest *SSL library (or distros shipping it that way) will see TLSv1.3 enabled, unless the configurations remove it explicitly. I think, based on feedback from others, this is what we want to happen. All this can and should be discussed by bringing forth technical arguments or counter examples, IMO. For the release, there will be voting, just as with other backport proposals, will it not? Cheers, Stefan
Re: TLSv1.3 supprt for 2.4.x?
Just tested this branch with OpenSSL 1.1.1p9. Haven't found issues yet. > Listen 42002 https > SSLHonorCipherOrder on > SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 Server error.log > AH00489: Apache/2.4.35-dev (FreeBSD) OpenSSL/1.1.1-pre9 configured -- > resuming normal operations client `openssl s_client -connect localhost:42002` > New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 I like the default server cipher selection! On Wed, Sep 5, 2018 at 1:36 PM Stefan Eissing wrote: > > A member of the OpenSSL project gave me a "go ahead" and we now have branch: > > https://svn.apache.org/repos/asf/httpd/httpd/branches/tlsv1.3-for-2.4.x > > as a copy of 2.4.x with > 1827912,1827924,1827992,1828222,1828720,1828723,1833588,1833589,1839920,1839946 > merged in. If was not a clean merge as some feature from trunk are not > present in 2.4.x, so peer review/test is definitely desired. > > I put a backport proposal into 2.4.x/STATUS > > Cheers, Stefan > > > > Am 03.09.2018 um 15:45 schrieb Jim Jagielski : > > > > +1! for backporting > > > >> On Sep 3, 2018, at 5:17 AM, Stefan Eissing > >> wrote: > >> > >> Dear SSL care takers and stake holders, > >> > >> trunk has TLSv1.3 support for some time. I just now changed the 'all' > >> SSLProtocol selection, so that it does not include TLSv1.3. This means > >> that in order to enable it, admins must add an explicit '+TLSv1.3' to > >> their config (same for SSLProxyProtocl of course). > >> > >> With this, the added support is really an opt-in and we could backport it > >> to 2.4.x, if we want. We have been burned with backporting SSL features > >> just recently (by my mistake), so I would understand that people feel a > >> bit reluctant here. On the other hand, there is certainly interest by > >> users. > >> > >> So, what is your opinion? > >> > >> Cheers, > >> > >> Stefan > >> > >> PS. There are some combinations in renegotiation/client certs that are not > >> tested well. Therefore, '+TLSv1.3' should be tagged as 'experimental' or > >> at least with a heavy caveat for those setups. But I see no issue with > >> using it for plain-vanilla https: setups. > > >
Re: TLSv1.3 supprt for 2.4.x?
Hi All, I've received a patch from the LibreSSL devs via mail. That resolves the renegotiation issue. Patch is awaiting review, I expect it to land in the LibreSSL repo soon. Cheers, Bernard. On Mon, Sep 3, 2018 at 1:36 PM Stefan Eissing wrote: > > Speaking of SSL and rare renegotiation setups: Bernard and me are suspecting > that > libressl has issues here for quite some time. At least it looks that way: > > https://github.com/libressl-portable/portable/issues/443 > > Just FYI in case someone encounters such things. > > > Am 03.09.2018 um 13:32 schrieb Stefan Eissing > > : > > > > > > > >> Am 03.09.2018 um 13:19 schrieb Joe Orton : > >> > >> On Mon, Sep 03, 2018 at 11:17:39AM +0200, Stefan Eissing wrote: > >>> Dear SSL care takers and stake holders, > >>> > >>> trunk has TLSv1.3 support for some time. I just now changed the 'all' > >>> SSLProtocol selection, so that it does not include TLSv1.3. This means > >>> that in order to enable it, admins must add an explicit '+TLSv1.3' to > >>> their config (same for SSLProxyProtocl of course). > >>> > >>> With this, the added support is really an opt-in and we could backport it > >>> to 2.4.x, if we want. We have been burned with backporting SSL features > >>> just recently (by my mistake), so I would understand that people feel a > >>> bit reluctant here. On the other hand, there is certainly interest by > >>> users. > >>> > >>> So, what is your opinion? > >> > >> Yes, I just worked on a backport of that set for Fedora, so I'm on board > >> for pushing & testing that in 2.4.x. Possibly warrants a branch to work > >> through the merge? > > > > We could do that. The patch, right now, is not that large, I think, but > > a branch does not hurt. > > > >>> PS. There are some combinations in renegotiation/client certs that are > >>> not tested well. Therefore, '+TLSv1.3' should be tagged as > >>> 'experimental' or at least with a heavy caveat for those setups. But I > >>> see no issue with using it for plain-vanilla https: setups. > >> > >> AIUI the various bits of new API added for TLS/1.3 are not necessarily > >> stable until there is a final OpenSSL 1.1.1 release, so maybe we should > >> wait for that first? > > > > I think they (or at least the parts we use) have been stable since pre3 in > > spring. There have been fixes under the hood in timing of callbacks, AFAIK. > > Since none of these are in any public part of httpd - apart from the > > protocol config which we alaways be there - I think we could broaden the > > test audience without much risk. > > > >> IMO there is no problem with supporting it by default (not needing > >> explicit +TLSv1.3) in 2.4. Since "bleeding edge OpenSSL" is needed to > >> enable it at build time, this isn't going to break production users on > >> current systems. > > > > Interesting. If that is consensus, I'd revert my change from earlier today. > > > > Cheers, Stefan > > > >> Regards, Joe >
Re: TLSv1.3 supprt for 2.4.x?
On Wed, Sep 5, 2018 at 10:52 AM, Dennis Clarke wrote: > On 09/05/2018 07:36 AM, Stefan Eissing wrote: > >> A member of the OpenSSL project gave me a "go ahead" and we now have >> branch: >> >> https://svn.apache.org/repos/asf/httpd/httpd/branches/tlsv1.3-for-2.4.x >> >> as a copy of 2.4.x with 1827912,1827924,1827992,182822 >> 2,1828720,1828723,1833588,1833589,1839920,1839946 merged in. If was not >> a clean merge as some feature from trunk are not present in 2.4.x, so peer >> review/test is definitely desired. >> >> I put a backport proposal into 2.4.x/STATUS >> >> Cheers, Stefan >> > > > Awesome but there are plenty of folks that will want a simple tarball > with the usual autoconf/configure magic done for them. Could be a waste > of effort given that OpenSSL 1.1.1 release is 6 days away. Not a waste of effort. The project can't realistically deliver such a large changeset without wider testing, the number of issues raised on multiple forums demonstrate that. (Thankfully > 50% are users who were unaware of draft vs. final TLS handshake signatures, and such inattentive users aren't productively contributing to interoperability review.) Users who are prepared to *constructively* engage on any proposed changeset should have few problems with a couple extra steps. I can't imagine the project releasing this changeset without first releasing a stable 2.4.35, followed shortly thereafter with a less stable TLS 1.3 release. It appears to introduce a set of required(?) config changes, something we've never purposefully done in a major.minor update.
Re: TLSv1.3 supprt for 2.4.x?
On 09/05/2018 07:36 AM, Stefan Eissing wrote: A member of the OpenSSL project gave me a "go ahead" and we now have branch: https://svn.apache.org/repos/asf/httpd/httpd/branches/tlsv1.3-for-2.4.x as a copy of 2.4.x with 1827912,1827924,1827992,1828222,1828720,1828723,1833588,1833589,1839920,1839946 merged in. If was not a clean merge as some feature from trunk are not present in 2.4.x, so peer review/test is definitely desired. I put a backport proposal into 2.4.x/STATUS Cheers, Stefan Awesome but there are plenty of folks that will want a simple tarball with the usual autoconf/configure magic done for them. Could be a waste of effort given that OpenSSL 1.1.1 release is 6 days away. Dennis
Re: TLSv1.3 supprt for 2.4.x?
On 09/03/2018 09:45 AM, Jim Jagielski wrote: +1! for backporting >> On Sep 3, 2018, at 5:17 AM, Stefan Eissing wrote: >> >> Dear SSL care takers and stake holders, >> >> trunk has TLSv1.3 support for some time. TLSv1.3 is a published protocol and I see no reason why it wouldn't be available in a stable release. https://tools.ietf.org/html/rfc8446 Dennis
Re: TLSv1.3 supprt for 2.4.x?
+1! for backporting > On Sep 3, 2018, at 5:17 AM, Stefan Eissing > wrote: > > Dear SSL care takers and stake holders, > > trunk has TLSv1.3 support for some time. I just now changed the 'all' > SSLProtocol selection, so that it does not include TLSv1.3. This means that > in order to enable it, admins must add an explicit '+TLSv1.3' to their config > (same for SSLProxyProtocl of course). > > With this, the added support is really an opt-in and we could backport it to > 2.4.x, if we want. We have been burned with backporting SSL features just > recently (by my mistake), so I would understand that people feel a bit > reluctant here. On the other hand, there is certainly interest by users. > > So, what is your opinion? > > Cheers, > > Stefan > > PS. There are some combinations in renegotiation/client certs that are not > tested well. Therefore, '+TLSv1.3' should be tagged as 'experimental' or at > least with a heavy caveat for those setups. But I see no issue with using it > for plain-vanilla https: setups.
Re: TLSv1.3 supprt for 2.4.x?
Am 03.09.2018 um 13:19 schrieb Joe Orton: AIUI the various bits of new API added for TLS/1.3 are not necessarily stable until there is a final OpenSSL 1.1.1 release, so maybe we should wait for that first? Last mentioned date for GA release of OpenSSL 1.1.1 was Tuesday 11th September. Not sure how fix this it, but at least that would be pretty close. Regards, Rainer
Re: TLSv1.3 supprt for 2.4.x?
> Am 03.09.2018 um 13:56 schrieb Ruediger Pluem : > > > > On 09/03/2018 01:32 PM, Stefan Eissing wrote: >> >> >>> Am 03.09.2018 um 13:19 schrieb Joe Orton : >>> >>> On Mon, Sep 03, 2018 at 11:17:39AM +0200, Stefan Eissing wrote: Dear SSL care takers and stake holders, > >> >>> IMO there is no problem with supporting it by default (not needing >>> explicit +TLSv1.3) in 2.4. Since "bleeding edge OpenSSL" is needed to >>> enable it at build time, this isn't going to break production users on >>> current systems. >> >> Interesting. If that is consensus, I'd revert my change from earlier today. > > +1 Done in r1839946. Cheers, Stefan
Re: TLSv1.3 supprt for 2.4.x?
On 09/03/2018 01:32 PM, Stefan Eissing wrote: > > >> Am 03.09.2018 um 13:19 schrieb Joe Orton : >> >> On Mon, Sep 03, 2018 at 11:17:39AM +0200, Stefan Eissing wrote: >>> Dear SSL care takers and stake holders, > >> IMO there is no problem with supporting it by default (not needing >> explicit +TLSv1.3) in 2.4. Since "bleeding edge OpenSSL" is needed to >> enable it at build time, this isn't going to break production users on >> current systems. > > Interesting. If that is consensus, I'd revert my change from earlier today. +1 Regards Rüdiger
Re: TLSv1.3 supprt for 2.4.x?
Speaking of SSL and rare renegotiation setups: Bernard and me are suspecting that libressl has issues here for quite some time. At least it looks that way: https://github.com/libressl-portable/portable/issues/443 Just FYI in case someone encounters such things. > Am 03.09.2018 um 13:32 schrieb Stefan Eissing : > > > >> Am 03.09.2018 um 13:19 schrieb Joe Orton : >> >> On Mon, Sep 03, 2018 at 11:17:39AM +0200, Stefan Eissing wrote: >>> Dear SSL care takers and stake holders, >>> >>> trunk has TLSv1.3 support for some time. I just now changed the 'all' >>> SSLProtocol selection, so that it does not include TLSv1.3. This means that >>> in order to enable it, admins must add an explicit '+TLSv1.3' to their >>> config (same for SSLProxyProtocl of course). >>> >>> With this, the added support is really an opt-in and we could backport it >>> to 2.4.x, if we want. We have been burned with backporting SSL features >>> just recently (by my mistake), so I would understand that people feel a bit >>> reluctant here. On the other hand, there is certainly interest by users. >>> >>> So, what is your opinion? >> >> Yes, I just worked on a backport of that set for Fedora, so I'm on board >> for pushing & testing that in 2.4.x. Possibly warrants a branch to work >> through the merge? > > We could do that. The patch, right now, is not that large, I think, but > a branch does not hurt. > >>> PS. There are some combinations in renegotiation/client certs that are >>> not tested well. Therefore, '+TLSv1.3' should be tagged as >>> 'experimental' or at least with a heavy caveat for those setups. But I >>> see no issue with using it for plain-vanilla https: setups. >> >> AIUI the various bits of new API added for TLS/1.3 are not necessarily >> stable until there is a final OpenSSL 1.1.1 release, so maybe we should >> wait for that first? > > I think they (or at least the parts we use) have been stable since pre3 in > spring. There have been fixes under the hood in timing of callbacks, AFAIK. > Since none of these are in any public part of httpd - apart from the > protocol config which we alaways be there - I think we could broaden the > test audience without much risk. > >> IMO there is no problem with supporting it by default (not needing >> explicit +TLSv1.3) in 2.4. Since "bleeding edge OpenSSL" is needed to >> enable it at build time, this isn't going to break production users on >> current systems. > > Interesting. If that is consensus, I'd revert my change from earlier today. > > Cheers, Stefan > >> Regards, Joe
Re: TLSv1.3 supprt for 2.4.x?
> Am 03.09.2018 um 13:19 schrieb Joe Orton : > > On Mon, Sep 03, 2018 at 11:17:39AM +0200, Stefan Eissing wrote: >> Dear SSL care takers and stake holders, >> >> trunk has TLSv1.3 support for some time. I just now changed the 'all' >> SSLProtocol selection, so that it does not include TLSv1.3. This means that >> in order to enable it, admins must add an explicit '+TLSv1.3' to their >> config (same for SSLProxyProtocl of course). >> >> With this, the added support is really an opt-in and we could backport it to >> 2.4.x, if we want. We have been burned with backporting SSL features just >> recently (by my mistake), so I would understand that people feel a bit >> reluctant here. On the other hand, there is certainly interest by users. >> >> So, what is your opinion? > > Yes, I just worked on a backport of that set for Fedora, so I'm on board > for pushing & testing that in 2.4.x. Possibly warrants a branch to work > through the merge? We could do that. The patch, right now, is not that large, I think, but a branch does not hurt. >> PS. There are some combinations in renegotiation/client certs that are >> not tested well. Therefore, '+TLSv1.3' should be tagged as >> 'experimental' or at least with a heavy caveat for those setups. But I >> see no issue with using it for plain-vanilla https: setups. > > AIUI the various bits of new API added for TLS/1.3 are not necessarily > stable until there is a final OpenSSL 1.1.1 release, so maybe we should > wait for that first? I think they (or at least the parts we use) have been stable since pre3 in spring. There have been fixes under the hood in timing of callbacks, AFAIK. Since none of these are in any public part of httpd - apart from the protocol config which we alaways be there - I think we could broaden the test audience without much risk. > IMO there is no problem with supporting it by default (not needing > explicit +TLSv1.3) in 2.4. Since "bleeding edge OpenSSL" is needed to > enable it at build time, this isn't going to break production users on > current systems. Interesting. If that is consensus, I'd revert my change from earlier today. Cheers, Stefan > Regards, Joe
Re: TLSv1.3 supprt for 2.4.x?
On Mon, Sep 03, 2018 at 11:17:39AM +0200, Stefan Eissing wrote: > Dear SSL care takers and stake holders, > > trunk has TLSv1.3 support for some time. I just now changed the 'all' > SSLProtocol selection, so that it does not include TLSv1.3. This means that > in order to enable it, admins must add an explicit '+TLSv1.3' to their config > (same for SSLProxyProtocl of course). > > With this, the added support is really an opt-in and we could backport it to > 2.4.x, if we want. We have been burned with backporting SSL features just > recently (by my mistake), so I would understand that people feel a bit > reluctant here. On the other hand, there is certainly interest by users. > > So, what is your opinion? Yes, I just worked on a backport of that set for Fedora, so I'm on board for pushing & testing that in 2.4.x. Possibly warrants a branch to work through the merge? > PS. There are some combinations in renegotiation/client certs that are > not tested well. Therefore, '+TLSv1.3' should be tagged as > 'experimental' or at least with a heavy caveat for those setups. But I > see no issue with using it for plain-vanilla https: setups. AIUI the various bits of new API added for TLS/1.3 are not necessarily stable until there is a final OpenSSL 1.1.1 release, so maybe we should wait for that first? IMO there is no problem with supporting it by default (not needing explicit +TLSv1.3) in 2.4. Since "bleeding edge OpenSSL" is needed to enable it at build time, this isn't going to break production users on current systems. Regards, Joe
