

iOS security bug – TLS mutual-auth fails with client elliptic curve keys - josephhainline
http://openradar.appspot.com/radar?id=5276828226813952

======
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.

------
mdriley
This is a bug in NSS. Here's the corresponding bug I filed against Chromium:
[https://code.google.com/p/chromium/issues/detail?id=349775](https://code.google.com/p/chromium/issues/detail?id=349775)

~~~
tptacek
Wait, nobody does ECC client certificate TLS right?

~~~
davidben
It's been fixed, but that was a bug in Chrome's NSS glue between NSS and the
OS X native key store. (The fix is under third_party/nss, but no one else
carries that particular file.) As far as I know, it works fine on other
platforms and in NSS itself.

------
josephhainline
If you're an iOS dev, would really appreciate a dupe of the rdar. It's been an
issue for a long time, apparently, and Apple needs some pressure to fix it, or
at the very least stop saying it works and document the error.

If you want to see the error in action, check out
[https://github.com/josephhainline/AppleBugTLSConnectionFails...](https://github.com/josephhainline/AppleBugTLSConnectionFailsWithEllipticCurveClientCert)

~~~
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!

