News for hackers. Stuff that matters.

xenolinguist

Speaking for the rare minority of folks who care about coding on Apple's other OS - this issue is trivially reproducible in OS X Mavericks with identical behavior. It's not just for iOS devs!
I'm one of the guys who helped isolate the problem that led to this bug report, and here's my take:

I agree, this is not a vulnerability; it prevents legitimate connections rather than allowing illicit ones.

Your "3rd party" remark doesn't make sense to me; In our case, we control the entire PKI, so both the client and server certificates are issued by our own "1st party".

And it's definitely a bug - no quotes. The client is _not_ the party canceling the connection; it's failing to send a necessary signature verification message to the server during handshaking, which causes well-behaved _servers_ to send a fatal alert to the _client_. On the SecureTransport side, the library then downgrades the SSL version and tries to connect again.

Note that I'm not suggesting the root bug is "implement ECC"; the root bug is the fact that NSURLCredential and/or NSURLConnection accept identities with invalid keys. The failure shouldn't be occurring 3/4 of the way through TLS handshaking, but at a much higher level where the next guy to run afoul of this won't lose a week to trying to figure out what they did wrong, when the real answer is (most likely) "You're using an unsupported key type".

PS - The same issue is verified to exist in OS X as well as iOS.