TLS/SSL Vulnerability

This flaw affects browsers, servers, VPN deployments, https and any other service or devices that use the protocol. The Internet Engineering Task Force (IETF) will be proposing an extension to the protocol to address the vulnerability. Neither protocol ensures continuity before and after renegotiation allowing a man in the middle (MITM) to introduce data at the beginning of an SSL session. If you are using SSL/TLS for any service from Mac OSX Server 10.6.x or 10.5.x then it is vulnerable to this exploit. If you use a web site and connect to it via https then you are vulnerable as well. However you should continue to always use https.

The MITM needs to intercept the traffic, send their data to the SSL server  and then request renegotiation. They can then forward the data from the original user exactly as it is done in the standard MITM attack. Web servers combine the data before renegotiation with data after renegotiation which compounds the problem and affects any site or web user of SSL. Client certificate authentication is the technology that is highly vulnerable in real world deployments but is a rarely used. The attack has been proven successful against a host of SSL applications and services including Apache and Microsoft IIS. Due to the difficulty of mounting the attack it would most likely be successful as a cocktail of exploits to attack a system. Encrypted data that is exposed to the MITM remains unreadable to the attacker but other weaknesses in the SSL/TLS protocol can be leveraged. Thus proving that a layer approach to security limits risk to a cocktail of exploits from crackers. 

OpenSSL developers (released here) and GNU TLS are working on patches which allow you to disable renegotiation but this does not fix the protocol's issue. The removal of renegotiation may render some web services and applications unusable so updates should not be applied to production systems until detailed test are accomplished. A broader approach is to ensure that routers are running up to date firmware, Kaminsky DNS bug patch is applied, system software has the latest security patches and even within trusted networks packets are filtered (ingress and egress) including application layer firewall and IPFW firewall in OSX server. Application firewalls can filter embedded http request lines since they are not obfuscated which can limit the risk of this vulnerability. 

Needless to state that this may be the tip of the iceberg and a vulnerability such as this can be used in countless imaginative ways. Similar to the Kaminsky DNS issue the internet is not falling but prudent action allows administrators to managed the risk of such vulnerabilities in widely used protocols. 

Update on Monday, November 16, 2009 at 08:20AM by drStrangeP0rk

It is being reported that a Turkish grad student, Anil Kurmus, has developed a real world attack using the SSL renegotiation bug. As was reported most researchers felt that the vulnerability most likely would not be used in an attack since it was complicate to execute resulting in limited results. Kurmus was able to use the bug to steal Twitter account information by injecting text that instructed Twitter's API to dump the contents of the web request into a Twitter message after it was decrypted. Twitter is the perfect victim since every request sent over their network includes user credentials in the form of user name and password. Second the API is very similar to the http protocol thus the Twitter API makes injection into a stream is easy. Users tend to also use applications which do not handle Twitter errors properly (error pages are not reported) thus users may never know about the attack. Twitter has closed this security hole last week but the TLS/SSL renegotiation bug is beyond theory and is effective with the balance of right attack surface, technical skill and determination. 

http://www.theregister.co.uk/2009/11/14/ssl_renegotiation_bug_exploited/