| TLS Working Group | Y. Nir |
| Internet-Draft | Check Point |
| Intended status: Experimental | April 30, 2014 |
| Expires: November 01, 2014 |
Using Client Puzzles to Protect TLS Servers From Denial of Service Attacks
draft-nir-tls-puzzles-00
This document proposes a mechanism for mitigating denial of service (DoS) and distributed denial of service (DDoS) attacks on TLS servers. Attackers are limited in their ability to cause resource waste on the server by requiring proof of work by the client before these CPU resources are expended.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 01, 2014.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
TLS ([TLS]) is vulnerable to a simple denial of service (DoS) attack. Arbitrary hosts on the Internet can begin a TLS handshake with a server. The attacking clients need only generate a valid TLS ClientHello and a valid-looking ClientKeyExchange, both of which require very little computing resources.
To respond, the server has to perform some CPU-intensive operations. Depending on the chosen ciphersuite, the server will need to perform an RSA decryption or a Diffie-Hellman exchange plus a RSA, DSA, or ECDSA signature. With such asymmetric work, it's easy for an attacker or a modestly sized bot-net to overwhelm a server's resources, creating a DoS or distributed DoS (DDoS) attack.
The extension described in this document mitigates this attack, by forcing the attacker to perform some work (a partial break of a hash function) before the server agrees to process the ClientKeyExchange. This has a marked effect on the latency, so Section 4 recommends against using this feature when the server is not under extreme load.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
A supporting client will send a new empty extension in the ClientHello message. This new extension is called client_puzzle.
A supporting server's reply depends on whether the feature is activated or not. It is expected that conforming servers will have an option to set this feature to be unconditionally deactivated and unconditionally activated, but at least the latter will be for testing purposes only. The usual configuration will be to activate the feature dynamically in response to a heavy load which may be a result of an attempt at a DoS attack.
When deactivated, the server MAY either respond with an empty client_puzzle extension in its ServerHello, or it MAY omit the extension entirely. Either way, no further action is required from either client or server. TBD: Should we mandate one or the other?
When activated, the server SHOULD generate a 32-byte value called a Mystery, and send a non-empty client_puzzle extension as described in Section 2.1. This extension is sent in the ServerHello. Exceptions to the SHOULD-level requirement are in Section 5.
A conforming client that has received a non-empty client_puzzle extension MUST respond with one of the following:
When the feature is activated and a puzzle has been sent in the extension, the server MUST NOT process the Certificate or the ClientKeyExchange messages if the PuzzleSolution is missing. In that case, it MUST terminate the connection with a puzzle_error alert. A puzzle_error alert is also used if the solution in the PuzzleSolution message is incorrect.
If the puzzle solution is correct, the server continues the handshake normally.
Client Server
ClientHello(*) -------->
ServerHello(*)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
PuzzleSolution
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
(*) The ClientHello and ServerHello include the client_puzzle
extension to indicate support
The diagram below outlines the protocol structure.
The client_puzzle extension is a ClientHello and ServerHello extension as defined in section 2.3 of [TLS-EXT]. The extension_type field is TBA by IANA.
The format of the non-empty extension is to be added, but it has to include the following fields:
This alert code is to be assigned by IANA. This alert is always fatal.
The format of the PuzzleSolution record is to be added, but it will contain the 32-byte Mystery. The content type is TBA by IANA.
The client finds this value by trying different values for the masked bits in the "masked puzzle" field in the client_puzzle extension.
The client MUST always send an empty client_puzzle extension in the ClientHello.
If no client_puzzle extension is present in the ServerHello, no further action is needed.
If an empty client_puzzle extension is present in the ServerHello, no further action is needed.
If a non-empty client_puzzle extension is present in the ServerHello, the verify that it is properly formatted and that the difficulty level is acceptable. The difficulty level is acceptable if all 2^n possibilities can be tested by the client in a reasonable amount of time. If either check fails, the client MUST terminate the connection with a puzzle_error alert.
The client then proceeds to attempt to solve the puzzle. If the puzzle is unsolvable, the client MUST terminate the connection with a fatal puzzle_error alert.
Having found a correct Mystery value, the client sends that value in a PuzzleSolution message, and proceeds with the rest of the TLS handshake.
Puzzle protection is enabled or disabled depending on load. See Section 4 for considerations.
When disabled, it is acceptable for the client to not send a client_puzzle extension. In this case, the server MUST NOT send a client_puzzle extension.
When disabled, if the client does send an empty client_puzzle extension, the server MAY reply with an empty client_puzzle extension. If the feature is administratively disabled, then the server SHOULD NOT send an empty client_puzzle extension, whereas if it's only disabled because the server is not under load, it SHOULD send the extension.
When puzzles are enabled, but the client did not send a client_puzzle extension, the server MUST terminate the connection with a puzzle_error alert.
When puzzles are enabled and the client has sent an empty client_puzzle extension, the server generates a random 32-byte string called the Mystery. To construct the extension, the server hashes the Mystery, sets a difficulty level (n), and adds the Mystery to the extension data field, clearing the last n bits. The server also stores the Mystery value.
When the client returns a PuzzleSolution handshake message, the server compares the Mystery value to the value in the PuzzleSolution. If they match, or if their SHA2-256 hashes match, processing continues as usual. If not, the server MUST terminate the session with a puzzle_error alert.
[This section needs a lot of expanding]
Not all Clients support this extension, so this protection should only be enabled when the server detects an unusual load that could indicate an attack. Detecting this is beyond the scope of this document.
The difficulty level should be set by balancing the requirement to minimize the latency for legitimate clients and making things difficult for attackers. A good rule of thumb is for taking about 1 second to solve the puzzle. A typical client or bot-net member in 2014 can perform slightly less than a million SHA2-256 hashes per second per core, so setting the difficulty level to n=20 is a good compromise. It should be noted that mobile initiators, especially phones are considerably weaker than that. Implementations should allow administrators to set the difficulty level, and/or be able to set the difficulty level dynamically in response to load.
Note that when this feature is enabled, it causes a latency of about one second. Such a delay may be unnoticeable for SMTP servers, but would be very irritating to browser users. These considerations should be taken into account when determining activation thresholds and difficulty levels.
Clients should set a maximum difficulty level beyond which they won't try to solve the puzzle and log or display a failure message to the administrator or user.
This mechanism is appropriate for TLS. For DTLS, initiating multiple handshakes so as to load the server with memory allocations may be a more attractive attack vector, one that this feature does not protect against. See Appendix A for an alternate design that could be appropriate for DTLS.
To be added
IANA is requested to allocate:
| [TLS] | Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. |
| [TLS-EXT] | Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
This appendix broadly describes an alternate design. I rejected this in favor of the design in the main part of the document, because that one seemed more appropriate for a TCP-based protocol such as TLS.
With this design, the client does not need to indicate support. When the server is under load, it responds to a ClientHello with an alert that carries the puzzle, and terminates the TLS connection. The client then solves the puzzle, and starts a new connection, including the puzzle solution in a ClientHello extension.
Advantages of this alternate design:
Disadvantages of this alternate design:
The challenge above is not insurmountable. It is possible to generate the Mystery in a stateless way by making it depend on client IP address and on a timestamp. Alternatively, the server can allocate state and store the issued Mysteries, deleting them when they are received to prevent re-use, and expiring them after some appropriate time span (at least round-trip time plus the time it takes the slowest client to solve the puzzle).