- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Email to a Friend
- Printer Friendly Page
- Report Inappropriate Content
Transport Security Layer (TLS) Man-In-The
As you may be aware, late last week a vulnerability in TLS, which may have also been referred to as an HTTPS vulnerability, was disclosed to the public (http://extendedsubset.com/Renegotiating_TLS.pdf). As with most high profile vulnerability releases, there has been a lot of incorrect assumptions made about this issue and the impact. This post will hopefully help combat the unnecessary fear and chaos.
First of all, this is a serious vulnerability with some very interesting attack vectors and of course a serious impact to anyone who is unfortunate enough to be exploited. That said, in order for an attacker to exploit this vulnerability the attacker needs to use other vulnerabilities to achieve Man-In-The-Middle access. Of course there are ways to accomplish this if you have local subnet access, or by performing DNS spoofing, but this requirement alone does raise the difficulty of exploitation.
With that let's review the top five myths that are floating around about this vulnerability:
Myth 1: You can no longer trust HTTPS connections like those provided by your online banks and favorite online retailers.
False: This is unnecessary panic and fear over this issue. Again, the issue here is that an attacker needs to first gain enough access to perform a MITM attack. It is also worth mentioning that many financial institutions have solutions in place to insure that you are in fact the correct user of their system. So while a level of security awareness and caution should always be in place when using the internet, there is no need to feel more insecure than usual.
Myth 2: The encryption of TLS has been compromised.
False: This vulnerability does not allow an attacker the ability to read encrypted data. It only allows for clear-text data to be inserted in to encrypted sessions. The cryptographic strength offered by TLS has not been compromised by this vulnerability.
Myth 3: OpenSSL has released a patch for this vulnerability.
False: The OpenSSL team has released a mitigation (www.openssl.org) that provides administrators the ability to turn off SSL renegotiation. It is important to understand that this mitigation is largely untested and the impact to clients, applications and other servers is unknown. Anyone who is considering implementing this mitigation should fully test this on non-production systems beforehand.
Myth 4: Hackers are actively exploiting this vulnerability.
False: To date there is no evidence that supports this claim. That said, many vendors and other interested parties are working together and actively monitoring for the use of this vulnerability. Note that exploit code has been released for this issue so this myth may very well become true.
Myth 5: This issue only affects Hypertext Transfer Protocol (HTTP) traffic.
False: The issue is not specific to HTTP but is specific to TLS. Many other protocols have implemented TLS in various ways. Today we have a provable vulnerability in HTTPS but research in to other protocols that use TLS is still underway. It is reasonable to expect that others may also have the same issue.
To review, this is a serious vulnerability but is by no means the end of the Internet as we know it. There are many vendors participating in not only assessing the various attack vectors, but also in working towards a high quality
patch that is regression tested as well as interoperability tested amongst all the affected implementations. This is not an easy process; there are multiple TLS implementations and literally thousands of products that use one or many of these implementations. Please note that this is a TLS issue and not a HTTPS issue. Other protocols, not just HTTPS, may in fact be affected.
ICASI (the Industry Consortium for the Advancement of Security on the Internet) has been acting as incident manager and coordinator for this issue. Many vendors who are not members of ICASI are getting involved, and ICASI welcomes any other vendors or individuals who may have a direct interest in this issue.
On November 11, 2009 ICASI released an advisory on this issue which you can read here: http://www.icasi.org/alerts.htm. The important parts of this advisory to pay attention to are the mitigation and detection options.
In addition to these options I also want to point out a tool that has been developed by Leviathan Security that can be ran on any Windows based system. This tool will detect, log and block potential exploitation attempts of this issue. Juniper Networks does not offer technical support for this tool so check it out on the Leviathan page for more information: http://www.leviathansecurity.com/research.html
Customers of Juniper Networks who have purchased an IDP, or a device such as our SRX line that has our IDP technology built in have some detection options as well. We have two attack objects available for customers.
SSL: Key Renegotiation - is an anomaly that is set to medium severity and can be used to detect key renegotiations which may be an indication of exploit attempts. Note that you should test your specific environments before using any kind of block rule in your policy.
HTTP: Request Injection - is a high severity signature that is available only for Juniper devices that have the ability to load private SSL keys and then inspect SSL traffic. If you have an IDP running release 4.1 and above with our latest detector, you can use this signature to identify and block exploit attempts.
Questions or comments on this issue are welcome. Please feel free to email me directly - smanzuik@juniper.net
