CN115567288A - A dynamic certificate proxy method based on openresty - Google Patents

Abstract

The invention provides a dynamic certificate proxy method based on openness, belongs to the technical field of Web communication, and solves the technical problem of reuse of a proxy server port. The dynamic certificate proxy method based on openness is realized by the following steps: s1, acquiring sni information sent to a server by a client through clientHello information in a TLS/SSL handshake process; s2, searching a certificate and a secret key of a corresponding server according to the obtained sni information; s3, configuring the certificate and the secret key into a web server; and S4, returning the newly configured certificate when TLS/SSL handshake is carried out with the client. The invention has the advantages of reducing the complexity of the system and increasing the convenience and maintainability.

Description

A dynamic certificate proxy method based on openresty

technical field

The invention belongs to the technical field of Web communication, and relates to an openresty-based dynamic certificate proxy method.

Background technique

When making a TLS connection, the client requests a digital certificate from the web server. Once the server sends the certificate, the client checks the certificate and compares the name it is trying to connect to with the name contained in the certificate. If a match occurs, the connection proceeds normally. If no match is found, the user may be warned of the discrepancy and the connection may be aborted, as the mismatch may indicate a man-in-the-middle attack. However, some applications allow the user to bypass the warning and continue connecting, and it is the user's responsibility to trust the certificate and connect.

It is possible to cover multiple hostnames with one certificate. The X.509v3 specification introduces the subjectAltName field, which allows a certificate to specify multiple domain names, and uses wildcards in the common name and subjectAltName fields.

Nginx is a lightweight web server/reverse proxy server and email (IMAP/POP3) proxy server, released under the BSD-like protocol. Its characteristic is that it occupies less memory and has strong concurrency capability. In fact, the concurrency capability of nginx is better than other web servers of the same type. Because in the stream of nginx, only one pair of certificate and key can be configured for the same server context listening port, but in some usage scenarios, if you want to return the corresponding certificate according to different access addresses, you need to configure There are multiple servers in the configuration file, and the problem of port reuse cannot be solved.

However, due to the lack of a complete list of all names, it may be difficult or even impossible to obtain a single certificate covering all the names the server will be responsible for. A server responsible for multiple hostnames may need to present a different certificate for each name (or set of names). Since 2005, CAcert has been running experiments with different uses of TLS on virtual servers. Most experiments are suboptimal and impractical. For example, subjectAltName can be used to include multiple domain names controlled by one person in a single certificate. Such "unified communications certificates" must be reissued whenever the list of domain names changes.

Name-based virtual hosting allows multiple DNS hostnames to be hosted by a single server (usually a web server) on the same IP address. To achieve this, the server uses the hostname provided by the client as part of the protocol (for HTTP, the name appears in the Host header). However, when using HTTPS, the TLS handshake happens before the server sees any HTTP headers. Therefore, it is impossible for the server to use the information in the HTTP host header to decide which certificate to present, so only names covered by the same certificate can be served by the same IP address.

Contents of the invention

The purpose of the present invention is to solve the above-mentioned problems in the existing technology, and propose a dynamic certificate proxy method based on openresty. The present invention solves the problem of proxy server port reuse, and can use the same port to proxy different sites and configure different Certificate.

The purpose of the present invention can be achieved through the following technical solutions:

An openresty-based dynamic certificate proxy method is characterized in that it is implemented through the following steps:

S1. Obtain the sni information sent by the client to the server through the clientHello information in the TLS/SSL handshake process;

S2. Find the certificate and key of the corresponding server according to the acquired sni information;

S3, configure the certificate and key into the web server;

S4. The newly configured certificate is returned when the TLS/SSL handshake is performed with the client.

Further, the TLS/SSL handshake process is as follows:

(1) The client sends a ClientHello message to the server;

(2) For the ClientHello message sent by the client, the server will return a ServerHello message;

(3) The server sends a Certificate message, and the client verifies the certificate sent by the server;

(4) The server sends a ServerKeyExchange message;

(5) The server sends a ServerHelloDone message;

(6) The client sends a ClientKeyExchange message;

(7) The client and the server exchange messages, and use the key negotiated in step (6) to encrypt.

Further, in step (1), the client needs to negotiate with the server, specifically which method to use for communication.

Further, in step (2), the ServerHello message returned by the server will inform the client of the communication method adopted.

Further, in step (3), the server can also choose whether to send a CertificateRequest message; the CertificateRequest message is used for the server to request a certificate from the client, which is for client authentication. When the client authentication is not used, the CertificateRequest will not be sent information.

Furthermore, when the server sends a CertificateRequest message in step (3), the client sends its own certificate together with the Certificate message to the server; when the server does not send a CertificateRequest message, the client does not send a Certificate message.

Further, in step (4), when the Certificate message is insufficient to meet the requirements, the server will send some necessary information to the client through the ServerKeyExchange message, and the content of the specific information sent will vary according to the used cipher suite. When this information is not needed, the ServerKeyExchange message will not be sent.

Further, in step (5), the message ServerHelloDone indicates the end of a series of messages starting from the ServerHello message.

Compared with the prior art, this openresty-based dynamic certificate proxy method has the following advantages:

The present invention does not require certificates to include all domain names, and only needs to return corresponding certificates according to the requested domain name, which reduces system complexity and increases convenience and maintainability.

Description of drawings

Fig. 1 is a work flowchart of the present invention.

Fig. 2 is a flow chart of ssl handshake in the present invention.

Fig. 3 is the sni information in the clienthello information in the present invention.

detailed description

The following are specific embodiments of the present invention and in conjunction with the accompanying drawings, the technical solutions of the present invention are further described, but the present invention is not limited to these embodiments.

As shown in Figure 1, this embodiment provides an openresty-based dynamic certificate proxy method, which is implemented through the following steps:

S1. Obtain the sni information sent by the client to the server through the clientHello information in the TLS/SSL handshake process;

S2. Find the certificate and key of the corresponding server according to the acquired sni information;

S3, configure the certificate and key into the web server;

S4. The newly configured certificate is returned when the TLS/SSL handshake is performed with the client.

Further, the TLS/SSL handshake process is as follows:

(1) The client sends a ClientHello message to the server;

(2) For the ClientHello message sent by the client, the server will return a ServerHello message;

(3) The server sends a Certificate message, and the client verifies the certificate sent by the server;

(4) The server sends a ServerKeyExchange message;

(5) The server sends a ServerHelloDone message;

(6) The client sends a ClientKeyExchange message;

(7) The client and the server exchange messages, and use the key negotiated in step (6) to encrypt.

Further, in step (1), the client needs to negotiate with the server, specifically which method to use for communication.

Further, in step (2), the ServerHello message returned by the server will inform the client of the communication method adopted.

Further, in step (3), the server can also choose whether to send a CertificateRequest message; the CertificateRequest message is used for the server to request a certificate from the client, which is for client authentication. When the client authentication is not used, the CertificateRequest will not be sent information.

Furthermore, when the server sends a CertificateRequest message in step (3), the client sends its own certificate together with the Certificate message to the server; when the server does not send a CertificateRequest message, the client does not send a Certificate message.

Further, in step (4), when the Certificate message is insufficient to meet the requirements, the server will send some necessary information to the client through the ServerKeyExchange message, and the content of the specific information sent will vary according to the used cipher suite. When this information is not needed, the ServerKeyExchange message will not be sent.

Further, in step (5), the message ServerHelloDone indicates the end of a series of messages starting from the ServerHello message.

As shown in Figure 2-3, in the handshake phase of TLS communication, the client will send ClientHello information, and through the SNI extension, the domain name information will be notified to the server in advance.

When Nginx starts, it will read the configured certificate content, and after a series of parsing, finally set the certificate by calling OpenSSL's SSL_use_certificate. For a matching private key, Nginx calls SSL_use_PrivateKey. Since OpenSSL allows us to dynamically set the certificate and private key, we can set the certificate and private key before establishing a connection. In this way, we can combine SNI (Server Name Indication) to dynamically set different certificates and private keys for different request domain names, without having to prepare all possible certificates and private keys in advance.

是一个基于Nginx与Lua的高性能Web平台，其内部集成了大量精良的Lua库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态Web应用、 Web服务和动态网关。

It is a high-performance web platform based on Nginx and Lua, which integrates a large number of excellent Lua libraries, third-party modules and most of its dependencies. It is used to conveniently build dynamic web applications, web services and dynamic gateways that can handle ultra-high concurrency and high scalability.

With OpenResty, we can easily turn this idea into reality. Required, are the ssl_certificate_by_lua* directives and the ngx.ssl module from lua-resty-core. In addition, the OpenSSL specified when compiling OpenResty requires version 1.0.2e or above.

See sample code below:

In the code above, the ssl_certificate_by_lua_block directive runs the user's Lua code when Nginx is about to initiate an SSL handshake for a downstream SSL connection.

In the lua code, first use ngx.ssl.clear_certs() to clear the certificate and private key used as a placeholder, then get the destination domain name requested by the client through ngx.ssl.server_name(), and then pass the obtained The target domain name obtains the corresponding certificate and key from disk or memory (the code in get_my_pem_cert_data(server_name) is implemented on demand according to business requirements), and finally calls ngx.ssl.set_cert and ngx.ssl.set_priv_key to obtain the certificate and key The key is configured into nginx.

The specific embodiments described herein are merely illustrative of the spirit of the invention. Those skilled in the art to which the present invention belongs can make various modifications or supplements to the described specific embodiments or adopt similar methods to replace them, but they will not deviate from the spirit of the present invention or go beyond the definition of the appended claims range.

Claims (8)

1. A dynamic certificate agent method based on openresty, characterized in that, it is realized through the following steps: S1. Obtain the sni information sent by the client to the server through the clientHello information in the TLS/SSL handshake process; S2. Find the certificate and key of the corresponding server according to the acquired sni information; S3, configure the certificate and key into the web server; S4. The newly configured certificate is returned when the TLS/SSL handshake is performed with the client. 2. A kind of dynamic certificate agent method based on openresty according to claim 1, is characterized in that, TLS/SSL handshake process is as follows: (1) The client sends a ClientHello message to the server; (2) For the ClientHello message sent by the client, the server will return a ServerHello message; (3) The server sends a Certificate message, and the client verifies the certificate sent by the server; (4) The server sends a ServerKeyExchange message; (5) The server sends a ServerHelloDone message; (6) The client sends a ClientKeyExchange message; (7) The client and the server exchange messages, and use the key negotiated in step (6) to encrypt. 3. A dynamic certificate proxy method based on openresty according to claim 2, characterized in that, in step (1), the client needs to negotiate with the server, specifically which method to use for communication. 4. A kind of openresty-based dynamic certificate agency method according to claim 2, characterized in that, in step (2), the ServerHello message returned by the server will inform the client of the communication method adopted. 5. a kind of dynamic certificate proxy method based on openresty according to claim 2, is characterized in that, in step (3), server can select whether to send CertificateRequest message simultaneously; CertificateRequest message is used for server to request certificate to client, This is for client authentication, when client authentication is not used, the CertificateRequest message will not be sent. 6. a kind of dynamic certificate agency method based on openresty according to claim 2, is characterized in that, when server sends CertificateRequest message in step (3), client can send the certificate of oneself together with Certificate message to server; When the server does not send a CertificateRequest message, the client will not send a Certificate message. 7. A kind of dynamic certificate agent method based on openresty according to claim 2, it is characterized in that, in step (4), when Certificate message is not enough to meet demand, server can send some necessary certificates to client by ServerKeyExchange message Information, the specific content of the information sent will vary according to the cipher suite used. When the information is not needed, the ServerKeyExchange message will not be sent. 8. A dynamic certificate agent method based on openresty according to claim 2, characterized in that, in step (5), the message ServerHelloDone represents the end of a series of messages starting from the ServerHello message.

Images