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&pathrev=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&pathrev=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&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&revision=1828790 > > http://svn.apache.org/viewvc?view=revision&revision=1828791 > > http://svn.apache.org/viewvc?view=revision&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&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&revision=1828790 > http://svn.apache.org/viewvc?view=revision&revision=1828791 > http://svn.apache.org/viewvc?view=revision&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&revision=1828220 - I think this is merged in the branch slightly differently? http://svn.apache.org/viewvc?view=revision&revision=1828790 http://svn.apache.org/viewvc?view=revision&revision=1828791 http://svn.apache.org/viewvc?view=revision&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?
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?
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
Re: TLSv1.3
Sorry William, didn't mean to disturb you. Just noticed some 2.5.1 and 2.5.1-dev strings appearing in commits. Hope the project will roll another 2.5-dev soon. OpenSSL 1.1.1 is nearing and a TLSv1.3 Apache server to go with that would be most excellent! Thanks! Bernard. 2018-04-10 17:35 GMT+02:00 William A Rowe Jr : > On Sun, Apr 8, 2018 at 11:37 AM, Bernard Spil wrote: >> Hi Stefan, Mario, >> >> I saw that 2.5.1-dev was tagged, is another release coming some time soon? > > Worried me enough to look; http://svn.apache.org/repos/asf/httpd/httpd/tags/ > > Thankfully nobody made such a tag. You'll note 2.5.0-alpha from a number > of months ago; this was the first in development of new tag and release > tooling, and as such it never made the cut. No word at this moment of the > next 2.5.1-alpha attempt.
Re: TLSv1.3
On Sun, Apr 8, 2018 at 11:37 AM, Bernard Spil wrote: > Hi Stefan, Mario, > > I saw that 2.5.1-dev was tagged, is another release coming some time soon? Worried me enough to look; http://svn.apache.org/repos/asf/httpd/httpd/tags/ Thankfully nobody made such a tag. You'll note 2.5.0-alpha from a number of months ago; this was the first in development of new tag and release tooling, and as such it never made the cut. No word at this moment of the next 2.5.1-alpha attempt.
Re: TLSv1.3
> Am 08.04.2018 um 18:37 schrieb Bernard Spil : > > Hi Stefan, Mario, > > LibreSSL will hopefully add TLSv1.3 to the next version (ca. 6 > months). So I can't test with that just yet. > > Yes, it does work only with Firefox Nightly. :/ Google Chrome Beta > doesn't negotiate 1.3 either. > Using 1.1.1-pre4 at the moment. > The security.tls.version.max in about:config doesn't help... Neither > do the TLS settings in Chrome chrome://flags > > To enable, you MUST add +TLSv1.3 to SSLProtocols? Otherwise it seems I > just get 1.2 No, it should be enabled by default and part of "all" in SSLProtocol. There is discussion if this is a smart move, however I checked in support for client certificates yesterday (needs more testing) that should keep it backward compatible. > I saw that 2.5.1-dev was tagged, is another release coming some time soon? Not that I know of. Cheers, Stefan > > Cheers, Bernard. > > > > 2018-04-03 14:58 GMT+02:00 Stefan Eissing : >> Just added your patch for the latest libressl checks. Thanks! >> >> If I run that version against Firefox Nightly, it negotiates TLSv1.3. That >> is with OpenSSL 1.1.1-pre3; I have no test env for libressl. >> >> Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop. >> >> Cheers, >> >> Stefan >> >>> Am 31.03.2018 um 22:42 schrieb Bernard Spil : >>> >>> I'm running an Apache 2.5.1 snapshot from 2018-03-30 linked against >>> 1.1.1-pre3 from 2018-03-20 (AKA beta 1). >>> >>> If I connect to Apache with openssl 1.1.1 it makes a TLSv1.3 >>> connection. Qualys SSLLabs doesn't see the TLSv1.3 at all. >>> Additionally, Apache doesn't start when SSLOpenSSLConfCmd is used >>> (SSLOpenSSLConfCmd groups secp521r1:secp384r1:x25519) >>> Negotiated connections default to x25519 which is not what I expect. >>> >>> From another host: >>> >>> % /usr/local/bin/openssl version >>> OpenSSL 1.1.1-pre3 (beta) 20 Mar 2018 >>> >>> % /usr/local/bin/openssl s_client -connect test.brnrd.eu:443 >>> CONNECTED(0003) >>> depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 >>> verify return:1 >>> depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 >>> verify return:1 >>> depth=0 CN = test.brnrd.eu >>> verify return:1 >>> >>> --- >>> No client certificate CA names sent >>> Peer signing digest: SHA384 >>> Peer signature type: ECDSA >>> Server Temp Key: X25519, 253 bits >>> --- >>> SSL handshake has read 2696 bytes and written 390 bytes >>> Verification: OK >>> --- >>> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 >>> Server public key is 384 bit >>> Secure Renegotiation IS NOT supported >>> Compression: NONE >>> Expansion: NONE >>> No ALPN negotiated >>> Early data was not sent >>> SSL-Session: >>> Protocol : TLSv1.3 >>> Cipher: TLS_AES_256_GCM_SHA384 >>> Session-ID: >>> Session-ID-ctx: >>> Master-Key: >>> PSK identity: None >>> PSK identity hint: None >>> SRP username: None >>> Start Time: 1522528505 >>> Timeout : 7200 (sec) >>> Verify return code: 0 (ok) >>> Extended master secret: no >>> --- >>> >>> Firefox Nightly and Chrome don't negotiate TLSv1.3 either >>> Am I expecting things that I should not? (Entirely possible :D) >>> >>> Cheers, Bernard. >>> >>> >>> >>> 2018-03-29 16:11 GMT+02:00 Stefan Eissing : Done in r1827992. Cheers, Stefan > Am 29.03.2018 um 12:56 schrieb Greg Stein : > > On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing > wrote: >> ... > That is the intention behind "SSLPolicy modern|intermediate|old" that > configures the TLS stack according to the Mozilla server-side-tls > recommendations. So, one does not have to mess with many directives to > have a site with an "A" SSL Labs rating. > > Besides, except for data center setups, Apache will be used *only* with > https: (and http: redirects to https:) very, very soon. That shifts the > average expertise of an admin setting up a https: site. > > Back to TLSv1.3: > > I do not like to invent new config directives for a new TLS version > either. The protocol on/off switch is now in "SSLProtocol" and that's > where it should be. AFAIK, it's only the cipher list that needs special > treatment (if one wants to override defaults or what SSLPolicy will do > for it, once a recommendation is out). > > Gotcha. > > > So, looking at "SSLCipherSuite". It basically passes the string to the > *SSL library. The manual page makes a big explanation and tables of > ciphers, but the lists repeats basically how OpenSSL cipher strings work. > It would be better to scrap that and replace it with a link to > https://www.openssl.org/docs/man1.0.2/apps/ciphers.html, now that openssl > has nicer documentation) > > Along the gist of your proposal, I think I'll expand "SSLCipherSuite" to > take more than 1 argument and look for optional prefixes to the suite > strings giv
Re: TLSv1.3
Fashionably late to the party but I've built it on Windows and it works for me on FF Nightly. Thanks Stefan for getting tls1.3 in and working. Cheers On 4/4/2018 4:24 AM, Stefan Eissing wrote: Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps doing TLSv1.2 while the Nightly goes TLSv1.3. Perhaps a matter of the previous draft still used in the releases FF. Just FYI. Am 03.04.2018 um 17:09 schrieb Mario Brandt : Hi Stefan, On 3 April 2018 at 14:58, Stefan Eissing wrote: Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop. With FF open the about:config page Find security.tls.version.max set the value from 3 to 4 Cheers Mario
Re: TLSv1.3
Hi Stefan, Mario, LibreSSL will hopefully add TLSv1.3 to the next version (ca. 6 months). So I can't test with that just yet. Yes, it does work only with Firefox Nightly. :/ Google Chrome Beta doesn't negotiate 1.3 either. Using 1.1.1-pre4 at the moment. The security.tls.version.max in about:config doesn't help... Neither do the TLS settings in Chrome chrome://flags To enable, you MUST add +TLSv1.3 to SSLProtocols? Otherwise it seems I just get 1.2 I saw that 2.5.1-dev was tagged, is another release coming some time soon? Cheers, Bernard. 2018-04-03 14:58 GMT+02:00 Stefan Eissing : > Just added your patch for the latest libressl checks. Thanks! > > If I run that version against Firefox Nightly, it negotiates TLSv1.3. That > is with OpenSSL 1.1.1-pre3; I have no test env for libressl. > > Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop. > > Cheers, > > Stefan > >> Am 31.03.2018 um 22:42 schrieb Bernard Spil : >> >> I'm running an Apache 2.5.1 snapshot from 2018-03-30 linked against >> 1.1.1-pre3 from 2018-03-20 (AKA beta 1). >> >> If I connect to Apache with openssl 1.1.1 it makes a TLSv1.3 >> connection. Qualys SSLLabs doesn't see the TLSv1.3 at all. >> Additionally, Apache doesn't start when SSLOpenSSLConfCmd is used >> (SSLOpenSSLConfCmd groups secp521r1:secp384r1:x25519) >> Negotiated connections default to x25519 which is not what I expect. >> >> From another host: >> >> % /usr/local/bin/openssl version >> OpenSSL 1.1.1-pre3 (beta) 20 Mar 2018 >> >> % /usr/local/bin/openssl s_client -connect test.brnrd.eu:443 >> CONNECTED(0003) >> depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 >> verify return:1 >> depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 >> verify return:1 >> depth=0 CN = test.brnrd.eu >> verify return:1 >> >> --- >> No client certificate CA names sent >> Peer signing digest: SHA384 >> Peer signature type: ECDSA >> Server Temp Key: X25519, 253 bits >> --- >> SSL handshake has read 2696 bytes and written 390 bytes >> Verification: OK >> --- >> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 >> Server public key is 384 bit >> Secure Renegotiation IS NOT supported >> Compression: NONE >> Expansion: NONE >> No ALPN negotiated >> Early data was not sent >> SSL-Session: >>Protocol : TLSv1.3 >>Cipher: TLS_AES_256_GCM_SHA384 >>Session-ID: >>Session-ID-ctx: >>Master-Key: >>PSK identity: None >>PSK identity hint: None >>SRP username: None >>Start Time: 1522528505 >>Timeout : 7200 (sec) >>Verify return code: 0 (ok) >>Extended master secret: no >> --- >> >> Firefox Nightly and Chrome don't negotiate TLSv1.3 either >> Am I expecting things that I should not? (Entirely possible :D) >> >> Cheers, Bernard. >> >> >> >> 2018-03-29 16:11 GMT+02:00 Stefan Eissing : >>> Done in r1827992. >>> >>> Cheers, >>> Stefan >>> Am 29.03.2018 um 12:56 schrieb Greg Stein : On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing wrote: > ... That is the intention behind "SSLPolicy modern|intermediate|old" that configures the TLS stack according to the Mozilla server-side-tls recommendations. So, one does not have to mess with many directives to have a site with an "A" SSL Labs rating. Besides, except for data center setups, Apache will be used *only* with https: (and http: redirects to https:) very, very soon. That shifts the average expertise of an admin setting up a https: site. Back to TLSv1.3: I do not like to invent new config directives for a new TLS version either. The protocol on/off switch is now in "SSLProtocol" and that's where it should be. AFAIK, it's only the cipher list that needs special treatment (if one wants to override defaults or what SSLPolicy will do for it, once a recommendation is out). Gotcha. So, looking at "SSLCipherSuite". It basically passes the string to the *SSL library. The manual page makes a big explanation and tables of ciphers, but the lists repeats basically how OpenSSL cipher strings work. It would be better to scrap that and replace it with a link to https://www.openssl.org/docs/man1.0.2/apps/ciphers.html, now that openssl has nicer documentation) Along the gist of your proposal, I think I'll expand "SSLCipherSuite" to take more than 1 argument and look for optional prefixes to the suite strings given, so one could do Oooh! Yes. Looks great. +1 > ... Cheers, -g >>> >
Re: TLSv1.3
> Am 04.04.2018 um 20:23 schrieb William A Rowe Jr : > > SSLProtocol TLSv1.2 TLSv1.3 > SSLProxyProtocol TLSv1.2 TLSv1.3 > > should be syntactically valid, no? Not sure. Is > SSLProtocol TLSv1.2 TLSv1.1 valid? On the road right now and cannot test. I agree that it probably makes sense, but for backport compat I tried to add TLSv1.3 in the same spirit as the other protocols. > > [Wed Apr 04 18:21:11.465896 2018] [ssl:warn] [pid 2228052:tid > 140031042861312] AH02532: SSLProtocol: Protocol 'TLSv1.3' overrides > already set parameter(s). Check if a +/- prefix is missing. > [Wed Apr 04 18:21:11.465946 2018] [ssl:warn] [pid 2228052:tid > 140031042861312] AH02532: SSLProxyProtocol: Protocol 'TLSv1.3' > overrides already set parameter(s). Check if a +/- prefix is missing. > > TLSv1.3 should begin 'unset' if TLSv1.2 is given without modifiers. > > > On Wed, Mar 28, 2018 at 10:49 AM, Stefan Eissing > wrote: >> Just added TLSv1.3 support in trunk. No fancy new early data features, just >> the basic. >> >> Open for discussion: >> - The Mozilla server-side-tls people are still thinking of what they will >> recommend, see: >> >> https://github.com/mozilla/server-side-tls/issues/191#issuecomment-376918933 >> - Turns out, cipher suites are separate from <= TLSv1.2. Since servers will >> co-host 1.2 and 1.3 >> for some time, we need additional config directives, I think. Added >> "SSLCipherSuiteV1_3" and >> am ashamed of the name. >> - The current handling of TLS versions that are not supported by the *SSL >> lib linked is not >> super helpful. It more or less pretends that the version does not exist >> (unknown protocol), >> but that is far from the truth. Shall we continue that or is this an >> opportunity to reconsider? >> - Should we allow the configuration of TLSv1_3 ciphers, even if the linked >> SSL does not support >> it? This is different from SSLProtocol which of course needs to fail if it >> cannot enable the >> version that is explicitly configured. >> I think it is ok to take it into the config, even though it never >> activates. >> >> Cheers, >> >> Stefan >> >> PS. If a FreeBSD libressl+apache maintainer is listening here, he may try if >> trunk compiles with it. I would not stop him. >>
Re: TLSv1.3
SSLProtocol TLSv1.2 TLSv1.3 SSLProxyProtocol TLSv1.2 TLSv1.3 should be syntactically valid, no? [Wed Apr 04 18:21:11.465896 2018] [ssl:warn] [pid 2228052:tid 140031042861312] AH02532: SSLProtocol: Protocol 'TLSv1.3' overrides already set parameter(s). Check if a +/- prefix is missing. [Wed Apr 04 18:21:11.465946 2018] [ssl:warn] [pid 2228052:tid 140031042861312] AH02532: SSLProxyProtocol: Protocol 'TLSv1.3' overrides already set parameter(s). Check if a +/- prefix is missing. TLSv1.3 should begin 'unset' if TLSv1.2 is given without modifiers. On Wed, Mar 28, 2018 at 10:49 AM, Stefan Eissing wrote: > Just added TLSv1.3 support in trunk. No fancy new early data features, just > the basic. > > Open for discussion: > - The Mozilla server-side-tls people are still thinking of what they will > recommend, see: > > https://github.com/mozilla/server-side-tls/issues/191#issuecomment-376918933 > - Turns out, cipher suites are separate from <= TLSv1.2. Since servers will > co-host 1.2 and 1.3 >for some time, we need additional config directives, I think. Added > "SSLCipherSuiteV1_3" and >am ashamed of the name. > - The current handling of TLS versions that are not supported by the *SSL > lib linked is not >super helpful. It more or less pretends that the version does not exist > (unknown protocol), >but that is far from the truth. Shall we continue that or is this an > opportunity to reconsider? > - Should we allow the configuration of TLSv1_3 ciphers, even if the linked > SSL does not support >it? This is different from SSLProtocol which of course needs to fail if it > cannot enable the >version that is explicitly configured. >I think it is ok to take it into the config, even though it never > activates. > > Cheers, > > Stefan > > PS. If a FreeBSD libressl+apache maintainer is listening here, he may try if > trunk compiles with it. I would not stop him. >
Re: TLSv1.3
Not sure if you are aware of the converse of our favorite site; https://www.ssllabs.com/ssltest/viewMyClient.html On Wed, Apr 4, 2018 at 7:52 AM, Stefan Eissing wrote: > :) I have that running for HOURS already! > > Results were from 1.1.1-pre4 > >> Am 04.04.2018 um 14:46 schrieb Rainer Jung : >> >> I don't know whether it helps, but OpenSSL release pre4 (beta 2) yesterday. >> >> Regards, >> >> Rainer >> >> Am 04.04.2018 um 13:24 schrieb Stefan Eissing: >>> Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps >>> doing TLSv1.2 >>> while the Nightly goes TLSv1.3. Perhaps a matter of the previous draft >>> still used >>> in the releases FF. >>> Just FYI. Am 03.04.2018 um 17:09 schrieb Mario Brandt : Hi Stefan, On 3 April 2018 at 14:58, Stefan Eissing wrote: > Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop. With FF open the about:config page Find security.tls.version.max set the value from 3 to 4 Cheers Mario >
Re: TLSv1.3
:) I have that running for HOURS already! Results were from 1.1.1-pre4 > Am 04.04.2018 um 14:46 schrieb Rainer Jung : > > I don't know whether it helps, but OpenSSL release pre4 (beta 2) yesterday. > > Regards, > > Rainer > > Am 04.04.2018 um 13:24 schrieb Stefan Eissing: >> Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps doing >> TLSv1.2 >> while the Nightly goes TLSv1.3. Perhaps a matter of the previous draft still >> used >> in the releases FF. >> Just FYI. >>> Am 03.04.2018 um 17:09 schrieb Mario Brandt : >>> >>> Hi Stefan, >>> >>> On 3 April 2018 at 14:58, Stefan Eissing >>> wrote: Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop. >>> >>> With FF open the about:config page >>> >>> Find >>> security.tls.version.max >>> >>> set the value from 3 to 4 >>> >>> Cheers >>> Mario
Re: TLSv1.3
I don't know whether it helps, but OpenSSL release pre4 (beta 2) yesterday. Regards, Rainer Am 04.04.2018 um 13:24 schrieb Stefan Eissing: Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps doing TLSv1.2 while the Nightly goes TLSv1.3. Perhaps a matter of the previous draft still used in the releases FF. Just FYI. Am 03.04.2018 um 17:09 schrieb Mario Brandt : Hi Stefan, On 3 April 2018 at 14:58, Stefan Eissing wrote: Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop. With FF open the about:config page Find security.tls.version.max set the value from 3 to 4 Cheers Mario
Re: TLSv1.3
Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps doing TLSv1.2 while the Nightly goes TLSv1.3. Perhaps a matter of the previous draft still used in the releases FF. Just FYI. > Am 03.04.2018 um 17:09 schrieb Mario Brandt : > > Hi Stefan, > > On 3 April 2018 at 14:58, Stefan Eissing wrote: >> Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop. > > With FF open the about:config page > > Find > security.tls.version.max > > set the value from 3 to 4 > > Cheers > Mario
Re: TLSv1.3
Hi Stefan, On 3 April 2018 at 14:58, Stefan Eissing wrote: > Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop. With FF open the about:config page Find security.tls.version.max set the value from 3 to 4 Cheers Mario
Re: TLSv1.3
Just added your patch for the latest libressl checks. Thanks! If I run that version against Firefox Nightly, it negotiates TLSv1.3. That is with OpenSSL 1.1.1-pre3; I have no test env for libressl. Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop. Cheers, Stefan > Am 31.03.2018 um 22:42 schrieb Bernard Spil : > > I'm running an Apache 2.5.1 snapshot from 2018-03-30 linked against > 1.1.1-pre3 from 2018-03-20 (AKA beta 1). > > If I connect to Apache with openssl 1.1.1 it makes a TLSv1.3 > connection. Qualys SSLLabs doesn't see the TLSv1.3 at all. > Additionally, Apache doesn't start when SSLOpenSSLConfCmd is used > (SSLOpenSSLConfCmd groups secp521r1:secp384r1:x25519) > Negotiated connections default to x25519 which is not what I expect. > > From another host: > > % /usr/local/bin/openssl version > OpenSSL 1.1.1-pre3 (beta) 20 Mar 2018 > > % /usr/local/bin/openssl s_client -connect test.brnrd.eu:443 > CONNECTED(0003) > depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 > verify return:1 > depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 > verify return:1 > depth=0 CN = test.brnrd.eu > verify return:1 > > --- > No client certificate CA names sent > Peer signing digest: SHA384 > Peer signature type: ECDSA > Server Temp Key: X25519, 253 bits > --- > SSL handshake has read 2696 bytes and written 390 bytes > Verification: OK > --- > New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 > Server public key is 384 bit > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > Early data was not sent > SSL-Session: >Protocol : TLSv1.3 >Cipher: TLS_AES_256_GCM_SHA384 >Session-ID: >Session-ID-ctx: >Master-Key: >PSK identity: None >PSK identity hint: None >SRP username: None >Start Time: 1522528505 >Timeout : 7200 (sec) >Verify return code: 0 (ok) >Extended master secret: no > --- > > Firefox Nightly and Chrome don't negotiate TLSv1.3 either > Am I expecting things that I should not? (Entirely possible :D) > > Cheers, Bernard. > > > > 2018-03-29 16:11 GMT+02:00 Stefan Eissing : >> Done in r1827992. >> >> Cheers, >> Stefan >> >>> Am 29.03.2018 um 12:56 schrieb Greg Stein : >>> >>> On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing >>> wrote: ... >>> That is the intention behind "SSLPolicy modern|intermediate|old" that >>> configures the TLS stack according to the Mozilla server-side-tls >>> recommendations. So, one does not have to mess with many directives to have >>> a site with an "A" SSL Labs rating. >>> >>> Besides, except for data center setups, Apache will be used *only* with >>> https: (and http: redirects to https:) very, very soon. That shifts the >>> average expertise of an admin setting up a https: site. >>> >>> Back to TLSv1.3: >>> >>> I do not like to invent new config directives for a new TLS version either. >>> The protocol on/off switch is now in "SSLProtocol" and that's where it >>> should be. AFAIK, it's only the cipher list that needs special treatment >>> (if one wants to override defaults or what SSLPolicy will do for it, once a >>> recommendation is out). >>> >>> Gotcha. >>> >>> >>> So, looking at "SSLCipherSuite". It basically passes the string to the *SSL >>> library. The manual page makes a big explanation and tables of ciphers, but >>> the lists repeats basically how OpenSSL cipher strings work. It would be >>> better to scrap that and replace it with a link to >>> https://www.openssl.org/docs/man1.0.2/apps/ciphers.html, now that openssl >>> has nicer documentation) >>> >>> Along the gist of your proposal, I think I'll expand "SSLCipherSuite" to >>> take more than 1 argument and look for optional prefixes to the suite >>> strings given, so one could do >>> >>> Oooh! Yes. Looks great. >>> >>> +1 >>> ... >>> >>> Cheers, >>> -g >>> >>
Re: TLSv1.3
well well if its not BANNED USER Reindl harrold using a ghost account On Tue, Apr 3, 2018 at 5:02 AM, li...@rhsoft.net wrote: > > > no, it's just an opinion based on the Chrome will penalty non-https in > general (bseides: the ACME challenge is happy with a automatic rediect > to https even if it's a self-signed certificate) > > that opinion completly ignores setups where the load-balancer does >
Re: TLSv1.3
Am 02.04.2018 um 20:56 schrieb Helmut K. C. Tessarek: > On 2018-03-29 04:16, Stefan Eissing wrote: >> Besides, except for data center setups, Apache will be used *only* >> with https: (and http: redirects to https:) very, very soon. That >> shifts the average expertise of an admin setting up a https: site. > > This statement makes me a bit nervous. Are you saying that there won't > be a way to use Apache with http anymore? no, it's just an opinion based on the Chrome will penalty non-https in general (bseides: the ACME challenge is happy with a automatic rediect to https even if it's a self-signed certificate) that opinion completly ignores setups where the load-balancer does tls-offloading/caching and has a dediacted connection in a seperated network to the backend servers which are http-only forever the load-balancer can be http://trafficserver.apache.org/ as example which also does HTTP2-over-TLS for the client while the backend connection is also HTTP/1.1 forever - in that case mod_h2/mod_md are not part of the game and even mpm_prefork stays untouched
Re: TLSv1.3
Hello, On 2018-03-29 04:16, Stefan Eissing wrote: > Besides, except for data center setups, Apache will be used *only* > with https: (and http: redirects to https:) very, very soon. That > shifts the average expertise of an admin setting up a https: site. This statement makes me a bit nervous. Are you saying that there won't be a way to use Apache with http anymore? (Since I don't know what a data center setup entails that is - new directive, http only setup, ...) Also, the 'will be used' part is a bit puzzling. This part rather suggests that all users will magically only use https from that point forward. Or was it meant as "Apache will only use https anymore"? I'm basically using https anyway, however there are connections that *must* be plain http, e.g. the ACME challenge. I like to use my own scripts for maintaining the certificates thus I am not using the Apache module, which further means that I must have control over Apache's http setup. I'm doing something like this: ServerName HOSTNAME:80 Alias "/.well-known/acme-challenge/" "/COMMON_DIR/acme-challenge/.well-known/acme-challenge/" Require all granted RewriteEngine On RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/.* RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L,R=301] ServerName HOSTNAME:443 # Your "real" configuration here Can you please elaborate on your above statement and clear that up for me? Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: TLSv1.3
I'm running an Apache 2.5.1 snapshot from 2018-03-30 linked against 1.1.1-pre3 from 2018-03-20 (AKA beta 1). If I connect to Apache with openssl 1.1.1 it makes a TLSv1.3 connection. Qualys SSLLabs doesn't see the TLSv1.3 at all. Additionally, Apache doesn't start when SSLOpenSSLConfCmd is used (SSLOpenSSLConfCmd groups secp521r1:secp384r1:x25519) Negotiated connections default to x25519 which is not what I expect. >From another host: % /usr/local/bin/openssl version OpenSSL 1.1.1-pre3 (beta) 20 Mar 2018 % /usr/local/bin/openssl s_client -connect test.brnrd.eu:443 CONNECTED(0003) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = test.brnrd.eu verify return:1 --- No client certificate CA names sent Peer signing digest: SHA384 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 2696 bytes and written 390 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 384 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent SSL-Session: Protocol : TLSv1.3 Cipher: TLS_AES_256_GCM_SHA384 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1522528505 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- Firefox Nightly and Chrome don't negotiate TLSv1.3 either Am I expecting things that I should not? (Entirely possible :D) Cheers, Bernard. 2018-03-29 16:11 GMT+02:00 Stefan Eissing : > Done in r1827992. > > Cheers, > Stefan > >> Am 29.03.2018 um 12:56 schrieb Greg Stein : >> >> On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing >> wrote: >> >... >> That is the intention behind "SSLPolicy modern|intermediate|old" that >> configures the TLS stack according to the Mozilla server-side-tls >> recommendations. So, one does not have to mess with many directives to have >> a site with an "A" SSL Labs rating. >> >> Besides, except for data center setups, Apache will be used *only* with >> https: (and http: redirects to https:) very, very soon. That shifts the >> average expertise of an admin setting up a https: site. >> >> Back to TLSv1.3: >> >> I do not like to invent new config directives for a new TLS version either. >> The protocol on/off switch is now in "SSLProtocol" and that's where it >> should be. AFAIK, it's only the cipher list that needs special treatment (if >> one wants to override defaults or what SSLPolicy will do for it, once a >> recommendation is out). >> >> Gotcha. >> >> >> So, looking at "SSLCipherSuite". It basically passes the string to the *SSL >> library. The manual page makes a big explanation and tables of ciphers, but >> the lists repeats basically how OpenSSL cipher strings work. It would be >> better to scrap that and replace it with a link to >> https://www.openssl.org/docs/man1.0.2/apps/ciphers.html, now that openssl >> has nicer documentation) >> >> Along the gist of your proposal, I think I'll expand "SSLCipherSuite" to >> take more than 1 argument and look for optional prefixes to the suite >> strings given, so one could do >> >> Oooh! Yes. Looks great. >> >> +1 >> >> >... >> >> Cheers, >> -g >> >
Re: TLSv1.3
Hi Stefan, Submitted a PR with changes required to build with LibreSSL 2.6 and 2.7 https://bz.apache.org/bugzilla/show_bug.cgi?id=62236 Cheers, Bernard. 2018-03-31 10:34 GMT+02:00 Bernard Spil : > Hi Stefan, > > Sure I'm here :D Have been the maintainer of the LibreSSL ports in > FreeBSD for a good while and more recently joined the apache@ team. > > I'll let you know my results. I have an OpenSSL 1.1.1 port in the > making so I can test all of this long before it lands in a release. > > Cheers, Bernard. > > 2018-03-28 17:49 GMT+02:00 Stefan Eissing : >> Just added TLSv1.3 support in trunk. No fancy new early data features, just >> the basic. >> >> Open for discussion: >> - The Mozilla server-side-tls people are still thinking of what they will >> recommend, see: >> >> https://github.com/mozilla/server-side-tls/issues/191#issuecomment-376918933 >> - Turns out, cipher suites are separate from <= TLSv1.2. Since servers will >> co-host 1.2 and 1.3 >>for some time, we need additional config directives, I think. Added >> "SSLCipherSuiteV1_3" and >>am ashamed of the name. >> - The current handling of TLS versions that are not supported by the *SSL >> lib linked is not >>super helpful. It more or less pretends that the version does not exist >> (unknown protocol), >>but that is far from the truth. Shall we continue that or is this an >> opportunity to reconsider? >> - Should we allow the configuration of TLSv1_3 ciphers, even if the linked >> SSL does not support >>it? This is different from SSLProtocol which of course needs to fail if >> it cannot enable the >>version that is explicitly configured. >>I think it is ok to take it into the config, even though it never >> activates. >> >> Cheers, >> >> Stefan >> >> PS. If a FreeBSD libressl+apache maintainer is listening here, he may try if >> trunk compiles with it. I would not stop him. >>
Re: TLSv1.3
Hi Stefan, Sure I'm here :D Have been the maintainer of the LibreSSL ports in FreeBSD for a good while and more recently joined the apache@ team. I'll let you know my results. I have an OpenSSL 1.1.1 port in the making so I can test all of this long before it lands in a release. Cheers, Bernard. 2018-03-28 17:49 GMT+02:00 Stefan Eissing : > Just added TLSv1.3 support in trunk. No fancy new early data features, just > the basic. > > Open for discussion: > - The Mozilla server-side-tls people are still thinking of what they will > recommend, see: > > https://github.com/mozilla/server-side-tls/issues/191#issuecomment-376918933 > - Turns out, cipher suites are separate from <= TLSv1.2. Since servers will > co-host 1.2 and 1.3 >for some time, we need additional config directives, I think. Added > "SSLCipherSuiteV1_3" and >am ashamed of the name. > - The current handling of TLS versions that are not supported by the *SSL > lib linked is not >super helpful. It more or less pretends that the version does not exist > (unknown protocol), >but that is far from the truth. Shall we continue that or is this an > opportunity to reconsider? > - Should we allow the configuration of TLSv1_3 ciphers, even if the linked > SSL does not support >it? This is different from SSLProtocol which of course needs to fail if it > cannot enable the >version that is explicitly configured. >I think it is ok to take it into the config, even though it never > activates. > > Cheers, > > Stefan > > PS. If a FreeBSD libressl+apache maintainer is listening here, he may try if > trunk compiles with it. I would not stop him. >
Re: TLSv1.3
Not at my dev machine any more, but good point. May result in disabling it unless explicitly configured. Work in progress... > Am 29.03.2018 um 16:15 schrieb Eric Covener : > > If you have this setup handy, could you check what happens if you > negotiate TLS1.3 then request a directory that has per-directory SSL > settings in it? > > I assume it fails (renegotiation) but not sure how the logs will look. > That would be one big pitfall for flipping on tls1.3.
Re: TLSv1.3
Am 29.03.2018 um 16:15 schrieb Eric Covener: If you have this setup handy, could you check what happens if you negotiate TLS1.3 then request a directory that has per-directory SSL settings in it? I assume it fails (renegotiation) but not sure how the logs will look. That would be one big pitfall for flipping on tls1.3. I think the expert group discussed this typical reneg use case before removing reneg. It seems to me that this https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.6.2 is what we are instead expected to do in the case of client cert requirement for a sub directory. The server checks, whether the client supports the "post_handshake_auth" extension and if so, it can send later (after the handshake and probably also after handling some requests) a CertificateRequest request message (without reneg). To enforce stronger crypto after the handshake, maybe https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.6.3 is the way to go, I'm not sure. I also do't know, whether this is still a relevant use case for TLS 1.3, because it only uses 5 ciphers and changing the default cipher list currently seems to be not really expected. Regards, Rainer
Re: TLSv1.3
If you have this setup handy, could you check what happens if you negotiate TLS1.3 then request a directory that has per-directory SSL settings in it? I assume it fails (renegotiation) but not sure how the logs will look. That would be one big pitfall for flipping on tls1.3.
Re: TLSv1.3
Done in r1827992. Cheers, Stefan > Am 29.03.2018 um 12:56 schrieb Greg Stein : > > On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing > wrote: > >... > That is the intention behind "SSLPolicy modern|intermediate|old" that > configures the TLS stack according to the Mozilla server-side-tls > recommendations. So, one does not have to mess with many directives to have a > site with an "A" SSL Labs rating. > > Besides, except for data center setups, Apache will be used *only* with > https: (and http: redirects to https:) very, very soon. That shifts the > average expertise of an admin setting up a https: site. > > Back to TLSv1.3: > > I do not like to invent new config directives for a new TLS version either. > The protocol on/off switch is now in "SSLProtocol" and that's where it should > be. AFAIK, it's only the cipher list that needs special treatment (if one > wants to override defaults or what SSLPolicy will do for it, once a > recommendation is out). > > Gotcha. > > > So, looking at "SSLCipherSuite". It basically passes the string to the *SSL > library. The manual page makes a big explanation and tables of ciphers, but > the lists repeats basically how OpenSSL cipher strings work. It would be > better to scrap that and replace it with a link to > https://www.openssl.org/docs/man1.0.2/apps/ciphers.html, now that openssl has > nicer documentation) > > Along the gist of your proposal, I think I'll expand "SSLCipherSuite" to take > more than 1 argument and look for optional prefixes to the suite strings > given, so one could do > > Oooh! Yes. Looks great. > > +1 > > >... > > Cheers, > -g >
Re: TLSv1.3
On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing < stefan.eiss...@greenbytes.de> wrote: >... > That is the intention behind "SSLPolicy modern|intermediate|old" that > configures the TLS stack according to the Mozilla server-side-tls > recommendations. So, one does not have to mess with many directives to have > a site with an "A" SSL Labs rating. > > Besides, except for data center setups, Apache will be used *only* with > https: (and http: redirects to https:) very, very soon. That shifts the > average expertise of an admin setting up a https: site. > > Back to TLSv1.3: > > I do not like to invent new config directives for a new TLS version > either. The protocol on/off switch is now in "SSLProtocol" and that's where > it should be. AFAIK, it's only the cipher list that needs special treatment > (if one wants to override defaults or what SSLPolicy will do for it, once a > recommendation is out). > Gotcha. > > So, looking at "SSLCipherSuite". It basically passes the string to the > *SSL library. The manual page makes a big explanation and tables of > ciphers, but the lists repeats basically how OpenSSL cipher strings work. > It would be better to scrap that and replace it with a link to > https://www.openssl.org/docs/man1.0.2/apps/ciphers.html, now that openssl > has nicer documentation) > > Along the gist of your proposal, I think I'll expand "SSLCipherSuite" to > take more than 1 argument and look for optional prefixes to the suite > strings given, so one could do > Oooh! Yes. Looks great. +1 >... Cheers, -g
Re: TLSv1.3
Am 29.03.2018 um 11:41 schrieb Yann Ylavic: > On Thu, Mar 29, 2018 at 11:39 AM, Yann Ylavic wrote: >> On Thu, Mar 29, 2018 at 10:16 AM, Stefan Eissing >> wrote: >>> >>> Along the gist of your proposal, I think I'll expand "SSLCipherSuite" >>> to take more than 1 argument and look for optional prefixes to the >>> suite strings given, so one could do >>> >>> # as before, applies to all TLS protocols <=TLSv1.2 SSLCipherSuite >>> XXX:YY:-AASSD:DSDS >>> >>> # Set ciphers for TLSv1.3, does not replace the previous line >>> SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 >>> >>> So, the directive becomes: >>> >>> SSLCipherSuite [ ProtocolClass ] Cipher-String >>> >>> where ProtocolClass is: >>> SSL (default) all TLS/SSL Protocols <= TLSv1.2 >>> TLSv1.3 TLS version 1.3 >> >> Looks good to me. >> I wonder if it's not applicable to TLSv1.2 already, there is a number >> of ciphers available to 1.2 only (with openssl < 1.1). > > (e.g. GCMs, CHACHA+POLYs, SHA-2s ...) FWIW: 30 minutes before the start of this thread i got this copy&paste per jabber - so it's an openssl issue at all that ghey just don't parse out the TLS1.3 related ones from SSLCipherSuite and so that is a completly new bahvior breaking the sort of abstraction that i shouldn't know about TLS 1.0/1.1/1.2/1.3 at all in consumer code __ upgrading to next openssl-1.1.1 could break your prod if you're using a forced cipher list because handshake will fail regardless the tls protocol version if you don't specify a cipher valid for TLSv1.3 in your cipher list. https://github.com/openssl/openssl/issues/5057 https://github.com/openssl/openssl/issues/5065 Openssl's team doesn't seem to consider this as an issue FYI OpenSSL did a 180 on this, they are implemented a new API call to set TLSv1.3 ciphers and enable them by default: https://github.com/mattcaswell/openssl/commit/d93e832a82087a5f9bcf7d93ed7ae21bc6c1fed0 https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_ciphersuites.html Split configuration of TLSv1.3 ciphers from older ciphers With the current mechanism, old cipher strings that used to work in 1.1.0, may inadvertently disable all TLSv1.3 ciphersuites causing connections to fail. This is confusing for users. In reality TLSv1.3 are quite different to older ciphers. They are much simpler and there are only a small number of them so, arguably, they don't need the same level of control that the older ciphers have. This change splits the configuration of TLSv1.3 ciphers from older ones. By default the TLSv1.3 ciphers are on, so you cannot inadvertently disable them through your existing config. Fixes #5359
Re: TLSv1.3
On Thu, Mar 29, 2018 at 11:39 AM, Yann Ylavic wrote: > On Thu, Mar 29, 2018 at 10:16 AM, Stefan Eissing > wrote: >> >> Along the gist of your proposal, I think I'll expand "SSLCipherSuite" >> to take more than 1 argument and look for optional prefixes to the >> suite strings given, so one could do >> >> # as before, applies to all TLS protocols <=TLSv1.2 SSLCipherSuite >> XXX:YY:-AASSD:DSDS >> >> # Set ciphers for TLSv1.3, does not replace the previous line >> SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 >> >> So, the directive becomes: >> >> SSLCipherSuite [ ProtocolClass ] Cipher-String >> >> where ProtocolClass is: >> SSL (default) all TLS/SSL Protocols <= TLSv1.2 >> TLSv1.3 TLS version 1.3 > > Looks good to me. > I wonder if it's not applicable to TLSv1.2 already, there is a number > of ciphers available to 1.2 only (with openssl < 1.1). (e.g. GCMs, CHACHA+POLYs, SHA-2s ...) > > Thanks, > Yann.
Re: TLSv1.3
On Thu, Mar 29, 2018 at 10:16 AM, Stefan Eissing wrote: > > Along the gist of your proposal, I think I'll expand "SSLCipherSuite" > to take more than 1 argument and look for optional prefixes to the > suite strings given, so one could do > > # as before, applies to all TLS protocols <=TLSv1.2 SSLCipherSuite > XXX:YY:-AASSD:DSDS > > # Set ciphers for TLSv1.3, does not replace the previous line > SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 > > So, the directive becomes: > > SSLCipherSuite [ ProtocolClass ] Cipher-String > > where ProtocolClass is: > SSL (default) all TLS/SSL Protocols <= TLSv1.2 > TLSv1.3 TLS version 1.3 Looks good to me. I wonder if it's not applicable to TLSv1.2 already, there is a number of ciphers available to 1.2 only (with openssl < 1.1). Thanks, Yann.
Re: TLSv1.3
> Am 29.03.2018 um 06:21 schrieb Greg Stein : > > On Wed, Mar 28, 2018 at 10:49 AM, Stefan Eissing > wrote: > Just added TLSv1.3 support in trunk. No fancy new early data features, just > the basic. > > Open for discussion: > - The Mozilla server-side-tls people are still thinking of what they will > recommend, see: > > https://github.com/mozilla/server-side-tls/issues/191#issuecomment-376918933 > - Turns out, cipher suites are separate from <= TLSv1.2. Since servers will > co-host 1.2 and 1.3 >for some time, we need additional config directives, I think. Added > "SSLCipherSuiteV1_3" and >am ashamed of the name. > > Why not something simple like: > > TLSVersion 1.3 > > and have that impute a specific set of ciphers? Get's away from the old "SSL" > name, and moves us to a directive that can accept version into the future > (instead of a new directive every time). > > And if you want to *refine* the behavior, then do it with new TLS* > directives. I've always had a problem with setting up TLS servers because of > the huge number of directives. It would be nice to just introduce a new, > simple directive that produces "all" the default handling for the majority of > users. That is the intention behind "SSLPolicy modern|intermediate|old" that configures the TLS stack according to the Mozilla server-side-tls recommendations. So, one does not have to mess with many directives to have a site with an "A" SSL Labs rating. Besides, except for data center setups, Apache will be used *only* with https: (and http: redirects to https:) very, very soon. That shifts the average expertise of an admin setting up a https: site. Back to TLSv1.3: I do not like to invent new config directives for a new TLS version either. The protocol on/off switch is now in "SSLProtocol" and that's where it should be. AFAIK, it's only the cipher list that needs special treatment (if one wants to override defaults or what SSLPolicy will do for it, once a recommendation is out). So, looking at "SSLCipherSuite". It basically passes the string to the *SSL library. The manual page makes a big explanation and tables of ciphers, but the lists repeats basically how OpenSSL cipher strings work. It would be better to scrap that and replace it with a link to https://www.openssl.org/docs/man1.0.2/apps/ciphers.html, now that openssl has nicer documentation) Along the gist of your proposal, I think I'll expand "SSLCipherSuite" to take more than 1 argument and look for optional prefixes to the suite strings given, so one could do # as before, applies to all TLS protocols <=TLSv1.2 SSLCipherSuite XXX:YY:-AASSD:DSDS # Set ciphers for TLSv1.3, does not replace the previous line SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 So, the directive becomes: SSLCipherSuite [ ProtocolClass ] Cipher-String where ProtocolClass is: SSL (default) all TLS/SSL Protocols <= TLSv1.2 TLSv1.3 TLS version 1.3 That would mean we have no new directives. > - The current handling of TLS versions that are not supported by the *SSL > lib linked is not >super helpful. It more or less pretends that the version does not exist > (unknown protocol), >but that is far from the truth. Shall we continue that or is this an > opportunity to reconsider? > > Euh, if the underlying libraries cannot support a new TLS version, *and* > httpd hasn't been coded to support that version, then yes: it should fail. > Both parts are needed. > > Did I misunderstand your query? > > - Should we allow the configuration of TLSv1_3 ciphers, even if the linked > SSL does not support >it? This is different from SSLProtocol which of course needs to fail if it > cannot enable the >version that is explicitly configured. >I think it is ok to take it into the config, even though it never > activates. > > Oh no no. If I want to configure "SuperAwesomeGJSCipher", and that isn't > available like I *expect* it to be ... then yeah. "Cipher not available. You > won't get the security you're seeking." #FAIL > > Cheers, > -g >
Re: TLSv1.3
On Wed, Mar 28, 2018 at 10:49 AM, Stefan Eissing < stefan.eiss...@greenbytes.de> wrote: > Just added TLSv1.3 support in trunk. No fancy new early data features, > just the basic. > > Open for discussion: > - The Mozilla server-side-tls people are still thinking of what they will > recommend, see: >https://github.com/mozilla/server-side-tls/issues/191# > issuecomment-376918933 > - Turns out, cipher suites are separate from <= TLSv1.2. Since servers > will co-host 1.2 and 1.3 >for some time, we need additional config directives, I think. Added > "SSLCipherSuiteV1_3" and >am ashamed of the name. > Why not something simple like: TLSVersion 1.3 and have that impute a specific set of ciphers? Get's away from the old "SSL" name, and moves us to a directive that can accept version into the future (instead of a new directive every time). And if you want to *refine* the behavior, then do it with new TLS* directives. I've always had a problem with setting up TLS servers because of the huge number of directives. It would be nice to just introduce a new, simple directive that produces "all" the default handling for the majority of users. > - The current handling of TLS versions that are not supported by the *SSL > lib linked is not >super helpful. It more or less pretends that the version does not exist > (unknown protocol), >but that is far from the truth. Shall we continue that or is this an > opportunity to reconsider? > Euh, if the underlying libraries cannot support a new TLS version, *and* httpd hasn't been coded to support that version, then yes: it should fail. Both parts are needed. Did I misunderstand your query? > - Should we allow the configuration of TLSv1_3 ciphers, even if the > linked SSL does not support >it? This is different from SSLProtocol which of course needs to fail if > it cannot enable the >version that is explicitly configured. >I think it is ok to take it into the config, even though it never > activates. > Oh no no. If I want to configure "SuperAwesomeGJSCipher", and that isn't available like I *expect* it to be ... then yeah. "Cipher not available. You won't get the security you're seeking." #FAIL Cheers, -g