Peer-to-peer SSL/TLS best practices/strategy
Peer-to-peer SSL/TLS best practices/strategy
- Subject: Peer-to-peer SSL/TLS best practices/strategy
- From: John Pannell <email@hidden>
- Date: Tue, 11 Dec 2012 21:54:13 -0700
Hi all-
(tl:dr - I'm looking for advice on putting a .cer or .p12 file, issued from a CA or self-signed, into my app and using it to secure peer-to-peer communications without the user encountering allow/deny warnings. All help appreciated!)
I'm working on an application for OS X and iOS that utilizes peer-or-peer networking to achieve much of its functionality. I currently have the networking framework tested and functional for my purposes on both platforms, and I'm now in the process of adding support for secure transmission. I am using NSStreams and dropping down to CFStream when needed.
I have successfully taken a self-signed certificate and used in in my test application to "secure" the streams, in that I've confirmed that the traffic is encrypted during transmission. This has been done by setting the correct stream properties at the CFStream level.
Of course, my test application presents a security prompt for allowing trust of the certificate (always allow, deny, allow) for each stream pair I open. I figured that when I got a legitimate certificate, this would clear up as it would have a trusted root. The thought of getting a cert, however, got me thinking:
1. A certificate is issued for a domain... these peer-to-peer connections will not have the correct hostname. How will I pass a test against hostname?
2. If I have to override TLS Chain Validation, do I even need to purchase and use a commercial certificate with a trusted root?
3. Do I even know a commercial cert will prevent the allow/deny warnings? Or a self-signed cert?
I have found the following relevant documentation:
http://developer.apple.com/library/ios/technotes/tn2232/_index.html#//apple_ref/doc/uid/DTS40012884-CH1-SECCUSTOMCERT
This notes that peer-to-peer suffers as described above, and suggests that a developer 1) establish some other trusted channel to get cert, 2) fetch cert from trust data, 3) get cert data from cert, and 4) compare data to that received from other channel.
http://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/NetworkingTopics/Articles/OverridingSSLChainValidationCorrectly.html#//apple_ref/doc/uid/TP40012544-SW1
This provides information on how to correctly override TLS Chain Validation.
I now see that it should be done, can be done, and ways to do it, but I'm still not entirely sure of the best way to achieve the goals (secure communications, no allow/deny warnings, no hacking/attacking). Here are the options I see:
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. Pros: can let the streams perform default chain validation, as the purchased certificate will have a valid root. Cons: Could a mischievous individual extract the .cer file from my app and start crafting a malicious app to talk to mine? Will this prevent the allow/deny warnings? I think so, but am not sure.
2. I could create a self-signed CA certificate, and use it to generate self-signed SSL certs. Embed in app. Add CA cert to trusted roots. Perform trust validation myself per docs. Pros: I can wrap these in .p12 file - even if someone pulls the file out of my app, they'd still need the password to access contents (perhaps I could do this with the commercial cert too?). Cons: full chain validation override.
3. I'm sure there are more options :-)
If anyone could advise, I'm very interested to know best practice for securing peer-to-peer connections, embedding the right type of certificate file, and avoiding warnings to the user (all performed at the CFNetwork level). All help appreciated!
John
_______________________________________________
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