Tech titans meet in secret to plug SSL hole
Web authentication busted on Apache, IIS
Researchers say they've uncovered a flaw in the secure sockets layer protocol that allows attackers to inject text into encrypted traffic passing between two endpoints.
The vulnerability in the transport layer security protocol allows man-in-the-middle attackers to surreptitiously introduce text at the beginning of an SSL session, said Marsh Ray, a security researcher who discovered the bug. A typical SSL transaction may be broken into multiple sessions, providing the attacker ample opportunity to sneak password resets and other commands into communications believed to be cryptographically authenticated.
Practical attacks have been demonstrated against both the Apache and Microsoft IIS webservers communicating with a variety of client applications. A consortium of some of the world's biggest technology companies have been meeting since late September to hash out a new industry standard that will fix the flaw. A draft is expected to be submitted on Thursday to the Internet Engineering Task Force.
"A core security guarantee made by TLS is violated as a result of this problem," said Steve Dispensa, CTO of PhoneFactor, a provider of two-factor authentication services, the company where Ray works. "It's going to take a while for the protocol changes necessary to be rolled out, because every browser and every server in the world is going to have to be patched."
Ray and Dispensa were quick to note that the vulnerability would most likely have to be exploited in concert with some other security weakness, say a flaw in a home router or the recent DNS bugs discovered by researcher Dan Kaminsky. And even then, an attacker would be unable to read encrypted data that flowed between a server and a client.
Indeed, Moxie Marlinspike a security researcher who has repeatedly exposed serious shortcomings in SSL, said the attacks were hard to pull off in the real world, in large part because they appeared to target a rarely used technology known as client certificate authentication.
"It's clever, but to my knowledge the common cases in which the majority of people use SSL (webmail, online banking, etc.) are currently unaffected," he wrote in an email. "I haven't found these attacks to be very useful in practice."
But Ray and Dispensa said there are attacks that don't rely at all on client authenticated certificates. They maintained that the ability of an attacker to inject plaintext of his choice into an authenticated data stream represented a major threat. And they said the attack has special implications for smartcards and other technologies that rely on client authenticated certificates.
"There is consensus among the biggest vendors in the world that it's a big problem," Dispensa said.
Already, developers from OpenSSL and GNU TLS have developed patches and are in the process of testing them. Other providers of hardware and software that implement SSL are in various stages of patching as well. Dispensa and Ray presented their findings under a non-disclosure agreement to a large number of company representatives on September 29 in Mountain View, California, at a company they declined to name.
The parties had planned to continue working on a fix in secret throughout the rest of the year. Coincidentally, a separate researcher recently documented the basics of the protocol defect and made some of the findings public, prompting Ray to disclose his research. The flaw has existed in TLS since the specification was published in the mid 1990s.
The vulnerability stems from the ability for either party in an SSL transaction to renegotiate the session, usually so one or the other can refresh its cryptographic keys. Because HTTP lacks a way to direct the client to resubmit the request within a newly authenticated channel, the server must apply the authentication retroactively. ®
Thanks Nathan. Isn't HDLC (I'm too lazy to google it at 1:30 in the am) a modified version of X.25, I don't remember too much, but the connection between the FEPS back in my mainframe days were HDLC.
If a black-hat can get into the path of trusted/secure communications, and can capture the entire conversation, including all protocol and encryption negotiations, would they be able to use a botnet to brute-force decrypt the entire stream? This isn't simply a down-side to using the internet, since there is nothing technically different between an internet connection and a leased line, especially since all of the major ISPs are also telecoms. How many encryption passes does one need to apply to a specific dataset to render it irretrievable by entities that are not supposed to be decrypting it? How many times do you have to recursively encrypt a file before you get original input back as the output? I am sure there are ?well? encrypted files that transit the internet, or more likely, leased connections that would be well worth the cost of spinning up an EC2 farm and spending $3 million to decrypt...
Fire Resistant House
The old CCITT protocols X.25 and friends would be a good place to start.
If you're doing serious business, the call setup and session mangement made life easier and more secure. Consistent routing, packet checks at every hop, anyone tries to break into
the conversation and the session drops.
TCP/IP is a nightmare for transaction processing in comparison.
Lousy for surfing porn sites though; IP much better for that. So IP won.
My house is glass
@Nathan Meyer: What would you recommend in place of IP?