Zero-day flaw found in Web encryption
A zero-day flaw in the TLS and SSL protocols, which are commonly used to encrypt Web pages, has been made public.
Security researchers Marsh Ray and Steve Dispensa unveiled the TLS (Transport Layer Security) flaw on Wednesday, following the disclosure of separate, but similar, security findings. TLS and its predecessor, SSL (Secure Sockets Layer), are typically used by online retailers and banks to provide security for Web transactions.
Ray, who works with Dispensa at two-factor authentication company PhoneFactor, explained in a blog post this week that he had initially discovered the flaw in August and demonstrated a working exploit to Dispensa at the beginning of September.
Read more of "Zero-day flaw found in web encryption" at ZDNet UK.
On the Windows side, SSL is used in Active Directory Federation Services (not for AD itself, mind, but for "secure" DMZ-like services where Active Directory functions are needed), Exchange OWA, and lots of other bits.
BTW - is it actively being exploited by the black hats, or are we just chucking around the "zero day" term indiscriminately now?
That was an absolutely disgusting attempt at FUD. What was your purpose in pointing out any MS products that use SSL?
SSL is used for secure connections between parties internet-wide. It's like somebody finding a flaw in the TCP/IP protocol and you pointing out the MS products that use it. Stop trying to spread FUD by association.
Who doesn't use SSL or TLS? Why point out Microsoft?
PS. i found most recent (last 5 years) MS products using TLS for server communications. Clients still use SSL alot (regardless of platofmr; MAC, Windows, Linux...even the iPhone).
Let me put into perspective what they're claiming: You go to the bank to open your safe deposit box. The Bank Manager is standing between you and the safe deposit box. You give the manager your key, he uses it on the safe deposit box to make sure they match, then gives the box and matching key to you. (not really how that happens but you get the picture). You can now open it.
In a MITM, the manager isn't trustworthy and makes a copy of the key (hard to do IRL, easy to do with invisible data).
This would only be an actual exploit if, I don't know, you could break into an already authenticated session after the handshakes. SSL passthrough MITM is nothing new, nothing special. If you want to fix that you need to changes how the internet works because all data, including certificates, is transmitted from client to host without encryption until that handshake occurs. If that gets passed through a rogue doing SSL passthrough and watching the traffic, then there's nothing you can really do about it because it'll get to see everything you see, including the certificates. It can then decrypt the data.
This problem has to do with channel renegotiation, e.g., when going to a specific URL that requires client authentication. And it indeed allows plain text injection into an authenticated session, since the authentication is renegotiated.
You have the following:
- a Server S with a public - private key pair - Spub and Spri
- a (randomly generated) symmetric key (K) used to encrypt the data for your secure session
- K is what we need to keep secret. As long as K is secret, your data remains safe.
- content encrypted with Spub can only be decrypted using Spri
Now, imagine the following sequence:
1. Client requests a secure session from the server
2. Server responds by sending across it's public key (Spub)
4. Client generates a random symmetric key (K) to use for this session
5. Client encrypts K using Spub (lets call this result K-Spub)
6. Client sends K-Spub back to the server
7. Server uses Spri to decrypt K-Spub (so now the server knows K)
8. Client and server encrypt everything using K for the rest of the session
9. Anybody who intercepted the entire conversation cannot know K (because they didn't know S-Pub)
I've left out a lot of stuff -- there are tons of attack vectors left open in that explanation (for example, how does the client know that the correct server is responding with it's Spub as opposed to an MITM. How does the server know it's the original client as opposed to an MITM. But using this technique and digital signatures you can add layers to address these questions, until you get to the final protocol.
I was also glad to see that they did the right thing by contacting and working with major affected vendors prior to publishing this. So while there may not be a quick/easy fix, at least they didn't go completely for the quick glory and catch everyone by surprise with this.
WIll be interesting to see how this progresses.
Oh, and most times, they do NOT 'go for the quick glory'. When businesses say that someone has, they are usually being facetious because they were told months or weeks ahead of the 'open announcement' that these problems were there and to fix them.
No, it is not. They don't use client authentication (you don't need to have a certificate to do online banking, only your bank has a certificate), so they don't need renegotiation.
Client auth is used more in things like Web services.
I'm sure you meant (because they didn't know SPri) and not
"(because they didn't know S-Pub)" ?
- by networksniff November 8, 2009 12:48 AM PST
- i make sure this public intentions could really make more use of flaws to rebuild a stuff in elite manner.
- Like this Reply to this comment
-
(16 Comments)As TSL,SSL flaws could take back eCommerce biz to early man acts.So need to act up on this for many more reasons.
sekhar
networksniff[dot]com