Subject: [TLS] add challenge in TLS v1.3 to prevent DDOS attack?

From: "Bingzheng Wu" <[email-masked]>
Date: Mon, 08 Jun 2015 16:46:18 +0800

Hi all,

TLS is susceptible to DDOS attack.
In TLS v1.3, attackers can generate ClientHello and ClientKeyshare messages easily,
while the server has to consume large amounts of CPU doing asymmetric crypto operations to generate ServerKeyshare and ServerCertificateVerify messages.

So, could we add a challenge-response mode in TLS v1.3 to increase the attacker's cost ?

The mode is disable in usual.
If the server think it's under attack (e.g. >1000 qps), it could enable this mode by responding a HelloRetryRequest (or a new type) message to the client with a challenge.
The client receiving the challenge must solve the challenge which is expensive in CPU, and continue the handshake by carrying the challenge's answer.

For example, server could make the challenge by encrypting an random number by a RSA public key (which is short), and send the private key (which is long) and cipher text to client.

This challenge mode may bring extra CPU consumption for normal clients when the server is under attack, but it can reduce the attack's influence for server, to prevent DDOS attack.

Obviously, this mode must be a part of TLS's main body, while being an extension dose not work.

Is this a feasible idea?

Regards,
Bingzheng Wu

---

From: CodesInChaos <[email-masked]>
Date: Mon, 8 Jun 2015 11:17:22 +0200

Not sure if this is a practical concern. If an attacker has so many
computers/IPs that IP blacklisting doesn't help anymore (TCP makes IP
spoofing difficult), they probably could simply flood the victim's
connection instead of relying on expensive crypto operations for DoS.

Your proposed proof-of-work doesn't look ideal either, since the cost
is fixed at a low value. Some variant of hashcash is clearly better.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 8 Jun 2015 09:19:56 +0000

>So, could we add a challenge-response mode in TLS v1.3 to increase the attacker's cost ?

You don't need anything that complex, OpenVPN has for a number of years
supported a very effective way of dealing with this, all you need to do is
formalise that.  It doesn't really need TLS 1.3 either, since you can do it in
a standard extension.  OpenVPN gives it the very misleading name tls-auth,
it's just a use of a PSK to MAC incoming packets, so the client-hello is
authenticated and dropped unless it has a valid MAC signature.  This has
protected OpenVPN against a number of OpenSSL vulnerabilities (as well as
generic port-scanning and similar), most notably Heartbleed, where any attempt
to exploit the vuln just bounced off, because unless you have the MAC key you
can't get past even the first hello message.

I started work on an RFC draft for this a while back, but it got shelved
because of conflicts over making it OpenVPN-compatible or not, it shouldn't be
too much work to dig it out and finish it (albeit in a non-OpenVPN-compatible
manner).

Peter.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 8 Jun 2015 12:31:55 +0300

On Mon, Jun 08, 2015 at 04:46:18PM +0800, Bingzheng Wu wrote:
> In TLS v1.3, attackers can generate ClientHello and
> ClientKeyshare messages easily, while the server has to
> consume large amounts of CPU doing asymmetric crypto operations
> to generate ServerKeyshare and ServerCertificateVerify messages.

Note that this type of attack already works in TLS 1.2.

> increase the attacker's cost ?

There is already an issue about this (but given nature of that
issue, it should be discussed on this ML, especially as it
still seems to be open).

> If the server think it's under attack (e.g. >1000 qps), it
> could enable this mode by responding a HelloRetryRequest (or
> a new type) message to the client with a challenge.
> The client receiving the challenge must solve the challenge
> which is expensive in CPU, and continue the handshake by
> carrying the challenge's answer.

One has to be careful that this kind of thing doesn't introduce
security issues. E.g. Proper implementations can not restart
handshake, and repeating yourself is legendary source of bugs.

> For example, server could make the challenge by encrypting an
> random number by a RSA public key (which is short), and send
> the private key (which is long) and cipher text to client.

The usual way things like this are done is via hashes.

TLS13 github issue #9 has link to a ML post describing one scheme:
https://www.ietf.org/mail-archive/web/tls/current/msg11763.html

-Ilari

---

From: "Bingzheng Wu" <[email-masked]>
Date: Mon, 08 Jun 2015 18:59:21 +0800

I talked about TLS level DDOS only, but not TCP level DDOS. I think they focus on different aspects.

I learned about the hash way of challenge from the link in Ilari's mail. It's better than my proposed way indeed. thanks.

> -----Original Message-----
> From: CodesInChaos [mailto:[email-masked]]
> Sent: Monday, June 08, 2015 5:17 PM
> To: Bingzheng Wu
> Cc: tls
> Subject: Re: [TLS] add challenge in TLS v1.3 to prevent DDOS attack?
> 
> Not sure if this is a practical concern. If an attacker has so many computers/IPs
> that IP blacklisting doesn't help anymore (TCP makes IP spoofing difficult), they
> probably could simply flood the victim's connection instead of relying on
> expensive crypto operations for DoS.
> 
> Your proposed proof-of-work doesn't look ideal either, since the cost is fixed at
> a low value. Some variant of hashcash is clearly better.

---

From: "Bingzheng Wu" <[email-masked]>
Date: Mon, 08 Jun 2015 19:05:49 +0800

Thanks for your information. I didn't know this before.
However I don't think this match my original purpose.

The tls-auth requires the client and server have PSK. 
But I want an general anti-DDOS method.
For example, this method could be used by general web browser to visit any
web sites.

Please fix me if I misunderstand the OpenVPN's method.

Thanks,
Bingzheng

> From: Peter Gutmann [mailto:[email-masked]]
> Sent: Monday, June 08, 2015 5:20 PM
> To: Bingzheng Wu; tls
> Subject: RE: [TLS] add challenge in TLS v1.3 to prevent DDOS attack?
> 
> formalise that.  It doesn't really need TLS 1.3 either, since you can do
it in a
> standard extension.  OpenVPN gives it the very misleading name tls-auth,
it's
> just a use of a PSK to MAC incoming packets, so the client-hello is
> generic port-scanning and similar), most notably Heartbleed, where any
> attempt to exploit the vuln just bounced off, because unless you have the
MAC
> key you can't get past even the first hello message.
> 
because
> of conflicts over making it OpenVPN-compatible or not, it shouldn't be too
much
> work to dig it out and finish it (albeit in a non-OpenVPN-compatible
manner).
> Peter.=

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 8 Jun 2015 11:30:50 +0000

>The tls-auth requires the client and server have PSK.

Sure, this is for the situation where you have known clients connecting to a
server (e.g. SCADA devices), not for general-purpose web use where you have an
arbitrary number of unknown clients connecting.  So that's one more note for
the RFC draft, be explicit about the scope...

Peter.

---

From: "Bingzheng Wu" <[email-masked]>
Date: Mon, 08 Jun 2015 19:32:04 +0800

I am sorry that I did not search the list archive thoroughly.
The scheme in your link is what I wanted (and the hash-challenge is better than my propose).

But I have one question still. It's said that this scheme can be implemented as an extension.
If a client who dose not support this extension receives the challenge, what should it do?
Just abort the connection?
Then some servers who provide important services may dare not to enable this scheme, to avoid impacting the users who use TLS client not supporting this extension.

Please fix me if I misunderstand that propose.

Thanks,
Bingzheng

> From: Ilari Liusvaara [mailto:[email-masked]]
> Sent: Monday, June 08, 2015 5:32 PM
> To: Bingzheng Wu
> Cc: tls
> > In TLS v1.3, attackers can generate ClientHello and ClientKeyshare
> > messages easily, while the server has to consume large amounts of CPU
> > doing asymmetric crypto operations to generate ServerKeyshare and
> > ServerCertificateVerify messages.
> 
> There is already an issue about this (but given nature of that issue, it should be
> discussed on this ML, especially as it still seems to be open).
> 
> > If the server think it's under attack (e.g. >1000 qps), it could
> > enable this mode by responding a HelloRetryRequest (or a new type)
> > message to the client with a challenge.
> > The client receiving the challenge must solve the challenge which is
> > expensive in CPU, and continue the handshake by carrying the
> > challenge's answer.
> 
> One has to be careful that this kind of thing doesn't introduce security issues.
> E.g. Proper implementations can not restart handshake, and repeating yourself
> is legendary source of bugs.
> 
> > For example, server could make the challenge by encrypting an random
> > number by a RSA public key (which is short), and send the private key
> > (which is long) and cipher text to client.
>

---

From: Erik Nygren <[email-masked]>
Date: Tue, 9 Jun 2015 19:25:14 -0400

We talked about this some at the TLS interim in Denver last year.
Yoav Nir even wrote up one variation:
https://tools.ietf.org/html/draft-nir-tls-puzzles-00
(and this idea even goes way back to
https://www.usenix.org/legacy/events/sec2001/full_papers/dean/dean.pdf
in 2001).  There was some desire to take an approach and try and get
it to look as close as possible to what DTLS is already doing with
HelloVerifyRequest
to try and reduce the number of different handshake flows.

The primary outcome of the discussion in Denver was a desire to understand
how a client puzzles scheme like this would help over simply doing
intelligent
server-side rate-limiting, especially as the two would likely need to be
used
together.  In cases where a small number of IPs are flooding in
connections,
server-side rate-limiting can be used to defend already today (although it
may
not differentiate between different users behind a CGNAT or proxy).
This then leaves more distributed attacks (eg, large bot nets with many
nodes)
in which case the challenge is to generate puzzles hard enough to slow down
the attackers while not stalling out mobile clients.  Giving the complexity
(and associated risks) involved in adding in this functionality, people
seemed
to want better models or simulations for what attacks it actually helped
with
vs other simpler approaches.

       Erik

On Mon, Jun 8, 2015 at 7:32 AM, Bingzheng Wu <[email-masked]>
wrote:

> Then some servers who provide important services may dare not to enable
> this scheme, to avoid impacting the users who use TLS client not supporting
> this extension.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>