Re: potential TLSv1.3 rproxy issue with openssl 1.1.1 and httpd 2.4.37?

[Mario Colindres]

I have a wellness completion benefit package that works good and a budget
component that I have registered for and The SSL must remain pure.
Assignments have been compiled and are relevant to the assistance progs;
Top priority LifeSpan preserved with occupational legitimate safework load
environments.

On Thu, Nov 1, 2018, 5:42 PM .  wrote:

> Hey everyone,
>
>I have an apache http server (version 2.4.37) that is using SSL
> (version 1.1.1) to communicate to an F5 back-end through mod_proxy and
> mod_proxy_http.
>
>The server is configured with a SSLProxyProtocol string that allows for
> TLSv1.3, and I am seeing an error that looks like the following:
>
> [Thu Nov 01 20:00:27.687919 2018] [ssl:info] [pid 86604:tid
> 47699324180224] [remote PRIVATEIPREDACTED:443] AH01964: Connection to child
> 0 established (server PRIVATEDNSNAMEREDACTED:443)
>
> [Thu Nov 01 20:00:27.687937 2018] [ssl:trace2] [pid 86604:tid
> 47699324180224] ssl_engine_rand.c(126): Proxy: Seeding PRNG with 144 bytes
> of entropy
>
> [Thu Nov 01 20:00:27.687999 2018] [ssl:trace4] [pid 86604:tid
> 47699324180224] ssl_engine_io.c(1667): [remote PRIVATEIPREDACTED:443]
> coalesce: have 0 bytes, adding 675 more
>
> [Thu Nov 01 20:00:27.688005 2018] [ssl:trace4] [pid 86604:tid
> 47699324180224] ssl_engine_io.c(1727): [remote PRIVATEIPREDACTED:443]
> coalesce: passing on 675 bytes
>
> [Thu Nov 01 20:00:27.688009 2018] [ssl:trace3] [pid 86604:tid
> 47699324180224] ssl_engine_io.c(1239): [remote PRIVATEIPREDACTED:443] SNI
> extension for SSL Proxy request set to 'PRIVATEDNSNAMEREDACTED'
>
> [Thu Nov 01 20:00:27.688014 2018] [ssl:trace3] [pid 86604:tid
> 47699324180224] ssl_engine_kernel.c(2191): [remote PRIVATEIPREDACTED:443]
> OpenSSL: Handshake: start
>
> [Thu Nov 01 20:00:27.688043 2018] [ssl:trace3] [pid 86604:tid
> 47699324180224] ssl_engine_kernel.c(2200): [remote PRIVATEIPREDACTED:443]
> OpenSSL: Loop: before SSL initialization
>
> [Thu Nov 01 20:00:27.688293 2018] [ssl:trace4] [pid 86604:tid
> 47699324180224] ssl_engine_io.c(2220): [remote PRIVATEIPREDACTED:443]
> OpenSSL: write 7/7 bytes to BIO#2b61fc008b80 [mem: 2b61fc027750] (BIO dump
> follows)
>
> [Thu Nov 01 20:00:27.688299 2018] [ssl:trace7] [pid 86604:tid
> 47699324180224] ssl_engine_io.c(2143): [remote PRIVATEIPREDACTED:443]
> +-+
>
> [Thu Nov 01 20:00:27.688302 2018] [ssl:trace7] [pid 86604:tid
> 47699324180224] ssl_engine_io.c(2181): [remote PRIVATEIPREDACTED:443] |
> : 15 03 01 00 02 02 50 ..P  |
>
> [Thu Nov 01 20:00:27.688304 2018] [ssl:trace7] [pid 86604:tid
> 47699324180224] ssl_engine_io.c(2187): [remote PRIVATEIPREDACTED:443]
> +-+
>
> [Thu Nov 01 20:00:27.688307 2018] [ssl:trace3] [pid 86604:tid
> 47699324180224] ssl_engine_kernel.c(22PRIVATEIPREDACTED[remote
> PRIVATEIPREDACTED:443] OpenSSL: Write: error
>
> [Thu Nov 01 20:00:27.688311 2018] [ssl:trace3] [pid 86604:tid
> 47699324180224] ssl_engine_kernel.c(2229): [remote PRIVATEIPREDACTED:443]
> OpenSSL: Exit: error in error
>
> [Thu Nov 01 20:00:27.688313 2018] [ssl:info] [pid 86604:tid
> 47699324180224] [remote PRIVATEIPREDACTED:443] AH02003: SSL Proxy connect
> failed
>
> [Thu Nov 01 20:00:27.688335 2018] [ssl:info] [pid 86604:tid
> 47699324180224] SSL Library Error: error:14228044:SSL
> routines:construct_ca_names:internal error
>
> [Thu Nov 01 20:00:27.688338 2018] [ssl:info] [pid 86604:tid
> 47699324180224] [remote PRIVATEIPREDACTED:443] AH01998: Connection closed
> to child 0 with abortive shutdown (server PRIVATEDNSNAMEREDACTED:443)
>
> [Thu Nov 01 20:00:27.688353 2018] [ssl:info] [pid 86604:tid
> 47699324180224] [remote PRIVATEIPREDACTED:443] AH01997: SSL handshake
> failed: sending 502
>
> [Thu Nov 01 20:00:27.688366 2018] [proxy_http:error] [pid 86604:tid
> 47699324180224] (PRIVATEIPREDACTED software caused connection abort:
> [client PRIVATEIPREDACTED:60171] AH01PRIVATEIPREDACTED error reading status
> line from remote server PRIVATEDNSNAMEREDACTED:443
>
>This is causing the back-end connection to fail.
>
>Narrowing the scope of the SSLProxyProtocol string to not allow for TLS
> 1.3 relieves the issue and allows proper communication to occur.
>
>Can anyone else confirm the issue?  If so, is there a bug report yet or
> would you like me to make one?
>
>If this is an issue with the release, I would mention that we also saw
> a different issue we had to patch ourselves with the apache http server
> proxy protocol SSL code between the releases of 2.4.29 and 2.4.33 (there
> were security fixes in this release so not upgrading wasn't a great
> option), perhaps there could be some additional automated testing for the
> use case of an SSL enabled proxy?  Unless of course we find I am doing
> something stupid at which point disregard that suggestion.
>
> Thanks,
> Dan Oliver
>

potential TLSv1.3 rproxy issue with openssl 1.1.1 and httpd 2.4.37?

[.]

Hey everyone,

   I have an apache http server (version 2.4.37) that is using SSL (version
1.1.1) to communicate to an F5 back-end through mod_proxy and
mod_proxy_http.

   The server is configured with a SSLProxyProtocol string that allows for
TLSv1.3, and I am seeing an error that looks like the following:

[Thu Nov 01 20:00:27.687919 2018] [ssl:info] [pid 86604:tid 47699324180224]
[remote PRIVATEIPREDACTED:443] AH01964: Connection to child 0 established
(server PRIVATEDNSNAMEREDACTED:443)

[Thu Nov 01 20:00:27.687937 2018] [ssl:trace2] [pid 86604:tid
47699324180224] ssl_engine_rand.c(126): Proxy: Seeding PRNG with 144 bytes
of entropy

[Thu Nov 01 20:00:27.687999 2018] [ssl:trace4] [pid 86604:tid
47699324180224] ssl_engine_io.c(1667): [remote PRIVATEIPREDACTED:443]
coalesce: have 0 bytes, adding 675 more

[Thu Nov 01 20:00:27.688005 2018] [ssl:trace4] [pid 86604:tid
47699324180224] ssl_engine_io.c(1727): [remote PRIVATEIPREDACTED:443]
coalesce: passing on 675 bytes

[Thu Nov 01 20:00:27.688009 2018] [ssl:trace3] [pid 86604:tid
47699324180224] ssl_engine_io.c(1239): [remote PRIVATEIPREDACTED:443] SNI
extension for SSL Proxy request set to 'PRIVATEDNSNAMEREDACTED'

[Thu Nov 01 20:00:27.688014 2018] [ssl:trace3] [pid 86604:tid
47699324180224] ssl_engine_kernel.c(2191): [remote PRIVATEIPREDACTED:443]
OpenSSL: Handshake: start

[Thu Nov 01 20:00:27.688043 2018] [ssl:trace3] [pid 86604:tid
47699324180224] ssl_engine_kernel.c(2200): [remote PRIVATEIPREDACTED:443]
OpenSSL: Loop: before SSL initialization

[Thu Nov 01 20:00:27.688293 2018] [ssl:trace4] [pid 86604:tid
47699324180224] ssl_engine_io.c(2220): [remote PRIVATEIPREDACTED:443]
OpenSSL: write 7/7 bytes to BIO#2b61fc008b80 [mem: 2b61fc027750] (BIO dump
follows)

[Thu Nov 01 20:00:27.688299 2018] [ssl:trace7] [pid 86604:tid
47699324180224] ssl_engine_io.c(2143): [remote PRIVATEIPREDACTED:443]
+-+

[Thu Nov 01 20:00:27.688302 2018] [ssl:trace7] [pid 86604:tid
47699324180224] ssl_engine_io.c(2181): [remote PRIVATEIPREDACTED:443] |
: 15 03 01 00 02 02 50 ..P  |

[Thu Nov 01 20:00:27.688304 2018] [ssl:trace7] [pid 86604:tid
47699324180224] ssl_engine_io.c(2187): [remote PRIVATEIPREDACTED:443]
+-+

[Thu Nov 01 20:00:27.688307 2018] [ssl:trace3] [pid 86604:tid
47699324180224] ssl_engine_kernel.c(22PRIVATEIPREDACTED[remote
PRIVATEIPREDACTED:443] OpenSSL: Write: error

[Thu Nov 01 20:00:27.688311 2018] [ssl:trace3] [pid 86604:tid
47699324180224] ssl_engine_kernel.c(2229): [remote PRIVATEIPREDACTED:443]
OpenSSL: Exit: error in error

[Thu Nov 01 20:00:27.688313 2018] [ssl:info] [pid 86604:tid 47699324180224]
[remote PRIVATEIPREDACTED:443] AH02003: SSL Proxy connect failed

[Thu Nov 01 20:00:27.688335 2018] [ssl:info] [pid 86604:tid 47699324180224]
SSL Library Error: error:14228044:SSL routines:construct_ca_names:internal
error

[Thu Nov 01 20:00:27.688338 2018] [ssl:info] [pid 86604:tid 47699324180224]
[remote PRIVATEIPREDACTED:443] AH01998: Connection closed to child 0 with
abortive shutdown (server PRIVATEDNSNAMEREDACTED:443)

[Thu Nov 01 20:00:27.688353 2018] [ssl:info] [pid 86604:tid 47699324180224]
[remote PRIVATEIPREDACTED:443] AH01997: SSL handshake failed: sending 502

[Thu Nov 01 20:00:27.688366 2018] [proxy_http:error] [pid 86604:tid
47699324180224] (PRIVATEIPREDACTED software caused connection abort:
[client PRIVATEIPREDACTED:60171] AH01PRIVATEIPREDACTED error reading status
line from remote server PRIVATEDNSNAMEREDACTED:443

   This is causing the back-end connection to fail.

   Narrowing the scope of the SSLProxyProtocol string to not allow for TLS
1.3 relieves the issue and allows proper communication to occur.

   Can anyone else confirm the issue?  If so, is there a bug report yet or
would you like me to make one?

   If this is an issue with the release, I would mention that we also saw a
different issue we had to patch ourselves with the apache http server proxy
protocol SSL code between the releases of 2.4.29 and 2.4.33 (there were
security fixes in this release so not upgrading wasn't a great option),
perhaps there could be some additional automated testing for the use case
of an SSL enabled proxy?  Unless of course we find I am doing something
stupid at which point disregard that suggestion.

Thanks,
Dan Oliver

Re: TLSv1.3 supprt for 2.4.x?

[Dennis Radford]

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?

[Dennis Radford]

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?

[Dennis Radford]

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?

[Dennis Radford]

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?

[Stefan Eissing]

> Am 18.09.2018 um 17:03 schrieb Joe Orton :
> 
>> On Tue, Sep 18, 2018 at 04:54:58PM +0200, Yann Ylavic wrote:
>>> On Tue, Sep 18, 2018 at 4:08 PM Joe Orton  wrote:
>>> 
>>> As of r1841219 I think the tlsv1.3-for-2.4.x is ready for merging...
>> 
>> Thanks Joe for the hard work!
> 
> Thanks to Stefan for getting us most of the way!
> 

I did the easy parts. You pulled this through. Thanks!

>> Does it work for mod_proxy auth with a httpd backend, both in TLS 1.3?
>> I wonder because PHA isn't enabled on mod_proxy either, IIUC.
>> Will test but possibly you did it already.
> 
> I thinkso but I will double-check it is being tested under TLSv1.3, I 
> added this for that case specifically, IIRC because I was seeing test 
> failures without it:
> 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?view=markup=1840710#l1561
> 
> Regards, Joe

Re: TLSv1.3 supprt for 2.4.x?

[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!

> Does it work for mod_proxy auth with a httpd backend, both in TLS 1.3?
> I wonder because PHA isn't enabled on mod_proxy either, IIUC.
> Will test but possibly you did it already.

I think so but I will double-check it is being tested under TLSv1.3, I 
added this for that case specifically, IIRC because I was seeing test 
failures without it:

http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?view=markup=1840710#l1561

Regards, Joe

Re: TLSv1.3 supprt for 2.4.x?

[Yann Ylavic]

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?

[Joe Orton]

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?

[Yann Ylavic]

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?

[Joe Orton]

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?

[Joe Orton]

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?

[Yann Ylavic]

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?

[Joe Orton]

On Tue, Sep 11, 2018 at 10:42:02AM +0200, Stefan Eissing wrote:
> > Am 10.09.2018 um 10:59 schrieb Joe Orton :
> > http://svn.apache.org/viewvc?view=revision=1828220
> > - I think this is merged in the branch slightly differently?
> 
> I think this overlaps with a subsequent change of SSL_HAVE_PROTOCOL_TLSV1_3 
> vs. SSL_OP_NO_TLSv1_3? Feel free to fix this as you think it's best.

Probably just need to mark it merged, ignore this for now.

> > http://svn.apache.org/viewvc?view=revision=1828790
> > http://svn.apache.org/viewvc?view=revision=1828791
> > http://svn.apache.org/viewvc?view=revision=1828792
> > - I think these should be merged too?
> 
> Just done. Thanks!

Thanks a lot.  

Does anybody have successful test results with post-handshake auth?  I'm 
testing against Fedora's OpenSSL 1.1.1pre9 which has merged the changes 
for https://github.com/openssl/openssl/issues/6933

I'm not able to get a successful PHA exchange, even with a client which 
explicitly enables PHA.  It seems like the test suite will be broken 
until the Perl stack is patched to enable PHA somehow, which is a 
massive headache AFAICT.

Without the SSL_peek(ssl, peekbuf, 0) after SSL_do_handshake(), OpenSSL 
is sending the CertificateRequest to the client but doesn't wait to read 
the response.  With the SSL_peek() call I think it successfully 
completes the "handshake" (and gets the cert) but then hangs waiting for 
app_data which is never coming, and eventually times out.  Anybody got 
better results?

Regards, Joe

Re: TLSv1.3 supprt for 2.4.x?

[Stefan Eissing]

> Am 10.09.2018 um 10:59 schrieb Joe Orton :
> 
> On Wed, Sep 05, 2018 at 01:36:06PM +0200, Stefan Eissing wrote:
>> A member of the OpenSSL project gave me a "go ahead" and we now have branch: 
>> 
>> https://svn.apache.org/repos/asf/httpd/httpd/branches/tlsv1.3-for-2.4.x
>> 
>> as a copy of 2.4.x with 
>> 1827912,1827924,1827992,1828222,1828720,1828723,1833588,1833589,1839920,1839946
>>  merged in. If was not a clean merge as some feature from trunk are not 
>> present in 2.4.x, so peer review/test is definitely desired.
> 
> Awesome, thank you Stefan!
> 
> Comparing to what I produced for Fedora, I had a few extra revisions 
> backported (and also missed some of the later ones you caught):
> 
> http://svn.apache.org/viewvc?view=revision=1828220
> - I think this is merged in the branch slightly differently?

I think this overlaps with a subsequent change of SSL_HAVE_PROTOCOL_TLSV1_3 vs. 
SSL_OP_NO_TLSv1_3? Feel free to fix this as you think it's best.

> http://svn.apache.org/viewvc?view=revision=1828790
> http://svn.apache.org/viewvc?view=revision=1828791
> http://svn.apache.org/viewvc?view=revision=1828792
> - I think these should be merged too?

Just done. Thanks!

> 
> I will do some testing now.
> 
> Regards, Joe

Re: TLSv1.3 supprt for 2.4.x?

[Joe Orton]

On Wed, Sep 05, 2018 at 01:36:06PM +0200, Stefan Eissing wrote:
> A member of the OpenSSL project gave me a "go ahead" and we now have branch: 
> 
> https://svn.apache.org/repos/asf/httpd/httpd/branches/tlsv1.3-for-2.4.x
> 
> as a copy of 2.4.x with 
> 1827912,1827924,1827992,1828222,1828720,1828723,1833588,1833589,1839920,1839946
>  merged in. If was not a clean merge as some feature from trunk are not 
> present in 2.4.x, so peer review/test is definitely desired.

Awesome, thank you Stefan!

Comparing to what I produced for Fedora, I had a few extra revisions 
backported (and also missed some of the later ones you caught):

http://svn.apache.org/viewvc?view=revision=1828220
- I think this is merged in the branch slightly differently?

http://svn.apache.org/viewvc?view=revision=1828790
http://svn.apache.org/viewvc?view=revision=1828791
http://svn.apache.org/viewvc?view=revision=1828792
- I think these should be merged too?

I will do some testing now.

Regards, Joe

Re: TLSv1.3 supprt for 2.4.x?

[William A Rowe Jr]

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?

[Stefan Eissing]

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

[Bernard Spil]

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?

[Bernard Spil]

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?

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

[Dennis Clarke]

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?

[Dennis Clarke]

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?

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

[Rainer Jung]

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?

[Stefan Eissing]

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

[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

Regards

Rüdiger

Re: TLSv1.3 supprt for 2.4.x?

[Stefan Eissing]

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?

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

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

> 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

TLSv1.3 supprt for 2.4.x?

[Stefan Eissing]

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

[Bernard Spil]

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 <wr...@rowe-clan.net>:
> On Sun, Apr 8, 2018 at 11:37 AM, Bernard Spil <br...@freebsd.org> 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

[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

[Stefan Eissing]

> Am 08.04.2018 um 18:37 schrieb Bernard Spil <br...@freebsd.org>:
> 
> 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 <stefan.eiss...@greenbytes.de>:
>> 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 <br...@freebsd.org>:
>>> 
>>> 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 <stefan.eiss...@greenbytes.de>:
>>>> Done in r1827992.
>>>> 
>>>> Cheers,
>>>> Stefan
>>>> 
>>>>> Am 29.03.2018 um 12:56 schrieb Greg Stein <gst...@gmail.com>:
>>>>> 
>>>>> 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 
>>

Re: TLSv1.3

[Gregg Smith]

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 <jbl...@gmail.com>:

Hi Stefan,

On 3 April 2018 at 14:58, Stefan Eissing <stefan.eiss...@greenbytes.de> 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

[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

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 <stefan.eiss...@greenbytes.de>:
> 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 <br...@freebsd.org>:
>>
>> 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 <stefan.eiss...@greenbytes.de>:
>>> Done in r1827992.
>>>
>>> Cheers,
>>> Stefan
>>>
>>>> Am 29.03.2018 um 12:56 schrieb Greg Stein <gst...@gmail.com>:
>>>>
>>>> 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

[Stefan Eissing]

> Am 04.04.2018 um 20:23 schrieb William A Rowe Jr <wr...@rowe-clan.net>:
> 
> 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
> <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.
>> - 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

[William A Rowe Jr]

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

[William A Rowe Jr]

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
<stefan.eiss...@greenbytes.de> 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 <rainer.j...@kippdata.de>:
>>
>> 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 <jbl...@gmail.com>:
>>>>
>>>> Hi Stefan,
>>>>
>>>> On 3 April 2018 at 14:58, Stefan Eissing <stefan.eiss...@greenbytes.de> 
>>>> 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

[Stefan Eissing]

:) I have that running for HOURS already!

Results were from 1.1.1-pre4

> Am 04.04.2018 um 14:46 schrieb Rainer Jung <rainer.j...@kippdata.de>:
> 
> 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 <jbl...@gmail.com>:
>>> 
>>> Hi Stefan,
>>> 
>>> On 3 April 2018 at 14:58, Stefan Eissing <stefan.eiss...@greenbytes.de> 
>>> 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

[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 <jbl...@gmail.com>:

Hi Stefan,

On 3 April 2018 at 14:58, Stefan Eissing <stefan.eiss...@greenbytes.de> 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

[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 <jbl...@gmail.com>:
> 
> Hi Stefan,
> 
> On 3 April 2018 at 14:58, Stefan Eissing <stefan.eiss...@greenbytes.de> 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

[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

[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 <br...@freebsd.org>:
> 
> 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 <stefan.eiss...@greenbytes.de>:
>> Done in r1827992.
>> 
>> Cheers,
>> Stefan
>> 
>>> Am 29.03.2018 um 12:56 schrieb Greg Stein <gst...@gmail.com>:
>>> 
>>> 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

[Nick Edwards]

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

[li...@rhsoft.net]

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

[Helmut K. C. Tessarek]

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

[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 <stefan.eiss...@greenbytes.de>:
> Done in r1827992.
>
> Cheers,
> Stefan
>
>> Am 29.03.2018 um 12:56 schrieb Greg Stein <gst...@gmail.com>:
>>
>> 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

[Bernard Spil]

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 <br...@freebsd.org>:
> 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 <stefan.eiss...@greenbytes.de>:
>> 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

[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 <stefan.eiss...@greenbytes.de>:
> 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

[Stefan Eissing]

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

[Rainer Jung]

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

[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

[Stefan Eissing]

Done in r1827992.

Cheers,
Stefan

> Am 29.03.2018 um 12:56 schrieb Greg Stein <gst...@gmail.com>:
> 
> 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

[Greg Stein]

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

[li...@rhsoft.net]

Am 29.03.2018 um 11:41 schrieb Yann Ylavic:
> On Thu, Mar 29, 2018 at 11:39 AM, Yann Ylavic <ylavic@gmail.com> wrote:
>> On Thu, Mar 29, 2018 at 10:16 AM, Stefan Eissing
>> <stefan.eiss...@greenbytes.de> 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
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

[Yann Ylavic]

On Thu, Mar 29, 2018 at 11:39 AM, Yann Ylavic <ylavic@gmail.com> wrote:
> On Thu, Mar 29, 2018 at 10:16 AM, Stefan Eissing
> <stefan.eiss...@greenbytes.de> 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

[Yann Ylavic]

On Thu, Mar 29, 2018 at 10:16 AM, Stefan Eissing
<stefan.eiss...@greenbytes.de> 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

[Stefan Eissing]

> Am 29.03.2018 um 06:21 schrieb Greg Stein <gst...@gmail.com>:
> 
> 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.

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

[Greg Stein]

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

TLSv1.3

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