# Client-Aware Negotiation for Secure and Efficient Data Transmission
## 3 Methodology
### CAN Based on Redirection  
Redirection means to jump from one website to another. In this manuscript, it refers to a jump from an HTTP site to an HTTPS site. This method is suitable for clients that do not support renegotiation or two-way authentication. Its overall idea is to prove the identity of the client by transmitting some information that does not require encryption and to use this client information to complete the CAN-SEAT strategy. After the server verifies the client's identity, the secure data transmission begins.  
The overall process of this method is similar to the renegotiation-based method. This section briefly describes the different steps: First, the client logs in using the HTTP protocol with the identity information. The server can identify the client by the client's IP and port information, or it can retrieve the information provided by the client from the Uniform Resource Locator (URL). Then, the server sets different secure data transmission schemes according to the client's information. When a client is redirected to a connection using the HTTPS URL, a handshake is first performed, and the server compares the certificate submitted by the client at this time to the identity information in the client information table. If the user's identity information meets the criteria, the handshake completes, and the data transmission begins. For systems that do not require a client to provide a certificate, the identity of the client is not checked. The following provides a feasible example of a practical deployment.  
As shown in Figure 4, we set the redirection that converts the HTTP URL to an HTTPS URL in the Apache configuration file and then specify that the clients can only log in through the HTTP URL and need to provide the client identity in the URL when logging in. After the server receives the connection request of the client, it obtains the URL when the client logs in and obtains the client identity information from the URL. Then, according to the client's identity information, the server sets the corresponding cipher suite. Clients are then redirected to sites using the HTTPS protocol. The next step is to perform a secure handshake, at which point, the client needs to set the corresponding secure transmission scheme for the client. After the first full handshake, the server also needs to match the identity from the certificate submitted by the client at this time with the previous identity information. The client is allowed to log in only if the identity information is consistent. If not, the client will fail to log in. If the server does not require a certificate, the client's identity is not detected. The secure transmission scheme is set according to the client identity information in the URL. The message sequence diagram of CAN based on redirection is similar to CAN based on renegotiation. The first two parts were replaced by three handshakes, while the last two were the same. Therefore, the message exchange procedure is not described here in too much detail.  
Unlike the renegotiation-based method, which involves only SSL modules, the CAN based on redirection involves HTTP modules, as well as SSL modules. The server needs to obtain the URL in the HTTP module and set the cipher suite in the SSL module, so the method needs to coordinate the two modules. The CAN based on renegotiation can obtain the client information in the second handshake because the thread handling the two handshakes does not change. However, the method based on redirection cannot ensure that the two sessions are based on the same process, let alone the thread. This means data cannot be transferred directly between two modules. We solve this problem by storing the information table needed in the shared zone. These tables' data are also cleaned regularly to avoid increasing retrieval time due to there being too much information.