I am using NuSOAP / 0.9.5 on my system.
There is a specification change in the communication destination system,
I have been informed that the following encryption algorithms have been disabled.
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
It seems that the following encryption algorithms can be used.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
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_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
I haven't specified a specific TLS version in NuSOAP / 0.9.5.
I would like to know the default TLS version.
Related
I am using NuSOAP / 0.9.5 on my system.
There is a specification change in the communication destination system,
I have been informed that the following encryption algorithms have been disabled.
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
It seems that the following encryption algorithms can be used.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
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_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
I haven't specified a specific TLS version in NuSOAP / 0.9.5.
I would like to know how to specify the TLS version.
I'm trying to control what TLS/SSL protocols are supported for a HTTPS connections to my webservice, by using a TIdServerIOHandlerSSLOpenSSL component and setting its SSLOptions.Method and SSLOptions.SSLVersions properties (as suggested in this answer).
The default is Method sslvTLSv1 and SSLVersions [sslvTLSv1] (see this answer for the relations between Method and SSLVersions):
I use nmap with the ssl-enum-ciphers.nse script from this answer to check what is actually available, and get this script output:
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_DES_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
| TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
| warnings:
| Ciphersuite uses MD5 for message integrity
| Weak certificate signature: SHA1
|_ least strength: C
But TLS 1.1 and TLS 1.2 are missing.
If I set Method to sslvSSLv23 ("a wildcard that allows dynamic version negotiation in cases where client and server support different SSL/TLS versions. It allows them to figure out and use the highest version common to both parties" (source)) I see sslvSSLv2and sslvSSLv3 become active.
But I do not want SSL 2.0 (deprecated/prohibited in 2011 by RFC 6176) and 3.0 (deprecated in June 2015 by RFC 7568) support (source).
I cannot subtract both sslvTLSv2 and sslvTLSv3 from the set generated by method sslvSSLv23: we revert to the default configuration where only TLS 1.0 is supported.
Note that if I 'only' leave out sslvTLSv2 (Method is sslvSSLv23 and SSLVersions is [sslvSSLv3,sslvTLSv1]), nmap tells me:
| ssl-enum-ciphers:
| SSLv3:
| ciphers:
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_DES_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
| TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
| warnings:
| CBC-mode cipher in SSLv3 (CVE-2014-3566)
| Ciphersuite uses MD5 for message integrity
| Weak certificate signature: SHA1
| TLSv1.0:
| ciphers:
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_DES_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
| TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
| warnings:
| Ciphersuite uses MD5 for message integrity
| Weak certificate signature: SHA1
| TLSv1.1:
| ciphers:
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_DES_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
| TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
| warnings:
| Ciphersuite uses MD5 for message integrity
| Weak certificate signature: SHA1
| Weak cipher RC4 in TLSv1.1 or newer not needed for BEAST mitigation
| TLSv1.2:
| ciphers:
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_DES_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
| TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
| warnings:
| Ciphersuite uses MD5 for message integrity
| Weak certificate signature: SHA1
| Weak cipher RC4 in TLSv1.1 or newer not needed for BEAST mitigation
|_ least strength: C
What can I do so that only all TLS 1.x versions are supported?
This is Delphi XE2 with Indy 10.5.8.0, running on Win7, tested with OpenSSL 1.02f. With OpenSSL 1.02g I get this issue, we are not yet ready for our update to Delphi Seattle (Update 1) where this is solved in the Indy code.
Additional notes:
Should I drop TLS 1.0 support as well?
SSLOptions.Mode is still at the default sslmUnassigned, I want to look at that later.
Note that the nmap script only tests SSLv3/TLS versions, not SSLv2. I used SSLScan in addition, and this shows that if I leave out sslvTLSv3 only, SSL2 is indeed still enabled ;-(
Forget the info about weak ciphers, that's the next thing to tackle ;-)
I am actually unable to do an nmap test if I run my webservice in the Delphi IDE, this gives all kinds of runtime errors (that do not surface if I run the executable). Maybe these are supposed to happen because the nmap script is firing off all kinds of tests?
EIdOSSLAcceptError 'Error accepting connection with SSL. EOF was observed that violates the protocol.'
EIdOSSLUnderlyingCryptoError in ssl3_get_client_hello:no shared cipher
EIdOSSLUnderlyingCryptoError in ssl3_get_client_hello:wrong version number
But TLS 1.1 and TLS 1.2 are missing.
Right, because if you set the Method to sslvTLSv1, Indy will only use TLS 1.0 specifically.
Your screenshot of the Object Inspector clearly shows that you are using a version of Indy that does not support TLS 1.1+ (if you were, there would be sslvTLSv1_1 and sslvTLSv1_2 options available in the SSLVersions property).
Note that if I 'only' leave out sslvTLSv2 (Method is sslvSSLv23 and SSLVersions is [sslvSSLv3,sslvTLSv1]), nmap tells me:
When the Method is sslvSSLv23, Indy merely disables unwanted SSL/TLS versions, in this case SSLv2. You are clearly using a version of the OpenSSL library that supports TLS 1.1+. So, because your Indy version does not support TLS 1.1+, it is not disabling them. They are enabled by default. Since you are not disabling TLS 1.0, TLS 1.1+ get left implicitly enabled by OpenSSL itself.
What can I do so that only all TLS 1.x versions are supported?
This is a little bit of an odd workaround, but you can set the SSLVersions to [sslvSSLv23,sslvTLSv1]. That will set the Method to sslvSSLv23 and remove sslvSSLv23 from the SSLVersions. This way, Indy will use the SSLv23 wildcard and disable SSLv2 and SSLv3, leaving TLS 1.0+ enabled.
Unfortunately, you cannot really make this configuration in the Object Inspector at design-time. Well, you can (enable just sslvTLSv1 first, and then enable ssvSSLv23 afterwards), but it won't be saved in the DFM correctly (the SSLVersions will be omitted since [sslvTLSv1] is the default value), and will thus end up re-enabling SSLv2 and SSLv3 at run-time. To avoid that, you will have to assign the SSLVersions in code at run-time, before activating your server:
IdServerIOHandlerSSLOpenSSL1.SSLOptions.SSLVersions := [sslvSSLv23,sslvTLSv1];
Otherwise, the alternative is to upgrade to an up-to-date version of Indy that natively supports TLS 1.1+, then you can just set the SSLVersions to [sslvTLSv1,sslvTLSv1_1,sslvTLSv1_2] (at run-time or design-time) and move on.
Im getting these errors from my app in iOS9.
It works great on iOS8.
My server is using tls v1.2. So, I dont know where is the problem.
2015-08-04 16:52:24.319 Entumano[676:59469] CFNetwork SSLHandshake failed (-9824)
2015-08-04 16:52:24.324 Entumano[676:59469] NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9824)
I got the answer. In all post i read they were talking about tls version. BUT apple it's also validating that your ssl have this ciphers:
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
I manage to workaround setting in plist NSAppTransportSecurity NSExceptionRequiresForwardSecrecy = NO
has anyone with the iOS 9 beta 1 had this issue?
I use standard NSURLConnection to connect to a webservice and as soon as a call is made to the webservice i get the below error. This is currently working in iOS 8.3
Possible beta bug? any ideas or thoughts would be great ! I know its very early in iOS 9 development
Here is the full error:
CFNetwork SSLHandshake failed (-9824)
NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9824)
NSURLRequest * urlRequest = [NSURLRequest requestWithURL:[NSURL URLWithString:#"https://mywebserviceurl"]];
NSURLResponse * response = nil;
NSError * error = nil;
NSData * data = [NSURLConnection sendSynchronousRequest:urlRequest
returningResponse:&response
error:&error];
iOS 9 and OSX 10.11 require TLSv1.2 SSL for all hosts you plan to request data from unless you specify exception domains in your app's Info.plist file.
The syntax for the Info.plist configuration looks like this:
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>yourserver.com</key>
<dict>
<!--Include to allow subdomains-->
<key>NSIncludesSubdomains</key>
<true/>
<!--Include to allow insecure HTTP requests-->
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<true/>
<!--Include to specify minimum TLS version-->
<key>NSExceptionMinimumTLSVersion</key>
<string>TLSv1.1</string>
</dict>
</dict>
</dict>
If your application (a third-party web browser, for instance) needs to connect to arbitrary hosts, you can configure it like this:
<key>NSAppTransportSecurity</key>
<dict>
<!--Connect to anything (this is probably BAD)-->
<key>NSAllowsArbitraryLoads</key>
<true/>
</dict>
If you're having to do this, it's probably best to update your servers to use TLSv1.2 and SSL, if they're not already doing so. This should be considered a temporary workaround.
As of today, the prerelease documentation makes no mention of any of these configuration options in any specific way. Once it does, I'll update the answer to link to the relevant documentation.
In iOS 10+, the TLS string MUST be of the form "TLSv1.0". It can't just be "1.0". (Sigh)
The following combination of the other Answers works.
Let's say you are trying to connect to a host (YOUR_HOST.COM) that only has TLS 1.0.
Add these to your app's Info.plist
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>YOUR_HOST.COM</key>
<dict>
<key>NSIncludesSubdomains</key>
<true/>
<key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
<true/>
<key>NSTemporaryExceptionMinimumTLSVersion</key>
<string>TLSv1.0</string>
<key>NSTemporaryExceptionRequiresForwardSecrecy</key>
<false/>
</dict>
</dict>
</dict>
For more info Configuring App Transport Security Exceptions in iOS 9 and OSX 10.11
Curiously, you’ll notice that the connection attempts to change the
http protocol to https to protect against mistakes in your code where
you may have accidentally misconfigured the URL. In some cases, this
might actually work, but it’s also confusing.
This Shipping an App With App Transport Security covers some good debugging tips
ATS Failure
Most ATS failures will present as CFErrors with a code in the -9800
series. These are defined in the Security/SecureTransport.h header
2015-08-23 06:34:42.700 SelfSignedServerATSTest[3792:683731] NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9813)
CFNETWORK_DIAGNOSTICS
Set the environment variable CFNETWORK_DIAGNOSTICS to 1 in order to
get more information on the console about the failure
nscurl
The tool will run through several different combinations of ATS
exceptions, trying a secure connection to the given host under each
ATS configuration and reporting the result.
nscurl --ats-diagnostics https://example.com
If your backend uses a secure connection ant you get using NSURLSession
CFNetwork SSLHandshake failed (-9801)
NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9801)
you need to check your server configuration especially to get ATS version and SSL certificate Info:
Instead of just Allowing Insecure Connection by setting NSExceptionAllowsInsecureHTTPLoads = YES , instead you need to Allow Lowered Security in case your server do not meet the min requirement (v1.2) for ATS (or better to fix server side).
Allowing Lowered Security to a Single Server
<key>NSExceptionDomains</key>
<dict>
<key>api.yourDomaine.com</key>
<dict>
<key>NSExceptionMinimumTLSVersion</key>
<string>TLSv1.0</string>
<key>NSExceptionRequiresForwardSecrecy</key>
<false/>
</dict>
</dict>
use openssl client to investigate certificate and get your server configuration using openssl client :
openssl s_client -connect api.yourDomaine.com:port //(you may need to specify port or to try with https://... or www.)
..find at the end
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: //
Session-ID-ctx:
Master-Key: //
Key-Arg : None
Start Time: 1449693038
Timeout : 300 (sec)
Verify return code: 0 (ok)
App Transport Security (ATS) require Transport Layer Security (TLS) protocol version 1.2.
Requirements for Connecting Using ATS:
The requirements for a web service connection to use App Transport Security (ATS) involve the server, connection ciphers, and certificates, as follows:
Certificates must be signed with one of the following types of keys:
Secure Hash Algorithm 2 (SHA-2) key with a digest length of at least 256 (that is, SHA-256 or greater)
Elliptic-Curve Cryptography (ECC) key with a size of at least 256 bits
Rivest-Shamir-Adleman (RSA) key with a length of at least 2048 bits An
invalid certificate results in a hard failure and no connection.
The following connection ciphers support forward secrecy (FS) and work
with ATS:
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
Update: it turns out that openssl only provide the minimal protocol version Protocol : TLSv1 links
After two days of attempts and failures, what worked for me is this code of womble
with One change, according to this post we should stop using sub-keys associated with the NSExceptionDomains dictionary of that kind of Convention
NSTemporaryExceptionMinimumTLSVersion
And use at the new Convention
NSExceptionMinimumTLSVersion
instead.
apple documentation
my code
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>YOUR_HOST.COM</key>
<dict>
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<true/>
<key>NSExceptionMinimumTLSVersion</key>
<string>TLSv1.0</string>
<key>NSExceptionRequiresForwardSecrecy</key>
<false/>
<key>NSIncludesSubdomains</key>
<true/>
</dict>
</dict>
</dict>
Another useful tool is nmap (brew install nmap)
nmap --script ssl-enum-ciphers -p 443 google.com
Gives output
Starting Nmap 7.12 ( https://nmap.org ) at 2016-08-11 17:25 IDT
Nmap scan report for google.com (172.217.23.46)
Host is up (0.061s latency).
Other addresses for google.com (not scanned): 2a00:1450:4009:80a::200e
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: server
| TLSv1.1:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: server
| TLSv1.2:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
|_ least strength: C
Nmap done: 1 IP address (1 host up) scanned in 5.48 seconds
This error was showing up in the logs sometimes when I was using a buggy/crashy Cordova iOS version. It went away when I upgraded or downgraded cordova iOS.
The server I was connecting to was using TLSv1.2 SSL so I knew that was not the problem.
In your project .plist file in add this permission :
<key>NSAppTransportSecurity</key>
<dict>
<!--Connect to anything (this is probably BAD)-->
<key>NSAllowsArbitraryLoads</key>
<true/>
</dict>
The syntax for the Info.plist configuration
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>yourserver.com</key>
<dict>
<!--Include to allow subdomains-->
<key>NSIncludesSubdomains</key>
<true/>
<!--Include to allow insecure HTTP requests-->
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<true/>
<!--Include to specify minimum TLS version-->
<key>NSExceptionMinimumTLSVersion</key>
<string>TLSv1.1</string>
</dict>
</dict>
Updated Answer (post-WWDC 2016):
iOS apps will require secure HTTPS connections by the end of
2016. Trying turn ATS off may get your app rejected in the future.
App Transport Security, or ATS, is a feature that Apple introduced in iOS 9. When ATS is enabled, it forces an app to connect to web services over an HTTPS connection rather than non secure HTTP.
However, developers can still switch ATS off and allow their apps to send data over an HTTP connection as mentioned in above answers. At the end of 2016, Apple will make ATS mandatory for all developers who hope to submit their apps to the App Store. link
The device I tested at had wrong time set. So when I tried accessing a page with a certificate that would run out soon it would deny access because the device though the certificate had expired. To fix, set proper time on the device!
has anyone with the iOS 9 beta 1 had this issue?
I use standard NSURLConnection to connect to a webservice and as soon as a call is made to the webservice i get the below error. This is currently working in iOS 8.3
Possible beta bug? any ideas or thoughts would be great ! I know its very early in iOS 9 development
Here is the full error:
CFNetwork SSLHandshake failed (-9824)
NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9824)
NSURLRequest * urlRequest = [NSURLRequest requestWithURL:[NSURL URLWithString:#"https://mywebserviceurl"]];
NSURLResponse * response = nil;
NSError * error = nil;
NSData * data = [NSURLConnection sendSynchronousRequest:urlRequest
returningResponse:&response
error:&error];
iOS 9 and OSX 10.11 require TLSv1.2 SSL for all hosts you plan to request data from unless you specify exception domains in your app's Info.plist file.
The syntax for the Info.plist configuration looks like this:
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>yourserver.com</key>
<dict>
<!--Include to allow subdomains-->
<key>NSIncludesSubdomains</key>
<true/>
<!--Include to allow insecure HTTP requests-->
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<true/>
<!--Include to specify minimum TLS version-->
<key>NSExceptionMinimumTLSVersion</key>
<string>TLSv1.1</string>
</dict>
</dict>
</dict>
If your application (a third-party web browser, for instance) needs to connect to arbitrary hosts, you can configure it like this:
<key>NSAppTransportSecurity</key>
<dict>
<!--Connect to anything (this is probably BAD)-->
<key>NSAllowsArbitraryLoads</key>
<true/>
</dict>
If you're having to do this, it's probably best to update your servers to use TLSv1.2 and SSL, if they're not already doing so. This should be considered a temporary workaround.
As of today, the prerelease documentation makes no mention of any of these configuration options in any specific way. Once it does, I'll update the answer to link to the relevant documentation.
In iOS 10+, the TLS string MUST be of the form "TLSv1.0". It can't just be "1.0". (Sigh)
The following combination of the other Answers works.
Let's say you are trying to connect to a host (YOUR_HOST.COM) that only has TLS 1.0.
Add these to your app's Info.plist
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>YOUR_HOST.COM</key>
<dict>
<key>NSIncludesSubdomains</key>
<true/>
<key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
<true/>
<key>NSTemporaryExceptionMinimumTLSVersion</key>
<string>TLSv1.0</string>
<key>NSTemporaryExceptionRequiresForwardSecrecy</key>
<false/>
</dict>
</dict>
</dict>
For more info Configuring App Transport Security Exceptions in iOS 9 and OSX 10.11
Curiously, you’ll notice that the connection attempts to change the
http protocol to https to protect against mistakes in your code where
you may have accidentally misconfigured the URL. In some cases, this
might actually work, but it’s also confusing.
This Shipping an App With App Transport Security covers some good debugging tips
ATS Failure
Most ATS failures will present as CFErrors with a code in the -9800
series. These are defined in the Security/SecureTransport.h header
2015-08-23 06:34:42.700 SelfSignedServerATSTest[3792:683731] NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9813)
CFNETWORK_DIAGNOSTICS
Set the environment variable CFNETWORK_DIAGNOSTICS to 1 in order to
get more information on the console about the failure
nscurl
The tool will run through several different combinations of ATS
exceptions, trying a secure connection to the given host under each
ATS configuration and reporting the result.
nscurl --ats-diagnostics https://example.com
If your backend uses a secure connection ant you get using NSURLSession
CFNetwork SSLHandshake failed (-9801)
NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9801)
you need to check your server configuration especially to get ATS version and SSL certificate Info:
Instead of just Allowing Insecure Connection by setting NSExceptionAllowsInsecureHTTPLoads = YES , instead you need to Allow Lowered Security in case your server do not meet the min requirement (v1.2) for ATS (or better to fix server side).
Allowing Lowered Security to a Single Server
<key>NSExceptionDomains</key>
<dict>
<key>api.yourDomaine.com</key>
<dict>
<key>NSExceptionMinimumTLSVersion</key>
<string>TLSv1.0</string>
<key>NSExceptionRequiresForwardSecrecy</key>
<false/>
</dict>
</dict>
use openssl client to investigate certificate and get your server configuration using openssl client :
openssl s_client -connect api.yourDomaine.com:port //(you may need to specify port or to try with https://... or www.)
..find at the end
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: //
Session-ID-ctx:
Master-Key: //
Key-Arg : None
Start Time: 1449693038
Timeout : 300 (sec)
Verify return code: 0 (ok)
App Transport Security (ATS) require Transport Layer Security (TLS) protocol version 1.2.
Requirements for Connecting Using ATS:
The requirements for a web service connection to use App Transport Security (ATS) involve the server, connection ciphers, and certificates, as follows:
Certificates must be signed with one of the following types of keys:
Secure Hash Algorithm 2 (SHA-2) key with a digest length of at least 256 (that is, SHA-256 or greater)
Elliptic-Curve Cryptography (ECC) key with a size of at least 256 bits
Rivest-Shamir-Adleman (RSA) key with a length of at least 2048 bits An
invalid certificate results in a hard failure and no connection.
The following connection ciphers support forward secrecy (FS) and work
with ATS:
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
Update: it turns out that openssl only provide the minimal protocol version Protocol : TLSv1 links
After two days of attempts and failures, what worked for me is this code of womble
with One change, according to this post we should stop using sub-keys associated with the NSExceptionDomains dictionary of that kind of Convention
NSTemporaryExceptionMinimumTLSVersion
And use at the new Convention
NSExceptionMinimumTLSVersion
instead.
apple documentation
my code
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>YOUR_HOST.COM</key>
<dict>
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<true/>
<key>NSExceptionMinimumTLSVersion</key>
<string>TLSv1.0</string>
<key>NSExceptionRequiresForwardSecrecy</key>
<false/>
<key>NSIncludesSubdomains</key>
<true/>
</dict>
</dict>
</dict>
Another useful tool is nmap (brew install nmap)
nmap --script ssl-enum-ciphers -p 443 google.com
Gives output
Starting Nmap 7.12 ( https://nmap.org ) at 2016-08-11 17:25 IDT
Nmap scan report for google.com (172.217.23.46)
Host is up (0.061s latency).
Other addresses for google.com (not scanned): 2a00:1450:4009:80a::200e
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: server
| TLSv1.1:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: server
| TLSv1.2:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
|_ least strength: C
Nmap done: 1 IP address (1 host up) scanned in 5.48 seconds
This error was showing up in the logs sometimes when I was using a buggy/crashy Cordova iOS version. It went away when I upgraded or downgraded cordova iOS.
The server I was connecting to was using TLSv1.2 SSL so I knew that was not the problem.
In your project .plist file in add this permission :
<key>NSAppTransportSecurity</key>
<dict>
<!--Connect to anything (this is probably BAD)-->
<key>NSAllowsArbitraryLoads</key>
<true/>
</dict>
The syntax for the Info.plist configuration
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>yourserver.com</key>
<dict>
<!--Include to allow subdomains-->
<key>NSIncludesSubdomains</key>
<true/>
<!--Include to allow insecure HTTP requests-->
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<true/>
<!--Include to specify minimum TLS version-->
<key>NSExceptionMinimumTLSVersion</key>
<string>TLSv1.1</string>
</dict>
</dict>
Updated Answer (post-WWDC 2016):
iOS apps will require secure HTTPS connections by the end of
2016. Trying turn ATS off may get your app rejected in the future.
App Transport Security, or ATS, is a feature that Apple introduced in iOS 9. When ATS is enabled, it forces an app to connect to web services over an HTTPS connection rather than non secure HTTP.
However, developers can still switch ATS off and allow their apps to send data over an HTTP connection as mentioned in above answers. At the end of 2016, Apple will make ATS mandatory for all developers who hope to submit their apps to the App Store. link
The device I tested at had wrong time set. So when I tried accessing a page with a certificate that would run out soon it would deny access because the device though the certificate had expired. To fix, set proper time on the device!