[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

CN117857095A - Non-private key TLS handshake solving method - Google Patents

Non-private key TLS handshake solving method Download PDF

Info

Publication number
CN117857095A
CN117857095A CN202311651911.6A CN202311651911A CN117857095A CN 117857095 A CN117857095 A CN 117857095A CN 202311651911 A CN202311651911 A CN 202311651911A CN 117857095 A CN117857095 A CN 117857095A
Authority
CN
China
Prior art keywords
private key
load balancing
certificate
key
dtcs
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311651911.6A
Other languages
Chinese (zh)
Inventor
任正
梁勇
郭爱杰
邓捷
何姗姗
杨泽润
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tianyi Cloud Technology Co Ltd
Original Assignee
Tianyi Cloud Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tianyi Cloud Technology Co Ltd filed Critical Tianyi Cloud Technology Co Ltd
Priority to CN202311651911.6A priority Critical patent/CN117857095A/en
Publication of CN117857095A publication Critical patent/CN117857095A/en
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083Network architectures or network communication protocols for network security for authentication of entities using passwords
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)

Abstract

The invention relates to the technical field of networks, and particularly discloses a method for solving a TLS handshake of a private key, which comprises the following steps: step S1: loading a certificate and a certificate private key and checking whether the certificate and the certificate private key are matched when load balancing is started; setting a non-private key mode, starting by a TLS protocol without uploading a certificate private key by a user, and not loading the certificate private key during starting, and not verifying whether the certificate is matched with the certificate private key; step S2: in order to make encryption operations asynchronous, it is necessary to modify the load balancing service contents; the method solves the problem that the public key of the user is scattered in the cloud environment to increase the risk of revealing the private key of the certificate, and by adopting the method, the user does not need to upload the private key of the certificate to the cloud environment any more, and only needs to provide encryption service in a place which is trusted by the user and can be accessed by a certain internet; on one hand, the risk of revealing the private key is avoided, and on the other hand, the user is convenient to manage the certificate private key.

Description

Non-private key TLS handshake solving method
Technical Field
The invention relates to the technical field of networks, in particular to a method for solving TLS handshake of a private key.
Background
The Ketless scheme is a solution provided by Cloudflat for solving the problems that the deployment of the certificate private key on various servers is inconvenient to manage, the leakage of the certificate private key is increased, and the like. Increasingly users deploy services on the cloud, while currently the conventional solution is to upload certificate private keys. Once the server is taken over by the hacker, the certificate private key is obtained by the hacker.
The OpenSSL engine mechanism OpenSSL provides a multi-platform compatible access framework for hardware accelerator card manufacturers, so that the drivers of the multi-platform compatible access framework can operate on each platform conveniently. Its function of replacing the default cryptographic algorithm is also often used in various software cryptographic algorithm replacement, encryptor TLS handshake solutions. Early default cryptographic algorithm implementation is gradually abstracted into a scheme, and OpenSSL engine has become a framework between the cross-over interface and the upper layer interface and the bottom layer algorithm, so that the access loss and difficulty of an alternative scheme are reduced.
The OpenSSL Async mode is an asynchronous I/O mode, and is used for abstracting the operation of the hardware accelerator card, which does not occupy the CPU, and a protocol is responsible for calling and waiting for the completion of the operation of the hardware accelerator card. Coroutine in Linux C is mainly implemented using ucontext family functions, openSSL uses Async Job to save various parameters and context variables of coroutine when the function runs
the task is a lower part mechanism of an interrupt processing program implemented by soft interrupt, and in the invention, the interaction with the dtcs server is performed by a processing function registered in the task.
The support of OpenSSL to a hardware acceleration card is mature, and by using an engine mechanism, a user can write a dtcs engine program of the user, so that the idea of offloading private key operation to a remote encryption server (configuring a private key) is realized. With its Async mode we can write asynchronous programs to avoid network latency in an internet environment that can make a single TLS handshake too long.
dtcs (distributed crypto service): the distributed encryption service is actually a set of components including dtcs engine and dtcs server.
dtcs engine: the distributed encryption service engine realized based on the OpenSSL engine mechanism is realized by unloading a default cryptographic algorithm to the dtcs engine, and the dtcs engine does not calculate the data and sends the data to the dtcs server.
dtcs server: the distributed encryption server side performs asymmetric private key encryption operation on the data after receiving the request;
RSA: here, the key negotiation algorithm is mainly referred to as rsa, which can enable two communication parties to negotiate a premaster key together through a public key encryption algorithm and a private key decryption algorithm, so as to calculate a session key (and a symmetric encryption key).
the tasklet mechanism: a soft interrupt mechanism is triggered by a dtcs engine, so that the dtcs engine can return a result immediately to avoid load balancing service blocking. We put the work of initiating requests to the dtcs server service, transmitting data, getting responses, informing the load balancing service in the tasklet handler.
TLS is an encryption protocol that provides end-to-end security for data sent between applications over the Internet.
TLS handshake is a process that uses asymmetric encryption techniques to ensure a connection with a server.
In order to solve the problems that the deployment of the certificate private key on various servers is inconvenient to manage, the leakage of the certificate private key is increased and the like, the invention provides a general method for carrying out TLS handshake on a non-private key.
Disclosure of Invention
The invention aims to provide a method for solving the problem that a certificate private key is inconvenient to manage when deployed on various servers, and leakage of the certificate private key is increased.
In order to achieve the above purpose, the present invention provides the following technical solutions: a method for a private key less TLS handshake resolution, the method comprising the steps of:
step S1: loading a certificate and a certificate private key and checking whether the certificate and the certificate private key are matched when the load balancing service is started; setting a non-private key mode, starting by a TLS protocol without uploading a certificate private key by a user, and not loading the certificate private key during starting, and not verifying whether the certificate is matched with the certificate private key;
step S2: asynchronous encryption operation, and modifying the load balancing service to support an OpenSSL Async mode;
step S3: writing a dtcs engine, deploying the dtcs engine in an environment where a load balancing service is located, registering a tasklet processing function, and initiating a private key encryption request to a dtcs server when the tasklet processing function is triggered;
step S4: writing a dtcs server, deploying the dtcs server in a trusted environment by a user, and interacting with the dtcs server through the Internet by the dtcs engine;
step S5: the method comprises the steps that a client performs TLS handshake with a load balancing service, and the load balancing service calls a method provided by OpenSSL to perform TLS handshake with the client; the method finally calls rsa private key decryption algorithm realized by dtcs engine to replace a default rsa private key decryption algorithm;
step S6: the rsa private key decryption algorithm realized by the dtcs engine triggers the task processing function registered in the step three and initiates a request to the dtcs server; the rsa private key decryption algorithm realized by the dtcs engine is returned immediately;
step S7: based on the load balancing service supporting the OpenSSL Async mode, the step S5 and the step S6 are carried out in an ASYNC_JOB cooperative process, and after the cooperative process is obtained and returned, the context switching is executed to pause the current task;
step S8: the method provided by OpenSSL returns an ERROR status code SSL_ERROR_WANT_ASYNC of load balancing service, which indicates that the current mode is Async mode, and the load balancing service proceeds with the following steps;
step S9: the load balancing service acquires the ERROR status code SSL_ERROR_WANT_ASYNC and registers a file descriptor associated with the TLS connection;
step S10: the load balancing service monitors the event arrival on the file descriptor through epoll,
step S11: step S6, after receiving the request of the tasklet processing function, the dtcs server searches the corresponding certificate private key, carries out RSA private key decryption operation on the data, and returns an operation result;
step S12: after the response is obtained, the tasklet processing function writes the result into the shared memory, and the notification of the processing completion is transmitted to the load balancing service from the dtcs engine through the file descriptor;
step S13: the load balancing service monitors that the file descriptor state is changed, and the method provided by OpenSSL is called again, so that the ASYNC_JOB dormant in the step S5 runs again, and data are read and processed from the shared memory.
As a preferred embodiment of the present invention, the step S1 of initiating the TLS protocol without uploading the private key of the certificate by the user is as follows:
step S1.1: the client sends ClientHello to the load balancing server, and the client initiates a connection request and sends an algorithm list supported by the connection request and a client random number to the load balancing service;
step S1.2: the load balancing service returns ServerHello, and the load balancing service sends a selected encryption algorithm and the random number of the server to the client;
step S1.3: the load balancing service returns a Certificate, wherein the Certificate is contained in the Certificate;
step S1.4: the load balancing service returns to ServerHelloDone, and the task of the load balancing service is ended at the stage;
step S1.5: the client sends ClientKeyexchange;
step S1.6: the client sends ChangeCipherSpec;
step S1.7: the client sends Finished and checks the whole connection process;
step S1.8: the load balancing service sends changeciphererspec; the load balancing service informs the client of the encrypted message sent by the negotiated symmetric encryption key;
step S1.9: and the load balancing service sends Finished and verifies the whole connection process.
As a preferred embodiment of the present invention, the certificate in step S1.3 includes a public key of the certificate.
As a preferred embodiment of the present invention, detecting whether a user configures a private key in a load balancing service, if so, TLS handshake follows a conventional procedure; if the user does not configure the private key and configures the address of the dtcs server, entering a non-private key mode.
As a preferred embodiment of the present invention, the load balancing service does not store the certificate private key in any form in the environment in which it is located.
As a preferred embodiment of the present invention, the tasklet processing function sends the offload mode, which is here the secure mode, key negotiation algorithm, key type and encrypted data to the dtcs server.
As a preferred embodiment of the present invention, the step S1.5 comprises the following steps that the client generates a premaster secret key through a random number generator, then uses a load balancing certificate public key to carry out public key encryption on the premaster secret key, and sends the encrypted information to a load balancing service; the client calculates a master key according to the client random number, the server random number and the premaster key, and further calculates a symmetric encryption key; after receiving the ClientKeyexchange, the load balancing service triggers a tasklet processing function, sends an unloading mode, a key negotiation algorithm, a key type and encrypted data to a dtcs server, obtains the data, decrypts the encrypted data by using a certificate private key to obtain a premaster key, calculates a master key according to a client random number, a server random number and the premaster key, further calculates a symmetric encryption key, and returns the symmetric encryption key to the tasklet processing function.
As a preferred embodiment of the present invention, the client in step S1.6 notifies the load balancing service that the message is thereafter sent encrypted with the negotiated symmetric encryption key.
As a preferred embodiment of the present invention, after the load balancing service receives the ClientKeyExchange, triggering the tasklet processing function, and sending the offload mode, the key negotiation algorithm, the key type and the encrypted data to the dtcs server service; after the dtcs server receives the data, if the uninstall mode is the safe mode, the premaster secret key is calculated according to the secret key negotiation algorithm and the secret key type.
As a preferred embodiment of the present invention, the tasklet processing function sends data to the dtcs server through the TLS protocol, and in order to avoid loop calls, the tasklet processing function needs to determine the private key type, and selects an algorithm suite different from the algorithm suite negotiated in step S1.2 to establish a TLS connection with the dtcs server.
Compared with the prior art, the invention has the beneficial effects that:
the method solves the problem that the risk of revealing the private key of the certificate is increased due to the dispersion of the private key of the user in the cloud environment, and by adopting the method, the user does not need to upload the private key of the certificate to the cloud environment any more, and only needs to provide encryption service in a place which is trusted by the user and can be accessed by a certain internet. On one hand, the risk of revealing the private key is avoided, and on the other hand, the user is convenient to manage the certificate private key.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following description will briefly introduce the drawings that are needed in the embodiments or the description of the prior art, and it is obvious that the drawings in the following description are only some embodiments of the present invention.
FIG. 1 is a flow chart of the method of the present invention;
FIG. 2 is a schematic diagram of components involved in the method of the present invention;
fig. 3 is a schematic flow chart of step S5-step 11 according to the present invention.
Detailed Description
In order to make the technical problems, technical schemes and beneficial effects to be solved more clear, the invention is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.
Referring to fig. 1-3, the technical scheme of the present invention is described in detail for achieving the above purpose.
The invention provides a method for solving TLS handshake of a private key, which comprises the following steps:
step S1: loading a certificate and a certificate private key and checking whether the certificate and the certificate private key are matched when the load balancing service is started; setting a non-private key mode, starting by a TLS protocol without uploading a certificate private key by a user, and not loading the certificate private key during starting, and not verifying whether the certificate is matched with the certificate private key;
step S2: asynchronous encryption operation, and modifying the load balancing service to support an OpenSSL Async mode;
step S3: writing a dtcs engine, deploying the dtcs engine in an environment where a load balancing service is located, registering a tasklet processing function, and initiating a private key encryption request to a dtcs server when the tasklet processing function is triggered;
step S4: writing a dtcs server, deploying the dtcs server in a trusted environment by a user, and interacting with the dtcs server through the Internet by the dtcs engine;
step S5: the method comprises the steps that a client performs TLS handshake with load balancing, and the load balancing calls a method provided by OpenSSL to perform TLS handshake with the client; the method finally calls rsa private key decryption algorithm realized by dtcs engine to replace a default rsa private key decryption algorithm;
step S6: the rsa private key decryption algorithm realized by the dtcs engine triggers the task processing function registered in the step three and initiates a request to the dtcs server; the rsa private key decryption algorithm realized by the dtcs engine is returned immediately;
step S7: because the load balancing is changed in the step S2, an OpenSSL Async mode is supported, the step S5 and the step S6 are carried out in an ASYNC_JOB cooperative process, and after the cooperative process is obtained and returned, the context switching is executed, and the current task is suspended;
step S8: since the current task is suspended, the method provided by OpenSSL will return to the load balancing ERROR status code ssl_error_WANT_ASYNC, indicating that the current ASYNC mode is present, and load balancing should proceed with the following steps;
step S9: the load balancing service acquires the ERROR status code SSL_ERROR_WANT_ASYNC and registers a file descriptor associated with the TLS connection;
step S10: the load balancing service monitors the event arrival on the file descriptor through epoll,
step S11: step S6, after receiving the request of the tasklet processing function, the dtcs server searches the corresponding certificate private key, carries out RSA private key decryption operation on the data, and returns an operation result;
step S12: after the response is obtained, the tasklet processing function writes the result into the shared memory, and the notification of the processing completion is transmitted to the load balancing service from the dtcs engine through the file descriptor;
step S13: the load balancing service monitors that the file descriptor state is changed, and the method provided by OpenSSL is called again, so that the ASYNC_JOB dormant in the step S5 runs again, and data are read and processed from the shared memory.
Further, in the step S1, the TLS protocol starting step without uploading the certificate private key by the user is as follows:
step S1.1: the client sends ClientHello to the load balancing server, and the client initiates a connection request and sends an algorithm list supported by the connection request and a client random number to load balancing;
step S1.2: the load balancing returns ServerHello, and the load balancing sends a selected encryption algorithm and the server random number to the client;
step S1.3: the load balancing returns a Certificate, wherein the Certificate is contained in the Certificate;
step S1.4: the load balancing returns to ServerHelloDone, and the task at the stage of load balancing is ended;
step S1.5: the client sends ClientKeyexchange;
step S1.6: the client sends ChangeCipherSpec;
step S1.7: the client sends Finished and checks the whole connection process;
step S1.8: load balancing sending ChangeCipherSpec; the load balancing informs the client of the encrypted sending of the message by using the negotiated symmetric encryption key;
step S1.9: and carrying out load balancing to send Finished, and checking the whole connection process.
Further, the certificate in step S1.3 includes a public key of the certificate.
Further, detecting whether a user configures a private key or not in the load balancing service, and if so, performing TLS handshake according to the traditional flow; if the user does not configure the private key and configures the address of the dtcs server, entering a non-private key mode.
Further, the load balancing service does not store the certificate private key in any form in the environment in which it resides.
Further, the tasklet processing function sends the offload mode, here the secure mode, key agreement algorithm, key type and encrypted data to the dtcs server.
Further, the step S1.5 comprises the following steps that the client generates a premaster secret key through a random number generator, public key encryption is carried out on the premaster secret key by using a load balancing certificate public key, and encrypted information is sent to load balancing; the client calculates a master key according to the client random number, the server random number and the premaster key, and further calculates a symmetric encryption key; after the load balance receives the ClientKeyexchange, triggering a tasklet processing function, sending an unloading mode, a key negotiation algorithm, a key type and encrypted data to a dtcs server, obtaining the data by the dtcs server, decrypting the encrypted data by using a certificate private key to obtain a premaster key, then calculating a master key according to a client random number, a server random number and the premaster key, further calculating a symmetric encryption key, and returning the symmetric encryption key to the tasklet processing function.
Further, in step S1.6, the client notifies the message after load balancing to be sent by encrypting with the negotiated symmetric encryption key.
Further, after the load balancing receives the ClientKeyexchange, triggering a tasklet processing function, and sending an unloading mode, a key negotiation algorithm, a key type and encrypted data to a dtcs server; after the dtcs server receives the data, if the uninstall mode is the safe mode, the premaster secret key is calculated according to the secret key negotiation algorithm and the secret key type.
Further, the tasklet processing function sends data to the dtcs server through the TLS protocol, and in order to avoid loop call, the tasklet processing function needs to determine the type of the private key, selects an algorithm suite different from the algorithm suite negotiated in step S1.2, and establishes TLS connection with the dtcs server.
The embodiments are described below with reference to the drawings.
Step S1: the load balancing starts up with loading the certificate and the certificate private key and checking if they match. The non-private key mode is added, a certificate private key is not loaded during starting, and whether the certificate is matched with the certificate private key is not verified;
step S2: asynchronous encryption operation, and modifying the load balancing service to support an OpenSSL Async mode;
step S3: as shown in the dtcs engine component in fig. 2, the dtcs engine needs to be written and deployed in the environment where the load balancing service is located. The dtcs engine registers a tasklet processing function. Initiating a private key encryption request to the dtcs server when the tasklet processing function is triggered (triggered in the TLS handshake process);
step S4: as shown in the dtcs server component in fig. 2, writing a dtcs server, and deploying the dtcs server in a trusted environment by a user, wherein the dtcs engine interacts with the dtcs server through the internet;
step S5: as shown in the non-private key TLS handshake protocol in fig. 1, the client performs TLS handshake with load balancing, and the load balancing calls the method provided by OpenSSL to perform TLS handshake with the client; the method finally calls a rsa private key decryption algorithm implemented by the dtcs engine to replace a default rsa private key decryption algorithm (see the 5.3 process in fig. 3);
step S6: the rsa private key decryption algorithm realized by the dtcs engine triggers the task processing function registered in the step three and initiates a request to the dtcs server; whereas the rsa private key decryption algorithm implemented by dtcs engine will be returned immediately (see procedure 5.5 in fig. 3);
step S7: because load balancing is changed in the second step and supports the OpenSSL Async mode, the fifth step and the sixth step are actually performed in an async_job, and after the JOB acquisition returns, context switching is performed to suspend the current task (see the 5.6 process in fig. 3);
step S8: since the current task is suspended, the method provided by OpenSSL will return to the load balancing ERROR status code ssl_error_WANT_ASYNC, indicating that the current ASYNC mode is present, and load balancing should proceed with the following steps;
step S9: the load balancing service obtains the ERROR status code ssl_error_WANT_ASYNC and registers a file descriptor associated with the TLS connection (see procedures 5.5 and 6 in fig. 3);
step S10: the load balancing service monitors the event arrival on the file descriptor through epoll (see procedure 7 in fig. 3).
Step S11: step six, after receiving the request of the tasklet processing function, the dtcs server searches the corresponding certificate private key, carries out RSA private key decryption operation on the data, and returns the operation result (see the 9 th process in FIG. 3);
step S12: after the response is obtained, the tasklet processing function writes the result into the shared memory, and the notification of the completion of the processing is transferred from the dtcs engine to the load balancing service through the file descriptor (see the 10 th process in fig. 3);
step S13: the load balancing service monitors that the file descriptor status is changed, and invokes the OpenSSL provided method again, so that async_job in step five is run again, and the data is read and processed from the shared memory (see the 11 th process in fig. 3).
The processor takes out instructions from the memory one by one, analyzes the instructions, then completes corresponding operation according to the instruction requirement, generates a series of control commands, enables all parts of the computer to automatically, continuously and cooperatively act to form an organic whole, realizes the input of programs, the input of data, the operation and the output of results, and the arithmetic operation or the logic operation generated in the process is completed by the arithmetic unit; the Memory comprises a Read-Only Memory (ROM) for storing a computer program, and a protection device is arranged outside the Memory.
For example, a computer program may be split into one or more modules, one or more modules stored in memory and executed by a processor to perform the present invention. One or more of the modules may be a series of computer program instruction segments capable of performing specific functions for describing the execution of the computer program in the terminal device.
It will be appreciated by those skilled in the art that the foregoing description of the service device is merely an example and is not meant to be limiting, and may include more or fewer components than the foregoing description, or may combine certain components, or different components, such as may include input-output devices, network access devices, buses, etc.
The processor may be a central processing unit (Central Processing Unit, CPU), other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. The general purpose processor may be a microprocessor or the processor may be any conventional processor or the like, which is the control center of the terminal device described above, and which connects the various parts of the entire user terminal using various interfaces and lines.
The memory may be used for storing computer programs and/or modules, and the processor may implement various functions of the terminal device by running or executing the computer programs and/or modules stored in the memory and invoking data stored in the memory. The memory may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function (such as an information acquisition template display function, a product information release function, etc.), and the like; the storage data area may store data created according to the use of the berth status display system (e.g., product information acquisition templates corresponding to different product types, product information required to be released by different product providers, etc.), and so on. In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as a hard disk, memory, plug-in hard disk, smart Media Card (SMC), secure Digital (SD) Card, flash Card (Flash Card), at least one disk storage device, flash memory device, or other volatile solid-state storage device.
The modules/units integrated in the terminal device may be stored in a computer readable storage medium if implemented in the form of software functional units and sold or used as separate products. Based on this understanding, the present invention may implement all or part of the modules/units in the system of the above-described embodiments, or may be implemented by instructing the relevant hardware by a computer program, which may be stored in a computer-readable storage medium, and which, when executed by a processor, may implement the functions of the respective system embodiments described above. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, executable files or in some intermediate form, etc. The computer readable medium may include: any entity or device capable of carrying computer program code, a recording medium, a U disk, a removable hard disk, a magnetic disk, an optical disk, a computer Memory, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), an electrical carrier signal, a telecommunications signal, a software distribution medium, and so forth.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The foregoing description of the preferred embodiments of the present invention is not intended to limit the invention thereto. Any modifications, equivalent substitutions, improvements, etc. within the principles and practice of the present invention are intended to be included within the scope of the present invention.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The foregoing description is only of the preferred embodiments of the present invention, and is not intended to limit the scope of the invention, but rather is intended to cover any equivalents of the structures or equivalent processes disclosed herein or in the alternative, which may be employed directly or indirectly in other related arts.

Claims (10)

1. A method for solving a private key-less TLS handshake, comprising the steps of:
step S1: loading a certificate and a certificate private key and checking whether the certificate and the certificate private key are matched when the load balancing service is started; setting a non-private key mode, starting by a TLS protocol without uploading a certificate private key by a user, and not loading the certificate private key during starting, and not verifying whether the certificate is matched with the certificate private key;
step S2: asynchronous encryption operation, and modifying the load balancing service to support an OpenSSL Async mode;
step S3: writing a dtcs engine, deploying the dtcs engine in an environment where a load balancing service is located, registering a tasklet processing function, and initiating a private key encryption request to a dtcs server when the tasklet processing function is triggered;
step S4: writing a dtcs server, deploying the dtcs server in a trusted environment by a user, and interacting with the dtcs server through the Internet by the dtcs engine;
step S5: the method comprises the steps that a client performs TLS handshake with a load balancing service, and the load balancing service calls a method provided by OpenSSL to perform TLS handshake with the client; the method finally calls rsa private key decryption algorithm realized by dtcs engine to replace a default rsa private key decryption algorithm;
step S6: the rsa private key decryption algorithm realized by the dtcs engine triggers the task processing function registered in the step three and initiates a request to the dtcs server; the rsa private key decryption algorithm realized by the dtcs engine is returned immediately;
step S7: based on the load balancing service supporting the OpenSSL Async mode, the step S5 and the step S6 are carried out in an ASYNC_JOB cooperative process, and after the cooperative process is obtained and returned, the context switching is executed to pause the current task;
step S8: the method provided by OpenSSL returns an ERROR status code SSL_ERROR_WANT_ASYNC of load balancing service, which indicates that the current mode is Async mode, and the load balancing service proceeds with the following steps;
step S9: the load balancing service acquires the ERROR status code SSL_ERROR_WANT_ASYNC and registers a file descriptor associated with the TLS connection;
step S10: the load balancing service monitors the event arrival on the file descriptor through epoll,
step S11: step S6, after receiving the request of the tasklet processing function, the dtcs server searches the corresponding certificate private key, carries out RSA private key decryption operation on the data, and returns an operation result;
step S12: after the response is obtained, the tasklet processing function writes the result into the shared memory, and the notification of the processing completion is transmitted to the load balancing service from the dtcs engine through the file descriptor;
step S13: the load balancing service monitors that the file descriptor state is changed, and the method provided by OpenSSL is called again, so that the ASYNC_JOB dormant in the step S5 runs again, and data are read and processed from the shared memory.
2. The method for solving the TLS handshake of claim 1, wherein the step S1 of initiating the TLS protocol without uploading the private key of the certificate by the user comprises the steps of:
step S1.1: the client sends ClientHello to the load balancing server, and the client initiates a connection request and sends an algorithm list supported by the connection request and a client random number to the load balancing service;
step S1.2: the load balancing service returns ServerHello, and the load balancing service sends a selected encryption algorithm and the random number of the server to the client;
step S1.3: the load balancing service returns a Certificate, wherein the Certificate is contained in the Certificate;
step S1.4: the load balancing service returns to ServerHelloDone, and the task of the load balancing service is ended at the stage;
step S1.5: the client sends ClientKeyexchange;
step S1.6: the client sends ChangeCipherSpec;
step S1.7: the client sends Finished and checks the whole connection process;
step S1.8: the load balancing service sends changeciphererspec; the load balancing service informs the client of the encrypted message sent by the negotiated symmetric encryption key;
step S1.9: and the load balancing service sends Finished and verifies the whole connection process.
3. A method of solving a private key TLS handshake according to claim 2, wherein said certificate in step S1.3 comprises a public key of the certificate.
4. A solution to TLS handshake with no private key according to claim 3, wherein the load balancing service detects whether the user configures the private key, and if so, the TLS handshake follows a conventional procedure; if the user does not configure the private key and configures the address of the dtcs server, entering a non-private key mode.
5. A private key less TLS handshake solution according to claim 4, wherein the load balancing service does not save the certificate private key in any form in the environment in which it is located.
6. A method of resolving a private key TLS handshake according to claim 5, wherein the tasklet handling function sends an offload mode, here a secure mode, key agreement algorithm, key type and encrypted data to the dtcs server.
7. The method for solving the TLS handshake of the private key according to claim 6, wherein the step S1.5 comprises the steps of generating a premaster secret by the client through the random number generator, public key encrypting the premaster secret using the public key of the load balancing certificate, and transmitting the encrypted information to the load balancing service; the client calculates a master key according to the client random number, the server random number and the premaster key, and further calculates a symmetric encryption key; after receiving the ClientKeyexchange, the load balancing service triggers a tasklet processing function, sends an unloading mode, a key negotiation algorithm, a key type and encrypted data to a dtcs server, obtains the data, decrypts the encrypted data by using a certificate private key to obtain a premaster key, calculates a master key according to a client random number, a server random number and the premaster key, further calculates a symmetric encryption key, and returns the symmetric encryption key to the tasklet processing function.
8. A method of solving a private key TLS handshake according to claim 7, wherein said client in step S1.6 notifies the load balancing service that the message thereafter is sent encrypted with the negotiated symmetric encryption key.
9. The method for solving the non-private key TLS handshake according to claim 8, wherein after the load balancing service receives the ClientKeyExchange, triggering a tasklet processing function to send an offload mode, a key negotiation algorithm, a key type and encrypted data to the dtcs server; after the dtcs server receives the data, if the uninstall mode is the safe mode, the premaster secret key is calculated according to the secret key negotiation algorithm and the secret key type.
10. The method according to claim 9, wherein the tasklet processing function sends data to the dtcs server via TLS protocol, and the tasklet processing function needs to determine the type of private key in order to avoid round robin call, and selects a different algorithm set from the one negotiated in step S1.2 to establish TLS connection with the dtcs server.
CN202311651911.6A 2023-12-05 2023-12-05 Non-private key TLS handshake solving method Pending CN117857095A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311651911.6A CN117857095A (en) 2023-12-05 2023-12-05 Non-private key TLS handshake solving method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311651911.6A CN117857095A (en) 2023-12-05 2023-12-05 Non-private key TLS handshake solving method

Publications (1)

Publication Number Publication Date
CN117857095A true CN117857095A (en) 2024-04-09

Family

ID=90538990

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311651911.6A Pending CN117857095A (en) 2023-12-05 2023-12-05 Non-private key TLS handshake solving method

Country Status (1)

Country Link
CN (1) CN117857095A (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0902067D0 (en) * 2008-02-15 2009-03-25 Connotech Experts Conseils Inc Method of bootstrapping an authenticated data session configuration
CN106341417A (en) * 2016-09-30 2017-01-18 贵州白山云科技有限公司 Content delivery network-based HTTPS acceleration method and system
CN109842664A (en) * 2017-11-29 2019-06-04 苏宁云商集团股份有限公司 A kind of CDN of the safety without private key of High Availabitity supports the system and method for HTTPS
CN114124582A (en) * 2022-01-27 2022-03-01 江苏千米网络科技股份有限公司 Method for carrying out SSL/TLS protocol communication by using key-free certificate

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0902067D0 (en) * 2008-02-15 2009-03-25 Connotech Experts Conseils Inc Method of bootstrapping an authenticated data session configuration
CN106341417A (en) * 2016-09-30 2017-01-18 贵州白山云科技有限公司 Content delivery network-based HTTPS acceleration method and system
CN109842664A (en) * 2017-11-29 2019-06-04 苏宁云商集团股份有限公司 A kind of CDN of the safety without private key of High Availabitity supports the system and method for HTTPS
CN114124582A (en) * 2022-01-27 2022-03-01 江苏千米网络科技股份有限公司 Method for carrying out SSL/TLS protocol communication by using key-free certificate

Similar Documents

Publication Publication Date Title
AU2018328182B2 (en) Securing a data connection for communicating between two end-points
EP2992658B1 (en) Secured access to resources using a proxy
AU2019332913B2 (en) Accessing resources in a remote access or cloud-based network environment
EP2761426B1 (en) Implementation of secure communications in a support system
US9385918B2 (en) System and method for secure provisioning of virtualized images in a network environment
US11711214B2 (en) Enhanced token transfer
US11165888B1 (en) Image acquisition device virtualization for remote computing
CN111970240B (en) Cluster receiving and managing method and device and electronic equipment
US11917064B2 (en) Token transformation filter for the service mesh
WO2022026316A1 (en) Secure token transfer between untrusted entities
US11722461B2 (en) Connecting client devices to anonymous sessions via helpers
CA3166710A1 (en) Optically scannable representation of a hardware secured artifact
CN117857095A (en) Non-private key TLS handshake solving method
KR20080045195A (en) Providing consistent application aware firewall traversal
US10831896B2 (en) Running local virtual disks containing applications with limited licenses

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination