I'd like to bypass certificate validation using Alamofire 5 and Swift 4. I'm using Alamofire to connect to a server with a self-signed certificate. This is similar to this question Alamofire with a self-signed certificate / ServerTrustPolicy, but the answers are for previous Alamofire versions and it's not clear to me how to apply this approach to version 5. Does anyone know how to implement this in Alamofire 5?
It's very similar in Alamofire 5 but ServerTrustPolicy has been refactored into a protocol with conforming types for better extensibility. Similar to the answer you linked, you'll need to create a ServerTrustManager for your domain:
let manager = ServerTrustManager(evaluators: ["your.domain.here": DisabledTrustEvaluator()])
let session = Session(serverTrustManager: manager)
Of course, you'll still need to add ATS exceptions for your domains as well.
Additionally, you should never ship code that uses the DisabledTrustEvaluator, as it would allow all invalid TLS connections.
Related
Our security team has performed a security scan on our mobile application and found the following vulnerabilities:
Vulnerability Name: Weak SSL Cipher Suites are Supported
Vulnerability Type: attWeakCipherSuites
Calling Method: com.crittercism.internal.ca.a(com.crittercism.internal.bz):com.crittercism.internal.cb
Method Signature: javax.net.ssl.SSLParameters.setCipherSuites(java.lang.String[]):void
Location: (Unknown)
Issue Validation Parameter - Name: cipherSuites
Issue Validation Parameter - Value: [TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Vulnerability Name: Lack of Certificate Pinning
Vulnerability Type: attSSLCertificatePinning
Calling Method: com.crittercism.internal.ca.a(com.crittercism.internal.bz):com.crittercism.internal.cb
Method Signature: java.net.URL.openConnection():java.net.URLConnection
Location: (Unknown)
Issue Validation Parameter - Name: this
Issue Validation Parameter - Value: https://5-8-10-android.appload.ingest.crittercism.com/v0/config
Can someone help me resolve the issues above?
Platform: Android
Framework: React-native
Your Questions
First question
Vulnerability Name: Weak SSL Cipher Suites are Supported
Vulnerability Type: attWeakCipherSuites
You need to pass only the latest recommended ciphers suites and you can read what ones are in the Mozilla site.
Currently the most secure ones are the ones recommended for Modern Compatibility
TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
Second question
Vulnerability Name: Lack of Certificate Pinning
Vulnerability Type: attSSLCertificatePinning
Once you are using React Native you may want to try the react-native-cert-pinner package:
This package manages TLS certificate pinning in react-native for Android and iOS.
You should read the README of the package for the detailed instructions, but as a quick start, this may work:
npm install react-native-cert-pinner --save
followed by an automated installation:
react-native link react-native-cert-pinner
Otherwise you should try, from the README, the manual installation for Android.
Going the Extra Mile
If you want to understand why you should be using Certificate Pinning, you can read this blog post on these 2 sections:
What is Certificate Pinning?
It will briefly explain what it is and how it works in an high level, and what to pin.
Certificate pinning is the mechanism of associating a domain name with an expected SSL/TLS certificate, technically and more accurately known as an X.509 certificate.
Why do we need Certificate Pinning?
Here it explains why is needed to be used in order to prevent trust based assumptions and to protect against use in hostile environments.
While https gives you confidentiality, integrity and authenticity in the communication channel between the mobile app and the API server, certificate pinning will protect this same guarantees from being broken.
My apologies if this is a duplicate, I may just not be using the correct terminology in my queries to find what I am looking for.
I have a vendor that sent me a certificate to install in my browser so that we can access their website. We cannot get to their pages otherwise.
We similarly have a server for our distributors that has a self signed certificate currently, but we would like to implement the same private certificate system.
What is this process even called? Where do I get started?
Is it just more options when creating the self signed certificate?
It sounds like you want to use client-side SSL certificates for authentication. The Apache documentation covers this use case in some detail (that's for version 2.4; see here for version 2.2).
I'm getting the above mention error when my client update their device to iOS 7.1, and then try to update our app from the AppCenter.
After some searching, i found a post with a similar problem here. But then since i'm in an environment where by the client is using AppCenter to update the apps, i can't be using USB to plugin and install the app for them.
Is there any workaround for downloads via AppCenter until a support is released?
A change was introduced to iOS as of iOS 7.1 that requires OTA application installation to take place over HTTPS (rather than HTTP), and no provision exists to allow the user to continue to accept the old behavior (i.e., to permit application installation over HTTP). It is my understanding that this was done as a security enhancement.
In order to do application installations on iOS 7.1 from Application Center, you would need to configure your Application Center to use HTTPS rather than HTTP, using a certificate that will be accepted as valid by your iOS device - that is, either issued by a recognized public CA, or issued by a private CA that you have set up your mobile devices to accept. You can find more information about how to perform this configuration here:
http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/topic/com.ibm.worklight.installconfig.doc/appcenter/c_ac_ssl_config.html
I would add some details. (Just work out this question)
We use self developed app center for our customers, to distribute demo/report apps.
You need SSL certificate. (see the post above)
You can buy any kind of public certificate . In some cases you can use self signed certificate previously installed on iOS device by Apple Configurator.
It seems that you don’t have to use https everywhere. Secure URL (https) must have a link to .plist only. The app center web site url and package .ipa url can still be under http.
… and shame on Apple that invents new ways to make developer life hard.
I'm working on the application that uses REST web service with SSL. The web service is already in place, identifying itself with the SSL certificate. Even though the certificate seems to be valid, it is still being rejected by iOS. Below are the details:
Web service presents the certificate chain consisting of 3 certificates, the root certificate that is present on this list, the intermediate certificate and finally the web service certificate
The method - (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)space is called each time I send requests to the web service. The comment in RestKit code says "server is using an SSL certificate that the OS can't validate", so I guess I should never reach that method, right?
I tried to access the web service from Safari on the test device, and the certificate is automatically accepted. The same goes for the desktop browsers.
Sslshopper says the certificate is fine.
I can connect to the web service by adding the certificate to the application bundle and handling it the same way I'd do with self-signed certificates, but I want to solve this the proper way. Any help greatly appreciated, especially if someone can point out why Safari on iOS accepts the cert, and my application does not.
Edit: it turns out that I've been using old RestKit version. I created the proof of concept that allowed me to dispatch some requests to my server, and with the RestKit master from today (3rd May 2012) the certificate is accepted. However, I get two calls to connection:canAuthenticateAgainstProtectionSpace:, in both of them I return NO, but it manages to connect properly anyway. So, the new question is, what exactly has changed in RestKit that I can connect properly now. I need to know this because I will have to patch the old version that I'm going to use for release. I will update RestKit afterwards.
Edit: I need to give that back to the RestKit guys, it was not their fault. The web service that I'm trying to connect to is using some kind of gateway which is the source of the problem. There were some fixes from the gateway crew earlier in the day, that's why it worked correctly by the time I managed to perform the tests with the latest RestKit version.
Can a particular web page in a web site, authonticate a web request using client side SSL certificate, while others don't?
It's possible using SSL/TLS renegotiation. The way to configure it depends on the server you're using (and whether it supports it).
Note that, at the end of last year (October/November 2009), an SSL/TLS protocol flaw was discovered regarding this feature.
SSL/TLS stacks that support renegotiation based on code before that will be vulnerable to the attack. Most libraries did an emergency security update where they disable renegotiation altogether (therefore removing the client-certificate renegotiation). In February 2010, RFC 5746 was published with a fix to this problem, but not all stacks implement it yet.
I believe the most common way to secure a single page is to put it in a subfolder that is SSL-secured.
This article may help:
http://www.leastprivilege.com/PartiallySSLSecuredWebAppsWithASPNET.aspx