I am trying to find what is the default implementation of BlackBerry for TLS protocol. Does it default to 1.0 or 1.1 or 1.2.
I am trying to find 1. What versions are TLS are supported 2. What is the default?
I have an app on BB world that connects to a back office server. The server team has decided to deprecate TLSv1.0. I am trying to find if this will impact my customers?
Current versions of BB10 do indeed support TLS 1.2 which you can test by using tools provided by SSL Labs. Unfortunately that is not the end of the story.
TLS is a protocol which specifies how to set up and use an encrypted connection. It does not set absolute requirements on encryption algorithm support however. I am aware of one documented case of an issue connecting with some Exchange Active Sync servers because the BB10 device and the server as configured do not have any cypher suites in common. Other EAS servers that are configured differently do not present this issue to BB10 devices.
What you need to do is find out specifically how the server team is going to configure TLS, and what they are going to accept for connections.
Related
Right now I'm developing an application using Xamarin.Forms. I ran into a problem with the TLS protocol.
My application uses an API. Because of security reasons the API uses HTTPS. This week we decided to remove the support of TLS 1.0 to accept only TLS 1.1 and 1.2 on the server side, but after we made this change, I noticed that my application stoped working.
While debugging I noticed that the call of the API throws an exception (I'm using HttpClient class from .Net). By searching for solutions on the Internet, I saw that many people think the problem is related to TLS support.
I solved this problem on Android and iOS using a plugin named ModernHTTPClient but one of my customers reported me that on his device running on Android they still have the problem (he's running a device with Android 4.2).
Checking Android documentation I saw that this version have support but is not enable by default, and the hard part is that there's not much documentation in the Internet about how I can activate this.
Any advice of how I can activate this? Did Xamarin.Android have native support for TLS 1.1 and up?
Thanks
ModernHTTPClient should use the platforms' native HTTP handling. Looks like for now you can build it manually using this pull: https://github.com/paulcbetts/ModernHttpClient/pull/210
Related Question:
AWS S3 Disabling SSLv3 Support
This is more of an inquiry for the mobile iOS SDK. Wondering what I have to do or where to start since am a bit clueless.
Also just received a notice that Amazon is deprecating SSLv3 and that I need to modify my requests to use TLS.
This is an older iOS app still using the AWS iOS SDK 1.7 version. This basically just accesses S3 Buckets for both upload and download of images.
Now is this normally handled already by the library or do I have to update to the v2 library, thereby dropping iOS 6 support. Or can it just be through code changes, etc.
The SSLSecurityLevel is handled by iOS.
Apple's Doc "By default, a stream’s security level is kCFStreamSocketSecurityLevelNegotiatedSSL. ", which means the client negotiated with server and choose the highest level security protocol agreed by both end.
Since all iOS version supports TLS,by default, iOS client will always try to use TLS during negotiation, and fallback to SSLv3 if it is not available. As long as server supports TLS, you should see no SSLv3 communications unless the default SSLSecurityLevel has been changed.
TLDR: Is there any way to configure iOS SSL cipher suites for a mobile-device-initiated, REST-over-TLS network connection, without using non-iOS-native HTTP or SSL libraries. If so, where is the API documented and are there any examples?
Details: I am working with others to develop an iOS mobile application and we are unable to locate details about how to force the native iOS crypto libraries to use a specific version of SSL/TLS, or specific cipher suites. This is for a custom REST application, so the approach would have to be possible to connect via HTTP over TLS.
The app is written in Objective-C. We are trying to stay within iOS native functionality without including a separate SSL/TLS library.
I did try to search for an answer on SO, but I didn't find anything that seemed to cover the question.
If I am using NSURLConnection with NSURL like https://www.example.comin iOS app(given that my server www.example.com is TLS enabled and SSL disabled), I am using SSL or TLS?
A client supplies a list of protocols to a server to use, the server picks one it supports.
This is in general.
You do not supply enough information to answer your question. What iOS version you use?
Here is an excerpt from Apple documentation.
iOS 5's TLS implementation has been upgraded to support TLS protocol version 1.2. Some non-compliant TLS server implementations do not implement TLS 1.2 and, more importantly, do not downgrade gracefully to a supported protocol version. As a result you may find that some TLS client applications built against the iOS 5 SDK may not connect to some TLS servers, when the same application built against a previous version of the iOS SDK would connect.
You may try configure the TLS protocol version using the TLSMinimumSupportedProtocol and TLSMaximumSupportedProtocol properties of the configuration. However with NSURLConnection the control over sockets is limited, e.g. you can't control ciphers, see this discussion.
You may want to use Wireshark to see what is being used in your case.
I am developing an iPhone application, I am trying to find a list of supported SSL/TLS versions and ciphers for iOS. Is there a reference or a method I can call to get this answer? Also, if I can limit the supported protocols and ciphers via code, how can I do this?
The TLS functionality in iOS is provided by OpenSSL, so look at their compatibility list. As far as limiting "the supported protocols and ciphers via code" goes, remember that you're working in a sandbox so you can only do that for your own app. You can't, for example, force every other app on the phone into plaintext. You'd present the list of ciphers you're willing to use during the negotiation phase of the SSL connection.