CN107124385B - Mirror flow-based SSL/TLS protocol plaintext data acquisition method - Google Patents
Mirror flow-based SSL/TLS protocol plaintext data acquisition method Download PDFInfo
- Publication number
- CN107124385B CN107124385B CN201610101613.3A CN201610101613A CN107124385B CN 107124385 B CN107124385 B CN 107124385B CN 201610101613 A CN201610101613 A CN 201610101613A CN 107124385 B CN107124385 B CN 107124385B
- Authority
- CN
- China
- Prior art keywords
- message
- record
- length
- protocol
- cache
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/168—Implementing security features at a particular protocol layer above the transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention provides a mirror flow-based SSL/TLS protocol plaintext data acquisition method, which comprises the following steps: step 1) receiving a mirrored SSL/TLS data packet, extracting records in the data packet, generating a plurality of complete records, and putting the records into a record queue; step 2) extracting a plurality of complete messages from the records in the record queue and putting the messages into a message queue; and 3) analyzing the messages in the message queue to obtain plaintext data. According to the method, data packets are spliced into the finished record according to the packaging format of the SSL/TLS protocol, the complete single message is further extracted and then processed, no requirement exists on whether a server synthesizes a plurality of messages into one record or packages the single message into a plurality of records, new messages needing to be analyzed can be flexibly selected to be added, and the expandability is good; the method processes the image data of the switch to obtain the plaintext data, does not interfere with the original service of the system, and does not influence the performance of the system.
Description
Technical Field
The invention belongs to the technical field of network security communication, and particularly relates to a mirror flow-based SSL/TLS protocol plaintext data acquisition method.
Background
The SSL protocol and its successor TLS protocol are security protocols that provide security and data integrity for network security. The SSL/TLS protocol is located between the TCP/IP protocol and the application layer protocol, and can provide security guarantee for various application layer protocols, such as FTP, TELNET protocol, etc., and at present, the SSL/TLS protocol is most widely applied to protect the HTTP protocol. The SSL/TLS protocol includes two layers: a recording layer protocol and a handshake protocol. The recording protocol provides basic security service for a high-level handshake protocol, and guarantees the integrity of data, and specifically comprises compression and decompression, encryption and decryption, calculation, MAC verification and the like. The handshake layer protocol comprises a handshake protocol, a password parameter modification protocol, an alarm protocol and an application data protocol, and is used for authentication of both communication parties, negotiation of an encryption algorithm, generation of a secret key and the like.
The high-level protocol protected by the SSL/TLS protocol is transmitted between the client and the server as ciphertext data without plaintext, which brings difficulty to data audit. Some technical means are needed to decrypt ciphertext data in the SSL/TLS communication process into plaintext data, and then the corresponding plaintext data is analyzed and audited. As shown in fig. 1, in the prior art, an SSL/TLS proxy server is generally introduced between a client and a server, and the proxy server is connected in series between the client and the server, and two SSL/TLS connections are respectively established with the client and the server. Because the SSL/TLS proxy server decrypts the data to obtain the plaintext data after acquiring the data, and then encrypts and transmits the plaintext data to the client, additional encryption operation brings burden to the system, and the response time of the system is prolonged, and the throughput rate is reduced.
Disclosure of Invention
The invention aims to overcome the defects existing in the prior SSL/TLS communication process when ciphertext data is decrypted into plaintext data, and provides a method for acquiring the plaintext data of an SSL/TLS protocol based on mirror flow.
In order to achieve the above object, the present invention provides a mirror flow-based SSL/TLS protocol plaintext data collection method, where the method includes:
step 1) receiving a mirrored SSL/TLS data packet, extracting records in the data packet, generating a plurality of complete records, and putting the records into a record queue;
step 2) extracting a plurality of complete messages from the records in the record queue and putting the messages into a message queue;
and 3) analyzing the messages in the message queue to obtain plaintext data.
In the above technical solution, the step 1) specifically includes:
step 101) receiving a mirrored SSL/TLS data packet;
step 102) extracting a first record from the data packet, checking whether a record cache region has a cache record, and directly calculating the length of the received first record if the record cache region does not have the cache record; if the record cache region has cache records, splicing the data packet to the cache records, and calculating the length of the first record of the current cache;
step 103) comparing the length of the first record with the length of the data packet, and if the length of the first record plus the length of the recording head is equal to the length of the data packet, turning to step 104); if the length of the first record and the length of the recording head are smaller than the length of the data packet, the step 105) is carried out; if the length of the first record plus the length of the recording head is larger than the length of the data packet, the step 106) is carried out;
step 104) placing the record in a record queue;
step 105) splitting the data packet, circularly extracting a single complete record and putting the single complete record into a record queue, and putting the last incomplete record into a record cache region;
step 106) placing the record in a record buffer area; turning to step 101);
and the incomplete records placed in the record buffer area wait for splicing of subsequent data packets, and then complete records are generated.
In the above technical solution, the step 2) specifically includes:
step 201) takes a record from the record queue as the current record,
step 202) checking the type of the current record, and if the type of the current record is an application data protocol, a password specification changing protocol or an alarm message, turning to step 203); if the current record type is a handshake protocol, go to step 204);
step 203) recording the current information as a single complete information, and putting the information into an information queue;
step 204) checking whether a message cache region has cache messages or not, and if no cache message exists, directly calculating the length of a first message in the current record; if the cache message exists in the cache, the length of the first message of the current cache is calculated after the current record is spliced to the cache message;
step 205) comparing the calculated length of the first message with the current recording length, and if the length of the first message plus the length of the message header is equal to the current recording length, turning to step 206); if the length of the first message plus the length of the message header is smaller than the current recording length, go to step 207); if the length of the first message plus the length of the message header is greater than the current record length, go to step 208);
step 206), currently recording the message as a single complete message, and placing the message into a message queue;
step 207) if the current record contains a plurality of messages, splitting the record, circularly extracting a plurality of complete messages and putting the messages into a message queue; putting the final incomplete message into a message buffer area;
step 208), recording the current message as an incomplete message, putting the message into a message buffer area, and switching to step 201);
the incomplete message put into the message buffer area waits for the subsequent records to be spliced, and then the complete message is generated.
In the above technical solution, the specific implementation process of step 3) is as follows:
taking out a message from the message queue, and if the message type is a handshake protocol, extracting the password specification and the key information; if the message type is the cipher protocol specification changing, the following records are protected by the newly negotiated cipher specification and the secret key; if the message type is the alarm message, analyzing the severity and the alarm description of the message; and if the message type is the application data protocol, decrypting the transmission data by using the extracted password specification and the key to obtain plaintext data.
In the above technical solution, the handshake protocol includes: ClientHello, ServerHello, SeverCertificate, serverhellolodone, clientkeyExange, NewSessionsTicket and Finished, wherein the specific steps of extracting the password specification and the key information are as follows:
step 301) if the handshake protocol type is ClientHello, recording a client random number, a session _ id and a session _ ticket;
step 302), if the handshake protocol type is ServerHello, judging whether session reuse occurs, if the session reuse occurs, extracting a master key and an encryption algorithm specification from the cached session information, and generating a password parameter; if the session reuse does not occur, recording a protocol version, a server random number, a sesseion _ id, an encryption suite and a compression algorithm;
step 303) if the handshake protocol type is the SeverCertification, extracting a server public key, and searching a matching certificate to obtain a server private key;
step 304), if the handshake protocol type is serverhellododone, the server has completed key exchange message at this time;
step 305), if the handshake protocol type is ClientKeyExange, decrypting the pre-master key by using the server, calculating the master key and generating a security parameter; if the conversation is a new conversation, caching the conversation information;
step 306), if the handshake protocol type is NewSessionTicket, if no session reuse occurs at this time, filling the session _ token item in the cached session information, and if the session reuse occurs, updating the session _ token item in the cached session information;
step 307) if the type of the handshake protocol is Finished, verifying all handshake data in the corresponding direction, and after the two parties pass the verification, starting application data transmission.
In the above technical solution, the step 3) further includes: and after the plaintext data is obtained, analyzing the plaintext data, generating an audit log and storing the audit log.
Compared with the prior art, the invention has the advantages that:
1. according to the method, data packets are spliced into the finished record according to the packaging format of the SSL/TLS protocol, the complete single message is further extracted and then processed, no requirement exists on whether a server synthesizes a plurality of messages into one record or packages the single message into a plurality of records, new messages needing to be analyzed can be flexibly selected to be added, and the expandability is good;
2. compared with the traditional method of introducing a proxy server, the method of the invention processes the image data of the switch to obtain the plaintext data, and does not interfere with the original service of the system and influence the performance of the system.
Drawings
FIG. 1 is a diagram of a prior art SSL/TLS protocol plaintext data collection system;
FIG. 2 is a flow chart of the mirror flow-based SSL/TLS protocol plaintext data collection method of the present invention;
fig. 3 is a schematic diagram of a mirror flow-based SSL/TLS protocol plaintext data collection system according to an embodiment of the present invention.
Detailed Description
The invention is described in detail below with reference to the drawings and preferred embodiments.
As shown in fig. 2, a mirror flow-based SSL/TLS protocol plaintext data collection method includes:
step 1) receiving a mirrored SSL/TLS data packet, extracting records in the data packet, generating a plurality of complete records, and putting the records into a record queue; the method specifically comprises the following steps:
step 101) receiving a mirrored SSL/TLS data packet;
step 102) extracting a first record from the data packet, checking whether a record cache region has a cache record, and directly calculating the length of the received first record if the record cache region does not have the cache record; if the record cache region has cache records, splicing the data packet to the cache records, and calculating the length of the first record of the current cache;
the SSL/TLS protocol record encapsulation format is shown in Table 1, where the header has a total of 5 bytes:
TABLE 1
Step 103) comparing the length of the first record with the length of the data packet, and if the length of the first record plus the length of the recording head is equal to the length of the data packet, turning to step 104); if the length of the first record and the length of the recording head are smaller than the length of the data packet, the step 105) is carried out; if the length of the first record plus the length of the recording head is larger than the length of the data packet, the step 106) is carried out;
step 104) placing the record in a record queue;
the record placed in the record queue is a complete record.
Step 105) splitting the data packet, circularly extracting a single complete record and putting the single complete record into a record queue, and putting the last incomplete record into a record cache region;
step 106) placing the record in a record buffer area; turning to step 101);
and the incomplete records placed in the record buffer area wait for splicing of subsequent data packets, and then complete records are generated.
Step 2) extracting a plurality of complete messages from the records in the record queue and putting the messages into a message queue;
because the SSL/TLS protocol record is not used as the boundary of the message, after the complete record is extracted, the complete message needs to be further extracted, and the step 2) specifically includes:
step 201) takes a record from the record queue as the current record,
step 202) checking the type of the current record, and if the type of the current record is an application data protocol, a password specification changing protocol or an alarm message, turning to step 203); if the current record type is a handshake protocol, go to step 204);
the SSL/TLS record handshake message format is shown in table 2, where the header is 4 bytes:
TABLE 2
Step 203) recording the current information as a single complete information, and putting the information into an information queue;
step 204) checking whether a message cache region has cache messages or not, and if no cache message exists, directly calculating the length of a first message in the current record; if the cache message exists in the cache, the length of the first message of the current cache is calculated after the current record is spliced to the cache message;
step 205) comparing the calculated length of the first message with the current recording length, and if the length of the first message plus the length of the message header is equal to the current recording length, turning to step 206); if the length of the first message plus the length of the message header is smaller than the current recording length, go to step 207); if the length of the first message plus the length of the message header is greater than the current record length, go to step 208);
step 206), currently recording the message as a single complete message, and placing the message into a message queue;
step 207) if the current record contains a plurality of messages, splitting the record, circularly extracting a plurality of complete messages and putting the messages into a message queue; putting the final incomplete message into a message buffer area;
step 208), recording the current message as an incomplete message, putting the message into a message buffer area, and switching to step 201);
the incomplete message put into the message buffer area waits for the subsequent records to be spliced, and then the complete message is generated.
Step 3) analyzing the messages in the message queue to obtain plaintext data;
taking out a message from the message queue, and if the message type is a handshake protocol, extracting the password specification and the key information; if the message type is the cipher protocol specification changing, the following records are protected by the newly negotiated cipher specification and the secret key; if the message type is the alarm message, analyzing the severity and the alarm description of the message; and if the message type is the application data protocol, decrypting the transmission data by using the extracted password specification and the key to obtain plaintext data.
The handshake protocol includes: ClientHello, ServerHello, SeverCertificate, serverhellolodone, clientkeyExange, NewSessionsTicket and Finished, wherein the specific steps of extracting the password specification and the key information are as follows:
step 301) if the handshake protocol type is ClientHello, recording a client random number, a session _ id and a session _ ticket;
step 302), if the handshake protocol type is ServerHello, judging whether session reuse occurs, if the session reuse occurs, extracting a master key and an encryption algorithm specification from the cached session information, and generating a password parameter; if the session reuse does not occur, recording a protocol version, a server random number, a sesseion _ id, an encryption suite and a compression algorithm;
step 303) if the handshake protocol type is the SeverCertification, extracting a server public key, and searching a matching certificate to obtain a server private key;
step 304), if the handshake protocol type is serverhellododone, the server has completed key exchange message at this time;
step 305), if the handshake protocol type is ClientKeyExange, decrypting the pre-master key by using the server, calculating the master key and generating a security parameter; if the conversation is a new conversation, caching the conversation information;
step 306), if the handshake protocol type is NewSessionTicket, if no session reuse occurs at this time, filling the session _ token item in the cached session information, and if the session reuse occurs, updating the session _ token item in the cached session information;
step 307) if the type of the handshake protocol is Finished, verifying all handshake data in the corresponding direction, and after the two parties pass the verification, starting application data transmission.
In the embodiment, the plaintext data is HTTP data, and the plaintext data is analyzed to obtain URL and other fields to generate and store an audit log for an auditor to audit subsequently.
As shown in fig. 3, by the method of the present invention, the client establishes SSL/TLS connection with the server, the collection device obtains the interactive data between the client and the server by using the switch image, and the collection device legally holds the server certificate and the private key.
Finally, it should be noted that the above embodiments are only used for illustrating the technical solutions of the present invention and not for limiting, and although the present invention is described in detail with reference to the embodiments, it should be understood by those skilled in the art that modifications or equivalent substitutions may be made on the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, which should be covered by the claims of the present invention.
Claims (5)
1. A mirror flow-based SSL/TLS protocol plaintext data collection method, the method comprising:
step 1) receiving a mirrored SSL/TLS data packet, extracting records in the data packet, generating a plurality of complete records, and putting the records into a record queue;
step 2) extracting a plurality of complete messages from the records in the record queue and putting the messages into a message queue;
step 3) analyzing the messages in the message queue to obtain plaintext data;
the step 1) specifically comprises the following steps:
step 101) receiving a mirrored SSL/TLS data packet;
step 102) extracting a first record from the data packet, checking whether a record cache region has a cache record, and directly calculating the length of the received first record if the record cache region does not have the cache record; if the record cache region has cache records, splicing the data packet to the cache records, and calculating the length of the first record of the current cache;
step 103) comparing the length of the first record with the length of the data packet, and if the length of the first record plus the length of the recording head is equal to the length of the data packet, turning to step 104); if the length of the first record and the length of the recording head are smaller than the length of the data packet, the step 105) is carried out; if the length of the first record plus the length of the recording head is larger than the length of the data packet, the step 106) is carried out;
step 104) placing the record in a record queue;
step 105) splitting the data packet, circularly extracting a single complete record and putting the single complete record into a record queue, and putting the last incomplete record into a record cache region;
step 106) placing the record in a record buffer area; turning to step 101);
and the incomplete records placed in the record buffer area wait for splicing of subsequent data packets, and then complete records are generated.
2. The image flow-based SSL/TLS protocol plaintext data collection method according to claim 1, wherein the step 2) specifically includes:
step 201) takes a record from the record queue as the current record,
step 202) checking the type of the current record, and if the type of the current record is an application data protocol, a password specification changing protocol or an alarm message, turning to step 203); if the current record type is a handshake protocol, go to step 204);
step 203) recording the current information as a single complete information, and putting the information into an information queue;
step 204) checking whether a message cache region has cache messages or not, and if no cache message exists, directly calculating the length of a first message in the current record; if the cache message exists in the cache, the length of the first message of the current cache is calculated after the current record is spliced to the cache message;
step 205) comparing the calculated length of the first message with the current recording length, and if the length of the first message plus the length of the message header is equal to the current recording length, turning to step 206); if the length of the first message plus the length of the message header is smaller than the current recording length, go to step 207); if the length of the first message plus the length of the message header is greater than the current record length, go to step 208);
step 206), currently recording the message as a single complete message, and placing the message into a message queue;
step 207) if the current record contains a plurality of messages, splitting the record, circularly extracting a plurality of complete messages and putting the messages into a message queue; putting the final incomplete message into a message buffer area;
step 208), recording the current message as an incomplete message, putting the message into a message buffer area, and switching to step 201);
the incomplete message put into the message buffer area waits for the subsequent records to be spliced, and then the complete message is generated.
3. The image flow-based SSL/TLS protocol plaintext data collection method according to claim 1 or 2, wherein the step 3) is implemented by:
taking out a message from the message queue, and if the message type is a handshake protocol, extracting the password specification and the key information; if the message type is the cipher protocol specification changing, the following records are protected by the newly negotiated cipher specification and the secret key; if the message type is the alarm message, analyzing the severity and the alarm description of the message; and if the message type is the application data protocol, decrypting the transmission data by using the extracted password specification and the key to obtain plaintext data.
4. The image flow-based SSL/TLS protocol plaintext data collection method according to claim 3, wherein the handshake protocol comprises: ClientHello, ServerHello, SeverCertificate, serverhellolodone, clientkeyExange, NewSessionsTicket and Finished, wherein the specific steps of extracting the password specification and the key information are as follows:
step 301) if the handshake protocol type is ClientHello, recording a client random number, a session _ id and a session _ ticket;
step 302), if the handshake protocol type is ServerHello, judging whether session reuse occurs, if the session reuse occurs, extracting a master key and an encryption algorithm specification from the cached session information, and generating a password parameter; if the session reuse does not occur, recording a protocol version, a server random number, a sesseion _ id, an encryption suite and a compression algorithm;
step 303) if the handshake protocol type is the SeverCertification, extracting a server public key, and searching a matching certificate to obtain a server private key;
step 304), if the handshake protocol type is serverhellododone, the server has completed key exchange message at this time;
step 305), if the handshake protocol type is ClientKeyExange, decrypting the pre-master key by using the server, calculating the master key and generating a security parameter; if the conversation is a new conversation, caching the conversation information;
step 306), if the handshake protocol type is NewSessionTicket, if no session reuse occurs at this time, filling the session _ token item in the cached session information, and if the session reuse occurs, updating the session _ token item in the cached session information;
step 307) if the type of the handshake protocol is Finished, verifying all handshake data in the corresponding direction, and after the two parties pass the verification, starting application data transmission.
5. The image flow-based SSL/TLS protocol plaintext data collection method according to claim 1, wherein the step 3) further comprises: and after the plaintext data is obtained, analyzing the plaintext data, generating an audit log and storing the audit log.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610101613.3A CN107124385B (en) | 2016-02-24 | 2016-02-24 | Mirror flow-based SSL/TLS protocol plaintext data acquisition method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610101613.3A CN107124385B (en) | 2016-02-24 | 2016-02-24 | Mirror flow-based SSL/TLS protocol plaintext data acquisition method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107124385A CN107124385A (en) | 2017-09-01 |
| CN107124385B true CN107124385B (en) | 2020-02-04 |
Family
ID=59716965
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610101613.3A Active CN107124385B (en) | 2016-02-24 | 2016-02-24 | Mirror flow-based SSL/TLS protocol plaintext data acquisition method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107124385B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110620766B (en) * | 2019-09-05 | 2021-12-14 | 东南大学 | Method for extracting TLS data block in encrypted network flow |
| CN110784444B (en) * | 2019-09-09 | 2021-10-15 | 航天行云科技有限公司 | Method for processing nested data stream and related equipment |
| CN111756751B (en) * | 2020-06-28 | 2022-10-21 | 杭州迪普科技股份有限公司 | Message transmission method and device and electronic equipment |
| CN114817641B (en) * | 2022-02-19 | 2023-06-20 | 英赛克科技（北京）有限公司 | Industrial data acquisition method and device and electronic equipment |
| CN114584393B (en) * | 2022-03-31 | 2023-10-20 | 深圳市瑞云科技有限公司 | Method for automatically selecting encryption protocol |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1451690A1 (en) * | 2001-10-29 | 2004-09-01 | Pitney Bowes Inc. | Monitoring system for a corporate network |
| CN101325519A (en) * | 2008-06-05 | 2008-12-17 | 华为技术有限公司 | Content auditing method, system based on safety protocol and content auditing equipment |
| CN102984243A (en) * | 2012-11-20 | 2013-03-20 | 杭州迪普科技有限公司 | Automatic identification method and device applied to secure socket layer (SSL) |
| CN104468537A (en) * | 2014-11-25 | 2015-03-25 | 公安部第三研究所 | System and method for achieving safety audit |
-
2016
- 2016-02-24 CN CN201610101613.3A patent/CN107124385B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1451690A1 (en) * | 2001-10-29 | 2004-09-01 | Pitney Bowes Inc. | Monitoring system for a corporate network |
| CN101325519A (en) * | 2008-06-05 | 2008-12-17 | 华为技术有限公司 | Content auditing method, system based on safety protocol and content auditing equipment |
| CN102984243A (en) * | 2012-11-20 | 2013-03-20 | 杭州迪普科技有限公司 | Automatic identification method and device applied to secure socket layer (SSL) |
| CN104468537A (en) * | 2014-11-25 | 2015-03-25 | 公安部第三研究所 | System and method for achieving safety audit |
Non-Patent Citations (1)
| Title |
|---|
| "适用于网络内容审计的SSL/TLS保密数据高效明文采集方法";董海韬 等;《计算机应用》;20151130(第10期);第2892页第2栏倒数第20行至第2894页第2栏倒数第11行，图2 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107124385A (en) | 2017-09-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107124385B (en) | Mirror flow-based SSL/TLS protocol plaintext data acquisition method | |
| EP1543648B1 (en) | System, method and computer program product for guaranteeing electronic transactions | |
| CN106941401B (en) | Acceleration equipment and method for obtaining session key based on acceleration equipment | |
| US7769997B2 (en) | System, method and computer program product for guaranteeing electronic transactions | |
| CN108156178B (en) | SSL/TLS data monitoring system and method | |
| WO2019178942A1 (en) | Method and system for performing ssl handshake | |
| EP2814199A1 (en) | Method and system for downloading file | |
| EP3232632A1 (en) | Method and system for acquiring plaintext of network secret data | |
| CN112487483A (en) | Encrypted database flow auditing method and device | |
| US8281122B2 (en) | Generation and/or reception, at least in part, of packet including encrypted payload | |
| CN107577729B (en) | Webpage data evidence obtaining method and system based on two channels | |
| CN110839240B (en) | Method and device for establishing connection | |
| CN114050920B (en) | Transparent network encryption system implementation method based on FPGA | |
| CN102970228B (en) | A kind of message transmitting method based on IPsec and equipment | |
| CN112272314B (en) | Method, device, equipment and medium for safely transmitting video in video network | |
| CN112738560A (en) | Video data transmission method, receiving method, server and client | |
| CN112035851A (en) | MYSQL database auditing method based on SSL | |
| CN116743372A (en) | Quantum security protocol implementation method and system based on SSL protocol | |
| KR101448866B1 (en) | Security apparatus for decrypting data encrypted according to the web security protocol and operating method thereof | |
| CN112165494B (en) | Message analysis method, device, electronic equipment and storage medium | |
| CN113872956A (en) | Method and system for inspecting IPSEC VPN transmission content | |
| US20160366191A1 (en) | Single Proxies in Secure Communication Using Service Function Chaining | |
| CN106685896B (en) | Clear data acquisition method and system in a kind of SSH agreement multilevel access | |
| CN109286598B (en) | TLS channel encrypted RDP protocol plaintext data acquisition system and method | |
| CN102843335B (en) | The processing method of streaming medium content and equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20210813 Address after: Room 1601, 16th floor, East Tower, Ximei building, No. 6, Changchun Road, high tech Industrial Development Zone, Zhengzhou, Henan 450001 Patentee after: Zhengzhou xinrand Network Technology Co.,Ltd. Address before: 100190, No. 21 West Fourth Ring Road, Beijing, Haidian District Patentee before: INSTITUTE OF ACOUSTICS, CHINESE ACADEMY OF SCIENCES Effective date of registration: 20210813 Address after: 100190, No. 21 West Fourth Ring Road, Beijing, Haidian District Patentee after: INSTITUTE OF ACOUSTICS, CHINESE ACADEMY OF SCIENCES Address before: 100190, No. 21 West Fourth Ring Road, Beijing, Haidian District Patentee before: INSTITUTE OF ACOUSTICS, CHINESE ACADEMY OF SCIENCES Patentee before: BEIJING INTELLIX TECHNOLOGIES Co.,Ltd. |