Information processing system, estimation method and program

Abstract

To make it possible to estimate the use of a suspicious digital certificate without decrypting encrypted communication even in the case of encrypted communication in which the digital certificate is encrypted.SOLUTION: An information processing system includes: a data acquisition unit 21 that acquires data related to encrypted communication performed between a first terminal and a second terminal connected to a network; and an estimation unit 25 that, of the acquired data, if an encrypted message sent from the second terminal to the first terminal to establish the encrypted communication satisfies a predetermined condition regarding data size, estimates that the encrypted message includes a suspicious digital certificate related to the second terminal.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present disclosure relates to a technique for detecting suspicious use of digital certificates. [Background technology]

[0002] Conventionally, an information processing device has been proposed that includes a communication acquisition unit that acquires data related to communication between a first terminal and a second terminal connected to a network before the data reaches the other terminal; a protocol analysis unit that analyzes the communication protocol related to the acquired data to identify a session establishment message contained in the data, the session establishment message including an electronic certificate of the communication partner in the session to be concealed; a certificate extraction unit that extracts the electronic certificate from the identified session establishment message; an inspection unit that verifies the legitimacy of the extracted electronic certificate and the communication partner in the session; and an identification information extraction unit that extracts identification information of the communication partner from data acquired by the communication acquisition unit that is transmitted and received between the first terminal and the second terminal before the transmission and reception of the session establishment message, and the inspection unit verifies the legitimacy of the communication partner in the session by comparing the identification information of the communication partner extracted by the identification information extraction unit with target server information contained in the electronic certificate (see Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6084278 Summary of the Invention [Problem to be solved by the invention]

[0004] Conventionally, in encrypted communications such as SSL (Secure Sockets Layer) / TLS (Transport Layer Security), a method of inspecting the electronic certificate of the communication partner has been used to detect suspicious communications by attackers. With this method, for example, if the inspection results in the electronic certificate being inspected being a self-signed certificate (a so-called "self-signed certificate"), the communication using that electronic certificate is detected as suspicious.

[0005] However, in TLS1.3, an encryption technology that has become increasingly popular in recent years, the number of parameters (handshake parameters) that are encrypted when establishing a session has increased compared to previous encryption technologies such as TLS1.2, and digital certificates are also encrypted and transferred in the same way as other parameters. In encrypted communications in which digital certificates are encrypted in this way, it is possible to decrypt the encrypted communications and then analyze them, but this poses a problem in that it increases the burden on security measures, such as requiring the introduction of expensive equipment to decrypt the encrypted communications.

[0006] In view of the above-mentioned problems, the present disclosure aims to estimate the use of a suspicious electronic certificate without decrypting the encrypted communication, even in the case of encrypted communication in which the electronic certificate is encrypted. [Means for solving the problem]

[0007] An example of the present disclosure is an information processing system including: a data acquisition means for acquiring data related to encrypted communication between a first terminal and a second terminal connected to a network; and an estimation means for estimating that, if an encrypted message sent from the second terminal to the first terminal to establish the encrypted communication among the acquired data satisfies a predetermined condition related to data size, the encrypted message contains a suspicious electronic certificate related to the second terminal.

[0008] The present disclosure can be understood as an information processing device, a system, a method executed by a computer, or a program executed by a computer. The present disclosure can also be understood as such a program recorded on a recording medium readable by a computer or other device, machine, etc. Here, a recording medium readable by a computer, etc. refers to a recording medium that stores information such as data and programs by electrical, magnetic, optical, mechanical, or chemical action and can be read by a computer, etc. [Effects of the Invention]

[0009] According to the present disclosure, even in the case of encrypted communication in which a digital certificate is encrypted, it is possible to estimate the use of a suspicious digital certificate without decrypting the encrypted communication. [Brief explanation of the drawings]

[0010] [Figure 1] 1 is a schematic diagram illustrating a configuration of a system according to a first embodiment. [Figure 2] FIG. 1 is a diagram illustrating a hardware configuration of a system according to a first embodiment. [Figure 3] 1 is a diagram illustrating an outline of a functional configuration of a network monitoring device according to a first embodiment. [Figure 4] FIG. 1 is a sequence diagram showing the flow of a handshake in conventional TLS1.2. [Figure 5] FIG. 2 is a sequence diagram showing the flow of a handshake in TLS1.3 according to the first embodiment. [Figure 6] 1 is a flowchart showing an outline of a flow of data processing according to the first embodiment. [Figure 7] 10 is a flowchart showing an outline of the flow of an estimation process according to the first embodiment. [Figure 8] FIG. 10 is a diagram illustrating an outline of the functional configuration of a network monitoring device according to a second embodiment. [Figure 9] 10 is a flowchart showing an outline of the flow of data processing according to the second embodiment. [Figure 10] FIG. 10 is a diagram illustrating an outline of the functional configuration of a network monitoring device according to a third embodiment. [Figure 11] 10 is a flowchart showing an outline of the flow of data processing according to the third embodiment. [Figure 12] FIG. 10 is a schematic diagram illustrating a configuration of a system according to a fifth embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, embodiments of an information processing system, an information processing device, a method, and a program according to the present disclosure will be described with reference to the drawings. However, the embodiments described below are merely examples, and the information processing system, the information processing device, the method, and the program according to the present disclosure are not limited to the specific configurations described below. In implementing the present disclosure, a specific configuration according to the embodiment may be appropriately adopted, and various improvements and modifications may be made.

[0012] [First embodiment] In this embodiment, an embodiment will be described in which an information processing system, an information processing device, a method, and a program according to the present disclosure are implemented in a system for monitoring a network. However, the information processing system, the information processing device, the method, and the program according to the present disclosure can be widely used as a technology for estimating whether or not a digital certificate is suspicious, and the application of the present disclosure is not limited to the examples shown in the embodiment. Note that in this embodiment and other embodiments described later, a "suspicious digital certificate" refers to a digital certificate that is questionable as to whether it is a legitimate digital certificate.

[0013] <System configuration> FIG. 1 is a schematic diagram showing the configuration of a system according to this embodiment. The system 9 according to this embodiment includes one or more client terminal devices 8, a network monitoring device 1 for monitoring communications related to the client terminal devices 8, a network segment 2 to which the client terminal devices 8 are connected, a router 3, a switch 4, and one or more server devices 7. The client terminal devices 8 in the network segment 2 can communicate with various server devices 7 connected in remote locations via the Internet or a wide area network via a proxy (proxy server) or a router (router 3 in the example of FIG. 1). In this embodiment, the network monitoring device 1 is connected between the proxy or router (router 3 in the example of FIG. 1) and an upper-level switch (switching hub), router, or gateway (switch 4 in the example of FIG. 1) in the network segment 2, thereby acquiring packets, frames, and the like passing through the proxy or router. In the system configuration shown in FIG. 1, the network monitoring device 1 operates in an inline mode, forwarding acquired packets that do not need to be blocked.

[0014] 2 is a diagram showing the hardware configuration of a system according to this embodiment. The network monitoring device 1 is a device for monitoring communications between a client terminal device 8 and a server device 7. In this embodiment, the network monitoring device 1 acquires data transmitted and received between the client terminal device 8 and the server device 7, and by analyzing the acquired data, estimates whether a suspicious electronic certificate (server certificate) is being used in the encrypted communications between the client terminal device 8 and the server device 7.

[0015] The network monitoring device 1 is a computer including a central processing unit (CPU) 11, a read-only memory (ROM) 12, a random access memory (RAM) 13, a storage device 14 such as an electrically erasable and programmable read-only memory (EEPROM) or a hard disk drive (HDD), and a communication unit 15 such as a network interface card (NIC). However, the specific hardware configuration of the network monitoring device 1 may be omitted, replaced, or added as appropriate depending on the embodiment. Furthermore, the network monitoring device 1 is not limited to a device consisting of a single housing. The network monitoring device 1 may be realized by multiple devices using so-called cloud or distributed computing technology. The network monitoring device 1 may also be included in an L2 bridge, an L3 router, a network address translation (NAT) device, a switch, or a proxy.

[0016] The server device 7 is a computer for providing various services to users. The server device 7 is a computer equipped with a CPU, ROM, RAM, a storage device, a communication unit, etc. (not shown). However, the specific hardware configuration of the server device 7 can be omitted, replaced, or added as appropriate depending on the embodiment. Furthermore, the server device 7 is not limited to a device consisting of a single housing. The server device 7 may be realized by multiple devices using so-called cloud or distributed computing technology, etc.

[0017] The client terminal devices 8 are computers used by users, and the users use various services provided by the server device 7 via these client terminal devices 8. The client terminal devices 8 are computers equipped with a CPU, ROM, RAM, storage devices, communication units, input devices, output devices, etc. (not shown). However, the specific hardware configuration of the client terminal devices 8 can be omitted, replaced, or added as appropriate depending on the embodiment. Furthermore, the client terminal devices 8 are not limited to devices consisting of a single housing. The client terminal devices 8 may be realized by multiple devices using so-called cloud or distributed computing technology, etc.

[0018] FIG. 3 is a diagram illustrating an outline of the functional configuration of a network monitoring device (information processing system) according to this embodiment. Note that FIG. 3 does not illustrate components other than the network monitoring device 1 (such as the router 3, switch 4, server device 7, and client terminal device 8). The network monitoring device 1 functions as a device including a data acquisition unit 21, a protocol determination unit 22, a session resumption determination unit 23, an identification unit 24, and an estimation unit 25, by loading a program stored in a storage device 14 into a RAM 13 and executing it with a CPU 11, thereby controlling the various hardware components included in the network monitoring device 1. Note that in this embodiment and other embodiments described below, the functions of the network monitoring device 1 are executed by the CPU 11, which is a general-purpose processor. However, some or all of these functions may be executed by one or more dedicated processors. Furthermore, the functional units included in the network monitoring device 1 are not limited to being implemented in a device (the device) consisting of a single housing, but may be implemented remotely and / or distributedly (for example, on the cloud).

[0019] The data acquisition unit 21 acquires data transmitted and received between the server device 7 and the client terminal device 8 connected to the network. The data acquisition unit 21 includes a packet receiving unit 21A and a packet assembling unit 21B. The packet receiving unit 21A receives a plurality of packets transmitted and received between the server device 7 and the client terminal device 8 before they reach their destination. If the packets received by the packet receiving unit 21A are packets that were fragmented (divided) when they were sent, the packet assembling unit 21B assembles (reconstructs) the divided packets into the original packet by referring to the headers of the packets, etc.

[0020] For example, when a packet is divided into multiple packets during transmission, the headers of each divided packet contain the same identification number and information indicating which part of the original packet each packet corresponds to, and the packet assembler 21B assembles the packets based on this information. The packet assembly process is performed for each communication flow (session). A communication flow is a unit that indicates a series of communications between two nodes from the start to the end of a session. Specifically, packets with the same attributes, such as the source IP address, destination IP address, source port number, destination port number, and protocol, are identified as the same communication flow. Therefore, communication flows are identified by referring to the packet headers. As described above, the data acquirer 21 acquires data (TLS messages) transmitted and received between the server device 7 and the client terminal device 8.

[0021] The protocol determination unit 22 determines the protocol of the encrypted communication performed between the server device 7 and the client terminal device 8. In this embodiment, the protocol determination unit 22 determines whether the protocol of the encrypted communication related to the acquired data is TLS1.3, which is an encrypted communication protocol that encrypts a digital certificate. This protocol determination process is performed by referring to messages (hereinafter referred to as "handshake messages") sent and received in a handshake that is performed prior to the encrypted communication in order to establish the encrypted communication.

[0022] In this embodiment, protocol determination unit 22 determines the protocol by referring to a ClientHello message (hereinafter referred to as "ClientHello") and a ServerHello message (hereinafter referred to as "ServerHello"), which are unencrypted handshake messages among the TLS messages acquired by data acquisition unit 21. Specifically, protocol determination unit 22 refers to "supported_version" in the "extension" field in ClientHello and ServerHello, and if each "supported_version" contains information indicating TLS1.3, determines that the protocol of the encrypted communication established by the handshake message is TLS1.3.

[0023] In this embodiment, if the above-mentioned judgment process determines that the protocol for the encrypted communication between the server device 7 and the client terminal device 8 is a specified encrypted communication protocol (TLS1.3), the estimation process described below (process of estimating whether a suspicious certificate is being used) is performed.

[0024] In this embodiment, as described above, when determining whether communication is encrypted using TLS 1.3, ClientHello and ServerHello are referenced, but this is not limited to this example as long as it is possible to determine whether communication is encrypted using TLS 1.3. Therefore, for example, only one of ClientHello and ServerHello may be referenced. Also, in this embodiment, as described above, the encryption protocol to be subjected to the estimation process described below is TLS 1.3, but any other protocol may be used as long as it encrypts a digital certificate.

[0025] The session resumption determination unit 23 determines whether the encrypted communication between the server device 7 and the client terminal device 8 is communication established by full negotiation, i.e., whether it is communication established by resuming a session (session resumption sequence). For example, in the case of TLS1.3, by resuming a session using a PSK (Pre-Shared Key), it is possible to establish a new connection (encrypted communication) without fully executing a handshake. When resuming a session using this PSK, it is not necessary to send a digital certificate in the handshake, and in this case, the digital certificate is not included in the handshake message. Therefore, in this embodiment, it is determined whether a PSK is used when establishing encrypted communication, and the estimation process described below is performed only when a PSK is not used (when the session is not resumed), i.e., when full negotiation is performed (when a session is established).

[0026] In this embodiment, session resumption determination unit 23 determines whether full negotiation is required by referring to a handshake message transmitted and received between server device 7 and client terminal device 8. For example, session resumption determination unit 23 refers to ClientHello, which is a message related to a session resumption request, and determines that the encrypted communication established by the handshake message is communication established by full negotiation if "pre_shared_key" does not exist in the "extension" field in ClientHello, or if "pre_shared_key" exists but its data length is zero.

[0027] The identification unit 24 identifies handshake messages transmitted and received between the server device 7 and the client terminal device 8 from the data acquired by the data acquisition unit 21. In particular, the identification unit 24 identifies encrypted handshake messages transmitted from the server device 7 to the client terminal device 8, which may include the digital certificate of the server device 7. In the case of TLS1.3, all messages after ServerHello are encrypted, so it is difficult to identify which TLS message includes the digital certificate, for example, from the packet header. Below, the differences between the handshakes (negotiations to start encrypted communication (TLS connection)) between TLS1.2 and TLS1.3 will be explained.

[0028] Figure 4 is a sequence diagram showing the flow of a handshake in conventional TLS 1.2. Figure 4 shows TLS messages exchanged between a server and a client in a handshake in TLS 1.2. Also, in Figure 4, arrows for encrypted messages are indicated by dashed lines. As shown in Figure 4, in TLS 1.2, a "ServerCertificate" message containing a server certificate (digital certificate) is sent to the client without encryption. Therefore, it is possible to identify whether a message contains a digital certificate by referring to the TLS header of a received message (packet). Specifically, it is possible to identify whether a message contains a digital certificate by referring to the "Content Type (Handshake Type)" in the TLS header, which indicates the type of data stored in the packet payload (TLS payload).

[0029] FIG. 5 is a sequence diagram showing the flow of a handshake in TLS1.3 according to this embodiment. While FIG. 5 shows TLS messages exchanged between a server and a client in a handshake in TLS1.3, TLS messages not shown in FIG. 5 may also be included. Also in FIG. 5, arrows representing encrypted messages are indicated by dashed lines. As shown in FIG. 5, in TLS1.3, a "Certificate" message containing a digital certificate is encrypted before being sent to the client. Therefore, it is difficult to determine whether a message contains a digital certificate by referring to the TLS header of a received message (packet). Specifically, even though the message is related to a handshake (Certificate), the "Content Type (Handshake Type)" in the TLS header indicates application data (encrypted data), making it difficult to identify the server certificate from the TLS header.

[0030] Therefore, in this embodiment, the encrypted handshake messages sent from the server device 7 to the client terminal device 8 are identified based on the order of messages in the handshake messages when establishing encrypted communication. Then, it can be estimated that at least one of the identified handshake messages contains a message (Certificate) that includes a digital certificate.

[0031] As shown in Fig. 5, in TLS1.3, after ServerHello, the server sends various TLS messages (handshake messages) including a "Certificate" message to the client, and then the client sends a "Finished" message. Note that the message sent from the client is not limited to the "Finished" message, and an "Alert" message or the like may be sent to the server depending on the situation. Therefore, the identification unit 24 can identify the encrypted message sent and received between the time ServerHello is sent and the time data (TCP packets) is sent from the client as an encrypted handshake message (a TLS message that may include a digital certificate) sent from server device 7 to client terminal device 8.

[0032] The estimation unit 25 estimates whether a message contains a suspicious digital certificate. In this embodiment, the estimation unit 25 estimates whether a message contains a suspicious digital certificate based on the data size of the message. For example, the estimation unit 25 (1) estimates whether a message contains a digital certificate based on the data size of the encrypted message, and then (2) estimates whether the digital certificate included in the estimated message is suspicious (whether the message contains a suspicious digital certificate) based on the estimated data size of the message. The estimation methods (1) and (2) are described below.

[0033] <(1) Estimation of message containing digital certificate> Typically, among the encrypted handshake messages sent from the server device 7, messages other than the Certificate message have smaller data sizes than the Certificate message. Therefore, among the encrypted messages identified by the identification unit 24, it is possible to estimate that a message exceeding a predetermined data size (second threshold) is a message that includes a digital certificate. For example, if the data size of the encrypted message identified by the identification unit 24 exceeds 400 bytes, the estimation unit 25 estimates that the encrypted message includes a digital certificate. Note that the second threshold is not limited to 400 bytes and can be set to any value. The data size of the encrypted message can be obtained by referring to "Length" in the TLS header, which indicates the length of the TLS payload.

[0034] <(2) Inference as to whether the digital certificate is suspicious> Generally, fraudulent server certificates, such as self-signed certificates (self-signed certificates), tend to contain less information and have a smaller data size than legitimate server certificates. Focusing on this characteristic, it is possible to estimate that, among encrypted messages exceeding the second threshold described above, a message that is less than a predetermined data size (first threshold) is a message containing a suspicious digital certificate. For example, if the data size of an encrypted message identified by the identification unit 24 is greater than 400 bytes but less than 1200 bytes, the estimation unit 25 estimates that the encrypted message contains a suspicious digital certificate. The first threshold is not limited to 1200 bytes and can be set to any value. The data size of the encrypted message can be obtained by referencing the "Length" in the TLS header, as described above.

[0035] As described above, when the encrypted message identified by the identification unit 24 satisfies a predetermined condition related to data size, the estimation unit 25 estimates that the encrypted message contains a suspicious digital certificate. In the above example, the predetermined condition related to data size is that the data size of the encrypted message is within a predetermined range (exceeding the second threshold and being less than the first threshold). However, the predetermined condition related to data size is not limited to the above example, and may be, for example, that the data size of the encrypted message is a predetermined size (e.g., 1000 bytes).

[0036] <Processing flow> Next, the flow of processing executed by the network monitoring device (information processing system) according to this embodiment will be described. Note that the specific content and processing order of the processing described below are an example for implementing the present disclosure. The specific content and processing order may be selected as appropriate depending on the embodiment of the present disclosure.

[0037] 6 is a flowchart showing an outline of the flow of data processing according to this embodiment. The processing shown in this flowchart is initiated when a ClientHello and a ServerHello are acquired as a result of packets being received and assembled by the data acquisition unit 21 in the network monitoring device 1. In other words, the processing shown in this flowchart is executed for each negotiation. Note that the "ClientHello" and "ServerHello" used in the following explanation (the explanation of FIG. 6) refer to the ClientHello and ServerHello that triggered the start of this flowchart.

[0038] In step S101, it is determined whether the protocol of the encrypted communication performed between the server device 7 and the client terminal device 8 is TLS1.3. Protocol determination unit 22 determines whether the encryption protocol is TLS1.3 by referring to ClientHello and ServerHello ("supported_version"). If it is determined that the protocol of the encrypted communication performed between the server device 7 and the client terminal device 8 is TLS1.3 (YES in step S101), the process proceeds to step S103. On the other hand, if it is determined that the protocol is not TLS1.3 (NO in step S101), estimation processing is not performed, and the process shown in this flowchart ends.

[0039] In step S103, it is determined whether the encrypted communication between the server device 7 and the client terminal device 8 is communication established by full negotiation (whether it is not communication related to session resumption). The session resumption determination unit 23 determines whether full negotiation will be performed by referring to the ClientHello ("pre_shared_key"). If it is determined that the encrypted communication between the server device 7 and the client terminal device 8 is communication established by full negotiation (YES in step S103), the process proceeds to step S106. On the other hand, if it is determined that full negotiation will not be performed (NO in step S103), estimation processing is not performed, and the process shown in this flowchart ends. Note that steps S101 and S103 can be performed in any order.

[0040] In step S106, an estimation process is performed on the TLS message (TLS record) following the ClientHello and ServerHello. Details of the estimation process will be described later with reference to Fig. 7. Thereafter, the process shown in this flowchart ends.

[0041] Fig. 7 is a flowchart showing an outline of the flow of estimation processing according to this embodiment. The processing shown in this flowchart is started when full negotiation is determined in step S103 in Fig. 6. Note that "ClientHello" and "ServerHello" used in the following explanation (explanation of Fig. 7) refer to the ClientHello and ServerHello that triggered the start of the flowchart shown in Fig. 6.

[0042] In step S201, data is acquired that is transmitted and received between server device 7 and client terminal device 8. Data acquisition unit 21 acquires the packet (TLS message) that follows ServerHello. Thereafter, the process proceeds to step S202.

[0043] In step S202, it is determined whether the acquired data is data (TCP packet) transmitted from the client terminal device 8 to the server device 7. The identification unit 24 determines whether the acquired packet is a packet transmitted from the client terminal device 8 to the server device 7 by referring to the IP header of the packet acquired in step S201, etc. If it is determined that the acquired packet is a packet transmitted from the client terminal device 8 to the server device 7 (YES in step S202), the encrypted handshake message has already been inspected, and therefore the processing shown in this flowchart ends. On the other hand, if it is determined that the acquired packet is not a packet transmitted from the client terminal device 8 to the server device 7 (NO in step S202), the processing proceeds to step S203.

[0044] In step S203, it is determined whether the acquired data is application data (encrypted data) transmitted from the server device 7 to the client terminal device 8. The identification unit 24 refers to the header (TLS header) of the packet acquired in step S201, and determines that the data is application data (encrypted data) if the "Content Type" in the header is information indicating that the data is application data. The identification unit 24 also refers to the IP header of the packet acquired in step S201, etc., to determine whether the acquired packet is a packet transmitted from the server device 7 to the client terminal device 8.

[0045] If it is determined that the acquired data is application data transmitted from the server device 7 to the client terminal device 8 (YES in step S203), the process proceeds to step S204. On the other hand, if it is determined that the acquired data is not application data transmitted from the server device 7 to the client terminal device 8 (NO in step S203), the process returns to step S201, and subsequent data (packets) are acquired. Note that the case where the result in step S203 is NO means that the acquired data corresponds to an unencrypted handshake message transmitted from the server device 7 to the client terminal device 8, and an example of such a handshake message is a ChangeCipherSpec message.

[0046] In step S204, it is determined whether the data size of the application data (encrypted message) exceeds a second threshold. The estimation unit 25 determines whether the data size of the encrypted message exceeds the second threshold, for example, by referring to "Length" in the TLS header of the packet acquired in step S201.

[0047] If it is determined that the data size of the encrypted message exceeds the second threshold (YES in step S204), it is presumed that the encrypted message contains a digital certificate, and the process proceeds to step S205. On the other hand, if it is determined that the data size does not exceed the second threshold (NO in step S204), it is presumed that the encrypted message is an encrypted message other than a Certificate message sent from the server device 7 to the client terminal device 8 (such as a CertificateVerify message or a Finished message), and the process returns to step S201, where subsequent data (packets) are acquired.

[0048] In step S205, it is determined whether the data size of the encrypted message (application data) is less than a first threshold. The estimation unit 25 determines whether the data size of the encrypted message is less than the first threshold, for example, by referring to "Length" in the TLS header of the packet acquired in step S201. If it is determined that the data size of the encrypted message is less than the first threshold (YES in step S205), the process proceeds to step S206. On the other hand, if it is determined that the data size is not less than the first threshold (NO in step S205), it is estimated that the message includes a valid digital certificate, and the process shown in this flowchart ends.

[0049] In step S206, it is estimated that a suspicious digital certificate is being used. The estimation unit 25 estimates that the packet (encrypted message) acquired in step S201 is a message that includes a suspicious digital certificate. After that, the processing shown in this flowchart ends.

[0050] As described above, the information processing system according to this embodiment determines whether a certificate is suspicious based on the data size of the encrypted message, making it possible to estimate the use of a suspicious electronic certificate (detect malware communication) without decrypting the encrypted communication, even in the case of encrypted communication in which the electronic certificate is encrypted, such as TLS1.3. Therefore, the information processing system according to this embodiment makes it possible to easily implement security measures without incurring the burden of introducing expensive equipment to decrypt encrypted communication.

[0051] [Second embodiment] In the first embodiment described above, an example was described in which whether a message contains a suspicious certificate is estimated based on the data size of the encrypted message. However, the digital certificate (server certificate) transmitted during the handshake may be compressed using an extension that compresses the certificate (the "compress_certificate" extension in the case of TLS1.3). In this case, the data size of the compressed digital certificate is smaller than that of the uncompressed digital certificate. Therefore, it is desirable that the predetermined condition (data size) used to estimate whether a certificate is suspicious be different depending on whether the digital certificate is compressed or not. Therefore, in the second embodiment described below, an example of a method for estimating whether a certificate is suspicious will be described, taking into account the case in which the digital certificate is compressed. Note that the same reference numerals are used for the configurations and processing contents described in the first embodiment, and descriptions thereof will be omitted.

[0052] <System configuration> The system configuration and hardware configuration according to this embodiment are generally similar to those of the first embodiment described with reference to FIGS. 1 and 2, and therefore a description thereof will be omitted.

[0053] Fig. 8 is a diagram showing an outline of the functional configuration of a network monitoring device (information processing system) according to this embodiment. Note that Fig. 8 omits the illustration of configuration other than the network monitoring device 1. The network monitoring device 1 functions as a device including a data acquisition unit 21, a protocol determination unit 22, a session resumption determination unit 23, an identification unit 24, an estimation unit 25, a compression determination unit 26, and a condition management unit 27, by a program recorded in a storage device 14 being read into a RAM 13 and executed by a CPU 11, which controls each piece of hardware provided in the network monitoring device 1. The compression determination unit 26 and the condition management unit 27 will be described below, but the other functional units are generally similar to those of the first embodiment, and therefore description thereof will be omitted.

[0054] The compression determination unit 26 determines whether the encrypted communication between the server device 7 and the client terminal device 8 is communication that uses a compressed digital certificate (communication that uses an extension that compresses a digital certificate (hereinafter referred to as "compression extension")). In this embodiment, the compression determination unit 26 determines whether the communication uses "TLS Certificate Compress," which is a compression extension that can be used in TLS1.3 or higher. Specifically, the compression determination unit 26 refers to the ClientHello, and if the "compress_certificate" extension exists in the "extension" field in the ClientHello, determines that the encrypted communication between the server device 7 and the client terminal device 8 is communication that uses compression extension.

[0055] The condition management unit 27 manages predetermined conditions (thresholds) used to estimate whether a certificate is suspicious. In this embodiment, the condition management unit 27 manages a first threshold used in communications that do not use compression / extension and a third threshold used in communications that use compression / extension. Specifically, when it is determined that encrypted communications between the server device 7 and the client terminal device 8 use compression / extension, the condition management unit 27 sets (calculates) a third threshold that is smaller than the first threshold. In other words, in communications that use compression / extension, the first threshold used to estimate whether a certificate is suspicious is changed to a smaller value. For example, the condition management unit 27 sets the third threshold to a value (e.g., 960 bytes) obtained by multiplying the first threshold (e.g., 1200 bytes) by 0.8.

[0056] As a result, in the case of communication that does not use compression and extension, a first threshold (e.g., 1200 bytes) is used in the process of inferring a suspicious certificate, and in the case of communication that does use compression and extension, a third threshold (e.g., 960 bytes) is used in the process of inferring a suspicious certificate. Note that if the predetermined condition is that the data size of the encrypted message is a predetermined size, for example, in the case of communication that does not use compression and extension, a digital certificate is inferred to be suspicious if the data size is 1000 bytes, and in the case of communication that does not use compression and extension, a digital certificate is inferred to be suspicious if the data size is 800 bytes.

[0057] As described above, it is possible to set different predetermined conditions to be used in the estimation process for communications that do not use compression and extension and communications that do use compression and extension. Specifically, the predetermined condition (first condition) used for communications that do not use compression and extension is that the data size of the encrypted message is within a first predetermined range (exceeding the second threshold and being less than the first threshold). On the other hand, the predetermined condition (second condition) used for communications that use compression and extension is, for example, that the data size of the encrypted message is within a second predetermined range (exceeding the second threshold and being less than the third threshold).

[0058] Furthermore, if the predetermined condition is that the data size of the encrypted message is a predetermined size, then, for example, the first condition is that the data size is a first predetermined size (e.g., 1000 bytes), and the second condition is that the data size is a second predetermined size (e.g., 800 bytes) that is smaller than the first size. This makes it possible to appropriately estimate whether or not a compressed digital certificate is suspicious. In other words, it becomes possible to perform a process for estimating suspicious certificates that takes into account cases where the digital certificate is compressed.

[0059] The degree to which the third threshold is reduced compared to the first threshold (the reduction ratio) can be set arbitrarily and is not limited to the above-mentioned 0.8 times. Similarly to the first threshold, the second threshold may be set to a smaller value (fourth threshold) when the communication uses compression / extension. In this case, the estimation unit 25 uses the threshold (fourth threshold) to estimate whether the message contains a digital certificate. Furthermore, in this embodiment, when the communication is determined to use compression / extension, the first threshold is reduced (the third threshold is calculated), but the timing at which the third threshold is calculated is not limited to this example. Therefore, for example, the third threshold may be set in advance, similar to the first threshold.

[0060] <Processing flow> Next, the flow of processing executed by the network monitoring device (information processing system) according to this embodiment will be described. Note that the specific content and processing order of the processing described below are an example for implementing the present disclosure. The specific content and processing order may be selected as appropriate depending on the embodiment of the present disclosure.

[0061] Fig. 9 is a flowchart showing an outline of the flow of data processing according to this embodiment. The data processing shown in Fig. 9 differs from the processing (steps) described in the first embodiment with reference to Fig. 6 in that steps S104 and S105 have been added. Note that processing steps other than these steps are given the same reference numerals as in the first embodiment (Fig. 6), and descriptions thereof will be omitted. Below, steps S104 and S105, which are added in this embodiment, will be described.

[0062] In step S104, it is determined whether the encrypted communication between the server device 7 and the client terminal device 8 is communication that uses compression and extension (communication that uses a compressed digital certificate). For example, the compression determination unit 26 references the ClientHello and determines that the communication uses compression and extension if the "compress_certificate" extension exists in the "extension" field in the ClientHello. If it is determined that compression and extension will be used (YES in step S104), the process proceeds to step S105. On the other hand, if it is determined that compression and extension will not be used (NO in step S104), the process proceeds to step S106.

[0063] In step S105, the threshold (first threshold) is changed. The condition management unit 27 changes the first threshold used in step S106 (step S205 in FIG. 7) to a smaller value (setting of a third threshold). Thereafter, the process proceeds to step S106. In the case of communication using compression / extension as a result of the process of step S105 (when the process proceeds from YES in step S104 to step S106), the third threshold (a value smaller than the first threshold) is used in the process of step S205. On the other hand, in the case of communication not using compression / extension (when the process proceeds from NO in step S104 to step S106), the first threshold is used in the process of step S205. Note that steps S101, S103, S104, and S105 may be performed in any order.

[0064] The estimation process according to this embodiment is generally similar to that described in the first embodiment with reference to Fig. 7, and therefore will not be described again. However, as described above, this embodiment differs from the first embodiment in that the first threshold value used in step S205 is different between communication that uses compression / extension and communication that does not use compression / extension.

[0065] [Third embodiment] In the first embodiment described above, an example has been described in which it is estimated whether a suspicious certificate is included in an encrypted message based on the data size of the message. Specifically, in the first embodiment, an example has been described in which it is estimated that a suspicious digital certificate is included in an encrypted message if the data size of the encrypted message is within a predetermined range (exceeding the second threshold and being less than the first threshold).

[0066] However, even an encrypted message having a size (length) within this predetermined range may still be a legitimate digital certificate. Thus, even if a message (digital certificate) satisfies the predetermined conditions for being presumed to be a suspicious certificate, it is desirable that the legitimate digital certificate not be presumed to be a suspicious certificate. Therefore, in the third embodiment described below, an example of a method for presuming a suspicious certificate by registering information about a legitimate certificate in a whitelist in advance, thereby excluding legitimate certificates from inspection targets, will be described. Note that the same reference numerals will be used for the configurations and processing contents described in the first embodiment, and description thereof will be omitted.

[0067] <System configuration> The system configuration and hardware configuration according to this embodiment are generally similar to those of the first embodiment described with reference to FIGS. 1 and 2, and therefore a description thereof will be omitted.

[0068] Fig. 10 is a diagram illustrating an outline of the functional configuration of a network monitoring device (information processing system) according to this embodiment. Note that Fig. 10 does not illustrate configurations other than the network monitoring device 1. The network monitoring device 1 functions as a device including a data acquisition unit 21, a protocol determination unit 22, a session resumption determination unit 23, an identification unit 24, an estimation unit 25, a validity condition holding unit 28, and a validity determination unit 29, by reading a program recorded in a storage device 14 into a RAM 13 and executing it by a CPU 11, thereby controlling each piece of hardware included in the network monitoring device 1. The validity condition holding unit 28 and the validity determination unit 29 will be described below, but the other functional units are generally similar to those of the first embodiment, and therefore description thereof will be omitted.

[0069] The validity condition holding unit 28 holds conditions for identifying communications that use valid electronic certificates (conditions for excluding communications from targets (inspection targets) for estimating whether or not an electronic certificate is suspicious). When a user is able to identify communications that use valid electronic certificates in advance, the user registers conditions (communication information) for identifying the communications in a whitelist to enable identification of the communications. Then, it is possible to prevent processing for estimating whether a communications matches the conditions registered in the whitelist. The validity condition holding unit 28 holds the conditions for identifying communications that use valid electronic certificates (hereinafter referred to as "validity conditions") registered by the user in this way. However, validity conditions are not limited to being registered by the user in advance, and may be registered by other methods. Examples of validity conditions that are held are described below.

[0070] The validity condition holding unit 28 holds, as validity conditions, conditions relating to at least one of the following communication information (1) to (3): Each condition (communication information) will be explained below. (1) SNI (Domain Name) (2) IP address (IPv4 / IPv6 address) (3) TLS Fingerprint

[0071] <(1)SNI> SNI (Server Name Identification) is an extension of TLS that enables server certificates for multiple domain names (host names) to be used with a single IP address. Specifically, during the handshake, the client communicates the domain name it wishes to access, allowing the server to use different digital certificates for each domain name rather than for each IP address. Therefore, in this embodiment, by registering domain names that use legitimate certificates in a whitelist, messages containing digital certificates for those domain names can be excluded from inspection. The condition for legitimacy in this case is that "the domain name accessed by the client matches a registered (held) domain name."

[0072] <(2) IP address> If it is possible to identify in advance the server device 7 that uses a legitimate certificate, it is possible to exclude messages sent from that IP address from inspection by registering the IP address (IPv4 address, IPv6 address, etc.) of that server device 7 in a whitelist. The condition for legitimacy in this case is that "the IP address of the message destination or sender matches a registered (retained) IP address."

[0073] <(3) TLS Fingerprint> Fingerprinting is a technology that identifies devices (terminals) from communication characteristics, like a person's fingerprint. TLS fingerprinting is a technology that identifies clients accessing a server by using the characteristics of the received packet (ClientHello) (even the type of browser can be identified). If the characteristics of normal communication (communication using a valid certificate) can be obtained in advance from a fingerprint (information obtained from ClientHello), then by registering that fingerprint information in a whitelist, it becomes possible to exclude messages related to normal communication from inspection. The condition for validity in this case is that "the information (fingerprint) in the received ClientHello matches the registered (stored) fingerprint."

[0074] For example, there are differences in the extensions used in ClientHello between SSL / TLS communications by major browsers and SSL / TLS communications by malware. Specifically, major browsers use a variety of extensions, whereas malware only uses a limited number of extensions due to specific applications. Therefore, by registering the number and types of extensions used in ClientHello when communicating with major browsers as a characteristic of communications with major browsers in a whitelist, it is possible to exclude messages related to communications with major browsers from inspection.

[0075] The validity condition holding unit 28 may hold a condition using at least one of the communication information (1) to (3) described above (for example, only (1)). Furthermore, (1) to (3) are examples of communication information used as validity conditions, and communication information other than (1) to (3) may be used as validity conditions.

[0076] The validity determination unit 29 determines whether the encrypted communication performed between the server device 7 and the client terminal device 8 is communication that uses a valid electronic certificate. Specifically, it determines whether the data acquired by the data acquisition unit 21 satisfies (matches) the validity conditions held by the validity condition holding unit 28, and if the validity conditions are met, it determines that the communication uses a valid electronic certificate.

[0077] For example, if the validity condition is a condition using the communication information described above in (1), the validity determination unit 29 refers to the ClientHello, and if the domain name stored in "server_name" in the ClientHello matches any of the domain names registered in the whitelist, determines that the communication uses a valid electronic certificate.

[0078] Furthermore, for example, if the validity condition is a condition using the communication information in (2) above, validity determination unit 29 determines whether the communication uses a valid electronic certificate by referring to the destination IP address in the header of the packet including ClientHello and / or the source IP address in the header of the packet including ServerHello. For example, validity determination unit 29 determines that the communication uses a valid electronic certificate when the destination IP address in the header of the packet corresponding to ClientHello matches any of the IP addresses registered in the whitelist.

[0079] Also, for example, if the validity condition is a condition using the communication information described above in (3), the validity determination unit 29 refers to the ClientHello, and if the number of extensions and parameter values ​​contained in the "extension" field in the ClientHello match the number of extensions and parameter values ​​registered in the whitelist, determines that the communication uses a valid electronic certificate.

[0080] In this embodiment, if the above-mentioned judgment process determines that the encrypted communication between the server device 7 and the client terminal device 8 is not communication that uses a legitimate electronic certificate that has been registered in advance on a whitelist, a process is performed to estimate whether a suspicious certificate is being used.

[0081] This makes it possible to exclude data relating to communications that have been previously identified as using legitimate digital certificates from inspection, and then perform processing to estimate suspicious certificates. In other words, even if a message (digital certificate) meets the conditions (predetermined conditions) for estimating a certificate as suspicious, it is possible to prevent legitimate digital certificates from being estimated as suspicious.

[0082] <Processing flow> Next, the flow of processing executed by the network monitoring device (information processing system) according to this embodiment will be described. Note that the specific content and processing order of the processing described below are an example for implementing the present disclosure. The specific content and processing order may be selected as appropriate depending on the embodiment of the present disclosure.

[0083] Fig. 11 is a flowchart showing an outline of the flow of data processing according to this embodiment. The data processing shown in Fig. 11 differs from the processing (steps) described in the first embodiment with reference to Fig. 6 in that step S102 has been added. Note that the processing steps other than step S102 are given the same reference numerals as in the first embodiment (Fig. 6), and their explanations will be omitted. Step S102, which is the processing added in this embodiment, will be explained below.

[0084] In step S102, it is determined whether the conditions of the whitelist are met. The validity determination unit 29 determines whether the encrypted communication performed between the server device 7 and the client terminal device 8 is communication that uses a pre-registered valid electronic certificate based on whether the conditions of the whitelist (validity conditions) are met. If the conditions of the whitelist are met (a pre-registered valid electronic certificate is used) (YES in step S102), there is no need to perform estimation processing, and the processing shown in this flowchart ends. On the other hand, if the conditions of the whitelist are not met (a pre-registered valid electronic certificate is not used) (NO in step S102), the processing proceeds to step S103. Note that steps S101 to S103 can be performed in any order.

[0085] As a result, it is possible to prevent the inference process from being performed for communications that use a digital certificate that has been determined to be a legitimate digital certificate in advance. Note that the inference process according to this embodiment is roughly the same as the process described in the first embodiment with reference to FIG. 7, and therefore a description thereof will be omitted.

[0086] [Fourth embodiment] This embodiment is a combination of the second and third embodiments described above. The system configuration and hardware configuration of this embodiment are generally similar to those of the first embodiment described with reference to FIGS. 1 and 2, and therefore will not be described again. The functional configuration of the network monitoring device of this embodiment is a configuration in which the validity condition holding unit 28 and validity determination unit 29 shown in FIG. 10 are added to the functional configuration of FIG. 8. The overview of each functional unit is generally similar to the overview of the functional units described in the first to third embodiments, and therefore will not be described again. The data processing of this embodiment is a combination of the processing described in the second embodiment with reference to FIG. 9 and the processing described in the third embodiment with reference to FIG. 11. Specifically, the data processing of this embodiment involves the execution of six processes (steps S101 to S106). The individual processes (steps) are generally similar to those described in the first to third embodiments, and therefore will not be described again.

[0087] [Fifth embodiment] In the above embodiment, an example has been described in which the network monitoring device 1 is connected between the router 3 and the switch 4 located above it, thereby acquiring packets, frames, etc. sent and received by the client terminal device 8 and forwarding packets that do not need to be blocked (see FIG. 1). However, the network configuration shown in the above embodiment is an example for implementing the present disclosure, and other network configurations may be adopted for implementation. An example of another network configuration will be described below.

[0088] 12 is a schematic diagram showing the configuration of a system according to this embodiment. In a system 9 according to this embodiment, similar to the above embodiment, a client terminal device 8 in a network segment 2 can communicate via a router 3 with various server devices 7 connected in remote locations via the Internet or a wide area network. In this variation, a network monitoring device 1 is connected to a monitoring port (mirror port) of a switch, router, or gateway (switch 4 in the example of FIG. 12) in the network segment 2, thereby acquiring packets, frames, etc. sent and received by the client terminal device 8. In this case, the network monitoring device 1 operates in a passive mode in which it does not forward acquired packets.

[0089] Furthermore, for example, even if the network monitoring device 1 is not connected to a monitoring port (mirror port) but is simply connected to the network segment 2, it can acquire packets, frames, etc. sent and received by the client terminal device 8 by acquiring all frames flowing through the network segment 2, including those not addressed to its own MAC address. In this case, the network monitoring device 1 also operates in passive mode. Furthermore, similar to the above embodiment, the network monitoring device 1 may be included in an L2 bridge, an L3 router, a NAT (Network Address Translation) device, a switch, a proxy, or the like.

[0090] 1. Network monitoring equipment 7 Server equipment 8 Client terminal equipment 9. System

Claims

1. a data acquisition means for acquiring data relating to encrypted communication performed between a first terminal and a second terminal connected to a network; an estimation means for estimating that an encrypted message transmitted from the second terminal to the first terminal to establish the encrypted communication among the acquired data satisfies a predetermined condition related to data size, and the encrypted message includes a suspicious digital certificate related to the second terminal; An information processing system comprising:

2. The predetermined condition is that the data size of the encrypted message is within a predetermined range. The information processing system according to claim 1 .

3. further comprising a specifying means for specifying an encrypted message to be transmitted from the second terminal to the first terminal in order to establish the encrypted communication; the identification means identifies, among the acquired data, an encrypted message transmitted and received between the first terminal and the second terminal in the period from the transmission of an unencrypted message to be transmitted between the first terminal and the second terminal in order to establish the encrypted communication until the transmission of data from the first terminal to the second terminal, as an encrypted message to be transmitted from the second terminal to the first terminal in order to establish the encrypted communication; 3. The information processing system according to claim 1 or 2.

4. further comprising a protocol determination means for determining whether the encrypted communication is encrypted communication according to a predetermined encrypted communication protocol; When it is determined that the protocol of the encrypted communication is the predetermined encrypted communication protocol, the processing by the estimation means is executed.

4. The information processing system according to claim 1.

5. The predetermined encrypted communication protocol is TLS 1.

3. The information processing system according to claim 4 .

6. the protocol determination means determines whether the protocol of the encrypted communication is the predetermined encrypted communication protocol by referring to at least one message among unencrypted messages transmitted and received between the first terminal and the second terminal to establish the encrypted communication, which are included in the acquired data; 6. The information processing system according to claim 4 or 5.

7. further comprising a session resumption determination means for determining whether the encrypted communication is a communication performed by resuming a session; When it is determined that the encrypted communication is not a communication performed by resuming the session, the estimation means executes a process.

7. The information processing system according to claim 1.

8. the session resumption determination means determines whether the encrypted communication is a communication to be performed by resuming the session by referring to a message related to a session resumption request among unencrypted messages transmitted and received between the first terminal and the second terminal to establish the encrypted communication, which are included in the acquired data; The information processing system according to claim 7 .

9. further comprising a compression determination means for determining whether the encrypted communication is a communication using a compressed digital certificate; The estimation means If it is determined that the encrypted communication is not communication using the compressed digital certificate, a first condition is used as the predetermined condition related to the data size, If it is determined that the encrypted communication is communication that uses the compressed digital certificate, a second condition different from the first condition is used as the predetermined condition related to the data size.

9. The information processing system according to claim 1.

10. the first condition is that the data size of the encrypted message is within a first predetermined range; the second condition is that the data size of the encrypted message is within a second predetermined range that is different from the first predetermined range; The information processing system according to claim 9 .

11. an upper limit value defining the second predetermined range is a value smaller than an upper limit value defining the first predetermined range; The information processing system according to claim 10.

12. a validity condition holding means for holding conditions for identifying communications using valid digital certificates; and a validity determination means for determining whether the encrypted communication is a communication that uses the valid electronic certificate based on the stored conditions, When it is determined that the encrypted communication does not use the valid digital certificate, the estimation means executes a process.

12. The information processing system according to claim 1.

13. the unencrypted messages transmitted and received between the first terminal and the second terminal to establish the encrypted communication are a ClientHello message and a ServerHello message; 9. The information processing system according to claim 3, 6, or 8.

14. the data acquisition means acquires data relating to the encrypted communication performed between the first terminal and the second terminal before the data reaches a destination. The information processing system according to any one of claims 1 to 13.

15. The computer a data acquisition step of acquiring data relating to encrypted communication performed between a first terminal and a second terminal connected to a network; and an estimation step of estimating, when an encrypted message transmitted from the second terminal to the first terminal to establish the encrypted communication among the acquired data satisfies a predetermined condition related to data size, that the encrypted message contains a suspicious digital certificate related to the second terminal. Estimation method.

16. Computer, a data acquisition means for acquiring data relating to encrypted communication performed between a first terminal and a second terminal connected to a network; and when an encrypted message transmitted from the second terminal to the first terminal to establish the encrypted communication satisfies a predetermined condition related to data size, the device functions as an estimation means for estimating that the encrypted message contains a suspicious electronic certificate related to the second terminal. program.

Images