CN109818916B - SSL/TLS proxy and negotiation method, device and computer readable storage medium thereof - Google Patents
SSL/TLS proxy and negotiation method, device and computer readable storage medium thereof Download PDFInfo
- Publication number
- CN109818916B CN109818916B CN201711176727.5A CN201711176727A CN109818916B CN 109818916 B CN109818916 B CN 109818916B CN 201711176727 A CN201711176727 A CN 201711176727A CN 109818916 B CN109818916 B CN 109818916B
- Authority
- CN
- China
- Prior art keywords
- ssl
- tls
- algorithm
- proxy
- suite
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Abstract
An SSL/TLS agent and a negotiation method, equipment and a computer readable storage medium thereof, wherein the SSL/TLS agent negotiation method comprises the following steps: the SSL/TLS proxy acquires an advantageous algorithm suite, and when the SSL/TLS proxy performs algorithm suite negotiation with the SSL/TLS server as a client role, the advantageous algorithm suite is provided for the SSL/TLS server. According to the scheme provided by the application, the SSL/TLS proxy provides the algorithm suite which is beneficial to the SSL/TLS proxy as the client role to the SSL/TLS server, so that the consumption of the SSL/TLS proxy as the client role is reduced, and the processing performance of the SSL/TLS proxy is improved.
Description
Technical Field
The embodiment of the invention relates to the field of mobile network communication, in particular to but not limited to an SSL/(Secure Socket Layer)/TLS (Transport Layer Security) agent, a negotiation method, equipment and a computer readable storage medium.
Background
In recent years, with the increasing awareness of security and privacy in the internet (especially mobile internet) industry, HTTPS (HTTP over SSL/TLS, hypertext transfer protocol over secure socket layer/transport layer security) is becoming popular, the SSL/TLS traffic proportion is increasing, and the demand scenario for a telecom operator to decrypt SSL/TLS encrypted traffic of a user is also increasing. In a telecommunication Mobile Network, regardless of a P-GW (Packet Data Network Gateway) Network element, an MEC (Mobile Edge Computing) server, an independent SSL/TLS proxy Network element, or other relevant firewall, router, etc., SSL/TLS proxy is increasingly used for intercepting and decrypting.
At 5G (5)thGeneration, fifth Generation) mobile network MEC function is taken as an example, file and video caching is one of important basic applications of MEC, but in recent years, many websites change file and video resources from HTTP (Hypertext Transfer Protocol) to HTTPS (Hypertext Transfer Protocol), which causes the MEC server to be unable to provide caching service for HTTPS files and videos like HTTP. The SSL/TLS agent can intercept and decrypt SSL/TLS traffic under the condition of permission, thereby helping to realize the caching function of the MEC on the HTTPS-based files and videos.
Taking a Parent Control (Parent Control) function in a mobile network as an example, a gateway or a related network element, a server and other intermediate devices can identify, analyze, extract and classify URLs in HTTP traffic, and block and limit URLs (Uniform Resource locators) that meet a category that is not suitable for children to access. However, for HTTPS traffic, because HTTPS is encrypted in a transport layer based on SSL/TLS, relevant intermediate devices cannot decrypt and cannot acquire URLs in the traffic, only information such as a server IP address, a DNS (Domain Name System) or SNI (Service Name Indication) of an SSL/TLS ClientHello message can be acquired, and for social and blog websites and the like, accurate classification can be performed according to paths in the URLs. Thus, HTTPS traffic cannot fully implement parental control functions. The SSL/TLS agent can intercept and decrypt SSL/TLS traffic under the condition of permission, thereby helping to completely realize the parental control function of HTTPS traffic.
Taking the redirection function in the mobile network as an example, the gateway or the related network elements, the server and other midway devices can redirect the HTTP traffic to realize the functions of arrearage prompt, login authentication, advertisement insertion and the like. But for HTTPS traffic, because HTTPS is encrypted at the transport layer based on SSL/TLS, the relevant intermediate device cannot decrypt and thus cannot implement redirection. The SSL/TLS proxy, if allowed, can intercept and decrypt SSL/TLS traffic, thereby facilitating HTTPS redirection functionality.
The SSL/TLS proxy decrypts the SSL/TLS flow of the user on the internet based on a man-in-the-middle interception mode, and the SSL/TLS proxy plays a role of an SSL/TLS server and a role of an SSL/TLS client in each TCP connection of the SSL/TLS. The processing performance of the SSL/TLS proxy is not only subject to the associated consumption in the role of SSL/TLS server, but also subject to the associated consumption in the role of SSL/TLS client. SSL/TLS proxying typically requires proxying a large number of SSL/TLS clients, and therefore, there is a need to improve the processing performance of SSL/TLS proxying.
Disclosure of Invention
At least one embodiment of the invention provides an SSL/TLS proxy, a negotiation method, equipment and a computer readable storage medium thereof, which improve the processing performance of the SSL/TLS proxy.
In order to achieve the object of the present invention, at least one embodiment of the present invention provides an SSL/TLS proxy negotiation method, including:
the SSL/TLS agent obtains an advantageous algorithm suite, wherein the advantageous algorithm suite is one or more algorithm suites which are advantageous to the SSL/TLS agent as a client role;
and when the SSL/TLS proxy is used as a client role to perform algorithm suite negotiation with the SSL/TLS server, the advantageous algorithm suite is provided for the SSL/TLS server.
An embodiment of the present invention provides an SSL/TLS proxy, including:
an algorithm suite obtaining module, configured to obtain an advantageous algorithm suite, where the advantageous algorithm suite is one or more algorithm suites that are advantageous for the SSL/TLS proxy to serve as a client role;
and the client module is used for providing the beneficial algorithm suite for the SSL/TLS server when the algorithm suite is negotiated with the SSL/TLS server.
An embodiment of the present invention provides an SSL/TLS proxy device, which includes a memory and a processor, where the memory stores a program, and the program, when being read and executed by the processor, implements the SSL/TLS proxy negotiation method.
An embodiment of the present invention provides a computer readable storage medium storing one or more programs, the one or more programs being executable by one or more processors to implement the SSL/TLS proxy negotiation method described above.
Compared with the prior art, in one embodiment of the invention, when the SSL/TLS proxy is used as a client role to perform algorithm suite negotiation with the SSL/TLS server, the algorithm suite which is beneficial to the SSL/TLS proxy as the client role is provided for the SSL/TLS server. In the embodiment, only the algorithm suite which is beneficial to the SSL/TLS client is sent to the SSL/TLS server, so that the SSL/TLS server can only passively accept the algorithm suite selected by the SSL/TLS proxy, the selection right of the algorithm suite is equivalent to the algorithm suite which is pre-transferred from the SSL/TLS server side to the SSL/TLS proxy side (as the role of the SSL/TLS client), the subsequent process can only use the algorithm suite which is beneficial to the SSL/TLS proxy as the client role and is specified by the SSL/TLS proxy, and when the beneficial algorithm suite is used, the SSL/TLS proxy processing consumption is lower, and the performance of the SSL/TLS proxy is improved. In another embodiment, the advantageous suite of algorithms is one supported by the SSL/TLS server, improving negotiation success rates.
Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.
Drawings
The accompanying drawings are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the example serve to explain the principles of the invention and not to limit the invention.
Fig. 1 is a diagram illustrating negotiation of an algorithm suite in a negotiation phase between an SSL/TLS client and a server in the related art.
FIG. 2 is a diagram illustrating negotiation of an algorithm suite in a negotiation phase among an SSL/TLS client, an SSL/TLS proxy, and an SSL/TLS server in the related art.
FIG. 3 is a flowchart of a SSL/TLS proxy negotiation method according to an embodiment of the present invention;
FIG. 4 is a flowchart of a SSL/TLS proxy negotiation method according to another embodiment of the present invention;
fig. 5 is a schematic diagram of negotiation of an algorithm suite in a negotiation phase among the SSL/TLS client, the SSL/TLS proxy, and the SSL/TLS server according to an embodiment of the present invention.
Fig. 6 is a schematic diagram of a sequence of successful probing interactions between the algorithm probe and the SSL/TLS server according to an embodiment of the present invention.
Fig. 7 is a schematic diagram of a detection failure interaction sequence of the algorithm detector and the SSL/TLS server according to another embodiment of the present invention.
Fig. 8 is an interaction sequence diagram of the algorithm probe and the SSL/TLS server, provided by an embodiment of the present invention, for respectively probing success or failure for a plurality of different algorithms.
Fig. 9 is a schematic diagram of a possible interaction sequence among the SSL/TLS client, the SSL/TLS proxy, and the SSL/TLS server according to an embodiment of the present invention.
FIG. 10 is a diagram of an SSL/TLS proxy architecture provided by one embodiment of the present invention;
fig. 11 is a diagram of an SSL/TLS proxy architecture according to another embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be noted that the embodiments and features of the embodiments in the present application may be arbitrarily combined with each other without conflict.
The steps illustrated in the flow charts of the figures may be performed in a computer system such as a set of computer-executable instructions. Also, while a logical order is shown in the flow diagrams, in some cases, the steps shown or described may be performed in an order different than here.
The processing performance of SSL/TLS based on different sets of SSL/TLS algorithms varies greatly. As shown in FIG. 1, according to SSL/TLS protocol specification, the SSL/TLS client sends the algorithm suite list supported by itself to the SSL/TLS server through a ClientHello message. After receiving the algorithm suite list sent by the SSL/TLS client, the SSL/TLS server selects one algorithm suite supported by the server, and sends the algorithm suite back to the SSL/TLS client through a ServerHello message. After the SSL/TLS client receives the algorithm suite, both sides use the algorithm suite to perform subsequent processing such as SSL/TLS negotiation flow, encryption and decryption.
According to the SSL/TLS protocol, the selection decision of the algorithm suite is assigned to the SSL/TLS server, and the SSL/TLS server usually selects the algorithm suite which is beneficial to the SSL/TLS server under the condition that other conditions are the same, so that the processing load of the SSL/TLS server is reduced, and the processing performance of the SSL/TLS server is improved.
However, such a suite of algorithms that is advantageous for SSL/TLS servers is generally disadvantageous for SSL/TLS clients. For example, two algorithm suites: algorithm suite a and algorithm suite B. Comparing the signature algorithm a in the algorithm suite A with the signature algorithm B in the algorithm suite B. The signature algorithm a has high signature speed but low signature verification speed; the signature algorithm b has a slow signature speed, but has a fast signature verification speed. The SSL/TLS server needs to perform signature processing frequently, so an algorithm suite a with high signature speed is selected; therefore, the SSL/TLS client has to passively accept the algorithm suite a with a slow signature verification speed, and the SSL/TLS client needs to perform signature verification frequently, so that the trending behavior of the SSL/TLS server is disadvantageous to the SSL/TLS client, and can negatively affect the processing performance of the SSL/TLS proxy in the role of the SSL/TLS client.
As shown in fig. 2, when the SSL/TLS proxy functions as an SSL/TLS client, a plurality of algorithm suites (algorithm suite 1, algorithm suite 2, and algorithm suite 3) supported by the SSL/TLS proxy are provided to the SSL/TLS server. The SSL/TLS server selects the most favorable algorithm suite 3 to return to the SSL/TLS proxy, and the SSL/TLS proxy can only passively accept the algorithm suite 3, so that the two parties negotiate to select the algorithm suite 3. However, the algorithm suite 3, which is advantageous for SSL/TLS servers, is generally disadvantageous for SSL/TLS proxies (acting as SSL/TLS clients). Therefore, the SSL/TLS proxy will passively accept a suite of algorithms that is detrimental to itself across a large number of connections, thereby negatively impacting the performance of the SSL/TLS proxy itself to a large extent.
According to the SSL/TLS protocol, because the SSL/TLS client does not know which algorithm suites are supported by the SSL/TLS server, the SSL/TLS client can only send all the algorithm suites supported by the SSL/TLS client to the SSL/TLS server, and the SSL/TLS server can select one algorithm suite from the algorithm suites, so that the selection decision of the algorithm suites is equivalent to that the SSL/TLS server has the selection decision of the algorithm suites.
The SSL/TLS proxy selects one or more algorithm suites that are advantageous to the SSL/TLS proxy as a client role, and only sends these one or more algorithm suites to the SSL/TLS server via ClientHello messages. And after receiving the one or more algorithm suites, the SSL/TLS server selects one algorithm suite and sends the selected algorithm suite to the SSL/TLS proxy. According to the scheme provided by the application, the decision right selected by the algorithm suite is pre-transferred to the SSL/TLS proxy side from the SSL/TLS server side, and the SSL/TLS proxy can select the algorithm suite which is beneficial to the SSL/TLS proxy, so that the processing performance of the SSL/TLS proxy is improved.
An embodiment of the present invention provides an SSL/TLS proxy negotiation method, as shown in fig. 3, including:
Wherein, in step 302, the SSL/TLS agent can provide the advantageous suite of algorithms to the SSL/TLS server via a ClientHello message.
In the negotiation method provided by this embodiment, when the SSL/TLS proxy negotiates with the SSL/TLS server as the role of the SSL/TLS client, only the algorithm suite that is beneficial to the SSL/TLS client is sent to the SSL/TLS server, so that the SSL/TLS server can only passively accept the algorithm suite that is selected by the SSL/TLS proxy, and the selection right of the algorithm suite is pre-transferred from the SSL/TLS server side to the SSL/TLS proxy side (as the role of the SSL/TLS client), and the algorithm suite that is beneficial to the SSL/TLS proxy as the role of the client is used in the subsequent process, thereby improving the performance of the SSL/TLS proxy.
In one embodiment, in step 301, the advantageous suite of algorithms is a suite of algorithms supported by the SSL/TLS server and a suite of algorithms supported by the SSL/TLS proxy in a client role.
In this embodiment, the algorithm suite sent by the SSL/TLS agent to the SSL/TLS server is not only beneficial to the SSL/TLS server as a client role, but also supported by the SSL/TLS server, and this implementation can avoid the problem of negotiation failure caused by the algorithm suite sent by the SSL/TLS agent to the SSL/TLS server not being supported by the SSL/TLS server, thereby increasing the success rate of negotiation.
In one embodiment, the advantageous algorithm suite may be one or more. For example, the algorithm suite that is most advantageous to the SSL/TLS proxy as a client role can be sent to the SSL/TLS server. Of course, multiple sets of algorithms may be sent for SSL/TLS server selection.
In another embodiment, the SSL/TLS proxy can obtain a suite of advantageous algorithms from outside, or can perform probing itself, and the SSL/TLS proxy obtains the suite of advantageous algorithms includes:
the SSL/TLS agent obtains the advantageous algorithm suite from an external algorithm detector;
or after the SSL/TLS agent fails to acquire the favorable algorithm suite from an external algorithm detector, detecting the algorithm suites supported by the SSL/TLS agent and the SSL/TLS server when the SSL/TLS agent serves as a client role, and selecting the algorithm suite which is favorable for the SSL/TLS agent to serve as the favorable algorithm suite from the algorithm suites supported by the SSL/TLS agent and the SSL/TLS server when the SSL/TLS agent serves as the client role;
or, the SSL/TLS proxy detects an algorithm suite supported by both the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy is in the client role, and selects an algorithm suite that is advantageous for the SSL/TLS proxy to serve as the client role from the algorithm suites supported by both the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy is in the client role as the advantageous algorithm suite. Namely, the SSL/TLS agent adopts a mode of combining the two, and detects by the SSL/TLS agent if a favorable algorithm suite cannot be obtained from an external algorithm detector. When the SSL/TLS proxy detects the data, the detection can be carried out through an algorithm detector built in the SSL/TLS proxy.
The algorithm detector can be built-in or external and is mainly used for detecting an algorithm suite supported by the SSL/TLS server. One detection mode of the algorithm detector is as follows:
probing each algorithm suite in a set of algorithm suites supported by the SSL/TLS proxy in a client role as follows: sending the algorithm suite to the SSL/TLS server, receiving the response of the SSL/TLS server, and judging whether the SSL/TLS server supports the currently sent algorithm suite according to the response of the SSL/TLS server;
and after detecting all algorithm suites in the algorithm suite set supported by the SSL/TLS proxy serving as the client role, determining the SSL/TLS proxy serving as the client role and the algorithm suites supported by the SSL/TLS server.
And after the algorithm detector determines that the SSL/TLS proxy is used as a client role and the algorithm suites supported by the SSL/TLS server, selecting an algorithm suite generation algorithm suite set which is favorable for the SSL/TLS proxy to be used as the client role from the algorithm suites supported by the SSL/TLS proxy and the SSL/TLS server. Whether the SSL/TLS proxy is favorable as the client role is determined by the performance influence of the algorithm suite on the SSL/TLS proxy as the client role, if the algorithm suite is adopted, the performance influence on the SSL/TLS proxy as the client role is small, the SSL/TLS proxy is favorable as the client role, and otherwise, the SSL/TLS proxy is unfavorable as the client role.
As shown in table 1 below, taking the RSA signature algorithm and the ECDSA signature algorithm as examples, the 2048-bit RSA algorithm is comparable to the 256-bit ECDSA algorithm in encryption strength. The SSL/TLS server with RSA algorithm has slow signature speed (only 1118 times signature per second), but the SSL/TLS client has fast signature verification speed (38202 times per second), so the RSA algorithm is beneficial to the SSL/TLS client; the ECDSA algorithm SSL/TLS server has fast signature speed (25363 times per second), but SSL/TLS client has slow signature verification speed (10465 times per second), so the ECDSA algorithm is unfavorable for the SSL/TLS client. Assuming that the algorithm probe collects that a target SSL/TLS server supports the two signature algorithms, for two algorithm suites respectively containing the two signature algorithms and having the same rest, the algorithm probe records that the target SSL/TLS server selects the algorithm suite containing the RSA signature algorithm to be beneficial to the SSL/TLS proxy, and records the algorithm suite as the beneficial algorithm suite.
TABLE 1 Algorithm suite comparison
It should be noted that, the advantages of the present application are relative, even if the two algorithm suites have small impact on the performance of the SSL/TLS server and large impact on the SSL/TLS proxy acting as a client, but the two algorithm suites have different impact on the performance of the SSL/TLS proxy acting as a client, where one of the two algorithm suites has a larger impact than the other, the algorithm suite with small impact may still be referred to as the algorithm suite with advantages for the SSL/TLS proxy. For example, algorithm a and algorithm B are both beneficial to the SSL/TLS server and are disadvantageous to the SSL/TLS proxy acting as the client, but algorithm a has a greater impact on the performance of the SSL/TLS proxy acting as the client than algorithm B, and at this time, algorithm B may be considered as an algorithm suite beneficial to the SSL/TLS proxy acting as the client.
In an embodiment, the method further includes that the SSL/TLS proxy selects an algorithm suite that is beneficial to the SSL/TLS proxy as a client role from algorithm suites supported by both the SSL/TLS proxy and the SSL/TLS server to form an algorithm suite set, and stores a corresponding relationship between the SSL/TLS server and the algorithm suite set. When the corresponding relation between the algorithm suite set and the SSL/TLS server is stored, the domain name of the SSL/TLS server can be used as an index, and the algorithm suite set can be stored. For example, it is possible to detect the algorithm suites supported by a plurality of SSL/TLS servers respectively, determine the algorithm suite sets that are beneficial to the SSL/TLS proxy as the client role, and then store the algorithm suite sets respectively by using the domain name of the SSL/TLS server as the index. When the SSL/TLS proxy is used as a client role to negotiate an algorithm suite with the SSL/TLS server, a corresponding algorithm suite set is queried through the domain name of the SSL/TLS server, and an advantageous algorithm suite is selected from the algorithm suite set and sent to the SSL/TLS server. Of course, in other embodiments, the domain name of the SSL/TLS server may be replaced with other information that indicates the identity of the SSL/TLS server.
For each SSL/TLS server, the algorithm detector uses the algorithm suite supported by the SSL/TLS proxy as the SSL/TLS client role one by one, and detects whether each SSL/TLS server supports the algorithm suite according to the domain name, so that the algorithm suite information supported by each SSL/TLS server is collected. And the algorithm detector selects an algorithm suite which is favorable for the SSL/TLS proxy to serve as the client role for each SSL/TLS server according to different performance influences caused by different algorithm suites on the SSL/TLS proxy to serve as the SSL/TLS client role, and stores the algorithm suite which is favorable for the SSL/TLS proxy for each SSL/TLS server by taking the domain name as an index.
Specifically, the algorithm detector may be integrated inside the SSL/TLS proxy, or externally disposed outside the SSL/TLS proxy, or a combination of internal and external methods may be adopted, that is, an algorithm detector is built inside the SSL/TLS proxy, and in addition, an algorithm detector is disposed outside the SSL/TLS proxy.
In an embodiment, a built-in algorithm detector can be used for detecting and collecting SSL/TLS website servers currently visited by a user, and the real-time performance and the accuracy are better.
In an embodiment, an external algorithm detector may be used to periodically detect and collect the supported algorithm suite of a large number of SSL/TLS servers, so that when the algorithm suite supported by the SSL/TLS servers changes, the SSL/TLS servers can be tracked in time. SSL/TLS servers that need to be probed can be pre-specified.
Since the external algorithm detector has no influence on the performance of the SSL/TLS agent, in an embodiment, for a first type of website, such as a known hit website, a TOP N website in each country, a website with a large visit amount, a designated website, and the like, the external algorithm detector may be used for detecting; and for a new SSL/TLS server discovered during the operation of the SSL/TLS proxy, especially for a new domain name with larger HTTPS concurrent flow, a built-in algorithm detector can be used for detecting.
When detecting, firstly, determining which algorithm suites (hereinafter referred to as "algorithm suite set S" or "S", and the number of the algorithm suites in S is recorded as N, each algorithm suite is recorded as "C1", "C2", "C3", "CN") are supported when the SSL/TLS proxy is in the role of the SSL/TLS client, and then performing probe collection on the algorithm suites. For an algorithm suite which is not supported by the SSL/TLS proxy in the role of the SSL/TLS client, detection collection can be omitted. For each domain name detected and collected, each of the N algorithm suites of the algorithm suite set S is separately detected and collected, that is, each domain name is detected and collected at least N times.
Specifically, for a certain detection acquisition of a certain domain name, a certain algorithm suite in the S is selected and used as the only meaningful algorithm suite for the SSL/TLS connection, the algorithm suite is sent to the SSL/TLS server represented by the domain name through the ClientHello, and whether the SSL/TLS server supports the algorithm suite is determined according to the response of the SSL/TLS server. After receiving the ClientHello message, the SSL/TLS server replies to ServerHello to indicate that the algorithm suite is supported, or replies to SSL Alert to indicate that the algorithm suite is not supported.
In one embodiment, the algorithm finder may record which algorithm suites are supported by the SSL/TLS server represented by each domain name. For example, domain name N1 supports set of algorithm suites S1 (e.g., algorithm suites such as C1, C2, C4, etc.), domain name N2 supports set of algorithm suites S2 (e.g., algorithm suites such as C1, C3, C4, C5, etc.), and so on. It should be noted that it is also possible to record only SSL/TLS server support and a suite of algorithms that is advantageous for SSL/TLS proxy to act as a client.
In one embodiment, to obtain the latest supported algorithm suite information for each SSL/TLS server, the algorithm probe may periodically traverse each SSL/TLS server, thereby continuously updating the algorithm suite supported by the SSL/TLS server.
In an embodiment, when the SSL/TLS proxy is acting as an SSL/TLS client, for each algorithm suite of the set of algorithm suites S (C1, C2, …, CN), the algorithm probe may specify a priority for each algorithm suite. Typically, each algorithm suite of S may be assigned a priority by a method such as a performance test or a theoretical evaluation of the algorithm suite performed in advance. Specifically, the SSL/TLS proxy further stores a priority of each algorithm suite in the set of algorithm suites, where the priority indicates a performance impact of the algorithm suite on the SSL/TLS proxy as a client role; for example, the higher the priority of the algorithm suite, the less the performance impact of the SSL/TLS proxy using the algorithm suite when the SSL/TLS proxy is represented as an SSL/TLS client, i.e., the more beneficial the algorithm suite is to the SSL/TLS proxy itself.
The SSL/TLS proxy providing the advantageous suite of algorithms to the SSL/TLS server comprises:
and the SSL/TLS proxy selects one or more algorithm suites from the algorithm suite set corresponding to the SSL/TLS server according to the priority of the algorithm suites and provides the algorithm suites to the SSL/TLS server.
For example, the algorithm suite with the smallest (most advantageous) impact on the client role performance of the SSL/TLS proxy may be selected according to the priority, the algorithm suite with the smallest and the next smallest (most advantageous and the next most advantageous) impact on the client role performance of the SSL/TLS proxy may be selected according to the priority, and the like, or one algorithm suite may be selected in turn from a plurality of stored algorithm suites for negotiation. Of course, in other embodiments, the set of algorithm suites may include only one algorithm suite that is most beneficial to the SSL/TLS proxy as the client role, and in this case, the algorithm suite may be selected directly from the set of algorithm suites.
In an embodiment, the algorithm detector uses domain names as indexes to construct an algorithm suite feature library of the SSL/TLS website server, the data portion corresponding to each domain name may only store one algorithm suite with the highest priority, and the data portion corresponding to each domain name may also store a plurality of algorithm suites and their respective priorities.
In one embodiment, the algorithm detector may construct the feature library in different forms according to the number of domain names of the algorithm suite. Typically, if the number of domain names of the algorithm suite is small, the feature library can be constructed in the form of an array or a list; if the number of domain names of the algorithm suite is large, the feature library can be constructed in the form of a multi-mode tree (such as an AC algorithm, a WM algorithm, a regular expression algorithm or other similar algorithms) and the like. Of course, this is merely an example, and other ways of constructing a feature library may be used as desired.
In an embodiment, the method further includes, when the SSL/TLS proxy performs algorithm suite negotiation with the SSL/TLS server as a client role, if the SSL/TLS server is located in a preset domain name filtering table, the SSL/TLS proxy provides the SSL/TLS proxy with all or a subset of the algorithm suites supported by the SSL/TLS proxy as the client role. Typically, for the selection of the subset of S here, one possible way is to take S ∞ K, i.e. the intersection of S and K, from the set K of algorithm suites carried in the ClientHello message of the SSL/TLS client (i.e. the set of algorithm suites supported by the SSL/TLS client, denoted "K"); when S # K is empty, the S itself is taken.
In an embodiment, when the SSL/TLS proxy acts as an SSL/TLS client, if the result cannot be queried from the algorithm probe, the SSL/TLS proxy causes the ClientHello message to carry the normal set of algorithms S, or some subset of S. Typically, for the selection of the subset of S here, one possible way is to take S ∞ K, i.e. the intersection of S and K, from the set K of algorithm suites carried in the ClientHello message of the SSL/TLS client (i.e. the set of algorithm suites supported by the SSL/TLS client, denoted "K"); when S # K is empty, the S itself is taken.
In an embodiment, after the SSL/TLS proxy provides the advantageous algorithm suite to the SSL/TLS server, if receiving information that the SSL/TLS server replies does not support the algorithm suite, adding a domain name filter table to the SSL/TLS server, indicating that the SSL/TLS proxy provides, to the SSL/TLS server, all or a subset of the algorithm suites supported by the SSL/TLS proxy as a client role when the subsequent SSL/TLS proxy performs algorithm suite negotiation with the SSL/TLS server as the client role. The reason for this is that it is possible that the algorithm suite supported by the SSL/TLS server has changed and the algorithm suite preferred by the SSL/TLS proxy is no longer supported by the SSL/TLS server.
The domain name filtering table is introduced mainly for distinguishing the SSL/TLS server, when negotiating with the SSL/TLS server not in the domain name filtering table, the SSL/TLS proxy sends a suite of algorithms that is advantageous to the SSL/TLS proxy to the SSL/TLS server, when negotiating with the SSL/TLS server in the domain name filtering table, the SSL/TLS proxy does not send a suite of algorithms that are advantageous to the SSL/TLS proxy as a client role to the SSL/TLS server, and possibly sends a suite of algorithms that are disadvantageous to the SSL/TLS proxy to the SSL/TLS server, for example, sends the SSL/TLS proxy as a complete suite of algorithms supported by the client role. The reason for this is that some SSL/TLS web servers themselves may have poor processing performance, so the SSL/TLS proxy may allow the SSL/TLS web server to choose a suite of algorithms that is advantageous to its own performance.
The domain name filtering tables can be two, one static domain name filtering table and one dynamic domain name filtering table, the static domain name filtering table can be kept unchanged, and the SSL/TLS server in the dynamic domain name filtering table can be changed, for example, after the SSL/TLS proxy sends an algorithm suite which is beneficial to the SSL/TLS proxy, if information which is replied by the SSL/TLS server and does not support the algorithm suite is received, the SSL/TLS server can be added into the dynamic domain name filtering table. The SSL/TLS server can subsequently be moved out of the dynamic domain name filtering table if the suite of algorithms supported by the SSL/TLS server that is advantageous for the SSL/TLS proxy to act as a client is re-detected. Of course, only one domain name filter table may be set, or only the pre-table is set, when the SSL/TLS proxy negotiates with the SSL/TLS server in the pre-table, the algorithm suite that is beneficial to the SSL/TLS proxy as the client role is sent to the SSL/TLS server, and when the SSL/TLS proxy negotiates with the SSL/TLS server that is not in the pre-table, the algorithm suite is sent to the SSL/TLS server in a manner in the related art, that is, all or a subset of the algorithm suites supported by the SSL/TLS proxy as the client role is sent to the SSL/TLS server.
In one embodiment, when the SSL/TLS server supports the SSL/TLS proxy-sent algorithm suite, a ServerHello message is returned and carries the selected algorithm suite, typically an SSL Alert message indicating a negotiation failure if the SSL/TLS server does not support the SSL/TLS proxy-sent algorithm suite. For failures that are not supported by the algorithm suite, the SSL Alert level is typically a face (Fatal), and the SSL Alert description is typically a 40/Handshake Failure (Handshake Failure). The SSL/TLS agent identifies the SSL Alert message and the alarm description thereof, and records the SNI of the SSL/TLS server into a dynamic domain name filter table for 40/Handshake Failure or other relevant description.
The application is further illustrated by the following specific examples.
Taking an external algorithm detector as an example, in this embodiment, only one most favorable algorithm suite that is used as a client role for the SSL/TLS proxy is sent to the SSL/TLS server, as shown in fig. 4, an embodiment of the present invention provides an SSL/TLS proxy negotiation method, including:
Specifically, when the SSL/TLS proxy acts as a server, the SNI is acquired from a ClientHello message sent by the SSL/TLS client. The SNI is the domain name. And when the SSL/TLS proxy is used as the SSL/TLS client role, the SNI is used for inquiring the algorithm detector to obtain an algorithm suite corresponding to the SNI.
In step 403, after receiving the message of responding to the optimal algorithm suite, the SSL/TLS proxy sends the message of responding to the optimal algorithm suite to the target SSL/TLS server as the only algorithm suite in the ClientHello message if obtaining the most favorable algorithm suite of the target SSL/TLS server.
The SSL/TLS server accepts the most favorable algorithm suite and sends a ServerHello message to the SSL/TLS proxy to select the most favorable algorithm suite, step 404.
The SSL/TLS server and SSL/TLS proxy use the selected suite of algorithms for subsequent processing.
As shown in fig. 5, when the SSL/TLS proxy serves as an SSL/TLS client, the algorithm suite supported by the SSL/TLS server is obtained as algorithm suite 2 and algorithm suite 3 in advance through probe acquisition, and the algorithm suite 2 is most beneficial to the SSL/TLS proxy (i.e., the SSL/TLS proxy serves as a client) itself compared with the algorithm suite 3, so that the SSL/TLS proxy only carries the algorithm suite 2 in the ClientHello message, and the SSL/TLS server only receives one algorithm suite 2 and can only receive it, so that the SSL/TLS proxy (i.e., the SSL/TLS client) determines and selects the algorithm suite 2 that is most beneficial to itself, thereby achieving the purpose of improving its performance.
Fig. 6 is a flowchart of a detection algorithm suite according to an embodiment of the present invention. As shown in fig. 6, the algorithm detector detects whether a target SSL/TLS server supports algorithm suite X on the premise that the SSL/TLS protocol specification is met. The algorithm detector only fills an algorithm suite X in an algorithm suite field in a conventional ClientHello message, and sends the ClientHello message to a target SSL/TLS server; and when the ServerHello message returned by the SSL/TLS server is received and the field of the algorithm suite in the ServerHello message is the algorithm suite X, the algorithm detector acquires the information that the target SSL/TLS server supports the algorithm suite X.
Fig. 7 is a flowchart of a detection algorithm suite according to another embodiment of the present invention. As shown in fig. 7, the algorithm detector detects whether a target SSL/TLS server supports algorithm suite Y on the premise of complying with the SSL/TLS protocol specification, and fills only algorithm suite Y in the field of the algorithm suite in the conventional ClientHello message, and sends the ClientHello message to the target SSL/TLS server; and when receiving the SSL Alert message returned by the SSL/TLS server, the algorithm detector acquires the information that the target SSL/TLS server does not support the algorithm suite Y.
Fig. 8 is a flowchart of a detection algorithm suite according to another embodiment of the present invention. As shown in fig. 8, the algorithm detector detects whether a target SSL/TLS server supports six algorithm suites (A, B, C, D, E, F) on the premise of complying with the SSL/TLS protocol specification, the algorithm detector is connected with the target SSL/TLS server six times, and only one of the algorithm suites (a, B, C, D, E, or F) is filled in the algorithm suite field in the conventional ClientHello message sent each time. Assume for algorithm suite A, C, D, E that the target SSL/TLS server will return a ServerHello message to accept; for algorithm suite B, F, the target SSL/TLS server will return an SSL Alert message to reject. Then the algorithm probe obtains this information that the target SSL/TLS server supports the algorithm suite A, C, D, E and does not support the algorithm suite B, F.
For the algorithm suite supported by a certain target SSL/TLS server, the algorithm detector selects the optimal algorithm suite when the SSL/TLS proxy is used as the client role according to the performance influence condition of each algorithm suite on the SSL/TLS proxy when the SSL/TLS proxy is used as the SSL/TLS client role, and records the information.
Taking the four algorithm suites (A, C, D, E) supported by a target SSL/TLS server in fig. 8 as an example, assuming that the algorithm probe analyzes that the target SSL/TLS server supports and the algorithm suite that is optimal for SSL/TLS proxy is algorithm suite C, the rest of the algorithm suites are all unfavorable for SSL/TLS proxy.
As shown in fig. 9, which is a schematic diagram of a typical interaction sequence of the SSL/TLS proxy in an embodiment of the present invention, when the SSL/TLS proxy serves as an SSL/TLS client, first, the SSL/TLS proxy requests an algorithm probe to acquire an optimal algorithm suite, and assuming that the algorithm probe already acquires the optimal algorithm suite of the target SSL/TLS server as an algorithm suite C, the algorithm probe returns information of the algorithm suite C to the SSL/TLS proxy. The SSL/TLS proxy only fills in the ClientHello message sent in the role of the SSL/TLS client as the only supported algorithm suite C and sends the algorithm suite C to the SSL/TLS server. The SSL/TLS server receives the algorithm suite C, because the algorithm suite C is supported by the SSL/TLS server, the algorithm suite C is returned in the ServerHello message, so that the algorithm suite C is selected by the two parties, and the algorithm suite C is most beneficial to the SSL/TLS agent as a client role, thereby achieving the purpose of improving the performance of the SSL/TLS agent.
In another embodiment of the present invention, if there is an internal algorithm detector, when the SSL/TLS proxy functions as an SSL/TLS client, before sending a ClientHello message, an attempt may be made to acquire an optimal algorithm suite of the target SSL/TLS server from the internal algorithm detector, and then an attempt may be made to acquire the optimal algorithm suite of the target SSL/TLS server from the external algorithm detector, so as to finally acquire the optimal algorithm suite of the target SSL/TLS server. Of course, the optimal algorithm suite can also be obtained from the external algorithm detector, and if the optimal algorithm suite fails, the optimal algorithm suite is obtained from the internal algorithm detector.
As shown in fig. 10, an embodiment of the present invention provides an SSL/TLS proxy, including: an algorithm suite acquisition module 1001 and a client module 1002, wherein:
the algorithm suite obtaining module 1001 is configured to obtain an advantageous algorithm suite, where the advantageous algorithm suite is one or more algorithm suites that are advantageous for the SSL/TLS proxy to serve as a client role;
the client module 1002 is configured to provide the advantageous algorithm suite to the SSL/TLS server when negotiating the algorithm suite with the SSL/TLS server.
In an embodiment, the advantageous suite of algorithms is a suite of algorithms supported by the SSL/TLS server and a suite of algorithms supported by the SSL/TLS proxy in a client role.
In one embodiment, the algorithm suite acquisition module 1001 acquires a suite of advantageous algorithms comprising:
obtaining the advantageous algorithm suite from an external algorithm detector;
alternatively, the first and second electrodes may be,
after failure of obtaining the favorable algorithm suite from an external algorithm detector, detecting the algorithm suites supported by the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy is in a client role, and selecting the algorithm suite which is favorable for the SSL/TLS proxy to serve as the favorable algorithm suite from the algorithm suites supported by the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy is in the client role;
alternatively, the first and second electrodes may be,
and detecting algorithm suites supported by the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy is in the client role, and selecting an algorithm suite which is favorable for the SSL/TLS proxy to be in the client role as the favorable algorithm suite from the algorithm suites supported by the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy is in the client role.
In an embodiment, the algorithm suite acquisition module 1001 detects that the SSL/TLS proxy and the SSL/TLS server support the algorithm suite as a client role, and includes:
probing each algorithm suite in a set of algorithm suites supported by the SSL/TLS proxy in a client role as follows: sending an algorithm suite to the SSL/TLS server, receiving the response of the SSL/TLS server, and judging whether the SSL/TLS server supports the currently sent algorithm suite according to the response of the SSL/TLS server;
and after detecting all algorithm suites in the algorithm suite set supported by the SSL/TLS proxy when the SSL/TLS proxy is in the client role, determining the algorithm suites supported by the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy is in the client role.
In an embodiment, the algorithm suite obtaining module 1001 is further configured to select an algorithm suite that is beneficial to the SSL/TLS proxy as the client role from among algorithm suites supported by both the SSL/TLS proxy and the SSL/TLS server to form an algorithm suite set, and store a corresponding relationship between the SSL/TLS server and the algorithm suite set.
In an embodiment, the algorithm suite acquisition module 1001 is further configured to store a priority of the algorithm suite, where the priority indicates a performance impact of the algorithm suite on the SSL/TLS proxy as a client role;
the client module 1002 providing the advantageous suite of algorithms to the SSL/TLS server includes: the client module 1002 selects one or more algorithm suites from the algorithm suite sets corresponding to the SSL/TLS servers according to the priority of the algorithm suites, and provides the selected algorithm suites to the SSL/TLS servers.
In an embodiment, after providing the advantageous algorithm suite to the SSL/TLS server, if receiving information that the SSL/TLS server replies that the algorithm suite is not supported, the client module 1002 is further configured to add a domain name filter table to the SSL/TLS server, indicating that the SSL/TLS proxy provides, as a whole algorithm suite supported by the client role or a subset thereof, to the SSL/TLS server when subsequently performing algorithm suite negotiation with the SSL/TLS server as the client role.
As shown in fig. 11, an embodiment of the present invention provides an SSL/TLS proxy 1100, which includes a memory 1110 and a processor 1120, where the memory 1110 stores a program, and when the program is read and executed by the processor 1120, the program implements the SSL/TLS proxy negotiation method according to any of the above embodiments.
An embodiment of the present invention provides a computer-readable storage medium storing one or more programs, the one or more programs being executable by one or more processors to implement the SSL/TLS proxy negotiation method according to any of the above embodiments.
The computer-readable storage medium includes: a U-disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic or optical disk, and other various media capable of storing program codes.
Although the embodiments of the present invention have been described above, the above description is only for the convenience of understanding the present invention, and is not intended to limit the present invention. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (10)
1. An SSL/TLS proxy negotiation method, comprising:
the SSL/TLS agent obtains an advantageous algorithm suite, wherein the advantageous algorithm suite is one or more algorithm suites which are advantageous to the SSL/TLS agent as a client role;
when the SSL/TLS agent is used as a client role to perform algorithm suite negotiation with an SSL/TLS server, the advantageous algorithm suite is provided for the SSL/TLS server;
after the SSL/TLS proxy provides the advantageous algorithm suite to the SSL/TLS server, if information which does not support the algorithm suite and is replied by the SSL/TLS server is received, the SSL/TLS server is added into a domain name filter table, and when the SSL/TLS proxy is used as a client role to conduct algorithm suite negotiation with the SSL/TLS server subsequently, the SSL/TLS proxy provides the SSL/TLS proxy as the whole algorithm suite or the subset thereof supported by the client role to the SSL/TLS server.
2. The SSL/TLS proxy negotiation method of claim 1, wherein the advantageous suite of algorithms is a suite of algorithms supported by the SSL/TLS server and a suite of algorithms supported by the SSL/TLS proxy in a client role.
3. The SSL/TLS proxy negotiation method of claim 1, wherein the SSL/TLS proxy acquisition expedient suite of algorithms comprises:
the SSL/TLS agent obtains the advantageous algorithm suite from an external algorithm detector;
alternatively, the first and second electrodes may be,
after the SSL/TLS proxy acquires the favorable algorithm suite from an external algorithm detector, detecting the algorithm suites supported by the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy is used as a client role, and selecting the algorithm suite which is favorable for the SSL/TLS proxy to be used as the favorable algorithm suite from the algorithm suites supported by the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy is used as the client role;
or, the SSL/TLS proxy detects an algorithm suite supported by both the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy is in the client role, and selects an algorithm suite that is advantageous for the SSL/TLS proxy to serve as the client role from the algorithm suites supported by both the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy is in the client role as the advantageous algorithm suite.
4. The SSL/TLS proxy negotiation method of claim 3, wherein the algorithm suite supported by the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy detects that the SSL/TLS proxy is in a client role comprises:
probing each algorithm suite in a set of algorithm suites supported by the SSL/TLS proxy in a client role as follows: sending the algorithm suite to the SSL/TLS server, receiving the response of the SSL/TLS server, and judging whether the SSL/TLS server supports the currently sent algorithm suite according to the response of the SSL/TLS server;
and after detecting all algorithm suites in the algorithm suite set supported by the SSL/TLS proxy serving as the client role, determining the SSL/TLS proxy serving as the client role and the algorithm suites supported by the SSL/TLS server.
5. The SSL/TLS proxy negotiation method of claim 3, wherein the method further comprises the SSL/TLS proxy selecting a set of algorithm suites that is favorable for the SSL/TLS proxy to act as a client from the sets of algorithms supported by the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy acts as a client, and storing the correspondence between the SSL/TLS server and the set of algorithm suites.
6. The SSL/TLS proxy negotiation method of claim 5, the method further comprising SSL/TLS proxy maintaining a priority for each suite of algorithms in the set of suites of algorithms, the priority indicating the performance impact of the suite of algorithms on the SSL/TLS proxy as a client role;
the SSL/TLS proxy providing the advantageous suite of algorithms to the SSL/TLS server comprises:
and the SSL/TLS proxy selects one or more algorithm suites from the algorithm suite set corresponding to the SSL/TLS server according to the priority of the algorithm suites and provides the algorithm suites to the SSL/TLS server.
7. An SSL/TLS proxy, comprising:
an algorithm suite obtaining module, configured to obtain an advantageous algorithm suite, where the advantageous algorithm suite is one or more algorithm suites that are advantageous for the SSL/TLS proxy to serve as a client role;
the client module is used for providing the beneficial algorithm suite to the SSL/TLS server when the algorithm suite is negotiated with the SSL/TLS server;
wherein the client module is further configured to: after the advantageous algorithm suite is provided for the SSL/TLS server, if the information that the algorithm suite is not supported and replied by the SSL/TLS server is received, the SSL/TLS server is added into a domain name filtering table, and when the SSL/TLS proxy is used as a client role to conduct algorithm suite negotiation with the SSL/TLS server subsequently, the SSL/TLS proxy provides the SSL/TLS server with all or a subset of the algorithm suites supported by the SSL/TLS proxy as the client role.
8. The SSL/TLS proxy of claim 7, wherein the algorithm suite acquisition module acquiring a favorable algorithm suite comprises:
obtaining the advantageous algorithm suite from an external algorithm detector;
alternatively, the first and second electrodes may be,
after failure of obtaining the favorable algorithm suite from an external algorithm detector, detecting the algorithm suites supported by the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy is in a client role, and selecting the algorithm suite which is favorable for the SSL/TLS proxy to serve as the favorable algorithm suite from the algorithm suites supported by the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy is in the client role;
alternatively, the first and second electrodes may be,
and detecting algorithm suites supported by the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy is in the client role, and selecting an algorithm suite which is favorable for the SSL/TLS proxy to be in the client role as the favorable algorithm suite from the algorithm suites supported by the SSL/TLS proxy and the SSL/TLS server when the SSL/TLS proxy is in the client role.
9. An SSL/TLS proxy device, comprising a memory and a processor, the memory storing a program which, when read and executed by the processor, implements the SSL/TLS proxy negotiation method as claimed in any one of claims 1 to 6.
10. A computer readable storage medium, storing one or more programs, the one or more programs being executable by one or more processors to implement the SSL/TLS proxy negotiation method as recited in any one of claims 1 through 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711176727.5A CN109818916B (en) | 2017-11-22 | 2017-11-22 | SSL/TLS proxy and negotiation method, device and computer readable storage medium thereof |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711176727.5A CN109818916B (en) | 2017-11-22 | 2017-11-22 | SSL/TLS proxy and negotiation method, device and computer readable storage medium thereof |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109818916A CN109818916A (en) | 2019-05-28 |
| CN109818916B true CN109818916B (en) | 2021-08-17 |
Family
ID=66599920
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711176727.5A Active CN109818916B (en) | 2017-11-22 | 2017-11-22 | SSL/TLS proxy and negotiation method, device and computer readable storage medium thereof |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109818916B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111314288B (en) * | 2019-12-23 | 2022-08-05 | 深信服科技股份有限公司 | Relay processing method, relay processing device, server, and storage medium |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101141244A (en) * | 2006-09-08 | 2008-03-12 | 飞塔信息科技（北京）有限公司 | Network encrypted data virus detection and elimination system, proxy server and method |
| US8225085B2 (en) * | 2007-06-05 | 2012-07-17 | Blue Coat Systems, Inc. | System and method for distributed SSL processing between co-operating nodes |
| CN103188074A (en) * | 2011-12-28 | 2013-07-03 | 上海格尔软件股份有限公司 | Proxy method for improving SSL algorithm intensity of browser |
| CN104735058A (en) * | 2015-03-04 | 2015-06-24 | 深信服网络科技（深圳）有限公司 | Encryption method and system based on security protocol SSL |
| CN105471896A (en) * | 2015-12-28 | 2016-04-06 | 深圳市深信服电子科技有限公司 | Agent method, device and system based on SSL (Secure Sockets Layer) |
| CN105577657A (en) * | 2015-12-18 | 2016-05-11 | 北京海泰方圆科技股份有限公司 | SSL/TLS algorithm suite expansion method |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170171170A1 (en) * | 2015-12-09 | 2017-06-15 | Xasp Security, Llc | Dynamic encryption systems |
-
2017
- 2017-11-22 CN CN201711176727.5A patent/CN109818916B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101141244A (en) * | 2006-09-08 | 2008-03-12 | 飞塔信息科技（北京）有限公司 | Network encrypted data virus detection and elimination system, proxy server and method |
| US8225085B2 (en) * | 2007-06-05 | 2012-07-17 | Blue Coat Systems, Inc. | System and method for distributed SSL processing between co-operating nodes |
| CN103188074A (en) * | 2011-12-28 | 2013-07-03 | 上海格尔软件股份有限公司 | Proxy method for improving SSL algorithm intensity of browser |
| CN104735058A (en) * | 2015-03-04 | 2015-06-24 | 深信服网络科技（深圳）有限公司 | Encryption method and system based on security protocol SSL |
| CN105577657A (en) * | 2015-12-18 | 2016-05-11 | 北京海泰方圆科技股份有限公司 | SSL/TLS algorithm suite expansion method |
| CN105471896A (en) * | 2015-12-28 | 2016-04-06 | 深圳市深信服电子科技有限公司 | Agent method, device and system based on SSL (Secure Sockets Layer) |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109818916A (en) | 2019-05-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10027564B2 (en) | Unobtrusive methods and systems for collecting information transmitted over a network | |
| TWI608743B (en) | Method, server and system for managing wireless network login password sharing function | |
| US20150295938A1 (en) | Method and apparatus for preventing unauthorized service access | |
| US8874695B2 (en) | Web access using cross-domain cookies | |
| US10263868B1 (en) | User-specific policy enforcement based on network traffic fingerprinting | |
| CN104636392B (en) | Carry out method, system, server and browser that recommendation information issues | |
| US9686173B1 (en) | Unsupervised methodology to unveil content delivery network structures | |
| US20150195381A1 (en) | Method and apparatus of identifying proxy ip address | |
| US11463537B1 (en) | Proxy selection by monitoring quality and available capacity | |
| CN114145004A (en) | System and method for using DNS messages to selectively collect computer forensics data | |
| US11496594B1 (en) | Regulation methods for proxy services | |
| US20110302272A1 (en) | Unobtrusive methods and systems for collecting information transmitted over a network | |
| US20170034164A1 (en) | Multifactor authentication for mail server access | |
| US20180288612A1 (en) | User equipment and method for protection of user privacy in communication networks | |
| US9491031B2 (en) | Devices, methods, and computer readable storage devices for collecting information and sharing information associated with session flows between communication devices and servers | |
| CN109818916B (en) | SSL/TLS proxy and negotiation method, device and computer readable storage medium thereof | |
| CN107623916B (en) | Method and equipment for WiFi network security monitoring | |
| CN105227532B (en) | A kind of blocking-up method and device of malicious act | |
| RU2601147C2 (en) | System and method for detection of target attacks | |
| CN111600929B (en) | Transmission line detection method, routing strategy generation method and proxy server | |
| Safari Khatouni et al. | An open dataset of operational mobile networks | |
| Hernandez-Quintanilla et al. | On the reduction of authoritative DNS cache timeouts: Detection and implications for user privacy | |
| US11902084B2 (en) | System, method, and computer program product for detecting an anomaly in network activity | |
| Sattler et al. | Packed to the Brim: Investigating the Impact of Highly Responsive Prefixes on Internet-wide Measurement Campaigns | |
| Zhou | Understanding home networks with lightweight privacy-preserving passive measurement |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |