WO2017045552A1

WO2017045552A1 - Method and device for loading digital certificate in ssl or tls communication

Info

Publication number: WO2017045552A1
Application number: PCT/CN2016/098186
Authority: WO
Inventors: 齐铁鹏; 杨洋; 刘立朋; 李振宇; 蒋锷; 周辉
Original assignee: 阿里巴巴集团控股有限公司
Priority date: 2015-09-15
Filing date: 2016-09-06
Publication date: 2017-03-23
Also published as: CN106533689B; CN106533689A

Abstract

Provided are a method and device for loading a digital certificate in SSL or TLS communication. The method comprises: receiving a handshake request message sent by a client based on a secure sockets layer (SSL) or transport layer security (TLS); according to the handshake request message, verifying a key exchange mode and a first signature mode supported by the client; judging whether the key exchange mode and the first signature mode match a currently loaded digital certificate; if not, loading another digital certificate matching the key exchange mode and the first signature mode; and according to the key exchange mode and the first signature mode successfully matching the digital certificate, returning a handshake response message to the client.The embodiments of the present application achieve dynamic loading of a suitable digital certificate in a handshake negotiation process, thereby ensuring successful completion of SSL/TLS handshake negotiation.

Description

Method and device for loading digital certificate in SSL or TLS communication

The present application claims priority to Chinese Patent Application No. 201510587689.7, entitled "A Method and Apparatus for Loading Digital Certificates in SSL or TLS Communication", filed on September 15, 2015, the entire contents of which are incorporated by reference. In this application.

Technical field

The present application relates to the technical field of communication, and in particular to a method for loading a digital certificate in SSL or TLS communication and an apparatus for loading a digital certificate in SSL or TLS communication.

Background technique

Emerging applications such as e-commerce and online banking have greatly facilitated people's daily life and are favored by people. Since these applications require online transactions on the network, they place higher demands on the security of network communications. Therefore, HTTPS (Hyper Text Transfer Protocol over Secure Socket Layer) has been used by more and more websites.

HTTPS is a HTTP (Hypertext Transfer Protocol) channel for security purposes. That is, HTTP is added to SSL (Secure Sockets Layer) or its subsequent version TLS (Transport Layer Security). SSL/TLS utilizes data encryption, authentication, and message integrity verification mechanisms to provide security for the transmission of data over the network.

The cryptographic algorithms applied by SSL/TLS, such as the hash algorithm of the digest, the signature algorithm of the certificate, and the encryption algorithm of the data, are also constantly updated, and various clients (including various versions of the browser, various types) Encryption methods that can be supported by applications, etc. are also uneven.

In a highly visited website such as an e-commerce platform, there are often various versions of client access.

Currently, for servers that support SSL/TLS, the digital certificate is basically loaded at startup. Only one digital certificate can be used for the specified domain name. Once the digital certificate is loaded, the digest algorithm and signature algorithm specified in the certificate can only be used for SSL/TLS handshake. Negotiation.

If some older versions of the client cannot support the newer algorithms in the certificate, the negotiation fails, resulting in the client not being able to access the website via HTTPS, and the website compatibility is poor, resulting in low communication security.

Summary of the invention

In view of the above problems, embodiments of the present application have been made in order to provide an overcoming of the above problems or at least partially A method for loading a digital certificate in SSL or TLS communication and a corresponding device for loading a digital certificate in SSL or TLS communication, which solve the above problems.

In order to solve the above problem, the embodiment of the present application discloses a method for loading a digital certificate in SSL or TLS communication, including:

Receiving a handshake request message sent by the client based on the Secure Sockets Layer protocol SSL or the Transport Layer Security Protocol TLS;

And verifying, according to the handshake request message, a key exchange manner supported by the client and a first signature manner;

Determining whether the key exchange mode and the first signature mode match the currently loaded digital certificate; if not, loading other digital certificates that match the key exchange mode and the first signature mode;

And returning a handshake response message to the client according to the key exchange manner that matches the success of the digital certificate and the first signature manner.

Optionally, the step of verifying the key exchange mode and the first signature mode supported by the client according to the handshake request message includes:

Finding a cipher suite from the handshake request message;

Identifying a key exchange mode and a first signature mode supported by the client from the cipher suite;

Optionally, the step of verifying the key exchange mode and the first signature mode supported by the client according to the handshake request message further includes:

Finding an extension header of the transport layer security protocol TLS from the handshake request;

A first signature mode supported by the client is identified from the extension header.

Optionally, the first signature mode that is verified is the first signature mode with the highest encryption strength of the client.

Optionally, the digital certificate is divided into groups according to the type of the public key, and one of the digital certificates is loaded in each group, and the currently loaded digital certificate is the highest-encrypted digital certificate in the group.

Optionally, the step of determining whether the key exchange mode and the signature mode match the currently loaded digital certificate comprises:

Finding a public key that matches the key exchange method;

Identifying a second signature manner of the digital certificate currently loaded in the packet to which the public key belongs;

Determining whether the first signature mode matches the second signature mode;

If yes, determining that the key exchange mode and the signature manner match the currently loaded digital certificate;

If not, it is determined that the key exchange mode and the signature mode do not match the currently loaded digital certificate.

Optionally, loading the other digital certificate that matches the key exchange manner and the first signature manner The steps include:

Identifying a third signature manner of other digital certificates in the group to which the public key belongs;

Determining whether the third signature mode matches the first signature mode;

If yes, the digital certificate to which the third signature mode belongs is loaded to replace the digital certificate currently loaded in the packet to which the public key belongs.

The embodiment of the present application further discloses an apparatus for loading a digital certificate in SSL or TLS communication, including:

a handshake request message receiving module, configured to receive a handshake request message sent by the client based on a Secure Sockets Layer protocol SSL or a Transport Layer Security Protocol TLS;

a client information verification module, configured to verify, according to the handshake request message, a key exchange manner supported by the client and a first signature manner;

a digital certificate matching module, configured to determine whether the key exchange mode and the first signature mode match the currently loaded digital certificate; if not, the digital certificate loading module is invoked;

a digital certificate loading module, loading other digital certificates matching the key exchange manner and the first signature manner;

The handshake response message returning module is configured to return a handshake response message to the client according to the key exchange manner that matches the success of the digital certificate and the first signature manner.

Optionally, the client information verification module includes:

a cipher suite lookup submodule for finding a cipher suite from the handshake request message;

a cipher suite identification submodule, configured to identify a key exchange mode and a first signature mode supported by the client from the cipher suite;

Optionally, the client information verification module further includes:

An extension header search submodule, configured to search for an extension header of a transport layer security protocol TLS from the handshake request;

The extended header identification submodule is configured to identify, from the extended header, a first signature manner supported by the client.

Optionally, the digital certificate matching module includes:

a public key lookup submodule, configured to find a public key that matches the key exchange manner;

a current signature mode identification submodule, configured to identify a digital certificate currently loaded in a packet to which the public key belongs Second signature method;

a first signature matching submodule, configured to determine whether the first signature mode matches the second signature mode; if yes, the first determining submodule is invoked, and if not, the second determining submodule is invoked;

a first determining submodule, configured to determine that the key exchange mode and the signature manner match the currently loaded digital certificate;

The second determining submodule is configured to determine that the key exchange mode and the signature manner do not match the currently loaded digital certificate.

Optionally, the digital certificate loading module includes:

a further signature mode identifying submodule, configured to identify a third signature mode of other digital certificates in the group to which the public key belongs;

a second signature matching sub-module, configured to determine whether the third signature mode matches the first signature mode; if yes, calling a digital certificate replacement sub-module;

And a digital certificate replacement submodule, configured to load the digital certificate to which the third signature mode belongs, to replace the digital certificate currently loaded in the packet to which the public key belongs.

Embodiments of the present application include the following advantages:

In the embodiment of the present application, the digital certificate is matched with the key exchange mode supported by the client and the first signature mode, so that the appropriate digital certificate is dynamically loaded during the handshake negotiation process to ensure successful completion of the SSL/TLS handshake negotiation. The poor compatibility of the website ensures that the client accesses the website through a secure protocol such as HTTPS, which improves the security of the communication.

The embodiment of the present application can configure multiple different types of digital certificates for the same domain name, which improves the dynamic loading efficiency of the digital certificate.

DRAWINGS

1 is a flow chart showing the steps of an embodiment of a method for loading a digital certificate in SSL/TLS communication according to the present application;

2 is a network model architecture diagram of an embodiment of the present application;

FIG. 3 is a signaling diagram of an SSL handshake according to an embodiment of the present application; FIG.

4 is a structural block diagram of an embodiment of an apparatus for loading a digital certificate in SSL/TLS communication according to the present application.

detailed description

The above described objects, features and advantages of the present application will become more apparent and understood.

SSL/TLS is a secure network transmission protocol, mainly to protect confidential information transmitted over the Internet. The protocol includes two processes: a handshake phase and a data transmission phase.

In the data transmission phase, the transmitted data is separately encrypted and decrypted using the negotiated symmetric key, and the digest key is digested to ensure the privacy and integrity of the data.

The main purpose of the handshake phase is to confirm the true validity of the identity of the other party and to generate the key required for the data transmission phase.

The SSL handshake process is as follows:

a client client sends a Client hello message. The message mainly includes the SSL version number, random number, callback ID, cipher suite, and compression method.

Among them, the cipher suite indicates the list of algorithms that the client can support, including the key exchange method, the signature method, and the encryption method.

b. The server returns a hello message to the client, including the SSL version number, the key exchange mode supported by the server and the client, the signature mode, and the encryption method, and the random number used to generate the secret key.

Here, the server needs to match the cipher suite in the client hello through the pre-loaded digital certificate and signature method. Only when the match is successful, the server hello message is returned, and the cipher algorithm used by both parties is identified in Client_hello.

c. The server sends the specified certificate (certificate chain) to the client for authentication.

d. After successfully verifying the server certificate, the client sends a client key exchange message to the server, which is used to encrypt the pre-master key through the server's public key and then send it to the server.

e. The two parties generate a master key for the transmission phase according to the pre-master key and the random number, thereby completing the SSL handshake negotiation process.

In step e, when the client verifies the server certificate, the client verifies the digital signature in the certificate according to the signature method in the certificate and the hash digest algorithm used by the signature. If the client does not support the response signature algorithm and the digest algorithm, The verification of the digital certificate will fail and the SSL handshake will not be completed.

Therefore, one of the concepts of the embodiment of the present application is proposed. When the client cannot support the signature algorithm and the digest algorithm of the digital certificate, the digital certificate supported by the client is dynamically loaded to perform handshake to ensure the successful handshake of the SSL/TLS.

1 is a flow chart showing the steps of an embodiment of a method for loading a digital certificate in an SSL/TLS communication, which may include the following steps:

Step 101: Receive a handshake request message sent by the client according to a Secure Sockets Layer protocol SSL or a transport layer security protocol TLS.

As shown in FIG. 2, the SSL/TLS is between the application layer and the TCP (Transmission Control Protocol) and IP (Internet Protocol) protocols.

The application layer data is no longer passed directly to the transport layer, but to the SSL/TLS layer, which encrypts the data received from the application layer.

The SSL protocol itself is divided into two layers:

The upper layer is an SSL handshake protocol, an SSL change cipher spec protocol, and an SSL alert protocol.

The underlying layer is the SSL record protocol.

SSL handshake protocol: used to negotiate the cipher suite (encryption algorithm, key exchange algorithm, MAC algorithm, etc.) used in the communication process, securely exchange keys between the server and the client, and implement authentication of the server and the client.

SSL password change protocol: The client and server notify the peer through the password change protocol, and subsequent packets will be protected and transmitted using the newly negotiated cipher suite and key.

SSL warning protocol: used to report alarm information to the communication peer. The message contains the severity and description of the alarm.

SSL record protocol: It is mainly responsible for blocking, calculating, adding MAC value, encrypting, and transmitting the processed record block to the upper layer data (SSL handshake protocol, SSL password change protocol, SSL warning protocol, and application layer protocol message). Give the opposite end.

The TLS protocol includes two protocol groups: the TLS Record Protocol and the TLS Handshake Protocol.

The TLS Recording Protocol is a layered protocol. The information in each layer may contain fields such as length, description, and content. The recording protocol supports information transfer, segmentation of data into processable blocks, compression of data, application of MAC, encryption, and transmission of results. The received data is decrypted, verified, decompressed, reorganized, etc., and then transmitted to the upper client.

The TLS handshake protocol consists of three sub-protocol groups, allowing peers to agree on the security parameters of the record layer, self-certify, instantiate security parameters, and report error conditions to each other.

Since TLS is based on SSL and is a subsequent version of SSL, there is a difference between the two, mainly because the encryption algorithms they support are different, and the overall process is basically the same. Therefore, in the implementation of this application In the example, it is mainly explained by SSL.

The first phase of the SSL handshake initiates a logical connection and establishes the security capabilities of the connection.

As shown in FIG. 3, the client sends a Client hello message (ie, a handshake request message) to the server and waits for a response from the server.

Step 102: Verify, according to the handshake request message, a key exchange mode and a first signature mode supported by the client.

Client hello messages usually include Version (version), Random (client random number), Session id (session ID), Cipher suite (client-supported cipher suite), Compression method (client-supported compression method) and other information.

Specifically, since different versions of clients (such as browsers) support different encryption and decryption algorithms, the same set of encryption and decryption algorithms can be used to ensure data encryption and decryption in the SSL communication process.

Therefore, during the SSL handshake phase, the client informs the server of the signature mode it supports, that is, the client transmits a list of locally supported cipher suites (Cipher Suite) to the server.

The server can then look up the cipher suite from the handshake request message, and identify the key exchange mode and the first signature mode supported by the client from the cipher suite.

SSL-based cipher suites usually start with "SSL". TLS-based cipher suites usually start with "TLS", followed by the key exchange method used in the key exchange phase, the symmetric encryption used to transfer data, The signature method used in the MAC used for data integrity verification (such as the hash algorithm) uses the word "With" to separate the key exchange method, the symmetric encryption method, and the signature method.

Below the example of the cipher suite:

SSL_DHE_RSA_WITH_DES_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Among them, DHE_RSA and ECDHE_ECDSA are key exchange modes, DES_CBC and AES_128_GCM are symmetric encryption modes, and SHA and SHA256 are signature modes (that is, different versions of hash algorithms).

In order to further ensure the security of the communication, the first signature method verified may be the first signature mode with the highest encryption strength of the client.

Therefore, when the server parses the Client hello, it can traverse the list of cipher suites to record the first signature method with the highest encryption strength.

In addition, if it is an extension header based on TLS and containing a TLS signature, the extension header of the transport layer security protocol TLS can be looked up from the handshake request, and the extension header indicates a list of signature methods that the client can support. The signature mode supported by the client can be read from the extension header, and the first signature party supported by the client is updated. formula.

It should be noted that some clients that use TLS, such as Internet Explorer, may not add extension headers according to the TLS specification. In this case, you can still traverse the cipher suite list to obtain the number supported by the client. A signature method.

Step 103, determining the key exchange mode and the first signature mode, whether it matches the currently loaded digital certificate; if not, executing step 104;

The format of digital certificates is generally based on the X.509V3 international standard. A standard X.509 digital certificate contains the following contents:

Version information, serial number, signature method used, issuer name, expiration date, owner name, public key used for negotiation, digital signature.

Usually, a digital certificate is an electronic certificate that needs to be applied and issued by a specialized digital certificate authority (CA).

When a digital certificate is issued, a private key and a public key are generated. The private key is kept by the server and cannot be leaked. The public key is attached to the digital certificate and can be made public.

The digital certificate itself is also accompanied by a certificate electronic signature, which is used to verify the integrity and authenticity of the certificate and to prevent the certificate from being serially altered.

In the embodiment of the present application, the digital certificate may be grouped according to the type of the public key. Currently OpenSSL (Open Secure Sockets Layer) can support three types of digital certificates at the same time, so that Better support for different types of clients and reduce the time to match digital certificates.

For example, the server is configured with the following digital certificates:

sha256WithRSAEncryption (public key using RSA)

sha1WithRSAEncryption (public key using RSA)

ecdsa-with-SHA256 (public key using ECC)

ecdsa-with-SHA1 (public key using ECC)

You can divide sha256WithRSAEncryption, sha1WithRSAEncryption into a group, that is, the public key of all digital certificates in this group uses RSA, and divides ecdsa-with-SHA256, ecdsa-with-SHA1 into another group, that is, all digital certificates in this group. The public key uses ECC.

One of the digital certificates can be loaded in each group.

In one case, the server can read the configured digital certificate into memory and load the specified digital certificate into the context of SSL or TLS at startup.

In another case, if another digital certificate is loaded during communication of SSL or TLS, the specified digital certificate can be reloaded into the context of SSL or TLS when the communication of the SSL or TLS is ended.

Since the digital certificate loading operation is relatively simple and is lightly loaded, even if the digital certificate is frequently replaced, the handshake negotiation of SSL or TLS is not affected.

In practice, you can modify the configuration file for a server (such as Tengine), allow multiple digital certificates to be configured, and modify the corresponding storage structure.

In order to further ensure the security of the communication, the currently loaded digital certificate may be the highest-encrypted digital certificate in the group to which it belongs.

For example, SHA256 has a higher encryption strength than SHA1, so for the above example grouping, you can load sha256WithRSAEncryption, ecdsa-with-SHA256.

In the embodiment of the present application, when the server (such as Tengine) initializes SSL/TLS, a callback function may be registered with the SSL/TLS service program for dynamically selecting the digital certificate according to the signature mode in the subsequent handshake phase.

During the handshake phase (that is, when the Client hello message is received for parsing), the callback function is called to pass a parameter to the callback function, that is, the signature mode supported by the client, such as the hash algorithm with the highest encryption strength.

The callback function performs a matching of the signature algorithm used by the hash algorithm with the certificate of the current same type of packet, and finds the certificate reload with the highest algorithm strength and matching the strength of the client hash algorithm.

Specifically, when matching the current digital certificate, the public key matching the key exchange manner may be searched for, and the second signature manner of the digital certificate currently loaded in the packet to which the public key belongs is identified;

Therefore, it is determined whether the first signature mode matches the second signature mode, and the so-called matching, the encryption strength of the second signature mode is equal to or lower than the encryption strength of the first signature mode.

For example, if the first signature mode is SHA256, if the second signature mode is SHA224, the two match. If the second signature mode is SHA512, the two do not match.

When the first signature mode matches the second signature mode, the key exchange mode and the signature mode may be determined to be matched with the currently loaded digital certificate;

When the first signature mode does not match the second signature mode, the key exchange mode and the signature mode may be determined to not match the currently loaded digital certificate.

For example, if the cipher suite of the client is SSL_DHE_RSA_WITH_DES_CBC_SHA, the first signature mode is SHA. If the RSA belongs to the group, the currently loaded digital certificate is sha256WithRSAEncryption, its second signature is sha256, does not match SHA, and needs to reload other matching digital certificates.

Step 104: Load other digital certificates that match the key exchange mode and the first signature mode.

In a specific implementation, the third signature mode of the other digital certificate in the group to which the public key belongs may be identified, and whether the third signature mode matches the first signature mode is determined, and if yes, the digital certificate to which the third signature mode belongs is loaded to the SSL. Or the TLS context to replace the digital certificate currently loaded in the packet to which the public key belongs. The subsequent SSL or TLS handshake operation will be sent to the client using this new digital certificate to ensure the normal operation of the handshake operation.

In order to further ensure the security of the communication, if multiple matching digital certificates are identified, the digital certificate with the highest encryption strength in the signature mode can be loaded.

Step 105: Return a handshake response message to the client according to the key exchange mode that matches the success of the digital certificate and the first signature mode.

It should be noted that, in step 103, if it is determined that the key exchange mode and the first signature mode match the currently loaded digital certificate, step 105 may be directly performed to return a handshake response message.

In step 103, if it is determined that the key exchange mode and the first signature mode do not match the currently loaded digital certificate, step 104 is executed, the matching digital certificate is loaded, and then step 105 is performed to return a handshake response. Message.

As shown in FIG. 3, the server returns a Server hello message (ie, a handshake response message) to the client, and confirms the information in the Client hello message.

Server hello usually includes Version (version, the highest version number supported by the client and the lower version number supported by the server), Random (server random number), Session id (session ID), Cipher suite (server) Information such as the selected cipher suite), Compression method (server-selected compression method).

After this phase, the client and server can know the following:

(1) SSL version;

(2) Key exchange mode, signature mode and symmetric encryption mode;

(3) compression method;

(4) Two random numbers related to key generation.

After this phase of the step, the server and client can perform handshake operations and encryption and decryption operations according to the SSL or TLS specifications.

The following is explained in the SSL specification:

The server sends the digital certificate carrying its own public key to the SSL client through a Certificate message.

The server sends a Server Hello Done message to notify the client that the version and cipher suite negotiation has ended and the key exchange begins.

After the client verifies that the server's digital certificate is valid, the public key in the digital certificate is used to encrypt the premaster secret generated by the client, and is sent to the server through the Client Key Exchange message.

The client sends a Change Cipher Spec message to inform the server that subsequent packets will be encrypted and MAC calculated using the negotiated key and cipher suite.

The client calculates the hash value of the interactive handshake message (all the interactive messages except the Change Cipher Spec message), processes the hash value (calculates and adds the MAC value, encryption, etc.) using the negotiated key and cipher suite, and passes The Finished message is sent to the SSL server.

The server uses the same method to calculate the hash value of the exchanged handshake message and compares it with the decrypted result of the Finished message. If the two are the same and the MAC value is successfully verified, the key and cipher suite negotiation is successful.

The server sends a Change Cipher Spec message to inform the SSL client that the subsequent message will be encrypted and MAC calculated using the negotiated key and cipher suite.

The server calculates the hash value of the handshake message that has been exchanged, processes the hash value (calculates and adds the MAC value, encryption, etc.) using the negotiated key and cipher suite, and sends the message to the client through the Finished message.

The client uses the same method to calculate the hash value of the exchanged handshake message and compares it with the decrypted result of the Finished message. If the two are the same and the MAC value is successfully verified, the key and cipher suite negotiation is successful.

After receiving the Finished message sent by the server, if the decryption succeeds, the client can determine that the server is the owner of the digital certificate, that is, the server authentication succeeds, because only the server with the private key can decrypt the premaster secret from the Client Key Exchange message. Indirectly, the client-to-server authentication is implemented.

After the handshake is completed, the server and the client respectively generate the symmetric master key required for encryption, the authentication key and the initialization vector used for integrity verification, respectively, using the preliminary master key.

In the data transmission phase, for each data packet, the sender (server or client) will first encrypt with the symmetric key, and use the authentication key to group the data according to the signature negotiated during the handshake (such as MD5 or SHA based MAC). Algorithm) to sign and generate a summary.

The receiving end (client or server) decrypts with a symmetric key, and uses the authentication key to sign the decrypted data according to the signature method negotiated during handshake (such as MD5 or SHA based MAC algorithm), generating a digest and receiving it. The summary is compared to verify the integrity of the data.

If the two are the same, the packet is not changed; otherwise, the packet is modified during transmission, and the receiver (client or server) will discard the packet.

It should be noted that, for the method embodiments, for the sake of simple description, they are all expressed as a series of action combinations, but those skilled in the art should understand that the embodiments of the present application are not limited by the described action sequence, because In accordance with embodiments of the present application, certain steps may be performed in other sequences or concurrently. In the following, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required in the embodiments of the present application.

Referring to FIG. 4, a structural block diagram of an apparatus for loading a digital certificate in an SSL/TLS communication according to the present application is shown. Specifically, the following modules may be included:

The handshake request message receiving module 401 is configured to receive a handshake request message sent by the client according to the Secure Sockets Layer protocol SSL or the transport layer security protocol TLS;

The client information verification module 402 is configured to verify, according to the handshake request message, a key exchange manner supported by the client and a first signature manner;

The digital certificate matching module 403 is configured to determine whether the key exchange mode and the first signature mode are matched with the currently loaded digital certificate; if not, the digital certificate loading module 404 is invoked;

The digital certificate loading module 404 loads other digital certificates that match the key exchange manner and the first signature manner;

The handshake response message returning module 405 is configured to return a handshake response message to the client according to the key exchange mode that matches the success of the digital certificate and the first signature mode.

In an embodiment of the present application, the client information verification module 402 may include the following sub-modules:

In an embodiment of the present application, the client information verification module 402 may further include the following sub-modules:

In a specific implementation, the first signature mode that is verified may be the first signature mode with the highest encryption strength of the client.

In an actual application, the digital certificate may be grouped according to the type of the public key, and one of the digital certificates is loaded in each group, and the currently loaded digital certificate may be the digital certificate with the highest encryption strength in the group.

In an embodiment of the present application, the digital certificate matching module 404 may include the following sub-modules:

a current signature mode identification submodule, configured to identify a second signature mode of the digital certificate currently loaded in the packet to which the public key belongs;

a first determining submodule, configured to determine the key exchange mode and the signature manner, and match the currently loaded digital certificate;

The second determining sub-module is configured to determine that the key exchange mode and the signature mode do not match the currently loaded digital certificate.

In an embodiment of the present application, the digital certificate loading module 405 may include the following sub-modules:

For the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.

The various embodiments in the present specification are described in a progressive manner, and each embodiment focuses on differences from other embodiments, and the same similar parts between the various embodiments can be referred to each other.

Those skilled in the art will appreciate that embodiments of the embodiments of the present application can be provided as a method, apparatus, or computer program product. Therefore, embodiments of the present application may adopt an entirely hardware embodiment, an entirely software embodiment, or a combination of soft A form of embodiment of hardware and hardware. Moreover, embodiments of the present application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.

In a typical configuration, the computer device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory. The memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory. Memory is an example of a computer readable medium. Computer readable media includes both permanent and non-persistent, removable and non-removable media. Information storage can be implemented by any method or technology. The information can be computer readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include non-persistent computer readable media, such as modulated data signals and carrier waves.

Embodiments of the present application are described with reference to flowcharts and/or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the present application. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor or other programmable data processing terminal device to produce a machine such that instructions are executed by a processor of a computer or other programmable data processing terminal device Means are provided for implementing the functions specified in one or more of the flow or in one or more blocks of the flow chart.

The computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device. The instruction device implements the functions specified in one or more blocks of the flowchart or in a flow or block of the flowchart.

These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device such that a series of operational steps are performed on the computer or other programmable terminal device to produce computer-implemented processing, such that the computer or other programmable terminal device The instructions executed above provide steps for implementing the functions specified in one or more blocks of the flowchart or in a block or blocks of the flowchart.

While a preferred embodiment of the embodiments of the present application has been described, those skilled in the art can make further changes and modifications to the embodiments once they are aware of the basic inventive concept. Therefore, the appended claims are intended to be interpreted as including all the modifications and the modifications

Finally, it should also be noted that in this context, relational terms such as first and second are used merely to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply these entities. There is any such actual relationship or order between operations. Furthermore, the terms "comprises" or "comprising" or "comprising" or any other variations are intended to encompass a non-exclusive inclusion, such that a process, method, article, or terminal device that includes a plurality of elements includes not only those elements but also Other elements that are included, or include elements inherent to such a process, method, article, or terminal device. An element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or terminal device that comprises the element, without further limitation.

The above provides a method for loading a digital certificate in SSL/TLS communication and a device for loading a digital certificate in SSL/TLS communication provided by the present application, and a specific example is applied to the principle of the present application. The description of the above embodiments is only for helping to understand the method of the present application and its core ideas; at the same time, for those skilled in the art, according to the idea of the present application, in the specific implementation and application scope There are variations, and the contents of this specification should not be construed as limiting the application.

Claims

A method for loading a digital certificate in an SSL or TLS communication, comprising:

Receiving a handshake request message sent by the client based on the Secure Sockets Layer protocol SSL or the Transport Layer Security Protocol TLS;

And verifying, according to the handshake request message, a key exchange manner supported by the client and a first signature manner;

Determining whether the key exchange mode and the first signature mode match the currently loaded digital certificate; if not, loading other digital certificates that match the key exchange mode and the first signature mode;

And returning a handshake response message to the client according to the key exchange manner that matches the success of the digital certificate and the first signature manner.
The method according to claim 1, wherein the step of verifying the key exchange mode and the first signature mode supported by the client according to the handshake request message comprises:

Finding a cipher suite from the handshake request message;

The key exchange mode and the first signature mode supported by the client are identified from the cipher suite.
The method according to claim 2, wherein the step of verifying the key exchange mode and the first signature mode supported by the client according to the handshake request message further comprises:

Finding an extension header of the transport layer security protocol TLS from the handshake request;

A first signature mode supported by the client is identified from the extension header.
The method according to claim 1 or 2 or 3, wherein the verified first signature mode is a first signature mode with the highest encryption strength of the client.
The method according to claim 1 or 2 or 3, wherein the digital certificate is divided into groups according to the type of the public key, and one of the digital certificates is loaded in each of the packets, and the currently loaded digital certificate is encrypted in the belonging group. The highest strength digital certificate.
The method according to claim 5, wherein the step of determining whether the key exchange mode and the signature mode match the currently loaded digital certificate comprises:

Finding a public key that matches the key exchange method;

Identifying a second signature manner of the digital certificate currently loaded in the packet to which the public key belongs;

Determining whether the first signature mode matches the second signature mode;

If yes, determining that the key exchange mode and the signature manner match the currently loaded digital certificate;

If not, it is determined that the key exchange mode and the signature mode do not match the currently loaded digital certificate.
The method according to claim 6, wherein the step of loading other digital certificates matching the key exchange mode and the first signature mode comprises:

Identifying a third signature manner of other digital certificates in the group to which the public key belongs;

Determining whether the third signature mode matches the first signature mode;

If yes, the digital certificate to which the third signature mode belongs is loaded to replace the digital certificate currently loaded in the packet to which the public key belongs.
An apparatus for loading a digital certificate in an SSL or TLS communication, comprising:

a handshake request message receiving module, configured to receive a handshake request message sent by the client based on a Secure Sockets Layer protocol SSL or a Transport Layer Security Protocol TLS;

a client information verification module, configured to verify, according to the handshake request message, a key exchange manner supported by the client and a first signature manner;

a digital certificate matching module, configured to determine whether the key exchange mode and the first signature mode match the currently loaded digital certificate; if not, the digital certificate loading module is invoked;

a digital certificate loading module, loading other digital certificates matching the key exchange manner and the first signature manner;

The handshake response message returning module is configured to return a handshake response message to the client according to the key exchange manner that matches the success of the digital certificate and the first signature manner.
The device according to claim 8, wherein the client information verification module comprises:

a cipher suite lookup submodule for finding a cipher suite from the handshake request message;

The cipher suite identification submodule is configured to identify, from the cipher suite, a key exchange mode and a first signature mode supported by the client.
The device according to claim 9, wherein the client information verification module further comprises:

An extension header search submodule, configured to search for an extension header of a transport layer security protocol TLS from the handshake request;

The extended header identification submodule is configured to identify, from the extended header, a first signature manner supported by the client.
The apparatus according to claim 8 or 9 or 10, wherein the digital certificate is divided into groups according to the type of the public key, and one of the digital certificates is loaded in each of the packets, and the currently loaded digital certificate is encrypted in the belonging group. The highest strength digital certificate.
The device according to claim 11, wherein the digital certificate matching module comprises:

a public key lookup submodule, configured to find a public key that matches the key exchange manner;

a current signature mode identification submodule, configured to identify a second signature mode of the digital certificate currently loaded in the packet to which the public key belongs;

a first signature matching submodule, configured to determine whether the first signature mode matches the second signature mode; if yes, the first determining submodule is invoked, and if not, the second determining submodule is invoked;

a first determining submodule, configured to determine that the key exchange mode and the signature manner match the currently loaded digital certificate;

The second determining submodule is configured to determine that the key exchange mode and the signature manner do not match the currently loaded digital certificate.
The device according to claim 12, wherein the digital certificate loading module comprises:

a further signature mode identifying submodule, configured to identify a third signature mode of other digital certificates in the group to which the public key belongs;

a second signature matching sub-module, configured to determine whether the third signature mode matches the first signature mode; if yes, calling a digital certificate replacement sub-module;

And a digital certificate replacement submodule, configured to load the digital certificate to which the third signature mode belongs, to replace the digital certificate currently loaded in the packet to which the public key belongs.