SSL works to ensure that traffic between a client and server is secure. However, its encryption feature can sometimes confound firewalls, creating a potential security threat for your network. Here's how SSL bridging can help solve the problem.
The Secure Sockets Layer (SSL) protocol was originally developed by Netscape and became a standard for sending information privately via a Web browser. SSL is popular for protecting the transmission of confidential information such as credit card numbers and financial data over the Internet. You can recognize an SSL connection because the URL begins with HTTPS and the browser typically shows a padlock in the status bar after the SSL session is established.
While SSL ensures a secure connection between client and server, the encrypted connection can pose a security problem for firewall administrators. SSL bridging addresses this problem, providing a way for a firewall to inspect the data inside the SSL tunnel, while still maintaining the security of the connection. Here's how SSL bridging works and how firewalls deal with it.
The problem with allowing SSL through the firewall
Traditional hardware packet filter-based firewalls are still popular on today's networks. Simple packet filter-based firewalls use information such as the source and destination IP address, source and destination TCP and UDP ports, and ICMP types and codes to control access into and out of the corporate network.
How stateful packet-filtering firewalls work
Modern stateful packet-inspection (SPI) firewalls (also known as stateful filtering and dynamic packet-filtering firewalls) notch up security by tracking session state or pseudo-state. Since the TCP protocol is a session-based protocol, the transport layer header includes important information about the state of the connection. The SPI firewall can use the transport layer state information to prevent exploits such as session hijacking and denial of service attacks.
In contrast to TCP, the UDP transport protocol does not establish and maintain session state. UDP state is managed by the application and server using the UDP protocol. However, SPI firewalls can apply a pseudo-state to maintain the integrity of UDP-based communications.
While SPI firewalls provided adequate security against the types of network attacks that were common in the 1990s, the vast majority of attacks seen today do not operate at the network or transport layer. Instead, they operate at the application layer. Today's attackers are more concerned about obtaining or destroying data on vulnerable servers located behind the firewall.
This presents a big problem. For the SPI firewall, a connection is considered legitimate as long as the source and destination addresses, ports, and state are valid. The SPI firewall is completely unaware of what's happening at the application layer.
If you host Web resources on your network behind the corporate SPI firewall, this leaves you vulnerable. Suppose you host a secure Web server located behind your SPI firewall, and a hacker launches an attack against your secure Web server. The SPI firewall would check the source and destination addresses and port, confirm the state of the connection, and pass the attacker's commands to the secure Web server. The attack succeeds because the SPI firewall is unaware of whatï¿?s happening at the application layer.
Enhanced SPI firewalls with rudimentary application-layer inspection
SPI firewall vendors are aware of major weaknesses inherent in packet-filtering firewalls. Some modern hardware firewall vendors have enhanced their SPI firewall offerings by including some rudimentary application-layer inspection mechanisms. This allows the SPI firewall not only to provide network and transport-layer security, but to also provide a degree of protection at the application layer.
However, many hardware firewalls that include some measure of stateful application-layer inspection are helpless to protect against attacks made through an encrypted channel. For example, suppose your organization uses a SPI firewall that also performs application-layer inspection on incoming HTTP connections. The firewall performs well in preventing attacks against your non-SSL sites, but you find that your SSL sites have been compromised on numerous occasions. Why?
The problem is that the SPI firewall with basic stateful application-layer inspection mechanisms is unable to inspect what happens in the encrypted channel. When the attacker connects to the secure Web site behind the corporate SPI firewall, the firewall can inspect only the initial CONNECT request. Once the SSL session is established between the attacker and the secure Web server, all application-layer information is completely hidden from the firewall. The attacker is able to send exploit commands and data within the secure channel, and there's nothing that the average SPI firewall can do about it.
How SSL bridging solves the problem
Some firewalls, such as ISA Server 2004, act as both a stateful packet and application-layer inspection firewall, solving this problem using the SSL to SSL bridging function. SSL to SSL bridging both provides the security of an end-to-end encrypted connection and allows the ISA firewall to perform stateful application-layer inspection on the HTTP data and commands passing from client to servers through the firewall.
The ISA firewall acts as a "bridge" between the SSL client and the SSL server. In order to bridge the connection, the ISA firewall impersonates the Web site by presenting a Web site certificate to the Web client. The Web client then establishes an SSL link between itself and the public interface of the ISA firewall. The ISA firewall then decrypts the session and exposes the application-layer data and commands to its HTTP stateful application-layer inspection engine (the HTTP Security Filter).
If the HTTP communications are suspect at the application layer, the ISA firewall blocks the suspect commands or data. If the HTTP Security Filter finds the communications to be valid, a second SSL session is established between the ISA firewallï¿?s corporate network interface and the secure Web server on the protected network. This provides secure communications from end to end while still enabling the ISA firewall to fully inspect the communication at the application layer. It's the best of both worlds.
Check with your firewall vendor
SSL to SSL bridging is a great feature that allows the firewall to inspect the contents of SSL-encrypted communications, so attackers can't hide malicious code within the SSL tunnel. If users on your network are relying on secured communications using SSL, this is an important addition to your security protocols.