On Sun, Aug 21, 2016 at 02:25:15PM -0400, Ted Unangst wrote: > Andreas Bartelt wrote: > > Since the use of TLS session tickets potentially interferes with forward > > secrecy on a per-session basis, I'd personally prefer an opt-in in > > libtls as well as in httpd with regard to its usage. However, such a > > semantic change would not be transparent. Any opinions on this? > > Defaulting to off makes sense to me. It's the marginally safer option and at > small scale probably not a performance concern. But if the default results in > 900 "tutorials" telling people to turn it back on because web scale, then all > we've done is make things difficult. >
While I agree it is important to turn them on for HTTP servers or any other protocol that does a lot of reconnects. This should also include the magic to make them work accross multiple processes (see my relayd diff for that -- which uses the libssl callback madness though). Without tickets the full TLS handshake will be made for every reconnect which is a common mode of operation for HTTP. Also I think tickets are a bit saver than the session cache (which AFAIK is also default on for servers) and probably the fallback mode. Client side tickets should be enabled since they are just pass along to the next connect without processing them. > > As kind of a first step, the attached diff adds an function to libtls > > which allows to (optionally) disable the use of tls session tickets. > > Can you please add an option to enable tickets? That makes it easier to write > software that works with either default. -- :wq Claudio
