Security Update 2014-002
support.apple.com
support.apple.com
Security - Secure Transport
Available for: OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.2
Impact: An attacker with a privileged network position may capture
data or change the operations performed in sessions protected by SSL
Description: In a 'triple handshake' attack, it was possible for an attacker to establish two connections which had the same encryption keys and handshake, insert the attacker's data in one connection, and renegotiate so that the connections may be forwarded to each other.
To prevent attacks based on this scenario, Secure Transport was changed so that, by default, a renegotiation must present the same server certificate as was presented in the original connection. This issue does not affect Mac OS X 10.7 systems and earlier.
CVE-ID CVE-2014-1295 : Antoine Delignat-Lavaud, Karthikeyan Bhargavan and Alfredo Pironti of Prosecco at Inria Paris
That doesn't sound good…
I feel like a lot of excellent applicable work is coming from the researchers at https://www.inria.fr/ Keep up the good work!
Curious. Isn't this a different update?
> We have confirmed that our attacks can be mounted on popular web browsers and HTTPS libraries, when they are used to perform certificate-based authentication at servers that enable both resumption and renegotiation.
I hope they've taken into account the fact that the value of a HTTP header can span multiple lines (RFC2616 section 4.2)
In SIP land, which copied HTTP then messed it up even further, there is no correct handling of such messages. Some SIP stacks will error, some will ignore, some will do it correctly. Thus you can't trust your proxy and server to come to the same conclusions and perform the same operations or apply the same security policy.
There's no good reason for line folding or comments. Protocols need only be human readable not human easily-composed-for-formatting. This isn't the 60s or early 70s where you're writing all emails and headers by hand.
No, but being so is incredibly convenient.
> This isn't the 60s or early 70s where you're writing all emails and headers by hand.
Again, no, but, again, it'd be very convenient to be able to do it.
HTTP isn't a programming language. It does not benefit from crazy syntax.
As for complexity... No. If your parser is non-trivial when compared to the rest of your stack, again, you are doing something very wrong.
I am not saying to implement full line editing or anything close that. I'd just like to point out that being able to sometimes manually interact with a server is very convenient.
Foo: ValueBegin (this is a comment)
ValueEnds
As far as performance, I must say you're incorrect. Review the nginx HTTP parser and you'll see all sorts of bitwise hacks in order to improve performance. This aligns with my own experience writing a packet capture system for a similar protocol.
Having open syntax, comments and line folding being part of the problem, incredibly complicates the parser. Other moronic things are the completely arbitrary handling of header fields. Some header fields allow their value to be split over multiple lines but must treat it as if it was one line. Others use multiple headers to provide some multi-line value. There's no simple parsing, it all must be sensitive to the context. This is just stupid, yet free-text protocol authors revel in it. SIP even publishes a "torture test" RFC where they're just oh-so-pleased with the edge cases their moronic spec allows. They even suggest a parser should guess as to the message sender's intent.
I'd also note that in some cases the parser is most of the stack (simple proxy scenarios, frontend security). Regardless, the fact that the rest of the stack may be complicated is not in any way an excuse for making the parser worse. This is not a programming language.
How much time does nginx spend parsing HTTP requests compared to waiting for network or disk IO?
> SIP even publishes a "torture test" RFC
This is actually very clever. I wish other protocols had something like it to help weed out partial and buggy implementations.
> They even suggest a parser should guess as to the message sender's intent.
This may be a little bit too much
> This is not a programming language.
A lot of incredibly powerful uses for technology come precisely from the unintended scenarios - the clever ways to abuse technology and force it to do something it was never intended to. Remember HTTP itself was conceived to do a tiny subset of what it does now.
Enough that they choose to use much more obtuse code? Not to mention network/IO scale independently so it's not a relevant comparison. I wrote a packet capture system that spent about 70% of its capture/index CPU budget on parsing.
A torture test is only clever if it's not absurd because of a thousand edge cases. Then it just reflects the stupidity in the protocol design.
Do you have any possible use of terrible parsing rules that encourage security holes? HTTP is commonly used outside browsers because it's a simple wrapper for a TCP-RPC model. Request something, get a response. And none of the features depend on the stupid parsing rules - absolutely no one and nothing benefits from that. Except perhaps contractors billing hourly.
They certainly had it profiled before they optimized it. There must be some numbers somewhere. "Enough" is hardly an acceptable answer.
The OP is about a Secure Transport bug, CVE-2014-1295.
So I guess Apple must have been using the OpenSSL library instead of their in-house Secure Transport library on the Airports!
Is there anywhere where Apple officially announces when they stop supporting an OS X version?
I was actually thinking more in terms of security and support.
PPC architectures are not very well supported nowadays, and haven't been for over 5 years. Perhaps longer. Sure, you can still run your machine on 10.5 and it might run really well still. That's no reason to trust it for mission critical tasks. God forbid if someone was using a OS X Server 10.5 and users trusted it with their credentials.
Vanity was pretty low on my list, but I understand everyone's priorities are different.
Not sure I trust Apple with longevity. Windows XP from 2002 just hit the dust and I've got a decade out of RHEL. For something from 2007 to be a write off is not good IMHO. I thoroughly regret my MBP purchase for theae reasons.
https://www.ruby-lang.org/en/news/2013/11/22/heap-overflow-i...