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