A fix for a flaw in an important Internet security protocol is ready for prime time but it will be many months before the patch is fully implemented, according to technical experts.

The authentication vulnerability in TSL/SSL, which is the most common security code on the Net, could be exploited by hackers for all kinds of mischief. Built into browsers and Web servers to protect high-value information, the flaw impacts a wide scope of technologies including online banking, back-office systems using Web-based protocols, non-HTTP applications such as mail and database servers, mobile phones, wireless access points, DECT phones and home security systems.

The vulnerability was discovered last September by researchers at PhoneFactor, a security service provider in Overland Park, Kansas, but was kept under wraps until November when another security expert, working independently, made the flaw public on a mailing list sponsored by the Internet Engineering Task Force (IETF).

With the cat out of the bag, PhoneFactor decided to push out a press release on the subject. In it CTO Steve Dispensa, who, along with Marsh Ray, initially unearthed the flaw, stated,

“Because this is a protocol vulnerability, and not merely an implementation flaw, the impacts are far-reaching. All SSL libraries will need to be patched, and most client and server applications will, at a minimum, need to include new copies of SSL libraries in their products. Most users will eventually need to update any software that uses SSL.”

“The discovery of this vulnerability speaks to a larger issue with single channel authentication protocols,” he added. “While this vulnerability is larger in scope than many, man-in-the-middle attacks have been a known threat for some time. Out-of-band protocols should be considered when possible to help mitigate the risk of these attacks.””

According to a U.S. Computer Emergency Readiness Team (CERT) vulnerability note, the TLS/SSL defect exploits the way the protocol handles renegotiation requests.

“The server treats the client’s initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data,” it explained.

The note said that SSL and TTL protocols are commonly used to provide authentication, encryption, integrity, and non-repudiation services to network applications such as HTTP, IMAP, POP3, LDAP. A vulnerability in the way SSL and TLS protocols allow renegotiation requests may allow an attacker to inject plaintext into an application protocol stream.

“A remote, unauthenticated attacker may be able to inject an arbitrary amount of chosen plaintext into the beginning of the application protocol stream,” it added. “This could allow and attacker to issue HTTP requests, or take action impersonating the user, among other consequences.”

What’s more, the attack is invisible to the server and browser it’s directed at, according to PhoneFactor. They have no idea that a session has been hijacked.

Following the public revelations about the TLS/SSL glitch, a working group was formed made up of vendors and representatives from the appropriate standards committees. They hammered out the fix for the problem that was released last week.

Vendors are expected to begin shipping patches containing the fix shortly. However, predictions are that adoption will be slow because patches must be performed on both servers and clients to fully close the security gap. “This obviously will not happen tomorrow,” Ray Marsh wrote in his Extended Subset blog, “but eventually clients and servers will have to start refusing connections with unpatched endpoints (just like they do with ancient versions of SSL today). i.e., their configuration needs to go from “insecure/compatible mode”to secure/strict mode.”

“Unfortunately, as long as there is a single unpatched client and a single compatible-mode server in the world (or a compatible-mode client and an unpatched server) there exists a potential vulnerability,” he added.

Because the patching process will be prolonged, Marsh recommends that steps be taken to ensure that Web surfers are aware of their security status when accessing servers on the Net.

“[In the coming months we will need client applications to begin warning users if they are connecting to an unpatched server,” he noted. “After all, wouldn’t you expect your browser to warn you if your connection could be hijacked because the (supposedly) secure site to which you were connecting was not maintained well enough to apply critical security patches on a regular basis?”