add option for disabling TLS session tickets to libttls

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

add option for disabling TLS session tickets to libttls

Andreas Bartelt-2
Hello,

LibreSSL enables the use of the TLS session ticket extension [RFC 5077,
or, according to comments in source code its older version 4507] by
default, and libtls currently doesn't provide an API call for disabling
this feature.

Consequently, OpenBSD's httpd has TLS session tickets enabled by default
and doesn't provide an option to turn this TLS extension off. Moreover,
there's currently no way to provide a specific policy with regard to the
use of TLS session tickets (e.g., lifetime of the corresponding secret
key which is used for encrypting all session tickets, the encryption
scheme for session tickets etc).

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?

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.

Best regards
Andreas

libtls.diff (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: add option for disabling TLS session tickets to libttls

Ted Unangst-6
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.

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

Reply | Threaded
Open this post in threaded view
|

Re: add option for disabling TLS session tickets to libttls

Andreas Bartelt-2
On 08/21/16 20:25, 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.
>
I'm not so sure that disabling session tickets is only marginally safer.
Please correct me if the following analysis is wrong.

With session tickets disabled:
- in case forward secrecy is not enabled and the attacker somehow
obtains the server's private key -> attacker can decrypt past, present
and future TLS traffic to this server
- in case forward secrecy is enabled and the attacker somehow obtains
the server's private key -> attacker can conduct active MITM attacks on
present and future TLS traffic to this server. However, passive MITM
attacks won't succeed.

With session tickets enabled:
- in case the attacker somehow obtains the secret key which is used by
the server to encrypt all of its session tickets -> attacker can conduct
passive MITM attacks with regard to all TLS traffic to this server in
the scope (i.e., lifetime) of the obtained secret key. This is because
TLS clients send their session tickets back to the server during session
resumption which enables a relatively straightforward way for snooping
them on the wire. Decrypted session tickets might also enable active
interference with their corresponding TLS sessions (e.g., the attacker
could actively resume them).

In my opinion, the security of this TLS extension strongly depends on
the assumptions about the attacker's capabilities and on the absence of
other vulnerabilities (e.g., some kind of key leakage similar to
heartbleed?). That being said, I still think that this TLS extension can
be deployed with reasonable security. However, it doesn't look to me
like a conservative ``default'' configuration.

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

diff, which also disables session tickets by default in libtls, is attached.


libtls.diff2 (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: add option for disabling TLS session tickets to libttls

Claudio Jeker
In reply to this post by Ted Unangst-6
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

Reply | Threaded
Open this post in threaded view
|

Re: add option for disabling TLS session tickets to libttls

Andreas Bartelt-2
On 08/22/16 08:17, Claudio Jeker wrote:

> 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.
>
here's another diff which also adds enable/disable functions with regard
to TLS session resumption. Although this mechanism is technically not a
TLS extension, it is also optional and basically provides the same
functionality as the TLS session ticket extension.

This diff is transparent to the current behaviour of libtls, i.e., it
enables session tickets as well as session resumption by default. As I
already said, I personally don't like the current default. In
particular, I don't like the lack of key management for TLS tickets
which always has to be done manually (see Claudio's relayd patch on
tech@). If things go wrong, the corresponding damage might be pretty
high on long-running TLS servers.

I suppose further API functions should be added for explicitly
configuring session resumption and session ticket parameters.

During testing, I've also noticed that the session resumption mechanism
currently doesn't work reliably. It always seems to fail at the first
session resumption attempt, and it works with unpredictable reliability
afterwards. I didn't look at the corresponding code in libssl yet.

OK?

libtls.patch (5K) Download Attachment