Re: Peer-to-peer SSL/TLS best practices/strategy
Re: Peer-to-peer SSL/TLS best practices/strategy
- Subject: Re: Peer-to-peer SSL/TLS best practices/strategy
- From: "Quinn \"The Eskimo!\"" <email@hidden>
- Date: Wed, 12 Dec 2012 11:07:06 +0000
On 12 Dec 2012, at 04:54, John Pannell <email@hidden> wrote:
> 1. I could purchase an SSL certificate, embed it in my app, and set the kCFStreamSSLPeerName on the stream to match the domain on the certificate.
No. You're missing one of the key points about TLS, namely that it involves digital identities (certificate + private key). Specifically, the server must, and the client may, apply a digital identity to the connection, the result of which is that the remote peer gets a copy of the identity's certificate and knows that the local peer has the private key associated with that certificate. In general it's safe to embed a certificate in your app (it's basically a complex wrapper around a public key). However, it's not safe to embed an identity in your app. There are two serious gotchas:
A. Someone could reverse engineer your app and extract the identity.
B. All copies of your app behave the same, so the user might be communicating with person A1 when they expected to be communicating with person Al [1].
In a peer-to-peer app you must have each app generate its own identity. That avoids both problem A and problem B. The main issue is that generating an identity is not easy.
The option I like the best is to create a web service that issues identities to email addresses. The workflow would look something like this:
1. user starts your app
2. your prompt them for their email address
3. you send an identity request to your web service
4. your web service sends the user an email
5. user clicks a link in the email to verify their email address
6. the web service issues the user a certificate, signed by the web service's custom root certificate
7. the web service sends the user the certificate and its associated private key, wrapped up in PKCS#12 blob attachment; this attachment does not have with the standard extension/MIME type, but a custom extension/MIME type that's claimed by your app
8. the web service optionally forgets the user's private key (things are more secure if you forget it, but it's not as easy for the user to refetch their identity if they lose it)
9. user opens that attachment in Mail
10. your app gets the PKCS#12 and installs it in the keychain ready for future use
This approach has a number of important advantages:
o The crypto heavy lifting is done on the server hosting your web service, which presumably has a fully-featured crypto toolbox.
o It works equally well for iOS and Mac apps.
o It actually gives you some real security; when connecting via TLS, you can a) verify that the identity was issued by your custom root certificate (it's safe to embed that in your app), and b) show the local user the email address of the remote peer and faithfully tell the local user that the remote user controls that email address.
There are, of course, some significant drawbacks:
o It's a bunch of extra work for you.
o The user must be online during the setup phase.
Share and Enjoy
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
[1] This happens a lot in the real world. In addition to my work email address of <email@hidden>, I also have the alias <email@hidden>. I receive a whole bunch of weird and wonderful emails at that address.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden