I am reading the documentation for both push using TLS certificates and push using authentication tokens
But besides explaining how to configure each, the articles don't really explain the differences or pros/cons of both approaches. Can somebody explain them to me?
Token-based authentication is newer and essentially simplifies APNS authentication.
It is based on a public and private key pair that you can generate on your Apple developer account.
Here are the main reasons why it is simpler:
The same key can be used for development and production apps whereas
different certificates are needed when using certificate-based
authentication.
The same key is used for all your apps referenced in your Apple
developer account. Certificate-based authentication needs one
certificate per app.
The key does not expire. Certificates do expire and need to be renewed every year or so.
A good source of intel is the 2016 WWDC video regarding APNS:
https://developer.apple.com/videos/play/wwdc2016/724/
For 2020, you can only realistically use the "token" method. The older approach is legacy and they will probably axe it.
Your private key will look like this
let keystring = `-----BEGIN PRIVATE KEY-----
MIGTAgEAMBMGByqGSM49Aas8d76as8das687asd687asd68as8brwUIWA46qcXis
zCu6dbd4s8d7b5s86gf98ugtr28re7089a7d6tbvpiiui524kyfpq9861eFJP7we
eE7rX4182609457ohgyj3lhgp98wfb698bfg69287f2k4htgwpo876grwo7XDklz
9fdg689d
-----END PRIVATE KEY-----`
your key id will look like this
let keyId = "CTU7XXBPRH"
and your Apple team id is your usual Apple team id, which looks like "YWD3UUTEWD".
Nowadays - thank goodness - it is relatively easy to get the private key and key id from inside your company's account on the Apple developer website.
If you want to test sending a push on an ordinary Node server on AWS, I strongly recommend this outstanding new npm, APNS2 https://www.npmjs.com/package/apns2
let bn = new BasicNotification(deviceToken, 'Hello')
It's about that easy to send pushes.
Tips:
Don't forget the damned "development/sandbox" pushes only work ON AN IPHONE TETHERED TO YOUR MAC/XCODE!
development/sandbox pushes - only for an iPhone tethered to your Mac with a build running from Xcode
production pushes - they do work completely fine with TestFlight builds.
Additionally: don't forget that the so-called development/sandbox pushes are often flakey. Often, they don't arrive for hours, they don't arrive at all, they simply don't work in many regions.
Don't forget that it is TOTALLY OK to use the "production" ones, simply, with a TestFlight app.
So
Make a build
Push it to your TestFlight account. Wait a few minutes as usual until the build comes through,
Install it from TestFlight to your phone
You will now get all the pushes - instantly!
Whereas if you
Make a build
Just build/run to your tethered iPhone
You do NOT get any pushes.
It's true that you can get the so-called "development" pushes, but they are often very flakey.
(To be clear, when using APNS2, if you do want to try "development" pushes, to order "development" pushes, simply use the extra line of code explained at the bottom here https://www.npmjs.com/package/apns2 )
In 2021, Apple's Setting Up a Remote Notification Server state
Both techniques have advantages and disadvantages, so decide which technique is best for your company.
Both Fattie and Ika have said that TLS/ Certificate based authentication is inferior. The Project UI in Firebase also uses language which doesn't explain much IMHO:
Configuration with auth keys is recommended as they are the more current method for sending notifications to iOS
Benefits of Certificate Authentication
Limited access certificates. Each certificate is tied to one application in your developer account and environment (development/ production). This avoids putting all your eggs in one basket, if your token auth key is compromised, a threat actor can push notifications to all your applications.
Simpler Provider application logic. The provider (service which interacts with APNs) (either your own server or a service you use) can just use the TLS certificate, and authenticate, without needing to create JWTs, add headers to the request or find the correct App ID to use.
Benefits of Token Authentication
Simpler setup process: because you only have to download a .p12 and use it your application. Go into developer.apple.com, create a Push Notification Key. However, your application has to renew these tokens every hour. Creating a .p12 for TLS authentication is a little bit more involved.
Does not expire, so you can set it and forget it. Whereas TLS certificates expire in 1 year by default.
The question boils down to security vs. convenience.
Convenience (use token auth): It's convenient to create a key and forget (token auth), and you might use Firebase (or another service) to actually renew the tokens every hour, so you don't have much work to do.
Security (use TLS auth): Do you really want to share the same key between all your applications? What if you want to limit the scope of a Push Notification Service Provider (e.g. Firebase, Ably, Pusher), but don't trust giving them access to all your applications. In reality, you might just have 1 application, so it does not matter.
Does this kind of even security matter, or is it just more convenient to use Token Auth? I would say in most cases, go with Token auth.
Related
In iOS, if pinned SSL certificate expires, do I need to re-submit the app? Will the apps with old version continue to work or will not work unless they are updated?
That entirely depends on how you pinned the certificate. Pinning a certificate means checking the certificate and its chain against a set of designated requirements that determine whether the new certificate should be accepted. There are nearly an infinite number of ways to do this, and thus nearly an infinite number of ways to shoot yourself in the foot while doing so.
As a rule:
If you are checking to see if the certificate's public key matches, you're fine as long as the new cert has the same public key. This is normally the simplest approach to get right, because you have the power to guarantee that a key under your direct control does not change. However, be aware that some automated certificate updating tools generate new keys by default.
If you are comparing the entire certificate, it will likely break, because obviously some aspects of the certificate (minimally, the expiration date) will change.
If you are comparing specific aspects of the certificate, such as the public key of the CA cert that signed it, it may or may not break, depending on whether those designated requirements match.
Be aware, however, that CAs periodically rotate out their signing keys to limit damage in the event of a key getting compromised. What this means is that the specific CA cert key that you pinned may not be the one that gets used to sign a subsequent certificate. And if you are doing this in an automated fashion, it isn't a question of whether you will break, but when.
For this reason, if you feel the need to do key pinning, it is strongly recommended that you pin only keys that are under your direct control, and that you force any automated update tools to reuse the existing key pair.
No. once you install ssl on your site or renew old one, it will start working. no need to resubmit the app.
read more at SSL Pinning and certificate expiry
I'm debating and need to know the implications of not using the SCEP protocol for the mdm enrolment, more precisely the Identity certificate (the certificate credential used for authentication). I'm talking about the certificate in the Identity section on IPCU, as shown in the image below, with the red arrow.
I wont be pushing down profiles with sensitive informations (like vpn, email, etc configurations and/or passwords).
My use case will be 99%:
Block/unblock apps by rating
Lock/unlock device
Block/unlock web domains
From reading around StackOverflow (here and here) the following scenarios can happen.
If someone get access to the certificate he will be able to impersonate an enrolled device, but he will only be able to receive commands/profiles and not initiate commands/profiles. Am I right?
A man in the middle attack can get access to the certificate
The advantage of using the PKCS12 embedded within the profile is that it is faster to implement and no external dependencies (SCEP server) but I'm not so sure about the disadvantages. So my questions and doubts is:
What can a malicious person do with the private key from the Identity certificate?
Can it be a security breach going with the PKCS12 embedded approach?
This is mostly a question of SCEP vs PKCS12 embedded within the profile, pros and cons.
Here my thought on that:
1) If you are building a prototype or a small not critical service then go with PKCS12.
2) If you are building a serious product (production and touching devices of people with sensitive info) then go with SCEP (you can get a free SCEP servers. It's not that complex).
Frankly, If I was on the dark side (trying to hack it) I don't think that I would attack PKCS12 vs SCEP (it's not the weakest link)
However, let say, I say I decided to try to hack it
I would try to do man in the middle. I will try to capture communicarion, save PKCS12 and password for it
I will use it to authenticate to MDM server.
You are right, I can't trigger any commands, but I can start probing your code to find where you skipped some security checks. Maybe you don't check that a certificate matches a device UUID and so on.
Hopefully, I will find enough security holes to do something (let say trigger actions for other users). Maybe I will send them Wipe command or may be I will try to install a root CA + HTTP proxy configuration to see all their traffic.
Anyhow. I don't think that it's that weakest link and it requires a lot of additional step to get to some interesting stuff. However, if you get there, you can do A LOT.
As a result for a serious product, it will make sense to invest several additional weeks in SCEP.
I'm working on an iOS app with a rails backend, running on a VPS (via my own domain).
My question is: is it insecure to use a self-signed SSL certificate on my server and ignore the warnings from NSURLConnection while communicating with it, considering that this is a private API which is only accessible via my iOS app?
The safe way to go in this scenario is: Sign it yourself and manually add the certificate to the local certificate database of every system you work from, so you don't need authentication to know it's yours. Sometimes this can be done automatically as easily as checking the box "ignore the warning for this certificate" the first time you connect from each system, which will prevent you from seen it again on that system unless the certificate changes.
This way you won't see the warning again, unless it's somebody else's self certificate you're looking at.
Ignoring the warning by default usually means that if somebody else signs its own certificate and presents it to you, you will go along without even noticing. Not a good idea.
If you auto-enroll an account for an X.509 certificate in a Windows PKI environment, do you get the same certificate (and, by extension, private key) on every computer in the domain that you log into, or does a different certificate get issued for each computer you log into?
I would expect there would be a single certificate that would appear in the CurrentUser certificate store on each computer you logged into. But this is a matter of dispute and I don't have an environment where I can test it.
Are there any subtleties of configuring the certificate template that affect this? Does not using roaming profiles affect this?
If it matters, I am most interested in how this works for service accounts, but I expect it would be the same as for interactive user accounts.
Our PKI is currently Server 2003. It should be migrated to Server 2008 within a year.
Win2K3 does support something called "credential roaming". I haven't investigated it myself, but did come across a document explaining it: http://technet.microsoft.com/en-us/library/cc700848.aspx
I need to establish a HTTPS 2-way SSL connection from my iPhone application to the customer's server.
However I don't see any secure way to deliver the client side certificates to the application (it's an e-banking app, so security is really an issue).
From what I have found so far the only way that the app would be able to access the certificate is to provide it pre-bundeled with the application itself, or expose an URL from which it could be fetched (IPhone app with SSL client certs).
The thing is that neither of this two ways prevent some third party to get the certificate, which if accepted as a risk eliminates the need for 2-way SSL (since anyone can have the client certificate).
The whole security protocol should look like this:
- HTTPS 2-way SSL to authenticate the application
- OTP (token) based user registration (client side key pair generated at this step)
- SOAP / WSS XML-Signature (requests signed by the keys generated earlier)
Any idea on how to establish the first layer of security (HTTPS) ?
Ok, so to answer my own question...
It turned out that the security has no fixed scale of measurement.
The security requirements are satisfied as long as the price for braking the system is significantly above the prize that one would get for doing so.
In my situation we are talking about e-banking system, but with somewhat low monthly limits (couple of thousands USD).
As I mentioned in my question there would be another layer of security above the HTTPS which will feature WSS XML-Signatures. The process of registering the user and accepting the his public key is also done in several steps. In the first step the user sends his telephone number together with a cod retrieved somehow from my client. Then an SMS is sent to the user with a confirmation code. The user enters the confirmation code into a OTP calculator that would produce OTP code which will identify the user. Then the public key is sent to the server together with the OTP code. From here on every request would be signed by the private counterpart of the public key sent to the server earlier.
So the biggest weakness for the whole process is that of someone reverse engineers the application and retrieves the client certificate used for the SLL. The only problem arising from this is that someone might observe users' transactions. However in order for someone to make a transaction he would need the user's private key, which is generated, encrypted and stored into the keychain. And the price for braking this security level is VERY HIGH.
We will additionally think on how to protect the users' data on a higher level (e.g. using WSS Encryption), but for the start I thing we are good with the current solution.
any opinion ?
regards
https doesn't really work this way. In a nutshell, you attach to a secure server where the certificates are signed by a well known authority.
If you use Apples (iPhone) classes for this, they will only accept 'good' certificates. By good, I mean what Apple deems as acceptable. If you don't use them (there are alternatives in the SDK), you won't be able to connect (except, maybe, in the case where you have an 'Enterprise' developers license - but I can't say that with 100% certainty as I haven't looked enough at this license to be sure)
To continue, use your https connection to your correctly signed website and then institute some sort of login with a built in username/password, or challenge/response based upon the unique ID of the iPhone (for example) and exchange keys using that connection.
Note that this means that your application will have to query for new certificates at (each connection/every X connections/every month/application specified intervals) to keep them up to date. You can then use these certificates to connect to the more secure server.
[edit]
Check this post - may have more information about what you're asking to do
[/edit]
[edit2]
Please note that the request is iphone, not OSX - app store approval is an issue
[/edit2]