Anyone please explain the role of SSL pinning and App transport security.
I read that SSLpinning is used to ensure that the app communicates only with the designated server itself
With the release of the iOS 9, the App Transport Security library was also introduced. By default, ATS denies all insecure connections which do not use at least the TLS 1.2 protocol. The TLS protocol is a replacement for the SSL protocol, but still, both of them are often referred to as SSL. With SSL pinning in mind, there is no difference between having TLS or SSL as the underlying implementation - the basic concept remains the same.
So my question is
1. If my server is using TLS 1.2 protocol, then enabling ATS is enough for security. No need of doing SSL Pinning in my app. Please confirm
2. If my server below TLS 1.2 protocol, then SSL pinning is the best way to avoid insecure connections. Please confirm
Cert pinning makes sure your app is communicating with the correct server. Without Cert pinning I can set up an intercepting proxy to see all of the traffic flowing in and out of your app.
Pinning the cert makes sure I cannot do this as the app will only accept communications from the server the offers the correct pinned certificate.
then enabling ATS is enough for security
You can never have 'enough for security' but this part is contextual based on what your app is doing. If the endpoints and data your app processes is sensitive you should defiantly be cert pinning. I would argue you should always do it anyway as it is easy to do.
If my server below TLS 1.2 protocol, then SSL pinning is the best way to avoid insecure connections
This will cause problem with ATS, your server should really be supporting TLS 1.2 it is pretty ubiquitous now. You also need to make sure the cert is using at east SHA256 fingerprint with either a 2048 bit or greater RSA key, or a 256bit or greater Elliptic-Curve (ECC) key and you need to support one of these cyphers:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
This may look scare but in reality the above is pretty standard.
NOTE:
both of them are often referred to as SSL
You are correct but this is a bad habit. They might do the same thing but they do it in a different way. SSL is SSL and TLS is TLS, they are different.
NOTE 2:
If you do use cert pinning consider using public key pinning or CA cert pinning.
https://infinum.co/the-capsized-eight/how-to-make-your-ios-apps-more-secure-with-ssl-pinning
"With the release of the iOS 9, the App Transport Security library was also introduced. By default, ATS denies all insecure connections which do not use at least the TLS 1.2 protocol. The TLS protocol is a replacement for the SSL protocol, but still, both of them are often referred to as SSL. With SSL pinning in mind, there is no difference between having TLS or SSL as the underlying implementation - the basic concept remains the same.
Related
I was integrating Sign in with Apple in my mobile app. I followed the configuration steps provided in the developer portal and downloaded the apple-developer-domain-association.txt file and placed it on my server at the given path. Now the file is loading from web browser but I'm not able to verify my domain on Apple developer account. Its giving me an error message "Verification failed for domain".
Anyone got same issue? how to get verified sucessfully
To verify domain to configure Sign in With Apple apple-developer-domain-association.txt file must be accessible publicly.
https://{YOUR_DOMAIN}/.well-known/apple-developer-domain-association.txt
Make sure
Domains and domains associated with email addresses must comply with Sender Policy Framework (SPF) standards.
Must be accessible via https. http doesn't work.
No redirect not even to wwww. Example url mentioned above must serve the apple-developer-domain-association.txt file without any redirects.
Hint: if you are serving apple-developer-domain-association.txt with www than you must register domain www.{YOUR_DOMAIN} white configuring sign in with apple configuration on developer.apple.com. To do that you have to make sure www.{YOUR_DOMAIN} is SPF compliance.
In continues and addition to #Bilal
A. If the domain is not SPF compliant you will be noted immediately when trying to add it in the developer portal
B. If you not sure whether your site is redirected yo can check it in http://www.redirect-checker.org/ or just use postman and disable 'Automatically follow redirects' option in the request settings
C. Apple require that your server must support the Transport Layer Security (TLS) 1.2 protocol and one of the cipher suites listed below:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
For me the problem was the www redirect I had no clue our servers do that, my devops helped me solve this just for the verification.
Best solution IMO is just use your own relay microservice with a unique dedicated domain...
To expand on #MTZ4's response (upvoted BTW because you nailed it), here is the process that I needed to work through, with some pointers to anyone else not quite as familiar with working through these types of problems.
In my case, I had CloudFlare dealing with both the DNS and TLS cipher certificates and Heroku serving the site.
The first step is determining whether your TLS provider serves the appropriate TLS ciphers required by Apple.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
One of the easiest way's to do this is by using SSL labs certificate checker. Simply enter your root domain and let the report run (takes a few minutes). In the report response, look for the section Cipher Suites and verify the TLS ciphers Apple wants are available. In the image below you can see them in orange and marked as weak.
You can ignore the weak status, this is because these ciphers do not use ephemeral keys and will not be used in TLS 1.3.
If you want a more comprehensive test, install NMAP and then download the ssl-enum-ciphers script. After installing NMAP and downloading the script, execute the script against your domain:
nmap --script ssl-enum-ciphers -p 443 my-root-domain.com
This produces a result set that looks like this:
Once again look for the TLSv1.2 section and check your list of ciphers against Apple's list. If they are not present (they are missing in the image above), then that is where your problem lies.
So how to fix? Well there are a few options and it all depends upon your TLS provider, which may be your web host or may be your DNS host depending upon your configuration.
For us, we are using CloudFlare as our DNS provider. CloudFlare also provides the TLS ciphers. Because CloudFlare does not support the ciphers Apple requires (the NMAP image above) and they won't add them due to their security concerns about TLS 1.2 and moving to TLS 1.3, we had to disable CloudFlare's proxy service to allow the TLS certificates that were being provided by our hosting service (Heroku).
This turned out to be easy. Just logging into CloudFlare, going to the DNS entries and changing the traffic routing behavior (click the orange cloud to make it grey for verification, then click it again once verification is done). For more information see CloudFlare's support page.
After doing this, Heroku was serving the TLS ciphers, which include the Apple required ones (as shown in the SSL Labs image above).
Ultimately whoever is serving your TLS ciphers must include the ones Apple needs. If your tests above don't show the correct ciphers, check your DNS/TLS service and your hosting provider to see if they support them. If they don't, then you may need to switch.
Finally, it is also worth noting that in Apple's developer portal, when you click the download button for the verification file, do not click it again! Each time you click the button, the verification file changes as it seems to be dynamically generated.
Just fix all the TLS issues, then log into the Apple developer portal, download the file, upload to your server and then verify.
I did end up working with Apple support on some of this and they are looking at adding some documentation to the verification page that states what ciphers are needed so others don't hit the same problems.
I'm running node js and express and had the issue because I bought a cheap SSL cert from Sectigo.
Here's what I did to fix it.
Check your SSL certificate for errors https://www.digicert.com/help/
I had to install an intermediate certificate. That solved the issue.
If you perform the check in Safari, it won't give you a confirmation that the domain is verified.
Instead, perform the check in Chrome and it will give you a confirmation.
Inspect the HTTP header coming back from your server. If it's a 301 Apple won't follow it. Instead, the verification file must be returned via 200 HTTP status code. The verification file I'm referring to is https://example.com/.well-known/apple-developer-domain-association.txt where example.com is your domain.
If you are using Cloudflare free tier, upgrading to the PRO plan (currently $20/month) does the trick. All their paid plans include the required ciphers.
And of course, you can always cancel the plan after verifying and go back to free.
As per my understanding, SSL Pinning is to compare the public key or certification of a server with the copies bundled in the client beforehand.
I saw in Stackoverflow that many developers use SSL Pinning by AFNetwork libraries, but most of them use it along with a self-signed certificate.
I have bought a valid certificate from a CA and passed the test to verify it worked fine. I mean, I set the following and it worked
...
_sharedHttpsInstance.securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone];
_sharedHttpsInstance.securityPolicy.allowInvalidCertificates = NO;
...
What I am wondering is that if set the Pinning mode to AFSSLPinningModePulicKey, my application would be more secure in communication with the server in addition to what the valid certificate have provided?
thanks a lot.
I'm don't know the exact implementation of SSL pinning in iOS, but in principle pinning provides definitely more security than the default verification against a set of builtin certificate agencies. By default systems trust more than 100 different CA from all over the world and each of the CA has the ability to issue any certificate it wants, even if another CA has already issued the same or a similar certificate. So if any of these 100+ CAs gets compromised they can issue a certificate for your domain, which would pass the checks in your application unless you use certificate pinning. Such compromises happened in 2011 with DigiNotar (no longer existent because of that) and Comodo (was too big to fail).
Probably the most prominent user of certificate pinning is Google Chrome, where it is used for the google domains and this helped to detect the compromises of DigiNotar and Comodo.
A downside of certificate pinning might be, that the application will stop working inside networks which do SSL interception for security reasons. Google Chrome seems to deal with this situation by accepting the certificate if it is signed by a CA explicitly added by the user (i.e. no builtin) alternatively to the pinning checks.
Another question which might be interesting is if SSL pinning is secure 'ENOUTH' for 'Most' of the application, even if working along with self-signed certification?
Checking against a fixed certificate or public key (e.g. certificate pinning with or without self-signed) is more secure than only checking if the certificate is signed by any of the 100s CAs trusted by the system. And as long as the developer has full control about both sides (e.g. application and server) it also scales well. The only advantage of additionally using the usual infrastructure is the use of the certificate revocation mechanism. But because the developer has control of the application (s)he could just replace the appplication in case the certificate gets compromised. So yes, in most cases it is secure enough do do SSL pinning with a self-signed certificate and it is more secure than using the standard certificate validation without pinning.
It's very difficult to say categorically whether pinning is better or worse, since it shifts the risk to a different party.
Pinning will essentially protect you better against a potential breach in any of the CA you trust. If a CA is compromised and made to issue a certificate for the host you're trying to contact, pinning will protect you against that because you will compare with the specific reference you've pinned, instead of going through the CA.
The downside is that it will prevent you from using the mechanisms in place at the CA to deal with a compromised host: certificate revocation. If the host's private key is compromised, going through the PKI verification mechanism should allow you to check for revocation, and be warned that such a problem happen. In contrast, you won't be able to know that with pinning, since you're not going through the CA to check the certificate at all.
Of course, you could combine both approaches, but this could cause additional problems (you'd need a strategy to deal with conflicting outcomes in both evaluations, otherwise a compromised CA revoking a valid cert could cause a DoS).
I don't know whethet AFNetworking's pinning mechanism replaces the PKI validation or complements it.
In general, choosing between using pinning or PKI validation depends on whether you think that particular host's private key is more or less likely to be compromised than the CAs you trust.
Another downside of pinning is that you need to update the application (or let the user "re-pin") every time the server certificate (or at least the key-pair, depending on what you've pinned) is changed legitimately. It's probably not a bad idea to re-key once in a while.
(To be clear, I'm not saying that CAs are better, just that pinning changes the set of problems.)
I understand the use and necessity of SSL Certificates. I am looking for a detailed explanation of the relationship between http protocol and SSL Certificate and also between https and SSL Certificate.
In AFNetworking defining _AFNETWORKING_ALLOW_INVALID_SSL_CERTIFICATES_ allows invalid certificates.
Assuming this flag is not set, the library should deny invalid certificates by default. But what if the server has no certificate installed at its end? I see that I can access a server with no certificate using http protocol.
And does the default certificate validation occur for https protocol only?
I want to access only those servers with a certificate and which are valid over http and https? Is this feature required and if so is it possible?
I think you don't understand what HTTP and HTTPS are about:
http is the session protocol to communicate with servers without encryption. Everything is sent in the clear and there is also no way to verify the authenticity of the server (i.e. that the server responding is indeed having the correct hostname). A server doesn't need an SSL certificate in this case.
https is used when you want to ensure that communication with the server is encrypted. For this, the server needs an SSL certificate and before anything is sent over the HTTP session, a handshake will take place allowing the client to fetch the SSL certificate of the server in order to encrypt the data that is sent. So an SSL certificate is only used for HTTPS connections.
It is also possible to verify the authenticity of the server, depending on the SSL certificate used. All browsers (and by default on iOS, unless you explicitely change this in your app) will only accept SSL certificates that have been issued by known certification authorities. This way you can be sure that the server is indeed located at the hostname you requested. Depending on the SSL certificate the owner of the server might also be verified (i.e. that the server indeed belongs to the company it claims to belong to).
I'm fairly new to SSL and secure connections in general. What are the major steps required for an iOS app to talk to a server over a secure communications channel?
I'm aware that an SSL certificate will probably be necessary. I'm planning to purchase one from a trusted certificate authority. However I'm not sure if both the app and the server need certificates or if it's just the server. Also I'm not sure how to handle SSL errors. Perhaps there's a library that can help with this like ASIHTTPRequest or similar.
If you are using HTTPS as your protocol for communication and have valid certificates on your server all that should be required is changing your http:// to https:// on your client. For HTTP libraries a very popular option now is AFNetworking. It is a bit better maintained than ASI and has some nice block features not supported by ASI.
As far as SSL errors, it is usually a good idea to present the warnings to end users (through alert views or some other means). They could point to real security attacks (but more likely will point to miss configured or expired certificates).
So i was sniffing through the pages of PKI's Overview by Joel Weise (http://highsecu.free.fr/db/outils_de_securite/cryptographie/pki/publickey.pdf) and one thing i didn't quite get is, when to use an OCSP responder over LDAP for checking up the validity of a given certificate ? Say some CA exposes both - when to use the OCSP service, when to use the Certificate Depositories LDAP servers ?
It might be helpful to think this way.
The Certificate Authority generates certificate revocation lists (CRLs). (You could query the CA directly but this is a bad idea due to risk of exposing private keys (secrets)).
The CRLs can then be made available via LDAP or HTTP. (if you have a small deployment you can likely stop here)
An OCSP server (or validation authority depending on the vernacular) can also consume CRLs. Once it does so it can handle validation (certificate status) requests. (if you have a larger deployment and handling CRLs is cumbersome you might consider this option)
There are options (3rd parties, e.g. not Microsoft) for there to be distributed OCSP responders that have pre-signed the responses and then forward and store (as opposed to multiple OCSP servers). (consider if you still have a relatively larger deployment and where you have network availability, scale, loading issues as another option).
Finally make sure that you are not only checking certificate status but also certificate trust. In federated environments you may want to consider the Server Certificate Validation Protocol (SCVP) as a complement to the above.