Non-perception encryption link establishment method and device

Abstract

The invention discloses a non-perception encrypted link establishment method and device. The method comprises the following steps: acquiring an encrypted link establishment request; according to the encrypted link establishment request, judging whether the establishment of an encrypted link needs to restart a server or not; if the server needs to be restarted for establishing the encrypted link, performing link establishment processing under a restart service to obtain a non-perceptual encrypted link; and if the encrypted link establishment does not need to restart the server, performing link establishment processing under a non-restart service to obtain the non-perceptual encrypted link. According to the invention, different link establishment processing can be adopted according to whether the server is restarted or not, so that the establishment of the encrypted link is realized, the security and the compatibility are improved, and the complexity and the cost of system upgrading are reduced. The method can be widely applied to the technical field of computers.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method and device for establishing a non-perceptual encrypted link. Background Art

[0002] With the rapid development and widespread application of the Internet, the frequency and complexity of network attacks are increasing, and network security issues are becoming increasingly prominent. During data transmission, the SSL / TLS protocol can ensure the confidentiality, integrity and authenticity of data by encrypting data. Traditional communication methods use HTTP for communication without encryption, and data is extremely vulnerable to man-in-the-middle attacks, traffic hijacking and data theft during transmission. In the encrypted communication method, the national secret algorithm is used for data transmission, but its software and hardware support requires a significant transformation of the browser or client, resulting in increased complexity and cost of system upgrades and low compatibility. At the same time, usually only the server identity is verified, there is a potential risk of client attacks, and the security is low.

[0003] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the invention

[0004] The embodiments of the present invention provide a method and device for establishing a non-perceptual encrypted link, which effectively improves security and compatibility and reduces the complexity and cost of system upgrades.

[0005] On the one hand, an embodiment of the present invention provides a method for establishing an imperceptible encrypted link, comprising the following steps:

[0006] Get the encryption link establishment request;

[0007] Determining whether the encrypted link establishment requires restarting the server according to the encrypted link establishment request;

[0008] If the establishment of an encrypted link requires restarting the server, the link establishment process is performed under the restart service to obtain an unaware encrypted link;

[0009] If the establishment of the encrypted link does not require restarting the server, the link establishment process is performed under the non-restart service to obtain the imperceptible encrypted link.

[0010] In some embodiments, the link establishment process under the restart service is performed to obtain an imperceptible encrypted link, including:

[0011] Get the target class name;

[0012] According to the target class name, construct a first class name conversion function;

[0013] Build enhanced server class functions;

[0014] Constructing a server secure socket layer conversion class according to the first class name conversion function and the enhanced server class function;

[0015] According to the server secure socket layer conversion class, construct a server secure socket layer invisible connection class;

[0016] Creating a keystore and a truststore, the keystore containing a server secure socket layer certificate and the truststore containing a client certificate;

[0017] According to the server secure socket layer invisible connection class, setting the main startup parameters;

[0018] Generate a first list file according to the main startup parameter;

[0019] Build server startup script;

[0020] The server startup script is executed according to the key store, the trust store and the first manifest file to obtain the imperceptible encrypted link.

[0021] In some embodiments, the execution process of the first class name conversion function includes:

[0022] Get the server startup path;

[0023] Performing symbol conversion on the server startup path to obtain a server startup class name;

[0024] If the server startup class name is equal to the target class name, the enhanced server class function is executed.

[0025] In some embodiments, the execution process of the enhanced server class function includes:

[0026] Create a pool class;

[0027] Modify the bytecode of the pool class to obtain a first class;

[0028] Extracting a startup function from the first category;

[0029] generating secure socket layer connector configuration information;

[0030] Adding the secure socket layer connector configuration information to the startup function;

[0031] Perform format code conversion on the first category to obtain a conversion code.

[0032] In some embodiments, the performing of the link establishment process under the non-restart service to obtain the imperceptible encrypted link includes:

[0033] Get the process identifier;

[0034] Constructing a second class name conversion function according to the process identifier;

[0035] Construct enhanced application framework class functions;

[0036] Constructing an invisible connection secure socket layer file conversion class according to the second class name conversion function and the enhanced application framework class function;

[0037] According to the invisible connection secure socket layer file conversion class, construct a main proxy function;

[0038] According to the main proxy function, construct a dynamic secure socket layer invisible connection class;

[0039] According to the dynamic secure socket layer invisible connection class, setting invisible connection parameters;

[0040] Generate a second manifest file according to the invisible connection parameters;

[0041] Build invisible connection startup script;

[0042] According to the second manifest file, the invisible connection startup script is executed to obtain the imperceptible encrypted link.

[0043] In some embodiments, the execution process of the main proxy function includes:

[0044] Get the detection instance;

[0045] Adding the invisible connection secure socket layer file conversion class to the detection instance;

[0046] extracting loaded classes from the detection instance;

[0047] The loaded class is reconverted to obtain a target class.

[0048] In some embodiments, the execution process of the invisible connection startup script includes:

[0049] Get input parameters;

[0050] Dividing the input parameters to obtain the process identifier and the invisible connection path;

[0051] According to the process identifier, a virtual machine connection process is performed to obtain a target virtual machine;

[0052] Performing proxy loading on the target virtual machine according to the invisible connection path;

[0053] The target virtual machine after the agent is loaded is separated.

[0054] In some embodiments, when the establishment of the encrypted link requires restarting the server, the method further includes:

[0055] Get the agent package;

[0056] Integrate the agent program package with the dependency package of the online client product to obtain an integrated package;

[0057] According to the integration package, the server is restarted so that the online client product loads the encryption certificate and realizes the establishment of an imperceptible encryption link.

[0058] In some embodiments, when the encrypted link establishment does not require restarting the server, the method further includes:

[0059] Get the process identifier, certification path, and agent package;

[0060] The agent package is executed according to the process identifier and the certificate path to achieve imperceptible encryption link establishment.

[0061] On the other hand, an embodiment of the present invention provides a device for establishing a non-perceptual encrypted link, including:

[0062] The first module is used to obtain an encrypted link establishment request;

[0063] The second module is used to determine whether the establishment of the encrypted link requires restarting the server according to the encrypted link establishment request;

[0064] The third module is used to perform link establishment processing under the restart service if the establishment of the encrypted link requires restarting the server to obtain an imperceptible encrypted link;

[0065] The fourth module is used to perform link establishment processing under non-restart service if the establishment of the encrypted link does not require restarting the server to obtain the imperceptible encrypted link.

[0066] The beneficial effects of the present invention are as follows:

[0067] The embodiment of the present invention first obtains a request to establish an encrypted link, and then determines whether the establishment of the encrypted link requires restarting the server based on the request to establish the encrypted link. If the establishment of the encrypted link requires restarting the server, link establishment processing is performed under the restart service to obtain an imperceptible encrypted link; if the establishment of the encrypted link does not require restarting the server, link establishment processing is performed under the non-restart service to obtain an imperceptible encrypted link, so that different link establishment processing can be adopted according to whether the server is restarted to achieve the establishment of the encrypted link, thereby improving security and compatibility and reducing the complexity and cost of system upgrades.

[0068] Other features and advantages of the present invention will be described in the following description, and partly become apparent from the description, or understood by practicing the present invention. The purpose and other advantages of the present invention can be realized and obtained by the structures particularly pointed out in the description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0070] Figure 1 This is a flow chart of a method for establishing a non-perceptual encrypted link according to an embodiment of the present invention;

[0071] Figure 2 A schematic diagram of a Tomcat server startup script according to an embodiment of the present invention;

[0072] Figure 3 A schematic diagram of a Spring Boot server startup script according to an embodiment of the present invention;

[0073] Figure 4 A schematic diagram of a program code for enhancing an application framework class function according to an embodiment of the present invention;

[0074] Figure 5 A schematic diagram of a process of establishing an encrypted link when restarting a server according to an embodiment of the present invention;

[0075] Figure 6 A schematic diagram of a process of establishing an encrypted link without restarting the server according to an embodiment of the present invention;

[0076] Figure 7 A schematic diagram of a process of a user using a client according to an embodiment of the present invention;

[0077] Figure 8 This is an architectural diagram of a user establishing an encrypted link according to an embodiment of the present invention;

[0078] Fig. 9 A schematic diagram of the structure of a device for establishing a non-perceptual encrypted link according to an embodiment of the present invention. DETAILED DESCRIPTION

[0079] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is further described in detail below in conjunction with the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the embodiments of the present application. They are only examples of devices and methods consistent with some aspects of the embodiments of the present application as detailed in the attached claims.

[0080] It is understood that the terms "first", "second", etc. used in this application can be used to describe various concepts in this article, but unless otherwise specified, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another concept. For example, without departing from the scope of the embodiment of the present application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the words "if" and "if" as used herein can be interpreted as "at the time of" or "when" or "in response to determination".

[0081] The terms "at least one", "multiple", "each", "any", etc. used in this application, at least one includes one, two or more, multiple includes two or more, each refers to each of the corresponding multiple, and any refers to any one of the multiple.

[0082] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0083] Before describing the embodiments of the present application in detail, some nouns and terms involved in the embodiments of the present application are first described. The nouns and terms involved in the embodiments of the present application are subject to the following explanations.

[0084] SSL (Secure Socket Layer): It is a network security protocol first adopted by Netscape. It is a security protocol implemented on the transmission communication protocol (TCP / IP) and uses public key technology. SSL widely supports various types of networks and provides three basic security services, all of which use public key technology.

[0085] Transport Layer Security (TLS): Used to provide confidentiality, data integrity, and authenticity between two communicating applications.

[0086] In related technologies, with the rapid development and widespread application of the Internet, network security issues have become increasingly prominent. In order to ensure that data is not eavesdropped or tampered with during transmission, the SSL / TLS protocol has become the mainstream technical standard for protecting network communication security. SSL / TLS ensures the confidentiality, integrity and authenticity of data by encrypting the transmitted data, and is widely used in e-commerce, online banking and other fields. However, although SSL / TLS technology is quite mature, many old Web systems still use HTTP plain text to transmit data, which poses a security risk. On the other hand, some emerging encryption standards (such as the national encryption algorithm) face compatibility issues when switching to these new standards due to their special hardware and browser requirements. Therefore, without the need for large-scale transformation of existing systems, establishing encrypted links for these systems without perception has become a technical challenge that needs to be solved urgently.

[0087] As the frequency and complexity of network attacks increase, the demand for network communication security in enterprises and institutions continues to escalate. The widespread use of SSL / TLS protocols has enhanced the security of network communications. However, the following prominent issues still exist in the network environment: (1) Unencrypted communication risks: A large number of traditional Web systems still communicate through HTTP due to historical reasons. In the absence of SSL / TLS encryption, data in such systems is extremely vulnerable to man-in-the-middle attacks, traffic hijacking, and data theft during transmission. With the increase in regulations and compliance requirements, such as GDPR and HIPAA, enterprises must ensure the security of their user data during transmission. (2) Compatibility issues with national encryption standards: With the promotion and application of the National Cryptography Standard (hereinafter referred to as the National Cryptography Standard), more and more enterprises and government agencies have begun to gradually switch to the National Cryptography Standard encryption algorithm. The National Cryptography Standard requires specific software and hardware support (such as the National Cryptography Browser, the National Cryptography Certificate, etc.), which brings compatibility issues to traditional Web systems. In particular, some old systems, if the National Cryptography Standard is adopted, often require major modifications to the browser, client, etc., resulting in increased complexity and cost of system upgrades. (3) Increasing demand for two-way SSL: In high-security scenarios, many systems have begun to use two-way SSL authentication to ensure that not only the server identity is trustworthy, but the client identity must also be authenticated. This further improves security, but it also poses challenges to system configuration and user experience, especially when deployed on a large scale. (4) High cost of renovating old systems: Old systems were not designed with modern security requirements in mind. The complexity of system code and the loss of developers make the maintenance and upgrade of these systems a major challenge. Often, professional companies or teams are required to carry out the renovation, and the renovated system may face compatibility issues, further increasing costs and risks.

[0088] Furthermore, there are several common implementation solutions for solving the problems of SSL / TLS link establishment and network communication encryption, but each of these solutions has its own limitations. (1) Currently, most Web systems establish SSL / TLS links by installing SSL certificates on the browser side. Users access the server through the HTTPS protocol, and the server and browser complete the SSL handshake to establish an encrypted link. This method is the mainstream SSL implementation method, but it has the following limitations: high user awareness, users need to manually install certificates and switch browser addresses (from HTTP to HTTPS), which increases the complexity of use; compatibility issues, in the national encryption algorithm environment, a specific national encryption browser must be used, resulting in a significant impact on users during the system switching process, and may not be able to access normally due to compatibility issues between different browsers; two-way authentication is difficult, two-way SSL authentication requires both the client and the server to provide certificates, and users need to manually configure the client certificate, which is cumbersome. (2) Configuring SSL / TLS on the server side is a relatively common method, mainly by modifying the configuration file of the Web server (such as Tomcat, Nginx, etc.) to enable SSL. The specific steps include configuring the server certificate, private key, SSL port, etc. Although this solution can control the encrypted link from the server side, it still has the following problems: complex manual configuration. Each time you configure SSL, you need to manually modify the server configuration file, and key management, certificate renewal and other operations are complicated; high update cost. If the system needs to switch from traditional SSL to national encryption algorithms or other standards, a large number of configurations need to be changed, and there are problems with incompatibility with existing applications. Support for old systems is poor. Many old systems are difficult to enable SSL directly on the server side due to architectural reasons. In particular, the configuration requirements for two-way SSL authentication are more complicated. (3) Another common way is to add SSL support to systems that do not enable SSL by setting up a reverse proxy server (such as Nginx, HAProxy, etc.). The reverse proxy server is located between the client and the Web server, responsible for processing the SSL / TLS handshake and forwarding the request after decryption to the backend server. The advantages of this solution are: SSL support can be added to the old system. Even if the backend server does not enable SSL, the reverse proxy server can provide an encrypted link for external requests; it supports two-way authentication. The reverse proxy server can configure two-way SSL authentication to achieve two-way authentication between the client and the server. However, the reverse proxy solution also has limitations: complex configuration and maintenance. The configuration of the reverse proxy server itself is complex, especially when dealing with large-scale traffic and multi-certificate management, the maintenance cost is high; performance issues, SSL / TLS handshake and encryption and decryption operations will increase the performance overhead of the reverse proxy server and affect the system throughput; it cannot solve client compatibility issues. In some scenarios that require national encryption algorithms, the reverse proxy cannot solve the client's browser compatibility issues.

[0089] In view of this, the embodiment of the present invention adopts different link establishment processes according to whether to restart the server, and realizes a solution that is imperceptible, highly compatible, and can automatically establish an SSL / TLS encrypted link. It is particularly suitable for traditional systems that do not enable SSL, systems that need to switch to new encryption standards (such as national encryption algorithms), and scenarios that need to support two-way SSL authentication. The embodiment of the present invention provides efficient and secure communication protection without changing user operations and system configurations through the combination of bytecode enhancement, proxy technology, and JavaFX network proxy client, thereby improving security and compatibility and reducing the complexity and cost of system upgrades.

[0090] The embodiments of the present application can imperceptibly establish SSL / TLS encrypted links for existing Web systems, aiming to improve the security of network communications. They are applicable to the following scenarios and requirements: (1) Web systems that do not enable SSL links. Many traditional Web systems still rely on the HTTP protocol for communication, lack basic network encryption protection, and are vulnerable to man-in-the-middle attacks and data leakage threats. The hidden chain security technology solution can automatically establish SSL / TLS links for these systems without changing user operations and system configurations, greatly improving the security of their network communications and ensuring that data transmission is not stolen or tampered with. (2) Web systems that switch to new SSL links (such as national secret SSL). Many institutions (such as governments and financial institutions) are gradually adopting national secret algorithms for encryption, but because national secret algorithms require specific national secret browser support, many existing systems face compatibility issues during the migration process. The hidden chain security technology solution can seamlessly support switching from traditional SSL links to national secret SSL links through proxy technology, solving the problem of poor compatibility of existing browsers and avoiding the impact of upgrading encryption standards on normal user use. (3) Support two-way SSL links. Two-way SSL authentication requires both the client and the server to provide certificates for identity authentication to ensure that both parties in communication are authenticated. The hidden chain security technology solution can automatically handle the authentication process of the two-way SSL link without the user's awareness, ensuring the security of both parties' identities and the privacy of communications, without the need for manual configuration or adjustment by the user. (4) Improving the security of old systems. Many old systems have serious security vulnerabilities because modern security standards were not considered during the design. In addition, the system structure is complex and the maintenance cost is high, and usually requires specialized companies and personnel to upgrade and transform it. The hidden chain security technology solution provides a simple and efficient solution. It can automatically establish an encrypted link for the old system through proxy and bytecode enhancement technology without affecting the normal operation of the system, thereby improving its security and avoiding high-cost system reconstruction and maintenance. The embodiments of the present application are suitable for scenarios where it is not desirable to make large-scale modifications to the existing system but it is necessary to improve the security of network communications. It can provide enterprises with an efficient, transparent and low-cost network security upgrade path.

[0091] The embodiment of the present application provides a method for establishing an imperceptible encrypted link, which relates to the field of computer technology. The embodiment of the present application provides a method for establishing an imperceptible encrypted link, which can be applied to a terminal, a server, or a software running in a terminal or a server. In some embodiments, the terminal can be a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, and a car terminal, etc., but is not limited to this; the server side can be configured as an independent physical server, or a server cluster or distributed system composed of multiple physical servers, and can also be configured as a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network; the software can be an application that implements a method for establishing an imperceptible encrypted link, etc., but is not limited to the above forms.

[0092] The present application can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc. The present application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present application can also be practiced in distributed computing environments, in which tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

[0093] The following is a detailed explanation of the embodiments of the present application in conjunction with the accompanying drawings:

[0094] Figure 1 is an optional flowchart of a method for establishing an imperceptible encrypted link provided in an embodiment of the present application. Figure 1 The method may include but is not limited to steps S101 to S104.

[0095] Step S101: Obtain an encrypted link establishment request;

[0096] Step S102: judging whether the establishment of the encrypted link requires restarting the server according to the encrypted link establishment request;

[0097] Step S103: If the establishment of the encrypted link requires restarting the server, the link establishment process under the restart service is performed to obtain an imperceptible encrypted link;

[0098] Step S104: If the establishment of the encrypted link does not require restarting the server, the link establishment process is performed under the non-restart service to obtain an imperceptible encrypted link.

[0099] Steps S101 to S104 shown in the embodiment of the present application implement the establishment of an encrypted link, improve security and compatibility, and reduce the complexity and cost of system upgrades.

[0100] In some embodiments, in step S101-step S102, an encrypted link establishment request may be obtained from user request information. The encrypted link establishment request may also be obtained in other ways, not limited thereto. Then, according to the encrypted link establishment request, it is determined whether the encrypted link establishment requires restarting the server. It is understandable that restarting the server and not restarting the server will use different encrypted link establishment processes.

[0101] In some embodiments, in step S103, the link establishment process under the restart service is performed to obtain an imperceptible encrypted link, which may include but is not limited to the following steps:

[0102] Get the target class name;

[0103] According to the target class name, build the first class name conversion function;

[0104] Build enhanced server class functions;

[0105] According to the first class name conversion function and the enhanced server class function, a server secure socket layer conversion class is constructed;

[0106] According to the server secure socket layer conversion class, construct the server secure socket layer invisible connection class;

[0107] Create a keystore and a truststore. The keystore contains the server SSL certificate and the truststore contains the client certificate.

[0108] Set the main startup parameters according to the server SSL invisible connection class;

[0109] Generate a first list file according to the main startup parameters;

[0110] Build server startup script;

[0111] According to the key store, trust store and the first list file, the server startup script is executed to obtain an imperceptible encrypted link.

[0112] In some embodiments, if the establishment of an encrypted link requires restarting the server, the link establishment process is performed under the restart service to obtain an imperceptible encrypted link. The target class name can be obtained first. For example, Tomcat can be used as the server, and the target class name can be org.apache.catalina.startup.Tomcat. Then, according to the target class name, a first class name conversion function is constructed, an enhanced server class function is constructed, and a server secure socket layer conversion class is constructed according to the first class name conversion function and the enhanced server class function. Then, according to the server secure socket layer conversion class, a server secure socket layer stealth connection class is constructed. For example, the program code can be expressed as public class TomcatSslStealthlink{publicstatic void premain(String stealthlinkArgs,Instrumentation inst){inst.addTransformer(new TomcatSslTransformer());}}. It can be understood that StealthlinkTransformer is an extension of ClassFileTransformer, which inherits the ClassFileTransformer class, which is a standard class of java agent. This embodiment enhances the ClassFileTransformer class in order to obtain certificates and find the classes and methods that need to be enhanced in the web container, and enhances the methods in the class, such as enhancing the start method of the tomcat class. The original start method of the tomcat class did not execute the addSslConnector method during execution. This bytecode dynamic modification method can be used to make it execute addSslConnector, which is equivalent to modifying the bytecode in memory. Among them, the start method is the method for initializing the connector when Tomcat starts.

[0113] Then create a keystore and a truststore, where the keystore contains the server Secure Sockets Layer certificate and the truststore contains the client certificate. According to the server Secure Sockets Layer stealth connection class, set the main startup parameter Premain-Class to com.example.stealthlink.TomcatSslStealthlink, and generate the first manifest file (such as MANIFEST.MF file) based on the main startup parameter. It can be understood that the MANIFEST.MF file is the manifest file of the jar package, and this file can be used to specify which class's main method needs to be executed when the jar package is started. The Premain-Class class is the entry class for starting the jar package. This is a parameter. The javaagent (java agent) will load the Premain-Class parameter in the manifest file when it starts. Finally, build the server startup script, and execute the server startup script according to the keystore, truststore and the first manifest file to obtain an imperceptible encrypted link. For example, write a server startup script tomcat_start.sh. The Tomcat server startup script is as follows Figure 2 As shown, the steps include initializing parameters, defining variables, and parsing parameters. The program code for executing the server startup script can be expressed as . / tomcat_start.sh-Stealthlink= / path / to / stealthlink.jar-Dcert-path= / path / to / cert-Dcert-pass=yourpassword, where the -D parameter is to set the system variable for easy use in the Stealthlink class. It is understandable that when using Stealthlink, the application's class loader needs to be handled correctly. The keystore path and password can be passed through system properties or environment variables to externalize the configuration and avoid hard coding. Different versions of Spring Boot may have different method signatures, which need to be adjusted according to the actual version.

[0114] More, when using Spring Boot as the server, the target class name can be org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory. You can set the main startup parameter Premain-Class to com.example.stealthlink.SpringBootSslStealthlink. Write a server startup script start_springboot_app.sh. The Spring Boot server startup script is as follows Figure 3As shown, the steps include initializing variables, parsing parameters, checking whether necessary parameters are provided, building startup commands, printing startup commands, and starting applications. The program code for executing the server startup script can be expressed as / start app.sh--agent-path= / path / to / agent.jar--app-jar= / path / to / app.jar-Dcert-path= / path / to / cert-Dcert-pass=yourpassword--server.port=8081. Among them, the JAR package path of Stealthlink is passed as a parameter (--steal-path). The JAR package path of the application is passed as a parameter (--app-jar). The system property parameter starting with -D is passed as a parameter for use by the JVM (Java Virtual Machine).

[0115] In some embodiments, the execution process of the first class name conversion function includes:

[0116] Get the server startup path;

[0117] Perform symbol conversion on the server startup path to obtain the server startup class name;

[0118] If the server startup class name is equal to the target class name, the enhanced server class function is executed.

[0119] In some embodiments, the server startup path can be obtained first. For example, Tomcat can be used as the server, and the server startup path can be org / apache / catalina / startup / Tomcat. Then the server startup path is symbolically converted to obtain the server startup class name. For example, the program code can be expressed as StringclazzName=className.replace(" / ",".") where className represents the server startup path, and clazzName represents the server startup class name. If the server startup class name is equal to the target class name, the enhanced server class function is executed. For example, the program code can be expressed as if("org.apache.catalina.startup.Tomcat".equals(clazzName)){return enhanceTomcatClass(classfileBuffer);}. Wherein, enhanceTomcatClass represents the enhanced server class function. More importantly, when Spring Boot is used as the server, the program code of the execution process of the first class name conversion function can be expressed as String clazzName = className.replace(" / ","."); if("org.springframework.boot.web.embedded.tomcat.TomcatServletWebserverFactory".equals(clazzName))returnenhanceTomcatFactoryClass(classfileBuffer,loader);}.

[0120] In some embodiments, the execution process of the enhanced server class function includes:

[0121] Create a pool class;

[0122] Modify the bytecode of the pool class to get the first class;

[0123] Extract the startup function from the first category;

[0124] generating secure socket layer connector configuration information;

[0125] Add SSL connector configuration information to the startup function;

[0126] Perform format code conversion on the first category to obtain a conversion code.

[0127] In some embodiments, a pool class can be created first, and bytecode modification can be performed on the pool class to obtain a first class. Exemplarily, Tomcat can be used as the server, and the program code can be expressed as ClassPool pool = new classPool(true); CtClass ctClass = pool.makeClass(new ByteArrayInputStream(classfileBuffer)). Then, the startup function can be extracted from the first class. Exemplarily, the program code can be expressed as CtMethod method = ctClass.getDeclaredMethod("start"). Next, the secure socket layer connector configuration information can be generated. Exemplarily, the program code can be expressed as CtMethod addSslConnector = CtNewMethod.make("private void addSslconnector(){" + "org.apache.catalina.connector.Connector connector = new org.apache.catalina.connector.Connector();" + "connector.setPort(8443);" + "connector.setSecure(true);" + "connector.setScheme(\"https\");" + "connector.setAttribute(\"keystoreFile\",\"path / to / keystore.jks\");" + "connector.setAttribute(\"keystorePass\",\"yourKeystorePassword\");" + "connector.setAttribute(\"clientAuth\",\"true\");" + "connector.setAttribute(\"sslProtocol\",\"TLS\");" + "connector.setAttribute(\"SSLEnabled\",true);" + "this.getService().addConnector(connector);" + "}", ctClass);Finally, the secure socket layer connector configuration information is added to the startup function, and the format code of the first class is converted to obtain the conversion code. Exemplarily, the program code can be expressed as ctClass.addMethod(addSslConnector); byte[]byteCode=ctClass.toBytecode().

[0128] More importantly, when Spring Boot is used as the server, the program code of the execution process of the first class name conversion function can be expressed as ClassPool pool=new ClassPool(true); pool.insertClassPath(newLoaderClassPath(loader)); CtClass ctClass=pool.makeClass(new ByteArrayInputStream(classfileBuffer)); CtMethod method=ctClass.getDeclaredMethod("getWebServer");method.insertBefore("{configureSsl(this);}"); / / Add configureSsl method;CtMethod configureSsl=CtNewMethod.make("private void configuressl(org.springframework.boot.web.embedded.tomcat.TomcatServletWebserverFactory factory){"+"org.springframework.boot.web.server.Sslssl=new org.springframework.boot.web.server.Ssl();"+"ssl.setKeyStore(\"path / to / keystore.jks\");"+"ssl.setKeyStorePassword(\"yourKeystorePassword\");"+"ssl.setClientAuth(o rg.springframework.boot.web.server.Ssl.ClientAuth.NEED);"+"factory.setSsl(ssl);"+"}",ctClass};ctClass.addMethod(configureSsl);byte[]byteCode=ctClass.toBytecode().

[0129] In some embodiments, in step S104, a link establishment process is performed under a non-restart service to obtain an imperceptible encrypted link, which may include but is not limited to the following steps:

[0130] Get the process identifier;

[0131] According to the process identifier, construct the second type name conversion function;

[0132] Construct enhanced application framework class functions;

[0133] According to the second class name conversion function and the enhanced application framework class function, an invisible connection secure socket layer file conversion class is constructed;

[0134] According to the invisible connection secure socket layer file conversion class, build the main proxy function;

[0135] According to the main proxy function, construct a dynamic secure socket layer invisible connection class;

[0136] According to the dynamic secure socket layer invisible connection class, set invisible connection parameters;

[0137] Generate a second list file according to the invisible connection parameters;

[0138] Build invisible connection startup script;

[0139] According to the second list file, execute the invisible connection startup script to obtain an imperceptible encrypted link.

[0140] In some embodiments, an invisible connection is dynamically attached to a running Java process, and the behavior of the application can be dynamically modified without interrupting the service to achieve SSL two-way authentication. The process identifier can be obtained first. For example, the PID of the running Java process, i.e., the process identifier, can be obtained using a system command or a tool provided by Java. Then, based on the process identifier, a second class name conversion function is constructed. For example, the program code of the execution process of the second class name conversion function can be expressed as String clazzName = className.replace(" / ","."); if("org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory".equals(clazzName)){return enhanceSpringBootClass(classfileBuffer,loader);}. Among them, enhanceSpringBootClass represents an enhanced application framework class function. Construct an enhanced application framework class function. For example, the program code of the enhanced application framework class function is as follows: Figure 4As shown, its execution process includes creating a pool class, obtaining service methods, generating connector configuration information, adding configuration information and converting format codes. Then, according to the second class name conversion function and the enhanced application framework class function, the invisible connection secure socket layer file conversion class StealthlinkSslclassFileTransformer is constructed, and according to the invisible connection secure socket layer file conversion class, the main agent function agentmain is constructed, and according to the main agent function, the dynamic secure socket layer invisible connection class DynamicSslStealthlink is constructed. It can be understood that the main agent function agentmain is the entry method for modifying the behavior of the target jvm at runtime. Then, according to the dynamic secure socket layer invisible connection class, the invisible connection parameter Stealthlink-Class:com.example.stealthlink.DynamicSslStealthlink is set. In addition, the parameters can also include Can-Redefine-Classes:true; Can-Retransform-Classes:true, which is used to load the dynamic secure socket layer invisible connection class when the jvm starts. Then, according to the stealth connection parameters, generate the second manifest file (MANIFEST.MF file). The program code for packaging the second manifest file can be expressed as jarcvfm dynamic-ssl-steallink.jar MANIFEST.MF com / example / steallink / *.class. Finally, build the stealth connection startup script, and execute the stealth connection startup script according to the second manifest file to obtain an imperceptible encrypted link. Exemplarily, the program code for executing the stealth connection startup script can be expressed as java-cp.:$JAVA_HOME / lib / tools.jar com.example.steallink.SteallinkStart <pid> / path / to / dynamic-ssl-steallink.jar.

[0141] In some embodiments, the execution process of the main proxy function includes:

[0142] Get the detection instance;

[0143] Added invisible connection secure socket layer file conversion class to detection instance;

[0144] Extract loaded classes from instrumented instances;

[0145] Re-transform the loaded class to obtain the target class.

[0146] In some embodiments, the detection instance Instrumentation inst can be first obtained as an input parameter, and then the stealthlink Secure Sockets Layer file transformation class stealthlinkSslclassFileTransformer is added to the detection instance. For example, the program code can be represented as inst.addTransformer(new stealthlinkSslclassFileTransformer(), true). Then, the loaded class is extracted from the detection instance. For example, the program code can be represented as Class<?>[]loadedClasses=inst.getAllLoadedClasses(). Finally, the loaded class is retransformed to obtain the target class. For example, the program code can be expressed as for(Class<?>clazz:loadedClasses){if(clazz.getName().equals("org.apache.catalina.startup.Tomcat")||clazz.getName().equals("org.springframework.boot.web.embedded.tomcat.TomcatServletWebserverFactory")){if(inst.isModifiableclass(clazz)){try{inst.retransformClasses(clazz);}catch(UnmodifiableclassExceptione){e.printStackTrace();}}}}。

[0147] In some embodiments, the execution process of the invisible connection startup script includes:

[0148] Get input parameters;

[0149] Divide the input parameters to obtain the process identifier and invisible connection path;

[0150] According to the process identifier, the virtual machine connection processing is performed to obtain the target virtual machine;

[0151] According to the invisible connection path, the target virtual machine is loaded with a proxy;

[0152] Detach the target virtual machine after the agent is loaded.

[0153] In some embodiments, the input parameter args can be obtained first. If the number of input parameters is 2, the input parameters are divided to obtain the process identifier pid and the stealthlinkPath. Then, according to the process identifier, the virtual machine connection processing is performed to obtain the target virtual machine vm. Exemplarily, the program code can be expressed as VirtualMachinevm=VirtualMachine.attach(pid). Then, according to the stealth connection path, the target virtual machine is loaded by an agent. Exemplarily, the program code can be expressed as vm.loadAgent(stealthlinkPath). Finally, the target virtual machine after the agent is loaded is separated. Exemplarily, the program code can be expressed as vm.detach().

[0154] In some embodiments, when the establishment of the encrypted link requires restarting the server, the method further includes:

[0155] Get the agent package;

[0156] Integrate the proxy package with the dependency package of the online client product to obtain an integrated package;

[0157] According to the integration package, the server is restarted so that the online client product can load the encryption certificate and establish an imperceptible encrypted link.

[0158] In some embodiments, the process of establishing an encrypted link under the restart server is as follows: Figure 5 As shown, you can first obtain the agent package (custom jar package, such as security-tls.jar), integrate the agent package with the dependency package of the online client product, and obtain the integrated package. It is understandable that the agent package (security-tls.jar) is placed in the public jar package of the backend service. Take the war package loaded by the tomcat server as an example: generally, this public jar package will be in the webapps / project / WEB-INF / lib directory of tomcat. Then restart the server according to the integrated package, so that the online client product loads the encryption certificate and realizes the establishment of an imperceptible encrypted link. It is understandable that the ssl certificate (encryption certificate) needs to be stored in a directory of the server in advance (such as / home / cert). When restarting the tomcat server, tomcat needs to do some configuration, and start.sh in the bin directory of tomcat cannot be executed directly. When executing this script, you need to add system variables, such as start.sh-Dcert-path= / home / cert-Dcert-pass=12345, which will be referenced in the security-tls.jar package. Furthermore, if two-way authentication is required, the client private key certificate needs to be manually imported. The client configuration process is similar to the server configuration process.

[0159] In some embodiments, when the encrypted link establishment does not require restarting the server, the method further includes:

[0160] Get the process identifier, certification path, and agent package;

[0161] Based on the process identifier and the certificate path, the agent package is executed to achieve the establishment of an imperceptible encrypted link.

[0162] In some embodiments, the process of establishing an encrypted link without restarting the server is as follows: Figure 6 As shown, the process identifier, certificate path and agent package can be obtained first. For example, the PS command can be executed to view the java process that needs to implement ssl communication and obtain the process identifier pid. It can be understood that the PS command is one of the Linux system commands and is a command for viewing processes in Linux. The ssl certificate (encryption certificate) needs to be stored in a directory of the server in advance (such as / home / cert), which can include the server private key certificate or the client CA certificate. Then, according to the process identifier and certificate path, the agent package is executed to achieve the establishment of an imperceptible encrypted link. For example, the hidden chain jar package (i.e., the agent package) is a server service package, and the program code for executing the agent package can be expressed as java-Dattach-id=pid-Dcert-path= / home / cert (certificate path)-Dcert-pass=12345 (private key password)-jar security-tls.jar. Furthermore, if you want to implement two-way SSL authentication or national encryption standard links, the client's private key certificate is issued by the server's client CA (Certification Authority), and the operation and maintenance personnel must distribute the client's private key certificate to the customer personnel and import the certificate into the hidden chain client (security-tls-client). If you do not need SSL two-way authentication, but only ordinary RSA one-way authentication, no additional operations are required, and security-tls-client will automatically obtain the public key certificate sent by the server.

[0163] In some embodiments, a user uses a client process such as Figure 7 As shown, you can first download and install the client, then start the client, the client obtains the unified configuration, and loads the configuration to facilitate the subsequent execution of the agent package, thereby achieving the establishment of an imperceptible encrypted link.

[0164] In some embodiments, the user establishes an encrypted link architecture such as Figure 8 As shown, the user interacts with the browser, forwards the traffic to the web server (which may include tomcat, jetty, jboss, or websphere) through the client proxy (which may include domain name resolution, blacklists or whitelists, or traffic forwarding), loads the certificate and key through the java ASM proxy, and establishes an imperceptible encrypted link.

[0165] In some embodiments, the client is a proxy interceptor that can intercept all traffic and set a black and white list to control which traffic to intercept to implement the SSL channel. However, to parse the traffic, not all traffic can be intercepted. A configuration item can be set, but the client does not know how to set it, so the client needs to obtain the message through the message middleware, obtain the configuration message and the client's private key certificate from the message, etc. This message is sent to the message middleware after the Stealthlink deployment is completed, and other means can also be used to publish the message. The javaFX client can be used to customize the development of receiving emails or other messages, etc. The architecture design of this embodiment can be implemented using kafka as the middleware. If it is in a cloud environment, the client's private key certificate can be manually uploaded by the client. The private key certificate of the client is issued by the client CA in the message middleware, and the client private key certificate of the message middleware needs to be issued offline. In this way, a secure channel between the client and the message middleware is realized. In this way, the client receives the message safely and reliably. After receiving the message, the client reads the message to obtain the certificate and configuration item in it to start the proxy server. In this way, it is still access to the ordinary http protocol for the client, and the client realizes the SSL link without perception. Furthermore, if the server and the message middleware are in the same cluster environment, it is not necessary to configure the certificate like the client. If the server and the message middleware are two separate environments and are accessed through the public network, the same configuration as the client is required, otherwise the channel between the server and the message middleware is unsafe. In addition, the underlying technical implementation of Stealthlink is based on java bytecode enhancement technology. During operation, the java bytecode is enhanced through the java agent to realize the dynamic ssl capability. This embodiment uses the agent technology to dynamically expand the ability of web middleware (tomcat, jetty, websphere, springboot, etc.) to handle the ssl authentication process, and on this basis, it is encapsulated to a certain extent through the dynamic parameters of the shell script, and at the same time, the message notification technology is used to realize the distribution of certificates to achieve the establishment of imperceptible encrypted links.

[0166] The beneficial effects of implementing the embodiments of the present invention include: the embodiments of the present invention first obtain a request to establish an encrypted link, and then determine whether the establishment of the encrypted link requires restarting the server based on the request to establish the encrypted link; if the establishment of the encrypted link requires restarting the server, link establishment processing is performed under the restart service to obtain an imperceptible encrypted link; if the establishment of the encrypted link does not require restarting the server, link establishment processing is performed under the non-restart service to obtain an imperceptible encrypted link, so that different link establishment processing can be adopted according to whether the server is restarted to achieve the establishment of the encrypted link, thereby improving security and compatibility and reducing the complexity and cost of system upgrades.

[0167] In some embodiments, the core classes of the Web server can be dynamically modified at runtime through bytecode enhancement technology, and the SSL / TLS encrypted link can be automatically established without modifying the server configuration file or client operation. The SSL-related classes of the Web server are enhanced using bytecode enhancement technology (such as ASM or Javassist), and the establishment logic of the inserted SSL link is designed. In traditional Web systems where SSL / TLS is not enabled, the creation of encrypted links without perception is achieved through proxy and bytecode enhancement technology, and the user operation and network address remain unchanged.

[0168] This embodiment seamlessly supports the switch from the traditional SSL link to the national encryption SSL link through the proxy technology, solves the problem of poor compatibility of existing browsers, avoids the client's dependence on a specific national encryption browser, and improves compatibility. The function of automatically switching encryption standards is realized, and the existing system does not need to be modified, and supports switching from a standard SSL / TLS link to a national encryption SSL link. The JavaFX client can be used to establish a national encryption SSL link with the server, solving the compatibility problem of the national encryption link without changing the user's browser and operating habits.

[0169] This embodiment supports two-way SSL authentication, and processes the two-way authentication of the client and the server imperceptibly through the proxy mechanism, ensuring the security of the identity authentication of both parties and the integrity of the communication encryption. The automatic establishment and authentication of the two-way SSL link is realized, and the user does not need to manually configure the client certificate or modify the system configuration. In a Web system that does not enable two-way SSL, the authentication and encryption of the two-way SSL link are realized through the proxy and bytecode enhancement technology.

[0170] This embodiment can use a JavaFX client, which is not only responsible for establishing an SSL link, but also provides domain name resolution, blacklist and whitelist management, and routing rule configuration to ensure that the system can flexibly handle traffic according to security policies. The JavaFX client dynamically configures domain name resolution to enable the proxy to intercept and route traffic for specific domain names. The JavaFX client can manage the blacklist and whitelist functions of network traffic to control which domain names or IPs can be accessed through the SSL link, thereby enhancing system security. Users can flexibly configure routing rules for network traffic through the client interface to determine how different types of traffic are processed and forwarded through the proxy.

[0171] This embodiment can establish an encrypted link for the old Web system through proxy and bytecode enhancement technology, solve the current situation of insufficient system design and many security vulnerabilities, and do not need to perform high-cost system reconstruction or maintenance. Through bytecode enhancement technology and proxy mechanism, SSL / TLS links are automatically established for the old system without changing the architecture and code of the old system, improving communication security. It automatically detects unencrypted communications and provides SSL link encryption solutions, which is suitable for Web applications with outdated designs and difficult system maintenance.

[0172] The proxy link of this embodiment can process all SSL / TLS communications imperceptibly, keeping the user's original operation consistent with the system behavior, and solving the problem of poor system compatibility when switching encrypted links. Through proxy technology, when users access unencrypted HTTP services, SSL / TLS encrypted links are transparently provided to them to ensure the consistency of system behavior and operating habits. It supports seamless switching between traditional encryption standards and national encryption standards. The proxy link automatically selects the encryption scheme according to system requirements to solve the compatibility problem in switching encrypted links.

[0173] This embodiment provides a secure and flexible SSL / TLS link establishment solution for the existing Web system through non-perceptual proxy and bytecode enhancement technology, significantly improving the system's network communication security. It mainly includes automatic establishment of SSL links, compatibility with national encryption standards, support for two-way authentication, and network management functions provided by the JavaFX client.

[0174] In some embodiments, automatic SSL / TLS link establishment can be achieved without changing user operations or modifying system configuration files. The beneficial effects of implementing this embodiment include imperceptible operation experience, no need to modify system configuration files, strong compatibility and support for national encryption, support for two-way SSL links, seamless security upgrades for old systems, flexible domain name resolution and flow control, and transparent proxy links to reduce performance overhead.

[0175] This embodiment does not require users to manually configure SSL / TLS certificates, modify browser settings, or change access URLs (such as switching from HTTP to HTTPS). This transparent link establishment avoids additional operations and cumbersome configurations for users, minimizing the impact of network security upgrades on users and systems. Compared with the prior art, most of the prior art requires users to manually configure certificates, or perform explicit switching on the browser side (such as HTTP to HTTPS), which increases the burden on users. In addition, users often need to modify browser or client configurations to adapt to the requirements of SSL / TLS encryption, and in some cases, compatibility issues may arise.

[0176] This embodiment can realize the automatic establishment of SSL / TLS links without modifying the server-side configuration files through bytecode enhancement and proxy technology. This greatly reduces the workload required for traditional SSL configuration, avoids errors and maintenance costs caused by manual modification of configuration files, and is particularly beneficial for old systems. Compared with the prior art, the establishment of traditional SSL links requires a lot of manual modifications to the server's configuration files (such as configuring SSL / TLS in Tomcat), and further modifications are required when switching to the national encryption algorithm. The prior art has poor support for old systems, and often requires specialized personnel to perform maintenance, which is cumbersome.

[0177] This embodiment not only supports conventional SSL / TLS links, but can also seamlessly switch to the national encryption standard, solving the compatibility problem under the national encryption standard. Since the national encryption algorithm requires specific national encryption browser support, many existing systems cannot smoothly switch to the national encryption link. This embodiment solves this compatibility problem through proxy technology, allowing the existing Web system to easily adapt to the national encryption link while keeping the user operation unchanged. Compared with the existing technology, the existing SSL / TLS technology often requires the client to use specific browsers and hardware support when switching to the national encryption standard, which greatly increases the compatibility problem. This embodiment can support seamless switching between traditional SSL and national encryption SSL, solving the difficulties faced by enterprises during the upgrade process.

[0178] This embodiment supports two-way SSL authentication in an imperceptible way. Users do not need to manually configure client certificates. The system automatically handles the authentication process to ensure the authenticity of the identities of both parties in communication and the security of data transmission. Two-way authentication is particularly important in scenarios with high security requirements such as finance, government, and other areas. Compared with the prior art, the configuration of traditional two-way SSL authentication is generally very complicated, especially the management and deployment of client certificates requires additional operations and configurations. This embodiment automates this process without user involvement, greatly simplifying the operation.

[0179] This embodiment uses proxy and bytecode enhancement technology to seamlessly provide SSL / TLS link support for old systems without the need to reconstruct the original code, thus avoiding high upgrade costs and complex technical requirements. Compared with the prior art, existing security upgrade solutions often require large-scale transformation of old systems, and such transformation usually requires reliance on a dedicated technical team and high maintenance costs. In contrast, this embodiment can improve the security of old systems with minimal system changes and in an imperceptible manner, greatly reducing the cost of maintenance and upgrades.

[0180] This embodiment can not only establish a secure SSL link through the JavaFX network proxy client, but also provide flexible domain name resolution, blacklist and whitelist management and routing rule configuration functions. This allows administrators to control which domain names or IPs can be accessed through the SSL link according to specific needs, enhancing security and management flexibility. Compared with the prior art, most existing SSL solutions only focus on the establishment of encrypted links, while ignoring the flexible management of domain name resolution and traffic control. This embodiment implements this function through the proxy client, which not only improves security, but also enhances the operability and customization capabilities of the system.

[0181] The proxy technology of this embodiment optimizes the performance overhead of the link while ensuring the establishment of a transparent SSL link. The proxy link can intelligently select the best encryption scheme (such as SSL / TLS or national encryption standards), and optimizes the load and performance, making it suitable for high-concurrency and large-scale enterprise applications. Compared with the prior art, the existing reverse proxy solutions usually have a large performance overhead, especially when processing a large number of encrypted links, which is prone to bottlenecks. This embodiment ensures a balance between performance and security through an optimized proxy link, so that the system can enjoy a secure link without sacrificing throughput.

[0182] In some embodiments, in the current network security field, there are some potential alternatives. Each alternative has certain application value in a specific scenario, but compared with the embodiments of the present invention, these alternatives usually have obvious limitations. The following are several common alternatives:

[0183] (1) The solution based on traditional SSL configuration is the most traditional way. It enables SSL / TLS links by manually configuring the Web server (such as Tomcat, Nginx, etc.). The administrator needs to configure certificates, keys, SSL ports, etc. on the server side and manually manage SSL / TLS encryption. This solution is simple to implement and widely used, and is the standard encryption method for many Web applications. However, it requires a lot of manual configuration, is prone to errors, and has high maintenance costs. It does not support old systems well, and many legacy systems find it difficult to directly apply this solution. Support for two-way SSL authentication and national encryption standards is complex, and switching or updating encrypted links requires a lot of configuration work. The traditional SSL configuration solution is suitable for simple encryption needs, but for systems that require flexible management, strong compatibility, and a non-perceived user experience, its limitations are more obvious.

[0184] (2) Reverse proxy SSL solution, which processes SSL / TLS links by deploying a reverse proxy server (such as Nginx, HAProxy, etc.) on the front end. The proxy server performs an SSL handshake with the client and forwards the request to the backend HTTP server. This solution can add SSL encryption support to backend servers that do not have SSL / TLS enabled. It is suitable for scenarios where you do not want to change the existing backend system, and can provide centralized management for multiple backend servers. However, the configuration of the reverse proxy server is complex, especially when a large number of encrypted links need to be processed, there are problems with performance and maintainability. The configuration is even more complex when processing two-way SSL authentication, especially the support for old systems and poor compatibility with national encryption algorithms. The performance overhead is increased, and the proxy server becomes the performance bottleneck of the entire system. It is suitable for scenarios that require unified encryption processing, but its complex maintenance and performance issues, especially in large-scale application scenarios, limit its widespread application.

[0185] (3) Hardware SSL accelerators: The SSL / TLS encryption and decryption process is processed by hardware SSL accelerators. These hardware devices are specially designed to accelerate SSL encryption operations and reduce the computing load on the server side. They can accelerate SSL / TLS encryption operations and significantly improve performance, especially in high concurrency and large data transmission scenarios. This solution can reduce the computing pressure on the server and is suitable for high-performance scenarios that need to process a large number of SSL links. However, it is costly and is usually suitable for large enterprises or scenarios with high security requirements, and is difficult to promote to small and medium-sized enterprises or old systems. It is impossible to flexibly manage domain name resolution, blacklists and whitelists, and routing rules, and is a pure acceleration solution. It requires professional personnel to maintain and operate, and is not suitable for scenarios that require flexible configuration and imperceptible experience. It is suitable for enterprise environments with high performance requirements, but its high cost and maintenance complexity limit its widespread use.

[0186] (4) Software layer SSL tunnel solution, which implements SSL tunnel through software, and all communications are encrypted and decrypted through this tunnel. Common tools include stunnel, etc. This solution is simple to implement, with many open source solutions, and is suitable for small-scale applications. It can provide SSL encryption support for different network protocols (not limited to HTTP). However, it requires additional configuration and maintenance, especially when there are performance bottlenecks in large-scale deployment. The creation and management of tunnels are relatively complex, and the management of SSL certificates requires additional attention. There is limited support for national encryption standards and two-way SSL links, and insufficient flexibility. It is suitable for encryption needs of small and medium-sized application scenarios or special protocols, but it has shortcomings in performance, scalability and maintenance costs, and is difficult to adapt to enterprise-level applications.

[0187] (5) Application layer SSL solution: By implementing SSL / TLS encryption at the application layer, developers can directly call SSL-related APIs (such as SSLContext in Java) in the application to achieve secure communication. This solution is highly flexible, and developers can finely control the logic and details of encryption. In some custom scenarios, specific sensitive data can be encrypted in a targeted manner. However, developers are required to have strong knowledge of SSL encryption, and different applications need to be implemented separately, which is costly. The transformation workload for large-scale applications and legacy systems is very large, and the difficulty of development and maintenance increases. Support for national encryption standards and two-way authentication needs to be re-implemented, which lacks universality. It is suitable for scenarios with custom encryption requirements, but due to the high development and maintenance costs, it is difficult to promote to general Web application systems.

[0188] like Fig. 9 As shown, the embodiment of the present invention also provides a device for establishing a non-perceptual encrypted link, including:

[0189] The first module 801 is used to obtain an encrypted link establishment request;

[0190] The second module 802 is used to determine whether the encryption link establishment requires restarting the server according to the encryption link establishment request;

[0191] The third module 803 is used to perform link establishment processing under the restart service if the establishment of the encrypted link requires restarting the server to obtain an imperceptible encrypted link;

[0192] The fourth module 804 is used to perform link establishment processing under non-restart service if the establishment of the encrypted link does not require restarting the server, so as to obtain an imperceptible encrypted link.

[0193] The contents of the above method embodiments are all applicable to the present device embodiments. The functions specifically implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0194] The preferred embodiments of the present application are described above with reference to the accompanying drawings, but the scope of the rights of the present application is not limited thereto. Any modification, equivalent substitution and improvement made by a person skilled in the art without departing from the scope and essence of the present application should be within the scope of the rights of the present application.< / pid>

Claims

1. A method for establishing an imperceptible encrypted link, characterized in that: The following steps are involved: Get the encryption link establishment request; Determining whether the encrypted link establishment requires restarting the server according to the encrypted link establishment request; If the establishment of an encrypted link requires restarting the server, the link establishment process is performed under the restart service to obtain an unaware encrypted link; If the establishment of the encrypted link does not require restarting the server, the link establishment process is performed under the non-restart service to obtain the imperceptible encrypted link.

2. The method according to claim 1, characterized in that The link establishment process under the restart service is performed to obtain an imperceptible encrypted link, including: Get the target class name; According to the target class name, construct a first class name conversion function; Build enhanced server class functions; Constructing a server secure socket layer conversion class according to the first class name conversion function and the enhanced server class function; According to the server secure socket layer conversion class, construct a server secure socket layer invisible connection class; Creating a keystore and a truststore, the keystore containing a server secure socket layer certificate and the truststore containing a client certificate; According to the server secure socket layer invisible connection class, setting the main startup parameters; Generate a first list file according to the main startup parameter; Build server startup script; The server startup script is executed according to the key store, the trust store and the first manifest file to obtain the imperceptible encrypted link.

3. The method according to claim 2, characterized in that The execution process of the first type name conversion function includes: Get the server startup path; Performing symbol conversion on the server startup path to obtain a server startup class name; If the server startup class name is equal to the target class name, the enhanced server class function is executed.

4. The method according to claim 2, characterized in that: The execution process of the enhanced server class function includes: Create a pool class; Modify the bytecode of the pool class to obtain a first class; Extracting a startup function from the first category; generating secure socket layer connector configuration information; Adding the secure socket layer connector configuration information to the startup function; Perform format code conversion on the first category to obtain a conversion code.

5. The method according to claim 1, characterized in that The performing of the link establishment process under the non-restart service to obtain the imperceptible encrypted link includes: Get the process identifier; Constructing a second class name conversion function according to the process identifier; Construct enhanced application framework class functions; Constructing an invisible connection secure socket layer file conversion class according to the second class name conversion function and the enhanced application framework class function; According to the invisible connection secure socket layer file conversion class, construct a main proxy function; According to the main proxy function, construct a dynamic secure socket layer invisible connection class; According to the dynamic secure socket layer invisible connection class, setting invisible connection parameters; Generate a second manifest file according to the invisible connection parameters; Build invisible connection startup script; According to the second manifest file, the invisible connection startup script is executed to obtain the imperceptible encrypted link.

6. The method according to claim 5, characterized in that The execution process of the main proxy function includes: Get the detection instance; Adding the invisible connection secure socket layer file conversion class to the detection instance; extracting loaded classes from the detection instance; The loaded class is reconverted to obtain a target class.

7. The method according to claim 5, characterized in that The execution process of the invisible connection startup script includes: Get input parameters; Dividing the input parameters to obtain the process identifier and the invisible connection path; According to the process identifier, a virtual machine connection process is performed to obtain a target virtual machine; Performing proxy loading on the target virtual machine according to the invisible connection path; The target virtual machine after the agent is loaded is separated.

8. The method according to claim 1, characterized in that: When the encrypted link establishment requires restarting the server, the method further includes: Get the agent package; Integrate the agent package with the dependency package of the online client product to obtain an integrated package; According to the integration package, the server is restarted so that the online client product loads the encryption certificate and realizes the establishment of an imperceptible encryption link.

9. The method according to claim 1, characterized in that: When the encrypted link is established without restarting the server, the method further includes: Get the process identifier, certification path, and agent package; The agent package is executed according to the process identifier and the certificate path to achieve imperceptible encryption link establishment.

10. A device for establishing an imperceptible encrypted link, characterized in that: include: The first module is used to obtain an encrypted link establishment request; The second module is used to determine whether the encryption link establishment requires restarting the server according to the encryption link establishment request; The third module is used to perform link establishment processing under the restart service if the establishment of the encrypted link requires restarting the server to obtain an imperceptible encrypted link; The fourth module is used to perform link establishment processing under non-restart service if the establishment of the encrypted link does not require restarting the server to obtain the imperceptible encrypted link.

Images