A few days ago, I wrote about a fundamental flaw in the Domain Name Service (DNS) protocol that handles the lookup from human-readable names into machine-processed Internet Protocol (IP) addresses, advising all readers to determine their vulnerability and take action.
There's one more warning I should pass on, however. Because this flaw allows an attacker to poison the DNS for anyone whose system connects to an unpatched DNS server, an attacker can also bypass a protection built into encrypted Web sessions.
Web encryption uses SSL/TLS (Secure Sockets Layer/Transport Layer Security), a standard that relies on three methods to ensure that your browser connects only to the correct party on the other end for a secured link.
First, every Web server that uses SSL/TLS has to have a certificate, either one per server or a group certificate. This certificate identifies the server.
Second, the certificate binds the domain name of the server. You can get a certificate for www.infoworld.com and use it with www.pcworld.com.
Third, the identity of the party that requests the certificate for a given domain name is validated by a certificate authority. A firm that operates such an authority validates the identity of the person and company requesting a certificate, and then creates a certificate with their blessing cryptographically bound into it. (Higher levels of validation are now available, which is why you see a large green area in the location filed of the latest versions of Internet Explorer and Firefox, which indicate that extended validation was performed.)
These certificate authorities themselves have a set of certificates that prove their identity, and which are pre-installed in browsers and operating systems. When you connect to a Web server, your browser retrieves the public certificate before starting a session, confirms that the IP address and domain name match, validates the integrity of the certificate, and then checks the authority signature for its validity.
If any test fails, you're warned by your browser. With the DNS flaw, an attacker could redirect your banking or ecommerce session to their mimicked versions of secure sites run by various firms, and your browser wouldn't notice the IP address difference, because the domain name in the bogus certificate would match the IP address that the attacker had planted.
However, your browser would note that there's no trusted certificate authority signature attached. (So far, there's no reports of any successful social engineering of these authorities tied in with the DNS flaw.) Your browser would tell you that the certificate was self-signed, meaning the attacker used a shortcut and left out an authority's signature, or used an non-trusted authority, that the attacker created themselves. (It's trivial to create an authority using open-source tools, and this is helpful within companies and organizations. I've done it myself. But those independent authorities aren't validated by browsers unless you separately install a certificate on those machines by hand.)
My warning here is that if you get any kind of certificate or SSL/TLS warning from your browser, stop the connection, call your ISP or IT department, and don't enter any personal or company information.