You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Eissing <st...@greenbytes.de> on 2018/03/28 15:49:19 UTC
TLSv1.3
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
Posted by Nick Edwards <ni...@gmail.com>.
well well if its not BANNED USER Reindl harrold using a ghost account
On Tue, Apr 3, 2018 at 5:02 AM, lists@rhsoft.net <li...@rhsoft.net> wrote:
>
>
> no, it's just an opinion based on the Chrome will penalty non-https in
> general (bseides: the ACME challenge is happy with a automatic rediect
> to https even if it's a self-signed certificate)
>
> that opinion completly ignores setups where the load-balancer does
>
Re: TLSv1.3
Posted by "lists@rhsoft.net" <li...@rhsoft.net>.
Am 02.04.2018 um 20:56 schrieb Helmut K. C. Tessarek:
> On 2018-03-29 04:16, Stefan Eissing wrote:
>> 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.
>
> This statement makes me a bit nervous. Are you saying that there won't
> be a way to use Apache with http anymore?
no, it's just an opinion based on the Chrome will penalty non-https in
general (bseides: the ACME challenge is happy with a automatic rediect
to https even if it's a self-signed certificate)
that opinion completly ignores setups where the load-balancer does
tls-offloading/caching and has a dediacted connection in a seperated
network to the backend servers which are http-only forever
the load-balancer can be http://trafficserver.apache.org/ as example
which also does HTTP2-over-TLS for the client while the backend
connection is also HTTP/1.1 forever - in that case mod_h2/mod_md are not
part of the game and even mpm_prefork stays untouched
Re: TLSv1.3
Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
Hello,
On 2018-03-29 04:16, Stefan Eissing wrote:
> 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.
This statement makes me a bit nervous. Are you saying that there won't
be a way to use Apache with http anymore? (Since I don't know what a
data center setup entails that is - new directive, http only setup, ...)
Also, the 'will be used' part is a bit puzzling. This part rather
suggests that all users will magically only use https from that point
forward. Or was it meant as "Apache will only use https anymore"?
I'm basically using https anyway, however there are connections that
*must* be plain http, e.g. the ACME challenge. I like to use my own
scripts for maintaining the certificates thus I am not using the Apache
module, which further means that I must have control over Apache's http
setup.
I'm doing something like this:
<VirtualHost IP_ADDRESS:80>
ServerName HOSTNAME:80
Alias "/.well-known/acme-challenge/"
"/COMMON_DIR/acme-challenge/.well-known/acme-challenge/"
<Directory "/COMMON_DIR/acme-challenge/">
Require all granted
</Directory>
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/.*
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L,R=301]
</VirtualHost>
<VirtualHost IP_ADDRESS:443>
ServerName HOSTNAME:443
# Your "real" configuration here
</VirtualHost>
Can you please elaborate on your above statement and clear that up for me?
Cheers,
K. C.
--
regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
Re: TLSv1.3
Posted by Rainer Jung <ra...@kippdata.de>.
Am 29.03.2018 um 16:15 schrieb Eric Covener:
> If you have this setup handy, could you check what happens if you
> negotiate TLS1.3 then request a directory that has per-directory SSL
> settings in it?
>
> I assume it fails (renegotiation) but not sure how the logs will look.
> That would be one big pitfall for flipping on tls1.3.
I think the expert group discussed this typical reneg use case before
removing reneg. It seems to me that this
https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.6.2
is what we are instead expected to do in the case of client cert
requirement for a sub directory. The server checks, whether the client
supports the "post_handshake_auth" extension and if so, it can send
later (after the handshake and probably also after handling some
requests) a CertificateRequest request message (without reneg).
To enforce stronger crypto after the handshake, maybe
https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.6.3
is the way to go, I'm not sure. I also do't know, whether this is still
a relevant use case for TLS 1.3, because it only uses 5 ciphers and
changing the default cipher list currently seems to be not really expected.
Regards,
Rainer
Re: TLSv1.3
Posted by Stefan Eissing <st...@greenbytes.de>.
Not at my dev machine any more, but good point. May result in disabling it unless explicitly configured.
Work in progress...
> Am 29.03.2018 um 16:15 schrieb Eric Covener <co...@gmail.com>:
>
> If you have this setup handy, could you check what happens if you
> negotiate TLS1.3 then request a directory that has per-directory SSL
> settings in it?
>
> I assume it fails (renegotiation) but not sure how the logs will look.
> That would be one big pitfall for flipping on tls1.3.
Re: TLSv1.3
Posted by Eric Covener <co...@gmail.com>.
If you have this setup handy, could you check what happens if you
negotiate TLS1.3 then request a directory that has per-directory SSL
settings in it?
I assume it fails (renegotiation) but not sure how the logs will look.
That would be one big pitfall for flipping on tls1.3.
Re: TLSv1.3
Posted by Gregg Smith <gl...@gknw.net>.
Fashionably late to the party but I've built it on Windows and it works
for me on FF Nightly. Thanks Stefan for getting tls1.3 in and working.
Cheers
On 4/4/2018 4:24 AM, Stefan Eissing wrote:
> Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps doing TLSv1.2
> while the Nightly goes TLSv1.3. Perhaps a matter of the previous draft still used
> in the releases FF.
>
> Just FYI.
>
>> Am 03.04.2018 um 17:09 schrieb Mario Brandt <jb...@gmail.com>:
>>
>> Hi Stefan,
>>
>> On 3 April 2018 at 14:58, Stefan Eissing <st...@greenbytes.de> wrote:
>>> Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop.
>>
>> With FF open the about:config page
>>
>> Find
>> security.tls.version.max
>>
>> set the value from 3 to 4
>>
>> Cheers
>> Mario
>
Re: TLSv1.3
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Not sure if you are aware of the converse of our favorite site;
https://www.ssllabs.com/ssltest/viewMyClient.html
On Wed, Apr 4, 2018 at 7:52 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
> :) I have that running for HOURS already!
>
> Results were from 1.1.1-pre4
>
>> Am 04.04.2018 um 14:46 schrieb Rainer Jung <ra...@kippdata.de>:
>>
>> I don't know whether it helps, but OpenSSL release pre4 (beta 2) yesterday.
>>
>> Regards,
>>
>> Rainer
>>
>> Am 04.04.2018 um 13:24 schrieb Stefan Eissing:
>>> Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps doing TLSv1.2
>>> while the Nightly goes TLSv1.3. Perhaps a matter of the previous draft still used
>>> in the releases FF.
>>> Just FYI.
>>>> Am 03.04.2018 um 17:09 schrieb Mario Brandt <jb...@gmail.com>:
>>>>
>>>> Hi Stefan,
>>>>
>>>> On 3 April 2018 at 14:58, Stefan Eissing <st...@greenbytes.de> wrote:
>>>>> Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop.
>>>>
>>>> With FF open the about:config page
>>>>
>>>> Find
>>>> security.tls.version.max
>>>>
>>>> set the value from 3 to 4
>>>>
>>>> Cheers
>>>> Mario
>
Re: TLSv1.3
Posted by Stefan Eissing <st...@greenbytes.de>.
:) I have that running for HOURS already!
Results were from 1.1.1-pre4
> Am 04.04.2018 um 14:46 schrieb Rainer Jung <ra...@kippdata.de>:
>
> I don't know whether it helps, but OpenSSL release pre4 (beta 2) yesterday.
>
> Regards,
>
> Rainer
>
> Am 04.04.2018 um 13:24 schrieb Stefan Eissing:
>> Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps doing TLSv1.2
>> while the Nightly goes TLSv1.3. Perhaps a matter of the previous draft still used
>> in the releases FF.
>> Just FYI.
>>> Am 03.04.2018 um 17:09 schrieb Mario Brandt <jb...@gmail.com>:
>>>
>>> Hi Stefan,
>>>
>>> On 3 April 2018 at 14:58, Stefan Eissing <st...@greenbytes.de> wrote:
>>>> Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop.
>>>
>>> With FF open the about:config page
>>>
>>> Find
>>> security.tls.version.max
>>>
>>> set the value from 3 to 4
>>>
>>> Cheers
>>> Mario
Re: TLSv1.3
Posted by Rainer Jung <ra...@kippdata.de>.
I don't know whether it helps, but OpenSSL release pre4 (beta 2) yesterday.
Regards,
Rainer
Am 04.04.2018 um 13:24 schrieb Stefan Eissing:
> Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps doing TLSv1.2
> while the Nightly goes TLSv1.3. Perhaps a matter of the previous draft still used
> in the releases FF.
>
> Just FYI.
>
>> Am 03.04.2018 um 17:09 schrieb Mario Brandt <jb...@gmail.com>:
>>
>> Hi Stefan,
>>
>> On 3 April 2018 at 14:58, Stefan Eissing <st...@greenbytes.de> wrote:
>>> Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop.
>>
>> With FF open the about:config page
>>
>> Find
>> security.tls.version.max
>>
>> set the value from 3 to 4
>>
>> Cheers
>> Mario
Re: TLSv1.3
Posted by Stefan Eissing <st...@greenbytes.de>.
Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps doing TLSv1.2
while the Nightly goes TLSv1.3. Perhaps a matter of the previous draft still used
in the releases FF.
Just FYI.
> Am 03.04.2018 um 17:09 schrieb Mario Brandt <jb...@gmail.com>:
>
> Hi Stefan,
>
> On 3 April 2018 at 14:58, Stefan Eissing <st...@greenbytes.de> wrote:
>> Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop.
>
> With FF open the about:config page
>
> Find
> security.tls.version.max
>
> set the value from 3 to 4
>
> Cheers
> Mario
Re: TLSv1.3
Posted by Mario Brandt <jb...@gmail.com>.
Hi Stefan,
On 3 April 2018 at 14:58, Stefan Eissing <st...@greenbytes.de> wrote:
> Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop.
With FF open the about:config page
Find
security.tls.version.max
set the value from 3 to 4
Cheers
Mario
Re: TLSv1.3
Posted by Bernard Spil <br...@freebsd.org>.
Sorry William, didn't mean to disturb you. Just noticed some 2.5.1 and
2.5.1-dev strings appearing in commits.
Hope the project will roll another 2.5-dev soon. OpenSSL 1.1.1 is
nearing and a TLSv1.3 Apache server to go with that would be most
excellent!
Thanks! Bernard.
2018-04-10 17:35 GMT+02:00 William A Rowe Jr <wr...@rowe-clan.net>:
> On Sun, Apr 8, 2018 at 11:37 AM, Bernard Spil <br...@freebsd.org> wrote:
>> Hi Stefan, Mario,
>>
>> I saw that 2.5.1-dev was tagged, is another release coming some time soon?
>
> Worried me enough to look; http://svn.apache.org/repos/asf/httpd/httpd/tags/
>
> Thankfully nobody made such a tag. You'll note 2.5.0-alpha from a number
> of months ago; this was the first in development of new tag and release
> tooling, and as such it never made the cut. No word at this moment of the
> next 2.5.1-alpha attempt.
Re: TLSv1.3
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sun, Apr 8, 2018 at 11:37 AM, Bernard Spil <br...@freebsd.org> wrote:
> Hi Stefan, Mario,
>
> I saw that 2.5.1-dev was tagged, is another release coming some time soon?
Worried me enough to look; http://svn.apache.org/repos/asf/httpd/httpd/tags/
Thankfully nobody made such a tag. You'll note 2.5.0-alpha from a number
of months ago; this was the first in development of new tag and release
tooling, and as such it never made the cut. No word at this moment of the
next 2.5.1-alpha attempt.
Re: TLSv1.3
Posted by Stefan Eissing <st...@greenbytes.de>.
> 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 <st...@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 <st...@greenbytes.de>:
>>>> Done in r1827992.
>>>>
>>>> Cheers,
>>>> Stefan
>>>>
>>>>> Am 29.03.2018 um 12:56 schrieb Greg Stein <gs...@gmail.com>:
>>>>>
>>>>> On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing <st...@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
>>>>>
>>>>
>>
Re: TLSv1.3
Posted by 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
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 <st...@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 <st...@greenbytes.de>:
>>> Done in r1827992.
>>>
>>> Cheers,
>>> Stefan
>>>
>>>> Am 29.03.2018 um 12:56 schrieb Greg Stein <gs...@gmail.com>:
>>>>
>>>> On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing <st...@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
>>>>
>>>
>
Re: TLSv1.3
Posted by Stefan Eissing <st...@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 <st...@greenbytes.de>:
>> Done in r1827992.
>>
>> Cheers,
>> Stefan
>>
>>> Am 29.03.2018 um 12:56 schrieb Greg Stein <gs...@gmail.com>:
>>>
>>> On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing <st...@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
>>>
>>
Re: TLSv1.3
Posted by 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 <st...@greenbytes.de>:
> Done in r1827992.
>
> Cheers,
> Stefan
>
>> Am 29.03.2018 um 12:56 schrieb Greg Stein <gs...@gmail.com>:
>>
>> On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing <st...@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
>>
>
Re: TLSv1.3
Posted by Stefan Eissing <st...@greenbytes.de>.
Done in r1827992.
Cheers,
Stefan
> Am 29.03.2018 um 12:56 schrieb Greg Stein <gs...@gmail.com>:
>
> On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing <st...@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
>
Re: TLSv1.3
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing <
stefan.eissing@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
Re: TLSv1.3
Posted by "lists@rhsoft.net" <li...@rhsoft.net>.
Am 29.03.2018 um 11:41 schrieb Yann Ylavic:
> On Thu, Mar 29, 2018 at 11:39 AM, Yann Ylavic <yl...@gmail.com> wrote:
>> On Thu, Mar 29, 2018 at 10:16 AM, Stefan Eissing
>> <st...@greenbytes.de> wrote:
>>>
>>> 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
>>>
>>> # as before, applies to all TLS protocols <=TLSv1.2 SSLCipherSuite
>>> XXX:YY:-AASSD:DSDS
>>>
>>> # Set ciphers for TLSv1.3, does not replace the previous line
>>> SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256
>>>
>>> So, the directive becomes:
>>>
>>> SSLCipherSuite [ ProtocolClass ] Cipher-String
>>>
>>> where ProtocolClass is:
>>> SSL (default) all TLS/SSL Protocols <= TLSv1.2
>>> TLSv1.3 TLS version 1.3
>>
>> Looks good to me.
>> I wonder if it's not applicable to TLSv1.2 already, there is a number
>> of ciphers available to 1.2 only (with openssl < 1.1).
>
> (e.g. GCMs, CHACHA+POLYs, SHA-2s ...)
FWIW: 30 minutes before the start of this thread i got this copy&paste
per jabber - so it's an openssl issue at all that ghey just don't parse
out the TLS1.3 related ones from SSLCipherSuite and so that is a
completly new bahvior breaking the sort of abstraction that i shouldn't
know about TLS 1.0/1.1/1.2/1.3 at all in consumer code
______________________
upgrading to next openssl-1.1.1 could break your prod if you're using a
forced cipher list because handshake will fail regardless the tls
protocol version if you don't specify a cipher valid for TLSv1.3 in your
cipher list.
https://github.com/openssl/openssl/issues/5057
https://github.com/openssl/openssl/issues/5065
Openssl's team doesn't seem to consider this as an issue
FYI OpenSSL did a 180 on this, they are implemented a new API call to
set TLSv1.3 ciphers and enable them by default:
https://github.com/mattcaswell/openssl/commit/d93e832a82087a5f9bcf7d93ed7ae21bc6c1fed0
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_ciphersuites.html
Split configuration of TLSv1.3 ciphers from older ciphers
With the current mechanism, old cipher strings that used to work in 1.1.0,
may inadvertently disable all TLSv1.3 ciphersuites causing connections to
fail. This is confusing for users.
In reality TLSv1.3 are quite different to older ciphers. They are much
simpler and there are only a small number of them so, arguably, they don't
need the same level of control that the older ciphers have.
This change splits the configuration of TLSv1.3 ciphers from older ones.
By default the TLSv1.3 ciphers are on, so you cannot inadvertently disable
them through your existing config.
Fixes #5359
Re: TLSv1.3
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Mar 29, 2018 at 11:39 AM, Yann Ylavic <yl...@gmail.com> wrote:
> On Thu, Mar 29, 2018 at 10:16 AM, Stefan Eissing
> <st...@greenbytes.de> wrote:
>>
>> 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
>>
>> # as before, applies to all TLS protocols <=TLSv1.2 SSLCipherSuite
>> XXX:YY:-AASSD:DSDS
>>
>> # Set ciphers for TLSv1.3, does not replace the previous line
>> SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256
>>
>> So, the directive becomes:
>>
>> SSLCipherSuite [ ProtocolClass ] Cipher-String
>>
>> where ProtocolClass is:
>> SSL (default) all TLS/SSL Protocols <= TLSv1.2
>> TLSv1.3 TLS version 1.3
>
> Looks good to me.
> I wonder if it's not applicable to TLSv1.2 already, there is a number
> of ciphers available to 1.2 only (with openssl < 1.1).
(e.g. GCMs, CHACHA+POLYs, SHA-2s ...)
>
> Thanks,
> Yann.
Re: TLSv1.3
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Mar 29, 2018 at 10:16 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
>
> 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
>
> # as before, applies to all TLS protocols <=TLSv1.2 SSLCipherSuite
> XXX:YY:-AASSD:DSDS
>
> # Set ciphers for TLSv1.3, does not replace the previous line
> SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256
>
> So, the directive becomes:
>
> SSLCipherSuite [ ProtocolClass ] Cipher-String
>
> where ProtocolClass is:
> SSL (default) all TLS/SSL Protocols <= TLSv1.2
> TLSv1.3 TLS version 1.3
Looks good to me.
I wonder if it's not applicable to TLSv1.2 already, there is a number
of ciphers available to 1.2 only (with openssl < 1.1).
Thanks,
Yann.
Re: TLSv1.3
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 29.03.2018 um 06:21 schrieb Greg Stein <gs...@gmail.com>:
>
> On Wed, Mar 28, 2018 at 10:49 AM, Stefan Eissing <st...@greenbytes.de> wrote:
> 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.
>
> Why not something simple like:
>
> TLSVersion 1.3
>
> and have that impute a specific set of ciphers? Get's away from the old "SSL" name, and moves us to a directive that can accept version into the future (instead of a new directive every time).
>
> And if you want to *refine* the behavior, then do it with new TLS* directives. I've always had a problem with setting up TLS servers because of the huge number of directives. It would be nice to just introduce a new, simple directive that produces "all" the default handling for the majority of users.
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).
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
# as before, applies to all TLS protocols <=TLSv1.2
SSLCipherSuite XXX:YY:-AASSD:DSDS
# Set ciphers for TLSv1.3, does not replace the previous line
SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256
So, the directive becomes:
SSLCipherSuite [ ProtocolClass ] Cipher-String
where ProtocolClass is:
SSL (default) all TLS/SSL Protocols <= TLSv1.2
TLSv1.3 TLS version 1.3
That would mean we have no new directives.
> - 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?
>
> Euh, if the underlying libraries cannot support a new TLS version, *and* httpd hasn't been coded to support that version, then yes: it should fail. Both parts are needed.
>
> Did I misunderstand your query?
>
> - 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.
>
> Oh no no. If I want to configure "SuperAwesomeGJSCipher", and that isn't available like I *expect* it to be ... then yeah. "Cipher not available. You won't get the security you're seeking." #FAIL
>
> Cheers,
> -g
>
Re: TLSv1.3
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Mar 28, 2018 at 10:49 AM, Stefan Eissing <
stefan.eissing@greenbytes.de> wrote:
> 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.
>
Why not something simple like:
TLSVersion 1.3
and have that impute a specific set of ciphers? Get's away from the old
"SSL" name, and moves us to a directive that can accept version into the
future (instead of a new directive every time).
And if you want to *refine* the behavior, then do it with new TLS*
directives. I've always had a problem with setting up TLS servers because
of the huge number of directives. It would be nice to just introduce a new,
simple directive that produces "all" the default handling for the majority
of users.
> - 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?
>
Euh, if the underlying libraries cannot support a new TLS version, *and*
httpd hasn't been coded to support that version, then yes: it should fail.
Both parts are needed.
Did I misunderstand your query?
> - 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.
>
Oh no no. If I want to configure "SuperAwesomeGJSCipher", and that isn't
available like I *expect* it to be ... then yeah. "Cipher not available.
You won't get the security you're seeking." #FAIL
Cheers,
-g
Re: TLSv1.3
Posted by Bernard Spil <br...@freebsd.org>.
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 <br...@freebsd.org>:
> 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 <st...@greenbytes.de>:
>> 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
Posted by Bernard Spil <br...@freebsd.org>.
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 <st...@greenbytes.de>:
> 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
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 04.04.2018 um 20:23 schrieb William A Rowe Jr <wr...@rowe-clan.net>:
>
> SSLProtocol TLSv1.2 TLSv1.3
> SSLProxyProtocol TLSv1.2 TLSv1.3
>
> should be syntactically valid, no?
Not sure. Is
> SSLProtocol TLSv1.2 TLSv1.1
valid? On the road right now and cannot test. I agree
that it probably makes sense, but for backport compat
I tried to add TLSv1.3 in the same spirit as the other
protocols.
>
> [Wed Apr 04 18:21:11.465896 2018] [ssl:warn] [pid 2228052:tid
> 140031042861312] AH02532: SSLProtocol: Protocol 'TLSv1.3' overrides
> already set parameter(s). Check if a +/- prefix is missing.
> [Wed Apr 04 18:21:11.465946 2018] [ssl:warn] [pid 2228052:tid
> 140031042861312] AH02532: SSLProxyProtocol: Protocol 'TLSv1.3'
> overrides already set parameter(s). Check if a +/- prefix is missing.
>
> TLSv1.3 should begin 'unset' if TLSv1.2 is given without modifiers.
>
>
> On Wed, Mar 28, 2018 at 10:49 AM, Stefan Eissing
> <st...@greenbytes.de> wrote:
>> 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
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
SSLProtocol TLSv1.2 TLSv1.3
SSLProxyProtocol TLSv1.2 TLSv1.3
should be syntactically valid, no?
[Wed Apr 04 18:21:11.465896 2018] [ssl:warn] [pid 2228052:tid
140031042861312] AH02532: SSLProtocol: Protocol 'TLSv1.3' overrides
already set parameter(s). Check if a +/- prefix is missing.
[Wed Apr 04 18:21:11.465946 2018] [ssl:warn] [pid 2228052:tid
140031042861312] AH02532: SSLProxyProtocol: Protocol 'TLSv1.3'
overrides already set parameter(s). Check if a +/- prefix is missing.
TLSv1.3 should begin 'unset' if TLSv1.2 is given without modifiers.
On Wed, Mar 28, 2018 at 10:49 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
> 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.
>