CN107124385B - Mirror flow-based SSL/TLS protocol plaintext data acquisition method - Google Patents

Mirror flow-based SSL/TLS protocol plaintext data acquisition method Download PDF

Info

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
Application number
CN201610101613.3A
Other languages
Chinese (zh)
Other versions
CN107124385A (en
Inventor
宋磊
闫露
董海韬
伍洪桥
叶晓舟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhengzhou Xinrand Network Technology Co ltd
Institute of Acoustics CAS
Original Assignee
Institute of Acoustics CAS
Beijing Intellix Technologies Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Institute of Acoustics CAS, Beijing Intellix Technologies Co Ltd filed Critical Institute of Acoustics CAS
Priority to CN201610101613.3A priority Critical patent/CN107124385B/en
Publication of CN107124385A publication Critical patent/CN107124385A/en
Application granted granted Critical
Publication of CN107124385B publication Critical patent/CN107124385B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/168Implementing security features at a particular protocol layer above the transport layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network 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

Mirror flow-based SSL/TLS protocol plaintext data acquisition method
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
Figure GDA0002241006180000051
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.
CN201610101613.3A 2016-02-24 2016-02-24 Mirror flow-based SSL/TLS protocol plaintext data acquisition method Active CN107124385B (en)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

Patent Citations (4)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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.