Like a security guard asleep at the front desk, Netscape's certificate management is leaving some doors unsecured. On May 12, 2000, CERT, an Internet security organisation, reported on a security deficiency regarding the way Netscape's browser validates SSL (Secure Socket Layer) certificates. This security hole has the potential of exposing e-commerce customers' sensitive data to a malicious Web site operator. With the help of testing from KeyLabs, BugNet was able to validate the security hole as well as Netscape's recently released security update for that hole. The problem is not that Netscape doesn't check for SSL certificates. The problem is in the way it validates those certificates. By not validating certificates appropriately, Netscape Communicator fails to warn the user of an invalid certificate, thereby allowing a malicious Web site operator to usurp a legitimate Web site identity and acquire sensitive customer information, like credit card numbers and passwords. SSL is implemented to assure Web users that they are really communicating with the intended Web server. It involves encrypted communication between the browser and the Web server. When functioning properly, SSL provides the vehicle for browsers to validate the credentials of a Web site. For example, when connecting to a secure site, the browser first establishes an SSL session with the Web server. The server then presents its certificate, typically issued by a certificate provider. The browser checks to see if the certificate is valid. Some of the things it looks for include: 1) the certificate must be issued by a trusted authority, like Verisign or Thawte. 2) the certificate must not have expired. And 3) the certificate must be issued for the site that you are trying to connect to. In other words, if you are browsing to www.securecompany.com and the certificate must be for www.securecompany.com. If any of these three criteria are not met, then Netscape would generate an invalid certificate warning message. Netscape correctly identifies these three conditions when it first establishes a secure connection. The problem is that while the secure session is alive, all secure connections to that server's IP address are assumed to be part of the same session. By not comparing host names with certificates for each connection, Netscape allows a malicious Web programmer redirect secure requests from the legitimate site to the renegade site where the hacker can glean the users information. In order for this Netscape SSL vulnerability to be exploited, certain conditions need to be met. First of all, the hacker must be able to contaminate your DNS server. Without this ability, it would be impossible to redirect your request from the legitimate Web site to the malicious one. Second, the malicious site must itself have a valid SSL certificate. Third, before the unwary user connects with the legitimate Web site, that user must make a valid, secure connection to the malicious site. You can check site certificates manually by double-clicking on the lock icon at the bottom of the Netscape browser and comparing the certificate name with the site you are trying to visit. While the potential for abuse is here, the likelihood is small due to the complexity of the prerequisites. The people most able to exploit this vulnerability would be your ISP or someone with control over Domain Name Service (DNS) tables. Also, they would need a way to "dupe" you into establishing a secure connection with their bogus site. KeyLabs was able to reproduce this vulnerability and the subsequent patch issued by Netscape. We used two Web sites with digital certificates issued by RSA. Instead of contaminating a DNS server entry we modified the host's file on the browsing computer to point to the bogus Web site. With this configuration we were able to redirect the user's secure connection from the intended site to our malicious site. The quickest way around this security hole is to update your Netscape Communicator with the Netscape Personal Security Manager (PSM) Add-on. You might also choose this time to upgrade to the latest release of Netscape version 4.73, which includes the fix for this vulnerability. Something else you might consider is keeping an eye on your ISP and DNS server. Big ISPs have a big name to protect and will be more diligent in ensuring that their DNS servers do not get compromised. What do you think? Tell the Mailroom. And read what others have said.