New SSL/TLS flaw leaves Safari vulnerable to man-in-the-middle attack, Apple promises fix
A newly-discovered flaw in some implementations of cryptographic protocols SSL and TLS -- including those used by Apple's Safari and Google's Android AOSP browsers -- could allow an attacker to force clients to use older, weaker encryption that would make it significantly easier to intercept secure communications.
Dubbed the "FREAK" attack, for "Factoring RSA Export Keys," the exploit relies on long-deprecated "export grade" encryption support mandated by the NSA during the crypto wars of the early 1990s. As noted by the Washington Post, the agency attempted to cap the strength of encryption software that could be exported outside the U.S., forcing engineers to design cryptographic libraries that could accept connections from both domestic clients with stronger encryption and foreign clients with weaker encryption.
Though the NSA abandoned this strategy in 2000, legacy support for such connections remains in many SSL/TLS clients and servers. The strength of encryption for a particular session is negotiated between the client -- for example, Safari -- and the server during the first "handshake;" researchers discovered that some clients would still accept the weaker export grade ciphers, even if they requested stronger encryption during the handshake.
This presents a problem when a vulnerable client attempts to connect to a host that still makes export ciphers available. An attacker can acquire and pre-crack the weaker export key from the server, then use it to masquerade as the legitimate host in a man-in-the-middle attack.
Apple has promised to distribute a client-side patch for the issue on both iOS and OS X by next week, while the researchers who discovered the flaw -- from INRIA, IMDEA, and Microsoft Research -- have been working to notify hosts who still serve export ciphers. Many of the latter, including content delivery network Akamai and Facebook, have disabled support for export ciphers on their servers.
Dubbed the "FREAK" attack, for "Factoring RSA Export Keys," the exploit relies on long-deprecated "export grade" encryption support mandated by the NSA during the crypto wars of the early 1990s. As noted by the Washington Post, the agency attempted to cap the strength of encryption software that could be exported outside the U.S., forcing engineers to design cryptographic libraries that could accept connections from both domestic clients with stronger encryption and foreign clients with weaker encryption.
Though the NSA abandoned this strategy in 2000, legacy support for such connections remains in many SSL/TLS clients and servers. The strength of encryption for a particular session is negotiated between the client -- for example, Safari -- and the server during the first "handshake;" researchers discovered that some clients would still accept the weaker export grade ciphers, even if they requested stronger encryption during the handshake.
This presents a problem when a vulnerable client attempts to connect to a host that still makes export ciphers available. An attacker can acquire and pre-crack the weaker export key from the server, then use it to masquerade as the legitimate host in a man-in-the-middle attack.
Apple has promised to distribute a client-side patch for the issue on both iOS and OS X by next week, while the researchers who discovered the flaw -- from INRIA, IMDEA, and Microsoft Research -- have been working to notify hosts who still serve export ciphers. Many of the latter, including content delivery network Akamai and Facebook, have disabled support for export ciphers on their servers.
Comments
So will this be a last minute addition to 8.2, is it included in 8.2 already, or will they rush out an 8.2.1 for next week?
No one here probably knows for certain, but if I had to guess, it would be included in iOS 8.2, and 8.2 would be available Monday shortly after the Apple event. I imagine Apple will demonstrate the companion apps for Apple Watch then. If Apple were to release the fix separately as 8.2.1, it would probably be misconstrued as an issue with 8.2, and I imagine Apple will want to avoid that.
A newly-discovered flaw in some implementations of cryptographic protocols SSL and TLS -- including those used by Apple's Safari and Google's Android AOSP browsers -- could allow an attacker to force clients to use older, weaker encryption that would make it significantly easier to intercept secure communications.
Dubbed the "FREAK" attack, for "Factoring RSA Export Keys," the exploit relies on long-deprecated "export grade" encryption support mandated by the NSA during the crypto wars of the early 1990s. As noted by the Washington Post, the agency attempted to cap the strength of encryption software that could be exported outside the U.S., forcing engineers to design cryptographic libraries that could accept connections from both domestic clients with stronger encryption and foreign clients with weaker encryption.
Though the NSA abandoned this strategy in 2000, legacy support for such connections remains in many SSL/TLS clients and servers. The strength of encryption for a particular session is negotiated between the client -- for example, Safari -- and the server during the first "handshake;" researchers discovered that some clients would still accept the weaker export grade ciphers, even if they requested stronger encryption during the handshake.
This presents a problem when a vulnerable client attempts to connect to a host that still makes export ciphers available. An attacker can acquire and pre-crack the weaker export key from the server, then use it to masquerade as the legitimate host in a man-in-the-middle attack.
Apple has promised to distribute a client-side patch for the issue on both iOS and OS X by next week, while the researchers who discovered the flaw -- from INRIA, IMDEA, and Microsoft Research -- have been working to notify hosts who still serve export ciphers. Many of the latter, including content delivery network Akamai and Facebook, have disabled support for export ciphers on their servers.
This affects everyone (Android, IOS, Windows?) on the server side (but the fix isn'T that hard to do there, change the config), and most browsers on the client side. Wonder though how many servers actually allow this downgrade ?
More a configuration issue (just not allowing downgrade is enough to prevent this). Web servers shouldn't be offering this kind of low security anyway.
The name of the exploit is a bit crazy though....
We need to cut out the middlemen.
Didn't this come up last year, or is this a new attack?
My guess is it that does not affect anyone using Chrome else it would be in big bold letters as the headline.
My guess is it that does not affect anyone using Chrome else it would be in big bold letters as the headline.
Correct, Chrome is not vulnerable to this attack. Just the base Android browser, so most Android users, I imagine. My family uses Chrome on Android, other than my wife with Safari on iOS.
Let's see Apple make their operating systems stronger than The Rock, such that even Nicolas Cage couldn't break into them.
This affects everyone (Android, IOS, Windows?) on the server side (but the fix isn'T that hard to do there, change the config), and most browsers on the client side. Wonder though how many servers actually allow this downgrade ?
More a configuration issue (just not allowing downgrade is enough to prevent this). Web servers shouldn't be offering this kind of low security anyway.
The name of the exploit is a bit crazy though.... Its not an easy attack to make.
Didn't this come up last year, or is this a new attack?
It is not really "new", since this is more a broken as designed issue (a quite old design); what"s new is that computers now make this attack easily possible :-).
A lot of web servers: https://freakattack.com/