[tptacek]

While this is a "bug" pertaining to "security", it doesn't look like a vulnerability; rather, if I'm reading it right, it looks like a compat/interop flaw: if your app uses TLS client certificates (like 0.001% of all apps) to talk to a 3rd party server, and you use ECC ciphersuites, the iOS SecureTransport library aborts the TLS connection.

Here's how big a deal this bug is: the feature they're talking about apparently flat-out doesn't work, they were the first people to figure that out, and this bug is the only place on the Internet that currently documents the fact.

In other words: not necessarily that big of a deal.

It's too bad, I guess, because more mobile apps should take advantage of TLS client certs; custom code that talk TLS can use them much more easily than browsers can.

[xenolinguist]

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.

[tptacek]

I wasn't scare-quoting.

By "third party", I simply meant "server software not running on iOS". I wasn't referring to the PKI, which isn't actually implicated in this bug report.

The client isn't aborting the connection directly, but it is indirectly doing so by failing to complete the TLS handshake properly.

I'm not sure what the user-visible difference is between this failing mid-handshake versus failing when SecureTransport is configured, but I see what you mean about being annoying to debug.

The most likely reason you're the first person figuring this bug out even for OS X (unsurprising, given that SecureTransport is shared) is that most OS X browsers don't use SecureTransport, but rather NSS, which does have workable ECC client certs.

As you've discovered, client certificates are a bit of an exotic feature.

[cr3ative]

Absolutely, the radar title of "TLS Mutual authentication with EC Keys fails" is much more appropriate.

[chime]

So the app/user just thinks it is a network/connection error?

[tptacek]

It basically is a network/connection error. At this point in the transaction, neither side has had a chance to reveal anything sensitive.

If I understand the bug properly, basically all this says is "if you want to use client certificates with an iOS app, you have to use RSA".