Patent Publication Number: US-9838423-B2

Title: Perfect forward secrecy distributed denial of service attack defense

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of U.S. patent application Ser. No. 14/586,852, entitled “Perfect Forward Secrecy Distributed Denial of Service Attack Defense,” filed on Dec. 30, 2014, the disclosure of which is incorporated herein by reference in their entirety for all purposes. 
    
    
     TECHNICAL FIELD 
     This disclosure relates generally to computer and network security and, more particularly, to perfect forward secrecy (PFS) distributed denial of service (DDoS) attack defense. 
     BACKGROUND 
     The approaches described in this section could be pursued but are not necessarily approaches that have previously been conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section. 
     PFS is a property of key-agreement protocols ensuring that compromising of a session key derived from long-term keys is impossible even if one of the long-term keys is compromised in the future. By using a key-agreement protocol, two or more parties can agree on the session key in such a way that all parties influence the generated session key. The PFS can be used in the Secure Sockets Layer (SSL) cryptographic protocol. The SSL protocol may use asymmetric cryptography to authenticate the counterparty with whom the protocol is communicating. The asymmetric cryptography is a cryptographic algorithm that requires two separate keys, referred to as a private key and a public key, to encrypt and decrypt data flowing between parties. The private key and the public key can be mathematically linked so that encryption of an encryption key, also referred to as a session key, by one party using the public key allows decryption of the session key by another party using the private key. Therefore, before beginning to exchange information protected by the SSL protocol, a client and a server must securely exchange or agree upon the session key to use when encrypting data flowing between the client and the server. 
     SSL sessions between the client and the server commence with a PFS handshake procedure that includes a process of negotiation that dynamically sets parameters of a communications channel established between the client and the server. Some steps of the handshake procedure may be very expensive by requiring the server to perform time and resource consuming computations to generate a public key for transmission to the client. An attacker may take advantage of such workload on the server and send multiple session requests to the server without any intent to establish a valid session. The attacker can simply terminate the connection after receiving a public key generated by the server and immediately reconnect with a new request. Alternatively, the attacker may respond to the server by sending random numbers instead of generating and encrypting a valid session key based on the received public key. As such actions of the attacker can easily overwhelm the capacity of the server or interrupt proper functioning of the server, they can be used in a denial of service (DoS) attack or, in case of distributed attackers, a Distributed DoS (DDoS) attack on the server. 
     SUMMARY 
     This summary is provided to introduce a selection of concepts in a simplified form that are further described in the Detailed Description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. 
     The present disclosure is related to approaches for mitigating a DoS attack. Specifically, a method for mitigating a DoS attack may commence with receiving, from a client, a request to initiate a secure session between the client and a server. The method may continue with determining whether the client is on a whitelist. Based on a determination that the client is absent from the whitelist, a pre-generated key may be sent to the client. The method may include determining validity of the established secure session. The determination may be performed based on further actions associated with the client. Based on the determination that the secure session is valid, a renegotiation of the secure session may be forced by the server. The method may further include generating, by the server, a new key using a method for securely exchanging cryptographic keys over a public channel. The new key may be sent to the client. 
     According to another approach of the present disclosure, there is provided a system for mitigating a DoS vice attack. The system may comprise at least one processor. The processor may be operable to receive, from a client, a request to initiate a secure session between the client and a server. The processor may be further operable to determine whether the client is on a whitelist. Based on a determination that client is absent from the whitelist, the processor may be operable to send a pre-generated key to the client to establish the secure session. The processor may be further operable to determine, based on further actions associated with the client, validity of the established secure session. Based on the determination that the secure session is valid, the processor may be operable to force a renegotiation of the secure session. The processor may be operable to generate a new key using a method for securely exchanging cryptographic keys over a public channel. Furthermore, the processor may be operable to send the new key to the client. 
     In further example embodiments of the present disclosure, the method operations are stored on a machine-readable medium comprising instructions, which when implemented by one or more processors perform the recited operations. In yet further example embodiments, hardware systems, or devices can be adapted to perform the recited operations. Other features, examples, and embodiments are described below. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Embodiments are illustrated by way of example, and not by limitation, in the figures of the accompanying drawings, in which like references indicate similar elements. 
         FIG. 1  shows an environment within which methods and systems for mitigating a DoS attack can be implemented. 
         FIG. 2  is a schematic diagram of an SSL handshake procedure between a client and a server. 
         FIG. 3  is a process flow diagram showing a method for mitigating a DoS attack. 
         FIG. 4  is a block diagram of a system for mitigating a DoS attack. 
         FIG. 5  shows a diagrammatic representation of a computing device for a machine, within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein can be executed. 
     
    
    
     DETAILED DESCRIPTION 
     The following detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show illustrations in accordance with example embodiments. These example embodiments, which are also referred to herein as “examples,” are described in enough detail to enable those skilled in the art to practice the present subject matter. The embodiments can be combined, other embodiments can be utilized, or structural, logical, and electrical changes can be made without departing from the scope of what is claimed. The following detailed description is therefore not to be taken in a limiting sense, and the scope is defined by the appended claims and their equivalents. In this document, the terms “a” and “an” are used, as is common in patent documents, to include one or more than one. In this document, the term “or” is used to refer to a nonexclusive “or,” such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. 
     The techniques of the embodiments disclosed herein may be implemented using a variety of technologies. For example, the methods described herein may be implemented in software executing on a computer system or in hardware utilizing either a combination of microprocessors or other specially designed application-specific integrated circuits (ASICs), programmable logic devices, or various combinations thereof. In particular, the methods described herein may be implemented by a series of computer-executable instructions residing on a storage medium, such as a disk drive or computer-readable medium. It should be noted that methods disclosed herein can be implemented by a computer (e.g., a desktop computer, tablet computer, laptop computer), game console, handheld gaming device, cellular phone, smart phone, smart television system, and so forth. 
     As outlined in the summary, the embodiments of the present disclosure refer to mitigating a DoS attack. A system for mitigating a DoS attack can be responsible for defending a server against DoS attacks. According to the present disclosure, a secure session can include an SSL session between a client and a server that begins with an exchange of messages, also referred to as an SSL handshake procedure. The client may contact the server by informing the server that the client wants to communicate with the server using the PFS. In other words, the client may send a request for initiating the secure session with the server. The request may include an SSL version number that the client supports, randomly generated data, cipher settings, and other information the server needs in order to establish an SSL session with the client. Providing such data to the server is not very resource-consuming for the client. In response to the request, the server may send an SSL version number supported by the server, randomly generated data, cipher settings, and other information that the client needs to communicate with the server using the SSL. Typically, the server can also send a key exchange message to the client. The key exchange message may include a public key. Because generation of the public key consumes a lot of computational resources of the server, it would be advantageous for the server to ensure that the client is not an attacker with intent to mount a DoS attack on the server. 
     To prevent DoS attacks, the server may investigate validity of the client. For this purpose, the server may determine whether the client is on a whitelist. The whitelist may include a list of trusted clients, for example, clients that have previously established secure sessions with the server. If the client is on the whitelist, the server may continue with the conventional SSL handshake procedure. If, on the other hand, the client is not on the whitelist (i.e. the client is unknown), the server may send a pre-generated key to the client instead of performing the computation of the public key. The pre-generated key may be stored in a database associated with the server. After sending the pre-generated key, the server may monitor the client&#39;s further actions for any suspicious activities. The suspicious activities can include lack of response to the public key received from the server, sending random data in response to the public key instead of generating a premaster key, and repetitively closing and opening connections with the server without responding to the public key. 
     If the server had to generate a new key instead of using the pre-generated key each time a request is received from the client, the capacity of the server could be overwhelmed. However, sending the pre-generated key is not computationally expensive and allows the server to investigate the client prior to establishing a session and, possibly, prevent a DoS attack. 
     If the client demonstrates its validity by sending a premaster key encrypted using the public key received from the server, the server can force a renegotiation of the secure session with the client. More specifically, the server may generate a new public key and send the new public key to the client. According to the conventional SSL handshake procedure, after receiving the new public key, the client may use the public key to encrypt a premaster key generated by the client. The server may receive the premaster key from the client. The server may use a private key of the server to decrypt the premaster key, and then both the server and the client may generate a master key based on the premaster key. Both the client and the server may use the master key to generate a session key, which is a symmetric key used to encrypt and decrypt data exchanged during the SSL secure session between the server and the client. Therefore, both the client and the server may generate the session key and encrypt the session key using the public key. The client may decrypt the session key received from the server using a private key of the client. Similarly, the server may decrypt the session key received from the client using the private key of the server. Therefore, no decryption key allowing decrypting data flowing between the client and the server is going across the wire. 
     Referring now to the drawings,  FIG. 1  illustrates an environment  100  within which methods and systems for mitigating a DoS attack can be implemented. The environment  100  may include a network  110 , a client  120 , a server  130 , and a system  400  for mitigating a DoS attack. The client  120  may include a network machine or a network resource that sends a request  140  for initiating a secure session to the server  130 . The client  120  may communicate with the server  130  using the network  110 . 
     The network  110  may include the Internet or any other network capable of communicating data between devices. Suitable networks may include or interface with any one or more of, for instance, a local intranet, a Personal Area Network, a LAN (Local Area Network), a WAN (Wide Area Network), a Metropolitan Area Network, a virtual private network, a storage area network, a frame relay connection, an Advanced Intelligent Network connection, a synchronous optical network connection, a digital T1, T3, E1 or E3 line, Digital Data Service connection, Digital Subscriber Line connection, an Ethernet connection, an Integrated Services Digital Network line, a dial-up port such as a V.90, V.34 or V.34 bis analog modem connection, a cable modem, an Asynchronous Transfer Mode connection, or a Fiber Distributed Data Interface or Copper Distributed Data Interface connection. Furthermore, communications may also include links to any of a variety of wireless networks, including Wireless Application Protocol, General Packet Radio Service, Global System for Mobile Communication, Code Division Multiple Access or Time Division Multiple Access, cellular phone networks, Global Positioning System, cellular digital packet data, Research in Motion, Limited duplex paging network, Bluetooth radio, or an IEEE 802.11-based radio frequency network. The network  110  can further include or interface with any one or more of an RS-232 serial connection, an IEEE-1394 (Firewire) connection, a Fiber Channel connection, an IrDA (infrared) port, a Small Computer Systems Interface connection, a USB (Universal Serial Bus) connection or other wired or wireless, digital or analog interface or connection, mesh or Digi® networking. The network  110  may include a network of data processing nodes that are interconnected for the purpose of data communication. 
     In response to receiving the request  140  for initiating a secure session with the server  130 , the system  400  may initiate mitigating a DoS attack as described in further detail below. 
       FIG. 2  is a schematic diagram of an SSL handshake procedure  200  between a client and a server, according to an example embodiment. The SSL handshake procedure  200  may commence with a ClientHello message  210  sent by the client  120  to the server  130 . The ClientHello message  210  may include data related to the highest SSL protocol version the client  120  supports, a random number, a list of suggested cipher suites, compression methods, and so forth. The server  130  may respond with a ServerHello message  220 . The ServerHello message  220  may include data related to the chosen protocol version, a random number, cipher suite, compression method from the choices offered by the client  120 , and so forth. The server  130  may also send a Certificate message  230 . 
     The server may further send a ServerKeyExchange message  240 . The ServerKeyExchange message  240  may include a public key. The public key may be generated using key-agreement protocols, for example, by using ephemeral (transient) Diffie-Hellman (DHE) Key Exchange and ephemeral Elliptic Curve Diffie-Hellman (ECDHE) Key Exchange. The server  130  may further send a ServerHelloDone message  250  to the client to indicate that the server  130  has finished the handshake negotiation process. 
     The client  120  may send a ClientKeyExchange message  260 , which may contain a premaster key or a public key depending on the selected cipher. The premaster key may be encrypted by the client  120  using the public key received from the server  130  in the ServerKeyExchange message  240 . 
     The SSL handshake procedure  200  can also include sending a ChangeCipherSpec record  270  by the client  120 , in which the client  120  informs the server  130  that any further data received from the client  120  will be authenticated. 
     Arrows  280  and  290  show steps of the SSL handshake procedure  200  at which the server  130  may be exposed to attacks. For example, generating the public key to be sent in the ServerKeyExchange message  240  may be a resource-consuming process for the server  130 . However, if the client  120  terminates the connection after receiving the ServerKeyExchange message  240 , the resources of the server  130  for computation of the public key can be wasted. Additionally, the ClientKeyExchange message  260  may comprise random numbers instead of the premaster key generated by using the public key. The server  130  may spend time for computation of the erroneous premaster key received from the client  120  and, thus, may be depleted of resources. 
       FIG. 3  shows a process flow diagram of a method  300  for mitigating a DoS attack, according to an example embodiment. In some embodiments, the operations may be combined, performed in parallel, or performed in a different order. The method  300  may also include additional or fewer operations than those illustrated. The method  300  may be performed by processing logic that may comprise hardware (e.g., decision making logic, dedicated logic, programmable logic, and microcode), software (such as software run on a general-purpose computer system or a dedicated machine), or a combination of both. 
     The method  300  may commence with receiving, from a client, a request to initiate a secure session between the client and a server at operation  302 . Receiving of the request from the client can initiate a handshake phase being performed before initiating the secure session. The request may include an indication and the secure session between the client and the server may include a PFS cipher. 
     The method  300  may continue with determining whether the client is on a whitelist at operation  304 . In response to the determination that client is absent from the whitelist, a pre-generated key may be sent to the client at operation  306 . 
     The method  300  may further include determining validity of the established secure session at operation  308 . The determination may be performed based on further actions associated with the client. In an example embodiment, the further actions associated with the client include at least one of the following: closing the connection by the client after receiving the pre-generated key from the server, absence of further data from the client after receiving the pre-generated key, failure to finish the handshake phase within a predetermined time frame, providing, by the client, data without calculating a pre-master key, and so forth. The calculation may include encrypting the pre-master key with the pre-generated key. 
     In response to the determination that the secure session is valid, a renegotiation of the secure session may be forced at operation  310 . The method  300  may further include operation  312 , at which a new key may be generated using a method for securely exchanging cryptographic keys over a public channel. In an example embodiment, the method for securely exchanging cryptographic keys over a public channel includes one or more of the following: DHE Key Exchange and ECDHE Key Exchange. The new key may include a public key of the secure session. Generation of the new key may include the steps of creating long random numbers, taking a primitive root of the generated long random numbers, and performing modulo operations. The modulo operations can use the multiplicative group of integers modulo p, where p is prime, and g is a primitive root modulo p, and where (g a ) b =(g b ) a =mod p; a and b being private keys of the client and the server, respectively. 
     At operation  314 , the new key may be sent to the client. The method  300  may further include adding the client to the whitelist. Alternatively, based on a determination that client is present on the whitelist, the established secure session may be determined to be valid and the renegotiation of the secure session may be forced. 
     In some embodiments, based on the further actions associated with the client, the method  300  may include determining that the established secure session is invalid. In response to the determination that the secure session is invalid, the client can be suspected of taking part in a DDoS attack. Based on the identification, initiation of the secure session may be denied. Additionally, the client may be added to a blacklist. Any requests from clients on the blacklist may be automatically denied by the server without performing a SSL handshaking procedure. 
       FIG. 4  shows a block diagram illustrating various modules of an example system  400  for mitigating a DDoS attack. Specifically, the system  400  may include at least one processor  402 . The processor  402  may be operable to receive, from a client, a request to initiate a secure session between the client and a server. In an example embodiment, the secure session includes a PFS cipher. The processor  402  may be further operable to determine whether the client is on a whitelist. 
     In response to the determination that client is absent from the whitelist, the processor  402  may be operable to send a pre-generated key to the client to establish a secure session. The processor  402  may be further operable to determine, based on further actions associated with the client, validity of the established secure session. In an example embodiment, the further actions associated with the client include one or more of the following: closing the connection by the client after receiving the pre-generated key from the server, lack of further data from the client after receiving the pre-generated key, failure to finish the handshake phase within a predetermined time frame, providing, by the client, data without calculating a pre-master key, and so forth. The calculation may include encrypting the pre-master key with the pre-generated key. 
     In response to the determination that the secure session is valid, the processor  402  may be operable to force a renegotiation of the secure session. 
     The processor  402  may be operable to generate a new key using one of various methods for securely exchanging cryptographic keys over a public channel. In an example embodiment, the method for securely exchanging cryptographic keys over a public channel includes at least one of the following: DHE Key Exchange and ECDHE Key Exchange. 
     Furthermore, the processor  402  may be operable to send the new key to the client. The processor  402  may add the client to the whitelist. Optionally, in response to the determination that client is on the whitelist, the processor  402  may be operable to determine that the established secure session is valid. 
     Optionally, based on the further actions associated with the client, the processor  402  may be operable to determine that the established secure session is invalid. In response to the determination that the secure session is invalid, the processor  402  may determine that the request is part of a DoS attack. Based on the determination, the processor  402  may be operable to deny initiation of the secure session and terminate the connection with the client. Additionally, based on the identification, the processor  402  may be operable to add the client to a blacklist. 
     The system  400  may further comprise a database  404  in communication with the processor  402 . The database  404  may store computer-readable instructions for execution by the processor  402 . 
       FIG. 5  illustrates an example computer system  500  that may be used to implement embodiments of the present disclosure. The computer system  500  may serve as a computing device for a machine, within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein can be executed. The computer system  500  can be implemented in the contexts of the likes of computing systems, networks, servers, or combinations thereof. The computer system  500  includes one or more processor units  510  and main memory  520 . Main memory  520  stores, in part, instructions and data for execution by processor  510 . Main memory  520  stores the executable code when in operation. The computer system  500  further includes a mass data storage  530 , portable storage medium drive(s)  540 , output devices  550 , user input devices  560 , a graphics display system  570 , and peripheral devices  580 . The methods may be implemented in software that is cloud-based. 
     The components shown in  FIG. 5  are depicted as being connected via a single bus  590 . The components may be connected through one or more data transport means. Processor unit  510  and main memory  520  are connected via a local microprocessor bus, and mass data storage  530 , peripheral device(s)  580 , portable storage device  540 , and graphics display system  570  are connected via one or more I/O buses. 
     Mass data storage  530 , which can be implemented with a magnetic disk drive, solid state drive, or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor unit  510 . Mass data storage  530  stores the system software for implementing embodiments of the present disclosure for purposes of loading that software into main memory  520 . 
     Portable storage device  540  operates in conjunction with a portable non-volatile storage medium, such as a floppy disk, CD, DVD, or USB storage device, to input and output data and code to and from the computer system  500 . The system software for implementing embodiments of the present disclosure is stored on such a portable medium and input to the computer system  500  via the portable storage device  540 . 
     User input devices  560  provide a portion of a user interface. User input devices  560  include one or more microphones, an alphanumeric keypad, such as a keyboard, for inputting alphanumeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys. User input devices  560  can also include a touchscreen. Additionally, the computer system  500  includes output devices  550 . Suitable output devices include speakers, printers, network interfaces, and monitors. 
     Graphics display system  570  includes a liquid crystal display or other suitable display device. Graphics display system  570  receives textual and graphical information and processes the information for output to the display device. 
     Peripheral devices  580  may include any type of computer support device to add additional functionality to the computer system. 
     The components provided in the computer system  500  of  FIG. 5  are those typically found in computer systems that may be suitable for use with embodiments of the present disclosure and are intended to represent a broad category of such computer components that are well known in the art. Thus, the computer system  500  can be a personal computer, handheld computing system, telephone, mobile computing system, workstation, tablet, phablet, mobile phone, server, minicomputer, mainframe computer, or any other computing system. The computer may also include different bus configurations, networked platforms, multi-processor platforms, and the like. Various operating systems may be used including UNIX, LINUX, WINDOWS, MAC OS, PALM OS, ANDROID, IOS, QNX, and other suitable operating systems. 
     It is noteworthy that any hardware platform suitable for performing the processing described herein is suitable for use with the embodiments provided herein. Computer-readable storage media refer to any medium or media that participate in providing instructions to a central processing unit, a processor, a microcontroller, or the like. Such media may take forms including, but not limited to, non-volatile and volatile media such as optical or magnetic disks and dynamic memory, respectively. Common forms of computer-readable storage media include a floppy disk, a flexible disk, a hard disk, magnetic tape, any other magnetic storage medium, a Compact Disk Read Only Memory (CD-ROM) disk, DVD, Blu-ray disc, any other optical storage medium, RAM, Programmable Read-Only Memory, Erasable Programmable Read-Only Memory, Electronically Erasable Programmable Read-Only Memory, flash memory, and/or any other memory chip, module, or cartridge. 
     In some embodiments, the computer system  500  may be implemented as a cloud-based computing environment, such as a virtual machine operating within a computing cloud. In other embodiments, the computer system  500  may itself include a cloud-based computing environment, where the functionalities of the computer system  500  are executed in a distributed fashion. Thus, the computer system  500 , when configured as a computing cloud, may include pluralities of computing devices in various forms, as will be described in greater detail below. 
     In general, a cloud-based computing environment is a resource that typically combines the computational power of a large grouping of processors (such as within web servers) and/or that combines the storage capacity of a large grouping of computer memories or storage devices. Systems that provide cloud-based resources may be utilized exclusively by their owners or such systems may be accessible to outside users who deploy applications within the computing infrastructure to obtain the benefit of large computational or storage resources. 
     The cloud may be formed, for example, by a network of web servers that comprise a plurality of computing devices, such as the computer system  500 , with each server (or at least a plurality thereof) providing processor and/or storage resources. These servers may manage workloads provided by multiple users (e.g., cloud resource customers or other users). Typically, each user places workload demands upon the cloud that vary in real-time, sometimes dramatically. The nature and extent of these variations typically depends on the type of business associated with the user. 
     Thus, methods and systems for mitigating a DoS attack have been described. Although embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes can be made to these example embodiments without departing from the broader spirit and scope of the present application. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.