February 9, 2013
Lucky Thirteen: Latest Blow to TLS
SSL usage by websites has grown significantly over recent years. The proliferation of wireless packet sniffing and password detection has necessitated protections for website credentials. As with so many things in security, increased usage has generated increased focus and scrutiny. The latest vulnerability, discovered by Nadhem J. AlFardan and Kenneth G. Paterson and known as Lucky Thirteen, claims to decrypt TLS encrypted traffic within two hours.
How Does It Work?
Lucky Thirteen is a man-in-the-middle attack that requires the attacker to be able to control traffic to and from server and client during the transaction. The attacker takes a request sent to the server and changes the header to contain 13 bytes of data. This results in an invalid header for the request, which in turn causes an error to be generated by the server and sent to the client. The vulnerability is presented by recording the time it takes the server to generate the error and respond. The researchers estimate about two hours of traffic can be utilized to calculate the necessary vectors to be begin decrypting traffic, although executing this attack over the internet should increase this time substantially due to network latency and congestion.
What Impact Does This Have on TLS?
Man-in-the-middle attacks are difficult to execute, due to the requirements to position a compromised system between the server and client. Other attacks do exist once a intermediate system can be compromised, including introducing a simple, untrusted certificate (most users will accept them anyway). The over all risk generated is relatively low when so many other vectors exist for man-in-the-middle attacks. The largest implication is that TLS may be overdue for another revision, sooner than later.
How Can This Be Defended Against?
With proper threat detection systems, this type of attack should be fairly straight forward to detect. TLS header errors can be reported and tabulated by IDS/IPS systems and responses initiated long before the optimistic two hour mark is reached. I expect that before long an OpenSSL update will be released that adds a random delay interval before error responses are sent back, thus frustrated the process details in this vulnerability. This type of attack is less of a threat itself than another warning that SSL and TLS need to be reformed further and matured as encryption standards for the world.