I’ve started a podcast (in German)! My new podcast will air Monday every other week. In each episode, I will interview one (or multiple) guests any software development-related topic, while focusing on Microsoft technology.
In the first episode, I talk to Microsoft’s Robin-Manuel Thiel on getting started with the cloud and Azure.
You can subscribe to the podcast feed at https://kerry.lothrop.de/feed/podcast/.
The best way to know all the network communication your app is doing is to inspect the network traffic to and from your phone while your app is running. My favorite tool for doing this is Fiddler by Progress Telerik.
Fiddler is a free Web Debugging Proxy for Windows. Its intended purpose is to allow web developers to inspect their browsers’ traffic. It was released in 2003 when browsers did not yet provide the nice debugging tools that browsers have nowadays. When launching Fiddler, it will start a proxy server and automatically register itself as the system HTTP proxy server for all browsers that use the system’s settings (e.g., IE, Edge, Chrome, Safari, Opera, etc.) and for Firefox. If you then call a web site from your browser you can see, in detail, all the traffic the browser is requesting from any server and all the responses.
But Fiddler will also let you capture the traffic from any app, even if it’s not on the same machine, if you tell that app to send its requests through the proxy server Fiddler provides. We’ll look at how to do this for a mobile app. To do this, it is usually a good idea to first turn off the capturing of your browser and operating system requests by disabling File → Capture Traffic (F12) so you only see the requests from your app.
The next thing to do is to tell Fiddler to open a port to allow apps from other hosts to connect to it. This is done by checking Allow remote computers to connect in the Connections tab under Tools → Options.
Now head over to your mobile phone. The phone will have to be inside the same wifi and the wifi will need to allow hosts to be able to communicate with each other. Such wifi networks are typically found at home or inside companies but not in public places. In the phone’s preferences, set your wifi’s proxy server to be the IP address of your PC and the TCP port that was set inside the Connections tab in Fiddler (the default is 8888).
On iOS, you’ll find this setting under Settings → Wifi, tap the ⓘ next to your wifi, then under HTTP Proxy → Configure Proxy, set to Manual, the set the Server to the IP address of your PC and the Port to the TCP port (typically 8888).
Lets launch one of my favorite apps, FlightRadar24, and look at the communication.
Looking at the communication, we see a lot of requests being sent out to multiple servers. But upon inspecting these requests, we notice we can see the contents of none of them. This is because the FlightRadar24 app is using HTTPS (which it should) for all of its requests.
The solution to this is to instruct Fiddler to Decrypt HTTPS traffic in the HTTPS tab of the settings.
What this does is essentially a TLS man-in-the-middle attack (for more details, see the previous blog post in this series on certificate pinning).
Looking at the communication, we notice that we see a lot of requests but their size is always 0. We also notice the app is not showing any flight movement information.
The reason for this is that, in order to do intercept the traffic and inspect the contents, Fiddler doesn’t forward the request to the server directly but instead acts as a web server towards our app. To do this, it creates a server certificate, issued by its own certificate authority. Since this certificate authority is not one that is trusted by the operating system, the HTTPS request inside the app fails. The FlightRadar24 app chooses not to show an error message when this happens so to the end user the result is that no flights show up.
What we can now do is get the operating system to trust the certificate issued by Fiddler. I’ll show how to do this for iOS.
Point Mobile Safari at http://ipv4.fiddler:8888/ while your phone’s proxy server is set to Fiddler.
This page provides the Fiddler root certificate. Installing a new root certificate is something that should be done with care. For this reason, the operating system will ask you to confirm multiple security prompts.
Tap FiddlerRoot certificate.
Tap Allow.
Tap Install to install the certificate DO_NOT_TRUST_FiddlerRoot.
Tap Install again.
Tap Install again.
Tap Done.
Open the Settings app and go to General → About → Certificate Trust Settings.
Activate the switch next to the DO_NOT_TRUST_FiddlerRoot certificate to enable the certificate. Make sure to turn this switch back off after you’ve finished inspecting your app’s traffic.
Confirm the installation by tapping Continue.
You’re done! The iPhone will now trust HTTPS requests that have intercepted by Fiddler.
Let’s have a look at the FlightRadar24 app again.
Suddenly, the app is working again and we can inspect all the traffic! Now you can dig into each request and see the communication the app is having with each server. Using Fiddler’s AutoResponder, you could also manipulate the data the app is receiving.
The reason this works is that the app is relying on the operating system to check the validity of certificates for HTTPS communication. If the app had been using certificate pinning, we would not be able to inspect the traffic at all using Fiddler.
One more note for Xamarin developers: Requests from your app to a backend are typically sent using HttpClient. There are multiple implementations of the HttpClientHandler that HttpClient can use and not all of them honor the HTTP proxy settings of the operating system. I wrote another blog post on the different types of handlers. If none of your app’s communication is showing up in Fiddler although the app is working, you will have to set the HTTP proxy server manually in your code.
HTTPS is on the rise. This is a good thing. HTTPS ensures your network communication is encrypted in both directions, protecting your app’s users. If you write the code
you are basically doing the same as a user entering the URL into the browser’s address bar would do. The user agent does a handshake with the host you specified, retrieves its certificate and checks the validity of that certificate according to a few criteria, e.g., host name, expiration date, revokation, and trust chain. Let’s have a look at a certificate, in this case the one for www.microsoft.com:
You can see details such as the expiration date or the host names the certificate is valid for. You can also see the certificate chain. This certificate was issued by the certificate authority “Microsoft IT TLS CA 4”. And its certificate was issued by “Baltimore CyberTrust Root”. Baltimore CyberTrust Root is in the list of trusted root certificates of most operating systems and that is why I can connect to https://www.microsoft.com/ without getting an error message.
This root certificate list is unfortunately the weakest link in the entire HTTPS story. Most users don’t check which root certificates are installed on their machine. There have been cases where computer vendors added their own certificate to the root certificates list. And there are also numerous companies that install the company’s root certificate onto each employee’s device so they can monitor all traffic by doing a man-in-the-middle attack.
For the browser story, this is currently the only way to make sure your browser can connect to all HTTPS servers on the internet, even those it has never contacted. But for a connection from a mobile app to its backend, you usually know exactly which server you’re connecting to. From a security perspective, it is a good idea to take advantage of this.
The most effective thing you can do is to get the root certificate list out of the picture. If you control the server and the certificate on the server, you can check if the certificate is the exact certificate you are expecting. You can do this by comparing if certificate’s public key is the one you are expecting. Here’s how to do that with .NET:
This code replaces the default certificate validation with custom code. This code compares the public key of the server’s certificate with the expected pubic key of the server. This public key corresponds with the private key that is installed on the server. Since it is not possible to derive the private key from a public key, this means that we can guarantee we’re talking to that one server and not any server our operating system happens to trust.
This code has a couple of limitations you should be aware of:
An alternative you can think about is rolling your own certificate authority and pinning not the certificate itself but the certificate authority. Even though a browser would not trust such a certificate from an unknown certificate authority, a mobile app would work just fine.
What is commonly referred to as SSL (Secure Sockets Layer) was actually renamed to TLS (Transport Layer Security) in 1999. TLS 1.2 is the current version and TLS 1.3 is expected to be finalized soon. All older version, including SSL 2, SSL3, TLS 1.0, and TLS 1.1 should not be considered sufficiently secure anymore at this point. At this time, TLS 1.2 should be used for all communication.
When using default settings, both the client and server will allow downgrading the connection to an older standard as part of the initial handshake. This is to allow new clients to connect to old servers and to allow old clients connect to new servers. But since we’re controlling both client and server, there is no reason to allow downgrades to the not sufficiently secure TLS version 1.1 or lower. The solution is to force both the client and the server to only allow TLS 1.2 connections. With HttpClient in .NET, this is done like this:
If you’re using Azure Websites as your backend, here’s an article on how to disable older TLS versions.
Xamarin developers will have to be aware that there are different implementations of HttpClient available and not all support TLS 1.2 or other security features. For help on picking the right HttpClient, I wrote a blog post entitled The many flavors of HttpClient.
Pinning both the certificate and the TLS version will make it much harder to intercept the communication between your app and its backend. It should be employed whenever making calls to a backend within the control of the app developer.
A few weeks ago at Xamarin Dev Days Graz I was asked a question I’ve been asked many times before: How do I obfuscate my mobile app’s code? My answer is always a counter-question: What are you trying to achieve by obfuscating your code? I’ve gotten different answers to this question and I want to dig into some answers I’ve received in the past in this blog post series.
A common answer is that there is some key or certificate that needs to be protected in the code.
I don’t believe code obfuscation is a good solution to this problem. I believe there typically isn’t anything that requires obfuscation inside an app’s code. Any attempts at hiding things inside an app’s code will only increase the effort it takes to get at that information but will not prevent it.
Some solutions I’ve heard for hiding a key inside the app code:
Let’s look at why these keys are there in the first place. In most cases, the key is used to authenticate the app towards a backend which is commonly referred to as an API key. For example, if you look at the Parse SDK Getting Started in the Xamarin Component Store, you’ll find this:
What the API expects here is a unique app ID and a key. The key gives you access to your data on the backend. The big problem here is that this one key is being used by all instances of the app.
A team at the University of Paderborn did an experiment to see if they could find that key inside app bundles in the Google Play store for apps that were using Parse. Using a simple static code analysis was enough for some apps but combining that with a dynamic (runtime) analysis was enough to retrieve the API key for all apps that were analyzed. Think about it: At some point, the app will have to call the method ParseClient.Initialize() with the plaintext key in memory.
The team then went on to analyze what they could access using those extracted API keys. The least information they could get for each app was a list of verified user email addresses. In many cases, they had complete read or even write access to all database tables for each app’s backend. The data found ranged from pictures, location information, contact information, and sales information to data gathered by trojans (yes, even the bad guys used Parse as a backend).
Parse is just an example here. You can find these API keys used in many backends and there is hardly an app out there that does not use any API keys. Anyone who extracts that API key can do whatever is allowed with that API key. This may or may not be a problem depending on what type of API key is at hand. It’s important to put yourself into the position of an attacker: What could someone who gets ahold of your API key do with that key?
In the case of Parse, it would have been possible to add user management and additionally authenticate users to access resources. That way, the API key itself would not have allowed access to all this data.
If you’re designing your own backend, you need to think about what type of data it is you are exchanging with your backend. Sometimes it may be OK to have your app access data from the backend without providing any credentials. This may be true for information you could also put on an unauthenticated website. But many times, you will be exchanging non-public information with your backend. In this case, it is always better to authenticate not the app but each user. The advantages are:
If you do have to use a service that requires an API key, it is usually best to not make that call from within your app. A better approach is to make an authenticated user request the information from your own backend and then let your backend make the 3rd party API call on behalf of the user. The advantages here are:
To hear more about this topic, you can watch my Xamarin Evolve talk on app security or stay tuned on this channel for more posts in this blog series.
I’ve updated my previous post “The many flavors of HttpClient” with current information on everything you need to know about HttpClient on Xamarin.
I co-authored a blog post with my co-worker Robin Wiegand on bringing Xamarin and Cordova together. Enjoy!
When using Xamarin, you can use the standard .NET HttpClient. By default, HttpClient is Mono’s complete reimplementation of the entire HTTP stack. It is sufficient for many use cases but there are other alternatives out there that can be defined by selecting an alternative HttpClientHandler. For my Evolve talk, I put together an overview of the different HttpClientHandlers you can use:
CFNetworkHandler (iOS 6+) and the new NSUrlSessionHandler (iOS 7+, starting with Xamarin.iOS 9.8) are the handlers that utilize Apple’s native APIs instead of the Mono implementation. You can define which handler the HttpClient default constructor will use either in the IDE or by providing an argument to mtouch (e.g., --http-message-handler=NSUrlSessionHandler).
For Android, there is now AndroidClientHandler (starting with Xamarin.Android 6.1). There is no IDE option for defining the default handler yet but you can define it using the @(AndroidEnvironment) build action on a text file in your Android project to define an environment variable XA_HTTP_CLIENT_HANDLER_TYPE to the value Xamarin.Android.Net.AndroidClientHandler.
Alternatively, you can use ModernHttpClient by handing a NativeMessageHandler to the HttpClient constructor which will also use native implementations for making HTTP calls.
The default Mono implementation does not support the newest (and most secure) TLS standard 1.2 while the native handlers do. To use TLS 1.2 with the Mono implementation, Xamarin.iOS 9.8 introduced the option to swap the TLS implementation with P/Invoke calls into the Apple’s TLS implementation. This can be selected either in the IDE or by adding the --tls-provider=appletls option to mtouch‘s options.
For Android, there is no such option but it is expected that BoringSSL support will be added soon.
Here’s the summary slide I showed in my talk:
Xamarin have actually gone through the trouble of reimplementing the TLS code to support TLS 1.1 and 1.2. However, it is expected that it will be abandoned because of security considerations in favor of the native platform implementations, just as Microsoft has done for Windows.
Here’s an update on the current state of HttpClient:
AndroidClientHandler your Android project’s properties page, just as you already could for iOS.BoringSSL into their codebase. For Android, this option is also selectable in your project’s properties page. BoringSSL also brings TLS 1.2 to the Unix/Linux implementations of Mono.ServicePointManager. Thomas Bandt wrote an excellent blog post on how to get certificate pinning working with ModernHttpClient and even AndroidClientHandler.And here’s the updated matrix:
On April 1, 2016, I was awarded the Microsoft MVP status for “Visual Studio and Development Technologies”. It is an incredible honor for me and I am still a little in shock. Already, I’m seeing new information pour in and new connections being made and I am really excited about the road ahead.
The shocking part for me was that I had concentrated my community work almost entirely on Xamarin technology. In October 2015, a change in the MVP program categories meant Xamarin was now one of the award category technologies (hey, even Java is on that list!).
I was nominated by Microsoft Technical Evangelist Daniel Meixner at the end of 2015 (thank you very much!), then there was a review, and apparently, my contributions were sufficient for the award committee.
I don’t plan on decreasing my efforts in 2016. I contributed to the MvvmCross 4.0 release at the beginning of the year, I’ve already done two public presentations, and I’ve found the time to blog. With Xamarin Evolve around the corner (where I’ll also be speaking) I’m anxious to find out which direction Xamarin and now Microsoft are going to take the cross-platform adventure we’re on. The announcements at Build made me very happy, personally, and I’m looking forward to sharing the knowledge with more people.
If you want to hear one of my presentations, keep an eye on my public speaking list where I’ll also be posting links to any videos or slides in case you missed the talk.
Above all, many thanks to my employer Zühlke who is supporting my community activity with time and money!
The Xamarin platform allows developing iOS and Android applications entirely in C#. Sometimes, however, some legacy code may be too large or complex to make porting it to C# for your mobile app worthwhile. Most examples found online show you how to use existing Objective-C libraries in Xamarin.iOS and existing Java libraries in Xamarin.Android. However, it is entirely possible to call C code from a Xamarin app. Microsoft’s recent support for C/C++ on iOS and Android in Visual Studio can make this a simple task.
You will need the sources for the code you want to call to compile it for iOS and Android. The code cannot access any libraries which you only have binaries for that have been compiled for other platforms.
To get started, create a new C++ cross-platform project using Visual Studio 2015.
You will need to have the corresponding Visual Studio package installed to have this option available.
This will create three projects: one for Android, one for iOS, and a shared project.
It is important to understand the shared project concept for this. The code in the shared project does not result in a DLL or library being generated. A shared project can hold any type of file. Projects referencing the shared project can access code from any file in the shared project. The code will then be compiled in the context of the referencing project. If code is not referenced, it is not compiled. For this reason, it is necessary to have calls into all code needed contained in the platform-specific projects. This means that the platform-specific C/C++ projects need to contain code, too. This code can be identical in the Android and iOS projects and reside in the same files. Unlike in .NET projects, file linking is not needed for C++ projects; source code files do not have to reside inside a project’s folder or subfolder.
In the example, I’ve created a simple function clib_add_internal() that add two integers and resides in the shared project.
This code is called from a function in the platform-specific projects.
For the example code, this doesn’t make any sense. For a real project, you will put any call that needs to be directly invoked from the .NET code (your interface) into the platform-specific projects while underlying code can reside in the shared project.
The calls from .NET will be using P/Invoke since C++/CLI is not available on iOS or Android. So the basic P/Invoke rules apply for your interface’s code: Either the code is plain C or, if you are using C++, the calls are either plain functions or static methods and contain only POC parameters and return values.
For the iOS project, the output format needs to be changed to a static library (.a file) since iOS does not allow dynamically loading code. For Android, a dynamic library (.so) should be built.
While the Android library can be compiled within Visual Studio, compiling the iOS library needs a connection to a build agent on the Mac. This is not the regular Xamarin.iOS installation on a Mac but a Microsoft tool that is installed on OS X using npm. Visual Studio will communicate with this tool through TCP/IP.
To call the native code, create a Xamarin project for iOS and Android each. Include the native libraries in the respective Xamarin projects.
On iOS, if you’re targeting multiple processor architectures (either supporting pre-iPhone 5s or supporting the simulator), you can build the iOS project for multiple platforms using the dropdown in the toolbar. Then, combine the libraries into one using lipo according the Xamarin docs. On Android, you’ll need to modify the .csproj according to the Xamarin documentation to specify the .so files for each platform.
The calls into the native code are regular P/Invoke calls (although DLLs don’t play a role here). On Android, you specify the name of the shared library.
On iOS, use the special Mono name __Internal to call into the static library.
And that’s it! You can find the example code at https://github.com/lothrop/XamarinNative. In the example, I put the C# marshaling code into another shared project that is referenced by the Xamarin.iOS and Xamarin.Android projects.
When using MvvmCross in a cross-platform mobile project you have the choice of four different approaches for creating the iOS user interface. Xamarin.Forms is one of those approaches that can be a good choice for many use cases (even if there is not graphical designer at this point). However, if your view has very specific visual requirements, it may be necessary to create a native view. There are three different ways you can do this:
MvvmCross supports all three native approaches.
This approach obviously produces the most code. It may be challenging for people new to the platform but it saves you the hassle of battling with the UI designers.
If you’re already on Xamarin 4 and prefer a visual editor, this is likely the best choice for you. Create a new XIB View Controller file using Xamarin Studio or Visual Studio. The ViewController code will also be created for you. All you need to do for MvvmCross is to change the base class from UIViewController to MvxViewController. In the example, three UI elements were created using the designer and were given the (not so creative) names UiLabel, UiTextField, and UiButton. These elements are then referenced in the data binding code that is common to all three approaches.
The big advantage of storyboards, the ability to design your screenflow in the designer, does not fit well with MvvmCross’s cross-platform navigation approach. If you define a transition from view A to view B in the designer it will only apply to the iOS platform. It is typically a better idea to move this navigation logic down into the cross-platform code inside your ViewModels. That is why it’s best to use a one-ViewController-per-storyboard approach when using storyboards in MvvmCross.
In the editor, you need to set the storyboard ID to the name of your ViewController. As with the XIB approach, change the base class from UIViewController to MvxViewController. Create a constructor taking an IntPtr and passing that on to the base class’s constructor. The last step is to add the [MvxFromStoryboard] attribute to the class.
The good thing is: You don’t have to make this decision at project start. MvvmCross supports implementing your view with the technology that is best for each view. You only need to ensure you don’t have multiple views for the same ViewModel and the same platform.
I’ve updated the example in the MvvmCross Starter Pack Nuget (starting with 4.0.0-beta8) to use a XIB file instead of the previous hand-coded approach with absolute coordinates (from the auto layout days). That should make it easier for people to get started.