Re: possible relayd.conf(5) documentation mistake regarding session tickets
On 20/10/21 09:26PM, Sebastian Benoit wrote:
> * i'm not sure we wanted session resumption to be enabled by default
> because of the security implications regarding perferct forward
> secrecy. Indeed the option is off by default at the moment.
Hey, thanks for explaining a bit. :) I read about session resumption
after your mail and can see why the default is off.
Originally I noticed the disparity between what the man page states and
what Qualys reports because I was comparing the results of default
ciphers and `tls { ciphers secure }`, as `openssl ciphers -v secure`
returns an error and SSL_CTX_set_cipher_list(3) doesn't list secure as
a control string.
--
https://amissing.link
Re: possible relayd.conf(5) documentation mistake regarding session tickets
Sebastian Benoit(benoit-li...@fb12.de) on 2020.10.21 21:26:00 +0200:
> Ashlen(euryd...@riseup.net) on 2020.10.20 16:02:49 -0600:
> > In relayd.conf(5), the tls section under PROTOCOLS states the following:
> >
> > no session tickets
> > Disable TLS session tickets. relayd(8) supports stateless TLS
> > session tickets (RFC 5077) to implement TLS session resumption.
> > The default is to enable session tickets.
> >
> > However, an SSL Labs test[1] without `tls { session tickets }` specified
> > shows no session tickets.
>
> There are two things i believe happening:
>
> * i'm not sure we wanted session resumption to be enabled by default because
> of the security implications regarding perferct forward secrecy. Indeed the
> option is off by default at the moment.
It's disabled by default on purpose.
Manpage is updated.
>
> * With TLS 1.3, session resumption is called pre-shared key) resumption.
> I have to check what the issue here is, that is if qualys does not show this
> right or if relayd has to do something different.
Indeed, our TLS 1.3 does not yet support session resumption.:
> For now, with the following options you should see session resumption:
>
> tls { session tickets, tlsv1.2, no tlsv1.3 }
Of course if you just do
tls { session tickets }
clients that support 1.3 wont get it, but ones that do not support 1.3 will.
Best,
Benno
Re: possible relayd.conf(5) documentation mistake regarding session tickets
Ashlen(euryd...@riseup.net) on 2020.10.20 16:02:49 -0600:
> In relayd.conf(5), the tls section under PROTOCOLS states the following:
>
> no session tickets
> Disable TLS session tickets. relayd(8) supports stateless TLS
> session tickets (RFC 5077) to implement TLS session resumption.
> The default is to enable session tickets.
>
> However, an SSL Labs test[1] without `tls { session tickets }` specified
> shows no session tickets.
There are two things i believe happening:
* i'm not sure we wanted session resumption to be enabled by default because
of the security implications regarding perferct forward secrecy. Indeed the
option is off by default at the moment.
* With TLS 1.3, session resumption is called pre-shared key) resumption.
I have to check what the issue here is, that is if qualys does not show this
right or if relayd has to do something different.
For now, with the following options you should see session resumption:
tls { session tickets, tlsv1.2, no tlsv1.3 }
I will figure out what to do about the default, the documentation and TLS
1.3.
/Benno
>
> $ uname -a
> OpenBSD lain.lan 6.8 GENERIC.MP#98 amd64
>
> [1]: https://www.ssllabs.com/ssltest/
>
> --
> https://amissing.link
>
--
possible relayd.conf(5) documentation mistake regarding session tickets
In relayd.conf(5), the tls section under PROTOCOLS states the following:
no session tickets
Disable TLS session tickets. relayd(8) supports stateless TLS
session tickets (RFC 5077) to implement TLS session resumption.
The default is to enable session tickets.
However, an SSL Labs test[1] without `tls { session tickets }` specified
shows no session tickets.
$ uname -a
OpenBSD lain.lan 6.8 GENERIC.MP#98 amd64
[1]: https://www.ssllabs.com/ssltest/
--
https://amissing.link
