How many times have we encountered Web sites that reassure us about their security just because they use SSL? We see statements such as, "Your transactions are protected by SSL." What does this statement really mean? Does SSL really secure sites against hackers? Let's take a closer look at what SSL really secures, how hackers can sometimes launch attacks through SSL, and how, as a countermeasure, administrators can audit and monitor SSL-enabled sites.
The Secure Sockets Layer (SSL) protocol encrypts data in transit between browsers and Web servers. The encryption prevents eavesdroppers from viewing session data such as passwords or credit card numbers. Virtually all Web servers that process sensitive information, financial data, or require authentication use SSL encryption. (When you see https in the URL of your Web browser, you are accessing an SSL-enabled Web server.)
Myth: SSL secures hosts or applications
SSL is not designed to secure operating systems; rather, it is designed to secure data in transit. Think of SSL as a "cryptographic pipe" between the Web browser and the Web server. This pipe encrypts data as it flows back and forth between the user and the Web site. SSL does not eradicate or mitigate vulnerabilities on the Web server. Behind the SSL pipe lie the same Web server programs, Web applications, CGI scripts, and back-end databases as on normal, non-SSL-enabled Web sites. Unfortunately, many administrators assume that SSL-enabled Web servers are automatically secure. In fact, as we will see, SSL-enabled Web servers are vulnerable to the very same attacks that compromise other Web servers.
SSL-enabled web servers are infrequently audited and monitored
The same unique properties of SSL that make it a universal choice for secure commerce also create problems for security administrators because administrators cannot use current vulnerability scanners or network intrusion detection systems (IDS) to audit or monitor SSL transactions. Network intrusion detection systems monitor network traffic for unauthorized activity. Any activity that matches a known attack signature or that is unauthorized by policy is flagged for administrator review. In order for a network IDS to function, the IDS must be able to view all traffic, but SSL encryption renders HTTPS traffic invisible to an IDS.
Furthermore, although popular security scanners audit normal Web servers for known vulnerabilities, such scanners don't check SSL-enabled servers. SSL-enabled Web servers can and do possess those same vulnerabilities, but presumably because of the time or difficulty involved in establishing SSL connections, security scanners do not audit SSL-enabled Web servers. The combination of no network monitoring and no vulnerability auditing leaves the most critical servers the least well protected.