JP7777471B2 - Information processing system, estimation method and program - Google Patents

Description

This disclosure relates to technology for detecting the use of suspicious digital certificates.

Conventionally, an information processing device has been proposed that includes a communication acquisition unit that acquires data related to communications between a first terminal and a second terminal connected to a network before it reaches the other terminal; a protocol analysis unit that analyzes the communication protocol related to the acquired data to identify a session establishment message included in the data, the message containing the digital certificate of the communication partner in the session to be concealed; a certificate extraction unit that extracts the digital certificate from the identified session establishment message; an inspection unit that verifies the legitimacy of the extracted digital 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 sent between the first terminal and the second terminal before the sending and receiving of the session establishment message. 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 included in the digital certificate (see Patent Document 1).

Patent No. 6084278

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 reveals that the electronic certificate being inspected is a self-signed certificate (a so-called "self-signed certificate"), communications using that electronic certificate are detected as suspicious.

However, TLS 1.3, an encryption technology that has become increasingly popular in recent years, encrypts an increased number of parameters (handshake parameters) when establishing a session compared to conventional encryption technologies such as TLS 1.2, and electronic certificates, like other parameters, are also encrypted before being transferred. In encrypted communications in which electronic certificates are encrypted in this way, it is possible to decrypt the encrypted communications and then analyze them, but this poses the problem of increasing the burden on security measures, such as the need to introduce expensive equipment to decrypt the encrypted communications.

In view of the above-mentioned problems, the present disclosure aims to estimate the use of suspicious electronic certificates without decrypting encrypted communications, even in the case of encrypted communications in which electronic certificates are encrypted.

One 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, 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, inferring that the encrypted message contains a suspicious digital certificate related to the second terminal.

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 or programs through electrical, magnetic, optical, mechanical, or chemical action and can be read by a computer, etc.

According to the present disclosure, even in the case of encrypted communications in which electronic certificates are encrypted, it is possible to infer the use of suspicious electronic certificates without decrypting the encrypted communications.

1 is a schematic diagram illustrating a configuration of a system according to a first embodiment. FIG. 1 is a diagram illustrating a hardware configuration of a system according to a first embodiment. 1 is a diagram illustrating an outline of a functional configuration of a network monitoring device according to a first embodiment. FIG. 1 is a sequence diagram showing a flow of a handshake in conventional TLS 1.2. FIG. 10 is a sequence diagram showing a flow of a handshake in TLS 1.3 according to the first embodiment. 1 is a flowchart showing an outline of a flow of data processing according to the first embodiment. 10 is a flowchart showing an outline of the flow of an estimation process according to the first embodiment. FIG. 10 is a diagram illustrating an outline of the functional configuration of a network monitoring device according to a second embodiment. 10 is a flowchart showing an outline of the flow of data processing according to the second embodiment. FIG. 10 is a diagram illustrating an outline of the functional configuration of a network monitoring device according to a third embodiment. 10 is a flowchart showing an outline of the flow of data processing according to the third embodiment. FIG. 10 is a schematic diagram illustrating a configuration of a system according to a fifth embodiment.

Embodiments of an information processing system, information processing device, method, and program according to the present disclosure will be described below with reference to the drawings. However, the embodiments described below are merely examples, and the information processing system, information processing device, method, and program according to the present disclosure are not limited to the specific configurations described below. When implementing the present disclosure, specific configurations may be adopted as appropriate depending on the implementation mode, and various improvements and modifications may be made.

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

<System configuration>
FIG. 1 is a schematic diagram showing the configuration of a system according to the present embodiment. The system 9 according to the present 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 upstream switch (switching hub), router, or gateway (switch 4 in the example of FIG. 1) of 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.

Figure 2 shows 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 sent 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 encrypted communications between the client terminal device 8 and the server device 7.

The network monitoring device 1 is a computer comprising a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, a storage device 14 such as an EEPROM (Electrically Erasable and Programmable Read Only Memory) or an HDD (Hard Disk Drive), and a communication unit 15 such as a NIC (Network Interface Card). However, the specific hardware configuration of the network monitoring device 1 can be omitted, replaced, or added as appropriate depending on the implementation. 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, L3 router, NAT (Network Address Translation) device, switch, or proxy.

The server device 7 is a computer that provides various services to users. The server device 7 is a computer that includes 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 implementation. 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.

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

Figure 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 components other than the network monitoring device 1 (such as the router 3, switch 4, server device 7, and client terminal device 8) are not illustrated in Figure 3. The network monitoring device 1 functions as a device including a data acquisition unit 21, protocol determination unit 22, session resumption determination unit 23, identification unit 24, and estimation unit 25, with programs stored in the storage device 14 read into the RAM 13 and executed by the CPU 11, controlling the various hardware components of 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 of the network monitoring device 1 are not limited to being implemented in a device (a single device) consisting of a single housing, but may be implemented remotely and/or distributedly (e.g., on the cloud).

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 multiple 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) during transmission, the packet assembling unit 21B assembles (reconstructs) the divided packets into the original packet by referencing the headers of the packets, etc.

For example, if a packet is split into multiple packets during transmission, the headers of each resulting packet contain the same identification number and information indicating which part of the original packet it corresponds to. The packet assembly unit 21B then assembles the packets based on this information. The packet assembly process is performed for each communication flow (session). A communication flow is a unit representing 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 referencing the packet headers. As described above, the data acquisition unit 21 acquires data (TLS messages) sent and received between the server device 7 and the client terminal device 8.

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 TLS 1.3, which is an encrypted communication protocol that encrypts electronic certificates. This protocol determination process is performed by referring to the messages (hereinafter referred to as "handshake messages") sent and received in the handshake that is performed prior to the encrypted communication to establish the encrypted communication.

In this embodiment, the protocol determination unit 22 determines the protocol by referring to the ClientHello message (hereinafter referred to as "ClientHello") and the ServerHello message (hereinafter referred to as "ServerHello"), which are unencrypted handshake messages among the TLS messages acquired by the data acquisition unit 21. Specifically, the protocol determination unit 22 refers to the "supported_version" in the "extension" field in the ClientHello and ServerHello, and if the respective "supported_version" fields contain information indicating TLS 1.3, it determines that the protocol of the encrypted communication established by the handshake message is TLS 1.3.

In this embodiment, if the above-described determination process determines that the protocol for encrypted communication between the server device 7 and the client terminal device 8 is a specified encrypted communication protocol (TLS 1.3), the estimation process (process to estimate whether a suspicious certificate is being used) described below is performed.

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 or not it is TLS 1.3. Therefore, for example, it is possible to reference only one of ClientHello and ServerHello. 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 that encrypts electronic certificates may be used.

The session resumption determination unit 23 determines whether the encrypted communication between the server device 7 and the client terminal device 8 is established by full negotiation, i.e., whether it is communication established by resuming a session (session resumption sequence). For example, in the case of TLS 1.3, by resuming a session using a PSK (Pre-Shared Key), it is possible to establish a new connection (encrypted communication) without performing a full handshake. When resuming a session using this PSK, there is no need 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 was used when establishing encrypted communication, and the estimation process described below is performed only if a PSK was not used (if the session was not resumed), i.e., if full negotiation was performed (if a session was established).

In this embodiment, the session resumption determination unit 23 determines whether full negotiation is being performed by referencing the handshake message transmitted and received between the server device 7 and the client terminal device 8. For example, the session resumption determination unit 23 references ClientHello, which is a message related to a session resumption request, and if "pre_shared_key" is not present in the "extension" field in ClientHello, or if "pre_shared_key" is present but its data length (Length) is zero, determines that the encrypted communication established by the handshake message is communication established by full negotiation.

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 server device 7's digital certificate. In the case of TLS 1.3, all messages after Server Hello are encrypted, making it difficult to identify which TLS messages contain a digital certificate, for example, from the packet header. Below, we will explain the differences between the handshakes (negotiations to start encrypted communication (TLS connection)) between TLS 1.2 and TLS 1.3.

Figure 4 is a sequence diagram showing the flow of a handshake in conventional TLS 1.2. Figure 4 shows TLS messages sent and received between a server and a client during a handshake in TLS 1.2. Also, in Figure 4, arrows indicating 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 determine whether a message contains a digital certificate by referencing the TLS header of the received message (packet). Specifically, it is possible to determine whether a message contains a digital certificate by referencing the "Content Type (Handshake Type)" in the TLS header, which indicates the type of data stored in the packet payload (TLS payload).

Figure 5 is a sequence diagram showing the flow of a handshake in TLS 1.3 according to this embodiment. Figure 5 shows TLS messages sent and received between a server and a client during a handshake in TLS 1.3, but TLS messages not shown in Figure 5 may also be included. Also in Figure 5, arrows indicating encrypted messages are indicated by dashed lines. As shown in Figure 5, in TLS 1.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 referencing 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.

For this reason, in this embodiment, the encrypted handshake message sent from the server device 7 to the client terminal device 8 is identified from the order of messages in the handshake message when establishing encrypted communication. It is then possible to estimate that at least one of these identified handshake messages contains a message (Certificate) that includes an electronic certificate.

As shown in FIG. 5, in TLS 1.3, after Server Hello, the server sends various TLS messages (handshake messages) including a "Certificate" message to the client, and the client then sends a "Finished" message. Note that the message sent from the client is not limited to the "Finished" message; depending on the situation, an "Alert" message or other message may be sent to the server. Therefore, the identification unit 24 can identify encrypted messages sent and received between the time Server Hello is sent and the time data (TCP packets) is sent from the client as encrypted handshake messages (TLS messages that may include an electronic certificate) sent from the server device 7 to the client terminal device 8.

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

(1) Estimation of message containing digital certificate
Typically, among the encrypted handshake messages transmitted 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, a message exceeding a predetermined data size (second threshold) can be estimated to be a message containing 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 contains a digital certificate. 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 referencing "Length" in the TLS header, which indicates the length of the TLS payload.

<(2) Presuming whether a 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 exceeds 400 bytes but is less than 1200 bytes, the estimation unit 25 estimates that the encrypted message contains a suspicious digital certificate. Note that the first threshold is not limited to 1200 bytes and can be set to any value. Note that the data size of the encrypted message can be obtained by referencing the "Length" in the TLS header, as described above.

As described above, if 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 example described above, the predetermined condition related to data size was described as the data size of the encrypted message being 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 example described above, and may be, for example, the data size of the encrypted message being a predetermined size (e.g., 1,000 bytes).

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

Figure 6 is a flowchart showing an overview of the data processing flow according to this embodiment. The processing shown in this flowchart is initiated when a ClientHello and 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 terms "ClientHello" and "ServerHello" used in the following explanation (of Figure 6) refer to the ClientHello and ServerHello that triggered the start of this flowchart.

In step S101, it is determined whether the protocol for encrypted communication between the server device 7 and the client terminal device 8 is TLS 1.3. The protocol determination unit 22 determines whether the encryption protocol is TLS 1.3 by referencing ClientHello and ServerHello ("supported_version"). If it is determined that the protocol for encrypted communication between the server device 7 and the client terminal device 8 is TLS 1.3 (YES in step S101), processing proceeds to step S103. On the other hand, if it is determined that it is not TLS 1.3 (NO in step S101), estimation processing is not performed, and the processing shown in this flowchart ends.

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 communication related to session resumption). The session resumption determination unit 23 determines whether full negotiation is to be performed by referencing 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 is not to 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.

In step S106, estimation processing is performed on the TLS message (TLS record) following the Client Hello and Server Hello. Details of the estimation processing will be described later using Figure 7. After that, the processing shown in this flowchart ends.

Figure 7 is a flowchart showing an overview of the estimation process flow according to this embodiment. The process shown in this flowchart is initiated when full negotiation is determined in step S103 in Figure 6. Note that the terms "ClientHello" and "ServerHello" used in the following explanation (the explanation of Figure 7) refer to the ClientHello and ServerHello that triggered the start of the flowchart shown in Figure 6.

In step S201, data transmitted and received between the server device 7 and the client terminal device 8 is acquired. The data acquisition unit 21 acquires the packet (TLS message) following the Server Hello. Processing then proceeds to step S202.

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

In step S203, it is determined whether the acquired data is application data (encrypted data) sent from the server device 7 to the client terminal device 8. The identification unit 24 references 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 references the IP header, etc., of the packet acquired in step S201 to determine whether the acquired packet is a packet sent from the server device 7 to the client terminal device 8.

If it is determined that the acquired data is application data sent 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 sent from the server device 7 to the client terminal device 8 (NO in step S203), the process returns to step S201, and the subsequent data (packet) is acquired. Note that the case where the result in step S203 is NO means that the acquired data corresponds to an unencrypted handshake message sent from the server device 7 to the client terminal device 8; an example of such a handshake message is a ChangeCipherSpec message.

In step S204, it is determined whether the data size of the application data (encrypted message) exceeds the 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.

If it is determined that the data size of the encrypted message exceeds the second threshold (YES in step S204), it is assumed that the encrypted message contains a digital certificate, and processing 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 assumed 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 processing returns to step S201, where subsequent data (packets) are acquired.

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), processing 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 contains a valid electronic certificate, and the processing shown in this flowchart ends.

In step S206, it is estimated that a suspicious electronic 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 electronic certificate. Then, the processing shown in this flowchart ends.

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 infer the use of a suspicious electronic certificate (detect malware communications) without decrypting the encrypted communications, even in the case of encrypted communications in which the electronic certificate is encrypted, such as TLS 1.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 communications.

[Second embodiment]
In the first embodiment described above, an example was described in which whether a message contains a suspicious certificate was 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 (in the case of TLS 1.3, the "compress_certificate" extension). 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.

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

Figure 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 in Figure 8, configuration other than the network monitoring device 1 is omitted from the illustration. The network monitoring device 1 functions as a device including a data acquisition unit 21, protocol determination unit 22, session resumption determination unit 23, identification unit 24, estimation unit 25, as well as a compression determination unit 26 and condition management unit 27, by having a program recorded in the storage device 14 read into the RAM 13 and executed by the CPU 11, which controls each piece of hardware provided in the network monitoring device 1. The compression determination unit 26 and condition management unit 27 will be described below, but as the other functional units are generally similar to those in the first embodiment, description thereof will be omitted.

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 digital certificates (hereinafter referred to as "compression extension")). In this embodiment, the compression determination unit 26 determines whether the communication uses "TLS Certificate Compress," a compression extension that is available in TLS 1.3 and higher. Specifically, the compression determination unit 26 references the ClientHello, and if the "compress_certificate" extension is present 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.

The condition management unit 27 manages predetermined conditions (thresholds) used to determine 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/expansion, and a third threshold used in communications that do use compression/expansion. Specifically, when the condition management unit 27 determines that encrypted communications between the server device 7 and the client terminal device 8 use compression/expansion, it sets (calculates) a third threshold that is smaller than the first threshold. In other words, in communications that use compression/expansion, the first threshold used to determine 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) that is 0.8 times the first threshold (e.g., 1200 bytes).

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. If the specified condition is that the data size of the encrypted message is a specified size, for example, in the case of communication that does not use compression and extension, a data size of 1000 bytes will be inferred as a suspicious electronic certificate, and in the case of communication that does not use compression and extension, a data size of 800 bytes will be inferred as a suspicious electronic certificate.

As described above, it is possible to differentiate the predetermined conditions used in the estimation process between communications that do not use compression and extension and communications that do. Specifically, the predetermined condition (first condition) used when communications 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 when communications 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).

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 a compressed electronic certificate is suspicious or not. In other words, it becomes possible to perform a suspicious certificate estimation process that takes into account cases where the electronic certificate is compressed.

The degree to which the third threshold is made smaller than the first threshold (the rate at which it is made smaller) can be set arbitrarily and is not limited to the above-mentioned 0.8 times. Furthermore, like the first threshold, the second threshold may also be set to a smaller value (fourth threshold) when the communication uses compression/expansion. In this case, the estimation unit 25 uses this threshold (fourth threshold) to estimate whether the message contains a digital certificate. Furthermore, in this embodiment, when the communication is determined to use compression/expansion, the first threshold is changed to a smaller value (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 also be set in advance, like the first threshold.

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

Figure 9 is a flowchart showing an overview of the data processing flow according to this embodiment. The data processing shown in Figure 9 differs from the processing (steps) described in the first embodiment with reference to Figure 6 in that steps S104 and S105 have been added. Note that processing steps other than these steps have been assigned the same reference numerals as in the first embodiment (Figure 6), and their explanation will be omitted. Below, we will explain steps S104 and S105, which are added in this embodiment.

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 is present in the "extension" field in the ClientHello. If it is determined that compression and extension will be used (YES in step S104), processing proceeds to step S105. On the other hand, if it is determined that compression and extension will not be used (NO in step S104), processing proceeds to step S106.

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 the third threshold). Processing then proceeds to step S106. As a result of the processing in step S105, in the case of communication that uses compression/expansion (when processing proceeds from YES in step S104 to step S106), the third threshold (a value smaller than the first threshold) is used in the processing in step S205. On the other hand, in the case of communication that does not use compression/expansion (when processing proceeds from NO in step S104 to step S106), the first threshold is used in the processing in step S205. Note that steps S101, S103, S104, and S105 can be performed in any order.

Note that the estimation process according to this embodiment is generally similar to that described with reference to FIG. 7 in the first embodiment, and therefore will not be described again. However, as mentioned above, this embodiment differs from the first embodiment in that the first threshold value used in step S205 differs between communications that use compression/extension and communications that do not use compression/extension.

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

However, even an encrypted message with a size (length) within this specified range may still be a legitimate digital certificate. In this way, even if a message (digital certificate) meets the specified 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 legitimate certificates in a whitelist in advance and excluding legitimate certificates from inspection targets will be described. Note that the same reference numerals will be used for the configuration and processing content described in the first embodiment, and a description thereof will be omitted.

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

Figure 10 is a diagram showing an outline of the functional configuration of a network monitoring device (information processing system) according to this embodiment. Note that in Figure 10, configuration other than that of the network monitoring device 1 is omitted. The network monitoring device 1 functions as a device including a data acquisition unit 21, protocol determination unit 22, session resumption determination unit 23, identification unit 24, and estimation unit 25, as well as a validity condition holding unit 28 and validity determination unit 29, by having a program recorded in the storage device 14 read into the RAM 13 and executed by the CPU 11, which controls each piece of hardware provided in the network monitoring device 1. The validity condition holding unit 28 and validity determination unit 29 will be described below, but as the other functional units are generally similar to those in the first embodiment, description thereof will be omitted.

The validity conditions 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). If a user is able to identify communications that use valid electronic certificates in advance, the user registers the conditions (communication information) for identifying the communications in a whitelist to enable identification of the communications. Then, for communications that match the conditions registered in the whitelist, it is possible to prevent processing for estimating whether the electronic certificate is suspicious. The validity conditions 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 using other methods. Examples of validity conditions that are held are described below.

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

<(1) Systemic Neural Networks (SNI)>
SNI (Server Name Identification) is an extension of TLS that allows server certificates for multiple domain names (host names) to be used with a single IP address. Specifically, during a 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 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."

<(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 (such as an IPv4 address or an IPv6 address) of that server device 7 in a whitelist. The validity condition in this case is that "the IP address of the message destination or sender matches a registered (retained) IP address."

<(3) TLS Fingerprint>
Fingerprinting is a technology that identifies devices (terminals) from communication characteristics, like a person's fingerprint, and TLS fingerprinting is a technology that identifies clients accessing a server by using the characteristics of received packets (Client Hello) (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 Client Hello), then by registering the fingerprint information in a whitelist, it becomes possible to exclude messages related to normal communication from inspection. The validity condition in this case is that "the information (fingerprint) in the received Client Hello matches the registered (stored) fingerprint."

For example, there are differences in the extensions used in Client Hello 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, etc. Therefore, by registering the number and types of extensions used in Client Hello when communicating using major browsers as a characteristic of communications using major browsers in a whitelist, it is possible to exclude messages related to communications using major browsers from inspection.

The validity condition holding unit 28 only needs to hold a condition that uses at least one of the communication information (1) to (3) described above (for example, only (1)). (1) to (3) are examples of communication information that can be used as validity conditions, and communication information other than (1) to (3) may also be used as validity conditions.

The validity determination unit 29 determines whether the encrypted communication 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 the validity conditions stored in the validity condition storage unit 28 (whether it matches the validity conditions), and if the validity conditions are satisfied, it determines that the communication uses a valid electronic certificate.

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

Furthermore, for example, if the validity condition is a condition using the communication information described in (2) above, the 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 containing Client Hello and/or the source IP address in the header of the packet containing Server Hello. For example, the validity determination unit 29 determines that the communication uses a valid electronic certificate if the destination IP address in the header of the packet corresponding to Client Hello matches any of the IP addresses registered in the whitelist.

Furthermore, for example, if the validity condition is a condition using the communication information described above in (3), the validity determination unit 29 references the Client Hello, and if the number of extensions and parameter values contained in the "extension" field in the Client Hello match the number of extensions and parameter values registered in the whitelist, determines that the communication uses a valid electronic certificate.

In this embodiment, if the above-described determination process determines that the encrypted communication between the server device 7 and the client terminal device 8 does not use 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.

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

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

Figure 11 is a flowchart showing an overview of the data processing flow according to this embodiment. The data processing shown in Figure 11 differs from the processing (steps) described in the first embodiment with reference to Figure 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 (Figure 6) and will not be described further. Below, we will explain step S102, the processing step added in this embodiment.

In step S102, it is determined whether the conditions of the whitelist are met. The validity determination unit 29 determines whether the encrypted communication 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.

As a result, it is possible to prevent the estimation process from being performed for communications that use electronic certificates that have been determined to be legitimate in advance. Note that the estimation process according to this embodiment is roughly the same as that described with reference to FIG. 7 in the first embodiment, and therefore will not be described here.

[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 here. The functional configuration of the network monitoring device of this embodiment is the functional configuration of FIG. 8 , to which the validity condition holding unit 28 and validity determination unit 29 shown in FIG. 10 have been added. 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 here. 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 here.

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

Figure 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, client terminal devices 8 within 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 Figure 12) in the network segment 2, thereby acquiring packets, frames, etc. sent and received by the client terminal devices 8. In this case, the network monitoring device 1 operates in a passive mode in which it does not forward acquired packets.

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 and frames 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. Also, as in the above embodiment, the network monitoring device 1 may be included in an L2 bridge, L3 router, NAT (Network Address Translation) device, switch, proxy, etc.

1 Network monitoring device 7 Server device 8 Client terminal device 9 System

Claims (16)

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: 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 . 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. 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. The predetermined encrypted communication protocol is TLS 1.3.
The information processing system according to claim 4 . 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. 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. 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 . 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. 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 . 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. 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. 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. 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. 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. 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.