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.
Related
When i try to access my ruby site from android mobile device i get following error, can anyone help me solving this problem.
With following added error NET::ERR_CERT_AUTHORITY_INVALID
You need to add intermediate certificate file in your nginx configuration. Here is the powerfull tool by zakjan to obtain the intermediate certificate files using your main certificate, Store obtained crt file to your server and mentioned it in the nginx.conf in ssl_certificate
If it's not self-signed then one of certificates in your ssl certificate chain may use vulnerable encryption algorithms like SHA-1. Check what encryption each certificate uses (you may do it on PC). Probably you will need to find ssl registrator which does not uses old encryption algorithms.
you may use https://www.ssllabs.com/ssltest/ to check if your site has issues with SSL configuration or certificate itself.
In fact i just checked it and here's result http://i.imgur.com/X9dPX8Q.jpg . The vulnerabilities it output could be the reason why mobile chrome is not trusting the certificate and shows you warning.
Another possible issue is man in the middle attack on your device. What network are you using? is it the same as your PC network? if not, it could be mitm attack on you.
I tried to use Fiddler to capture some iOS apps traffic, ex: Facebook, SnapChat, Gmail, and Instagram.
Instagram is not using https so I can get all the traffic and see the cookies I sent out but Fiddler cannot decrypt other three apps. It only shows something like this:
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted
the parameters below. Version: 3.3 (TLS/1.2) Random: 54 3F 49 C4 20 08
09 BC A8 84 24 92 08 BF B4 38 39 C9 BB 1C B2 7B 95 6A 39 34 E7 AC FE
0F 62 67 SessionID: empty Extensions: server_name graph.facebook.com
elliptic_curves
Could anyone help me understand how they do this so I can use the same technology to protect my app.
Your question revolves around preventing HTTPS man in the middle (MITM) attacks against iOS applications. Using Fiddler or other HTTPS proxies is a form of naive MITM attack that, unfortunately, often works.
HTTP is built on top of a secure transport protocol called TLS (and before that, SSL). The connection is encrypted using public and private keys between trusted parties. And that is where things tend to go wrong. The concept of trust is central to the security of TLS and SSL before it. The server your application connects to provides cryptographic credentials that must be evaluated to establish trust.
Think of this like a passport or driver's license. In most cases, the license checks out. Then you get one with the name McLovin. If you don't actually look at the name, date of birth, number, photo, hologram, etc. you may just blindly trust that McLovin is who they say they are. And then you're in trouble.
Don't trust McLovin.
Most applications trust McLovin :(
To protect your application against these kinds of attacks you should implement a more strict set of crendential and trust evaluations. Apple has a tech note, Technote 2232: HTTPS Trust Evaluation that details this quite well.
A good start is to implement SSL Pinning. Pinning checks the credential of the remote host against a known value - all or part of that certificate. The iOS application has some copy of that certificate, and when connecting to that host checks the credential the host provides against this "known good" certificate. Some applications just check the meta information, others attempt to checksum the certificate (AFNetworking does this), and others perform a full trust evaluation using the known good certificate against the credential. Apple details this process in the WWDC 2014 session Building Apps for Enterprise and Education. If the remote host is not using the expected credentials, the connection is aborted. There is no traffic for an attacker to intercept. If your server's certificate changes often this can be a problem - which is one of several reasons its preferred to check the server's public key instead of meta information or a hash. Unfortunately, some server administrators change public keys often. Some think this is more secure. It's not.
Now, obviously this requires the iOS application to have a copy of the "good" certificate, or some part of it. You can include the certificate in your application, or implement your own method of key exchange. Secure key exchange has long been the subject of cryptographic research and is not something to be taken lightly.
Including the certificate in your application is the solution most people use. You may decide it's important to secure this certificate from someone who may have compromised or jailbroken the device. You have a number of different options for doing so. Obviously you could include it as a resource, and encrypt that. You can also include it directly within the application binary, which can be much more difficult for an attacker to access. This can be done by using the xxd tool with Xcode, as a script build phase or as a build rule. Obviously, you can implement additional protection on top of that.
If the device has been compromised or the application has been tampered with it's possible the "known good" credential has been altered. This is where the iOS application sandbox can work to your advantage. You can detect many of these scenarios by implementing receipt validation for your application. Assuming your application is being distributed through an Apple channel such as the iOS App Store, when it's installed it includes a receipt. That can be validated, and that can be used to implement tamper-proofing for many common scenarios.
These are all methods that can be implemented in the client to protect communications over HTTPS from MITM attacks. The server can also expose the client in many more ways, and the server should be regularly audited for vulnerabilies. Use only known strong cryptographic algorithms, stay up to date with current public vulnerabilities, etc.
Of course, if your application is something that can connect to random HTTPS services you have no control over, like a web browser, your options are more limited. In those cases, the best you can do when a remote host's credentials are in doubt is give the user the choice to trust or not trust the credentials. On iOS there is no UI for doing so provided by the system frameworks, that would be something your application would have to implement.
This is only one, small facet of securing an iOS application, but your question was specific about man in the middle attacks.
The way in which Fiddler can decrypt HTTPS traffic is by using their own certificate. However, when Facebook/Snapchat/Gmail detects that the certificate is not trusted by the system (and in cases will be more strict and limit the certificates within the trusted, so a third party trusted cert might be rejected), it will refuse to connect with the cert.
Fiddler can generate certs for the iOS to accept and install onto the system, but you first need to follow these instructions:
Install CertMaker
Generate the certificate from fiddler, it should then be on your desktop
Visit the certificate from your Safari browser (Safari only, others will not work)
Install the certificate
From this, you should then be able to sniff traffic from these applications.
So to answer the question again, it's not that they're preventing, it's common for SSL applications to deny responses from the server if the server provides an untrusted certificate. What Fiddler does, is spoof the part of the certificate with its so that when you are communicating over SSL, Fiddler can then use its cert to decrypt your traffic.
To answer the second part of your question, please check out this question for details. Essentially, you can force the user to use a specific certification and thus prevent the user from using installed certs.
However, they can still get around this -- just in a bit more sneaky way, but guided, this is on the client side, anything goes.
I pushed a Spree Rails app to Heroku and I see it's using ssl withhttps:// and has a yellow padlock in the browser. Clicking on this shows "Identity verified" and the Certificate Information says Issued To: *.herokuapp.com
This is great. With no configuration or expense at the Heroku end, my app is using SSL with a valid looking certificate. Ok it's a yellow rather than green padlock but hey, not bad for free.
I'm sure this is a stupid question..but how can I run another Rails app on Heroku with a verified certificate without paying for the SSL add-on and purchasing my own certificate?
The TLS/SSL connection your browser is establishing is due to the fact the you are connecting to your app via appname.herokuapp.com. This is standard and will automatically work for any app you create out of the box. Heroku provides SSL encryption as you may be sending sensitive information to the server and it is better practice to encrypt data that you may not necessarily deem sensitive, but your client may. All reputable providers (SAS, Web Hosts, Email Providers) will have a wildcard SSL certificate installed to the base domain (*.herokuapp.com) as it is a single certificate that is relatively inexpensive and will secure all the sub-domains automatically.
That being said Apps are SSL-enabled already and can be accessed simply by using https, e.g., https://appname.herokuapp.com, but you would want to go with the SSL endpoint option when you want to establish the trusted relationship with your clients. Both ways are as secure as the other, but with the wildcard SSL (also referred to as a shared SSL certificate) the trust is established between the client via their browser and Heroku not your App/Site. With the SSL signed to your domain.com the clients can connect to your domain and not the Heroku sub-domain and see your site's information in the connection information on the browser. If your site is needing disambiguation from Heroku then is when you will want to proceed with an SSL setup outside the default.
As for what SSL type and issuer to use I would not recommend https://www.startssl.com/ as they do not offer SSLs with high browser ubiquity as they are not fully signed by an external root authority. Comodo and the consumer standard Rapid/GeoTrust are the best choices as far as assurance, recognition, and easy of use and concerned. You only need a DV (domain validated) SSL and they can be had for a few domains a month.
More on this and the Heroku SSL configuration can be found here
I recently spent some time setting this up. It can be done using CloudFront and a proxy to Heroku. This is probably best used for small projects but seems to be working great so far! See my post here:
http://ksylvest.com/posts/2014-05-06/setup-free-ish-ssl-tls-on-heroku-for-ruby-on-rails-or-any-other-framework
A few things have changed since this question was first answered, notably the advent of Let's Encrypt and new Heroku SSL endpoints, which together make it possible to add SSL for free. I've created a gem to generate and add certificates automatically: https://github.com/KMarshland/heroku-ssl. Once you've added heroku_ssl to your gemfile, you can simply run:
rake heroku_ssl:update_certs
Alternatively, if you don't want to use the gem, you can do these tasks manually:
1. Generate the SSL Certificate
Follow the instructions in https://github.com/unixcharles/acme-client to generate your certificates. You'll need to register your email, authorize the domain, and then finally get your certificates. When authorizing the domain, if you only have one server running, you can simply stick the authorization file in your public folder; if not, you'll either have to set up a dedicated controller and route or add a text record to your DNS zone file.
2. Add the certificate to Heroku
After downloading your certificates, you can either use Heroku's web interface or just run
heroku certs:update fullchain.pem privkey.pem
3. Configure your DNS
You need to set a CNAME record in your DNS zone file that points to [yourdomain].herokudns.com. The DNS zone file specifies what urls get mapped to what servers on the domain name you own. If your site is already pointed to your Heroku app, there will already be a CNAME record; you just need to change where it points to. If not, you'll need to add a new line:
[subdomain] [TTL] IN CNAME [yourdomain].herokudns.com.
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).
I have an iOS client app which connects to a server using HTTPS.
I've added code in the client to verify the identify of the server.
How can a tester testing this feature test that it is now secure, how can they for example create a MITM situation and check that the client rejects connects etc.?
I've tried googling for how to do this but haven't had much luck.
Can it be done using tools like Charles and proxies etc. or is messing around with a wireless router and having detailed knowledge necessary?
This might be over simplification for your solution, but concepts might help.
A web browsers extracts the name of hosts from embedded certificate and do a comparison of host name that we're trying to connect with. If validation fails, we usually see a security warning. For ex: we can connect with facebook by either typing https://www.facebook.com or by typing https://173.252.100.16/. When we choose second option, we get a security warning.
Your program must be using SSL client socket to connect with HTTPS server. The socket must be having capability to extract the hostname from the embedded certificate. Once you get that, compare that with valid HOST NAME that your program is trying to connect with. If it matches, let request proceed, If not, abandon that session.
To re-create MITM, your web server can use a self signed certificate that can be issue to whatever host name you want, but the IP of server could be 127.0.0.1 (for example). Since there is a mismatch between the host name and actual IP, we can probably simulate the MITM situation.
I'm assuming that digital certificate can't be forged in this case.