#sslsecurityhack SSL/TLS, the encryption system that has been keeping online credit card transactions and HIPAA-sensitive communications safe for over a decade, has broken down. As shown by researchers at a recent conference, a simple tool now gives hackers access to your PayPal transactions and much more. Gonna be fixed? Possibly not for many months, even years, since any change to the SSL/TLS protocols causes ecommerce to break for any number of sites, depending on the server or browser involved in the transaction. The hack is truly a killer app.Just google SSL/TLS HIPAA and you'll find hundreds of applications that use Secure Sockets Layer/Transport Layer Security technology to secure electronic medical records transactions. (Here's an ironic example of the misinformation out there, labeled "Completely Secure Collection of Web Form Data using SSL".)
An article in The Register reports that a couple of researchers announced a demo of their tool, called BEAST (Browser Exploit Against SSL/TLS), at a Buenos Aires security conference last week. BEAST performs a "plaintext-recovery" attack, exploiting a (previously theoretical, but known) weakness in TLS. During encryption, the TLS protocol scrambles each subsequent block of data based on the previous encrypted block. It had long been theorized that an attack could manipulate the process to make educated guesses about the contents of the plaintext blocks. If a guess is correct, the block cipher will get the same hash for a new block as it used for the previous one, resulting in identical cipher-text. Security just goes POOF.
At the moment, BEAST requires a little under two seconds to decrypt each byte in an encrypted cookie, used by a web browser to secure an online transaction session. Doing the math, a 1,000-byte cookie would take maybe half a minute, but researchers Thai Duong and Juliano Rizzo have now announced that they've tweaked the process down to about ten seconds. That's plenty quick to grab whatever users are sending, decypher it, and, well, steal it.
So, what are browser makers doing to plug this new hole? One word: Nothing. What's the hold up? Well, although this "theoretical" hack has been understood for years, a secure transaction involves just too many parties to get it all straightened out without knocking out millions -- perhaps billions -- of transactions for perhaps an extended period of time. For instance, the Firefox and Chrome browsers (according to w3schools.com, Firefox gets 40.6% of traffic, while Internet explorer gets just 22.4%, and Google Chrome gets 30.3% as of August, 2011) use the open source Network Security Package to implement HTTPS. But there are other security packages out there, and IE uses one of them. Any change would require simultaneous change to all packages. And that's not the half of it; the servers use multiple SSL implementation platforms, such as OpenSSL, and all of those would have to change at the same time. The offending protocol, TLS 1.0, has been available in an upgraded version (1.1 and 1.2) since 2006, but getting all the ducks lined up just isn't happening. While IE 8 and up include support for TLS 1.1 and 1.2, which do not appear to have the vulnerability, it is not the default, and still relies on servers to accept the protocols without falling back to 1.0.
“The problem is people will not improve things unless you give them a good reason, and by a good reason I mean an exploit... It's terrible, isn't it?” said an analyst with the security firm Qualys.
There appear to be no reliable estimates of the percentage of HIPAA electronic transactions that are secured using SSL with TLS 1.0, but considering that, in the absence of a broadly implemented general browser-server solution, any TLS v1.2 implementations would require proprietary code at both the server and client sides, and transactions running under the hackable version would likely be the overwhelming majority. As of early 2011, Microsoft's .Net framework did not support the updated TLS protocols, suggesting that any EMR, EHR, eligibility and billing applications developed at that time may not support them either. Time to call your vendor?
Check Comments below for updates...
No comments:
Post a Comment