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

Reply via email to