No solution yet for SSL/TLS security hole besides turning renegotiation off

A defect in the protocol that secures monetary exchanges and other private transactions throughout the Web, discovered by wireless security engineers last August, continues to go unfixed as vendors work towards a solution. It can only be described as miraculous that a working exploit hasn't yet been detected for a security hole that hid in plain sight ever since Transport Layer Security was developed.

The problem was inadvertently made public last November. In short, it has to do with the transition Web sites make between the older Secure Sockets Layer protocol and the augmented TLS. During the transition process, the Web sites leave one protocol, but have to remind each other what they were transitioning from and to -- like asking one another, "What were we talking about again?" The question and answer get sent in the clear, making it easy for a man-in-the-middle to spoof the site with the answer.

Yesterday, Microsoft issued an advisory for server administrators, linked to a Knowledgebase article that provides an update package for Windows Server. But that package is not a fix; actually, it's just a System Registry patch that disables the entire renegotiation process. It makes your system safe from the exploit, but it may end up leaving transactions encrypted with SSL rather than TLS.

Microsoft warns that this could be an inconvenience for some customers whose applications require this kind of step-up renegotiation in order to make a connection. That could be a very serious inconvenience indeed if your name happens to be "US Dept. of Defense."

Back in April 2004, DoD directive 8100.2 (recently redubbed 8100.02) specified that data traffic over wireless devices was only permissible by layering an encryption system atop the existing wireless infrastructure. This was back before Wi-Fi was trusted. That changed with a supplement to that directive issued in June 2006 by the Assistant Secretary of Defense for Networks and Information Integration (known on record as "ASD(NII)/DoD CIO"). The supplement marked the Department's official embrace of 802.11i security standards for Wi-Fi, which the CIO deemed compliant with Security Level 2 out of 4, of the government's Security Requirements for Cryptographic Modules (PDF available here).

As the latest (2007) version of 8100.02 now reads (PDF available here), "Encryption of unclassified data for transmission to and from wireless devices is required. Exceptions may be granted on a case-by-case basis as determined by the Designated Approving Authority (DAA) for the wireless connections under their control. At a minimum, data encryption must be implemented end-to-end over an assured channel and shall be validated under the Cryptographic Module Validation Program as meeting requirements per Federal Information Processing Standards (FIPS) Publication (PUB) 140-2, Overall Level 1 or Level 2, as dictated by the sensitivity of the data."

And as the FIPS 140-2 document explains, "Security Level 2 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an operating system. An equivalent evaluated trusted operating system may be used. A trusted operating system provides a level of trust so that cryptographic modules executing on general purpose computing platforms are comparable to cryptographic modules implemented using dedicated hardware systems."

Standard 802.11i is published and maintained by the IEEE, and its encryption protocol of choice is maintained by the IETF: EAP-TLS, the most evolved form of the protocol that started out as SSL.

Now, it would appear the DoD may be on the threshold of wading into precisely the minefield they had hoped to avoid, prior to their embrace of 802.11i. The fix to the TLS security hole, when it comes, will have to be coordinated and simultaneous, involving the cooperation of not just Microsoft but hardware vendors that supply the government with systems, such as Cisco and Aruba Networks. Technically, operating systems that were considered "trusted" enough to substitute for firmware cryptographic modules, under FIPS 140-2 Security Level 2, may not qualify as "trusted" now, were someone to make that official evaluation. The more time vendors assume in coordinating their response, the more opportunity the Pentagon may have to reach that dreadful conclusion.