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(00000003) > 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 > <snip> > --- > 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 >>> >>
