A vulnerability exists in the manner in which versions of Netscape Communicator up to, but not including, 4.73, validate SSL certificates. This vulnerability could make it possible for the integrity of an SSL connection to be compromised. For optimum security, Netscape should perform a match for a certificate for both the hostname and establish connections based on the name present in the certificate matching the name of any presently open connections. The example given in the Bugtraq posting outlined a possible way this could be utilized. An abridged, slightly clearer explanation: An attacker poisons a nameserver to redirect all connections to www.goodguy.com, normally 100.100.100.100, to 99.99.99.99, www.badguy.com. The attacker causes all normal http requests to return what they normally would on www.goodguy.com, even though a user attempting to contact www.goodguy.com hits www.badguy.com. Upon getting a hit to www.badguy.com, the attacker causes an SSL connection to be...
A vulnerability exists in the manner in which versions of Netscape Communicator up to, but not including, 4.73, validate SSL certificates. This vulnerability could make it possible for the integrity of an SSL connection to be compromised. For optimum security, Netscape should perform a match for a certificate for both the hostname and establish connections based on the name present in the certificate matching the name of any presently open connections. The example given in the Bugtraq posting outlined a possible way this could be utilized. An abridged, slightly clearer explanation: An attacker poisons a nameserver to redirect all connections to www.goodguy.com, normally 100.100.100.100, to 99.99.99.99, www.badguy.com. The attacker causes all normal http requests to return what they normally would on www.goodguy.com, even though a user attempting to contact www.goodguy.com hits www.badguy.com. Upon getting a hit to www.badguy.com, the attacker causes an SSL connection to be established. This can be done by embedding a small image. The user may or may not get a warning about establishing a secure connection -- this warning is on by default, although many users will choose to disable this warning. The attacker needs to use a legitimate SSL key, certified by someone listed as trustworthy (thwate.com, for instance) The user can continue to shop to their hearts content, on the real site, as it's being proxied. When the user decides to check out, it will attempt to establish an SSL connection to www.goodguy.com. Upon checking the ip address for www.goodguy.com, for establishing an SSL connection, it will note that an SSL connection already exists to it's IP. The key, however, was issued to www.badguy.com. The SSL connection will be established, and by all indications appear to go to www.goodguy.com, when in fact it is to www.badguy.com. This could be used by a would be attacker to steal information such as credit cards, or any other information protected by SSL.
