[Dr.WoW] [No.39] SSL VPN Mechanisms -part 1

Latest reply: Aug 28, 2018 18:21:06 3109 5 1 0

1 Advantages of SSL VPN

The Internet has developed in a fast, unpredictable manner, and it can now be said that "network connections are available anywhere, anytime". Although PCs and laptops are ubiquitous, these are already being looked down upon as being too heavy and inconvenient, and everyone now has a smart phone or tablet, allowing them to enjoy anytime/anywhere Internet access. The times are ever changing, and advances in science and technology continue to be made, but what remains the same is the concept that science and technology are people-centricpeople are looking for more convenience, simplicity and security. For specific use scenarios involving remote connections and access to internal networks, a few cracks have appeared in the leading traditional VPN technology, IPSec:

l   Inflexible networking. When constructing an IPSec VPN, if equipment is added or the user's IPSec policy is altered, the existing IPSec configuration needs to be adjusted.

l   Client software needs to be installed for IPSec VPNs, leading to a good deal of trouble in terms of compatibility, deployment and maintenance.

l   IPSec is not strict enough regarding user access control; IPSec can only undertake network layer control, but is unable to conduct granular access control of application layer resources.

As the saying goes, "there is a way up every mountain; if there's a problem there must be a solution", and accordingly a new kind of technology has begun to take center stage: Secure Sockets Layer VPN (SSL VPN), a new lightweight remote access solution, effectively solves the aforementioned problems, and has very broad application in real-world remote access solutions.

l   SSL VPN operates between the transport layer and the application layer, and does not change IP or TCP headers or impact the existing network topology. If a firewall is deployed in the network, an SSL VPN only requires that the traditional HTTPS (port 443) be enabled on the firewall.

l   SSL VPN uses the browser/server (B/S) architecture. Therefore, SSL VPN does not require client applications, and only requires a browser for ease of use.


Although SSL VPN does not require the installation of additional clients, SSL VPN features have explicit requirements regarding the browser and operating system type and version. For specific requirements please review product documents.

l   More importantly, compared with IPSec network layer control, all access control in an SSL VPN is based in the application layer, and the level of granularity can reach the URL or file levels, which can greatly improve the security of remote access.

Below I, Dr. WoW, will take everyone on a detailed introduction of SSL VPN technology.

2 SSL VPN Use Scenarios

So-called SSL VPN technology is actually a name created by VPN vendors, and refers to remotely connected users using the SSL function embedded in standard Web browsers to connect to an SSL VPN server on an enterprise intranet, following which the SSL VPN server can forward packets to a specific internal server, thereby allowing remotely connected users to access specially designated server resources within the company after passing authentication. In this scenario, remotely connected users and SSL VPN servers use the standard SSL protocol to encrypt data transmitted between them―this amounts to establishing a tunnel between the remotely connected user and the SSL VPN server.

Generally speaking, SSL VPN servers are deployed behind firewalls at the egress; the typical use scenario for SSL VPN is shown in Figure 1-1.

Figure 1-1 Typical use scenario for SSL VPN



Remotely connected users will hereinafter be called "remote users."

Huawei's USG2000/5000/6000 families of firewalls can serve directly as SSL VPN servers, conserving network construction and administration costs. While I have the opportunity, let me get a word in on behalf of Huawei, which has released the specialized SVN2000 and SVN5000 series of SSL VPN server products. These provide support for higher numbers of users, and support SSL VPN solutions for even greater numbers of use scenarios.

In this section, I will primarily introduce the establishment of a connection between remote users and an SSL VPN server, as well as the process of successfully logging in to the SSL VPN server. How SSL VPN servers forward remote user requests to various internal servers will be introduced in subsequent sections.

Before beginning a rather dull, theoretical introduction, I will provide a demonstration of the steps involved in logging in to an SSL VPN server, so that the ease and convenience of SSL VPNs can be observed visually.

The steps typically involved in remote user access of an SSL VPN server are extremely simple, as shown in Table 1-1.

Table 1-1 Steps for remote user access of an SSL VPN server


Detailed description


Open a browser, enter the https://SSL VPN server address: port or https://domain, to initiate a connection.


The web page may give a reminder that there is a problem with the security certificate for the website about to be accessed, but we'll select "continue to this website."


The SSL server login interface successfully appears. The interface's right side requests for the user name/password to be input.


Input the user name/password (previously obtained from the enterprise network administrator), successfully log in to the SSL VPN server, and enter the intranet resources access page.


Can these few steps guarantee the establishment of an SSL VPN connection and secure access? Why is there a reminder that there is a problem with the security certificate of the web address to be accessed? I'm sure there are many questions swirling around in everyone's minds now. With these questions in mind, we'll explore how remote users exchange packets with the SSL VPN server in these few brief steps.

I believe there are two keys involved in this, which also display two basic security features of SSL VPN technology:

1.         Security of the transmission process

In the aforesaid definition of SSL VPN, we mentioned that remote users and SSL VPN servers use the standard SSL protocol to encrypt data transmitted between them. The SSL protocol begins operating from when a user opens his/her browser and accesses the SSL VPN server address. Therefore, we need to explore the mechanisms through which the SSL protocol operates in more detail.

2.         Security of user identities.

In the above demonstration of logging in to SSL VPN servers, the remote user accessed the SSL VPN server's login interface, and the SSL VPN server requested that the user name/password be input. This is actually the SSL VPN server requesting authentication of the user's identity. SSL VPN servers generally support multiple kinds of user authentication methods to guarantee the security and legitimacy of access. Huawei's firewalls support multiple methods for authenticating user names/passwords, including local authentication, server authentication, certificate authentication, two-factor authentication (user name/password + certificate), etc.

3 SSL Protocol Operating Mechanisms

SSL is a kind of protocol that establishes a secure path between clients and servers. It is a Web application-based security protocol developed by the Netscape company, and provides data encryption, server authentication, information integrity and optional client authentication for application protocols based in TCP/IP connections (such as HTTP, Telnet and FTP, etc.). This is to say that the SSL protocol has the following features:

l   All data to be transmitted is encrypted for transmission, so that third parties cannot eavesdrop.

l   It possesses verification mechanisms, so the two communicating parties will immediately discover any information tampering.

l   It's equipped with an identity certificate to prevent identities from being forged.

The SSL protocol has been developed continuously since being released in 1994. The SSL 2.0 and SSL 3.0 versions released by the Netscape company have been broadly used. Following these, an Internet standardization organization released the TLS 1.0 protocol (also known as SSL 3.1) based in SSL 3.0, and later also released the TLS1.1 and TLS 1.2 versions. At present, most mainstream browsers now support TLS 1.2. Huawei's firewalls support the SSL 2.0, SSL 3.0 and TLS 1.0 versions.

The SSL protocol's structure is made up of two layers. The lower layer is the SSL record protocol, and the higher layer has the SSL handshake protocol, the SSL change cipher spec protocol and the SSL alert protocol; the roles of each protocol are as shown in Figure 1-2.

Figure 1-2 SSL protocol structure and uses



It's thus obvious that the establishment of an SSL connection primarily relies on the SSL handshake protocol, and below we'll explore the SSL handshake protocol in detail.

The SSL handshake protocol's basic design approach can be summarized in a brief sentence: it transmits ciphertext using a public key encryption algorithm. Or, to put things another way, the server tells its public key to the client, the client then uses the server's public key to encrypt information, and after the server receives the ciphertext, it uses its own private key for decryption.


There are two problems with this design approach which require further refined solutions:

1.         When the server tells its public key to the client, how can it be guaranteed that the public key has not been tampered with?

Solution: incorporate a digital certificate. Input the server's public key into the server certificate, with the server sending the certificate to the client. So long as the certificate is trustworthy, the public key can be trusted.

2.         The security of the public key encryption algorithm is high, however, as the two terminal devices each use private keys for decryption, the algorithm is relatively complicated, and the computing usage for encryption and decryption is high―how can efficiency be increased?

Solution: incorporate a new "session key". The client and server negotiate the "session key" using a public key encryption algorithm, and subsequent data packets all use this "session key" for encryption and decryption (this is also known as a symmetric encryption algorithm). The computing speed is very fast when using a symmetric encryption algorithm, allowing for a great increase in the computing efficiency of encryption and decryption.

To explain things further, "the session key" is actually a secret key shared by the server and the client. It is called the "session key" because it incorporates the concept of a session. Every TCP-based SSL connection is associated with a session, and the session is created by the SSL handshake protocol. This provides complete transmission encryption for each connection, and means that the handshake process is included in the session.

Since the design of the SSL handshake protocol has already resolved the key questions, below we'll cover specific design details: the aforementioned design approach is achieved through four communications between the server and the client, thereby ensuring that highly efficient, secure encrypted packet transmission can be conducted following the handshake stage.

The specific content of the four communications involved in the SSL handshake is shown in Figure 1-3. It is important to note that all communications in this stage are cleartext.

Figure 1-3 SSL Handshake process


3.         Client sends request (Client Hello)

The client (generally the browser) first sends an encrypted communication request to the server. The primary information provided to the server in this step is as follows:

(1)      The protocol version supported, for example TLS version 1.0.

(2)      A random number generated by the client, to be used a bit later in generating the "session key".

4.         Server's response (Server Hello)

After receiving the client's request, the server sends a response to the client. This step includes the following information:

(1)      Confirmation of the version of the cryptographic communication protocol being used, for example TLS version 1.0. If the version supported by the browser and the server are not the same, then the server closes encrypted communication.

(2)      A random number generated by the server, to be used a bit later in generating the "session key".

(3)      Confirmation of the cipher suite.

(4)      A server certificate that contains the server's public key.


The SSL handshake protocol supports two-directional authentication between the client and the server. If the server needs to verify the client, the server must send a certificate authentication request regarding the client in this step.

5.         Client Response

After the client receives the server's response, it first authenticates the server's certificate. If the certificate has not been issued by a trustworthy institution, or if the certificate's domain name and the real domain name are not the same, or if the certificate has expired, then it will display an alert in which a choice can be made as to whether or not to continue the communication. If there is no problem with the certificate, the client will extract the server's public key from the certificate. Following this it will send the following three items of information to the server:

(1)      A pre-master key made up of random numbers, encrypted using the server's public key. This prevents eavesdropping, and the pre-master-key will be used a momentarily to generate the "session key". At this time the client will have three random numbers, and can compute the "session key" to be used for this session.

(2)      A change cipher spec notice, expressing that all future information will be sent using the encryption method and private key negotiated by the two parties.

(3)      The client's handshake finish notice, expressing that the client's handshake stage has already been concluded. At the same time as this is the HASH value for all content sent previously, used for server authentication.

6.         The server's final response

After the server receives the client's random pre-master key, it computes and generates the "session key" to be used for this session (the computing method and computed results are the same as the client's). Following this, the below, final information is sent to the client:

(1)      A change cipher spec notice, expressing that future information will all be sent using the encryption method and secret key negotiated by the two parties.

(2)      The server handshake finish message, expressing the server's handshake stage.

Now that everyone has finished reviewing the specific content of the SSL handshake protocol's four communications, I think it likely that some additional questions have arisen. As always, I'm ready to serve:

(1)      When the random pre-master-key appears, the client and server already have three random numbers, and the two then use the previously negotiated encryption method to each generate the same "session key" to be used in this session. Why do three random numbers need to be used to generate the "session key"?

Answer: It is clear that the public key encryption algorithm's use of the three random numbers in obtaining the final symmetric secret key is done in order to increase security. The reason the pre-master-key exists is because the SSL protocol does not trust that every host will be able to generate "completely random" random numbers. If the random numbers are not random, then it may be possible to infer them, creating security problems. And, three 'false random numbers' gathered together are extremely close to being random.

(2)      During the SSL handshake protocol's second communication, when the server responds (server hello), it sends its own certificate, and the client immediately conducts verification of the servers' certificate; this is to say that the client verifies the servers' legitimacy. Is this related to the alert encountered in 1.Figure 1-1Table 1-1 when we were demonstrating logging in into the SSL VPN server that "there is a problem with this website's security certificate"?

Answer: Actually, the SSL protocol begins to operate from when the client (the remote user) accesses the SSL VPN server through HTTPS in step 1 of 1.Figure 1-1Table 1-1. The notice in step 2 just happens to correspond with the second communication of the SSL handshake protocol―at this time the server sends its own local certificate to the client, and the client needs to conduct authentication of the server's certificate. The appearance of the alert indicates that the client believes this server's certificate is not trustworthy. If this reminder appears during our everyday access to online banking and other similar interfaces, we need to increase our vigilance to prevent mistakenly entering phishing websites. However, we'll choose to mandate trust for this website for now.


My explanation of the SSL handshake protocol's operating mechanisms is now complete. Take a deep breath―we still need to test the principles behind this from a practical standpoint.

                               Step 1     Use a firewall as the SSL VPN server and complete related configuration on the firewall.

SSL server functionality on a firewall is called a virtual gateway. The virtual gateway's address/domain name is the SSL VPN server's address/domain name.

a.          Configure the virtual gateway, enable the SSL VPN server function, configure the server address, etc.

b.         Configure the authentication authorization method as local authentication, and create the user (including configuring the user name and password.)

c.          Configure security policies to guarantee network interworking. We will introduce methods for configuring security policies in " 8.7 Configuring security policies."

                               Step 2     Follow the steps provided at the beginning of this chapter demonstrating client login to the SSL VPN server, and use the configured user name/password to log in to the SSL VPN server.

a.          Client initiates a connection request using an IE browser to the firewall's virtual gateway In the figure below, numbers 21-29 show the entire four-communication SSL handshake process. After the server replies with its Server Finished Message (already encrypted; there is a note that this is an encrypted handshake message) in No. 29, the alert interface stating that the security certificate has a problem appears. At this point, the client and server have actually not begun normal communication, but are in the SSL handshake stage. The client has verified that the server is not legitimate, and the client's Web interface has asked the user whether or not they want to continue browsing this website.


b.         To mandate trust, select "continue to this website". Beginning with No. 103, the client requests to use a new session, and again initiates the SSL handshake protocol. After handshake completion, normal encrypted communication is begun, and continues until the user's browser successfully loads the firewall's virtual gateway's user login interface.


c.          The user name/password are entered. Beginning with No. 1561, SSL handshake protocol initiation is continued. Following the four communications, the "session key" is negotiated, and beginning with the packet carrying the user name/password, all data between the user and the server is encrypted (shown as 'Application Data') and sent to the server.






To view the list of all Dr. WoW technical posts, click here.

  • x
  • convention:

Created Sep 23, 2015 09:41:07 Helpful(0) Helpful(0)

Thank you for sharing.
  • x
  • convention:

Created Aug 15, 2018 11:38:00 Helpful(0) Helpful(0)

Some pictures/figures can't be loaded on this post :(
  • x
  • convention:

MVE Created Aug 15, 2018 13:21:50 Helpful(0) Helpful(0)

very useful
thank you
  • x
  • convention:

Created Aug 15, 2018 13:29:14 Helpful(0) Helpful(0)

This is a very interesting and complete post, thanks for sharing @dr.wow

I notice that some pictures has an error, could you fix them?
  • x
  • convention:


Héctor R. Azcanio
Created Aug 28, 2018 18:21:06 Helpful(0) Helpful(0)

thanks Dr. Wow
  • x
  • convention:



You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits