Http-based portal authentication method, system, device and storage medium

Abstract

The application relates to the technical field of Portal authentication, in particular to a Portal authentication method and system based on HTTPS, a device and a storage medium. The HTTPS access request of a WEB server initiated by a client is received, user authentication strategy matching is performed, if the matching is successful, the form of a data packet is checked whether it conforms to a first preset rule, if yes, the message of TCP three-way handshake of the traffic with the successful strategy matching is released through the data forwarding surface of a security gateway, so that TCP connection establishment is successful, then SSL protocol handshake is performed, the HTTPS access request of the WEB server initiated by the client is decrypted by the data forwarding surface by using the result of the SSL protocol handshake, and the related result of the Portal authentication based on HTTPS is obtained. The SSL handshake process with the client is realized on the data forwarding surface, the HTTPS request is decrypted, and the HTTPS redirection is responded, so that the path of processing data packets is shortened, the time delay is reduced, and the concurrency number is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Portal authentication, in particular to a Portal authentication method and system based on HTTPS, a device and a storage medium. BACKGROUND

[0002] To implement Portal authentication based on HTTPS, the core problem to be solved for a security gateway is SSL offloading. A common solution is to use an HTTPS service process on the control plane to implement SSL handshake with the client, thereby solving the problem of SSL offloading. However, the existing technical solution uses a separate HTTPS service process, which results in a longer processing path of data packets inside the security gateway and increased latency, and is also limited by the limit of the number of socket descriptors that can be opened by a user-mode process, which also limits the number of concurrent clients that can be processed. At the same time, because the HTTPS service process only runs on one CPU core, it cannot implement multi-core concurrent processing of concurrent requests.

[0003] That is, in the prior art, when performing Portal authentication based on HTTPS, a separate HTTPS service process is used, which results in a longer processing path of data packets inside the security gateway, increased latency, and limited number of concurrent clients. SUMMARY

[0004] To at least partially overcome the problem of using a separate HTTPS service process when performing Portal authentication based on HTTPS in the related art, which results in a longer processing path of data packets inside the security gateway, increased latency, and limited number of concurrent clients, the present application provides a Portal authentication method and system based on HTTPS, a device and a storage medium.

[0005] The scheme of the present application is as follows:

[0006] In a first aspect, the present application provides a Portal authentication method based on HTTPS, which comprises:

[0007] initiating, by a client, an HTTPS access request to a WEB server;

[0008] receiving the HTTPS access request to the WEB server initiated by the client, and performing user authentication policy matching;

[0009] if the matching is successful, checking whether the form of the data packet conforms to a first preset rule, and if it does, releasing the TCP three-way handshake message of the traffic with successful policy matching through the data forwarding plane of the security gateway, so that the TCP connection is successfully established;

[0010] using the result of the TCP connection establishment success, performing SSL protocol handshake;

[0011] using the result of the SSL protocol handshake, the data forwarding surface decrypts the client-initiated HTTPS access request to the WEB server to obtain the related results of the HTTPS-based Portal authentication.

[0012] Further, the receiving of the client-initiated HTTPS access request to the WEB server and the performing of the user authentication policy matching include:

[0013] receiving the client-initiated HTTPS access request to the WEB server, determining whether the source IP address and the destination IP address match the user authentication policy, and if so, continuing to verify whether the form of the data packet conforms to the first preset rule;

[0014] Otherwise, the data packet is normally forwarded.

[0015] Further, the verifying of whether the form of the data packet conforms to the first preset rule, if so, passing the TCP three-way handshake message of the policy-matched successful traffic through the data forwarding surface of the security gateway to make the TCP connection successful, includes:

[0016] determining whether the data packet is a DNS message;

[0017] If the TCP destination port of the data packet is 53 or the UDP destination port is 53, the data packet is a DNS message, and the data packet is normally forwarded;

[0018] Otherwise, determining whether the data packet is a https message;

[0019] If the TCP destination port of the data packet is 443 or 8443, the data packet is a https message form, and the data packet is discarded;

[0020] Otherwise, determining whether the data packet is a TCP three-way handshake message, if the data packet is a TCP three-way handshake message, passing the TCP three-way handshake message of the policy-matched successful traffic through the data forwarding surface of the security gateway to make the TCP connection successful.

[0021] Further, the using of the result of the TCP connection establishment success, performing SSL protocol handshake, includes:

[0022] using the result of the TCP connection establishment success, verifying whether the data packet is a related message of the SSL protocol;

[0023] If the data packet is a message related to the SSL protocol, the SSL_accept() function of OpenSSL is called to perform the exchange of encryption functions, verify the SSL certificate, exchange or generate a session key to complete the SSL protocol handshake.

[0024] Otherwise, the data packet is discarded.

[0025] Further, the data forwarding surface decrypts the HTTPS access request initiated by the client to the WEB server based on the result of the SSL protocol handshake to obtain a result of the HTTPS-based Portal authentication, including:

[0026] The SSL_read() function of OpenSSL is called to decrypt the HTTPS access request initiated by the client to the WEB server based on the result of the SSL protocol handshake.

[0027] The content of the HTTP 302 page redirected to the Portal server is encrypted by calling the SSL_write() function of OpenSSL based on the decrypted result.

[0028] The encrypted result is sent to the client through a successfully established channel of TCP connection.

[0029] After receiving the HTTP 302 redirection, the browser automatically accesses the Portal authentication page redirected to obtain a result of the HTTPS-based Portal authentication.

[0030] In a second aspect, the application provides a HTTPS-based Portal authentication system, which comprises:

[0031] A request module for initiating an HTTPS access request to a WEB server by a client.

[0032] A first data processing module for receiving the HTTPS access request initiated by the client to the WEB server and performing user authentication policy matching.

[0033] A second data processing module for checking whether the form of the data packet conforms to a first preset rule if the matching is successful, and releasing the message of the TCP three-way handshake of the traffic with the successful policy matching through the data forwarding surface of the security gateway if the form conforms to the first preset rule to make the TCP connection successful.

[0034] A third data processing module for performing an SSL protocol handshake based on the result of the successful TCP connection.

[0035] The authentication module is configured to decrypt the HTTPS access request initiated by the client to the WEB server by the data forwarding face based on a result of the SSL protocol handshake, and obtain a result of the HTTPS-based Portal authentication.

[0036] In a third aspect, the application provides a HTTPS-based Portal authentication device, which comprises:

[0037] a memory having an executable program stored thereon;

[0038] a processor configured to execute the executable program in the memory to implement the steps of the method according to any one of the preceding aspects.

[0039] In a fourth aspect, the application provides a computer readable storage medium having computer instructions stored thereon, the computer instructions being configured to cause a computer to execute the steps of the method according to any one of the preceding aspects.

[0040] The technical solution provided by the application can have the following beneficial effects:

[0041] The HTTPS access request initiated by the client to the WEB server is received, and user authentication strategy matching is performed. If the matching is successful, it is checked whether the form of the data packet conforms to a first preset rule. If the form conforms to the first preset rule, the data forwarding face of the security gateway is used to release the TCP three-way handshake message of the traffic with the successful strategy matching, so that the TCP connection is successfully established. Then, the SSL protocol handshake is performed, and the data forwarding face decrypts the HTTPS access request initiated by the client to the WEB server based on a result of the SSL protocol handshake, and obtains a result of the HTTPS-based Portal authentication. The SSL handshake process with the client is implemented on the data forwarding face, the HTTPS request is decrypted, and the HTTPS redirection is responded, so that the path of processing the data packet is shortened, the time delay is reduced, and the concurrency number is increased.

[0042] It should be understood that the foregoing general description and the following detailed description are only exemplary and explanatory, and cannot limit the application. BRIEF DESCRIPTION OF DRAWINGS

[0043] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the application and, together with the specification, serve to explain the principles of the application.

[0044] Figure 1 is a HTTPS-based Portal authentication method flowchart provided by an embodiment of the application;

[0045] Figure 2is a Portal authentication system networking topology provided by one embodiment of the present application;

[0046] Figure 3 is a flowchart of a processing mode of a secure gateway to implement Portal authentication based on HTTPS provided by one embodiment of the present application;

[0047] Figure 4 is a flowchart of a data packet processing mode of an improved scheme of Portal authentication based on HTTPS provided by one embodiment of the present application;

[0048] Figure 5 is a flowchart of a processing mode of a data forwarding surface to implement Portal authentication page redirection based on HTTPS provided by one embodiment of the present application;

[0049] Figure 6 is a composition diagram of a Portal authentication system based on HTTPS provided by another embodiment of the present application;

[0050] Figure 7 is a composition diagram of a Portal authentication device based on HTTPS provided by another embodiment of the present application. DETAILED DESCRIPTION

[0051] The exemplary embodiments will be described in detail herein with reference to the attached drawings. The following description is with reference to the drawings, in which like numerals represent like elements throughout the several figures. The implementation described in the following exemplary embodiments is not meant to represent all implementations consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present application as detailed in the appended claims.

[0052] Portal authentication is also commonly referred to as Web authentication, and a Portal authentication website is commonly referred to as a portal. When a user accesses the Internet, the user must be authenticated at the portal, and if the authentication is not successful, the user can only access specific network resources, and after the authentication is successful, the user can access authorized network resources. Portal authentication is generally applied in enterprises, hotels, schools, high-speed rail stations, airports, and the like, to achieve the purposes of control of network access permissions, advertisement pushing, enterprise promotion, and the like.

[0053] A Portal authentication system mainly includes four elements: a client, a gateway device, a Portal server, and an authentication server. The networking topology is as shown in the following figure: Figure 2 Specifically, the secure gateway mainly has the following three functions:

[0054] 1. Before authentication, redirect the HTTP / HTTPS request of the client to the Portal server.

[0055] 2. In the authentication process, interacting with the Portal server, authentication server to complete the authentication of user identity.

[0056] 3. After the authentication is passed, allowing the user to access the authorized network resources.

[0057] With the rapid development of mobile Internet, the security in the process of data transmission is highly valued. A large number of HTTP-based applications are gradually upgraded to HTTPS, and HTTPS is a data encryption transmission based on SSL protocol. Because of the SSL protocol layer, the data packet interaction between all clients and the security gateway is much more complex than the HTTP protocol, which prompts the security gateway device to support the SSL protocol offloading capability to redirect the HTTPS request to the Portal server.

[0058] In the prior art, to implement the HTTPS-based Portal authentication, the core problem to be solved is SSL offloading. The usual solution is to use a HTTPS service process in the control plane to implement the SSL handshake process with the client, and then solve the problem of SSL offloading. The business logic flowchart is as follows Figure 3

[0059] Start an independent HTTPS service process in the control plane of the security gateway, listen on the loopback address 127.0.0.1, and the data interaction process is as follows:

[0060] Process ①: The client sends an HTTPS request, and the data forwarding plane receives the request.

[0061] Process ②: After the data forwarding plane receives the HTTPS request sent by the client, it performs DNAT conversion on the request, and the DNAT-converted address is 127.0.0.1. In this way, the HTTPS request will be sent to the local HTTPS service process of the gateway device through the kernel.

[0062] Process ③: The HTTPS service process processes the request of the client and sends a response message to the kernel, and the kernel will send the response message to the data forwarding plane.

[0063] Process ④: The data forwarding plane modifies the source address 127.0.0.1 of the response message to the original request message destination address recorded on the DNAT session through the five-tuple information query, and then sends it to the client.

[0064] ​The prior art scheme adopts a separate HTTPS service process, which results in a long processing path and increased time delay of data packets inside the security gateway, and is limited by the limitation of the number of socket descriptors that can be opened by a user process, which also limits the number of concurrent clients that can be processed. Meanwhile, since the HTTPS service process only runs on one CPU core, multi-core concurrent processing of concurrent requests cannot be achieved.

[0065] To solve the above problems, the present application provides an HTTPS-based Portal authentication method, system, device and storage medium. The method includes the following steps: receiving an HTTPS access request initiated by a client to a WEB server, performing user authentication policy matching; if the matching is successful, checking whether the form of the data packet conforms to a first preset rule; if the form conforms to the first preset rule, releasing the TCP three-way handshake message of the traffic whose policy matching is successful through the data forwarding surface of the security gateway, so that the TCP connection is successfully established; then performing SSL protocol handshake, and using the result of the SSL protocol handshake to decrypt the HTTPS access request initiated by the client to the WEB server through the data forwarding surface to obtain the result of the HTTPS-based Portal authentication. The SSL handshake process with the client is implemented on the data forwarding surface, the HTTPS request is decrypted, and the HTTPS redirection is responded, so as to shorten the processing path of the data packet, reduce the time delay, and increase the concurrency.

[0066] Embodiment one

[0067] Please refer to Figure 1 , Figure 1 is a flowchart of an HTTPS-based Portal authentication method provided by an embodiment of the present application. The method includes the following steps:

[0068] S1. A client initiates an HTTPS access request to a WEB server;

[0069] S2. Receiving the HTTPS access request initiated by the client to the WEB server, performing user authentication policy matching;

[0070] S3. If the matching is successful, checking whether the form of the data packet conforms to a first preset rule; if the form conforms to the first preset rule, releasing the TCP three-way handshake message of the traffic whose policy matching is successful through the data forwarding surface of the security gateway, so that the TCP connection is successfully established;

[0071] S4. Using the result of the TCP connection establishment to perform SSL protocol handshake;

[0072] S5. Using the result of the SSL protocol handshake, the data forwarding plane decrypts the client-initiated HTTPS access request to the WEB server to obtain the relevant result of the HTTPS-based Portal authentication.

[0073] In one embodiment, as described in step S2, the receiving of the client-initiated HTTPS access request to the WEB server and the user authentication policy matching include:

[0074] The receiving of the client-initiated HTTPS access request to the WEB server judges whether the source IP address and the destination IP address match the user authentication policy. If they match, the form of the data packet is verified according to the first preset rule.

[0075] Otherwise, the data packet is normally forwarded.

[0076] In one embodiment, as described in step S3, if the matching is successful, the form of the data packet is verified according to the first preset rule. If it is consistent, the data forwarding plane of the security gateway releases the TCP three-way handshake message of the traffic with successful policy matching, so that the TCP connection is successfully established, including:

[0077] Judging whether the data packet is a DNS message;

[0078] If the destination port of the TCP of the data packet is 53 or the UDP destination port is 53, the data packet is a DNS message, and the data packet is normally forwarded.

[0079] Otherwise, it is judged whether the data packet is a https message.

[0080] If the destination port of the TCP of the data packet is 443 or 8443, the data packet is a https message, and the data packet is discarded.

[0081] Otherwise, it is judged whether the data packet is a TCP three-way handshake message. If the data packet is a TCP three-way handshake message, the data forwarding plane of the security gateway releases the TCP three-way handshake message of the traffic with successful policy matching, so that the TCP connection is successfully established.

[0082] In one embodiment, as described in step S4, the SSL protocol handshake is performed using the result of the TCP connection establishment, including:

[0083] Using the result of the TCP connection establishment, it is judged whether the data packet is a related message of the SSL protocol.

[0084] If the data packet is a message related to the SSL protocol, the SSL_accept() function of OpenSSL is called to perform the exchange of encryption functions, verify the SSL certificate, and exchange or generate a session key to complete the SSL protocol handshake.

[0085] Otherwise, the data packet is discarded.

[0086] In one embodiment, as described in step S5, the data forwarding plane decrypts the client-initiated HTTPS access request to a WEB server using the result of the SSL protocol handshake to obtain the result of the HTTPS-based Portal authentication, including:

[0087] The SSL_read() function of OpenSSL is called to decrypt the client-initiated HTTPS access request to a WEB server using the result of the SSL protocol handshake.

[0088] The content of the HTTP 302 page redirected to the Portal server is encrypted by calling the SSL_write() function of OpenSSL using the result of the decryption.

[0089] The encrypted result is sent to the client through a successfully established TCP connection.

[0090] After receiving the HTTP 302 redirection, the browser automatically accesses the redirected Portal authentication page to obtain the result of the HTTPS-based Portal authentication.

[0091] In specific implementation, as shown in Figure 4 , the present application implements SSL protocol offloading in the data forwarding plane, completes the interaction process of the client SSL handshake message, provides complete HTTPS service, thereby shortening the path of processing data packets, reducing latency, and improving concurrency.

[0092] In specific implementation, the flowchart of the data forwarding plane implementing HTTPS-based Portal authentication page redirection is as shown in Figure 5 .

[0093] 1. The client initiates an HTTPS access request to a WEB server (this server can be a user-built server or a WEB server on the Internet), and this traffic hits the user authentication strategy configured by the security gateway. The data forwarding plane of the security gateway will release the TCP three-way handshake message of this traffic by default, so that the TCP connection is successfully established. Figure 5 - Process ①)

[0094] 2. After the TCP connection between the client and the WEB server is successfully established, the handshake message ClientHello of SSL is initiated, the data forwarding surface of the security gateway intercepts the ClientHello message and calls the SSL_accept() function of OpenSSL to complete the whole process of SSL handshake with the client. Figure 5 Flow 2)

[0095] 3. After the SSL handshake between the data forwarding surface of the security gateway and the client is completed, when the HTTPS request sent by the client is received, the SSL_read() function of OpenSSL is called to decrypt the HTTPS request of the client, then the content of the HTTP 302 page redirected to the Portal server is encrypted by calling the SSL_write() of OpenSSL, and is sent through the TCP connection of flow 1. Figure 5 Flow 3)

[0096] 4. After receiving the HTTP 302 redirection, the browser automatically accesses the Portal authentication page redirected to. Figure 5 Flow 4).

[0097] In specific implementation, the detailed logic of the data forwarding surface for processing the data packet is as follows,

[0098] The gateway data surface receives the HTTPS request initiated by the client, performs authentication policy matching, specifically judges whether the source IP and the destination IP match the user authentication policy, if not, the data packet is normally forwarded; otherwise, it is judged whether the data packet is a DNS message;

[0099] If the TCP destination port of the data packet is 53 or the UDP destination port is 53, the data packet is a DNS message, and the data packet is normally forwarded;

[0100] Otherwise, it is judged whether the data packet is a https message;

[0101] If the TCP destination port of the data packet is 443 or 8443, the data packet is in the form of https message, and the data packet is discarded;

[0102] Otherwise, it is judged whether the data packet is a TCP three-way handshake message, if the data packet is a TCP three-way handshake message, the data packet of the traffic with successful policy matching is released through the data forwarding surface of the security gateway, so that the TCP connection is successfully established.

[0103] Based on the channel with successfully established TCP connection, the SSL handshake protocol is performed;

[0104] After the SSL handshake is completed, the client encrypted https packet is decrypted into plaintext http, the response plaintext http redirection packet is assembled, the plaintext http packet is encrypted into https through the SSL protocol layer, and is sent to the client.

[0105] The client decrypts the response https packet into plaintext http, requests the redirected Portal page, and receives the page responded by the portal server.

[0106] In one embodiment, the SSL handshake process with the client is implemented on the data forwarding plane of the application, the HTTPS request is decrypted, and the HTTPS redirection is responded; the SSL handshake is completed on the data forwarding plane of the application, so that the HTTPS request packet is decrypted, compared with the existing method of starting the HTTPS service process on the application layer, the processing path of the HTTPS packet in the gateway device is shortened, and the packet delay is reduced. Meanwhile, the multi-core concurrent processing of the HTTPS request can be implemented on the multi-core gateway device.

[0107] Embodiment two

[0108] Please refer to Figure 6 , Figure 6 is another embodiment of the application, which provides a HTTPS-based Portal authentication system composition schematic diagram, the system comprises:

[0109] The request module 601 is configured to initiate an HTTPS access request to a WEB server by a client.

[0110] The first data processing module 602 is configured to receive the HTTPS access request to the WEB server initiated by the client, and perform user authentication policy matching.

[0111] The second data processing module 603 is configured to, if the matching is successful, check whether the form of the packet conforms to a first preset rule, and if yes, release the TCP three-way handshake packet of the traffic with the successful policy matching through the data forwarding plane of the security gateway, so that the TCP connection is successfully established.

[0112] The third data processing module 604 is configured to perform SSL protocol handshake by using the result of the successful TCP connection establishment.

[0113] The authentication module 605 is configured to decrypt the HTTPS access request to the WEB server initiated by the client by using the result of the SSL protocol handshake, and obtain a result of the HTTPS-based Portal authentication.

[0114] Embodiment three

[0115] Please refer to Figure 7, Figure 7 In another embodiment of the present application, a schematic diagram of an HTTPS-based portal authentication device is provided, and the device comprises:

[0116] a memory 71, on which an executable program is stored;

[0117] a processor 72, configured to execute the executable program in the memory 71, so as to implement the steps of the method according to any one of the preceding embodiments.

[0118] In addition, the present application provides a computer readable storage medium, which stores computer instructions for causing a computer to execute the steps of the method according to any one of the preceding embodiments. The storage medium can be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a Flash Memory, a Hard Disk Drive (HDD) or a Solid-State Drive (SSD), etc. The storage medium can also include a combination of the above-mentioned types of memories.

[0119] It can be understood that the same or similar parts in the above embodiments can be mutually referred to, and the content not described in detail in some embodiments can be referred to the same or similar content in other embodiments.

[0120] It should be noted that, in the description of the present application, the terms "first", "second", etc. are only used for descriptive purposes, and cannot be understood as indicating or implying relative importance. In addition, in the description of the present application, unless otherwise specified, the meaning of "a plurality of" is at least two.

[0121] Any process or method descriptions in flow charts or described elsewhere herein can be understood as representing code modules, segments, or portions of code which include one or more executable instructions for performing specified logic functions or steps, and the various embodiments of the present application include additional implementations in which the order of execution is not necessarily the same as the order shown or discussed. It will be appreciated that the scope of the present application includes additional implementations in which the order of execution is not necessarily the same as the order shown or discussed.

[0122] It should be understood that each of the elements of the present application can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented in hardware, and in another embodiment, any of the following technologies known in the art or their combinations can be used: discrete logic circuitry having logic gates for implementing logic functions on data signals, application specific integrated circuits having appropriate combinational logic gates, programmable gate arrays (PGA), field programmable gate arrays (FPGA), etc.

[0123] Those skilled in the art of the present technology can understand that all or part of the steps carried out by the above-mentioned embodiment method can be completed by a program instructing the relevant hardware, and the program can be stored in a computer readable storage medium. When the program is executed, it includes one of the steps of the method embodiment or a combination thereof.

[0124] In addition, each functional unit in each embodiment of the present application can be integrated into one processing module, or each unit can be physically present separately, or two or more units can be integrated into one module. The above-mentioned integrated module can be realized in the form of hardware or in the form of a software function module. The integrated module, if realized in the form of a software function module and sold or used as an independent product, can also be stored in a computer readable storage medium.

[0125] The above-mentioned storage medium can be a read-only memory, a magnetic disk or an optical disk, etc.

[0126] In the description of the present specification, the description of the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the illustrative description of the above terms does not necessarily mean the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0127] Although the embodiments of the present application have been shown and described above, it should be understood that the above-mentioned embodiments are exemplary and cannot be understood as limiting the present application, and those skilled in the art can make changes, modifications, replacements and variations to the above-mentioned embodiments within the scope of the present application.

Claims

1. A Portal authentication method based on HTTPS, characterized in that, The method includes: The client initiates an HTTPS access request to the web server; Receive the HTTPS access request to the web server initiated by the client and perform user authentication policy matching; If a match is successful, the form of the data packet is checked to see if it conforms to the first preset rule. If it does, the TCP three-way handshake message of the traffic that matched the policy is allowed to pass through the data forwarding plane of the security gateway, so that the TCP connection is successfully established. Use the successful establishment of the TCP connection to perform an SSL handshake. Using the result of the SSL handshake, the OpenSSL SSL_read() function is called to decrypt the HTTPS access request initiated by the client to the web server; Using the decryption result, the content of the HTTP 302 page redirected to the Portal server is encrypted by calling the OpenSSL SSL_write() function; Using the encrypted result, a successful TCP connection is established and sent to the client; After the client receives the HTTP 302 redirect, the browser will automatically access the redirected Portal authentication page and obtain the relevant results of the Portal authentication based on HTTPS.

2. The method according to claim 1, characterized in that, The step of receiving the HTTPS access request to the web server initiated by the client and performing user authentication policy matching includes: Receive the HTTPS access request to the WEB server initiated by the client, determine whether the source IP address and destination IP address match the user authentication policy, and if they match, continue to verify whether the form of the data packet conforms to the first preset rule. Otherwise, the data packet is forwarded normally.

3. The method according to claim 1, characterized in that, If the form of the verification data packet conforms to the first preset rule, and if so, the TCP three-way handshake message of the traffic that successfully matches the policy is allowed to pass through the data forwarding plane of the security gateway, so that its TCP connection is successfully established, including: Determine if the data packet is a DNS message; If the TCP destination port of the data packet is 53 or the UDP destination port is 53, then the data packet is a DNS message and the data packet is forwarded normally. Otherwise, determine whether the data packet is an HTTPS message; If the TCP destination port of the data packet is 443 or 8443, then the data packet is in HTTPS message format and the data packet is discarded. Otherwise, determine whether the data packet is a TCP three-way handshake message. If the data packet is a TCP three-way handshake message, allow the TCP three-way handshake message of the traffic that successfully matches the policy to pass through the data forwarding plane of the security gateway, so that its TCP connection is successfully established.

4. The method according to claim 1, characterized in that, The step of using the successful establishment of the TCP connection to perform an SSL handshake includes: Using the successful establishment of the TCP connection, verify whether the data packet is a message related to the SSL protocol. If the data packet is a message related to the SSL protocol, the SSL protocol handshake is completed by calling the SSL_accept() function of OpenSSL to exchange encryption functions, verify SSL certificates, and exchange or generate session keys. Otherwise, the data packet is discarded.

5. An HTTPS-based Portal authentication system, applied to the HTTPS-based Portal authentication method according to any one of claims 1-4, characterized in that, The system includes: The request module is used by the client to initiate HTTPS access requests to the web server; The first data processing module is used to receive the HTTPS access request to the WEB server initiated by the client and perform user authentication policy matching. If the second data processing module is successful in matching, it verifies whether the form of the data packet conforms to the first preset rule. If it does, it allows the TCP three-way handshake message of the traffic that is successfully matched by the policy to be passed through the data forwarding surface of the security gateway, so that the TCP connection is successfully established. The third data processing module uses the successful establishment result of the TCP connection to perform an SSL protocol handshake. The authentication module is used to utilize the result of the SSL handshake to call the OpenSSL SSL_read() function to decrypt the HTTPS access request initiated by the client to the web server. Using the decryption result, the content of the HTTP 302 page redirected to the Portal server is encrypted by calling the OpenSSL SSL_write() function; Using the encrypted result, a successful TCP connection is established and sent to the client; After the client receives the HTTP 302 redirect, the browser will automatically access the redirected Portal authentication page and obtain the relevant results of the Portal authentication based on HTTPS.

6. A Portal authentication device based on HTTPS, characterized in that, The device includes: Memory, on which executable programs are stored; A processor for executing the executable program in the memory to implement the steps of the method according to any one of claims 1-4.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the steps of the method according to any one of claims 1-4.

Images