Re: Security with Streams
Re: Security with Streams
- Subject: Re: Security with Streams
- From: Jens Alfke <email@hidden>
- Date: Sat, 25 Jun 2016 18:12:18 -0400
> On Jun 18, 2016, at 2:34 AM, Gerriet M. Denkmann <email@hidden> wrote:
>
> 1. (important) the client really wants to know that:
> (1a) it is talking to the right server and not to some evil entity masquerading as the real server.
> (1b) the data it receives has not been tampered with on the way.
You want an SSL (aka TLS) connection, with the server providing a certificate (the typical setup.)
> 2. (less important) the server might want to know that the client connecting to it is a valid client.
> This might help if there are thousands of fake clients overwhelming the server with fake requests.
> But this is a kind of unlikely scenario.
For that you’d need the SSL client to provide a certificate too. This is supported by the CFStream APIs.
> 3. (hardly important at all) no one can read the data exchanged.
> The data exchanged it really not sensitive.
Well, you get that for free with SSL anyway :)
Accomplishing (1b) and (3) is straightforward, I think. The doc-comment for NSNetService says how to enable SSL/TLS for the sockets by setting the stream properties:
* To enable TLS on the stream, set the various TLS settings using
* kCFStreamPropertySSLSettings before calling -open. You must also specify
* kCFBooleanTrue for kCFStreamSSLIsServer in the settings dictionary along with
* a valid SecIdentityRef as the first entry of kCFStreamSSLCertificates.
*/
- (void)netService:(NSNetService *)sender didAcceptConnectionWithInputStream:(NSInputStream *)inputStream outputStream:(NSOutputStream *)outputStream NS_AVAILABLE(10_9, 7_0);
It doesn’t say so, but I’m guessing you need to set the kCFStreamPropertySSLSettings property on the client side too (but not IsServer or Certificates), otherwise the client will try to open a plain socket and the SSL handshake will fail.
The harder part is (1a) because it gets into the issues of “trust” and “identity”, which are quite deep and complex. Your server app will need to provide an X.509 certificate when it accepts a connection. The usual way to get these is from a certificate authority like Verisign or Comodo (or now, Let’s Encrypt), but they issue certificates for DNS domain names, and your server probably doesn’t run on a host with its own domain name, since you’re just connecting to it via a raw IP address. The other option is getting a cert for an email address, but those are marked as being for use only in signing mail messages, not for SSL.
We are now falling into the rabbit hole that is peer-to-peer trust & identity. How is your server going to identify it so that a client will know that it’s the server it expects? I don’t know whether you’ve given any thought to this; the answer affects how you’d implement this part of the app.
—Jens
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden