Chương 8. M ạ ng riêng ả o – Virtual Private Network
8.2.4 Application Layer-Based Components of a VPN Solution
Many firewalls provide application gateways. This technique requires the firewall to be aware of those applications that it will permit to flow across the boundary of a corporate intranet. The user connects to the firewall, which terminates the application. Then, the firewall launches another copy of the same application, running it between itself and the external destination. The firewall then provides synchronization between the internal application (user-to-firewall) and the external application (firewall-to-destination).
8.2.4.1 SOCKS
A circuit level gateway relays TCP and also UDP connections and does not provide any extra packet processing or filtering. A circuit level gateway is a special type of application level gateway. This is because the application level gateway can be configured to pass all information once the user is authenticated, just as the circuit level gateway (see Figure 449). However, in practice, there are significant differences between them:
• Circuit level gateways can handle several TCP/IP applications as well as UDP applications without any extra modifications on the client side for each
application. Thus, this makes circuit level gateways a good choice to satisfy user requirements.
• Circuit level gateways do not provide packet processing or filtering. Thus, a circuit level gateway is generally referred to as a transparent gateway.
• Application level gateways have a lack of support for UDP.
• Circuit level gateways are often used for outbound connections, whereas application level gateways (proxy) are used for both inbound and outbound connections. Generally, in cases of using both types combined, circuit level gateways can be used for outbound connections and application level gateways can be used for inbound connections to satisfy both security and user requirements.
A well-known example of a circuit level gateway is SOCKS. Because data that flows over SOCKS is not monitored or filtered, a security problem may arise. To minimize the security problems, trusted services and resources should be used
on the outside network (untrusted network).
SOCKS is a standard for circuit level gateways. It does not require the overhead of a more conventional proxy server where a user has to consciously connect to the firewall first before requesting the second connection to the destination. The user starts a client application with the destination server IP address. Instead of directly starting a session with the destination server, the client initiates a session to the SOCKS server on the firewall. The SOCKS server then validates that the source address and user ID are permitted to establish onward connection into the nonsecure network, and then creates the second session.
SOCKS needs to have new versions of the client code (called SOCKSified clients) and a separate set of configuration profiles on the firewall. However, the server machine does not need modification; indeed it is unaware that the session is being relayed by the SOCKS server. Both the client and the SOCKS server need to have SOCKS code. The SOCKS server acts as an application level router between the client and the real application server. SOCKSv4 is for outbound TCP sessions only. It is simpler for the private network user, but does not have secure password delivery so it is not intended for sessions between public network users and private network applications. SOCKSv5 provides for several authentication methods and can therefore be used for inbound
connections as well, though these should be used with caution. SOCKSv5 also supports UDP-based applications and protocols.
The majority of Web browsers are SOCKSified and you can get SOCKSified TCP/IP stacks for most platforms.
8.2.4.2 Secure Sockets Layer (SSL) and Transport Layer Security (TLS)
SSL is a security protocol that was developed by Netscape Communications Corporation, along with RSA Data Security, Inc. The primary goal of the SSL protocol is to provide a private channel between communicating applications, which ensures privacy of data, authentication of the partners and integrity.
SSL provides an alternative to the standard TCP/IP socket API that has security implemented within it. Hence, in theory it is possible to run any TCP/IP
application in a secure way without changing the application. In practice, SSL is only widely implemented for HTTP connections, but Netscape Communications Corporation has stated an intention to employ it for other application types, such as Network News Transfer Protocol (NNTP) and Telnet, and there are several
such implementations freely available on the Internet. IBM, for example, is using SSL to enhance security for TN3270 sessions in its Host On-Demand, Personal Communications and Communications Server products, as well as securing configuration access to firewalls.
SSL is composed of two layers:
1. At the lower layer, there is a protocol for transferring data using a variety of predefined cipher and authentication combinations, called the SSL Record Protocol. Figure 45 on page 93 illustrates this, and contrasts it with a standard HTTP socket connection. Note that this diagram shows SSL as providing a simple socket interface, on which other applications can be layered. In reality, current implementations have the socket interface embedded within the application and do not expose an API that other applications can use.
2. At the upper layer, there is a protocol for the initial authentication and transfer of encryption keys, called the SSL Handshake Protocol.
An SSL session is initiated as follows:
• On the client (browser) the user requests a document with a special URL that begins https: instead of http:, either by typing it into the URL input field, or by clicking a link.
• The client code recognizes the SSL request and establishes a connection through TCP port 443 to the SSL code on the server.
• The client then initiates the SSL handshake phase, using the SSL Record Protocol as a carrier. At this point there is no encryption or integrity checking built in to the connection.
The SSL protocol addresses the following security issues:
Privacy: After the symmetric key is established in the initial handshake, the messages are encrypted using this key.
Integrity: Messages contain a message authentication code (MAC) ensuring the message integrity.
Authentication: During the handshake, the client authenticates the server using an asymmetric or public key. It can also be based on
certificates.
SSL requires each message to be encrypted and decrypted and therefore, has a high performance and resource overhead.
Comparing IPSec to SSL
As described in Chapter 3, “Layer-3 VPN protocols” on page 37, IPSec provides cryptographically strong authentication and encryption for IP traffic and also provides for secure and certificate-based key exchange and refresh using IKE.
By deliberately jumping to conclusions, you might suggest that this is essentially the same functionality that SSL and TLS provide as well. In this section we point out the similarities and fundamental differences between IPSec and SSL and explain which are the main areas of use for both protocols.
Both are similar:
• IPSec (via IKE) and SSL provide client and server authentication.
• IPSec and SSL provide data authentication and secrecy, even though on different levels of the protocol stack.
• IPSec and SSL can use cryptographically strong algorithms for encryption and hashing operations and can use certificate-based authentication (IPSec via IKE).
• IPSec (via IKE) and SSL provide key generation and refresh without transmitting any keys in the clear or out of band.
Both are different:
• SSL is implemented as an API between the application and transport layers;
IPSec is implemented as a framework at the internetwork layer.
• SSL provides application-to-application security (for instance, Web browser to Web server), IPSec provides device-to-device security
• SSL does not protect IP headers. This can be an exposure to spoofing and session hijacking attacks. IPSec does protect IP headers.
• SSL does not protect UDP traffic, IPSec does.
• SSL operates end-to-end and has no concept of tunneling. This can be a problem when traffic needs to be examined by content inspection and virus scanning systems before it is delivered to the final destination. IPSec can operate both ways, end-to-end and as a tunnel.
• SSL can traverse NAT or SOCKS which provides for hiding internal addressing structures or to avoid private IP address conflicts. IPSec in transport mode (end-to-end) cannot use NAT for that purpose but it can use an IPSec tunnel to achieve the same goal and provide even more security than NAT because that tunnel can also be encrypted.
• Applications need to be modified to use SSL (become SSL aware). This can be a problem when you do not have access to the application source code, or you do not have the time or expertise to change the application. IPSec is transparent to applications.
Usually, SSL is fine when you have only one application to be secured and that is already available in an SSL-aware version. This is the case with a variety of standard applications nowadays, not only with Web browers and servers. Also, if you have the option of implementing 3-tier concepts by employing Web
application gateways at the perimeter of the network, SSL is a good choice.
If you have a great number of applications to secure you may be better off securing the whole network instead of dealing with each application in turn. In this case, IPSec is truly the better choice. Unless you develop your own applications, IPSec is much more flexible than SSL to implement a security policy that requires different levels and combinations of authentication, encryption and tunneling.
Last but not least, the choice of a proper security technology also depends on the business model. If the purpose of your application servers is to be accessible to the public, then a Web-based design and security technology based on SSL may be the right choice. SSL is available on any standard Web browser and that will be the only tool used and required by the users. In this case, everybody is your potential customer.
If, however, the circle of users who should be given access to your application servers or networks is more restrictive, then a VPN based on IPSec and maybe some layer-2 tunneling technologies is more likely the way to go. In this case, the participants and their roles in the data interchange are predefined.
Trang 330