An HTTPS data transmission security state detection method, system, device and medium based on network protocol analysis

Abstract

The application discloses an HTTPS data transmission security state detection method and system based on network protocol analysis, equipment and medium, mainly relates to the security state detection technical field, in order to solve the problem that the existing scheme lacks comprehensive analysis of HTTPS communication data. Including: generating a preset security strength requirement result according to TLS session data; generating a session decryption risk result according to the type of the analysis key exchange algorithm; obtaining certificate basic information by analyzing the Certificate message sent by the server involved in the TLS session data; generating a server verification result according to the certificate basic information; generating a certificate transparency log verification result according to the public CT log server corresponding to the server certificate; sending a server certificate state query request to the OCSP response server of the CA through the OCSP, and obtaining a certificate revocation state query result; and generating a risk generation report by summarizing the results.

Description

Technical Field

[0001] This application relates to the field of security status detection technology, and in particular to a method, system, device and medium for HTTPS data transmission security status detection based on network protocol analysis. Background Technology

[0002] Currently, the closest existing technologies in the field of HTTPS communication security testing are mainly based on traditional SSL / TLS protocol detection methods. Existing technologies typically employ the following schemes to achieve basic verification of HTTPS communication security: (1) Certificate verification scheme based on browser built-in mechanism: Existing schemes mainly rely on the certificate verification mechanism built into the browser client to perform basic verification on the digital certificate returned by the server during the TLS handshake phase. The browser verifies the signature of the server certificate issuing authority (CA) through a pre-set list of trusted root certificates, and checks whether the certificate's validity period is within the current time range. (2) Protocol analysis scheme based on network packet capture tools: Using network packet capture tools such as Wireshark and tcpdump, the TLS handshake data packets in the HTTPS communication process are captured and analyzed.

[0003] However, existing browser-built-in certificate verification mechanisms only perform basic certificate validity checks and cannot deeply verify the integrity of the session key negotiation process during the TLS handshake, nor can they detect whether the integrity of encrypted data has been compromised during transmission. While existing network packet capture tools can capture TLS handshake messages, they lack the ability to fully parse the structured information of digital certificates. Current technologies also lack automated verification mechanisms for comparing certificate signature information with the CA root certificate. Summary of the Invention

[0004] This application provides a method, system, device, and medium for HTTPS data transmission security status detection based on network protocol analysis, in order to solve the problem that existing solutions lack comprehensive analysis of HTTPS communication data.

[0005] Firstly, this application provides a method for detecting the security status of HTTPS data transmission based on network protocol analysis, the method comprising: Obtain TLS session data in the target network environment through the network interface; Based on the TLS protocol version information supported by the client in the ClientHello message corresponding to the TLS session data, generate a protocol downgrade risk result; based on the cipher suite selected by the server in the ServerHello message corresponding to the TLS session data, generate a security risk result; based on the ServerKeyExchange message in the TLS session data, generate a preset security strength requirement result; based on the analysis of the key exchange algorithm type, generate a session decryption risk result. Based on the Certificate message sent by the server involved in the TLS session data, the basic certificate information is obtained by parsing; based on the basic certificate information, the server verification result is generated; the server verification result includes: server certificate validity period verification, domain name matching verification, certificate signature legality verification, and certificate chain integrity verification; Based on the public CT (Certificate Transparency) log server corresponding to the server certificate, generate the certificate transparency log verification result; send a server certificate status query request to the CA's OCSP response server via OCSP (Online Certificate Status Protocol) to obtain the certificate revocation status query result; The system summarizes the results of protocol downgrade risk, security risk, preset security strength requirements, session decryption risk, server verification, certificate transparency log verification, and certificate revocation status query, and generates a risk generation report.

[0006] In one implementation of this application, TLS session data in the target network environment is obtained through a network interface, specifically including: Real-time capture of communication data in the target network environment via network interface; Based on the TCP / IP protocol stack, the captured communication data is parsed in layers to identify the port information of the transport layer and filter out the communication traffic of the target port. The selected traffic is identified by application layer protocol identification. By analyzing the protocol header feature fields of the data packets, complete TLS session data is extracted from the communication traffic with HTTPS / TLS protocol header feature fields.

[0007] In one implementation of this application, a protocol downgrade risk result is generated based on the TLS protocol version information supported by the client in the ClientHello message corresponding to the TLS session data; a security risk result is generated based on the cipher suite selected by the server in the ServerHello message corresponding to the TLS session data; a preset security strength requirement result is generated based on the ServerKeyExchange message in the TLS session data; and a session decryption risk result is generated based on the analysis of the key exchange algorithm type, specifically including: Parse the ClientHello message corresponding to the TLS session data to extract the list of TLS protocol versions supported by the client, the list of cipher suites, the client random number, and extended field information; determine the protocol versions supported by the client based on the TLS protocol version list, the list of cipher suites, the client random number, and extended field information; if the protocol version is lower than the preset version, determine that there is a protocol downgrade risk; otherwise, determine that there is no protocol downgrade risk. Parse the ServerHello message corresponding to the TLS session data, extract the cipher suite selected by the server, compare the selected cipher suite with the preset security cipher suite whitelist, and determine that there is a security risk if the selected cipher suite is not in the whitelist; otherwise, determine that there is no security risk. Parse the ServerKeyExchange message corresponding to the TLS session data, extract the key exchange parameters on the server side, and verify whether the security strength of the key exchange parameters meets the preset requirements. If the preset requirements are met, the result of the preset security strength requirement is determined to meet the preset requirements; otherwise, the result of the preset security strength requirement is determined to not meet the preset requirements. The type of key exchange algorithm corresponding to the TLS session data is parsed. If the key exchange algorithm type supports forward secrecy, the session decryption risk result is determined to be that there is no risk of historical sessions being decrypted; otherwise, the session decryption risk result is determined to be that there is a risk of historical sessions being decrypted.

[0008] In one implementation of this application, basic certificate information is obtained by parsing the Certificate message sent by the server involved in the TLS session data; based on the basic certificate information, a server verification result is generated; wherein, the server verification result includes: server certificate validity period verification, domain name matching verification, certificate signature legality verification, and certificate chain integrity verification, specifically including: Based on the Certificate message sent by the server involved in the TLS session data, parse the X.509 certificate format and extract the following structured fields: certificate version, serial number, signature algorithm identifier, issuer information, validity period, user information, alternate name of the principal, and public key information; The certificate's effective and expiration times are compared with the current system time. If the current time is earlier than the effective time or later than the expiration time, the server certificate validity period verification result is determined to be abnormal; otherwise, the server certificate validity period verification is determined to be normal. The system matches and verifies the target domain name actually accessed by the user against the Common Name field and the Alternate Name field in the certificate. If the target domain name does not match any of the domain name fields in the certificate, the certificate domain name is determined to be mismatched, and the domain name matching verification is marked as having a domain name spoofing risk. Otherwise, the domain name matching verification is marked as not having a domain name spoofing risk. Based on the principle of asymmetric encryption, the public key of the issuing CA is used to decrypt the digital signature of the current certificate to obtain the certificate digest value; at the same time, the digest value of the TBS part of the certificate is recalculated using the signature algorithm identified in the certificate; the two digest values ​​are compared, and if they match, the signature verification is successful; if they do not match, it is determined that the certificate signature has been tampered with or the certificate is a forged certificate. Starting with the server certificate, trace the certificate chain upwards level by level, determine whether the certificate chain is incomplete, and generate the corresponding certificate chain integrity verification result.

[0009] In one implementation of this application, a certificate transparency log verification result is generated based on the public CT log server corresponding to the server certificate; a server certificate status query request is sent to the CA's OCSP response server via OCSP to obtain the certificate revocation status query result, specifically including: Query the publicly available CT log server corresponding to the server certificate to verify whether the server certificate has been recorded in the CT log. If no corresponding record for the server certificate is found in any CT log, the certificate transparency log verification result indicates a risk of forgery. Otherwise, the certificate transparency log verification result indicates no risk of forgery. The OCSP sends a certificate status query request to the CA's OCSP response server to query the revocation status of the server certificate and each intermediate certificate in the certificate chain. If any certificate has been revoked, the certificate revocation status query result is determined to be that the certificate is invalid; otherwise, the certificate revocation status query result is determined to be that the certificate is valid.

[0010] In one implementation of this application, a risk generation report is generated by summarizing the results of protocol downgrade risk, security risk, preset security strength requirement, session decryption risk, server verification, certificate transparency log verification, and certificate revocation status query, specifically including: The results of all detection dimensions are standardized and encoded to convert qualitative judgments into weighted risk scores. Among them, the existence of protocol downgrade risk, security risk, failure to meet preset security strength requirements, historical session decryption risk, abnormal validity period, domain name mismatch, invalid signature, incomplete certificate chain, no CT log record, and certificate revocation are all marked as risk items with 1 point, while the corresponding compliance results without risk are marked as 0 points. All results are integrated into a structured risk dataset. Based on the risk dataset, risk levels are categorized and aggregated. Risk weights are assigned according to the impact of different detection items on HTTPS transmission security. Among them, certificate revocation, domain name mismatch, and illegal signature are preset high-risk items with a weight coefficient of 2; protocol downgrade, insecure encryption suite, and incomplete certificate chain are preset medium-risk items with a weight coefficient of 1; and missing CT logs, insufficient key strength, and lack of forward secrecy are preset low-risk items with a weight coefficient of 0.5. The overall risk score of the target HTTPS session is calculated. At the same time, all risk points are sorted into high-risk, medium-risk, and low-risk categories to form risk detail entries, and a report with overall risk quantification results is output.

[0011] Secondly, this application provides an HTTPS data transmission security status detection system based on network protocol analysis, the system comprising: The acquisition module is used to acquire TLS session data in the target network environment through the network interface; The first result module is used to generate protocol downgrade risk results based on the TLS protocol version information supported by the client in the ClientHello message corresponding to the TLS session data; generate security risk results based on the cipher suite selected by the server in the ServerHello message corresponding to the TLS session data; generate preset security strength requirement results based on the ServerKeyExchange message in the TLS session data; and generate session decryption risk results based on the analysis of the key exchange algorithm type. The second result module is used to parse and obtain basic certificate information based on the Certificate message sent by the server involved in the TLS session data; and generate server verification results based on the basic certificate information; wherein, the server verification results include: server certificate validity period verification, domain name matching verification, certificate signature legality verification, and certificate chain integrity verification; The third result module is used to generate certificate transparency log verification results based on the public CT log server corresponding to the server certificate; and to send a server certificate status query request to the CA's OCSP response server through OCSP to obtain the certificate revocation status query result. The aggregation module is used to aggregate results of protocol downgrade risk, security risk, preset security strength requirements, session decryption risk, server verification, certificate transparency log verification, and certificate revocation status query, and generate a risk generation report.

[0012] In one implementation of this application, the acquisition module is used to capture communication data in the target network environment in real time through a network interface; Based on the TCP / IP protocol stack, the captured communication data is parsed in layers to identify the port information of the transport layer and filter out the communication traffic of the target port. The selected traffic is identified by application layer protocol identification. By analyzing the protocol header feature fields of the data packets, complete TLS session data is extracted from the communication traffic with HTTPS / TLS protocol header feature fields.

[0013] Thirdly, this application provides an HTTPS data transmission security status detection device based on network protocol analysis, the device comprising: processor; And a memory containing executable code, which, when executed, causes the processor to perform a network protocol analysis-based HTTPS data transmission security state detection method, as described above.

[0014] Fourthly, this application provides a non-volatile computer storage medium storing computer instructions thereon, which, when executed, implement a network protocol analysis-based HTTPS data transmission security status detection method as described above.

[0015] As can be seen from the above technical solutions, this application has the following advantages: By actively parsing the ClientHello and ServerHello messages during the TLS handshake phase, this mechanism automates the comparison between the client's supported protocol versions and the server's selected cipher suites, directly generating protocol downgrade risk and security risk results. This overcomes the limitations of traditional browsers that rely solely on static certificate validity verification. This mechanism can identify communication using weak protocols (such as SSL 3.0 and TLS 1.0) or insecure cipher suites (such as RC4 and DES), blocking potential man-in-the-middle attack paths at the protocol layer and significantly improving the verifiable security of the HTTPS connection establishment phase.

[0016] Based on the key exchange algorithm type and parameters in the ServerKeyExchange message, and combined with preset security strength requirements, the system automatically assesses the anti-cracking capability of the key negotiation process and generates session decryption risk results. Simultaneously, it performs deep structured parsing of the Certificate message sent by the server, fully extracting and verifying certificate validity, domain name matching, signature validity, and certificate chain integrity, achieving multi-dimensional automated verification of the server's identity. This mechanism overcomes the shortcomings of existing packet capture tools that only capture messages but cannot parse the certificate structure, ensuring the authenticity and trustworthiness of the server's identity and preventing covert access by forged or expired certificates.

[0017] Further integrating public CT log server queries and OCSP response server real-time queries, it automatically generates certificate transparency log verification results and certificate revocation status query results, achieving closed-loop verification of certificate issuance transparency and real-time revocation status at the protocol analysis level for the first time. This addresses the shortcomings of traditional systems in lacking automated signature consistency comparison and revocation status tracking, upgrading the security status assessment of HTTPS communication from "static certificate verification" to "dynamic end-to-end auditing," providing traceable, quantifiable, and reportable real-time security situation awareness capabilities for the network environment. Attached Figure Description

[0018] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart of a method for detecting the security status of HTTPS data transmission based on network protocol analysis, provided in an embodiment of this application.

[0020] Figure 2 This is a schematic diagram of the internal structure of an HTTPS data transmission security status detection system based on network protocol analysis, provided in an embodiment of this application.

[0021] Figure 3 This is a schematic diagram of the internal structure of an HTTPS data transmission security status detection device based on network protocol analysis, provided in an embodiment of this application. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] Those skilled in the art should understand that the embodiments described below are merely preferred embodiments of this disclosure and do not imply that this disclosure can only be implemented through these preferred embodiments. These preferred embodiments are merely used to explain the technical principles of this disclosure and are not intended to limit the scope of protection of this disclosure. Based on the preferred embodiments provided by this disclosure, all other embodiments obtained by those skilled in the art without creative effort should still fall within the scope of protection of this disclosure.

[0024] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0025] The technical solutions proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0026] The embodiment provides a method for detecting the security status of HTTPS data transmission based on network protocol analysis, such as Figure 1 As shown in the embodiments of this application, the method mainly includes the following steps: Step 110: Obtain TLS session data in the target network environment through the network interface.

[0027] In some embodiments, obtaining TLS session data in the target network environment through a network interface specifically includes: Real-time capture of communication data in the target network environment via network interface; Based on the TCP / IP protocol stack, the captured communication data is parsed in layers to identify the port information of the transport layer and filter out the communication traffic of the target port. The selected traffic is identified by application layer protocol identification. By analyzing the protocol header feature fields of the data packets, complete TLS session data is extracted from the communication traffic with HTTPS / TLS protocol header feature fields.

[0028] It should be further explained that this step captures communication data in the target network environment in real time through the network interface and performs layered parsing based on the TCP / IP protocol stack. This accurately identifies communication traffic on port 443 or other custom HTTPS ports in the transport layer, avoiding protocol misjudgments caused by non-standard ports. Furthermore, by analyzing the TLS record layer type field (e.g., 0x16 indicates a handshake message), version number, and ClientHello structure characteristics in the data packets, it achieves accurate identification of HTTPS / TLS protocol traffic and effectively filters non-TLS traffic (such as X11, HTTP plaintext, or other application layer protocols). This ensures that the extracted TLS session data is complete and noise-free, providing reliable and structured raw input data for subsequent protocol version analysis, cipher suite identification, and certificate structure parsing.

[0029] Step 120: Generate a protocol downgrade risk result based on the TLS protocol version information supported by the client in the ClientHello message corresponding to the TLS session data; generate a security risk result based on the cipher suite selected by the server in the ServerHello message corresponding to the TLS session data; generate a preset security strength requirement result based on the ServerKeyExchange message in the TLS session data; and generate a session decryption risk result based on the type of key exchange algorithm analyzed.

[0030] In some embodiments, this step may specifically be as follows: Parse the ClientHello message corresponding to the TLS session data to extract the list of TLS protocol versions supported by the client, the list of cipher suites, the client random number, and extended field information; determine the protocol versions supported by the client based on the TLS protocol version list, the list of cipher suites, the client random number, and extended field information; if the protocol version is lower than the preset version, determine that there is a protocol downgrade risk; otherwise, determine that there is no protocol downgrade risk. Parse the ServerHello message corresponding to the TLS session data, extract the cipher suite selected by the server, compare the selected cipher suite with the preset security cipher suite whitelist, and determine that there is a security risk if the selected cipher suite is not in the whitelist; otherwise, determine that there is no security risk. Parse the ServerKeyExchange message corresponding to the TLS session data, extract the key exchange parameters on the server side, and verify whether the security strength of the key exchange parameters meets the preset requirements. If the preset requirements are met, the result of the preset security strength requirement is determined to meet the preset requirements; otherwise, the result of the preset security strength requirement is determined to not meet the preset requirements. The type of key exchange algorithm corresponding to the TLS session data is parsed. If the key exchange algorithm type supports forward secrecy, the session decryption risk result is determined to be that there is no risk of historical sessions being decrypted; otherwise, the session decryption risk result is determined to be that there is a risk of historical sessions being decrypted.

[0031] It should be further explained that this step, by parsing the protocol version list and cipher suite list in the ClientHello message, automatically compares them with the preset minimum version threshold and the security cipher suite whitelist. This objectively determines whether there is a case of protocol downgrading or the use of weak cipher suites, avoiding omissions caused by manual judgment based on experience. Based on the cipher suite selected by the server in ServerHello, it matches it with the preset whitelist and directly outputs the security risk status, realizing the automatic identification of non-standard or deprecated algorithms (such as RC4, 3DES). By parsing the key exchange parameters (such as DH prime length, ECDH curve type) in the ServerKeyExchange message, it verifies whether they meet the preset security strength requirements (such as DH≥2048 bits, ECDH≥256 bits), ensuring that the key negotiation parameters conform to the current security baseline. Furthermore, it determines whether forward secrecy is supported based on the key exchange algorithm type (such as ECDHE, DHE vs RSA), thereby clarifying whether historical sessions have the potential risk of being stored for a long time and then decrypted.

[0032] Step 130: Parse the Certificate message sent by the server involved in the TLS session data to obtain the basic certificate information; generate the server verification result based on the basic certificate information.

[0033] The server verification results include: server certificate validity period verification, domain name matching verification, certificate signature legality verification, and certificate chain integrity verification.

[0034] In some embodiments, this step may specifically be as follows: Based on the Certificate message sent by the server involved in the TLS session data, parse the X.509 certificate format and extract the following structured fields: certificate version, serial number, signature algorithm identifier, issuer information, validity period, user information, alternate name of the principal, and public key information; The certificate's effective and expiration times are compared with the current system time. If the current time is earlier than the effective time or later than the expiration time, the server certificate validity period verification result is determined to be abnormal; otherwise, the server certificate validity period verification is determined to be normal. The system matches and verifies the target domain name actually accessed by the user against the Common Name field and the Alternate Name field in the certificate. If the target domain name does not match any of the domain name fields in the certificate, the certificate domain name is determined to be mismatched, and the domain name matching verification is marked as having a domain name spoofing risk. Otherwise, the domain name matching verification is marked as not having a domain name spoofing risk. Based on the principle of asymmetric encryption, the public key of the issuing CA is used to decrypt the digital signature of the current certificate to obtain the certificate digest value; at the same time, the digest value of the TBS part of the certificate is recalculated using the signature algorithm identified in the certificate; the two digest values ​​are compared, and if they match, the signature verification is successful; if they do not match, it is determined that the certificate signature has been tampered with or the certificate is a forged certificate. Starting with the server certificate, trace the certificate chain upwards level by level, determine whether the certificate chain is incomplete, and generate the corresponding certificate chain integrity verification result.

[0035] It should be further explained that this step automates the reading of basic certificate information by parsing the Certificate message sent by the server and extracting fields such as version, validity period, user name, alternate name of the principal, public key, and signature algorithm from the X.509 certificate, avoiding omissions during manual verification. Comparing the certificate's effective and expiration times with the current system time objectively determines whether there are expired or ineffective cases, preventing the establishment of connections using certificates with invalid times. Accurate matching of the target domain name with the Common Name (CN) and Alternate Name of the Principal (SAN) fields in the certificate directly identifies potential spoofing behavior where the domain name does not match the certificate subject. Based on the signature algorithm specified in the certificate and the issuer's public key, the digest of the TBS portion is recalculated and compared with the signature decryption result to confirm that the certificate has not been tampered with and its source is trustworthy. The certificate chain is traced upwards level by level to verify whether each issuer is in the trust chain and whether it is uninterrupted, ensuring that the server certificate is issued by a legitimate CA and the chain is complete.

[0036] Step 140: Generate a certificate transparency log verification result based on the public CT log server corresponding to the server certificate; send a server certificate status query request to the CA's OCSP response server via OCSP to obtain the certificate revocation status query result.

[0037] In some embodiments, this step may specifically be as follows: Query the publicly available CT log server corresponding to the server certificate to verify whether the server certificate has been recorded in the CT log. If no corresponding record for the server certificate is found in any CT log, the certificate transparency log verification result indicates a risk of forgery. Otherwise, the certificate transparency log verification result indicates no risk of forgery. The OCSP sends a certificate status query request to the CA's OCSP response server to query the revocation status of the server certificate and each intermediate certificate in the certificate chain. If any certificate has been revoked, the certificate revocation status query result is determined to be that the certificate is invalid; otherwise, the certificate revocation status query result is determined to be that the certificate is valid.

[0038] It should be further explained that this step verifies whether the server certificate is recorded in the logs by querying publicly available CT log servers. This objectively determines whether the certificate complies with industry-mandated transparency requirements, preventing potential forgery or unauthorized issuance due to certificates not being on the blockchain from being mistakenly considered legitimate by the system. When no corresponding record is found in any CT log, the system directly generates a verification result of "forgery risk exists," providing a traceable machine judgment basis for subsequent connection blocking or alarms. Simultaneously, by sending a certificate status query request to the CA's OCSP response server, the real-time revocation status of the server certificate and each intermediate certificate in the certificate chain is obtained. This accurately identifies invalid certificates that have been revoked but not marked by the local trust store, preventing the continued use of invalid certificates due to CRL update delays. Both types of query results are based on automated request and response parsing according to standard protocols (RFC 6962, RFC 6960), without relying on manual judgment or external database comparisons. This ensures that the verification process is reproducible and the results are auditable, providing structured, machine-readable input data for security status reports.

[0039] Step 150: Summarize the results of protocol downgrade risk, security risk, preset security strength requirements, session decryption risk, server verification, certificate transparency log verification, and certificate revocation status query, and generate a risk generation report.

[0040] In some embodiments, this step may specifically be as follows: The results of all detection dimensions are standardized and encoded to convert qualitative judgments into weighted risk scores. Among them, the existence of protocol downgrade risk, security risk, failure to meet preset security strength requirements, historical session decryption risk, abnormal validity period, domain name mismatch, invalid signature, incomplete certificate chain, no CT log record, and certificate revocation are all marked as risk items with 1 point, while the corresponding compliance results without risk are marked as 0 points. All results are integrated into a structured risk dataset. Based on the risk dataset, risk levels are categorized and aggregated. Risk weights are assigned according to the impact of different detection items on HTTPS transmission security. Among them, certificate revocation, domain name mismatch, and illegal signature are preset high-risk items with a weight coefficient of 2; protocol downgrade, insecure encryption suite, and incomplete certificate chain are preset medium-risk items with a weight coefficient of 1; and missing CT logs, insufficient key strength, and lack of forward secrecy are preset low-risk items with a weight coefficient of 0.5. The overall risk score of the target HTTPS session is calculated. At the same time, all risk points are sorted into high-risk, medium-risk, and low-risk categories to form risk detail entries, and a report with overall risk quantification results is output.

[0041] It should be further explained that this step standardizes the expression of multi-dimensional security status by uniformly encoding seven types of detection results—protocol downgrade risk, security risk, security strength compliance, session decryption risk, server verification status, CT log verification results, and certificate revocation status—into binary risk items (0 or 1). Based on this, according to the actual impact of each risk item on HTTPS communication security, high-risk items (certificate revocation, domain name mismatch, illegal signature) are assigned a weight of 2, medium-risk items (protocol downgrade, insecure encryption suite, incomplete certificate chain) a weight of 1, and low-risk items (missing CT logs, insufficient key strength, lack of forward secrecy) a weight of 0.5. A weighted sum is then generated to produce a quantifiable overall risk score. Simultaneously, all triggered risk points are categorized and grouped according to weight level, forming structured risk detail entries, and outputting a report containing the total score and a list of categorized risks. This process is entirely based on the logical operations of preset rules and input data, without relying on manual interpretation or subjective judgment, ensuring that the report content is reproducible and traceable, providing accurate and unambiguous machine-readable output for automated security policy triggering, audit log generation, or system alarms.

[0042] In addition, this application Figure 2 This application provides an embodiment of an HTTPS data transmission security status detection system based on network protocol analysis. For example... Figure 2 As shown in the embodiments of this application, the system mainly includes: The acquisition module 210 is used to acquire TLS session data in the target network environment through a network interface.

[0043] The acquisition module 210 is used to capture communication data in the target network environment in real time through the network interface; Based on the TCP / IP protocol stack, the captured communication data is parsed in layers to identify the port information of the transport layer and filter out the communication traffic of the target port. The selected traffic is identified by application layer protocol identification. By analyzing the protocol header feature fields of the data packets, complete TLS session data is extracted from the communication traffic with HTTPS / TLS protocol header feature fields.

[0044] The first result module 220 is used to generate a protocol downgrade risk result based on the TLS protocol version information supported by the client in the ClientHello message corresponding to the TLS session data; generate a security risk result based on the cipher suite selected by the server in the ServerHello message corresponding to the TLS session data; generate a preset security strength requirement result based on the ServerKeyExchange message in the TLS session data; and generate a session decryption risk result based on the type of key exchange algorithm analyzed.

[0045] The second result module 230 is used to parse and obtain basic certificate information based on the Certificate message sent by the server involved in the TLS session data; and generate server verification results based on the basic certificate information; wherein the server verification results include: server certificate validity period verification, domain name matching verification, certificate signature legality verification, and certificate chain integrity verification.

[0046] The third result module 240 is used to generate a certificate transparency log verification result based on the public CT log server corresponding to the server certificate; and to send a server certificate status query request to the CA's OCSP response server through OCSP to obtain the certificate revocation status query result.

[0047] The summary module 250 is used to summarize the results of protocol downgrade risk, security risk, preset security strength requirements, session decryption risk, server verification, certificate transparency log verification, and certificate revocation status query, and generate a risk generation report.

[0048] The above are method embodiments of this application. Based on the same inventive concept, this application also provides an HTTPS data transmission security status detection device based on network protocol analysis. Figure 3 As shown, the device includes: a processor; and a memory storing executable code thereon, which, when executed, causes the processor to perform an HTTPS data transmission security state detection method based on network protocol analysis as described in the above embodiment.

[0049] Specifically, the server obtains TLS session data from the target network environment through a network interface; generates a protocol downgrade risk result based on the TLS protocol version information supported by the client in the ClientHello message corresponding to the TLS session data; generates a security risk result based on the cipher suite selected by the server in the ServerHello message corresponding to the TLS session data; generates a preset security strength requirement result based on the ServerKeyExchange message in the TLS session data; generates a session decryption risk result based on the type of key exchange algorithm analyzed; parses the Certificate message sent by the server involved in the TLS session data to obtain basic certificate information; generates a server verification result based on the basic certificate information; the server verification result includes: server certificate validity verification, domain name matching verification, certificate signature legality verification, and certificate chain integrity verification; generates a certificate transparency log verification result based on the public CT log server corresponding to the server certificate; sends a server certificate status query request to the CA's OCSP response server through OCSP to obtain a certificate revocation status query result; and summarizes the protocol downgrade risk result, security risk result, preset security strength requirement result, session decryption risk result, server verification result, certificate transparency log verification result, and certificate revocation status query result to generate a risk generation report.

[0050] In addition, this application embodiment also provides a non-volatile computer storage medium storing executable instructions, which, when executed, implement the above-described method for HTTPS data transmission security status detection based on network protocol analysis.

[0051] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for detecting the security status of HTTPS data transmission based on network protocol analysis, characterized in that, The method includes: Obtain TLS session data in the target network environment through the network interface; Based on the TLS protocol version information supported by the client in the ClientHello message corresponding to the TLS session data, generate a protocol downgrade risk result; based on the cipher suite selected by the server in the ServerHello message corresponding to the TLS session data, generate a security risk result; based on the ServerKeyExchange message in the TLS session data, generate a preset security strength requirement result; based on the analysis of the key exchange algorithm type, generate a session decryption risk result, specifically including: Parse the ClientHello message corresponding to the TLS session data to extract the list of TLS protocol versions supported by the client, the list of cipher suites, the client's random number, and extended field information. Based on the TLS protocol version list, cipher suite list, client random number, and extended field information, determine the protocol versions supported by the client. If the protocol version is lower than the preset version, determine that there is a protocol downgrade risk; otherwise, determine that there is no protocol downgrade risk. Parse the ServerHello message corresponding to the TLS session data to extract the cipher suite selected by the server. Compare the server-selected cipher suite with the preset security cipher suite whitelist. If the selected cipher suite is not in the whitelist... If the security risk is determined to exist, it is determined to exist otherwise. The ServerKeyExchange message corresponding to the TLS session data is parsed to extract the server-side key exchange parameters. The security strength of the key exchange parameters is verified to meet preset requirements. If the preset requirements are met, the preset security strength requirement is determined to be met; otherwise, the preset security strength requirement is determined to be not met. The type of key exchange algorithm corresponding to the TLS session data is parsed. If the key exchange algorithm type supports forward secrecy, the session decryption risk is determined to be non-existent; otherwise, the session decryption risk is determined to be present. Based on the Certificate message sent by the server involved in the TLS session data, the basic certificate information is obtained by parsing; based on the basic certificate information, the server verification result is generated; the server verification result includes: server certificate validity period verification, domain name matching verification, certificate signature legality verification, and certificate chain integrity verification; Based on the public CT log server corresponding to the server certificate, generate the certificate transparency log verification result; send a server certificate status query request to the CA's OCSP response server through OCSP to obtain the certificate revocation status query result; The system summarizes the results of protocol downgrade risk, security risk, preset security strength requirements, session decryption risk, server verification, certificate transparency log verification, and certificate revocation status query, and generates a risk generation report.

2. The HTTPS data transmission security status detection method based on network protocol analysis according to claim 1, characterized in that, Obtain TLS session data from the target network environment through the network interface, specifically including: Real-time capture of communication data in the target network environment via network interface; Based on the TCP / IP protocol stack, the captured communication data is parsed in layers to identify the port information of the transport layer and filter out the communication traffic of the target port. The selected traffic is identified by application layer protocol identification. By analyzing the protocol header feature fields of the data packets, complete TLS session data is extracted from the communication traffic with HTTPS / TLS protocol header feature fields.

3. The HTTPS data transmission security status detection method based on network protocol analysis according to claim 1, characterized in that, Based on the Certificate message sent by the server involved in the TLS session data, the basic certificate information is obtained by parsing. Based on the basic certificate information, a server verification result is generated. This result includes: server certificate validity verification, domain name matching verification, certificate signature validity verification, and certificate chain integrity verification. Specifically, it includes: Based on the Certificate message sent by the server involved in the TLS session data, parse the X.509 certificate format and extract the following structured fields: certificate version, serial number, signature algorithm identifier, issuer information, validity period, user information, alternate name of the principal, and public key information; The certificate's effective and expiration times are compared with the current system time. If the current time is earlier than the effective time or later than the expiration time, the server certificate validity period verification result is determined to be abnormal; otherwise, the server certificate validity period verification is determined to be normal. The system matches and verifies the target domain name actually accessed by the user against the Common Name field and the Alternate Name field in the certificate. If the target domain name does not match any of the domain name fields in the certificate, the certificate domain name is determined to be mismatched, and the domain name matching verification is marked as having a domain name spoofing risk. Otherwise, the domain name matching verification is marked as not having a domain name spoofing risk. Based on the principle of asymmetric encryption, the public key of the issuing CA is used to decrypt the digital signature of the current certificate to obtain the certificate digest value; at the same time, the digest value of the TBS part of the certificate is recalculated using the signature algorithm identified in the certificate; the two digest values ​​are compared, and if they match, the signature verification is successful; if they do not match, it is determined that the certificate signature has been tampered with or the certificate is a forged certificate. Starting with the server certificate, trace the certificate chain upwards level by level, determine whether the certificate chain is incomplete, and generate the corresponding certificate chain integrity verification result.

4. The HTTPS data transmission security status detection method based on network protocol analysis according to claim 1, characterized in that, Generate certificate transparency log verification results based on the public CT log server corresponding to the server certificate; By sending a server certificate status query request to the CA's OCSP response server through OCSP, the certificate revocation status query result is obtained, specifically including: Query the publicly available CT log server corresponding to the server certificate to verify whether the server certificate has been recorded in the CT log. If no corresponding record for the server certificate is found in any CT log, the certificate transparency log verification result indicates a risk of forgery. Otherwise, the certificate transparency log verification result indicates no risk of forgery. The OCSP sends a certificate status query request to the CA's OCSP response server to query the revocation status of the server certificate and each intermediate certificate in the certificate chain. If any certificate has been revoked, the certificate revocation status query result is determined to be that the certificate is invalid; otherwise, the certificate revocation status query result is determined to be that the certificate is valid.

5. The HTTPS data transmission security status detection method based on network protocol analysis according to claim 1, characterized in that, The report summarizes the results of protocol downgrade risk assessment, security risk assessment, preset security strength requirement assessment, session decryption risk assessment, server verification assessment, certificate transparency log verification assessment, and certificate revocation status query, and generates a risk report, which includes: The results of all detection dimensions are standardized and encoded to convert qualitative judgments into weighted risk scores. Among them, the existence of protocol downgrade risk, security risk, failure to meet preset security strength requirements, historical session decryption risk, abnormal validity period, domain name mismatch, invalid signature, incomplete certificate chain, no CT log record, and certificate revocation are all marked as risk items with 1 point, while the corresponding compliance results without risk are marked as 0 points. All results are integrated into a structured risk dataset. Based on the risk dataset, risk levels are categorized and aggregated. Risk weights are assigned according to the impact of different detection items on HTTPS transmission security. Among them, certificate revocation, domain name mismatch, and illegal signature are preset high-risk items with a weight coefficient of 2; protocol downgrade, insecure encryption suite, and incomplete certificate chain are preset medium-risk items with a weight coefficient of 1; and missing CT logs, insufficient key strength, and lack of forward secrecy are preset low-risk items with a weight coefficient of 0.

5. The overall risk score of the target HTTPS session is calculated. At the same time, all risk points are sorted into high-risk, medium-risk, and low-risk categories to form risk detail entries, and a report with overall risk quantification results is output.

6. A security status detection system for HTTPS data transmission based on network protocol analysis, characterized in that, The system includes: The acquisition module is used to acquire TLS session data in the target network environment through the network interface; The first result module is used to generate protocol downgrade risk results based on the TLS protocol version information supported by the client in the ClientHello message corresponding to the TLS session data; generate security risk results based on the cipher suite selected by the server in the ServerHello message corresponding to the TLS session data; generate preset security strength requirement results based on the ServerKeyExchange message in the TLS session data; and generate session decryption risk results based on the type of key exchange algorithm analyzed, specifically including: Parse the ClientHello message corresponding to the TLS session data to extract the list of TLS protocol versions supported by the client, the list of cipher suites, the client's random number, and extended field information. Based on the TLS protocol version list, cipher suite list, client random number, and extended field information, determine the protocol versions supported by the client. If the protocol version is lower than the preset version, determine that there is a protocol downgrade risk; otherwise, determine that there is no protocol downgrade risk. Parse the ServerHello message corresponding to the TLS session data to extract the cipher suite selected by the server. Compare the server-selected cipher suite with the preset security cipher suite whitelist. If the selected cipher suite is not in the whitelist... If the security risk is determined to exist, it is determined to exist otherwise. The ServerKeyExchange message corresponding to the TLS session data is parsed to extract the server-side key exchange parameters. The security strength of the key exchange parameters is verified to meet preset requirements. If the preset requirements are met, the preset security strength requirement is determined to be met; otherwise, the preset security strength requirement is determined to be not met. The type of key exchange algorithm corresponding to the TLS session data is parsed. If the key exchange algorithm type supports forward secrecy, the session decryption risk is determined to be non-existent; otherwise, the session decryption risk is determined to be present. The second result module is used to parse and obtain basic certificate information based on the Certificate message sent by the server involved in the TLS session data; and generate server verification results based on the basic certificate information; wherein, the server verification results include: server certificate validity period verification, domain name matching verification, certificate signature legality verification, and certificate chain integrity verification; The third result module is used to generate certificate transparency log verification results based on the public CT log server corresponding to the server certificate; and to send a server certificate status query request to the CA's OCSP response server through OCSP to obtain the certificate revocation status query result. The aggregation module is used to aggregate results of protocol downgrade risk, security risk, preset security strength requirements, session decryption risk, server verification, certificate transparency log verification, and certificate revocation status query, and generate a risk generation report.

7. The HTTPS data transmission security status detection system based on network protocol analysis according to claim 6, characterized in that, The acquisition module is used to capture communication data in the target network environment in real time through the network interface; Based on the TCP / IP protocol stack, the captured communication data is parsed in layers to identify the port information of the transport layer and filter out the communication traffic of the target port. The selected traffic is identified by application layer protocol identification. By analyzing the protocol header feature fields of the data packets, complete TLS session data is extracted from the communication traffic with HTTPS / TLS protocol header feature fields.

8. A security status detection device for HTTPS data transmission based on network protocol analysis, characterized in that, The device includes: processor; And a memory storing executable code, which, when executed, causes the processor to perform a network protocol analysis-based HTTPS data transmission security status detection method as described in any one of claims 1-5.

9. A non-volatile computer storage medium, characterized in that, It stores computer instructions, which, when executed, implement a method for detecting the security status of HTTPS data transmission based on network protocol analysis as described in any one of claims 1-5.

Images