Re: Security with Streams
Re: Security with Streams
- Subject: Re: Security with Streams
- From: Keary Suska <email@hidden>
- Date: Sun, 26 Jun 2016 22:12:07 -0600
> On Jun 26, 2016, at 9:13 PM, Gerriet M. Denkmann <email@hidden> wrote:
>
>>
>>
>> Self-signed certificates can only offer encryption, but cannot offer trust because they are not verifiable. You can’t use the server certificate as a key since you pass that key out to anyone who wants it (in your app), and anyone who gets it can impersonate the server.
>
> Assume that an evil entity has got hold of “MyServerCertificate.cer”, but has no access to my keychain and thus to the private key of MyServerCertificate.
> Could they use this certificate to open a secure stream to a client? Or do they need the private key to sign?
To clarify, I was pointing out two weaknesses that come out of self-signed certificates, and in the latter case how comparing an embedded certificate/key with the server’s public certificate/key would not offer any security if it were self-signed, as you would be using the cert as a passcode that anyone can easily have. With a verifiable certificate you wouldn’t normally have these weaknesses and you get server verification (usually called “authentication”) as part of the SSL/TLS protocol so you don’t have to code for that case (though you may need to be explicit that you want certificate verification if it isn’t the default).
For the latter part of the question, in asymmetric encryption schemes, the private key is certainly needed to decrypt but does not authenticate. If you permit ad-hoc connections from the server to the client, the only way to authenticate the server would be by the server providing a client certificate and that being verified by a third-party. Even a self-signed client certificate does not provide authentication as it too is tantamount to using the certificate as a password that you give you to anyone who buys your app. Now, normally, the communications would still be encrypted and difficult to decipher, as long as you are comparing signed certificates, but if the certificate ever changes you now have to redistribute the new signed certificate.
I would also reiterate that when using SSL/TLS you don’t need to bother with key verification such as what ssh uses, since ssh uses those methods precisely because it does not rely on third party authentication so requires the client and server to agree that the connection is valid even though neither can actually guarantee that it is the case. This would be more similar to my peer-to-peer example, where trust is agreed upon before communication proceeds. SSL/TLS is also more robust in this case because the certificate can change at any time (which will periodically happen every 1-5 years anyway) but the server can still be correctly authenticated.
HTH,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
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