Re: Security with Streams
Re: Security with Streams
- Subject: Re: Security with Streams
- From: Jens Alfke <email@hidden>
- Date: Sun, 26 Jun 2016 16:11:49 -0700
> On Jun 25, 2016, at 7:44 PM, Gerriet M. Denkmann <email@hidden> wrote:
>
> Following TN2326 I created a (self signed) Certificate Authority and a Digital Identity called "MyServerId".
You probably used the Keychain Access app for this? That works fine, but you’ll probably want every instance of the server app to create its own key-pair and cert, and you don’t want the user to have to use Keychain Access. I’ve got some utility code in my MYUtilities library that will create an Identity (key pair + cert) programmatically:
https://github.com/snej/MYUtilities/blob/master/MYAnonymousIdentity.h
The MYGetOrCreateAnonymousIdentity() function returns a SecIdentityRef you can use with CFStream.
> Absolutely not sure whether the code above is correct, but it seems to be working.
That was fast! This is frustrating stuff to implement. Or maybe the docs have gotten a lot better recently ;-)
> Currently (as indicated in the code above) my client has a copy of the real server certificate and compares it with the certificate obtained from its inputStream.
> I am not sure whether putting the server certificate into the client is ok or a breach of security.
It’s fine; the certificate is public and intended to be shared. It’s the private key that’s sensitive. What you’re describing is called “key-pinning”: restricting a client to connect only with a server with a known public key.
If every instance of the server has its own key, then embedding a cert in the client app doesn’t work. What’s usually done is to have the app store a copy of the cert the first time it connects to the server (with the user’s approval), and then require the same cert every subsequent time it connects. (This is similar to what SSH does, where the first time you connect to a host it tells you the key is unknown and asks if you want to trust it.)
The situation you want to watch out for is where the client connects to a server it’s already connected to, but the cert’s public key doesn’t match the previous one. This is where you sound the alarm to the user — either someone’s trying to spoof the real server, or perhaps the server lost its keys and had to create a new cert (maybe its disk crashed and there wasn’t a backup of the keychain.)
—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