> Am 08.04.2018 um 18:37 schrieb Bernard Spil <[email protected]>: > > 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 <[email protected]>: >> 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 <[email protected]>: >>> >>> 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 <[email protected]>: >>>> Done in r1827992. >>>> >>>> Cheers, >>>> Stefan >>>> >>>>> Am 29.03.2018 um 12:56 schrieb Greg Stein <[email protected]>: >>>>> >>>>> On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing >>>>> <[email protected]> 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 >>>>> >>>> >>
