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

ol 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)

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

Re: TLSv1.3 supprt for 2.4.x?

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

Re: TLSv1.3 supprt for 2.4.x?

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

Re: TLSv1.3 supprt for 2.4.x?

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

Re: TLSv1.3 supprt for 2.4.x?

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

Re: TLSv1.3 supprt for 2.4.x?

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

Re: TLSv1.3 supprt for 2.4.x?

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

Re: TLSv1.3 supprt for 2.4.x?

On Tue, Sep 18, 2018 at 4:08 PM Joe Orton wrote: > > As of r1841219 I think the tlsv1.3-for-2.4.x is ready for merging... Thanks Joe for the hard work! > > A BIG caveat remains around Post-Handshake Auth. With the current Perl > stack (including whatever adjustments for OpenSS

Re: TLSv1.3 supprt for 2.4.x?

As of r1841219 I think the tlsv1.3-for-2.4.x is ready for merging... A BIG caveat remains around Post-Handshake Auth. With the current Perl stack (including whatever adjustments for OpenSSL 1.1.1 already required) the failures I get with the test suite and that branch are significant, because

Re: TLSv1.3 supprt for 2.4.x?

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

Re: TLSv1.3 supprt for 2.4.x?

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

Re: TLSv1.3 supprt for 2.4.x?

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

Re: TLSv1.3 supprt for 2.4.x?

sl-1.1.1pre9 (SSLProtocol TLSv1.3 and SSLVerifyClient require), with both firefox and s_client (w/ and w/o -enable_pha) and can't reproduce the hang. What's your client tooling? Regards, Yann.

Re: TLSv1.3 supprt for 2.4.x?

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

Re: TLSv1.3 supprt for 2.4.x?

> Am 10.09.2018 um 10:59 schrieb Joe Orton : > > On Wed, Sep 05, 2018 at 01:36:06PM +0200, Stefan Eissing wrote: >> A member of the OpenSSL project gave me a "go ahead" and we now have branch: >> >> https://svn.apache.org/repos/asf/httpd/httpd/branch

Re: TLSv1.3 supprt for 2.4.x?

On Wed, Sep 05, 2018 at 01:36:06PM +0200, Stefan Eissing wrote: > A member of the OpenSSL project gave me a "go ahead" and we now have branch: > > https://svn.apache.org/repos/asf/httpd/httpd/branches/tlsv1.3-for-2.4.x >

Re: TLSv1.3 supprt for 2.4.x?

ur 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 con

Re: TLSv1.3 supprt for 2.4.x?

pache.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/tes

Re: TLSv1.3 supprt for 2.4.x?

rations 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

Re: TLSv1.3 supprt for 2.4.x?

8 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, > >>> > >>

Re: TLSv1.3 supprt for 2.4.x?

On Wed, Sep 5, 2018 at 10:52 AM, Dennis Clarke wrote: > On 09/05/2018 07:36 AM, Stefan Eissing wrote: > >> A member of the OpenSSL project gave me a "go ahead" and we now have >> branch: >> >> https://svn.apache.org/repos/asf/httpd/httpd/branches/tl

Re: TLSv1.3 supprt for 2.4.x?

On 09/05/2018 07:36 AM, Stefan Eissing wrote: A member of the OpenSSL project gave me a "go ahead" and we now have branch: https://svn.apache.org/repos/asf/httpd/httpd/branches/tlsv1.3-for-2.4.x as a cop

Re: TLSv1.3 supprt for 2.4.x?

On 09/03/2018 09:45 AM, Jim Jagielski wrote: +1! for backporting >> On Sep 3, 2018, at 5:17 AM, Stefan Eissing wrote: >> >> Dear SSL care takers and stake holders, >> >> trunk has TLSv1.3 support for some time. TLSv1.3 is a published protocol and I

Re: TLSv1.3 supprt for 2.4.x?

+1! for backporting > On Sep 3, 2018, at 5:17 AM, Stefan Eissing > wrote: > > Dear SSL care takers and stake holders, > > trunk has TLSv1.3 support for some time. I just now changed the 'all' > SSLProtocol selection, so that it does not include TLSv1.3. This means that

Re: TLSv1.3 supprt for 2.4.x?

Am 03.09.2018 um 13:19 schrieb Joe Orton: AIUI the various bits of new API added for TLS/1.3 are not necessarily stable until there is a final OpenSSL 1.1.1 release, so maybe we should wait for that first? Last mentioned date for GA release of OpenSSL 1.1.1 was Tuesday 11th September. Not

Re: TLSv1.3 supprt for 2.4.x?

gt;>> 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 t

Re: TLSv1.3 supprt for 2.4.x?

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?

ieb 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

Re: TLSv1.3 supprt for 2.4.x?

> Am 03.09.2018 um 13:19 schrieb Joe Orton : > > On Mon, Sep 03, 2018 at 11:17:39AM +0200, Stefan Eissing wrote: >> Dear SSL care takers and stake holders, >> >> trunk has TLSv1.3 support for some time. I just now changed the 'all' >> SSLProtocol selec

Re: TLSv1.3 supprt for 2.4.x?

On Mon, Sep 03, 2018 at 11:17:39AM +0200, Stefan Eissing wrote: > Dear SSL care takers and stake holders, > > trunk has TLSv1.3 support for some time. I just now changed the 'all' > SSLProtocol selection, so that it does not include TLSv1.3. This means that > in order to enable

TLSv1.3 supprt for 2.4.x?

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

Re: TLSv1.3

Sorry William, didn't mean to disturb you. Just noticed some 2.5.1 and 2.5.1-dev strings appearing in commits. Hope the project will roll another 2.5-dev soon. OpenSSL 1.1.1 is nearing and a TLSv1.3 Apache server to go with that would be most excellent! Thanks! Bernard. 2018-04-10 17:35 GMT+02

Re: TLSv1.3

On Sun, Apr 8, 2018 at 11:37 AM, Bernard Spil wrote: > Hi Stefan, Mario, > > I saw that 2.5.1-dev was tagged, is another release coming some time soon? Worried me enough to look; http://svn.apache.org/repos/asf/httpd/httpd/tags/ Thankfully nobody made such a tag. You'll note

Re: TLSv1.3

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

Re: TLSv1.3

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

Re: TLSv1.3

Hi Stefan, Mario, LibreSSL will hopefully add TLSv1.3 to the next version (ca. 6 months). So I can't test with that just yet. Yes, it does work only with Firefox Nightly. :/ Google Chrome Beta doesn't negotiate 1.3 either. Using 1.1.1-pre4 at the moment. The security.tls.version.max

Re: TLSv1.3

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

Re: TLSv1.3

SSLProtocol TLSv1.2 TLSv1.3 SSLProxyProtocol TLSv1.2 TLSv1.3 should be syntactically valid, no? [Wed Apr 04 18:21:11.465896 2018] [ssl:warn] [pid 2228052:tid 140031042861312] AH02532: SSLProtocol: Protocol 'TLSv1.3' overrides already set parameter(s). Check if a +/- prefix is missing. [Wed Apr

Re: TLSv1.3

ng: >>> 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 0

Re: TLSv1.3

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

Re: TLSv1.3

I don't know whether it helps, but OpenSSL release pre4 (beta 2) yesterday. Regards, Rainer Am 04.04.2018 um 13:24 schrieb Stefan Eissing: Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps doing TLSv1.2 while the Nightly goes TLSv1.3. Perhaps a matter of the previous

Re: TLSv1.3

Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps doing TLSv1.2 while the Nightly goes TLSv1.3. Perhaps a matter of the previous draft still used in the releases FF. Just FYI. > Am 03.04.2018 um 17:09 schrieb Mario Brandt <jbl...@gmail.com>: > > Hi St

Re: TLSv1.3

Hi Stefan, On 3 April 2018 at 14:58, Stefan Eissing wrote: > Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop. With FF open the about:config page Find security.tls.version.max set the value from 3 to 4 Cheers Mario

Re: TLSv1.3

Just added your patch for the latest libressl checks. Thanks! If I run that version against Firefox Nightly, it negotiates TLSv1.3. That is with OpenSSL 1.1.1-pre3; I have no test env for libressl. Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop. Cheers, Stefan >

Re: TLSv1.3

well well if its not BANNED USER Reindl harrold using a ghost account On Tue, Apr 3, 2018 at 5:02 AM, li...@rhsoft.net wrote: > > > no, it's just an opinion based on the Chrome will penalty non-https in > general (bseides: the ACME challenge is happy with a automatic rediect

Re: TLSv1.3

Am 02.04.2018 um 20:56 schrieb Helmut K. C. Tessarek: > On 2018-03-29 04:16, Stefan Eissing wrote: >> Besides, except for data center setups, Apache will be used *only* >> with https: (and http: redirects to https:) very, very soon. That >> shifts the average expertise of an admin setting up a

Re: TLSv1.3

Hello, On 2018-03-29 04:16, Stefan Eissing wrote: > Besides, except for data center setups, Apache will be used *only* > with https: (and http: redirects to https:) very, very soon. That > shifts the average expertise of an admin setting up a https: site. This statement makes me a bit nervous.

Re: TLSv1.3

I'm running an Apache 2.5.1 snapshot from 2018-03-30 linked against 1.1.1-pre3 from 2018-03-20 (AKA beta 1). If I connect to Apache with openssl 1.1.1 it makes a TLSv1.3 connection. Qualys SSLLabs doesn't see the TLSv1.3 at all. Additionally, Apache doesn't start when SSLOpenSSLConfCmd is used

Re: TLSv1.3

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

Re: TLSv1.3

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

Re: TLSv1.3

Not at my dev machine any more, but good point. May result in disabling it unless explicitly configured. Work in progress... > Am 29.03.2018 um 16:15 schrieb Eric Covener : > > If you have this setup handy, could you check what happens if you > negotiate TLS1.3 then request

Re: TLSv1.3

Am 29.03.2018 um 16:15 schrieb Eric Covener: If you have this setup handy, could you check what happens if you negotiate TLS1.3 then request a directory that has per-directory SSL settings in it? I assume it fails (renegotiation) but not sure how the logs will look. That would be one big

Re: TLSv1.3

If you have this setup handy, could you check what happens if you negotiate TLS1.3 then request a directory that has per-directory SSL settings in it? I assume it fails (renegotiation) but not sure how the logs will look. That would be one big pitfall for flipping on tls1.3.

Re: TLSv1.3

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 i

Re: TLSv1.3

s 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

Re: TLSv1.3

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:

Re: TLSv1.3

ake 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

Re: TLSv1.3

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

Re: TLSv1.3

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

Re: TLSv1.3

On Wed, Mar 28, 2018 at 10:49 AM, Stefan Eissing < stefan.eiss...@greenbytes.de> wrote: > Just added TLSv1.3 support in trunk. No fancy new early data features, > just the basic. > > Open for discussion: > - The Mozilla server-side-tls people are still thinking of what they

TLSv1.3

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