Newsletters Select newsletters below and click the button to sign up!
Internetnews BloggersRecent Entries
ArchivesMonthly ArchivesSearch The Blog
« Linux dominates top 500 supercomputer list |
Sean Michael Kerner Blog
| Mozilla Weave nears release »
SSL at risk (again), this time Twitter is the first target From the 'Not a Hoax' files:
SSL is of critical importance to all web users as the most commonly used method for securing websites. There is now a new publicly posted exploit technique available for SSL that takes advantage of a renegotiation flaw with TLS <DEFINE:TLS>. As a proof of concept, security researcher Anil Kurmas has blogged about how TLS/SSL renegotiation can be used to exploit Twitter's HTTPS (that is SSL secured) API. "All in all, a man in the middle is able to steal the credentials of a user authenticating himself through HTTPS to a trusted website, and CSRF protections do not apply here," Kurmas wrote.This is extremely serious and in my opinion represents perhaps the single biggest threat to the integrity of the Internet today. Without SSL, ecommerce becomes insecure and the vast majority of the web's population cannot login securely to any website. Sure there have been SSL threats before. Most notably, I've seen security researcher Moxie Marlinspike present his ideas at Black Hat on SSLstrip in February, then again in July. Marlinspike however wasn't directly attacking SSL itself, though. His attacks involved a man in the middle type attack as well, but where a regular HTTP user is tricked into thinking they are actually on an HTTPS (SSL) protected site. The new attack (if I understand it correctly) actually intercepts legitimate HTTPS traffic. It's a subtle but very significant difference. The good news is that SSL vendors and standards makers are aware of the issue and are working on a fix. The open source OpenSSL project has already pushed out a new version that removes the ability for a TLS/SSL renegotiation in the first place. Going a step further the IETF standard body is working on an effort to solve the problem in a more definitive manner. The IETF solution is similar in some respects to how DNS is getting secured with DNSSEC by way of a cryptographic signature to provide an additional layer of integrity and authentication. "SSL and TLS renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client," the IETF draft states. "The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This draft defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack."Unlike DNSSEC which is difficult to roll out on a global basis, the new TLS extension would be an incremental update for existing TLS users to implement. I suspect that it will take some time till the entire web is secured as the first official patches roll out from vendors and users around the world upgrade their software. 0 TrackBacksListed below are links to blogs that reference this entry: SSL at risk (again), this time Twitter is the first target. TrackBack URL for this entry: https://swarm.jupitermedia.com/mt-tb.cgi/9284 2 CommentsLeave a comment |
||
You've got the attack right, but it is still, in essence, a Man in the Middle Attack -- in this case, an issue with SSL protocol and Twitter's API and not SSL certificates (we're working hard at VeriSign to ensure that this distinction comes across, because this hardly means SSL is "broken" or anything even remotely close to that). It does, still, however, need to be patched by developers, and the good news is that since the attack is fairly convoluted it's not likely to be attempted on a grand scale before a patch is released. There's more info about this here: https://blogs.verisign.com/ssl-blog/2009/11/more_on_the_ssl_renegotiation.php
So, I think the comments above are correct, but the reality is that the SSL MITM attack described by Moxie is far easier to execute, and MUCH! more expensive to fix. (the cryptographic co-processor community is standing by for your order!)It's being largely ignored I think, which should provide some insight into how expensive it is.
As noted, the cost to fix the renegotiation flaw in the protocol is relatively cheap, especially in comparison. The tie into DNSSEC is a bridge too far, imho, but it does generate keyword hits. :)