WO2017045552A1 - Procédé et dispositif pour charger un certificat numérique dans une communication de couche de prise sécurisée (ssl) ou de sécurité de couche de transport (tls) - Google Patents

Procédé et dispositif pour charger un certificat numérique dans une communication de couche de prise sécurisée (ssl) ou de sécurité de couche de transport (tls) Download PDF

Info

Publication number
WO2017045552A1
WO2017045552A1 PCT/CN2016/098186 CN2016098186W WO2017045552A1 WO 2017045552 A1 WO2017045552 A1 WO 2017045552A1 CN 2016098186 W CN2016098186 W CN 2016098186W WO 2017045552 A1 WO2017045552 A1 WO 2017045552A1
Authority
WO
WIPO (PCT)
Prior art keywords
signature
digital certificate
mode
client
key exchange
Prior art date
Application number
PCT/CN2016/098186
Other languages
English (en)
Chinese (zh)
Inventor
齐铁鹏
杨洋
刘立朋
李振宇
蒋锷
周辉
Original Assignee
阿里巴巴集团控股有限公司
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 阿里巴巴集团控股有限公司 filed Critical 阿里巴巴集团控股有限公司
Publication of WO2017045552A1 publication Critical patent/WO2017045552A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Definitions

  • 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.
  • HTTPS Hyper Text Transfer Protocol over Secure Socket Layer
  • 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.
  • SSL Secure Sockets Layer
  • TLS Transport Layer Security
  • SSL/TLS 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.
  • 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.
  • 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.
  • the embodiment of the present application discloses a method for loading a digital certificate in SSL or TLS communication, including:
  • the step of verifying the key exchange mode and the first signature mode supported by the client according to the handshake request message includes:
  • 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:
  • a first signature mode supported by the client is identified from the extension header.
  • the first signature mode that is verified is the first signature mode with the highest encryption strength of the client.
  • 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.
  • the step of determining whether the key exchange mode and the signature mode match the currently loaded digital certificate comprises:
  • loading the other digital certificate that matches the key exchange manner and the first signature manner The steps include:
  • 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.
  • 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
  • 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.
  • the first signature mode that is verified is the first signature mode with the highest encryption strength of the client.
  • 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.
  • 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.
  • 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;
  • 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.
  • 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.
  • FIG. 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
  • FIG. 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the server sends the specified certificate (certificate chain) to the client for authentication.
  • the client 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.
  • 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.
  • 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.
  • the digital certificate supported by the client is dynamically loaded to perform handshake to ensure the successful handshake of the SSL/TLS.
  • FIG. 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.
  • SSL Secure Sockets Layer protocol
  • TLS transport layer security protocol
  • the SSL/TLS is between the application layer and the TCP (Transmission Control Protocol) and IP (Internet Protocol) protocols.
  • TCP Transmission Control Protocol
  • IP Internet Protocol
  • 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.
  • 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.
  • the client sends a Client hello message (ie, a handshake request message) to the server and waits for a response from the server.
  • a Client hello message ie, a handshake request message
  • 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.
  • the same set of encryption and decryption algorithms can be used to ensure data encryption and decryption in the SSL communication process.
  • 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.
  • Cipher Suite locally supported cipher suites
  • 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 uses the word "With” to separate the key exchange method, the symmetric encryption method, and the signature method.
  • DHE_RSA and ECDHE_ECDSA are key exchange modes
  • DES_CBC and AES_128_GCM are symmetric encryption modes
  • SHA and SHA256 are signature modes (that is, different versions of hash algorithms).
  • the first signature method verified may be the first signature mode with the highest encryption strength of the client.
  • 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.
  • 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.
  • TLS Transmission Control Protocol
  • 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 may be used.
  • 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;
  • 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.
  • a digital certificate is an electronic certificate that needs to be applied and issued by a specialized digital certificate authority (CA).
  • CA digital certificate authority
  • 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.
  • the digital certificate may be grouped according to the type of the public key.
  • OpenSSL Open Secure Sockets Layer
  • the server is configured with the following digital certificates:
  • One of the digital certificates can be loaded in each group.
  • 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.
  • the specified digital certificate can be reloaded into the context of SSL or TLS when the communication of the SSL or TLS is ended.
  • 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.
  • the currently loaded digital certificate may be the highest-encrypted digital certificate in the group to which it belongs.
  • SHA256 has a higher encryption strength than SHA1, so for the above example grouping, you can load sha256WithRSAEncryption, ecdsa-with-SHA256.
  • 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.
  • 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.
  • 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;
  • the encryption strength of the second signature mode is equal to or lower than the encryption strength of the first signature mode.
  • the first signature mode is SHA256
  • the second signature mode is SHA224
  • the two match If the second signature mode is SHA512, the two do not match.
  • the key exchange mode and the signature mode may be determined to be matched with the currently loaded digital certificate
  • the key exchange mode and the signature mode may be determined to not match the currently loaded digital certificate.
  • 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.
  • 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.
  • 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.
  • step 105 may be directly performed to return a handshake response message.
  • 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.
  • the server returns a Server hello message (ie, a handshake response message) to the client, and confirms the information in the Client hello message.
  • a Server hello message ie, a handshake response 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).
  • 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 client and server can know the following:
  • the server and client can perform handshake operations and encryption and decryption operations according to the SSL or TLS specifications.
  • 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.
  • 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.
  • the client 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.
  • 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.
  • 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 signature such as MD5 or SHA based MAC.
  • Algorithm Algorithm
  • the receiving end 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.
  • the packet is not changed; otherwise, the packet is modified during transmission, and the receiver (client or server) will discard the packet.
  • 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.
  • the client information verification module 402 may include the following sub-modules:
  • 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
  • the client information verification module 402 may further include the following sub-modules:
  • 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 first signature mode that is verified may be the first signature mode with the highest encryption strength of the client.
  • 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.
  • the digital certificate matching module 404 may include the following sub-modules:
  • 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 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.
  • the digital certificate loading module 405 may include the following sub-modules:
  • 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;
  • 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.
  • the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
  • 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.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • 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.
  • RAM random access memory
  • ROM read only 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé et un dispositif pour charger un certificat numérique dans une communication de couche de prise sécurisée (SSL) ou de sécurité de couche de transport (TLS). Le procédé consiste à : recevoir un message de requête d'établissement de liaison envoyé par un client sur la base d'une couche de prise sécurisée (SSL) ou d'une sécurité de couche de transport (TLS) ; selon le message de requête d'établissement de liaison, vérifier un mode d'échange de clé et un premier mode de signature pris en charge par le client ; déterminer si le mode d'échange de clé et le premier mode de signature correspondent ou non à un certificat numérique chargé actuellement ; si tel n'est pas le cas, charger un autre certificat numérique correspondant au mode d'échange de clé et au premier mode de signature ; et selon le mode d'échange de clé et le premier mode de signature correspondant avec succès au certificat numérique, renvoyer un message de réponse d'établissement de liaison au client. Les modes de réalisation de la présente invention parviennent au chargement dynamique d'un certificat numérique approprié dans un processus de négociation d'établissement de liaison, ce qui permet de garantir l'achèvement réussi d'une négociation d'établissement de liaison SSL/TLS.
PCT/CN2016/098186 2015-09-15 2016-09-06 Procédé et dispositif pour charger un certificat numérique dans une communication de couche de prise sécurisée (ssl) ou de sécurité de couche de transport (tls) WO2017045552A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510587689.7 2015-09-15
CN201510587689.7A CN106533689B (zh) 2015-09-15 2015-09-15 一种在ssl/tls通信中加载数字证书的方法和装置

Publications (1)

Publication Number Publication Date
WO2017045552A1 true WO2017045552A1 (fr) 2017-03-23

Family

ID=58288106

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/098186 WO2017045552A1 (fr) 2015-09-15 2016-09-06 Procédé et dispositif pour charger un certificat numérique dans une communication de couche de prise sécurisée (ssl) ou de sécurité de couche de transport (tls)

Country Status (2)

Country Link
CN (1) CN106533689B (fr)
WO (1) WO2017045552A1 (fr)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108040071A (zh) * 2017-12-30 2018-05-15 深圳市潮流网络技术有限公司 一种VoIP音视频加密密钥动态切换方法
CN111771357A (zh) * 2019-01-31 2020-10-13 深圳市汇顶科技股份有限公司 Tls证书认证方法、装置、设备及存储介质
CN112235235A (zh) * 2020-08-28 2021-01-15 中国大唐集团科学技术研究院有限公司 一种基于国密算法的sdp认证协议实现方法
CN112532390A (zh) * 2019-08-30 2021-03-19 华为技术有限公司 加载数字证书认证机构证书的方法及装置
CN113364776A (zh) * 2021-06-04 2021-09-07 北银金融科技有限责任公司 一种验证区块链节点使用国密算法通信的方法和系统
CN113746807A (zh) * 2021-08-11 2021-12-03 北银金融科技有限责任公司 一种区块链节点支持国密算法通信检测方法
CN114448729A (zh) * 2022-04-07 2022-05-06 中国信息通信研究院 工业互联网中客户端的身份认证方法和装置
CN114830602A (zh) * 2019-12-17 2022-07-29 微芯片技术股份有限公司 用于低吞吐量通信链路的系统的相互认证协议及用于执行该协议的设备
CN115021932A (zh) * 2022-05-30 2022-09-06 支付宝(杭州)信息技术有限公司 用于tlcp协议的握手过程的身份验证方法
CN115714681A (zh) * 2022-11-11 2023-02-24 中国联合网络通信集团有限公司 数据验证方法、装置及存储介质
CN117560718A (zh) * 2024-01-11 2024-02-13 广东广宇科技发展有限公司 一种基于群智感知的消防物联网远程监测方法

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2561822B (en) * 2017-04-13 2020-02-19 Arm Ip Ltd Reduced bandwidth handshake communication
CN106936848A (zh) * 2017-04-19 2017-07-07 武汉票据交易中心有限公司 一种服务器的socket加密通信方法
CN109302369B (zh) * 2017-07-24 2021-03-16 贵州白山云科技股份有限公司 一种基于密钥验证的数据传输方法及装置
CN108566361B (zh) * 2018-01-05 2020-08-21 武汉信安珞珈科技有限公司 一种基于ssl/tls协议的安全参数协商方法和系统
CN108429615A (zh) * 2018-01-10 2018-08-21 如般量子科技有限公司 一种基于量子密钥的Stunnel通信方法和Stunnel通信系统
CN108833541A (zh) * 2018-06-15 2018-11-16 北京奇安信科技有限公司 一种识别终端信息的方法及装置
CN109905239A (zh) * 2019-03-07 2019-06-18 亚数信息科技（上海）有限公司 一种证书管理方法及装置
CN111917694B (zh) * 2019-05-09 2023-02-28 中兴通讯股份有限公司 一种tls加密流量识别方法及装置
CN110971616B (zh) * 2019-12-24 2022-04-01 广州市百果园信息技术有限公司 基于安全传输层协议的连接建立方法、客户端和服务器
CN111064738B (zh) * 2019-12-26 2022-09-30 山东方寸微电子科技有限公司 一种tls安全通信的方法及系统
EP3866428B1 (fr) * 2020-02-13 2021-12-29 Axis AB Procédé de réapprovisionnement d'un certificat de sécurité numérique, système et son produit programme informatique non transitoire
CN113328980B (zh) * 2020-02-29 2022-05-17 杭州迪普科技股份有限公司 Tls认证方法、装置、系统、电子设备及可读介质
CN112422530B (zh) * 2020-11-04 2023-05-30 无锡沐创集成电路设计有限公司 Tls握手过程中服务器端的密钥安全保护方法及密码设备
CN112637348B (zh) * 2020-12-23 2022-05-10 北京金山云网络技术有限公司 一种连接建立方法、装置、系统及电子设备
CN112906063B (zh) * 2021-02-26 2024-04-26 杭州萤石软件有限公司 一种数字摘要算法处理设备方法、装置、系统及设备
CN113037480A (zh) * 2021-03-25 2021-06-25 北京华宇信息技术有限公司 基于jsse的国密加密通信方法及其装置、存储介质
CN114006724B (zh) * 2021-09-18 2023-08-29 中国互联网络信息中心 一种加密dns解析器发现及认证的方法与系统
CN113872990B (zh) * 2021-10-19 2023-06-30 南方电网数字电网研究院有限公司 基于ssl协议的vpn网络证书认证方法、装置和计算机设备
CN115150067A (zh) * 2022-05-10 2022-10-04 北京理工大学 一种基于网络隐蔽通道的tls协议构建方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101127604A (zh) * 2007-09-25 2008-02-20 中兴通讯股份有限公司 信息安全传输方法和系统
CN101770619A (zh) * 2008-12-31 2010-07-07 中国银联股份有限公司 一种用于网上支付的多因子认证方法和认证系统
CN103607417A (zh) * 2012-12-03 2014-02-26 深圳市证通电子股份有限公司 支持ssl协议的网络服务器
US8782774B1 (en) * 2013-03-07 2014-07-15 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
CN104639534A (zh) * 2014-12-30 2015-05-20 北京奇虎科技有限公司 网站安全信息的加载方法和浏览器装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2712242C (fr) * 2008-01-18 2017-03-28 Identrust, Inc. Liaison d'un certificat numerique a de multiples domaines de confiance
CN101325519B (zh) * 2008-06-05 2011-02-16 成都市华为赛门铁克科技有限公司 基于安全协议的内容审计方法、系统和内容审计设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101127604A (zh) * 2007-09-25 2008-02-20 中兴通讯股份有限公司 信息安全传输方法和系统
CN101770619A (zh) * 2008-12-31 2010-07-07 中国银联股份有限公司 一种用于网上支付的多因子认证方法和认证系统
CN103607417A (zh) * 2012-12-03 2014-02-26 深圳市证通电子股份有限公司 支持ssl协议的网络服务器
US8782774B1 (en) * 2013-03-07 2014-07-15 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
CN104639534A (zh) * 2014-12-30 2015-05-20 北京奇虎科技有限公司 网站安全信息的加载方法和浏览器装置

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108040071B (zh) * 2017-12-30 2023-02-17 深圳市潮流网络技术有限公司 一种VoIP音视频加密密钥动态切换方法
CN108040071A (zh) * 2017-12-30 2018-05-15 深圳市潮流网络技术有限公司 一种VoIP音视频加密密钥动态切换方法
CN111771357A (zh) * 2019-01-31 2020-10-13 深圳市汇顶科技股份有限公司 Tls证书认证方法、装置、设备及存储介质
CN111771357B (zh) * 2019-01-31 2022-05-24 深圳市汇顶科技股份有限公司 Tls证书认证方法、装置、设备及存储介质
CN112532390A (zh) * 2019-08-30 2021-03-19 华为技术有限公司 加载数字证书认证机构证书的方法及装置
CN114830602A (zh) * 2019-12-17 2022-07-29 微芯片技术股份有限公司 用于低吞吐量通信链路的系统的相互认证协议及用于执行该协议的设备
CN112235235A (zh) * 2020-08-28 2021-01-15 中国大唐集团科学技术研究院有限公司 一种基于国密算法的sdp认证协议实现方法
CN112235235B (zh) * 2020-08-28 2023-09-22 中国大唐集团科学技术研究院有限公司 一种基于国密算法的sdp认证协议实现方法
CN113364776A (zh) * 2021-06-04 2021-09-07 北银金融科技有限责任公司 一种验证区块链节点使用国密算法通信的方法和系统
CN113746807A (zh) * 2021-08-11 2021-12-03 北银金融科技有限责任公司 一种区块链节点支持国密算法通信检测方法
CN114448729B (zh) * 2022-04-07 2022-06-07 中国信息通信研究院 工业互联网中客户端的身份认证方法和装置
CN114448729A (zh) * 2022-04-07 2022-05-06 中国信息通信研究院 工业互联网中客户端的身份认证方法和装置
CN115021932A (zh) * 2022-05-30 2022-09-06 支付宝(杭州)信息技术有限公司 用于tlcp协议的握手过程的身份验证方法
CN115714681A (zh) * 2022-11-11 2023-02-24 中国联合网络通信集团有限公司 数据验证方法、装置及存储介质
CN115714681B (zh) * 2022-11-11 2024-05-14 中国联合网络通信集团有限公司 数据验证方法、装置及存储介质
CN117560718A (zh) * 2024-01-11 2024-02-13 广东广宇科技发展有限公司 一种基于群智感知的消防物联网远程监测方法
CN117560718B (zh) * 2024-01-11 2024-04-09 广东广宇科技发展有限公司 一种基于群智感知的消防物联网远程监测方法

Also Published As

Publication number Publication date
CN106533689A (zh) 2017-03-22
CN106533689B (zh) 2019-07-30

Similar Documents

Publication Publication Date Title
WO2017045552A1 (fr) Procédé et dispositif pour charger un certificat numérique dans une communication de couche de prise sécurisée (ssl) ou de sécurité de couche de transport (tls)
JP7215684B2 (ja) 部分的に信頼できる第三者機関を通しての鍵交換
KR102392420B1 (ko) 다중키 쌍 시그너처를 사용한 프로그램 실행 및 데이터 증명 체계
CN109347835B (zh) 信息传输方法、客户端、服务器以及计算机可读存储介质
US10826708B2 (en) Authenticating nonces prior to encrypting and decrypting cryptographic keys
US11985239B2 (en) Forward secrecy in transport layer security (TLS) using ephemeral keys
EP3391620B1 (fr) Systèmes et procédés de communications sécurisées à parties multiples en utilisant un mandataire
RU2718689C2 (ru) Управление конфиденциальной связью
WO2016107320A1 (fr) Procédé de chargement d'informations de sécurité de site web, et navigateur
US11533297B2 (en) Secure communication channel with token renewal mechanism
US20170346819A1 (en) Mutual authentication with symmetric secrets and signatures
WO2016107318A1 (fr) Système sécurisé de communications
US11303431B2 (en) Method and system for performing SSL handshake
TW201742399A (zh) 資料安全傳輸方法、客戶端及服務端方法、裝置及系統
WO2016107322A1 (fr) Procédé de mise en œuvre pour navigateur sécurisé, et dispositif de navigateur sécurisé
KR20210134655A (ko) 보안 시스템 및 관련 방법
AU2016287732A1 (en) Mutual authentication of confidential communication
JP2015115893A (ja) 通信方法、通信プログラム、および中継装置
US10963593B1 (en) Secure data storage using multiple factors
EP4022840A1 (fr) Techniques décentralisées pour la vérification de données dans la sécurité de couche de transport et d'autres contextes
WO2016112580A1 (fr) Procédé et dispositif de traitement de service
KR102128244B1 (ko) Ssl/tls 기반의 네트워크 보안 장치 및 방법
JP2014147039A (ja) 暗号通信装置、代行サーバ、暗号通信システム、暗号通信装置プログラム及び代行サーバプログラム
WO2019223232A1 (fr) Procédé et dispositif d'authentification d'informations de transaction
WO2019223231A1 (fr) Procédé et dispositif de réalisation d'une authentification d'informations de transaction

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16845666

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16845666

Country of ref document: EP

Kind code of ref document: A1