CN119561998A - Communication method and device - Google Patents
Communication method and device Download PDFInfo
- Publication number
- CN119561998A CN119561998A CN202411580117.1A CN202411580117A CN119561998A CN 119561998 A CN119561998 A CN 119561998A CN 202411580117 A CN202411580117 A CN 202411580117A CN 119561998 A CN119561998 A CN 119561998A
- Authority
- CN
- China
- Prior art keywords
- portal server
- registration message
- nat
- message
- target
- 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.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/54—Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The application provides a communication method and a communication device, wherein the method comprises the steps of carrying out key negotiation with a target Portal server and establishing DTLS connection when a configured policy template is bound, sending a first registration message to NAT equipment through the DTLS connection so that the NAT equipment carries out NAT conversion on the first registration message and then sends a second registration message to the target Portal server, generating a registry item by the target Portal server according to the second registration message, and interacting Portal protocol messages with the target Portal server through the DTLS connection and the NAT equipment when an accessed user equipment initiates a request for accessing network resources, and carrying out Portal authentication.
Description
Technical Field
The present application relates to the field of communications technologies, and in particular, to a communications method and apparatus.
Background
Portal authentication, also commonly referred to as Web authentication, is a mechanism for network access control. Which requires the user to authenticate before gaining access to the network resource. Portal authentication plays a vital role as a network access control technology, and can ensure the safe access of network resources.
Portal authentication is typically deployed at the access stratum and critical data portals that need protection, and enforces access control. In a networking environment adopting Portal authentication, user equipment can actively access a known Portal server website through access equipment to initiate Portal authentication, can access any non-Portal server website through the access equipment, is forcefully accessed to the Portal server website subsequently, and then starts Portal authentication.
In the communication interaction between the access equipment and the Portal server, the Portal server performs identity authentication on the user by utilizing the protocol message so as to achieve the purpose of controlling the access of the user. In the existing Portal protocol, protocol messages are supposed to be carried on the basis of user datagram protocol (English: user Datagram Protocol, abbreviated as UDP) messages, and are composed of a fixed-length header and variable-length attribute fields.
However, if the Portal server is at the far end, when the access device interacts with the Portal server, the protocol messages received and transmitted by both sides are transmitted across the public network, and because the UDP messages only carry out encryption protection on the password part carried by the UDP messages, other fields are in plain text interaction. In this way, unsafe hidden dangers such as protocol message loss, interception and the like occur in the Portal authentication process.
Disclosure of Invention
In view of this, the application provides a communication method and device, which are used for solving the problem that in the existing Portal authentication process, because a protocol message is carried by a UDP message and the UDP message is in plaintext interaction, unsafe hidden dangers such as the loss and interception of the protocol message occur.
In a first aspect, the present application provides a communication method, the method being applied to an access device, the method comprising:
When the configured policy template is bound, key negotiation is carried out with a target Portal server, and DTLS connection is established;
Sending a first registration message to NAT equipment through the DTLS connection, so that the NAT equipment carries out NAT conversion on the first registration message and then sends a second registration message to the target Portal server, and the target Portal server generates a registry item according to the second registration message;
when an accessed user equipment initiates a request for accessing network resources, the accessed user equipment interacts with the target Portal server through the DTLS connection and the NAT equipment to send a first Portal protocol message to the NAT equipment, and Portal authentication is carried out;
the first registration message, the second registration message and the Portal protocol message are encrypted messages which are encrypted by using the key and the encryption algorithm after the key negotiation.
In a second aspect, the present application provides a communication apparatus for application to an access device, the apparatus comprising:
The establishing unit is used for carrying out key negotiation with the target Portal server and establishing DTLS connection when the configured strategy template is bound;
a sending unit, configured to send a first registration message to a NAT device through the DTLS connection, so that the NAT device performs NAT conversion on the first registration message and then sends a second registration message to the target Portal server, where the target Portal server generates a registry entry according to the second registration message;
The sending unit is further configured to interact a Portal protocol packet with the target Portal server through the DTLS connection and the NAT device and perform Portal authentication when the accessed user equipment initiates a request for accessing a network resource;
the first registration message, the second registration message and the Portal protocol message are encrypted messages which are encrypted by using the key and the encryption algorithm after the key negotiation.
In a third aspect, the application provides a network device comprising a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor to cause the processor to perform the method provided by the first aspect of the application.
The access device and the target Portal server are connected through the DTLS, the access device sends a first registration message to the NAT device through the DTLS, so that the NAT device can send a second registration message to the target Portal server after carrying out NAT conversion on the first registration message, the target Portal server generates a registration list item according to the second registration message, when the accessed user device initiates a request for accessing network resources, the access device interacts Portal protocol messages with the target Portal server through the DTLS and the NAT device, portal authentication is carried out, and the first registration message, the second registration message and the Portal protocol messages are encrypted messages which are encrypted by utilizing keys and encryption algorithms after key negotiation.
In this way, in the scene of cross-public network transmission between the access equipment and the remote Portal server, the access equipment establishes DTLS connection with the Portal server, so that the transmission after the encryption processing of the Portal protocol messages in the subsequent Portal authentication process is realized. Therefore, the access equipment and the Portal server are easy to butt joint, portal authentication is safer, and the access equipment utilizes a single Socket communication multi-session DTLS mode, so that the management cost of maintaining a large number of Socket communication by the Portal server is reduced while safety is brought. The method also solves the problem that in the existing Portal authentication process, because the protocol message is carried by the UDP message and the UDP message is in plaintext interaction, unsafe hidden dangers such as the loss and interception of the protocol message occur.
Drawings
FIG. 1 is a flow chart of a communication method provided by an embodiment of the present application;
fig. 2 is a signaling diagram of a communication method according to an embodiment of the present application;
Fig. 3 is a block diagram of a communication device according to an embodiment of the present application;
fig. 4 is a hardware structure of a network device according to an embodiment of the present application.
Detailed Description
Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with aspects of the application as detailed in the accompanying claims.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and/or" as used herein refers to and encompasses any or all possible combinations of one or more of the corresponding listed items.
It should be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the application. The term "if" as used herein may be interpreted as "at..once" or "when..once" or "in response to a determination", depending on the context.
The communication method provided by the embodiment of the application is described in detail below. Referring to fig. 1, fig. 1 is a flowchart of a communication method according to an embodiment of the present application. The method is applied to an access device. The communication method provided by the embodiment of the application can comprise the following steps.
Step 110, when the configured policy template is bound, performing key negotiation with a target Portal server, and establishing a DTLS connection;
Specifically, through the local area network, the user device accesses an interface of the access device, which enables Portal authentication. The access device is connected with network address translation (English: network Address Translation, NAT for short), the NAT device is connected with the Portal server through the public network.
And starting a Portal process in the access equipment to realize Portal authentication of the user equipment.
A policy template is configured in the access device, and the policy template includes information such as various encryption algorithms, public key infrastructure (english: public Key Infrastructure, abbreviated as PKI), version and model numbers, and the like. The version model specifically refers to a version model of a data packet transport layer security protocol (english: datagram Transport Layer Security, abbreviated as DTLS) and transport layer security protocol (english: transport Layer Security, abbreviated as TLS) connection supported by the access device.
After the Portal process binds the policy template, the access device performs key negotiation with the target Portal server and establishes a DTLS connection.
The following briefly describes the process of the access device performing key agreement with the target Portal server and establishing a DTLS connection.
And establishing handshake connection between the access equipment and the target Portal server, verifying the identity of the opposite party in the handshake process, completing verification of the identity of the opposite party and completing negotiation of the secret key and the encryption suite so as to encrypt data in subsequent data transmission.
Initial Hello negotiation procedure:
The access device sends a ClientHello message to the target Portal server to initiate a handshake process, where the ClientHello message includes information such as DTLS version and encryption suite supported by the access device. After receiving the ClientHello message, the target Portal server sends a HellovelifyRequest message to the access server. The HelloVerifyRequest message comprises information such as a DTLS version, an encryption suite and Cookie information selected by the target Portal server.
So far, the primary Hello negotiation process between the access equipment and the target Portal server is completed.
Secondary Hello negotiation procedure:
The access device again sends a Client Hello message to the target Portal server, where the Client Hello message includes the encryption suite, the Cookie sent by the target Portal server, and a Random number (Random). After receiving the Client Hello message, the target Portal server verifies whether the Cookie is legal. If the Cookie is legal, continuing to carry out handshake connection with the access equipment and sending ServerHello to the access equipment, and if the Cookie is illegal, refusing to establish connection with the access equipment by the target Portal server. The target Portal server continues to send the authentication message to the access device. The authentication message comprises a digital Certificate of the public key information of the target Portal server, so that the access equipment can carry out identity authentication on the target Portal server. The target Portal server continues to send a ServerKeyExchange message to the access device, the ServerKeyExchange message including the temporary public key of the target Portal server itself. The target Portal server continues to send a CertificateRequest message to the access device. The Certification request message is used for enabling the access device to provide a digital certificate of self public key information so that the target Portal server can carry out identity authentication on the access device. The target Portal server continues to send ServerHelloDone messages to the access device. The ServerHelloDone message is used for informing the access device of the completion of the DTLS version and encryption suite negotiation process, and starting key exchange.
So far, the secondary Hello negotiation process between the access equipment and the target Portal server is completed.
Key negotiation process:
The access device sends a Certificate message to the target Portal server, wherein the Certificate message comprises a digital Certificate of the public key information of the access device. After the access device acquires the digital certificate of the public key information of the target Portal server, the access device verifies whether the digital certificate of the public key information of the target Portal server is legal. If the client is legal, the access device encrypts the key randomly generated by the guest access device by using the public key in the digital certificate, and continuously sends a ClientKeyexchange message to the target Portal server. The ClientKeyExchange message includes the encrypted key. The access device continues to send a CertificateVerify message to the target Portal server, where the CertificateVerify message is used for authenticating the access device by the target Portal server. The access device continues to send changecipherespec messages to the target Portal server. The changecipherespec message is used for notifying the target Portal server that the subsequent message will be encrypted by adopting the negotiated key and encryption suite. The access device continues to send the Finished message to the target Portal server. The Finished message is used for notifying the target Portal server, and the handshake process is Finished. The target Portal server sends a ChangeCipherSpec message to the access device. The changecipherespec message is used to inform the access device that the subsequent message will be encrypted using the negotiated key and encryption suite. The target Portal server continues to send the Finished message to the access device. The Finished message is used to notify the access device that the handshake process is complete.
So far, the key negotiation process between the access equipment and the target Portal server is completed.
After the handshake between the access device and the target Portal server is successful, the access device also completes the authentication of the target Portal server. The reason is that the target Portal server with the private key can decrypt the key from the ClientKeyExchange message, thereby achieving the success of the subsequent handshake.
Step 120, sending a first registration message to a NAT device through the DTLS connection, so that the NAT device performs NAT conversion on the first registration message and then sends a second registration message to the target Portal server, and the target Portal server generates a registry entry according to the second registration message;
specifically, according to the description of step 110, after the access device establishes a DTLS connection with the target Portal server, the access device generates a first registration message. The first registration message includes a device name (e.g., device ID) of the access device.
And through the DTLS connection, the access device sends a first registration message to the NAT device. After receiving the first registration message, the NAT equipment carries out NAT conversion on the first registration message to obtain a second registration message. The NAT equipment continues to send a second registration message to the target Portal server.
And after receiving the second registration message, the target Portal server generates a registry item corresponding to the access equipment according to the second registration message. The registry key includes information such as the name of the access device, the IP address after NAT translation, and the port number. The target Portal server generates a registry item, which is used for determining the access equipment and acquiring the IP address and port number information of the access equipment after NAT conversion when the Portal protocol message is subsequently sent to the access equipment.
In the embodiment of the present application, the first registration message is a UDP message, which includes a UDP header and a data field. After the access device establishes DTLS connection with the target Portal server, the access device encrypts the complete data field in the UDP message through the information such as the secret key, the encryption algorithm and the like negotiated in the process of establishing the DTLS connection. The first registration message is an encrypted message.
Note that the UDP header does not perform encryption processing. When NAT equipment carries out NAT conversion on the first registration message, NAT conversion is carried out on a source internet protocol (English: internet Protocol, abbreviated as IP) address and a source port, and an encrypted data field is not processed, so that a second registration message is obtained. The second registration message is an encrypted message.
And 130, when the accessed user equipment initiates a request for accessing network resources, a Portal protocol message is interacted with the target Portal server through the DTLS connection and the NAT equipment, and Portal authentication is performed.
Specifically, according to the description of step 120, after the access device sends a first registration message to the NAT device, when the accessed user device initiates a request for accessing a network resource (for example, a POST request (carrying a user name and a password) of http/https is sent to the target Portal server through a landing page of the target Portal server), the access device interacts a Portal protocol message with the target Portal server through the established DTLS connection and the NAT device, and performs Portal authentication (for example, the target Portal server generates a Portal protocol message after receiving the POST request).
It should be noted that, the process of the user equipment initiating the request for accessing the network resource and the process of the access device performing the Portal authentication with the target Portal server are the same as the existing process of initiating the access request and the Portal authentication, and will not be described in detail here.
In the embodiment of the application, through the established DTLS connection, the access device and the target Portal server may encrypt any one of the Portal protocol messages and send the encrypted message to the NAT device.
For example, the target Portal server sends a first Portal protocol message to the NAT device. Similarly, similar to the above description in step 120, after receiving the first Portal protocol packet, the NAT device performs NAT conversion on the first Portal protocol packet to obtain a second Portal protocol packet. The NAT device continues to send a second Portal protocol message to the access device.
And after receiving the second Portal protocol message, the access equipment continues Portal authentication. It can be understood that, when the access device performs Portal authentication, the access device may also perform encryption processing on any one of the Portal protocol messages and send the encrypted Portal protocol messages to the NAT device.
In the embodiment of the present application, the Portal protocol messages are also UDP messages, which include UDP headers and data fields. After the DTLS connection is established, the access equipment and the target Portal server carry out encryption processing on the complete data field in the UDP message through the information such as the secret key, the encryption algorithm and the like negotiated in the process of establishing the DTLS connection. The Portal protocol messages are also encrypted messages.
Note that the UDP header does not perform encryption processing. When NAT equipment carries out NAT conversion on the Portal protocol message, the NAT conversion is carried out on the source IP address and the source port, and the encrypted data field is not processed, so that the Portal protocol message after NAT conversion is obtained. The Portal protocol message after NAT conversion is the encrypted message.
Optionally, in the embodiment of the present application, a process of periodically sending the registration message by the access device is further included.
Specifically, after sending the first registration message to the NAT device, the access device periodically generates the registration message, for example, every 10s by default.
The access device generates a third registration message. The third registration message includes a device name (e.g., device ID) of the access device.
And the access device sends a third registration message to the NAT device through the DTLS connection. And after receiving the third registration message, the NAT equipment carries out NAT conversion on the third registration message to obtain a fourth registration message. The NAT equipment continues to send a fourth registration message to the target Portal server.
After receiving the fourth registration message, the target Portal server updates the registration list item corresponding to the access device according to the fourth registration message. The registry key includes information such as the name of the access device, the IP address after NAT translation, and the port number.
In the embodiment of the present application, the third registration message is a UDP message, which includes a UDP header and a data field. After the access device establishes DTLS connection with the target Portal server, the access device encrypts the complete data field in the UDP message through the information such as the secret key, the encryption algorithm and the like negotiated in the process of establishing the DTLS connection. The third registration message is an encrypted message.
Note that the UDP header does not perform encryption processing. When NAT equipment carries out NAT conversion on the third registration message, NAT conversion is carried out on the source IP address and the source port, and the encrypted data field is not processed, so that a fourth registration message is obtained. The fourth registration message is an encrypted message.
As shown in fig. 2, fig. 2 is a signaling diagram of a communication method according to an embodiment of the present application. In fig. 2, the access device first establishes a DTLS connection with the target Portal server. After the DTLS connection is established, the access device generates and sends a registration message 1 to the NAT device through the DTLS connection.
After receiving the registration message 1, the NAT device performs NAT conversion on the source IP address 1 (private network IP) and the source port 1 (private network port) included in the registration message 1 to obtain a registration message 2, where the registration message 2 includes the converted source IP address 2 (public network IP) and source port 2 (public network port). The NAT device continues to send registration message 2 to the target Portal server.
After receiving the registration message 2, the target Portal server generates a registry item corresponding to the access equipment according to the registration message 2, and locally stores the registry item.
When the accessed user equipment initiates a request for accessing network resources, the target Portal server and the access equipment can encrypt any Portal protocol message, then send the encrypted Portal protocol message to the NAT equipment through the DTLS connection, and send the NAT-converted Portal protocol message to the opposite terminal after the NAT equipment performs NAT conversion.
After the access device sends the registration message 1 to the NAT device, the access device regenerates and sends the registration message 3 to the NAT device every 10s.
Through the DTLS connection, the access device sends a registration message 3 to the NAT device. After receiving the registration message 3, the NAT device performs NAT conversion on the source IP address 1 (private network IP) and the source port 1 (private network port) included in the registration message 3 to obtain a registration message 4, where the registration message 4 includes the converted source IP address 3 (public network IP) and source port 4 (public network port). The NAT device continues to send registration message 4 to the target Portal server.
NAT devices in a network are typically operator devices, and NAT mapping rules configured on the NAT devices change according to the operator's plan. For example, during the 0-6 point time period, NAT mapping rules translate source IP address 1 to source IP address 2, during the 6-12 point time period, NAT mapping rules translate source IP address 1 to source IP address 3, and so on.
After receiving the registration message 4, the target Portal server updates the registry item corresponding to the access device according to the registration message 4.
In the embodiment of the present application, the registration messages 1 to 4 are all UDP messages, which include a UDP header and a data field. After the access device establishes DTLS connection with the target Portal server, the access device encrypts the complete data field in the UDP message through the information such as the secret key, the encryption algorithm and the like negotiated in the process of establishing the DTLS connection.
Note that the UDP header does not perform encryption processing. When NAT equipment carries out NAT conversion on the registration message 1 and the registration message 3, the NAT conversion is carried out on the source IP address and the source port, and the encrypted data field is not processed.
Optionally, in the embodiment of the present application, a process of disconnecting the DTLS connection between the access device and the target Portal server is further included.
Specifically, after the user equipment completes Portal authentication, the access equipment disables the policy template and disconnects the DTLS. The access device also generates a first close notification and sends the first close notification to the NAT device again, so that the NAT device sends a second close notification to the target Portal server after forwarding the first close notification through NAT.
And after receiving the closing notification, the target Portal server disconnects the DTLS.
The first closing notification and the second closing notification are encrypted messages.
It should be noted that the DTLS connection is carried over the SSL session between the access device and the target Portal server. Therefore, when the access device disconnects the DTLS connection, the SSL session carrying the DTLS connection may be destroyed. When the target Portal server disconnects the DTLS connection, after receiving the closing notification, the target Portal server can destroy the SSL session carrying the DTLS connection. If the target Portal server does not receive the closing notification, the target Portal server can determine that the DTLS connection between the target Portal server and the access equipment is disconnected after the preset time is reached, and destroy the SSL session carrying the DTLS connection by itself.
It is understood that, when the access device encrypts the first close notification, the access device may encrypt the first close notification by using an existing SSL protocol encryption manner, which will not be repeated herein.
Similarly, in the process of establishing DTLS connection with the target Portal server, both parties encrypt the transmitted message, or encrypt the transmitted message by using the encryption manner of the existing SSL protocol, which is not repeated here.
Optionally, in the embodiment of the present application, before the access device sends the first registration packet to the NAT device through the DTLS connection, the access device further performs a procedure of determining to invoke the DTLS connection through the local mapping table.
Specifically, the IP addresses of multiple Portal servers may be configured within the access device. According to the IP address of each Portal server, the access device can respectively carry out Socket communication with different Portal servers through different interfaces, and on the Socket communication, the access device and each Portal server create a secure Socket layer (English: secure Sockets Layer, abbreviated: SSL) session.
The SSL session created may be embodied as a data structure, such as a memory block. SSL session information, such as both end device information (IP address), session ID, carried DTLS information, etc., is stored in the data structure.
After creating the SSL session, the access device also locally generates a mapping relationship table entry comprising the IP address of the Portal server and a pointer to the data structure. The access device stores the plurality of mapping relation table entries into a local mapping relation table.
In the embodiment of the application, the access device may take one of the plurality of Portal servers as the target Portal server according to the configuration instruction of the administrator (for example, the configuration instruction includes the IP address of the Portal server).
The access device creates a DTLS connection with the target Portal server over the SSL session established with the target Portal server (the specific creation process may be implemented as described in the previous embodiments). Meanwhile, the access device can obtain a mapping relation table item matched with the IP address of the target Portal server from the local mapping relation table according to the IP address of the target Portal server. The access device accesses the data structure by means of a pointer to the data structure, updating the stored SSL session information.
Before sending the first registration message to the target Portal server, the access device may further obtain, from the local mapping relationship table, a mapping relationship table entry matching with the IP address of the target Portal server according to the IP address of the target Portal server. The access device accesses the data structure block by means of a pointer to the data structure, such that a corresponding SSL session is invoked and a DTLS connection is invoked on the SSL session.
Subsequently, the access device may send various encrypted messages to the target Portal server over the invoked DTLS connection.
Further, one SocketA has been configured within the access device, and the SocketA includes SocketA1 for IPv4 networks and SocketA for IPv6 networks, depending on the different networks applicable. Similarly, one SocketB has been deployed within each Portal server, and the SocketB includes SocketB1 for IPv4 networks and SocketB for IPv6 networks, depending on the different networks available.
In the embodiment of the application, the messages interacted between the access equipment and the Portal server are carried by UDP protocol, namely, are UDP messages. The UDP protocol is not connected at the transmission layer, so that the access devices respectively communicate with SocketB corresponding to each Portal server through SocketA. For example, in communication, socketA invokes the send to () function to send a message to the IP address of the Portal server, which receives the message through SocketB.
For example, the Portal server 1 is adapted to an IPv4 network, and the Portal server 2 is also adapted to an IPv4 network. When communicating with the Portal server 1 and the Portal server 2, the access device communicates with SocketB of each of the Portal server 1 and the Portal server 2 through SocketA1 which is the same applicable to the IPv4 network.
It will be appreciated that in the foregoing example, socketA a communicates with each SocketB a of Portal server 1, portal server 2, respectively, to create multiple SSL sessions on SocketA a. For example, socketA carries two SSL sessions, SSL session 1 created with Portal server 1 and SSL session 2 created with Portal server 2, respectively. One DTLS connection is created on each SSL session, i.e. DTLS connection 1 is carried on SSL session 1 and DTLS connection 2 is carried on SSL session 2.
The access device and the target Portal server are connected through the DTLS, the access device sends a first registration message to the NAT device through the DTLS, so that the NAT device can send a second registration message to the target Portal server after carrying out NAT conversion on the first registration message, the target Portal server generates a registration list item according to the second registration message, when the accessed user device initiates a request for accessing network resources, the access device interacts Portal protocol messages with the target Portal server through the DTLS and the NAT device, portal authentication is carried out, and the first registration message, the second registration message and the Portal protocol messages are encrypted messages which are encrypted by utilizing keys and encryption algorithms after key negotiation.
In this way, in the scene of cross-public network transmission between the access equipment and the remote Portal server, the access equipment establishes DTLS connection with the Portal server, so that the transmission after the encryption processing of the Portal protocol messages in the subsequent Portal authentication process is realized. Therefore, the access equipment and the Portal server are easy to butt joint, portal authentication is safer, and the access equipment utilizes a single Socket communication multi-session DTLS mode, so that the management cost of maintaining a large number of Socket communication by the Portal server is reduced while safety is brought. The method also solves the problem that in the existing Portal authentication process, because the protocol message is carried by the UDP message and the UDP message is in plaintext interaction, unsafe hidden dangers such as the loss and interception of the protocol message occur.
Based on the same inventive concept, the embodiment of the application also provides a communication device corresponding to the communication method. Referring to fig. 3, fig. 3 is a communication apparatus provided in an embodiment of the present application, where the apparatus is applied to an access device, and the apparatus includes:
An establishing unit 310, configured to perform key negotiation with a target Portal server and establish DTLS connection when the configured policy template is bound;
A sending unit 320, configured to send a first registration message to a NAT device through the DTLS connection, so that the NAT device performs NAT conversion on the first registration message, and then sends a second registration message to the target Portal server, where the target Portal server generates a registry entry according to the second registration message;
The sending unit 320 is further configured to interact a Portal protocol packet with the target Portal server through the DTLS connection and the NAT device and perform Portal authentication when the accessed user equipment initiates a request for accessing a network resource;
the first registration message, the second registration message and the first Portal protocol message are encrypted messages which are encrypted by utilizing the key and the encryption algorithm after the key negotiation.
Optionally, the apparatus further comprises:
a disconnection unit (not shown in the figure) for locally disconnecting the DTLS connection when unbinding the policy template;
The sending unit 320 is further configured to send a first close notification to the NAT device, so that the NAT device performs NAT conversion on the first close notification and then sends a second close notification to the target Portal server, where the target Portal server locally disconnects the DTLS connection according to the second close notification;
the first closing notification and the second closing notification are encrypted messages.
Optionally, the sending unit 320 is further configured to send, through the DTLS connection, a third registration packet to the NAT device, so that the NAT device performs NAT conversion on the third registration packet, and then sends a fourth registration packet to the target Portal server, where the target Portal server updates the registry entry according to the fourth registration packet;
The third registration message and the fourth registration message are encrypted messages which are encrypted by using the key after key negotiation.
Optionally, the apparatus further comprises:
An obtaining unit (not shown in the figure) configured to obtain, from a local mapping relationship table, a mapping relationship table entry matching the IP address of the target Portal server according to the IP address of the target Portal server, where the mapping relationship table entry includes a pointer for pointing to a data structure storing SSL session information;
An access unit (not shown in the figure) for accessing the data structure via the pointer such that a corresponding SSL session is invoked and the DTLS connection is invoked on the SSL session.
Optionally, the establishing unit is further configured to establish Socket communications with at least one Portal server through a local Socket, where the Socket communications carries a plurality of SSL sessions, and each SSL session carries a DTLS connection.
The access device and the target Portal server are connected through the DTLS, the access device sends a first registration message to the NAT device through the DTLS, so that the NAT device can send a second registration message to the target Portal server after carrying out NAT conversion on the first registration message, the target Portal server generates a registration list item according to the second registration message, when the accessed user device initiates a request for accessing network resources, the access device and the target Portal server interact Portal protocol messages through the DTLS and the NAT device, portal authentication is carried out, and the first registration message, the second registration message and the Portal protocol messages are encrypted messages which are encrypted by utilizing a key and an encryption algorithm after key negotiation.
In this way, in the scene of cross-public network transmission between the access equipment and the remote Portal server, the access equipment establishes DTLS connection with the Portal server, so that the transmission after the encryption processing of the Portal protocol messages in the subsequent Portal authentication process is realized. Therefore, the access equipment and the Portal server are easy to butt joint, portal authentication is safer, and the access equipment utilizes a single Socket communication multi-session DTLS mode, so that the management cost of maintaining a large number of Socket communication by the Portal server is reduced while safety is brought. The method also solves the problem that in the existing Portal authentication process, because the protocol message is carried by the UDP message and the UDP message is in plaintext interaction, unsafe hidden dangers such as the loss and interception of the protocol message occur.
Based on the same inventive concept, the embodiment of the present application also provides a network device, as shown in fig. 4, including a processor 410, a transceiver 420, and a machine-readable storage medium 430, where the machine-readable storage medium 430 stores machine executable instructions capable of being executed by the processor 410, and the processor 410 is caused to perform the communication method provided by the embodiment of the present application by the machine executable instructions. The communication device shown in fig. 3 may be implemented by using a hardware structure of a network device as shown in fig. 4.
The computer readable storage medium 430 may include a random access Memory (english: random Access Memory, abbreviated as RAM) or a nonvolatile Memory (english: non-volatile Memory, abbreviated as NVM), such as at least one magnetic disk Memory. Optionally, the computer readable storage medium 430 may also be at least one storage device located remotely from the aforementioned processor 410.
The Processor 410 may be a general-purpose Processor including a central processing unit (Central Processing Unit, abbreviated as CPU), a network Processor (Network Processor, abbreviated as NP), a digital signal Processor (DIGITAL SIGNAL Processor, abbreviated as DSP), an Application-specific integrated Circuit (ASIC), a Field-Programmable gate array (GATE ARRAY, abbreviated as FPGA), a discrete gate or transistor logic device, or a discrete hardware component.
In an embodiment of the present application, processor 410 is enabled to implement the processor 410 itself and invoke transceiver 420 to perform the communication method described in the previous embodiment of the present application by reading machine-executable instructions stored in machine-readable storage medium 430.
Additionally, embodiments of the present application provide a machine-readable storage medium 430, the machine-readable storage medium 430 storing machine-executable instructions that, when invoked and executed by the processor 410, cause the processor 410 itself and the invoking transceiver 420 to perform the communication methods described in the foregoing embodiments of the present application.
The implementation process of the functions and roles of each unit in the above device is specifically shown in the implementation process of the corresponding steps in the above method, and will not be described herein again.
For the device embodiments, reference is made to the description of the method embodiments for the relevant points, since they essentially correspond to the method embodiments. The apparatus embodiments described above are merely illustrative, wherein the elements illustrated as separate elements may or may not be physically separate, and the elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purposes of the present application. Those of ordinary skill in the art will understand and implement the present application without undue burden.
For the communication device and the machine-readable storage medium embodiments, since the method content involved is substantially similar to the method embodiments described above, the description is relatively simple, and reference will only be made to part of the description of the method embodiments.
The foregoing description of the preferred embodiments of the application is not intended to be limiting, but rather to enable any modification, equivalent replacement, improvement or the like to be made within the spirit and principles of the application.
Claims (10)
1. A method of communication, the method being applied to an access device, the method comprising:
When the configured policy template is bound, key negotiation is carried out with a target Portal server, and DTLS connection is established;
Sending a first registration message to NAT equipment through the DTLS connection, so that the NAT equipment carries out NAT conversion on the first registration message and then sends a second registration message to the target Portal server, and the target Portal server generates a registry item according to the second registration message;
When the accessed user equipment initiates a request for accessing network resources, a Portal protocol message is interacted with the target Portal server through the DTLS connection and the NAT equipment, and Portal authentication is performed;
the first registration message, the second registration message and the Portal protocol message are encrypted messages which are encrypted by using the key and the encryption algorithm after the key negotiation.
2. The method according to claim 1, wherein the method further comprises:
when the strategy template is unbinding, the DTLS connection is disconnected locally;
Sending a first closing notification to the NAT equipment, so that the NAT equipment performs NAT conversion on the first closing notification and then sends a second closing notification to the target Portal server, and the target Portal server locally disconnects the DTLS according to the second closing notification;
the first closing notification and the second closing notification are encrypted messages.
3. The method according to claim 1, wherein the method further comprises:
Sending a third registration message to the NAT equipment through the DTLS connection, so that the NAT equipment carries out NAT conversion on the third registration message and then sends a fourth registration message to the target Portal server, and the target Portal server updates the registry item according to the fourth registration message;
The third registration message and the fourth registration message are encrypted messages which are encrypted by using the key after key negotiation.
4. The method of claim 1, wherein prior to sending the first registration message to the NAT device over the DTLS connection, the method further comprises:
According to the IP address of the target Portal server, a mapping relation table item matched with the IP address of the target Portal server is obtained from a local mapping relation table, and the mapping relation table item comprises a pointer for pointing to a data structure for storing SSL session information;
and accessing the data structure through the pointer so as to call a corresponding SSL session and call the DTLS connection on the SSL session.
5. The method according to claim 4, wherein the method further comprises:
And establishing Socket communication with at least one Portal server through a local Socket, wherein the Socket communication carries a plurality of SSL sessions, and each SSL session carries a DTLS connection.
6. A communication apparatus, the apparatus being applied to an access device, the apparatus comprising:
The establishing unit is used for carrying out key negotiation with the target Portal server and establishing DTLS connection when the configured strategy template is bound;
a sending unit, configured to send a first registration message to a NAT device through the DTLS connection, so that the NAT device performs NAT conversion on the first registration message and then sends a second registration message to the target Portal server, where the target Portal server generates a registry entry according to the second registration message;
The sending unit is further configured to interact a Portal protocol packet with the target Portal server through the DTLS connection and the NAT device and perform Portal authentication when the accessed user equipment initiates a request for accessing a network resource;
the first registration message, the second registration message and the Portal protocol message are encrypted messages which are encrypted by using the key and the encryption algorithm after the key negotiation.
7. The apparatus of claim 6, wherein the apparatus further comprises:
The disconnection unit is used for locally disconnecting the DTLS connection when the strategy template is unbound;
The sending unit is further configured to send a first close notification to the NAT device, so that the NAT device performs NAT conversion on the first close notification and then sends a second close notification to the target Portal server, where the target Portal server locally disconnects the DTLS connection according to the second close notification;
the first closing notification and the second closing notification are encrypted messages.
8. The apparatus of claim 6, wherein the sending unit is further configured to send a third registration packet to the NAT device through the DTLS connection, so that the NAT device performs NAT conversion on the third registration packet and then sends a fourth registration packet to the target Portal server, and the target Portal server updates the registry key according to the fourth registration packet;
The third registration message and the fourth registration message are encrypted messages which are encrypted by using the key after key negotiation.
9. The apparatus of claim 6, wherein the apparatus further comprises:
The acquisition unit is used for acquiring a mapping relation table item matched with the IP address of the target Portal server from a local mapping relation table according to the IP address of the target Portal server, wherein the mapping relation table item comprises a pointer used for pointing to a data structure for storing SSL session information;
And the access unit is used for accessing the data structure through the pointer so as to call the corresponding SSL session and call the DTLS connection on the SSL session.
10. The apparatus of claim 9, wherein the establishing unit is further configured to establish Socket communications with at least one Portal server through a local Socket, where Socket communications carry a plurality of SSL sessions, and each SSL session carries a DTLS connection.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202411580117.1A CN119561998A (en) | 2024-11-06 | 2024-11-06 | Communication method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202411580117.1A CN119561998A (en) | 2024-11-06 | 2024-11-06 | Communication method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN119561998A true CN119561998A (en) | 2025-03-04 |
Family
ID=94745461
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202411580117.1A Pending CN119561998A (en) | 2024-11-06 | 2024-11-06 | Communication method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN119561998A (en) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20110231652A1 (en) * | 2010-03-19 | 2011-09-22 | F5 Networks, Inc. | Proxy ssl authentication in split ssl for client-side proxy agent resources with content insertion |
| CN107534658A (en) * | 2015-03-16 | 2018-01-02 | 康维达无线有限责任公司 | End-to-end authentication at the service layer using public key mechanisms |
| WO2018019069A1 (en) * | 2016-07-25 | 2018-02-01 | 华为技术有限公司 | Resource operation method and apparatus |
| CN109067729A (en) * | 2018-07-26 | 2018-12-21 | 新华三技术有限公司 | A kind of authentication method and device |
| CN110383788A (en) * | 2017-03-07 | 2019-10-25 | 西门子股份公司 | Method and security element for executing one or more applications for secure data exchange with one or more servers providing web services, in particular for IoT devices |
| CN110719248A (en) * | 2018-07-12 | 2020-01-21 | 中移（杭州）信息技术有限公司 | Method and device for forwarding user datagram protocol message |
| CN116886334A (en) * | 2023-06-09 | 2023-10-13 | 福建新大陆通信科技股份有限公司 | Lightweight CoAP secure communication method and system based on DTLS |
-
2024
- 2024-11-06 CN CN202411580117.1A patent/CN119561998A/en active Pending
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20110231652A1 (en) * | 2010-03-19 | 2011-09-22 | F5 Networks, Inc. | Proxy ssl authentication in split ssl for client-side proxy agent resources with content insertion |
| CN107534658A (en) * | 2015-03-16 | 2018-01-02 | 康维达无线有限责任公司 | End-to-end authentication at the service layer using public key mechanisms |
| WO2018019069A1 (en) * | 2016-07-25 | 2018-02-01 | 华为技术有限公司 | Resource operation method and apparatus |
| CN110383788A (en) * | 2017-03-07 | 2019-10-25 | 西门子股份公司 | Method and security element for executing one or more applications for secure data exchange with one or more servers providing web services, in particular for IoT devices |
| CN110719248A (en) * | 2018-07-12 | 2020-01-21 | 中移（杭州）信息技术有限公司 | Method and device for forwarding user datagram protocol message |
| CN109067729A (en) * | 2018-07-26 | 2018-12-21 | 新华三技术有限公司 | A kind of authentication method and device |
| CN116886334A (en) * | 2023-06-09 | 2023-10-13 | 福建新大陆通信科技股份有限公司 | Lightweight CoAP secure communication method and system based on DTLS |
Non-Patent Citations (1)
| Title |
|---|
| 韦俊琳;段海新;万涛;: "HTTPS/TLS协议设计和实现中的安全缺陷综述", 信息安全学报, no. 02, 15 March 2018 (2018-03-15) * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8214635B2 (en) | Transparent proxy of encrypted sessions | |
| EP3142327B1 (en) | Intermediate network entity | |
| US8549614B2 (en) | Establishing internet protocol security sessions using the extensible messaging and presence protocol | |
| US9398026B1 (en) | Method for authenticated communications incorporating intermediary appliances | |
| US9350708B2 (en) | System and method for providing secured access to services | |
| US10084888B2 (en) | Method and apparatus for accelerating web service with proxy server | |
| US7222234B2 (en) | Method for key agreement for a cryptographic secure point—to—multipoint connection | |
| US9350711B2 (en) | Data transmission method, system, and apparatus | |
| KR100948604B1 (en) | Security Method in Server-based Mobile Internet Protocol System | |
| CN101299667A (en) | Authentication method, system, client equipment and server | |
| CN108200104A (en) | The method and system that a kind of progress SSL shakes hands | |
| CN106169952B (en) | A kind of authentication method that internet Key Management Protocol is negotiated again and device | |
| WO2009082950A1 (en) | Key distribution method, device and system | |
| US20180183584A1 (en) | IKE Negotiation Control Method, Device and System | |
| Taylor et al. | Validating security protocols with cloud-based middleboxes | |
| CN114760093A (en) | Communication method and device | |
| CN119561998A (en) | Communication method and device | |
| Matama et al. | Extension mechanism of overlay network protocol to support digital authenticates | |
| Khandkar et al. | Masking host identity on internet: Encrypted TLS/SSL handshake | |
| CN116938603B (en) | Traffic transmission method, device, equipment and storage medium based on stealth gateway | |
| KR102086489B1 (en) | Method for decrypting a secure socket layer for securing packets transmitted from a predetermined operating system | |
| Korhonen et al. | Mobile IPv6 security framework using transport layer security for communication between the mobile node and home agent | |
| CN117527752A (en) | NAT penetration method based on third party assisted TLS protocol | |
| Grochla et al. | Extending the TLS protocol by EAP handshake to build a security architecture for heterogenous wireless network | |
| Kimura et al. | Secure connection re-establishment for session-based IP mobility |
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 |