Re: TLSv1.3
Hi Stefan, Sure I'm here :D Have been the maintainer of the LibreSSL ports in FreeBSD for a good while and more recently joined the apache@ team. I'll let you know my results. I have an OpenSSL 1.1.1 port in the making so I can test all of this long before it lands in a release. Cheers, Bernard. 2018-03-28 17:49 GMT+02:00 Stefan Eissing : > Just added TLSv1.3 support in trunk. No fancy new early data features, just > the basic. > > Open for discussion: > - The Mozilla server-side-tls people are still thinking of what they will > recommend, see: > > https://github.com/mozilla/server-side-tls/issues/191#issuecomment-376918933 > - Turns out, cipher suites are separate from <= TLSv1.2. Since servers will > co-host 1.2 and 1.3 >for some time, we need additional config directives, I think. Added > "SSLCipherSuiteV1_3" and >am ashamed of the name. > - The current handling of TLS versions that are not supported by the *SSL > lib linked is not >super helpful. It more or less pretends that the version does not exist > (unknown protocol), >but that is far from the truth. Shall we continue that or is this an > opportunity to reconsider? > - Should we allow the configuration of TLSv1_3 ciphers, even if the linked > SSL does not support >it? This is different from SSLProtocol which of course needs to fail if it > cannot enable the >version that is explicitly configured. >I think it is ok to take it into the config, even though it never > activates. > > Cheers, > > Stefan > > PS. If a FreeBSD libressl+apache maintainer is listening here, he may try if > trunk compiles with it. I would not stop him. >
Re: svn commit: r1773397 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy.c
2017-01-31 10:53 GMT+01:00 Plüm, Rüdiger, Vodafone Group < ruediger.pl...@vodafone.com>: > > > > -Ursprüngliche Nachricht- > > Von: Joe Orton [mailto:jor...@redhat.com] > > Gesendet: Dienstag, 31. Januar 2017 10:42 > > An: dev@httpd.apache.org > > Betreff: Re: svn commit: r1773397 - in /httpd/httpd/trunk: CHANGES > > modules/proxy/mod_proxy.c > > > > On Mon, Jan 30, 2017 at 07:52:03AM -0500, Eric Covener wrote: > > > I have a fix but not sure if the change should just be reverted. In > > > the PR, the user changed the 2.2 config to make the ProxyPass within > > > location and expected similar behavior. > > > > > > Should have probably just told them that exceptions just could not be > > > done that way. > > > > > > PR config is > > > > > > ProxyPass /error ! > > > > > > ProxyPass http://foo/... > > > > > > > > > It seemed useful at the time, but since stuffing the thing inside of > > > Location is not all that more useful functionally, adding more code > > > seems like a mistake. > > > > Asserting/documenting that higher-level exceptions don't apply for > > ProxyPass within seems pretty reasonable to me. > > > > +1 While reviewing https://bz.apache.org/bugzilla/show_bug.cgi?id=61225 I tried to add some clarification with http://svn.apache.org/r1828069 (trunk only for the moment, will wait a bit before backporting if anybody wants to add/amend). Luca
Re: TLSv1.3
Hi Stefan, Submitted a PR with changes required to build with LibreSSL 2.6 and 2.7 https://bz.apache.org/bugzilla/show_bug.cgi?id=62236 Cheers, Bernard. 2018-03-31 10:34 GMT+02:00 Bernard Spil : > Hi Stefan, > > Sure I'm here :D Have been the maintainer of the LibreSSL ports in > FreeBSD for a good while and more recently joined the apache@ team. > > I'll let you know my results. I have an OpenSSL 1.1.1 port in the > making so I can test all of this long before it lands in a release. > > Cheers, Bernard. > > 2018-03-28 17:49 GMT+02:00 Stefan Eissing : >> Just added TLSv1.3 support in trunk. No fancy new early data features, just >> the basic. >> >> Open for discussion: >> - The Mozilla server-side-tls people are still thinking of what they will >> recommend, see: >> >> https://github.com/mozilla/server-side-tls/issues/191#issuecomment-376918933 >> - Turns out, cipher suites are separate from <= TLSv1.2. Since servers will >> co-host 1.2 and 1.3 >>for some time, we need additional config directives, I think. Added >> "SSLCipherSuiteV1_3" and >>am ashamed of the name. >> - The current handling of TLS versions that are not supported by the *SSL >> lib linked is not >>super helpful. It more or less pretends that the version does not exist >> (unknown protocol), >>but that is far from the truth. Shall we continue that or is this an >> opportunity to reconsider? >> - Should we allow the configuration of TLSv1_3 ciphers, even if the linked >> SSL does not support >>it? This is different from SSLProtocol which of course needs to fail if >> it cannot enable the >>version that is explicitly configured. >>I think it is ok to take it into the config, even though it never >> activates. >> >> Cheers, >> >> Stefan >> >> PS. If a FreeBSD libressl+apache maintainer is listening here, he may try if >> trunk compiles with it. I would not stop him. >>
Re: TLSv1.3
I'm running an Apache 2.5.1 snapshot from 2018-03-30 linked against 1.1.1-pre3 from 2018-03-20 (AKA beta 1). If I connect to Apache with openssl 1.1.1 it makes a TLSv1.3 connection. Qualys SSLLabs doesn't see the TLSv1.3 at all. Additionally, Apache doesn't start when SSLOpenSSLConfCmd is used (SSLOpenSSLConfCmd groups secp521r1:secp384r1:x25519) Negotiated connections default to x25519 which is not what I expect. >From another host: % /usr/local/bin/openssl version OpenSSL 1.1.1-pre3 (beta) 20 Mar 2018 % /usr/local/bin/openssl s_client -connect test.brnrd.eu:443 CONNECTED(0003) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = test.brnrd.eu verify return:1 --- No client certificate CA names sent Peer signing digest: SHA384 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 2696 bytes and written 390 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 384 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent SSL-Session: Protocol : TLSv1.3 Cipher: TLS_AES_256_GCM_SHA384 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1522528505 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- Firefox Nightly and Chrome don't negotiate TLSv1.3 either Am I expecting things that I should not? (Entirely possible :D) Cheers, Bernard. 2018-03-29 16:11 GMT+02:00 Stefan Eissing : > Done in r1827992. > > Cheers, > Stefan > >> Am 29.03.2018 um 12:56 schrieb Greg Stein : >> >> On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing >> wrote: >> >... >> That is the intention behind "SSLPolicy modern|intermediate|old" that >> configures the TLS stack according to the Mozilla server-side-tls >> recommendations. So, one does not have to mess with many directives to have >> a site with an "A" SSL Labs rating. >> >> Besides, except for data center setups, Apache will be used *only* with >> https: (and http: redirects to https:) very, very soon. That shifts the >> average expertise of an admin setting up a https: site. >> >> Back to TLSv1.3: >> >> I do not like to invent new config directives for a new TLS version either. >> The protocol on/off switch is now in "SSLProtocol" and that's where it >> should be. AFAIK, it's only the cipher list that needs special treatment (if >> one wants to override defaults or what SSLPolicy will do for it, once a >> recommendation is out). >> >> Gotcha. >> >> >> So, looking at "SSLCipherSuite". It basically passes the string to the *SSL >> library. The manual page makes a big explanation and tables of ciphers, but >> the lists repeats basically how OpenSSL cipher strings work. It would be >> better to scrap that and replace it with a link to >> https://www.openssl.org/docs/man1.0.2/apps/ciphers.html, now that openssl >> has nicer documentation) >> >> Along the gist of your proposal, I think I'll expand "SSLCipherSuite" to >> take more than 1 argument and look for optional prefixes to the suite >> strings given, so one could do >> >> Oooh! Yes. Looks great. >> >> +1 >> >> >... >> >> Cheers, >> -g >> >
