Yet Another SSL Hack Hilites Achilles Heel Weaknesses of “Standards”
Posted by LS on September 23rd, 2011. Category: Blog
We have been strongly opining on the conceptual weaknesses of the SSL protocol for some time, for example here: http://bit.ly/nERJ9Y in this article of ours as well as referencing some excellent thoughts of other, like here: http://bit.ly/g52J3D.
Of course we also felt strongly enough that the SSL has so many faults that FN developed its own protocol, ASL specifically to address all of SSL’s shortcoming, including from our perspective the much more serious threat of phishing.
But enough background, lets get back to today’s topic at hand which was “the plaintext-recovery attack that exploits a vulnerability in TLS that has long been regarded as mainly a theoretical weakness”, as quoted directly from Dan Goodin and theregister.co.uk which in IMHO has done an outstanding job of covering SSL’s legion of issues (not to mention most cyber-security topics) and has done so again as related to this latest hack/potential hack, click here for details: http://bit.ly/qFyk2W. (Note that this hack is currently not been verified, but the individuals involved have a strong pedigree and as such we believe it will be confirmed to be valid, post the planned presentation)
Specifically there are 3 interesting things of note about this exploit:
- It has been conceptually known as a weakness for quite some time and also as noted, this exploit does not work against TLS 1.1 or 1.2, both of which have been around for years (and of course doesn’t work against FN’s ASL protocol either…)
- Despite the long history of conceptual weaknesses having a remarkable aptitude for showing up as real threats, the work of Thai Duong and Juliano Rizzo is still impressive (despite the fact that the hack requires a client side component and god knows that once you have client side access to a users machine, there are many more simpler (and powerful) ways to steal data…)
- The real story here is the exposure of two “open source” and “standards” as altruistically naive as linchpin pillars of effective cyber- security. More specifically, standards, like laws or regulation are only as good as their explicit or implicit enforcement and as the pretty well complete lack of adoption of a “standard” that was updated twice to fix/patch vulnerabilities, it’s a pretty sobering reminder that lightweight implementation still remains an important consideration for security products. Said another way, the prospective benefits of upgrading to a newer version of a protocol were pretty well universally deemed less important than the negative impacts to user experience that its adoption might entail. As such, the decentralized adoption requirements and de facto unilateral decision by any party to implement “recommended changes to any standard, no matte how necessary have proven to be more that just a conceptual issue, as this hack clearly outlines.
And so, another day another nail in the SSL coffin (gratuitous chiding on our part) but at some point people will probably start to figure out or care, that someone has in
Cyber-Security Revisited – Why SSL Needs Replacing
Posted by LS on July 27th, 2011. Category: News
As citizens of the Internet, we have all come to associate web security with the lock icon in commerce transactions, the icon added to our browsing to indicate we are secure (i.e. https), as well as the growing use of encryption to protect our communications, such as email and instant messaging.
Since introducing the notion of Federated Networks’ Application Security Layer Protocol (ASL) almost a year ago, we have been surprised by the lack of understanding of the plethora of issues facing SSL, as well as the fair question of whether this need of replacement is simply the figment of this security vendor’s imagination.
Let’s deal with the latter issue, first. The title of Dan Goodwin’s aptly entitled article in The Register “How is SSL hopelessly broken? Let us count the ways”В provides some clues (read the article as well, it’s great!) that FN is not alone in its perceptions, as do the following quotes from other well-known security industry pundits:
“It’s pretty crappy, but it’s what it is now,” White Hat Security CTO Jeremiah Grossman said, referring to the SSL system. “It is definitely weak. It could fall down at any time.” (2011)
Said fellow researcher Dan Kaminsky, who attended the Black Hat presentation. “The larger message of Moxie’s talk is one that a lot of people have been talking about actually for a few years now: This SSL thing is not working very well.” (2009)
“Right now, it’s just an illusion of security,” said Moxie Marlinspike, a security researcher who has repeatedly poked holes in the technical underpinnings of SSL. “Depending on what you think your threat is, you can trust it on varying levels, but fundamentally, it has some pretty serious problems.” (2011).
By way of a little more technically oriented background, communication security over the Internet is currently generally provided via Secure Socket Layer (SSL) and/or its replacement, the Transport Layer Security (TLS) cryptographic protocols. These protocols in turn utilize the X.509 standard for a public key infrastructure (PKI).
Both SSL and X.509 have been around since the beginning of the Internet as we know it, some 15 or so years ago in what we jokingly refer to as “the Jurassic period”, for 15 years of internet time, feels like 15,0000…
As the quotes and Goodwin’s article portend, there are plenty of flaws in SSL and we don’t plan on rehashing old ground covered by others. Instead, we have chosen to focus only on SSL’s most fundamental challenges, which for convenience we have divided into three categories: design challenges; implementation challenges and circumvention challenges.
Design Challenges:
In our minds the biggest design challenge inherent in SSL/TLS is that it is by definition, a Transport Layer Protocol and as such is ill suited to protecting against the application level threats prevalent in the modern Internet. These threats are generally referred to as Man-In-the-Middle threats, including the granddaddy of them all, Phishing and its newest incarnation, Spear Phishing.
Other important design differences however also remain from a purely technical perspective, as compared to FN’s ASL protocol, including:
Implementation Challenges:
The biggest implementation challenge facing SSL from our perspective is the lack of use of certificate bi-directionality whereby both the website and the User are concurrently validated. Interestingly, this is not a technology challenge, rather more of a business/business model challenge being driven by the business models of current CertificateВ authority providers such as Symantec (Verisign).
That said, other SSL implementation challenges and foibles have been significant and appear at an almost constant rate of 1 or 2 a year, some of which are noted in Dan Goodin’s article and/or the related links in same.
Circumvention Challenges:
Despite a plethora of circumventions of the SSL/TCP protocol, the most material of all the man-in-the middle type challenges remains phishing. To that end, specifically stopping phishing and more generally any and all Man-in-the middle threat vectors was the key consideration in designing FN’s ASL protocol and one which the protocol is particularly adept at solving. In FN’s case, the MITM still receives a user’s data, but at all times said data is protected by AES encryption, essentially making it very difficult to compromise.
Of course SSL or ASL for that matter is only one link in the chain of security that is only as strong as it weakest link. This point made poignantly and hilariously by none other than Eugene Spafford and remains one of our favorite cyber security quotes of all time namely that SSL is like “using an armored truck to transport rolls of pennies between someone on a park bench and someone doing business from a cardboard box.”
Not only do we wholeheartedly agree, as comprehensive, end-2-end security (of which SSL as troubled as it is, remains only one component) is our mantra here at FN, as the saying goes we could not have said it better ourselves. In truth we could not have at all, as we are just flat out just not that clever or pithy. Classic!
This article first appeared in the techherald.com
For more, follow us on twitter @fednetworks
Cyber Security Revisited: Why Compromise Breeds Compromise
Posted by admin on April 29th, 2011. Category: News
by David Lowenstein and Risu Na
The seeming inevitability of cyber insecurity makes it all too easy to externalize the situation, requiring someone – somewhere – to do something. But what about our own personal roles and responsibilities as security professionals and consumers? How much of this problem do we personally own? Read more